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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp