Let me clarify this a bit. A bounce message should not be sent to
anybody *EXCEPT THE ACCOUNT THAT ORIGINATED THE EMAIL*. The only MTA in
a position to know this info is the the MTA at the sender's ISP (or
place of work or whatever).
On Sat, Apr 05, 2003 at 10:46:12PM -0800, J C Lawrence wrote
On Sat, 5 Apr 2003 23:23:07 -0500
waltdnes <waltdnes(_at_)waltdnes(_dot_)org> wrote:
To continue providing delivery-failure info to legitimate senders,
we will have to use some variant of 4xx or 5xx reject messages.
This creates five obvious problems: inbound and outbound relays,
aliases, .forwards, and header rewriting. Inbound and outbound relays
architectures are extremely common, for good reasons like scalability,
control, oversight, network security/posture, etc. Aliases and
.forwards I'll leave to themselves with the simple comment, "role
addresses".
1) Inbound relays is a design decision. It will have to change in
future.
2) The outbound relay should not be a problem. I *HOPE* that an ISP
is competent enough to log who is logged in, and to be able to translate
a 550 from a distant MTA into a bounce message *TO THE ACCOUNT THAT SENT
THE ORIGINAL EMAIL*.
3) aliases. See 2), the ISP should translate the 550 error message to
a bounce message *TO THE ACCOUNT THAT SENT THE ORIGINAL EMAIL*.
4) .forwards The risks of running a bot.
5) Header re-writing is to good email practice what self-modifying
code is to good programming. Mailing lists are one exception to that.
They should handle 550 rejects properly, because they are effectively
originating a new email.
As soon as a there's a disjoint between the system that the MUA is
running on, and the final delivery address for a mail, return signalling
has to be OOB. What that really means is that as long as the MUA can't
originate a direct TCP connection to the final delivery system, knowing
that its the final delivery system, you have to have OOB error
signalling.
This, of course, implies that the internet-facing MTA will have be
able to make and carry out the decision to reject an email.
It implies rather more than that. It implies that the MUA does all the
hard work from scheduling to spooling on down as well.
WRONG. The *MTA* does that. An ISP knows who is logged on via which
IP address. Until such time as the email has been accepted by the
recipient's ISP's MTA, the email is still queued up on the sender's ISP.
They should be able to generate an *INTERNAL* bounce message *TO THE
ACCOUNT (not the address) THAT SENT THE ORIGINAL EMAIL*.
Current challenge-response systems share the major flaw of bounce
messages, i.e. they blindly accept the "From:" header as gospel.
False. TMDA among other challenge/response systems authenticates on
envelope and From: together. This is deliberate.
And a spammer running "Desktop Mailer" direct-to-MX or going via an
0wn3d machine is *NOT* going to be deterred by having to forge one more
item in the spam.
Removing OOB error signalling is a fundamental protocol change as it
moves SMTP from a largely asynchronous messaging system to a purely
synchronous messaging system.
Main problem is that it's *NOT* OOB. Just ask any innocent victim
who's gotten thousands of bounce messages when a spammer has forged
their email address as the "From:".
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg