On Wed, 2004-04-07 at 14:25, Dave Howe wrote:
I think 10 is a bit low.
It is, although it's more of an example value than a practical one. You'd have to get some statistics on average e-mail use from your mail servers and tune the value accordingly.
I am not really an abnormal email user - but I tend to block answer a lot of emails, and send them as fast as I type them - so I can easily send 20-30 emails in the first hour, then maybe an hour slack, then another dozen or so - depending on inbound traffic and what arguments are ongoing on my mailing lists at the time.
Same here, but this pattern of e-mail burst - slack - burst etc. could be quite easily implemented in the way described, as long as you have some accurate statistics to use as baseline values and adjust the actual operational values accordingly.
Ok, I could in theory use web forums, usenet (probably also subject to your rate limiting) or whatever for this, but tbh I don't think I can in practice - if the discussion is on a mailing list, at best I would have to sign that list to a web mail account and reply that way, and as an average user I don't see why should I make life awkward for myself like that just to make life easier for admins (and I *am* an admin, so I have to look at both sides of the coin here)
Agree, it should be transparent to the user, but again that's where accurate figures come in, and ofcourse the whole system could be as fine-grained as you like, with further limits and slack on subnet level, or by dividing into departments/organisations each with their own limits on different levels (although keeping it as simple as possible would ofcourse be preferred).
I notice you are limiting by smtp session, and a spammer could easily send 100 emails each going to 100 recipients in a single session.
Yep, that's the main problem, limiting the amount of recipients as well as SMTP connections seems to be impractical although perhaps not impossible. An average user nor running a mailing-list will not realisticly send many e-mails to >100 recipients, and when they do it's often internal distribution lists within the same domain, so limiting recipients to a sensible value might not be as hard as it sounds. It also depends on where you want the limiter. When limiting connections between the user and his outgoing SMTP server you run into the recipient problem, so you might be better of limiting outgoing connections from your SMTP server, since multiple recipients will result in multiple outgoing connections from the sending server, althoug this does make coming up with accurate values for the actual base-line limits harder. It would probably require a pretty painful initial setup where the provider tracks e-mail statistics over a period of time and either bases a general limiting value on a good analysis or tweaks the limits on a per customer basis, making the initial setup very labour intensive, but perhaps better in the long term. Instead of automatic blocking you might put in a system where the admin gets alarmed by unusually high activity above the initial limit+slack and the mail is cached but not sent out before admin intervention, allowing the admin to decide whether it's malicious mail traffic or not without disrupting normal service for the user, apart from occasional delivery delay. Regards, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl