[LBBS-70] mod_smtp_delivery_external: Use SRS for externally forwarded messages
This is an issue/improvement exposed by the resolution to [LBBS-53].
When server A sends a message to server B, which forwards it directly to server C, the MAIL FROM of the message C receives is still that used in the transaction started by A, passed through intact by B. This is known as "plain forwarding", where the envelope sender is untouched: https://en.wikipedia.org/wiki/Email_forwarding#Server-based_forwarding
Currently this is implemented simply by adding the forward-to address during rules processing (in mod_mailscript or mod_sieve), where the forward-to address is simply added as a recipient to the existing job: https://github.com/InterLinked1/lbbs/blob/master/nets/net_smtp.c#L1463
While this is "conventional", in practice, this is likely to cause issues these days as SPF checks will fail at C, since the MAIL FROM used by B when forwarding the message externally doesn't resolve back to B. DKIM should still succeed, but if DKIM isn't set up at A, then this could cause a DMARC failure at C, leading to the entire message being rejected.
Here is a project that solves this for postfix: https://github.com/roehling/postsrsd
As can be seen, it implements SRS (Sender Rewriting Scheme): https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
We should consider doing something like that on messages such as the above. Unlike the postfix version, since the LBBS SMTP server is fairly monolithic, we can (and should) optimize it such that SRS is only used when forwarding a message received from another server, and only when forwarding it to another external mail server. In the cases of the source or destination being local, there is no need to rewrite the envelope sender.
Additionally, we could use an advanced technique such as using a unique, temporary envelope sender address that is only good for that particular message, for a short period of time. However, in the case of forwarded messages, these are due to the user explicitly forwarding it, and I think it could be just as logical to use the recipient at B's address as the new MAIL FROM address in the transaction towards C. Since this could be different for each forwarding rule, we would need to keep track of extra state telling us who requested the message be forwarded, so the RCPT TO address that triggered that forward as the new MAIL FROM address for that particular (and only that particular) delivery.
VERP / improvement of the return paths used for mailing list posts could also be improved here (a unique bounce address per recipient): https://github.com/InterLinked1/lbbs/blob/master/modules/mod_smtp_mailing_lists.c#L391
Also see: https://datatracker.ietf.org/doc/html/draft-varshavchik-verp-smtpext-01
Comments
You must be