Milter-greylist

> Joel Reicher <joel@...> wrote:
> 
> > OK, at least that addresses my concern for known mail farms, but the
> > larger part of my concern is for *unknown* mail farms. When mail first
> > arrives from them, it can be greylisted a very, very long time if the
> > maillog and greylist.db trawling isn't done often enough. I was hoping
> > making the greylisting facility SPF-aware would solve this.
> 
> If I understand correctly your idea, you want to do this:
> 
> if (spf) 
>         greylist (*, from, rcpt)
> else
>         greylist (addr, from, rcpt)

No, not quite. What I have in mind is the effect of the following (but
I wouldn't actually implement it this way)

if (spf)
	foreach (i in spfRecord)
		if(i is pass-qualified)
			greylist (i, from, rcpt)
else
	greylist (addr, from, rcpt)

The intent is to treat the SPF record as a "subnetmatch".

> What happens if a spammert sends from a botnet with from addresses in a
> domain that has a ?all SPF record (ie: any host may send mail from the
> domain)? 

Firstly, I think any administrator that took SPF seriously and used it
for a mail farm wouldn't qualify the farm machines as neutral.

But you could ask the same question about +all in the record, and I see
two ways of going on that. One is to treat it as a special case and
never greylist it.

On the other hand, what would be the harm in treating it the same
way as any other part of the record, and let the other two fields of the
greylisted tuple do their job? I see no problem with opening the system up
to a spammer who might resend from a different IP later, since that's no
more likely then resending from the same IP, in which case the spam gets
past greylisting anyway.

Cheers,

	- Joel