[Top] [All Lists]

Re: [ietf-smtp] Per-Recipient Data Responses

2014-03-10 14:53:40

about the PRDR current adoption, I see the problem not that much in the unimplemented PRDR facility on the server side, but rather in the lack of possibility to reject mail at SMTP level after DATA-fullstop, even in the simple case where the mail has only one recipient.

My personal preference is to reject the spam intended for me, and inform the sender immediately, instead of filling my spam folder, and loosing time to check in it, causing by this way huge delays until false classified ham is proceeded. I guess many other users will have the same preferences, if it frees them from the obligation to check the spam folder. This does not cause also additional support burden to postmasters, as the work to clarify why a mail is rejected because it was being evaluated as spam, is the same compared to the work explaining why the email ended in the spam folder.

For me a step in the adoption of PRDR is to ask, if the concrete user prefers spam mails to go in the spam folder or to be rejected on SMTP level. There are also some variations possible, like emails which are very, very, very likely spam to be rejected at SMTP level, if the mail envelope has only one recipient, otherwise delivered to the spam or inbox folders.

Spam is not the only reason to reject mails after DATA-fullstop. Another issue are emails sent to mailing lists, where the rejection can be concluded only after evaluating From:, Resent-From:, Sender: and Resent-Sender: headers. If the mailing list preference is to reject mails from non subscribers, and some entitled sender chooses by error the wrong sender address, then this email will probably have only one recipient on the envelope, and the mail can be rejected at SMTP level.

Asking why PRDR is not adopted and asking why in the above single-recipient-scenario emails are not rejected as SMTP level after DATA-fullstop, is essentially the same.

It is not the problem of the PRDR draft, it is not the problem with the lack of its current adoption, it is the design of the SMTP servers, that cannot decide during SMTP reception after DATA-fullstop, if the recipient wants the email or not, regardless of the possibility to reject it (e.g. when there is only one recipient).

I guess for most software it would be trivial to implement the client-part (interpret the response after DATA-fullstop-353); and currently the sole reason for the limited use of PRDR is the amount of work to make the SMTP-server part of the MTA able to decide at SMTP level, if the recipient wants the message.

If this logic was already in the servers, they could accept only the first recipient from the mail envelope and send temporary rejection to all the others. But on the same time deliver the email promptly to all recipients, that want the email. In this case the sender might get a message, that the email is not delivered yet (after four hours), however the email will be in the mailboxes of the recipients at that time. Under this circumstances only the case has to be dealt with, when the recipients have promptly received the emails, but the sender gets the wrong message, that her/his message was not delivered yet.

Depending how the temporary rejection is done, there might be no administrative burden with such messages. Some 451-text like this shall reduce the questions: The sending server does not implement the PRDR-SMTP extension, that's why it is not possible to tell the sending MTA immediately, if all recipients have already received the message. The recipients that wanted to receive the message, have already received it. It takes some time to tell the sending MTA, which recipients have rejected the message, hence the current notification.

Going a step further, a new enhanced status code can be added to draft-hall-prdr-00.txt, that is returned when the temporary reject is done, because the sending client does not ask for PRDR. On the server side it shall be also not that difficult to track, if a message is delivered for the second time (once when the mail was rejected temporary, and once, when the sender retries and the message is accepted), as the double delivery suppression functionality shall already be there.

As for Sendmail and Postfix, this could be done by milters, which evaluate Sieve scripts and enforce SMTP reject. More generally, this can be achieved by tweaking the milter interface to support per recipient logic/data/callbacks. I think this is what the pmilter interface of META1 does.

As for the question, about why shall a server print for every recipient a response, instead of using one reply text, if all recipients reject the message, the answer is, that the rejection text can differ per recipient.

Kind regards

ietf-smtp mailing list