[Top] [All Lists]

Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR

2019-02-08 10:56:40
Hello Paul,

I am suggesting to tell the sender that the message for a recipient is 
temporary rejected, why delivering the message.

Why would an mta-client change the message-id of an email having several 
recipients on each retry?

Consider this example, I wrote to a friend an email stating “Tomorrow is my 
last day in this neighbourhood, I would enjoy meeting you once again before my 
departure”.  This email had empty Subject: and two weeks later the recipient 
told me, that she read only now the email, because it was delivered in the Spam 
folder (quarantined).  In this example, the software/AI/ML decided that there 
will be no meeting.  The real term is “false positive”.

To avoid side effects of false positives, somebody has to be involved in 
manually dealing with them.  You have to involve the recipient, the sender or 
special staff.

Obliging the recipient to deal with false positives, leads to a cancelled 
meeting in the example here and it “is nobody’s fault”.  Besides, when the 
recipient address is an alias for a mailbox on another provider, there is no 
way the aliasing server can communicate to the recipient the suspicious state.

Having special staff to deal with false positives is not an option in my case.

So the senders must be concerned with false positives, by hard rejecting the 
email, what I proposed.

There is no ideal way to go.  If the options are:
- good delivery for a server with a lot of aliases to other service providers, 
by ensuring good IP-repitation (implies no-bounces policy),
- no cancelled meetings or alike, because the software decided to speed down 
the communication flow by quarantining a message (false positives),
- mail delivery with unnecessary delays

you have to choose your priorities. Any choice has drawbacks. Arranging 
software towards avoiding the impacts of false positives (meetings, which do 
not happen) is justified.

Corollary: avoiding quarantines at any price, e.g. by rejecting emails with 
p=quarantine, when DMARC fails, can be justified depending on the priorities.


On February 8, 2019 10:37:56 AM GMT+01:00, Paul Smith 
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
On 07/02/2019 22:20, Dilyan Palauzov wrote:
Strictly speaking the delivery for all recipients does not have to be
delayed.  The server can deliver promptly the messages to all deserving
recipients, memorize the Message-Id and the per recipient response, and
in subsequent transactions communicate the status per recipient.

So, you're suggesting delivering the message to the recipient, even 
though you've said it's been rejected?

That's not standards compliant... You don't KNOW that the sender is 
going to retry it, and if it does, you don't know if it'll use the same

Message-Id, so the recipient may receive a message that the sender 
thinks they didn't, or they may receive multiple duplicates, or 
something else. You can't deliver it until/unless you say you'll
deliver it.

The problems with the idea of 4xx rejecting recipients with different 
rules are that you really don't know what the sender is going to do,
are essentially removing the ability to send mail to multiple
at once, and you are adding load everywhere - a message sent to 100 
people at the same domain potentially has to be sent 100 times rather 
than just once (even if all recipients will accept it), and there have 
to be 5050 recipient checks rather than just 100, etc.

Is it that big a deal? If the recipient doesn't want the message, just 
accept it and quarantine it... That'll may even cut down on support 
calls - when a message is sent 'To: bob(_at_)example(_dot_)com, 

and Kate receives the message, but Bob, who is sitting next to her, 
doesn't and has no idea why because you PRDR rejected it because of a 
rule that Bob turned on and didn't understand. (Or doesn't receive it 
until a few hours later (if at all, if the sender times-out), because
HASN'T got a *relevant* rule enabled, but does have some irrelevant 
slightly different setting from Kate).

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>