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

["Jon Kyme" <jrk@merseymail.com>]

> 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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg