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
transaction.
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 serverdomain.com with servdom.example.com
add:
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: a.example.com, welcome ESMTP v2.0
C: EHLO mail.example.org
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.
retry=00:00:00
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.
retry=00:00:00
C: RCPT TO:<five(_at_)example(_dot_)com>
S: 451 This recipient has a different mail rejecton policy than the first one.
retry=00:00:01
C: QUIT
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.
Regards
Дилян
On Wed, 2019-02-06 at 10:23 -0500, Hector Santos wrote:
Hi,
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.
Thanks
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.
Regards
Дилян
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?
https://tools.ietf.org/html/draft-santos-smtpgrey-02
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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp