[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Jon Kyme wrote:
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 ?
Basically, yes. There's a page located at <http://postmaster.info.aol.com/guidelines/standards.html> that details their anti-spam policies. For all I know, my server my run afoul of more than one.

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?).

I'm not too familiar with this. I'll read it later today.

Philip Miller


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg