Hello,
Let's limit us now on hosts, that do not offer PRDR.
** 550 Mail for mailing-list(_at_)example(_dot_)org rejected **
> The 550 code means that mail to the above-mentioned recipients
(spamtrap(_at_)example(_dot_)org and
> mailing-list(_at_)example(_dot_)org was rejected for policy reasons. A DSN
may
be sent by server.example.com
> to both recipients. The recipients may not see your reject message or
they may not understand it.
Is there any software nowadays, that sends DSN to the recipients telling
them that they cannot receive emails?
There's tons of it. In fact there are plenty of cases where submissions
intentionally accept messages they know are undeliverable just so they can send
back a DSN later. (We routinely have customers set things up this way.) The
usual reason for this is to work around incompetent clients that fail to
display error messages correctly or consistently. (Such clients are, sad to
say, fairly common in some places.)
In my eyes, for normal users when a server answers with "550 Mail
rejected", the sending user receives a mail, telling her "The server
said: 550 Mail for mailing-list(_at_)example(_dot_)org rejected".
It depends on when the error is detected. If the error is detected during
initial submission the user agent typically throws up a window containing
whatever message the server put out. (But not always - see above.) Whether or
not there's additional information in that window is hugely client dependent -
it can vary from just an unadorned message to an elaborate display with the
actual server error appearing only as a kind of footnote, or in some cases
isn't displayed at all.
If, OTOH, the error is detected during a relay operation, which is the norm
with the sorts of errors you have been talking about, the SMTP client takes the
error it got from the server and constructs a DSN to send to the user. The DSN
will say something along the lines of "sending mail to these addresses failed,
the server gave this reason for the failure". And how the DSN is actually
displayed is also client dependent.
What does the user think now?
With your proposal the user is likely to be very confused because odds
are they got a message in effect saying:
Could not send mail to a,b,c because "b was rejected".
A short time later there's a nonnegligable chance said user will be on hold
waiting for customer support from their ISP. This is not a direction that will
bring joy to the hearts of the folks who run large mail systems.
Does she come to the idea, despite what is written in
RFC 2821, that the mail has reached no of the other recipients or she is
unable to understand this non-standard message, while having no problems
with interpreting standard responses?
You're missing the fact that the actual server error is often only a small part
of the error report the user sees. The SMTP server that produced the error has
no control whatsoever over how this stuff is displayed and you're making all
sorts of assumptions about how things are displayed that simply are not true in
practice.
You're also depending on the ability of the user to actually read the error
message and understand it. What happens if the user does not understand the
language the error message is written in? One of the goals of the DSN design is
to allow for localization of error messages, either by generating the DSN in
the language appropriate for the user or perhaps by having the client discard
the first part of a standard DSN and replace it with text generated from the
second machine readable part. But that implies that the semantics of the error
have to be provided by the error code and the context in which the error
appeared - you cannot count on the text part of the message communicating
anything whatsoever.
The problem is with mailing list software, which will be unable to
automatically unsubscribe faulty addresses.
That's another problem, but it is far from the only, or even the most major,
flaw in your proposal.
LSoft has solved it in
listserv using 'passive probing" (see the second half titled "passive
probes" in http://www.lsoft.com/news/techtipLSV-issue1-2006-us.asp ).
The mailing lists are therefore not such a big problem.
Wrong again, I'm afraid. This might be the case if what you were generating is
false negatives, that is, effectively saying that such and such an error is
valid when it is not. Periodic probing (which has been around for several
decades at least) is a reasonable way to get rid of addresses you cannot
otherwise figure out are bad.
But probes aren't much of a defense against false positives. A significant
number of list managers that receive an authoritative indication that an entire
group of addresses they just tried to send to are bad are going to unsubscribe
them all right away rather than wait for a later probe to confirm that the
addresses are bogus. And this even ignores the very real possibility that
server responses can be influenced by the number of recipients. And you cannot
count on the fact that this was a response to a message body rather than to an
individual recipient being a factor in the list manager's decision. In fact in
many cases this distinction will not be visible to the list manager, which may
be extracting this information from a DSN.
Imagine all
mails for me(_at_)forward(_dot_)example(_dot_)int are redirected to
me(_at_)example(_dot_)com .
Already now when me(_at_)forward(_dot_)example(_dot_)int is subscribed to one
mailing
list, and the mailbox me(_at_)example(_dot_)com disappears traceless, the mail
server gets the message, that mails for me(_at_)example(_dot_)com cannot be
delivered. But me(_at_)example(_dot_)com is not subscribed to the list. So now
what? (more detailed at
http://mail.aegee.org/lists/listowners-life.html#suspicious-subscribers
). It is the same as receiving "550 Mail for mailing-list(_at_)example(_dot_)org
rejected".
I fail to see how any of this is relevant to the matter at hand.
Is it possible to include in 2821bis, that software implementing it has
to support the PRDR extension?
Absolutely not. That would be a major addition of functionality and as such a
violation of process rules for 2821bis advancement. Heck, PRDR is just an
individual draft at this point, and even worse it appears to be one without a
significant amount of community support. (I personally think PRDR is a very
good idea but my personal opinion of it doesn't change my assessment that the
community has showed limited interest.) It would have to be at least published
proposed standard before we could even consider adopting it as part of a
future revision of 2821bis.
This will be additional motivation for
all programmers to implement it. 2821bis compliant sounds much better
than PRDR compliant and I suppose the programmers shall want to be
2821bis compliant.
Let me rephrase my previous question:
Does anybody see any _negative_concequences_ (was 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 _de_facto_ implies, that the mail was accepted by all but
mailing-list(_at_)example(_dot_)org?
It does not imply that. See above for why and why IMO this proposal is a total
nonstarter.
If you want to proceed constructively I suggest you talk with Eric about
getting PRDR moving again. I for one will happily support that, although the
most optimistic course I can see forward for it would result in it only having
some impact several years from now.
Ned