Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

Fake/wildcard SPF domain rejection

Fake/wildcard SPF domain rejection

2007-11-02 by Сергей Коган

Hi !

More and more spammers are using misconfigured (or spam-and-drop)
domains with wildcard (+all) SPF policy. This defeats milter-greylist
protection, as SPF-compliant senders are not subject to initial message
delay.

I propose a trivial code that reduces trust in too-permissive SPF domains.

This works as follows:

- Test incoming address with SPF_CHECK as usual.
- If address is permitted (EXF_SPF), test some bogus IP-addressed with
the same domain/SPF policy.
- If bogus addresses are permitted, then do not trust the domain SPF record.


What do you think ?


Code snippet follows (call it instead of SPF_CHECK in milter-greylist.c):
===
int spf_wildcard_filter(sa, salen, helo, fromp)
         struct sockaddr *sa;
         socklen_t salen;
         char *helo;
         char *fromp;
{
int result=SPF_CHECK(sa,salen,helo,fromp);

// Negative results are reported immidiately
if(result!=EXF_SPF) return(result);

// FIXME: it would be nice to support IPv6 here
if(sa->sa_family!=AF_INET) return(result);

// FIXME: Bogus addresses should be generated by rand()
// or set in config file (probably better)
// For now I just hard-code two "suffucuently bogus" addresses here
struct sockaddr_in fakeaddr;
fakeaddr.sin_family=AF_INET;
fakeaddr.sin_port=25;

// If bogus address is not allowed, we trust this domain
inet_aton("250.19.0.16",&(fakeaddr.sin_addr));
if(SPF_CHECK(&fakeaddr,salen,helo,fromp)!=EXF_SPF) return(result);
inet_aton("127.210.140.17",&(fakeaddr.sin_addr));
if(SPF_CHECK(&fakeaddr,salen,helo,fromp)!=EXF_SPF) return(result);

// It's a spammer - ignore SPF check result
mg_log(LOG_INFO,"SPF fake/wildcard policy detected");
return(EXF_NONE);
}
===

---
Sincerely yours,
Sergey Kogan

Re: Fake/wildcard SPF domain rejection

2007-11-02 by Jim Hermann

--- In milter-greylist@yahoogroups.com, <kogan@...> wrote:
>
> Hi !
> 
> More and more spammers are using misconfigured (or spam-and-drop)
> domains with wildcard (+all) SPF policy.

See http://tech.groups.yahoo.com/group/milter-greylist/message/3701

We need all the SPF return codes available, plus a custom return code 
for +all results.

Jim

Re: [milter-greylist] Re: Fake/wildcard SPF domain rejection

2007-11-02 by manu@netbsd.org

Jim Hermann <hostmaster@...> wrote:

> See http://tech.groups.yahoo.com/group/milter-greylist/message/3701
> 
> We need all the SPF return codes available, plus a custom return code
> for +all results.

Better than +all, you can check whether your own IP address validates
the sender SPF record. If it does, odd are that you have a wide-open SPF
record.

I plan to start wokring on SPF filtering soon.

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

Re: Fake/wildcard SPF domain rejection

2007-11-03 by Jim Hermann

--- In milter-greylist@yahoogroups.com, manu@... wrote:
>
> Jim Hermann <hostmaster@...> wrote:
> 
> > See http://tech.groups.yahoo.com/group/milter-greylist/message/3701
> > 
> > We need all the SPF return codes available, plus a custom return 
code
> > for +all results.
> 
> Better than +all, you can check whether your own IP address validates
> the sender SPF record. If it does, odds are that you have a wide-
open SPF
> record.

Unless it was a SPF Record for our own domain.  ;)  My incoming server 
gets email from domains that are also authorized to send email from my 
IP Address.  My own domain SPF record looks like this:

"v=spf1 ip4:69.94.104.180 ip4:69.94.104.190 ptr:quickbooks.com 
ptr:yahoo.com ptr:sbcglobal.net ptr:enom.com ptr:rr.com 
ptr:meadville.edu ptr:chron.com -all"

I guess you could pick a completely random IP Address.  The odds are 
pretty small of hitting a member of the IP Addresses in a legitimate 
SPF record.  The odds of hitting a single CIDR set of /16 addresses 
would be 1/65536.  A SPF Record like mine is pretty broad and it still 
probably would be less than a 1/1000 chance of randomly hitting it.

Alternatively, you could let the user pick a secret IP Address.  It 
could be their IP Address, a random IP Address, or the IP Address of a 
unassigned IP Address in China.  This is probably a better idea.

Jim

Re: [milter-greylist] Re: Fake/wildcard SPF domain rejection

2007-11-03 by manu@netbsd.org

> Unless it was a SPF Record for our own domain.  ;)  My incoming server
> gets email from domains that are also authorized to send email from my
> IP Address.  

Well, what's the point of doing a SPF lookup for them? They should be
whitelisted earlier in the ACL.

> Alternatively, you could let the user pick a secret IP Address.  It 
> could be their IP Address, a random IP Address, or the IP Address of a
> unassigned IP Address in China.  This is probably a better idea.

Or a user-configurable netblock in which the address will be randomly
selected...

I've written the code for checking any SPF status in an ACL clause, and
the self-SPF case described above. Anyone has a SPF testbed to testdrive
it?

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

Re: Fake/wildcard SPF domain rejection

2007-11-04 by Jim Hermann

--- In milter-greylist@yahoogroups.com, manu@... wrote:
>
> > Unless it was a SPF Record for our own domain.  ;)  My incoming 
server
> > gets email from domains that are also authorized to send email 
from my
> > IP Address.  
> 
> Well, what's the point of doing a SPF lookup for them? They should be
> whitelisted earlier in the ACL.
> 

I require spf pass results for any whitelist IP Address where the 
expected domain name has a SPF record.  Even a whitelisted IP Address 
can become compromised or a IP Address range might be too broad.  

For example, aol.com and cs.com have SPF records:

racl whitelist addr 64.12.136.0/24 spf report "SPF_OK From %f at IP %
i - Sender IP whitelisted, not delayed by %V" # AOL - confirmed - jwh
racl whitelist addr 64.12.137.0/24 spf report "SPF_OK From %f at IP %
i - Sender IP whitelisted, not delayed by %V" # AOL - confirmed - jwh
racl whitelist addr 64.12.138.0/24 spf report "SPF_OK From %f at IP %
i - Sender IP whitelisted, not delayed by %V" # AOL - confirmed - jwh
[snip - of course, there are more aol.com email servers]

Also, juno.com and rr.com has SPF records:

racl whitelist addr 64.136.47.0/24 spf report "SPF_OK From juno.com" # 
juno.com untd.com[64.136.47.20]
racl whitelist addr 66.27.89.0/24 spf report "SPF_OK From rr.com" # 
san.res.rr.com [66.27.89.65]

For the whitelist to be used, the envelope sender domain SPF record 
must match the IP Address.  If the domain does not have a SPF record, 
like yahoo.com, I don't include the spf requirement:

racl whitelist addr 209.131.38.0/24    # n29b.bullet.sp1.yahoo.com 
[209.131.38.250] no spf
racl whitelist addr 209.191.68.0/24    # webxxxxx.mail.mud.yahoo.com 
[209.191.68.150] no spf
racl whitelist addr 216.252.101.0/24   # webxxxxx.mail.mud.yahoo.com 
[216.252.101.34] no spf
racl whitelist addr 216.252.110.0/24   # webxxxxx.mail.re3.yahoo.com 
[216.252.110.220] no spf

Jim

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.