On Sun, 6 Apr 2003 18:00:21 -0400
waltdnes <waltdnes(_at_)waltdnes(_dot_)org> wrote:
Let me clarify this a bit. A bounce message should not be sent to
anybody *EXCEPT THE ACCOUNT THAT ORIGINATED THE EMAIL*.
What is the definition of, "the account that originated the email" for
mail originating from an automated system, such as a cron job, make,
logcheck, or similar?
In what way does this alter Return-Path semantics?
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).
How do they know? A standard ISP has several hundred thousand domains
typically. Do we require per-mail account registration and
authentication for senders? Where's the value add to the ISp to deploy
all the extra machinery, configurations, and end-user tech support for
such?
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.
Its a pretty hard thing to remove as use of inbound relays is one of the
early tools in building scalable mail processors (they provide
buffering, control, review, etc). Inbound relays also (essentially)
match the definition of transport protocol gateways, and secondary MXes.
What happens for a delivery error when a secondary MX delivers to the
primary MX?
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*.
See above. There's an assumed knowledge space there which doesn't
currently exist and is difficult to make exist. If you add things like
per-mail user authentication (shared secret, whatever), then perhaps.
However, that gets even more difficult with things like, ohh, a company
with its own domain and an intermittent connection using an ISP's
smarthost to relay out mail, a multi-homed company also using a
smarthost, or a standard distributed corporate deployment using a single
outbound relay (as IBM for instance once did, several chunks of the US
military still do, etc).
3) aliases. See 2), the ISP should translate the 550 error message to
a bounce message *TO THE ACCOUNT THAT SENT THE ORIGINAL EMAIL*.
How do you handle the case where an alias points out of domain, or where
an alias points to several delivery targets, only some of which error?
4) .forwards The risks of running a bot.
They are essentially no different than aliases.
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.
Actually, they don't. Assuming an ISP and a dialup account, they can at
best currently know a class of addresses which could be infinite in the
registered domain case, but could easily be >1 in the NAT or multi-user
household case.
Why are you dealing only with ISPs? A small fraction, less than half,
of the mail that I deal with originated behind a consumer ISP.
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.
So no secondary MXing then, and the recipient MTA has to have perfect
knowledge of the state behind it such that the it can guarantee (or not)
successful delivery of a message at SMTP time...
Ouch.
You just lost the majority of the developed world there.
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.
True, tho the problem is knowing and getting both the envelope and From:
right for a given message to a given recipient. <shrug> It can happen,
I've seen KLEZ do it twice in the last year.
There's a more simple clarity here. If JoeBloew's machine can email
various people, then rogue software in control of JoeBlow's machine can
email those same people. If we require manual revelation of a secret by
JoeBlow to be able to send mail, then there is nothing to prevent that
same rogue software from compromising the secret or impersonating
JoeBloe in other ways. Additionally, such a manual repetitive barrier
will actively encourage Joe to not use email at all...
Where's the win?
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.
Ahem. They do not occur within the SMTP session that sent the message
generating the bounce. (Tho I admit they use the same transport and
*MAY* use the same physical systems etc).
Just ask any innocent victim who's gotten thousands of bounce messages
when a spammer has forged their email address as the "From:".
As I mentioned early, I just got thru receiving a little over 80,000
such bounces.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg