First of all, there are two separate but not disjoint cases of forwarding
that could occur in a messages transmission path:
1. A Message Originator relays its mail through a third party host
2. A Message Recipient has mail delivered to a designated host, which then
passes it along.
The second case is easy to solve. Rewriting the message envelope in this
case is undesireable, because it would mean that if delivery failed, a
notification could not be returned to the sender. However, rewriting isn't
necessary in this case, because the recipient knows who's relaying their
mail and can make provisions to accept all mail from the designated
recipient.
Assuming that the recipient has that level of control. I suspect that's
a minority situation.
My recommendation for how this case should be handled is as follows. This
scenario should be added in some form to LMAP:
1. lmap-mta is authorized to send mail for sender.com
2. lmap-mta is connected to the internet via a random ISP, isp.com
3. lmap-mta is forced to relay mail through smtp.isp.com (outside policy,
port 25 block, MTA-Mark)
[etc, no need to repeat it all I think]
The missing link in this scenario is the standardized encoding for the
return-path within a return-path.
Others have mentioned ENVID. I suppose that's promising, but one
would have to consider the potential for abuse there. Is it possible
to forge the return-path-within-return-path (envid or otherwise)?
With ENVID, the server owning the ID has to either keep some history,
or has to use an algorithm whereby envids can be verified. The first
seems to require more implementation/deployment impact than we're
allowed to consider; the second would seem to provide an abuse path.
OTOH I may simply be confused.
mm
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg