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

Hi

The draft spec as written does not restrict multiple triplets designs.

If the Greylist server issues different retry hint times for RCPT TOaddress, then it should can be presumed it is designed to recorddifferent triplets, and with such a Greylist server, it is assumingclients are prepared to behave properly, as expected, to reschedulethe delivery to different people based on the 4yz reply code.

However, the question is are they prepared to handle different replyhints "reply=" to reschedule at different times?

Note there is a complexity and uniqueness for SMTP outbound systems,the queuing, the loading, the scheduling logics, etc. This is why theother commentators indicated only the server response "reply=" hintwere added, but not the client side. Its "easier" to set serverresponses. Client side adoption means code changes to advanced queuinglogics.


Anyway, I think I can update the draft to add protocol notes that say:

    GreyListing Servers MAY issue multiple and different reply hints per
    RCPT TO in a transaction.

    Compliant Clients SHOULD be prepared to reschedule retries using
    different reply hint times per transaction when issuing multiple
    RCPT TO addresses.

I can add your example as well. A reply hint of zero basically tellsthe client, they can perform a normal reschedule.


Thanks

On 2/6/2019 4:47 PM, Дилян Палаузов wrote:

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


--
HLS


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp