Hello,
The Arnt's approach leads to evaluating DSN as spam, thus leaving
them unread, a.k.a. useless.
Does anybody see any disadvantages of ending the session
EHLO server.example.com
250 OK server.example.org
MAIL FROM:<spammer(_at_)example(_dot_)com>
250 OK
RCPT TO:<spamtrap(_at_)example(_dot_)org>
250 OK
RCPT TO:<mailing-list(_at_)example(_dot_)org>
250 OK
DATA
354 OK
That is all.
.
with
550 Mail rejected by mailing-list(_at_)example(_dot_)org
which implies, that the mail was accepted by all but
mailing-list(_at_)example(_dot_)org?
Aside from the fact that such usage is entirely nonstandard and no SMTP client
is going to be able to deal with it, there's no disadvantage at all... In fact
SMTP clients are required to operate entirely on the basis of the reply code so
this is going to come across as all recipients having been rejected. I believe
A any other behavior from a client would actually be a standards violaation,
not to mention a bad idea.
How many evelopes I receive do have more than one recipient? Well,
except the spam almost nothing. But imagine a mailing list that has
1000 subcribers. 10 mails for sure will go for the same domain, so for
that 10 subscribers giving a temporary error after the second RCPT
would lead to huge delays (<=> grey listing).
This is a very worrisome statement given that the only real way to address this
issue in general is with an extension to SMTP that provides functionality
similar to the multiple responses LMTP allows (but without the additional
semantics implied by LMTP).
The problem with SMTP extensions of this sort is that they are fairly useless
until there are enough implementations out there that there's a good chance
the extension will be available when it is needed. If the majority of people
who are sending you messages with multiple recipients are spammers, what would
the incentive be for these spammers to implement this? I very much doubt that
spammers care about your problems returning DSNs. So if your claims are correct
where's the benefit in doing this?
This extension also has the unfortunate charactistic that clients get very
little benefit out of implementing it no matter what, and unless you already
have LMTP support in your client coding this can be a fairly nontrivial
undertaking. The server side is another matter - server side is where the
benefit is - but a bunch of servers supporting it without corresponding client
support isn't useful.
More generally, the issue with SMTP extensions is always whether the cost of
deploying it worth the benefit you get out of it. Sometimes you get lucky and
extension support deploys not because of the utility of the extension but
rather because the support happened to be in versions of popular email software
that needed to installed for other reasons. But you cannot count on this, and
deployment costs in SMTP can be surprisingly high, especially for extensions
that change the command-response structure of the protocol - think of what this
means for stateful inspection proxies, for example.
Finally, I also note that there has been at least one proposal put forward to
address this:
http://www.watersprings.org/pub/id/draft-hall-prdr-00.txt
So at least there's a proposal on the table.
Ned