[Greylist-users] Re: Identifying ill configured relays from expired records

[Barb Dijker]

On 2 May 2004, at 10:24, Allan E. Johannesen wrote:
> I tried greylisting last year and gave up with what I viewed as an
> insurmountable problem of identifying the worldwide bogus smtp 
> generators.
>
> A local cable company retries once a day, with the same message out of 
> a
> different server each time (maybe not, or course, maybe it can randomly
> actually be the same server).

That is what $do_relay_lookup_by_subnet is for (in Evan's).  Seems to 
work well.

>   Various daily mailing lists appeared to use
> "spam"-like software to send it.  One place tried 3 times in rapid 
> succession,
> then would do the same the next day with the next days news.  I phoned 
> them up
> and couldn't find anyone who knew anything about how it's actually 
> sent.

I classify these as legitimate spam: vendor/customer news, opt-in, or 
subscription lists.  The senders have the same problem as spammers - 
volume is too high to manage ensured delivery.

In such cases, only the first day of news might be dropped.  The next 
day the triple should be the same, even though the message content is 
different.  So the mail should be then passed.

Any site that drops on a tempfail clearly does not think their mail is 
important enough to ensure delivery.  If they don't think their mail is 
important, we shouldn't lose sleep over it either.  In most cases the 
message is moot when a day late or the list is archived.

Another setting I find useful here is $delay_mail_secs set to 4 
minutes.  There are many legitimate servers that retry in 5-10 minutes. 
  The low delay does not appear to impact the effectiveness at all since 
spam blasters appear to retry with no delay.  In addition, opening up 
$update_record_life_secs to 90 days or higher helps to eliminate 
problems here without sacrificing effectiveness.  That makes your 
database bigger (and slower).

> Yahoo has the obvious problem of the same sender/receiver being out of
> potentially different servers every time.

Again $do_relay_lookup_by_subnet.

It probably wouldn't be to hard to add a feature whereby if the mail 
passes SPF that the sending IP (and maybe even the from username) is 
ignored.  That could take care of places like yahoo and your cable 
company.

I don't like the idea of maintaining whitelists for stupid mailers.  
It's a maintenance hassle and prone to errors.  That is why 
blacklisting doesn't work well.  Things change too often.

The bottom line is greylisting is the only thing I've found to be 
effective at the recipient end without discrimination based on content 
or association.  I have a customer who is on a ton of porn mailing 
lists.  Spamassassin tags all his mail as spam.  As greylisting becomes 
more widespread in use, which it will, legitimate sites will have to 
wise up on how they send their mail.

Barb Dijker
Netrack, Inc., 3080 Valmont Rd Ste 200, Boulder CO 80301
303.938.0188, toll free 1.888.9Netrack, fax 303.938.0177
www.netrack.net