Subject: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3

From: Дилян Палаузов <[email-masked]>
Date: Mon, 11 Feb 2019 08:15:07 +0000

Hello,

RFC3463 Enhanced Mail System Status Codes defines in 3.6 Mail Delivery Protocol Status:

  X.5.3   Too many recipients

     More recipients were specified for the message than could have
     been delivered by the protocol.  This error should normally
     result in the segmentation of the message into two, the
     remainder of the recipients to be delivered on a subsequent
     delivery attempt.  It is included in this list in the event
     that such segmentation is not possible.

RFC5321 Simple Mail Transfer Protocol says:

4.2.3.  Reply Codes in Numeric Order

  452  Requested action not taken: insufficient system storage

4.5.3.1.8.  Recipients Buffer

   The minimum total number of recipients that MUST be buffered is 100
   recipients.  Rejection of messages (for excessive recipients) with
   fewer than 100 RCPT commands is a violation of this specification.
   The general principle that relaying SMTP server MUST NOT, and
   delivery SMTP servers SHOULD NOT, perform validation tests on message
   header fields suggests that messages SHOULD NOT be rejected based on
   the total number of recipients shown in header fields.  A server that
   imposes a limit on the number of recipients MUST behave in an orderly
   fashion, such as rejecting additional addresses over its limit rather
   than silently discarding addresses previously accepted.  A client
   that needs to deliver a message containing over 100 RCPT commands
   SHOULD be prepared to transmit in 100-recipient "chunks" if the
   server declines to accept more than 100 recipients in a single
   message.

4.5.3.1.9.  Treatment When Limits Exceeded

  452 Too many recipients (see below)

4.5.4.  Retry Strategies
4.5.4.1.  Sending Strategy

  contains: … the retry interval SHOULD be at least 30 minutes…
  and says nothing about 452 or 4.5.3

Is the number 100 randomly choosen?  Obviously, a site can accept 120 RCPTs per iteration, and for the 121st RCPT reply
with “452 4.5.3 Retry immediately after DATA”.

Are clients supposed to retry immediately after receiving 452 4.5.3?

What is the difference between „452” and „451 4.5.3”?  
https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml says 4.5.3 can be combined
only with 451.

Does „452 Requested action not taken: insufficient system storage” mean in 30 minutes there might be more storage, as
opposed to 4.5.3?

What will happen, if a site has one (1) as a minimum total number of recipients that are buffered?

What is the sending strategy after the total number of recipient per MAIL FROM:<..>... DATA . is exceeded?

How are 452 and 451 4.5.3 supposed to be different than the retry=0 hint?

Regards
  Дилян

---

From: Paul Smith <[email-masked]>
Date: Mon, 11 Feb 2019 09:07:23 +0000

On 11/02/2019 08:15, Дилян Палаузов wrote:
> Is the number 100 randomly choosen?

Yes, I believe so (just like maximum line lengths, etc). It's more a 
"physical limitation of the server" response than a policy limitation. 
(In my experience, policy limitations on numbers of recipients per 
message tend to return 5xx responses, rather than 4xx ones).

So, just like the 1024 character line limit is rarely required nowadays, 
also a 100 recipient/message limit is going to be rarely needed - 
servers can handle a lot more than that, and unnecessarily requiring a 
retry to deliver to more recipients is just adding server/client load 
for no benefit.

> Are clients supposed to retry immediately after receiving 452 4.5.3?

No, they're just supposed to retry sometime later.

In fact, you're breaking a 'MUST' in RFC 5321, Paragraph 4.5.4.1 if you 
do retry immediately - you "MUST delay retrying a particular destination 
after one attempt has failed". OK, it doesn't say you can't just delay 
for 0.5 seconds, but a delay of some sort is definitely indicated, and 
SHOULD be at least 30 minutes (although most will try sooner than that 
for the first retry)

Note that extended SMTP reply codes are an option, not a part of the 
SMTP standard itself. There is absolutely no requirement for the sender 
to read anything beyond the first '4' digit of the base response code.

> What will happen, if a site has one (1) as a minimum total number of recipients that are buffered?

It could take a very long time (possibly never) for a message to a large 
number of recipients to be delivered.

The problem with all these discussions is that the receiver server has 
no idea how the sender server will react. Retry strategies are not 
mandated by the SMTP standard. All that is required is that after a 4xx 
response the sender SHOULD try again at some later time, and on a 5xx 
response the sender MUST NOT try the same message again. (RFC 5321, 
4.5.4.1, first 2 paragraphs are the required ones ).

That is *ALL* that the receiver can rely on. That's why a lot of the 
onus on delivery is down to the receiver.

If the receiver wants users to receive messages in a timely fashion, 
they should not issue 4xx responses arbitrarily - if they CANNOT accept 
the message because the disk is full, that's fine, but if they can 
accept the message, they should do so - if they want the recipients to 
have a chance to get the message quickly.

If the sender gets a 4xx response (the digits after the first '4' may 
not be read, and extended reply codes may not be read at all), then it 
will retry at some point - the first retry will possibly be within 10 
minutes, probably within an hour, almost definitely within a day. It MAY 
send a 'message delayed' message to the sender at some point, but it may 
not.

If a message is repeatedly 4xx'd then the retry time may increase on 
subsequent retries, so, if you only accept a single message, and 4xx all 
the others, and there are only 10 recipients, the recipients may well 
get the message at these times:

 1. 10:00
 2. 10:05
 3. 10:10
 4. 10:40
 5. 11:40
 6. 12:40
 7. 16:40
 8. 20:40
 9. 00:40
10. 04:40

