On Sun, 6 Apr 2003 05:30:58 -0700
Phillip Hallam-Baker <Hallam-Baker> wrote:
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.
I think twenty years is more than enough time to phase out an obsolete
protocol. If stopping spam breaks UUCP then UUCP breaks, don't give it
a second's thought, that is a problem for the UUCP diehards to solve,
on their own.
Large chunks of the 3rd world, as well as both hostile and remote
environments hang off UUCP links (ObNote: I did for years). The fact
that this works and very cost effectively is something to be admired;
very much an example of a "suitable technology". Should various
people's dreams about the 'net in space (colonies, stations, etc) be
realised I suspect something very like UUCP (and FTP by mail etc) will
resurface. Assuming that only the directly small-latency connected are
or can be "interesting" seems painfully chauvinistic and
segregationalist.
I would start from a different premise, I would not 'ban the bounce'
instead I would observe that bounces are going to be much less likely
to get through in the future.
Ouch. That would transfer SMTP from an occasionally and rarely
unreliable protocol to one that is both explicitly unreliable and
unauditable at the transport level.
I think one thing to realise here is that email is not bound to SMTP.
SMTP is merely a commonly used transport for mail that has certain
protocol holes and weaknesses that need to be fixed -- problems that are
shared and defined by any asynchronous store-and-forward message-based
protocol. There are other transports that are widely used, and they
will be (increasingly) used as the net grows and extends into different
environments. From our perspective I'd concentrate on two aspects:
1) Changing SMTP as a transport (not as a mail definition), needed to
control the problem (without excluding other transports).
2) Making any needed changes at the RFC 2822 level to support
the necessary transport protocol features.
One approach we could take is to add in an authenticator token into
outgoing messages in such a way that it will be returned in the
bounce. That way an MTA can know if a bounce is legit and not spam.
This is fairly easy to do with a standard secret & MAC protocol.
However that is only solving one part of the problem. The bounce
messages should carry the same info as SMTP error codes and it should
be possible for the MTA to process bounces in a transparent fashion
without showing the bounce message.
Absolutely. In the same line DSNs should, by now, be widely deployed
and a fundamental aspect of using email in the real world. Sadly, error
handling is always the red headed step child and gets the transient
scraps of attention left over from adding ROI-generating features.
--
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