Chuq Von Rospach <[EMAIL PROTECTED]> writes:
> <http://www.imc.org/draft-ietf-drums-smtpupd> -- you are mistaken,
> sir. According to the latest draft of the standard update for RFC821, a
> limitation of less than 100 RCPT-TO is a violation of the standard. You
> must accept at least 100. If you limit beyond that, the restriction has
> to be orderly (silently deleting mail or recipients that goes over the
> limit is explicitly denied -- at one point, AOL did that. I don't know
> if they still do, but that's against the standards.
>From the standpoint of the SMTP *client*, this restriction is essentially
meaningless, since of course the server is permitted to return a 4xx code
to *any* RCPT command, and therefore the client has to handle it
gracefully anyway.
The provision of a "minimum maximum" of 100 recipients seems to me to be
for "political" reasons of some sort, perhaps just to avoid changing a
provision of RFC 821 but possibly to encourage MTA authors to handle the
multiple recipient case. Setting a lower maximum will not cause
interoperability problems (although the server may accept mail more slowly
under some conditions). I see no reason why a site shouldn't feel
comfortable with setting it lower as a matter of site policy.
(On the other hand, I don't see off-hand much purpose served in doing so.
Whatever help it may provide to slowing down outgoing spam is likely lost
in the noise, most spammer software that I've run across doesn't use
anywhere near 100 RCPTs anyway, and widespread lowering of the limit will
just cause spammers to adjust their tools. But it's possible there's some
factor that I'm missing.)
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
