Milter-greylist

Hi!

I've been experimenting with SPF policy check to drive away spf-aware 
spammers who register bogus 2-nd/3-rd level domains and activate +all 
SPF policy on them. The idea is simple:

- Check incoming IP address against domain SPF policy. Fail if this IP 
is not permitted.
- \ufffdheck some bogus IP-address against the same domain SPF policy. Fail 
if this IP is permitted.

I was a bit puzziled with milter-greylist configuration engine, so I 
hard-coded that bogus IP-address into spf.c.

After about a month with a modified spf check it seems that nothing is 
broken, and I have no more spam from domains with too permissive SPF policy.

Do you consider to implement something like that (with a configurable 
IP-address) into mainline ?

My modifications to spf.c follows:

===CUT==
int spf_check(ad, as, ap, priv)
         acl_data_t *ad;
         acl_stage_t as;
         struct acl_param *ap;
         struct mlfi_priv *priv;
{
         int result=spf_check_intl(ad,as,ap,priv);
         if(result==0) return(result);

         struct mlfi_priv priv_copy,*priv2;
         memcpy(&priv_copy,priv,sizeof(priv_copy));
         priv2=&priv_copy;
         struct sockaddr *sa = SA(&priv2->priv_addr);
         inet_aton("88.14.22.16",SADDR4(sa));
         if(spf_check_intl(ad,as,ap,priv2))
             {
             // Bogus SPF record
             mg_log(LOG_WARNING, "%s: bogus SPF record: lists 
88.14.22.16",priv->priv_queueid);
             return(0);
             }
         return result;
}
#define spf_check spf_check_intl

Sergey Kogan a �crit :
> Hi!
> 
> I've been experimenting with SPF policy check to drive away spf-aware 
> spammers who register bogus 2-nd/3-rd level domains and activate +all 
> SPF policy on them. The idea is simple:
> 
> - Check incoming IP address against domain SPF policy. Fail if this IP 
> is not permitted.
> - \u0421heck some bogus IP-address against the same domain SPF policy. Fail 
> if this IP is permitted.
> 

This is already implemented.
Check for "spf self".

> I was a bit puzziled with milter-greylist configuration engine, so I 
> hard-coded that bogus IP-address into spf.c.
> 
> After about a month with a modified spf check it seems that nothing is 
> broken, and I have no more spam from domains with too permissive SPF policy.
> 
> Do you consider to implement something like that (with a configurable 
> IP-address) into mainline ?
> 
> My modifications to spf.c follows:
> 
> ===CUT==
> int spf_check(ad, as, ap, priv)
>          acl_data_t *ad;
>          acl_stage_t as;
>          struct acl_param *ap;
>          struct mlfi_priv *priv;
> {
>          int result=spf_check_intl(ad,as,ap,priv);
>          if(result==0) return(result);
> 
>          struct mlfi_priv priv_copy,*priv2;
>          memcpy(&priv_copy,priv,sizeof(priv_copy));
>          priv2=&priv_copy;
>          struct sockaddr *sa = SA(&priv2->priv_addr);
>          inet_aton("88.14.22.16",SADDR4(sa));
>          if(spf_check_intl(ad,as,ap,priv2))
>              {
>              // Bogus SPF record
>              mg_log(LOG_WARNING, "%s: bogus SPF record: lists 
> 88.14.22.16",priv->priv_queueid);
>              return(0);
>              }
>          return result;
> }
> #define spf_check spf_check_intl
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 


-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.

On Sat, Mar 21, 2009 at 03:03:23PM +0600, Sergey Kogan wrote:
> 
> I've been experimenting with SPF policy check to drive away spf-aware 
> spammers who register bogus 2-nd/3-rd level domains and activate +all 
> SPF policy on them. The idea is simple:
> 
> - Check incoming IP address against domain SPF policy. Fail if this IP 
> is not permitted.
> - \u0421heck some bogus IP-address against the same domain SPF policy. Fail 
> if this IP is permitted.

Are you looking for `spf self'?

   spf    This is used to test SPF status. Possible values are pass, soft\u2010
          fail,  fail, unknown, error, none, and self.  The first six val\u2010
          ues are plain SPF validation status. The self value is a special
          test  that  checks  the  server's  local  IP address against the
          sender's SPF record. If that test validates, odds are good  that
          the  sender  SPF  record is wide open, and this is hint that SPF
          should not be trusted.


> After about a month with a modified spf check it seems that nothing is 
> broken, and I have no more spam from domains with too permissive SPF policy.

What about spam from domains with restrictive SPF policies? SPF pass
means nothing nowadays.



   Petar Bogdanovic

Petar Bogdanovic <petar@...> wrote:

> What about spam from domains with restrictive SPF policies? SPF pass
> means nothing nowadays.

Agreed. SPF fail is probably the only interesting thing to use (for
rejection)

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

manu@... a \ufffdcrit :
> Petar Bogdanovic <petar@...> wrote:
> 
>> What about spam from domains with restrictive SPF policies? SPF pass
>> means nothing nowadays.
> 
> Agreed. SPF fail is probably the only interesting thing to use (for
> rejection)
> 

Personnaly I use several SPF rules in greylist.conf:

- "spf fail" to reject (but beware of non-SRS-compliant forwarders which 
could lead to false-prositives). This protects agains some 
sender-address abuses (so, some spam).

- "spf softfail" to greylist somewhat longer than the default

- "spf pass spf self" also to greylist longer (too bad we couldn't fully 
reject, some legitimate domains have broken SPFs...)

- "spf pass" to skip default greylisting (on the bottom part of ACLs).

And I have some more acls to apply heavier penalty if the above rules 
combine with some other: for example, if we have "spf self" AND some 
positive DNSRBL, the we could reject.

But nowadays spammers are more and more shifting away from trojan spam 
agents (zombie botnets), which weren't so difficult to identify (DNSRBL, 
SPF, DNS records regex, and the like). They are rather going to exploit 
regular SMTP servers, which have good SPFs, are on whitehlists, have 
unsuspicious DNS records... So the fight becomes more fuzzy.

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.