You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "David F. Skoll" <df...@roaringpenguin.com> on 2014/08/15 19:50:31 UTC
Bogus SPF +all (was Re: dnssec / dane)
On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
> On Fri, 15 Aug 2014, David F. Skoll wrote:
> > SPF is so easy ("v=spf1 +all")
> Doing *that* should be worth a point or two by itself.
Yes. I even through about implementing it, but there are so many ways
to achieve this:
v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org
... etc...
that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK. (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)
Regards,
David.
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?
askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /v=spf1.+\+all/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /v=spf1.+\-all/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/
I can't seem to get these rules to fire on test emails?
Example domain of merchantaccount-quotes.co.uk
Paul
On 15/08/14 18:50, David F. Skoll wrote:
On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
On Fri, 15 Aug 2014, David F. Skoll wrote:
SPF is so easy ("v=spf1 +all")
Doing *that* should be worth a point or two by itself.
Yes. I even through about implementing it, but there are so many ways
to achieve this:
v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org
... etc...
that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK. (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)
Regards,
David.
--
Paul Stead
Systems Engineer
Zen Internet
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Steve Freegard <st...@fsl.com>.
On 15/08/14 18:54, Joe Quinn wrote:
> On 8/15/2014 1:50 PM, David F. Skoll wrote:
>> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
>> John Hardin <jh...@impsec.org> wrote:
>>
>>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>>> SPF is so easy ("v=spf1 +all")
>>> Doing *that* should be worth a point or two by itself.
>> Yes. I even through about implementing it, but there are so many ways
>> to achieve this:
>>
>> v=spf1 +all
>> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
>> v=spf1 exists:openspf.org
>>
>> ... etc...
>>
>> that we really need an SPF normalizing library that tells you what
>> percentage of IPv4 space would pass, and then add points for anyone
>> claiming
>> (say) that more than 1% of total IPv4 space is OK. (Though the exists:
>> mechanism is nasty; not sure you even can predict what percentage of
>> IPv4 is covered in complex cases.)
>>
>> Regards,
>>
>> David.
> I guess the logical next question would be what proportion of spam uses
> universal SPF to eke out negative points. Has anyone seen this sort of
> thing in the wild?
I've been dealing with this outside of SA for quite a while now. Here's
the last month on my low volume dev box:
[root@mail1-ec2 Haraka]# grep -h 'ignoring SPF' /var/log/maillog* | tr
-s " " | cut -d" " -f8- | sort | uniq -c | sort -rn
590 [sender_auth] ignoring SPF Pass result: v=spf1 a +all
363 [sender_auth] ignoring SPF Pass result: v=spf1 mx ptr +all
86 [sender_auth] ignoring SPF Pass result: v=spf1 +all
62 [sender_auth] ignoring SPF Pass result: v=spf1 a mx +all
23 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:17.0.0.0/8 ~all
4 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:162.0.0.0/8
ip4:107.161.144.0/8 ~all
3 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:0.0.0.0/1
ip4:130.0.0.0/1 ~all
3 [sender_auth] ignoring SPF Pass result: v=spf1 a mx ptr
mx:mail.windmedya.net ip4:46.235.13.163 +all
2 [sender_auth] ignoring SPF Pass result: v=spf1 a mx
ip4:69.16.157.128/25 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1 mx
ip4:77.232.64.0/19 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1 mx
ip4:183.91.18.234 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1
include:_spf.uni5.net a mx ptr ip4:177.74.160.0/20 ip4:177.91.0.0/22
ip4:74.50.96.0/19 ip4:201.28.44.232/30 ip4:177.223.221.0/24
ip4:199.193.112.0/21 ip4:177.47.96.0/19 ip4:177.36.16.0/20
ip4:68.233.224.0/19 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1
include:_spf.uni5.net a mx ptr ip4:177.74.160.0/20 ip4:177.91.0.0/22
ip4:177.47.96.0/19 ip4:177.36.16.0/20 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1
include:spf-a.roh.org.uk include:spf-b.roh.org.uk +all
1 [sender_auth] ignoring SPF Pass result: v=spf1 a ptr
ip4:85.95.239.112 mx:mail.yunusemregroup.net +all
1 [sender_auth] ignoring SPF Pass result: v=spf1 a mx ptr
mx:mail.sakaryadental.com ip4:91.191.171.161 +all
1 [sender_auth] ignoring SPF Pass result: v=spf1 a
ip4:194.225.184.4 include:iums.ac.ir +all
I ignore and flag SPF Pass results where +all is set or if the netmask
on ip4: is /[0-8] - that obviously isn't perfect as it doesn't handle
the exists: case (which I admittedly hadn't thought of).
I'm doing this at the SMTP level; a quick look through the logs shows
that the top hitting pattern (v=spf1 a +all) is matching a lot of
invalid recipients or DNSBL blacklisted connections indicating that it's
a definite spam indicator.
Kind Regards,
Steve.
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.08.2014 um 19:54 schrieb Joe Quinn:
> On 8/15/2014 1:50 PM, David F. Skoll wrote:
>> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
>> John Hardin <jh...@impsec.org> wrote:
>>
>>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>>> SPF is so easy ("v=spf1 +all")
>>> Doing *that* should be worth a point or two by itself.
>> Yes. I even through about implementing it, but there are so many ways
>> to achieve this:
>>
>> v=spf1 +all
>> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
>> v=spf1 exists:openspf.org
>>
>> ... etc...
>>
>> that we really need an SPF normalizing library that tells you what
>> percentage of IPv4 space would pass, and then add points for anyone
>> claiming
>> (say) that more than 1% of total IPv4 space is OK. (Though the exists:
>> mechanism is nasty; not sure you even can predict what percentage of
>> IPv4 is covered in complex cases.)
>>
>> Regards,
>>
>> David.
> I guess the logical next question would be what proportion of spam uses
> universal SPF to eke out negative points. Has anyone seen this sort of
> thing in the wild?
However it seems SPF is not a good trigger, but perhaps combi of valid
DKIM and DANE is it "recently". I agree this may no last forever but
on the other hand spamassassin rules are not static and can be changed
if needed.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Joe Quinn <jq...@pccc.com>.
On 8/15/2014 1:50 PM, David F. Skoll wrote:
> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>> SPF is so easy ("v=spf1 +all")
>> Doing *that* should be worth a point or two by itself.
> Yes. I even through about implementing it, but there are so many ways
> to achieve this:
>
> v=spf1 +all
> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
> v=spf1 exists:openspf.org
>
> ... etc...
>
> that we really need an SPF normalizing library that tells you what
> percentage of IPv4 space would pass, and then add points for anyone claiming
> (say) that more than 1% of total IPv4 space is OK. (Though the exists:
> mechanism is nasty; not sure you even can predict what percentage of
> IPv4 is covered in complex cases.)
>
> Regards,
>
> David.
I guess the logical next question would be what proportion of spam uses
universal SPF to eke out negative points. Has anyone seen this sort of
thing in the wild?
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by John Hardin <jh...@impsec.org>.
On Fri, 15 Aug 2014, Dave Warren wrote:
> On 2014-08-15 12:05, John Hardin wrote:
>> "exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for
>> "exists:"??
>
> With other types of macro expansion, you could query a DNS backend that
> returns responses from database or algorithmically rather than based on
> static SPF rules written in DNS as text.
>
> Arguably most of it is needlessly complex in practice, but it's still a neat
> idea, or would be, if SPF FAIL were universally enforced.
Ah, ok, I didn't think to combine it with macros and such. That makes more
sense.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
From the Liberty perspective, it doesn't matter if it's a
jackboot or a Birkenstock smashing your face. -- Robb Allen
-----------------------------------------------------------------------
Today: the 69th anniversary of the end of World War II
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Dave Warren <da...@hireahit.com>.
On 2014-08-15 12:05, John Hardin wrote:
> "exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for
> "exists:"??
Imagine something like:
exists:%{l}.%{o}.%{i}._spf.webhost.example
This might allow me to PASS only messages coming from addresses that
actually exist, and are from the correct server. (Sure, the sending
server really should enforce this itself, but not all do)
Or I could get more complicated, PASS message from addresses that exist
from the correct server, NEUTRAL from addresses that exist when the
message is from an incorrect server, and fail everything from invalid
addresses no matter what:
exists:%{l}.%{o}.%{i}._spf.webhost.example
?exists:%{l}.%{o}._any._spf.webhost.example -all
With other types of macro expansion, you could query a DNS backend that
returns responses from database or algorithmically rather than based on
static SPF rules written in DNS as text.
Arguably most of it is needlessly complex in practice, but it's still a
neat idea, or would be, if SPF FAIL were universally enforced.
Even without FAIL enforcement though, exists: can be used as a logging
mechanism to track forgeries, similar to DMARC's feedback mechanism.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by John Hardin <jh...@impsec.org>.
On Fri, 15 Aug 2014, David F. Skoll wrote:
> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>> SPF is so easy ("v=spf1 +all")
>
>> Doing *that* should be worth a point or two by itself.
>
> Yes. I even through about implementing it, but there are so many ways
> to achieve this:
>
> v=spf1 +all
> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
> v=spf1 exists:openspf.org
>
> ... etc...
>
> that we really need an SPF normalizing library that tells you what
> percentage of IPv4 space would pass, and then add points for anyone claiming
> (say) that more than 1% of total IPv4 space is OK.
Sure.
> (Though the exists: mechanism is nasty; not sure you even can predict
> what percentage of IPv4 is covered in complex cases.)
"exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for
"exists:"??
That also could be worth a point or two if it's used. There's no reason to
try to be *too* smart about edge cases. Do the coverage analysis where
possible, and add a point for unusual stuff like that. I assume this all
would have to be plugin-based; add an exclusion list for domains where
"exists:" is expected and should not be scored, similar to the URIBL
lookup domain exclusion list.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Therapeutic Phrenologist - send email for affordable rate schedule.
-----------------------------------------------------------------------
Today: the 69th anniversary of the end of World War II
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Hmm, serves me right for not reading correctly, doesn't look like SENDERDOMAIN is a tag that is set - is there another tag I could use? DKIMDOMAIN exists, but no use
On 31/10/14 16:05, Paul Stead wrote:
have noticed I get the following from a debug:
dbg: check: tagrun - tag SENDERDOMAIN is still blocking action 1
-- Am I using the right tag?
--
Paul Stead
Systems Engineer
Zen Internet
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Paul Stead <pa...@zeninternet.co.uk>.
I have noticed I get the following from a debug:
dbg: check: tagrun - tag SENDERDOMAIN is still blocking action 1
-- Am I using the right tag?
On 31/10/14 13:51, Paul Stead wrote:
Tried to send this before, seemed to not go through, apologies if two copies get through eventually...
Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?
askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /^v=spf1.+\+all$/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /^v=spf1 -all$/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/
I can't seem to get these rules to fire on test emails?
Paul
On 15/08/14 18:50, David F. Skoll wrote:
On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
On Fri, 15 Aug 2014, David F. Skoll wrote:
SPF is so easy ("v=spf1 +all")
Doing *that* should be worth a point or two by itself.
Yes. I even through about implementing it, but there are so many ways
to achieve this:
v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org
... etc...
that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK. (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)
Regards,
David.
--
Paul Stead
Systems Engineer
Zen Internet
--
Paul Stead
Systems Engineer
Zen Internet
Re: Bogus SPF +all (was Re: dnssec / dane)
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Tried to send this before, seemed to not go through, apologies if two copies get through eventually...
Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?
askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /^v=spf1.+\+all$/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /^v=spf1 -all$/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/
I can't seem to get these rules to fire on test emails?
Paul
On 15/08/14 18:50, David F. Skoll wrote:
On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
On Fri, 15 Aug 2014, David F. Skoll wrote:
SPF is so easy ("v=spf1 +all")
Doing *that* should be worth a point or two by itself.
Yes. I even through about implementing it, but there are so many ways
to achieve this:
v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org
... etc...
that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK. (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)
Regards,
David.
--
Paul Stead
Systems Engineer
Zen Internet