ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals: LMAP - Forwarding Comment and Recommended Changes

2003-12-17 10:37:38

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