Milter-greylist

--- In milter-greylist@yahoogroups.com, manu@n... wrote:
> egcrosser <egcrosser@y...> wrote:
> 
> [SPF]
> > I'm afraid that's not really the case.  What a spammer can do is
> > register a (number of) throwaway domain(s) and publish SPF record
of
> > the kind "v=spf1 +all".  Then command his zombie army to use MAIL
> > FROM:<...@...>.
> 
> Well, if that happens, I assume SPF has no point, then. 
> I just see a minor point: buying a domain costs money, and if I
recall
> correctly, the registar must hold the real identity of the domain
owner.

SPF indeed has less point than it is generally perceived.  What it
does allow is building reputation/certification systems based on
domain names instead of IP addresses.  Which is generally a good
thing.  The "proper" approach to SPF deployment is:

1. block mail that gets SPF "fail".
2. if SPF "pass", collect/check reputation based on domain
3. otherwise, collect/check reputation based on IP address

An easy (imperfect) way to check domain reputation is to run WHOIS
query and see how old it is.

> > Really so.  Still the problem with the current approach is that
it in
> > fact gives spammers a "fast track" around the greylist! (as
described
> > above)
> 
> But do you get spam with this scenario?

Currently no (I think), but it is just because SPF is not deployed
wide enough for spammers to notice.

> [Dynamic greylisting delay, getting higher and higher for bad guys] 
> > > That's an interesting idea. Don't you fear you could give higer
and
> > > higher scores to ISP mail servers? 
> > Possibly the delay can automatically drop down to default value
once
> > "bad behavior" stops?
> 
> Could you post a more detailed plan of the way you think this
should be
> handled? The idea of a reputation system sounds appealing to me,
but I
> don't see how you would increase or decrease the delays exactly.

Have this table:
+--------------------+-----------+--------+
| IP or SPF verified | "Badness" | Last   |
| domain             | index     | update |
+--------------------+-----------+--------+

On incoming mail to non-existent user (or other indication of "bad"
behavior, e.g. DCC positive), increase badness index by
constant_coefficient/(time_now-last_update+1), and set last_update to
current time.  Or maybe just increase it by a constant.

On "good" incoming mail (e.g. that would cause autowhitelisting) reset
badness index to zero.  And set last_update to current time.

On any incoming mail, set
new_delay=default_delay+another_coefficient*(badne
ss_index/(time_now-last_update+1))

Formulae may be more sophisticated, such as logarithmic or
exponential, but you get the idea.

Eugene