On Fri, Jul 04, 2025 at 10:26:09PM +0200, Dmytro Alieksieiev via Postfix-users
wrote:
> > Only if you (choose to?) ignore problems. Others have an opportunity to
> > fix them and not lose mail.
>
> 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 :)
You don't have to drop the looping alias, you can either:
- If all relevant mail arrives via SMTP, add an access(5)
REJECT table entry, while the problem is investigated
and eventually addressed.
- Prepend an override virtual(5) alias table to the list
of tables, used to temporarily redirect problem messages
to a suitable mailbox, while the problem is investigated
and eventually addressed, at that time, the saved messages
can be delivered to the appropriate recipient(s).
> For external mail (sender), it results in delayed bounces, blurry
> diagnostics, and operator frustration.
Yes, any ignored problems will eventually result in a bounce.
> 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.
As noted, the delay gives time for operators to notice and/or users to
complain they're getting no mail. When the problem is fixed in time, no
mail is lost. Postfix is an "opinionated" MTA, optimised to work hard
to not lose mail under various adverse conditions.
> Other Postfix features (e.g., content filters, policy maps) allow
> fine-grained control. This one doesn’t, and it's an operational
> blind spot.
No, this is a consistent design feature, similarly, DNS lookup errors
(not NXDOMAIN, but SERVFAIL and the like) are unconditionally soft
errors in the Postfix SMTP server, and when persistent, will sometimes
lead to late bounces, the problem may be a local issue, network issue,
or a misconfiguration in the remote authoritative DNS service.
Regardless, Postfix will report a soft error.
> * 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
In a two-stage mail system with an edge MTA relaying inbound mail and
alias expansion happening downstream, you don't need to parse logs to
detect problems with inbound forwarding, unless something is very wrong,
inbound mail should be forwarded in seconds, or perhaps a few minutes.
All you need to do is monitor the queue of the inbound relay MTA, and
fix any problems that result in messages sitting around for more than
a few minutes.
> Based on that I would say that alias expansion process would be nice to
> happen at earlier stage to play well with verify functionality,
That was the system design in the perimeter MTAs I configured for prior
employers, alias expansion (via LDAP) took place at the edge.
> 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.
I don't think this is a sound feature to add, it would be misunderstood
by naïve users.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
