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
> 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?
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". What does the
user think now? 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?
The problem is with mailing list software, which will be unable to
automatically unsubscribe faulty addresses. 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. 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
). It is the same as receiving "550 Mail for mailing-list(_at_)example(_dot_)org
>> How many envelopes I receive do have more than one recipient? Well,
>> except the spam almost nothing. But imagine a mailing list that
>> has 1000 subscribers. 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).
> If you are greylisting, in my opinion, it needs to be for the ENTIRE
> transaction, not just individuals. I doubt it will work right and again
> your end can do what it wants, but you won't be able to change the
> SENDER behavior who is designed to work with a standard expected
> behavior. If you send a 45x at the DATA, then the entire transaction
> MAY be tried again. A 55x will not be tried again - period.
Giving temporary reject to a user is the same as applying greylisting
for that user. I do not want to apply greylisting at all, however when
one suggests to accept all but the first recipient and reject temporary
the others, he means that applying (a kind of) greylisting is the way to
make per recipient responses. Up to now it was just not labelled
Is it possible to include in 2821bis, that software implementing it has
to support the PRDR extension? 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
Let me rephrase my previous question:
Does anybody see any _negative_concequences_ (was disadvantages) of
ending the session
250 OK server.example.org
That is all.
550 Mail rejected by mailing-list(_at_)example(_dot_)org
which _de_facto_ implies, that the mail was accepted by all but