Re: [ietf-smtp] Per-Recipient Data Responses
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
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
ietf-smtp mailing list