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".
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.
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.
I do realize that there is a significant difference in scale between a
small ISP, versus AOL. Looking up a RCPT: address amongst 30 million
main addresses (and who-knows-how-many "screen names") requires
significant hardware/software to do in a timely manner. But it will
have to be done. Otherwise other people, and entire ISPs, may be
forced to blockade in self-defense against biggies who
mailbomb-by-proxy.
You also assume that mail is delivered to directly connected systems
only. What about, say, domains sitting behind UUCP or ETRN links
wherein the relay box *HAS* no knowledge of accounts configured on that
domain as it has no organisational ties to it other than as an MX.
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.
--
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