On Wed, 7 May 1997, Lyle Scully wrote:
> So that means if a message came in and had 500 recipients, and I had the
> max set to 100, it would deliver 100 messages and deffer the remaining 400?
> Then later on does it attempt to send the next 100, and the next, etc,
> until it clears it?
Yes, that is the way it is likely to happen at the moment.
> I realize this probably isn't the best method. But if I could think of a
> better way then I would be happy to entertain it. Problem is I just had a
> client (no longer a client) that decided to send out very big messages with
> upwards of 5K recipients per message. I am looking for a method that would
> kill that type of message before my system sends it out.
I could add an option that would give a hard (rather than a soft) error
on hitting the 101st and subsequent recipients. That would still leave
the original 100 to carry on and get delivered. The trouble with SMTP is
that it accepts the recipients one by one, so you don't know how many
there are except by counting them. The only option for attempting to
reject the whole message after accepting one or more recipients is to
give a hard error to the DATA command or at the end of the data. I know
from experience that doing this doesn't always work. There are mailers
out there that treat any error at those points as a soft error, and they
keep on trying to send the message. Of course, in your case that would
at least prevent the message from being sent out.
> There are all
> these filters to help with mail when it comes in, but what about the ISP's
> that want to try to be responsible and kill it before it leaves our
> networks? On this last spam round I received 400+ complaints. If I can't
> prevent this from happening on my own network, how can I reasonably expect
> someone else to do it.
I am very sympathetic! I will certainly implement an option to give a
hard rather than a soft error on recipients "over the limit", and also
an option to give an error to the DATA command if there are too many
recipients. That's easy enough to do, and it will give you some more
flexibility.
Philip
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
