[Top] [All Lists]

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

2019-02-09 04:28:36
On 2019-02-08 17:56:15 +0100, Dilyan Palauzov wrote:
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,

I agree with this (Although bounce messages are in practice hard to
understand by normal users and therefore often ignored).

what I proposed.

But I don't think this is what you proposed. 

As I understood it, you proposed delivering a message while returning a
4xx reply to the sender. 

So the recpipient gets the message, but the sender might get a "your
message couldn't be delivered for 4 hours" notification even though it
was actually delivered. 

I think this would be very confusing.

It also doesn't help with reducing the number of delivery rounds since
the message Id isn't available at the time RCPT is received.


   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp(_at_)hjp(_dot_)at         | management tools.
__/   | | -- Ross Anderson <>

Attachment: signature.asc
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>