On Nov 6, 2010, at 12:45 PM, Stan Hoeppner wrote:

> Michael J Wise put forth on 11/6/2010 11:02 AM:
> 
>> 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.
> 
> The devil is always in the details.

Yes.

> If each of your customer sites
> users has a mailbox on your systems, or more accurately a
> u...@customer.tld email address in your LDAP or SQL DB for relay
> authentication, I believe you can set per user rate limits using policyd.

Problem is, they don't.
The mailbox is on THEIR system.
And however much we beg, plead or whine, some of our customers don't share 
their complete user list with us.
Did I mention we handle a few billion pieces of email a day?
That's a lot of UPDATEs.

> For a given real human user, most aren't going to send more than 1 email
> per minute, if that, unless the user is a Linux developer and pools up
> 15 patch emails then sends them all at once.

Or if there's a mailinglist involved.
But that kind of a situation should be configurable.
Or ... we'll notice it real quick. :)

> For such users, set their
> per user limit higher.  For average users, set it to 1 per minute, or 1
> per 5 minutes.  For mailing lists or transaction systems, set nothing.
> Etc.

Exactly.
But still ...frequency of UPDATEs.

>>> 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.
> 
> Yes it is.  I've heard the following phrase too many times to count:
> "You can't fix stupid."  Technology to prevent a user from typing their
> logon credentials into a web form or sending them in a phish reply would
> be a huge step in the right direction.  I don't even want to guess at
> the development cost for such a system.  Such a system will have flaws,
> and some lusers will still bite the hook. :(

YeahBut ... hmmm. Patentable idea queued for later.

> 
> AFAIK, outbound body header/filtering and targeted rate limiting
> followed up by human intervention after the proper alarms go off, is
> probably the state of the art today WRT phish generated spam.  And AFAIK
> Postfix with the appropriate add on software can accomplish this.

Nice to be called, State of the Art, thanks!

Aloha,
Michael.
-- 
"Please have your Internet License             http://kapu.net/~mjwise/
 and Usenet Registration handy..."

Reply via email to