[Top] [All Lists]

Re: acceptings partically a message (3)

2007-07-17 13:09:43

Hi Dilyan,
At 10:22 17-07-2007, Dilyan Palauzov wrote:
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 > 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?

Some MTAs still send DSNs to the recipients to inform them that their email could not be delivered. For example, if this email is not accepted by the mail server that operates this mailing list, I will get a DSN from my mail server.

Quoting Section 6.1 of RFC 2821:

   "When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility

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 normal user may see the mail (DSN) as incomprehensible. There is no guarantee that the reject message will be relayed to the sending user. People actually expect email to work (mail delivered to intended recipient). The expectations wans as they gain first hand experience of the side-effects of antispam measures.

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 ). 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 rejected".

You can use VERP and track down which subscription is bouncing with it.

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.

That falls outside the scope of RFC 2821bis.

2821bis compliant sounds much better than PRDR compliant and I suppose the programmers shall want to be 2821bis compliant.

PRDR may have better traction that other extensions from sites running mail filters as they benefit from it.

Let me rephrase my previous question:

Does anybody see any _negative_concequences_ (was disadvantages) of ending the session
250 OK
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
354 OK
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 mailing-list(_at_)example(_dot_)org?

Yes, I see several:

1. That reply code applies to all recipients of the message.

2. I don't understand English

3. My MTA does not convey the actual reject message to me.

4. My MTA silently drops DSNs.