On Tue, 6 May 1997, Lyle Scully wrote:
> In trying to set up "recipients_max" under 1.61 I got two different methods
> of how it handled a message that had more than the allowed #. From a POPd
> standpoint it wouldn't even take the message (log file said something along
> the lines of "connection unexpectedly lost"). Which from a anti-spam
> standpoint I didn't mind. But when I tried it from the commandline of
> another machine it sent me back a message stating that I was over the
> allowed recipient limit.
Exim behaves differently, depending on how the message is submitted. If
the message is coming in via SMTP, it accepts recipients up to the
maximum, and then gives a 421 error for the remaining ones. As that is a
temporary error, the remote machine is liable to try again later for the
remaining recipients, as you remarked.
If the message is coming in from the command line, Exim refuses to
accept it altogether. There shouldn't be any difference between 1.61 and
1.62 in these behaviours.
I didn't really think of using recipients_max as an anti-spam device,
more as a way of limiting the processing for a particular message.
Perhaps I should implement an option to make exceeding recipients_max a
hard error for SMTP input for all recipients after the maximum have been
received. However, I don't think it is likely to be much of a spam
deterrent; the perpretrators will just send a zillion separate messages
instead.
What do people on the list think? Should it be a hard or soft error by
default, and should there be an option for changing the default?
Implementation is trivial.
Philip
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
