On Nov 6, 2010, at 11:47 AM, Stan Hoeppner wrote: > I'm guessing your perspective is going to be different that most users > on this list, who are, I'm guessing, not ISPs or service providers per > se.
Yeah. We have about a thousand servers currently doing mail classification. > Thus, I'm guessing the focus of most folks here in this regard is > simply, to use a plumbing analogy, to open the faucet just enough to > allow normal mail to flow freely, but cause a build up of runaway spam > flow to drip out around the faucet, allowing the OP to see the small > puddle and fix the leak. I don't think that's what is on the OP's mind, but ... yes, Rate Limiting is also good, but some of our customers send a huge volume of legit mail in a short amount of time (Phone bills, newletters, etc.), and at THIS point, Customer Support is not predisposed to renegotiate all those contracts to allow the main group to do rate limiting. But I suspect it's going to creep in over time. In addition, with a cluster of a thousand servers in geographically dispersed and load-balanced datacenters, having them coordinate the knowing of how many emails a given customer has sent in the past minute ... Well, I'd be interested in any pointers anyone here could throw on that as well. Not the kind of thing your typical sysadmin with a few hosts, each with their own line in an MX record normally contends with, I know, but hopefully ... some on this list have dealt with similar problems. > This addresses the typical phished credentials > scenario which I think is what most here are probably concerned with. Phished credentials on Customer webmail and compromised machines (Bots, "accidental" open relay) in customer premises are our main issues currently. > I gather that in your environment the goal is to punish the user who > cranked open the knob on the faucet, instead of putting a lock on the > thing in the first place, limiting how far it can be opened. Adding locks after the fact with existing contracts in place can get messy. But we are thinking about it, and are working on rate limiting for some customers. The thing is, we don't want to "Punish" people as such, we want to FIX THE PROBLEM. Phished credentials in theory is fixed by inoculating all users to NOT type their password into an outgoing email EVER. If they are not inoculated, it's fixed by dropping them into a banned sender list and having the customer drop by their office. > Thus, the methods discussed here are probably going to be geared toward > the former and not so much the latter. Still, it's an interesting topic, and I hope at least in part OnTopic for the list. Aloha, Michael. -- "Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy..."