That would be perfectly acceptable by the SMTP standards. (If there were 
100 recipients, it's probable that the last 80 or so would never receive 
the message, because it's timed out before being sent).

Any optional drafts/standards that are written won't magically affect 
how all mail servers work. Their developers have to weigh up the cost in 
time & complexity vs any benefits gained to implement any optional 
features (and then users have to decide it's worth their while to 
install the updated versions and learn about/enable/configure the new 
features)

-- 

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

---

From: Richard Clayton <[email-masked]>
Date: Mon, 11 Feb 2019 12:13:49 +0000

In message <[email-masked]>, Paul Smith
<[email-masked]> writes

>    So, just like the 1024 character line limit is rarely required 
>    nowadays, also a 100 recipient/message limit is going to be rarely 
>    needed - servers can handle a lot more than that, and unnecessarily 
>    requiring a retry to deliver to more recipients is just adding 
>    server/client load for no benefit.

Servers often impose 100 recipient/message limits in order to discourage
less sophisticated spammers from misbehaving at scale. You would be
unwise to build a sending platform that expected to be able to send
email with more than 100 recipients per destination

viz: "rarely required" may be true from the point of view of how much
RAM a server has, but there are many more considerations

>    The problem with all these discussions is that the receiver server 
>    has no idea how the sender server will react.

absolutely ...  "deliverability" is about a great deal more than what
the standards say  -- and how recipient servers react is often
predicated on the (perceived) identity of the sender

>    Any optional drafts/standards that are written won't magically 
>    affect how all mail servers work. Their developers have to weigh up 
>    the cost in time & complexity vs any benefits gained to implement 
>    any optional features (and then users have to decide it's worth 
>    their while to install the updated versions and learn 
>    about/enable/configure the new features)

there is also an argument to be made against making the protocol more
complex without an absolutely compelling use case for adding more
features ... even if the decision is to ignore an optional feature
everyone who does any implementation needs to (a) do even more reading
to assess whether they will implement it and (b) write even more code to
conditionally handle the cases when the system they are talking to does
or does not handle the option. This is expensive.

At this point in SMTP's history we should be deprecating features that
are not being used at scale, rather than inventing new ones

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Feb 2019 11:09:47 -0500

On 2/11/2019 3:15 AM, Дилян Палаузов wrote:
>
> Is the number 100 randomly choosen?  Obviously, a site can accept
>120 RCPTs per iteration, and for the 121st RCPT reply

Keep in mind any limits and restrictions, like others, are generally 
for the unauthenticated client/server session.

If the client is authenticated and/or authorized, limits can be 
changed and/or removed.  The key difference between a MTA, MDA and MSA 
is whether they are authorized and/or allowed to relay mail. 
Otherwise, its the same receiver software just behaving differently 
based in the client's status.

For example, a Mail List Server (MLS) starting a distribution to 500 
people, connects to a local host IP or LAN IP where the SMTP 
receiver/server running on the same machine or on the same subnet, or 
it could even be a Smart Host were there is an negotiated 
contract/authorization, in these cases, the limits can change or be 
removed.

> Are clients supposed to retry immediately after receiving 452 4.5.3?

Focus on 4yz, not the specific code and extended code.  That is not 
the say, you can "train" (program) your client to factor in these 
extra extended details.

For SMTP servers, it depends on few factors.  For our server, if there 
are Multiple IPs based on MX record expansion, it may immediately try 
the next IP and only after all the IPs are tried, that may or may not 
be counted as 1 attempt.   In general, SMTP recommends a variable 
retry table and I remember using early simple algorithms of once per 
hour for 4-5 days.   That was enhanced to using variable retry tables. 
  Here is our default variable retry time based on # of attempts:

# Default retry schedule.
[Attempts]
Default=60
Attempt1=1
Attempt2=4
Attempt3=15
Attempt5=30
Attempt10=120
Attempt21=5
Attempt22=5
Attempt23=15
Attempt25=30
Attempt30=120
Attempt40=60`
Attempt72=60

We also have tables based on the socket errors where the retries 
varies and could be more limited or extended in total attempts.  So if 
the client is having trouble connecting to a server, the retries times 
can change.  How long do you continue trying a BAD IP address?  It 
might be bad only for a day or so until the receiver's DNS records is 
corrected or has propagated thru the network.  Here is my retry table 
for Socket Error 10065

#---------------------------------------------------------------
# ERROR CONNECTION TO IP ADDRESS.  This is a BAD IP address. The
# host record may exist, but the IP connects to no where.
#---------------------------------------------------------------
[Attempts:10065]
Default=60
Attempt1=1
Attempt2=10
Attempt3=20
Attempt5=30
Attempt6=60
Attempt50=0

So after the 6th attempt, it is once per hour and after about 2 days, 
Attempt50, it is exhausted and a bounce is created.    The main point 
here, is that this is a very complex side of SMTP and its 
implementation specific.

However, due to the advent of greylisting and the SMTP-GREY draft, the 
2nd attempt is recommended to be shorten with the hope of minimizing 
delays and this is where the "retry=" comes into play.

> https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml says 4.5.3 can be combined

Please note that extended reply codes are optional. Your client/server 
MUST focus on the main xyz reply codes. In general, the extended codes 
and the response strings are more for humans, help desk, etc, but that 
is not to say, the client software can not programmed to use the 
extended information.

> Does „452 Requested action not taken: insufficient system storage” mean in 30 minutes there might be more storage, as

You can't jump to conclusions like this.  All you can do is use the 
4yz to reschedule a retry and it comes with a  "reply=" hint, possibly 
factor that into your retry.  Again, you can program your client to 
see a 4.5.3 extended code and add logic that might maybe change the 
retry time to perhaps 30 minutes or maybe 5 hours.  With no hint, you 
don't know.

> What will happen, if a site has one (1) as a minimum total number of recipients that are buffered?

Probably nothing.  The server is not playing by the rules allowing 100 
per the SMTP recommendation, but the client should not break as well. 
  The client has to be aware of its distribution, the 2yz, 4yz and 5yz 
it reads for RCPT TO commands.

Side note.  Our MLS has two modes for distribution, UUCP or SMTP. 
UUCP predated SMTP and in this mode, the distribution created 1 set of 
*.DAT/CMD/XQT files per recipient.   Prior to SMTP, these files were 
then copied or picked up by hosted domains.  When SMTP was added, the 
MLS can now go direct and use multiple RCPT TO commands in a SMTP 
session or the MLS can be set to use the UUCP export format and in 
this case, a mail router eyeballing the export folder will pick them 
up and hand them over to the MTA who begin sending them out one by one.

> What is the sending strategy after the total number of recipient per MAIL FROM:<..>... DATA . is exceeded?

Break it up.   You are talking about how software outbound strategies 
are designed and implemented. Rest assured it is not all the same, 
like the UUCP mode described above.

> How are 452 and 451 4.5.3 supposed to be different than the retry=0 hint?

As far as SMTP-GREY draft is concern, a retry=time-delay value of zero 
is undefined. A zero value goes against the point of Greylisting where 
a block delay was determined to be necessary. See section 2.5. 
Recommended Blocking Times.

https://tools.ietf.org/html/draft-santos-smtpgrey-02#section-2.5

However, problematically, a server issuing a "retry=00:00:00" hint 
would translate to a no block time delay and the client can try again 
when it decides to try again.

-- 
HLS

---

From: Paul Smith <[email-masked]>
Date: Mon, 11 Feb 2019 16:39:26 +0000

> when it decides to try again.
The key point is that a server issuing ANY 'retry=' means that the 
client can try again when it decides to try again. That is even if the 
client understands the 'retry=' hints. It's a *hint*.

The client may look at "retry=00:05:00" and say "that's too short, I'll 
try again in 20 minutes, or at "retry=04:00:00" and say "that's too 
long, I'll try again in 1 hour".

The client is what determines when it will retry. Basing any scheme 
around the server being able to control that is doomed to failure.

Using the hints for greylisting isn't going to be problematic because 
greylisting is usually solved by a single retry in the correct 
timeframe. Subverting them for other purposes (which may involve 
multiple retries, even after the specified delays) may give unintended 
results.

If you're on your 20th retry and the server is STILL saying 
'retry=00:00:01', for the 20th time, then it wouldn't be unreasonable 
for the client to say 'stuff that, I'll leave it a few hours and then 
try it again'.

--

---

From: Russ Allbery <[email-masked]>
Date: Mon, 11 Feb 2019 09:08:16 -0800

> email with more than 100 recipients per destination

I ran into my favorite version of that problem somewhere around 2010.  The
antivirus software we were using at the time (I think Sophos, although
don't quote me on that) decided that it should inspect all outgoing SMTP
network transactions to look for viruses.  Not a completely unreasonable
thing to do.  However, the SMTP code had a bug or misfeature such that if
the message was going to more than (IIRC) 50 recipients, it would just
silently eat the message.

Not return an error, not indicate any sort of failure, just silently
/dev/null the message.

Given that the message that people were trying to send was the acceptance
and rejection messages to prospective college kids, this caused quite a
lot of consternation and emergency attempts to debug the campus mail
servers until we figured out it was the antivirus.

-- 
Russ Allbery ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Feb 2019 12:35:31 -0500

On 2/11/2019 11:39 AM, Paul Smith wrote:
>> would translate to a no block time delay and the client can try
>> again when it decides to try again.
>>
> The client may look at "retry=00:05:00" and say "that's too short,
> I'll try again in 20 minutes, or at "retry=04:00:00" and say "that's
> too long, I'll try again in 1 hour".
>

Of course, yes, the server is only providing a hint for a minimum 
retry time. It is saying it is not a good idea to try again before the 
block time has expired, otherwise it will be a wasted failed attempt 
further delaying delivery.

    Since there is no clear recommendation for a blocking time delay
    (other than to keep it short as possible), this specification offers
    the "retry=time-delay" hint as a method to alleviate the uncertainty
    in the wasted attempts and delays in timely mail delivery.

So we are in agreement here.

But I am not sure why a "retry=0" was suggested.  Is Dilyan suggesting 
that client should try immediately when it sees an explicit 
"retry=time-value" with a time-value of zero?

My only point is that a SMTP-GREY does not define an explicit 
time-value of zero.  But software wise with existing code, I don't see 
any other interpretation other than basic fall thru logic of keeping 
with the client's normal retry schedule, and not to be interpreted as 
retry immediately, don't wait.

In our code, the normal logic is to get the next retry time (in secs) 
from the retry tables as a function of # of attempts thus far and also 
socket error, if any.  If the response string has a reply hint (value 
is greater than zero), this hint time is used to replace the next time 
already.

The logic is like this:

     // logic fo 4yz response string.
     nSecs = GetNextAttemptSecs(nAttempts, nLastError);
     if (nSecs == 0) return CREATE_BOUNCE;
     nHintSecs = ExtractRetryHint(sResponseString);
     if (nHintSecs > 0) nSecs = nHintSecs

nSecs is then used to calculate the next attempt time based on the 
last attempt time.

I don't think I like the idea of using an explicit time-value of zero 
as way to try to drive a client to retry immediately.  As you said, 
the client will decide anyway.  Plus, now, you get into the idea of a 
Zero vs Null in the parser function and a new return value 
interpretation is required, i.e. return a negative value to mean "No 
Hint" provided.

     nHintSecs = ExtractRetryHint(sResponseString);
     if (nHintSecs > -1) nSecs = nHintSecs;

-- 
HLS

---

From: [email-masked]
Date: Mon, 11 Feb 2019 17:54:32 -0500

> are not being used at scale, rather than inventing new ones

How big a food fight would I start by asknig what are the top 3 things to heave
over the side? :)

---

From: [email-masked]
Date: Mon, 11 Feb 2019 18:02:12 -0500

> contract/authorization, in these cases, the limits can change or be 

Been there, done that.  We discovered that having our Listserv machine hand off
local deliveries to our main mail hub 2000 at a time and letting it do any
needed envelope bursting generated less load on the hub than handing it 20 mail
items for 100 each.  Made a *big* difference for postings to lists that had 40K vt.edu
addresses and 2K addresses for the rest of the planet. :)

(And yes, we only did that sort of stuff for high-traffic paths where the sysadmins
at both ends were onboard...)

---

From: "John Levine" <[email-masked]>
Date: 11 Feb 2019 23:10:20 -0500

>How big a food fight would I start by asknig what are the top 3 things to heave

Good question.

NO-SOLICITING (only invented to make a political point)
CONPERM and CONNEG (never seen them used)
ATRN (a hack to try and run an SMTP server on a dynamic address)

CHECKPOINT was an experiment 24 years ago which we can now declare complete.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 12 Feb 2019 09:32:07 +0000

On 11/02/2019 12:13, Richard Clayton wrote:> At this point in SMTP's
history we should be deprecating features that
> are not being used at scale, rather than inventing new ones

That's a false dichotomy; we can do one and still do the other.
-- 
Cheers,
  Jeremy

---

From: Paul Smith <[email-masked]>
Date: Tue, 12 Feb 2019 09:35:45 +0000

> ATRN (a hack to try and run an SMTP server on a dynamic address)

The one UK ISP which I know used to support ATRN (ODMR) stopped a couple 
of years ago.

There's a service provider called 'etrn.com' which I think still support 
it. They don't call it 'ATRN' or 'ODMR', but their 'Authenticated 
Domain' service sounds like it's that 
(https://www.etrn.com/e-mail-spooling-service.html)

Obviously, I don't know how many of their customers use it, but it may 
annoy them if that was deprecated ;-)

--

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 13 Feb 2019 12:22:09 +0000

Hello,

the answer is “You cannot change systems installed ten years ago and at the end everything is implementation specific”. 
What was the question?

492 can mean “Mailbox is full”, or “Too many recipients in this iteration” since the very beginning.

4.5.3 means only the latter and communicating “the too many recipients” can be used to limit the incoming spam or be
means to achieve other things.

What retry strategy is reasonable, when the server communicates “Too many recipients in this transaction”?

Do more MX/IP addresses for a domain suggest more frequent retries (more total amount of iterations per time unit) on
“Too many recipients in this transaction”?

Is publishing 1024 distinct IPv6 addresses for MX on a domain a good idea, in order to decrease the average delay
imposed by “Too many recipients in this transaction” temporary error?

> … So if the client is having trouble connecting to a server, the retries times can change.  How long do you continue
trying a BAD IP address?  It might be bad only for a day or so until the receiver's DNS records is corrected or has
propagated thru the network. 

See https://wiki.apache.org/spamassassin/OtherTricks → Fake MX Records, hence an MX/IP address can be bad forever.  This
shall not have impact on the retry times for the valid IP addresses.

> "retry=time-value" with a time-value of zero?

Exactly.  The answer of “Why this is needed” is for a separate discussion, lets first fix how to convince the client how
to retry immediately.

> when it decides to try again.

My reading of:
  retryhint   = "retry=" time-delay
  time-delay  = ( [days "-"] hours ":" minutes ":" seconds) / totalsecs
  totalsecs   = 6*DIGIT  ; 0-999999
is that retry=0 and retry=00:00:00 is the same.

Because retry=0 is not specified in the smtpgrey-draft, I asked here on 06 Feb 2019 21:47:58 +0000 to amend, that on
retry=0 the server shall retry after end-of-data.  There are use cases, not related to greylisting, where the server
answers with retry=0 to a set of recipients and with retry=1 to other sets of recipients, and so on.  This recipients
shall be retried in group transactions together.  That is why I propose now to add to the draft:

When a server combines a retry hint with 4.5.3 Enhanced status code, the client can reuse the TCP connection for the
retries, but repeat the RCPT after DATA end-of-data.  Different values of the retry hints suggest grouping the
recipients with the same value in a single retry transaction and repeating the iteration for each such group.

> long, I'll try again in 1 hour".

Absolutely!  Nevertheless it is still possible to write down what is reasonable and the motivation for one or other
implementation is.

> as way to try to drive a client to retry immediately.  

What is the problem with immediate retry, when we are not talking about greylistting, but about Too many recipients in
this transaction?

Greetings
  Дилян

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Feb 2019 11:54:35 -0500

> is that retry=0 and retry=00:00:00 is the same.

Format wise, that would be the same time-delay -- zero seconds.   It 
was not the intent of the original HARRIS Greylisting concept and the 
SMTP-GREY draft to drive a client to retry immediately by explicitly 
issuing a time-delay (block time, retry hint) of zero seconds.

> What is the problem with immediate retry, when we are not talking about greylistting, but about Too many recipients in this transaction?

We are talking about the concept of "greylisting" when using 4yz as a 
way to perform any form of load and/or spam controls.  Its a form of a 
throttle whether it was "too many recipients,"  "too much mail," or 
"too many connections," etc.  You are telling the client to "slow 
down," "Backoff" and "try again later."  The operative word here is 
"later."

For the unsolicited, unauthenticated mail sender, specific to the 
limit of RCPT TO field, the client is allowed 100 (per SMTP spec). The 
compliant SMTP client should know this protocol limit and the 
developer should program the SMTP outbound system around this limit 
and also be ready to handle a 4yz issued at any point in the SMTP 
session, including before the limit is reached and possibly after the 
first one.  Regardless of the 4yz reasons, the MTA needs to be ready.

Specific to SMTP-GREY, an explicit hint of zero time, is not defined, 
nor expected and would not be backward compatible with my existing 
code and possibly clients who may be reading the reply hints in the 
many forms that exist today.

Here is an idea: Why Zero?   Why not use block time of 1 sec?  Unless 
we are dealing with "Quantum Entanglement," this should work in the 
way you are looking for, no?

-- 
HLS

---

From: [email-masked]
Date: Wed, 13 Feb 2019 14:53:11 -0500

On Wed, 13 Feb 2019 12:22:09 +0000, Дилян Палаузов said:

> Is publishing 1024 distinct IPv6 addresses for MX on a domain a good idea

Only if you're *really* sure that everybody who wants to talk to you supports
at least EDNS0 and doesn't block tcp/53 :)

---

From: "John Levine" <[email-masked]>
Date: 13 Feb 2019 15:27:32 -0500

>at least EDNS0 and doesn't block tcp/53 :)

Let me simplify that answer:

No, it is not.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2019 08:11:29 +1100

Nobody that is sane blocks TCP from or to recursive servers.  Those that
argue for blocking DNS/TCP usually do so in the context of authoritative servers.
Even there it is "Gun, Foot, Shoot" territory.  There are lots of ways TCP is
used in DNS today when answering ordinary queries (not zone transfers).

* answers don’t fit -> TC=1.
* referral doesn’t fit -> TC=1.
* anti spoofing setting TC=1.
* client recovery from multiple BADCOOKIE responses.

If you have a DNSSEC signed zone you will almost certainly be getting some
TCP traffic.

Too many times I have seen authoritative servers send back TC=1 only to be
blocked by a firewall.  Friends don’t let friends block DNS queries with
firewalls.

Mark

> On 14 Feb 2019, at 6:53 am, [email-masked] wrote:
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 16 Feb 2019 14:25:00 +0000

Hello Santos,

your draft describes an existing server’s defering strategy and advices clients how to act, when this defering strategy
is in effect.  One of the essential parts of your draft is writing down the idea (formalizing) for the smtp-clients to
reuse the IP address on retrying, when grey listing is in effect.  Whether grey listing is in effect, does not depend on
a 250-GREYLIST or retry= information.

I suggest you include in the draft how a client can recognize that greylisting deferring is in effect and, based on the
outcome, decide to use or not other IP addresses for subsequent/immediate retries.

If retry=0 is (intentionaly) left undefined, then the draft shall state this, and probably suggest what clients shall do
on retry=0.  (E.g. ignore).  Keeping retry=0 this way, because anything else is not backward compatible with
implementations of a draft, does not necessary mean that there is a consensus.

Your draft states:
   If a SMTP server offers a "retry=time-delay" hint which results in a
   wasted 2nd attempt and requires additional attempts, the SMTP client
   MAY begin to ignore the server's "retry=time-delay" hint after the
   2nd wasted retry.  The SMTP client implementation can decide what
   limits to place on honoring "retry=time-delay" hints and wasted
   attempts it provides.

I suggested previously, and this was not tackled, that a retry is not wasted, if the remaining number of recipients has
decreased during the retry.

Regards
  Дилян

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Feb 2019 12:33:23 -0500

Dilyan,

The SMTP-GREY extension fits with RFC5321, Section 4.5.4 "Retry 
Strategies."

    https://tools.ietf.org/html/rfc5321#section-4.5.4

Note the section 4.5.4.1 sending strategy MUST requirement for a delay 
and added considerations for more advanced strategies that can shorten 
the 30 minutes SHOULD:

    The sender MUST delay retrying a particular destination after one
    attempt has failed.  In general, the retry interval SHOULD be at
    least 30 minutes; however, more sophisticated and variable strategies
    will be beneficial when the SMTP client can determine the reason for
    non-delivery.

That is what the SMTP-GREY "retry hint" was intended to do, not get 
into a more complex client/server negotiated retry system where all 
sorts of factors are considered.  The compliant SMTP client MUST delay 
the retry and the extension fits with the extended "sophisticated and 
variable strategies" consideration described above to adjust the retry 
interval.

Beyond this, IMO, it would be a different document like a BCP or 
Information status, perhaps titled:

         "SMTP Outbound Mail Optimization Strategies"

that will serve bulk mail senders in today's environment. It would 
apply in general for remote servers who have deployed greylisting 
methods for load and/or spam controls.

As far as SMTP-GREY, maybe a (draft) clarification for the time-value 
can be appended to section 2.5 "Recommended Blocking Times:"

    .....

    Using a time-value of zero for the reply hint may be used by
    the Greylisting Server in an attempt to convey to the compliant
    SMTP client, the server has no blocking time and the client may
    retry without delay or follow its normal retry schedule.

    Since a non-compliant SMTP client will always follow a normal
    retry schedule, it is recommended the Greylisting Server who wishes
    to reject the first attempt with little to no blocking time for the
    2nd attempt to consider using a retry hint of one second for backward
    compatibility reasons. Using one second should effectively produce 
the
    same almost immediate retry the Greylisting server maybe looking for,
    while using zero seconds may not produce the desired effect of an 
immediate
    client retry and cause an undesired delay, i.e. the client could 
default to
    30 minutes as suggested by RFC531.

Thanks

-- 
HLS