Hi Wietse,
If you think that Postfix uses the wrong error type,
then that is a request for a source code change.
It would be nice if there would be option to configure alias expansion
response codes like it have it in many other places that ends with
"_code" under Postfix Configuration Parameters
<https://www.postfix.org/postconf.5.html> and "_reason" to adjust text,
or just something like "reject_alias_expansion_loop = yes" where
default is "no" (current behavior).
Hi Viktor,
Only if you (choose to?) ignore problems. Others have an opportunity to
fix them and not lose mail.
Thank you for feedback, will evaluate a bit then. The reason is that for
private use (or use in one not really big corp) use you will able to
find who was created that alias and figure out where end user expect to
get that email and fix alias configuration in reasonable amount of time
without much effort.
But on system where you far ago from user and have 0 contact with him
getting such information is mostly impossible, and totally impossible in
a reasonable amount of time. In such scenario throwing permanent error
to sender looks like much more valid approach. What you propose is
grep\alert on this event and manually drop looping aliases and clean the
queue each time user break something on his alias? I don't think it's
operator friendly approach :)
In short:
*
For external mail (sender), it results in delayed bounces, blurry
diagnostics, and operator frustration.
*
It’s not actionable unless you grep logs and apply manual steps to
do what you would do anyway - drop alias which will result in near
same 5xx error, but on rcpt to.
*
Other Postfix features (e.g., content filters, policy maps) allow
fine-grained control. This one doesn’t, and it's an operational
blind spot.
* Verify endpoint can't verify if alias works as expansion done on
cleanup (when saving queue file instead on mail from) which mean
that downstream MTA with always pass verify and accept emails from
outside. This lead to:
o a lot of bounce-backs about delayed and non-delivered emails
instead of instant rejecting inside of same SMTP session (with
verify negative cache in place**)
o increased load on downstream MTA as it will store emails till
email will not get dropped from queue due to it's age,
potentially leading to a service outage due to storage
exhaustion, especially in scenarios of intentional abuse of
service, creation of loops by purpose and mail bombing
Based on that I would say that alias expansion process would be nice to
happen at earlier stage to play well with verify functionality, but I
can guess it would be quite complex change, so well... if there would
ability to reply with 5xx error for detected expansion loop, I think
moving alias map to the incoming MX MTA would be enough + setting
transport map for a next hop of all emails.
Thank you
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 04/07/2025 21:07, Wietse Venema via Postfix-users wrote:
Dmytro Alieksieiev via Postfix-users:
Hi Postfix community,
Does anybody know the original reason of why there is no way to adjust
response code for Alias expansion error (internal loop detected) in
Postfix settings?
This enhanced staus code codes was chosen 20 years ago based on
error categories in RFC 3463. Making this configurable makes no
sense to me. If you think that Postfix uses the wrong error type,
then that is a request for a source code change.
I consider "alias loop" not as as permanent as "user unknown".
Wietse
_______________________________________________
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
