As noted in the current discussion draft, LMAP will affect forwarding:
3.4 Message relaying and forwarding are affected by LMAP
Mail forwarders have traditionally left the sender envelope untouched.
"Forwarding" is used in the sense of *ix user .forward and /etc/aliases
files.
Let us examine a situation where an LMAP conformant domain A sends a
message to address B which forwards the message to LMAP conformant
recipient C using the original sender address from A. If the B->C
forward had been set up without the consent of the recipient C, A's LMAP
records would be checked by C's LMAP client, and the message would be
correctly rejected.
If the recipient C did desire the B->C forwarding, three workarounds are
possible.
1) B's MTA could rewrite the sender address to pass C's LMAP criteria
without involving the user B.
2) the user B could alter the .forward such that forwarded messages are
reinjected with B's address in the return-path. For example, a .forward
that was previously "C(_at_)example(_dot_)com" might now read
"|/usr/sbin/sendmail
-oi C(_at_)example(_dot_)com"
3) the recipient C could provide a whitelist to C's MTA indicating that
forwarded messages are expected to arrive for C from B.
LMAP conformant SMTP forwarders should implement a sender rewriting
scheme or its equivalent. Forwarders may work around this issue by
simply modifying .forward files to pipe messages to a local mailer.
[snip]
5.1.16 Factor 4.5 (16), Mailing Lists
[snip mailing list suff because it comes to the right conclusion that
mailing lists should alter the sender envelope]
The one practice which will be most affected by LMAP is the use of
".forward" files. Widespread use of LMAP may make the use of .forward
files problematic.
We recognize that every MTA using .forward files on *ix hosts or similar
configurations do not alter the sender envelope when forwarding mail.
However, commercial and proprietary mail-forwarding systems alter the
sender envelope, and these are by far the most popular pure
mail-forwarding instances.
There is no fix for .forward usage aside from altering the sender
envelope and designating the forwarding host via LMAP.
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. LMAP is useful here, because it lets the recipient designate the
relay to trust by fully-qualified host name rather than IP address and be
sure that it's the host in question.
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.
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. It
requires only information that would be in the DNS as result of LMAP
conformance. It does not require additional cryptographic information or
processing. It does not require domain owners to put semantically wrong
trust statements in the DNS to satisfy third-parties' policies.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg