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

From: Philip Miller <[email-masked]>
Date: Sun, 14 Dec 2003 12:49:07 -0500

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 "[email-masked]" might now read "|/usr/sbin/sendmail
> -oi [email-masked]"
> 
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 17 Dec 2003 12:36:11 -0500

> recipient.

Assuming that the recipient has that level of control.  I suspect that's
a minority situation.

> 3. lmap-mta is forced to relay mail through smtp.isp.com (outside policy, 

  [etc, no need to repeat it all I think]

> 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

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 23:18:37 +0100

On Wed, Dec 17, 2003 at 12:36:11PM -0500, Mark E. Mallett wrote:
> [ ... ]

I don't think so (confused ;-).

I have always wondered if, with LMAP, abusing sender domains will become
impossible, will spammers fall back to empty envelope senders, aka
mimiking bounces? How will we solve THAT problem? The first time they
started admin started blocking empty envelope senders and if this will
be widely used again I fear a lot more admins will block "bounces".

However this will solve the problems with return-path rewriting ;/

Otherwise, without tracking, return-path rewriting with routing
information may lead to the same problems we had with
     user%destination@relay
addresses, with the diefference that it now has a form
     user=destination%otheruser@relay

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Richard Rognlie <[email-masked]>
Date: Wed, 17 Dec 2003 17:24:45 -0500

> be widely used again I fear a lot more admins will block "bounces".

One answer is the DRIP portion of the LMAP proposal.

DRIP operates on the HELO/EHLO part of the smtp conversation.  And
LMAP advises that a null sender be thought of as [email-masked]
(for the purposes of validation).

-- 
 /  \__  | Richard Rognlie / Sultan of Sendmail / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/ <rrognlie at gamerz.net>
 /  \__/ | 
 \__/    | CAUTION: may contain Mature material......but I doubt it.