On 12/16/19 8:01 AM, Tony Finch wrote:
this an area where practice appears to have diverged from the standard.
I not keen to see the limit reduced, but perhaps advice to clients to
default further below 100 than they may doing already may be warranted.
I can only speak to Postfix, which defaults to sending up to 50 and
accepting 1000.
I would like a requirement that servers must not reject the entire message
if there are up to 100 RCPTs even if the server returns 452 for some of
them. Senders can then pipeline safely.
Part of me wonders why there's a minimum number of RCPTs at all if,
practically speaking, the client has to be able to deal with a
server-imposed limit no matter where it is.
Seen in this light, the minimum requirement seems like more of a guide
for optimization by clients than a requirement for servers.
Then again, if existing clients are currently assuming 100 or some
substantial fraction thereof, I would not want to break them by telling
servers that they can now impose whatever limit they like.
I am tempted to suggest that there be a MAXRCPTS EHLO response to let
the server advertise its explicit limit. But again, this would give
license to servers to change existing limits.
Other than the rare server that really cannot store 100 recipients, is
there some operational reason to permit fewer? Did someone empirically
determine, or arbitrarily decide, that spambots would be more likely to
send 100 recipients than legitimate senders?
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp