[Top] [All Lists]

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

2019-02-06 09:23:32

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 database.

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 Greylisting.


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 accordingly.


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