[Greylist-users] Re: A Greylisting idea.

Mon Jun 23 09:19:42 PDT 2003

On Mon, 23 Jun 2003, Evan Harris wrote:

> > Potentially twisted idea:  If this is in fact an issue, what you should be
> > able to do is add a dummy address to the recipients list the first time
> > that a RCPT TO: should be temp-failed and you haven't accepted any of the
> > addresses, remove the dummy address if you accept an email address
> > after adding it, and then if/when the data command is sent (sendmail won't
> >...
>
> You're right, that is a twisted idea.  But it would probably work.  I'll
> have to think about integrating that.  I just don't know if it's worth it.
> no further consideration.

As I said, "If this is in fact an issue," as I'm of the same opinion.  The
sending MTA is broken, greylisting just makes it more obvious.

> > The way I was thinking of greylisting was to only track from/to/ip addr
> > until the second message, and then just whitelist the IP address for all
> > email, on the assumption that if it passed the MTA IQ test for one
> > transaction, it would pass it for all of them, have greylisting entries
> > valid for 35-45 days, and renew them whenever an email matched them.
>
> The main problem I see with that, is that it makes the problem very simple
> to workaround by the spammers.  Here's how they could do it:

I wasn't saying that my idea was better in any way.  My original message
(offlist and chopped out of the discussion a message or two back) stated
that this was my original idea of greylisting, and that yours was better
thought out.

> > important.  Right now, there's almost no text words that I'm looking for
> > within an email, I'm mostly looking at things that no proper MUA would
> > generate, or what appears to be deliberate attempts to hide.  Several
>
> As a side note, if spamassassin doesn't already have a comperable equivalent
> for all of your tests (see http://au2.spamassassin.org/tests.html) I'd hope
> you would submit a description of the unique tests to them so they can add
> it.  They put a lot of work into those kinds of heuristics, and I'm all for
> reusing someone elses work, assuming it covers all the needed tests.

Just looked that list over, and my best two rules aren't on that list, so
I'll look into that when I get the chance.  They're so effective that I'm
almost afraid that they'll become useless when they go into spamassassin
since they'll be documented where the bulkers check to see how to get
around blocks.  Both of them require that the email be parsed out for mime
entities, however.  One looks for non-comment/non-doctype tags or plain
text outside the <html></html> container, the other looks for multipart/*
sections with only a single sub-entity.  (O.K., now that they're out, I
have less reason to hide them).