[Top] [All Lists]

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

2019-02-11 06:15:34
Hash: SHA1

In message <407238d5-03de-2c40-3015-fca482055574(_at_)pscs(_dot_)co(_dot_)uk>, 
Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> 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

Version: PGPsdk version 1.7.1


ietf-smtp mailing list