I couldn't find any information about max no of "rcpt to" commands
allowed in a single smtp session in rfc2821.
See Section 22.214.171.124. It says:
The minimum total number of recipients that must be buffered is 100
recipients. Rejection of messages (for excessive recipients) with fewer
than 100 RCPT commands is a violation of this specification. The general
principle that relaying SMTP servers MUST NOT, and delivery SMTP
servers SHOULD NOT, perform validation tests on message headers suggests
that rejecting a message based on the total number of recipients
shown in header fields is to be discouraged. A server which imposes a
limit on the number of recipients MUST behave in an orderly fashion,
such as to reject additional addresses over its limit rather than
silently discarding addresses previously accepted. A client that needs
to deliver a message containing over 100 RCPT commands SHOULD be
prepared to transmit in 100-recipient "chunks" if the server declines to
accept more than 100 recipients in a single message.
The wording is quite different but the limit value hasn't changed from RFC 821.
It looks like there is no limit defined for it.
Nope. See above.
I don't wanna let any spammer to send
hundereds of mails in a single smtp session.
Actually, you may want them to do this since it is possible to detect such
traffic and act on it in various ways. But if you block it outright spammers
will simply accomodate your policy and in the process they may make the spam
they send harder to detect.
So , what is the resonable
max number of "rcpt to" commands for a single smtp session?
You may not want to limit the number at all. However, if you must limit it you
can put the limit no lower than 100 without violating the standard. And of
course a limit of 100 isn't much of a limit.
The bottom line is that hard limits on the number of recipients are not in and
of themselves an effective means of controlling spam and you should not be
pursuing them as such a solution.