From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
...
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.
ETRN is part of STMP. The reasons people continue to use ETRN and
UUCP have nothing to do with mere conservatism. In the modern era,
they are too hard use (including keep running) compared with just
going with the flow. They are used because in some situations they
are least painful solution.
More common examples of why relays are required and why they cannot
know whether an incoming message can be delivered during the SMTP
transaction are MX secondaries and corporate firewalls. How can an
MX secondary or corporate firewall know not merely that the Rcpt_To
address is valid but that there will be no problems putting the message
into the mailbox? "User unknown" is not the only 5yz SMTP error code
and not the only contents of a bounce.
...
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.
I don't recall ever seeing a bounce that did not have all of the
information of the original STMP error code. This fact falls out
of the common method of generating bounces. Bounces are commonly
merely logs of the SMTP transaction up to and including the string
that came from the SMTP server including its error code.
Other than the retrying for 4yz error codes and the special case or
kludge to deal with the too many recipients bug in old SMTP servers,
the bounces are already handled exactly the same as SMTP error codes.
In both cases, the error code is shown to the originating end-user. In
most cases, there is nothing that can be done except show the information
to the end-user so that the end-user can decide whether to send to some
other address (e.g. correct a typo), give up, or ask for help.
] From: Daniel Feenberg <feenberg(_at_)nber(_dot_)org>
] ...
] The proposal only suggests that hosts accepting mail from *stangers*
] should know if they are going to deliver that mail before they "OK" it at
] the completion of the mail acceptance process. RBLs do this, most content
] based screening does not, but could if it wanted too. MTAs don't usually
] support this very enthusiastically.
]
] No doubt that some mail architectures will not be able to do this. To
] reject mail for non-existant users the accepting MTA will have to have
] access to the user list, which is sometimes not available to the accepting
] MTA in the DMZ. That would have to change. The alternatives are to stop
] bouncing bad email-addresses or become a vehicle for spammers to abuse,
] neither of which is very attractive.
Before installing a solution, it is best to determine whether the
problem is significant. No evidence has been offered to show that
bounces are a significant problem in the Internet in general. The
Flowers.com court case, the laws against header forgery, or perhaps
other causes have significantly reduced the relative frequency with
which bounces cause problems for innocents. That is not to say that
problems do not occur, but they've not been shown to be significant.
Getting rid of bounces would require all SMTP servers not only to know
that an address is valid, but to predict that there will be no problem
when the message is delivered. The first will not happen in many
corporate environments. There are security reasons that people find
compelling for keeping the DMZ SMTP servers ignorant, and "security"
trumps changes to fix things that haven't been a problem yet. (Note that
I am not defending those security concern but only reporting them.)
More important, it is impossible for an SMTP server to know that
delivery will be successful. Between end of the STMP transaction when
an MX secondary or DMZ SMTP server says "250 ok" and the seconds to
hours later when the server gets around to passing the message, the
user's mailbox could have overflowed, the user name could have been
terminated, or a computer could have crashed.
] We have gone to quite a bit of trouble to start doing Spamassassin
] screening in a Sendmail Milter, rather than in the local delivery agent,
] just for this reason. By refusing mail rather than dropping it on the
] floor we will give senders of false positives a rejection rather than
] risk losing the message entirely.
There are additional, individually compelling reasons to filter in
the MTA instead of the MUA. One compelling reason is that as anyone
who has read the postmaster mailbox for a modest to large domain knows,
bounces have long been unreliable. Many bounces "double-bounce" into
postmaster mailboxes or just disappear into black holes. As in most
situations, it is best to detect and report as early and directly as
possible.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg