Log in

No account? Create an account
entries friends calendar profile my webpage Previous Previous Next Next
Spam, spam... - Tina Marie's Ramblings
Red hair and black leather, my favorite colour scheme...
Spam, spam...
Has anyone taken a good look at this?


From the web page:

Greylisting got it's name because it is kind of a cross between black- and white-listing, with mostly automatic maintenance. A key element of the Greylisting method is this automatic maintenance.
The Greylisting method is very simple. It only looks at three pieces of information (which we will refer to as a "triplet" from now on) about any particular mail delivery attempt:

  • The IP address of the host attempting the delivery

  • The envelope sender address

  • The envelope recipient address

From this, we now have a unique triplet for identifying a mail "relationship". With this data, we simply follow a basic rule, which is:

  • If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure.

Since SMTP is considered an unreliable transport, the possibility of temporary failures is built into the core spec (see RFC 821). As such, any well behaved message transfer agent (MTA) should attempt retries if given an appropriate temporary failure code for a delivery attempt (see below for discussion of issues concerning non-conforming MTA's).

During the initial testing of Greylisting, it was observed that the vast majority of spam appears to be sent from applications designed specifically for spamming. These applications appear to adopt the "fire-and-forget" methodology. That is, they attempt to send the spam to one or several MX hosts for a domain, but then never attempt a true retry as a real MTA would. From our testing, this means that currently, based on a fairly conservative interpretation of testing data, we see effectiveness of over 95%, and that is with no legitimate mail ever being permanently blocked.

I'm thinking about trying out the sendmail implementation. It's a fascinating idea....

Current Mood: exhausted exhausted

8 comments or Leave a comment
alioth1 From: alioth1 Date: June 25th, 2003 10:04 am (UTC) (Link)
Sounds cool. I bet there's a way to do it with Exim and Perl :-)

I personally use a combination of SpamAssassin, the Spamhaus Blackhole List (which is fairly conservative in what it blocks, only blocking bad offenders unlike other lists which arbitarily block entire /24 subnets) and the DCC (Distributed Checksum Clearinghouse). The DCC is quite interesting as it creates a 'fuzzy' checksum for mail. Thousands of MXes compare checksums via the DCC servers to detect whether mail is bulk or not (SpamAssassin controls DCC usage in my case). This is all started by Exim, my MTA of choice (I've never liked sendmail much).

Anyway, Exim - http://www.exim.org
SpamAssassin - http://www.spamassassin.org
The DCC: http://www.rhyolite.com/anti-spam/dcc

It vastly cuts down on spam, and the risk of false positives is very low.

The greylist idea sounds very cool and it sounds like it'll be effective ... do they have a list of MTAs that barf? (I'm betting M Sexchange is one of those that die on temporary failures )
skywhisperer From: skywhisperer Date: June 26th, 2003 12:03 pm (UTC) (Link)


It's currently implemented in perl, using the same interface as SpamAssassin, so it should be pretty easily ported to exim.

One of the downsides of the method is that in order to be effective, all MXes for a given domain need to run it...

the_carrot From: the_carrot Date: June 25th, 2003 12:52 pm (UTC) (Link)
Jesus, that's sweet, but in the case of some industrial-strength mail servers how big is that table of relationships going to get (I'm thinking ISPs here)?
skywhisperer From: skywhisperer Date: June 25th, 2003 01:41 pm (UTC) (Link)


Pretty big, but throw it into a SQL database, and it's not a real big deal. Most ISPs are saying that about 90% of their incoming mail is spam, so it's probably an easy trade.
the_carrot From: the_carrot Date: June 25th, 2003 01:50 pm (UTC) (Link)

Re: ...

Yeah, that's a good point, you'll be saving a ton of storage by not accepting all that mail. Still, I don't like having to perform a database search on every piece of mail coming in, but then again, the machine's not gonna be routing nearly as many messages, so the clock cycles will be there, and I guess I sort of do that now when I sort through my incoming email, right, and...

Holy shit! You could build this as an appliance. Corporations would go for that big-time: plug it in, configure it with the server names, and voila!
skywhisperer From: skywhisperer Date: June 25th, 2003 02:10 pm (UTC) (Link)

Re: ...

There's already an appliance that would be a perfect place to put it - build it into your firewall.

the_carrot From: the_carrot Date: June 25th, 2003 07:46 pm (UTC) (Link)

Re: ...

That would be a good place to put it, all right. Hmmm...


Goddamn you, you code vixen, now you've got me thinking about this shit instead of going to bed like a normal person.
(Deleted comment)
jedi_mermaid From: jedi_mermaid Date: June 26th, 2003 12:02 am (UTC) (Link)
Yeah, really.

Who says that PM hours are "normal" for bed anyway?
8 comments or Leave a comment