ietf-asrg
[Top] [All Lists]

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

2003-12-15 04:13:40
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.
[snip] 



The first case is much trickier. It means that a third party to a 
commmunication must be trusted. For example, all of my outgoing mail,
with
the zemos.net domain, is relayed through smtp.comcast.net because of
broken
mail policies at other domains (read: AOL). This 'smart host' is
effectively
an open relay for all Comcast customers. If I don't add it to LMAP,
messages
relayed through it would rightfully be rejected by the recipient MTA, 
because they don't originate from an LMAP designated MTA. However, if I
do
add it, any Comcast customer would be able to forge the zemos.net domain 
without trouble.


I take it that the policy that you're referring to as broken is the policy
of not taking mail from dial-up IPs ?



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)
4. smtp.isp.com is authorized to send mail for isp.com
5. lmap-mta connects to smtp.isp.com and transmits a message with a MAIL 
FROM in sender.com.
6. smtp.isp.com verifies that lmap-mta is LMAP-authorized by sender.com
7. smtp.isp.com accepts the message
8. smtp.isp.com rewrites the sender envelope to encode the original 
return-path in an address at isp.com
9. smtp.isp.com connects to mx.recipient.com and transmits the message
10. mx.recipient.com verifies that smtp.isp.com is LMAP-authorized by
isp.com
11. mx.recipient.com accepts the message, but is later forced to generate
a
bounce notice about it.
12. mx.recipient.com sends the bounce message to the isp.com return-path
13. isp.com's MX sees the specially-encoded return-path and passes the 
notification to the original return path.
14. The message originator @sender.com receives the bounce message.

The missing link in this scenario is the standardized encoding for the 
return-path within a return-path. If this idea is already in use by some 
commercial servers, I'd love to hear about it. If not, we need to come up
with some appropriate design (some variation on VERP might work) and
suggest
it in the LMAP draft. There's no need to REQUIRE the use of a specific 
format, because it only needs to be uniform within each ISP or relay, not
Internet-wide.
This makes LMAP a reasonable alternative to Yahoo's Domain Keys proposal.

I think you're right, to make this kind of relaying work nicely, something
along these lines would need to be provided. It makes the return-path the
same as the outward path. That symmetry is probably a Good Thing and might
be usefully provided for your second case (and others) also,
i.e. all intermediate MTA should perhaps have the ability to rewrite the
envelope from and decode for bounces.

Would it be useful to consider rfc3461 ENVID in this context?
I don't know how wide support for this is (is there any?).









--

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg