[Top] [All Lists]

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

2019-02-06 15:48:43
Hello Hector,

irrespective of SMTP transaction, grey-listing and IPaddr-MAILfrom-RCPTto 
triplet, describing more use cases for your
draft will increase its usefulness and more sites will implement it.

In any case, your draft shall state, if not included already, is that on

421|451 … retry=00:00:00

after RCPT TO: the client is supposed really soon to send another MAIL FROM: 
followed by that RCPT.

Like this:

Abstract: … Retry-time=00:00:00 can be send by a server, to accept emails for 
some recipients of an email, and reject it
for others.

Introduction/new subsection:
==Accepting the email for some recipients and rejecting it for others==
In order to avoid backscatters, or mitigate the effects of false positives, a 
site can reject suspicious emails during
the SMTP dialog, depending on recipient’s preferences.  When an email to such a 
site has several recipients in the
envelope and on the mail host these recipients have different policy for 
rejecting emails, the site can accept the first
RCPT TO: for the first recipient and any other recipient, who shares the mail 
rejection policy with the first recipient.
After the DATA-DOT the email for those recipients is accepted or rejected.  For 
the other recipients, the site can
communicate to the sender, that it shall retry immediately with a new 

Amendment to section 2.3.4 RCTO TO:
For the purposes of applying different mail reject policies for the different 
recipients, a server communicates to the
client to retry immediately a new transaction with the failed recipient.  

Seciton 3 SMTP Service Keyword
I see no advantages for the 250-GREYLISTS EHLO reply, as with or without it 
nothing changes.

Section 4 Examples:

I propose replacing with


Example of a site, where the first and third recipients share the same 
rejection policy, and all other recipients share
a different mail rejection policy:

S:, welcome ESMTP v2.0
S: 250-HELP
C: MAIL FROM:<jqpublic(_at_)mail(_dot_)example(_dot_)com>
S: 250 User OK
C: RCPT TO:<one(_at_)example(_dot_)com>
S: 250 OK
C: RCPT TO:<two(_at_)example(_dot_)com>
S: 451 This recipient has a different mail rejection policy than the first one. 
C: RCPT TO:<three(_at_)example(_dot_)com>
S: 250 OK
C: RCPT TO:<four(_at_)example(_dot_)com>
S: 451 This recipient has a different mail rejecton policy than the first one. 
C: RCPT TO:<five(_at_)example(_dot_)com>
S: 451 This recipient has a different mail rejecton policy than the first one. 
S: 221 Goodbye

Note, by using a different retry for the last recipient, the server hints to 
retry two(_at_)example(_dot_)com and four(_at_)example(_dot_)com
in a new transaction, and five(_at_)example(_dot_)com in another transaction.  
The server can do so in order to signal, that 
two(_at_)example(_dot_)com and four(_at_)example(_dot_)com have a separate, 
common mail-rejection policy, while five(_at_)example(_dot_)com has again
another mail rejection policy.

Another point to consider, even if you did a … response per RCPT TO …,  I am 
not sure how clients will deal with
this.  Will they retry the 4yz responses and skip the 250 and 5yz responses?

This is what I and clients do now.


On Wed, 2019-02-06 at 10:23 -0500, Hector Santos wrote:

This draft is nothing more than an attempt to "IETF formalize" the 
functional and technical specification for an existing "technology" 
used for SMTP, and hopefully agree on the "retry hint" 4yz response 
string format to assist servers and clients in minimizing delivery 
delays.  Adding more to it was not the goal.

But how does Multiple RCPT TO fields apply in a transaction?

The typical Greylist "Triplet" are the three SMTP process parameters; 
the connecting IP, the Return Path (MAIL FROM) and the forwarding 
address (RCPT). Together, they make up the hash index to the greylist 

Offhand, I would have to see how current code works with the idea of 
multiple triplets per transaction, one for each RCPT TO received. 
For our system, the GreyList Hook, is done at the DATA level where a 
bunch of p-code filters are run in sequence.  The Greylist hook grabs 
the first RCPT TO, I believe, but one key reason to do this at the 
DATA level to allow 3rd party developers a p-code reprogramming chance 
to add the Message-ID to the "triplet" as some GreyList systems are 
known to do, maybe in place of the RCPT and the possibility of having 
multiple addresses.  I think that makes technical sense.  But there 
are greylist systems who run immediately at the RCPT TO state and 
don't have the payload to work with.

Another point to consider, even if you did a GreyList response per 
RCPT TO and recorded multiple triplets,  I am not sure how clients 
will deal with this.  Will they retry the 4yz responses and skip the 
250 and 5yz responses?

Another point to consider is that Greylisting addresses anonymous 
senders, i.e. you don't know who they are, don't have info on them, 
not white listed, etc.  So sender authorization may be a local policy 
consideration in allowing multiple RCPT TO per transaction which would 
preempt greylisting and other filters a system may have.  For example, 
in our package, if the connecting client/sender is authorized either 
by IP or ESMTP AUTH, most restrictions are removed and most 
hooks/shims filters are pretty much skipped, i.e. RBL, SPF, CBV and 


On 2/5/2019 4:03 PM, Дилян Палаузов wrote:
Hello Hector,

I have not read your proposal, but I guess its purpose is to communicate to 
the other party (smpt-client) when to retry
transmission, in order to mitigate to minimum the delays from grey listing. 
 This is great, but there is one more
application of the proposed extension, that is not called “grey listing”:

When a mail for many recipients is send and different recipients have 
different accept/reject policies, PRDR is the non-
plus-ultra.  When the SMTP parties do not agree on PRDR, the server can 
accept the email for the first recipient and all
other recipients of the mail, that have the same accept/reject policy as 
the first recipient.  All other RCPT TO:s are
told to retry later *immediately*.

This enables, to apply different accept/delay policies per email recipient 
without having PRDR and without causing
noticeble delays for any recipient.

Consider updating the “Introduction” and “Abstract” of your draft 


On Tue, 2019-02-05 at 11:11 -0500, Hector Santos wrote:
Which smtp servers and client follow or honor Greylist SMTP retry hint
for rescheduling retries?

I wrote this draft a while ago, wondering if any software beside mine,
Wildcat! SMTP, supports it?

It has been every efficient and it has helped minimized the retry
attempts for delivery of mail to 2 with the shortest period.

ietf-smtp mailing list