Re: Greylisting (was Re: "Fairly-Secure" Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

[Gary Funck <ga...@intrepid.com>]

On 11/29/12 14:46:25, David F. Skoll wrote:
> We greylist after the end of DATA.  This wastes bandwidth, but lets us
> use the Subject: line as an additional mix in the greylisting tuple.
> This catches ratware that retries in the face of greylisting, but
> mutates the subject line with each retry.

We use grey listing on our low volume server, and as others have
noted, it works well because a high percentage of spam bots do
not bother to retry.  But as others have mentioned, it can be
painful waiting for the delayed confirmation on a registration to a web
site to come in an hour/two later, or email from a new client
who is waiting on a response.

Since this is a Spam Assassin list: Is there a way of disabling
grey listing, but still receiving some benefit from the principle
that mail received from a first time or infrequent sender should
be looked upon with some suspicion?

Assume that either some to-be-implemented SA filter, or some
mail gateway front-end (like MIMEDefang), adds a new tag/two,
for example: SENDER_FIRST_RCPT, SENDER_LOW_FREQ,
SENDER_HI_FREQ, or SENDER_HI_AVE_SA_SCORE? All these tags
might be based upon some look back period (say: 90 days).

Theoretically, these new tags could be calculated after the fact
when passing through a spam corpus.  And since many/most grey
listing systems differentiate by some form of (sender, recipient)
pairing this analysis can be reliably/repeatably performed by an
SA plug-in at the point of delivery to the user, if needed.

It would need to be shown that these new tags improve
the ability to discriminate spam from ham.  If the scheme
worked well, there might be no need for grey listing at all.

Re: Greylisting (was Re: "Fairly-Secure" Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

[Martin Gregorie <ma...@gregorie.org>]

On Mon, 2012-12-03 at 07:23 -0800, Gary Funck wrote:
> Since this is a Spam Assassin list: Is there a way of disabling
> grey listing, but still receiving some benefit from the principle
> that mail received from a first time or infrequent sender should
> be looked upon with some suspicion?
> 
Yes. If you keep a list of the recipients of outgoing mail its easy to
whitelist any mail you receive from them. This approach does what you
want: a sender is treated as suspicious until you've sent mail to them
and recipient list maintenance is easy to automate.

I use a mail archive system as my recipients list because it has a
record of everybody I've sent mail to. I use an SA plugin to access the
archive. The combination of it and an associated rule will whitelist
anybody who is recorded in the archive as having received mail from me.

However, the database archives messages at 4-6 /sec, so this and/or the
storage requirements (4.3 GB to store 143,000 messages) may mean that,
if you're a high volume site and/or don't need an archive, you'd be
better off just keeping a list of the recipient(s) of outgoing messages.
 
I wrote my archive for personal use because I can find an old e-mail
with the archive search tool faster than I can by ferreting though a set
of mail folders: it was never designed as a high volume solution, but
should manage small business volumes quite easily with both it and SA
running on a typical desktop PC. Up to early this year I was using an
866 MHz P3 with 512MB RAM that easily kept up while PostgreSQL,the
archive, Postfix and SA. That is all now running on a 3GHz dual Athlon
with 4 GB RAM but not going any faster - an upgrade to Fedora 16 forced
the change because its installer wouldn't run in less than 1GB RAM.

If you think my SA plugin or the mail archive would be of use to you,
contact me off-list.


Martin

Re: Greylisting (was Re: "Fairly-Secure" Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

[Matt <ma...@gmail.com>]

>> We greylist after the end of DATA.  This wastes bandwidth, but lets us
>> use the Subject: line as an additional mix in the greylisting tuple.
>> This catches ratware that retries in the face of greylisting, but
>> mutates the subject line with each retry.

> We use grey listing on our low volume server, and as others have
> noted, it works well because a high percentage of spam bots do
> not bother to retry.  But as others have mentioned, it can be
> painful waiting for the delayed confirmation on a registration to a web
> site to come in an hour/two later, or email from a new client
> who is waiting on a response.

Using dnswl.org to whitelist against greylisting might help some.

> Since this is a Spam Assassin list: Is there a way of disabling
> grey listing, but still receiving some benefit from the principle
> that mail received from a first time or infrequent sender should
> be looked upon with some suspicion?
>
> Assume that either some to-be-implemented SA filter, or some
> mail gateway front-end (like MIMEDefang), adds a new tag/two,
> for example: SENDER_FIRST_RCPT, SENDER_LOW_FREQ,
> SENDER_HI_FREQ, or SENDER_HI_AVE_SA_SCORE? All these tags
> might be based upon some look back period (say: 90 days).
>
> Theoretically, these new tags could be calculated after the fact
> when passing through a spam corpus.  And since many/most grey
> listing systems differentiate by some form of (sender, recipient)
> pairing this analysis can be reliably/repeatably performed by an
> SA plug-in at the point of delivery to the user, if needed.
>
> It would need to be shown that these new tags improve
> the ability to discriminate spam from ham.  If the scheme
> worked well, there might be no need for grey listing at all.
>

Re: Greylisting (was Re: "Fairly-Secure" Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

[RW <rw...@googlemail.com>]

On Mon, 3 Dec 2012 07:23:59 -0800
Gary Funck wrote:

> Since this is a Spam Assassin list: Is there a way of disabling
> grey listing, but still receiving some benefit from the principle
> that mail received from a first time or infrequent sender should
> be looked upon with some suspicion?

Personally I wouldn't want to do it that way round - with a positive
score for unknown rather than a negative score for known. 

YMMV but almost all of the FPs I've had in the last ten years have been
that sort of mail because it's less likely to be recognised by Bayes.