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(_at_)relay
addresses, with the diefference that it now has a form
user=destination%otheruser(_at_)relay
What are these problems, and will they exist in an LMAP world?
Let me guess: relay gets a bounce to user=destination%otheruser(_at_)relay
that isn't really a bounce; it's spam to user(_at_)destination(_dot_)
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg