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

From: Matthew Elvey <[email-masked]>
Date: Wed, 24 Dec 2003 10:18:39 -0800

Alan, any thoughts on the
Re: [Asrg] 6. Proposals: LMAP - Forwarding Comment and Recommended Changes
thread? 
It does seem that some solution to the mail looping possibility that 
LMAP's current envelope rewriting creates is a must.
It seems that when there's envelope rewriting, the return address must 
be encoded/stored somewhere, and used when there are bounces.
ENVID or something like it seems like the right solution.  There are 
umpteen ways the ENVID could be used to confidently ensure that the 
relay only relays back bounces of emails it has sent. (As a server would 
be dealing with its own ENVIDs, perhaps the way that this is done need  
be suggested but not required.)

The usage for ENVID that we are considering would break rules specified 
in RFC 1891:

(a) Any ENVID parameter included in the MAIL command when a message was
    received, MUST also appear on the MAIL command with which the
    message is relayed, with the same associated esmtp-value.  If no
    ENVID parameter was included in the MAIL command when the message
    was received, the ENVID parameter MUST NOT be supplied when the
    message is relayed.

Relays should be adding ENVID parameters, though they MUST NOT.
In multihop forwards, we would be replacing, not preserving the ENVID.
Careful consideration of the consequences is needed before we break 
these rules!

On 12/17/2003 2:18 PM, Markus Stumpf sent forth electrons to convey:

> ...
>
>[W]ithout 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
>  
>
What are these problems, and will they exist in an LMAP world?
Let me guess: relay gets a bounce to user=destination%otheruser@relay 
that isn't really a bounce; it's spam to user@destination.
Without tracking, the relay could still only allow bounces that looked 
like bounces (MDNs or from postmaster/mailer-daemon) but a spec allowing 
this would still effectively be saying it's OK to run an open bounce 
relay, which would be bad.

Currently, I can send spam by sending 'from' the target address 'to' an 
invalid address on a machine that accepts and bounces such email to the 
target address.
However, this is not possible with most machines, which refuse, instead 
of accept and bounce such email.  This is best practice, and 
increasingly common.

I would like to suggest two alternate solutions that resolve the mail 
looping possibility.
1)The sending system connects to relaying-lmap-mta and begins sending an 
email to an address that has forwarding set up to next-mta.
relaying-lmap-mta receives the email up to the end-of-data marker, but 
does not reply immediately.
Instead, it initiates relaying of the message to the destination.  Only 
after next-mta accepts the message does relaying-lmap-mta accept the 
message from the sending system.
This solution will not work in the rare situation where 
relaying-lmap-mta is not continuously connected to the 'net.
However, it works in the vast majority of cases, and will reduce bounces.
Perhaps this should be done, wherever possible, with ENVID as a fallback 
solution only when relaying-lmap-mta is not connected to the 'net.
2)A second alternate solution would be for the sending system to be told 
the forwarding address by relaying-lmap-mta (e.g. using EXPN) and send 
the message directly there iteself, but this would cause privacy and 
security problems; seems like a nonstarter.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 25 Dec 2003 10:37:28 +0000

> Careful consideration of the consequences is needed before we break 

If the message has a new envelope then it's a new message. Even if it has
the same *body* as another message. So we're not really relaying when we do
this kind of forwarding - we're injecting a *new* message into the MTS. So
why not create an ENVID?

Consider mail forwarding for some hosting clients. Their MXs point to one
of our machines which just has a bunch of aliases to shove the mail on to
whatever their "real email" is. So mail to [email-masked] comes to
us. Then, in the aliasing, a *new* message for
[email-masked] is generated.
That is to say, mail to [email-masked] is addressed to an entity
which is responsible for generating new messages actually to the client -
it's not relaying as such, because the envelope is new.

--