|
Re: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3
2019-02-11 10:10:16
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
with “452 4.5.3 Retry immediately after DATA”.
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.
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.
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
opposed to 4.5.3?
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
|
|