Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR
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:
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