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

The longer you hold up the response to receiving the data content, the
more likely you are that some connection level event will occur,
causing a re-send of the message.

So, if you can take up to 30s to do proper spam checking of a message,
how many dups are you willing to put up with?

Also, if you don't let some of the spam in, its much harder for the
system to get false positives marked as not spam and learn.

Certainly, some spam systems do a better job of delineating between
"very very spammy" and not, but that isn't always obvious.

And I think spammers would figure out pretty quickly if they got
different behavior between spamming a single address and multiple.

And I'm really not a fan of the accept but say we didn't 'yet' method,
that sounds pretty awful.

We certainly reject a good percentage of spam at smtp time, but
rejecting all spam at smtp time isn't really possible.  We are guilty
on the mailing list permission backscatter though, as with anything,
its possible to fix it, just hasn't reason high enough on the
priority.

Brandon

On Mon, Mar 10, 2014 at 12:53 PM, Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org> wrote:

Hello,

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
  Dilyan


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp