You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ned Slider <ne...@unixmail.co.uk> on 2010/06/30 17:37:01 UTC

How not to implement SPF (nationwide.co.uk)

I was a little bit surprised to see a phishing email today from 
nationwide.co.uk that passed SPF!

So, upon further investigation we see:

$ dig txt nationwide.co.uk

;; ANSWER SECTION:
nationwide.co.uk.       5648    IN      TXT     "v=spf1 mx 
a:mailhost.nationet.com a:mailhost2.nationet.com include:messagelabs.com 
~all"

Great, at least they have an SPF record, but then messagelabs.com lets 
the side down:

$ dig txt messagelabs.com

;; ANSWER SECTION:
messagelabs.com.        84771   IN      TXT     "v=spf1 +all"


So all mail from  nationwide.co.uk will pass SPF. Great. And banks 
wonder why they get so many phishing emails. Are they really that 
incompetent or do they just not care?

I really don't understand why banks don't implement DKIM and/or SPF and 
make it easier for us to filter phishing emails.

My solution is to just filter ALL mail from bank or bank-like domains. 
The vast majority are phishing anyway with only a few marketing emails 
(often not from a bank domain) or "your online statement is ready" 
notifications that I'm sure users can do without. Those that do 
implement DKIM/SPF etc can then be whitelisted.


Re: How not to implement SPF (nationwide.co.uk)

Posted by Benny Pedersen <me...@junc.org>.
On ons 30 jun 2010 17:37:01 CEST, Ned Slider wrote

> I was a little bit surprised to see a phishing email today from  
> nationwide.co.uk that passed SPF!

contact them to solve it then, provide the evidence for them, might be  
next step to stop such spam mails

> So, upon further investigation we see:
>
> $ dig txt nationwide.co.uk
>
> ;; ANSWER SECTION:
> nationwide.co.uk.       5648    IN      TXT     "v=spf1 mx  
> a:mailhost.nationet.com a:mailhost2.nationet.com  
> include:messagelabs.com ~all"

include to a 3dr party domain makes it less spf secure since 3dr party  
can use +all as seen below

suggest make bug in bugzilla for test more strongly in spamassassin  
for this, but it should be possible to see its not sent from the mx,  
with or without spf

> Great, at least they have an SPF record, but then messagelabs.com  
> lets the side down:
>
> $ dig txt messagelabs.com
>
> ;; ANSWER SECTION:
> messagelabs.com.        84771   IN      TXT     "v=spf1 +all"

+all is spf valid

> So all mail from  nationwide.co.uk will pass SPF. Great. And banks  
> wonder why they get so many phishing emails. Are they really that  
> incompetent or do they just not care?

banks are clueless :)

really any tld co.uk is

> I really don't understand why banks don't implement DKIM and/or SPF  
> and make it easier for us to filter phishing emails.

or pgp/smime, here i still have to see a spam mail that is pgp signed !

> My solution is to just filter ALL mail from bank or bank-like  
> domains. The vast majority are phishing anyway with only a few  
> marketing emails (often not from a bank domain) or "your online  
> statement is ready" notifications that I'm sure users can do  
> without. Those that do implement DKIM/SPF etc can then be whitelisted.

bingo, there are to many softfails and domains not using openspf  
wizard, and follow the guide strictly, it does not mean that spf is  
bad, if used properly

i got my own bank to use spf properly by talk with my supporter about  
it, it was typicly seen after mail forges of mail for end users belive  
when from is bank domain then its there bank that sent it no matter  
that enveloppe sender or ip was outside of danmark :(

-- 
xpoint http://www.unicom.com/pw/reply-to-harmful.html


Re: How not to implement SPF (nationwide.co.uk)

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On Wed, 30 Jun 2010 20:19:43 +0100
>> Ned Slider<ne...@unixmail.co.uk>  wrote:
>>> so they have no SPF policy? Wrong, they do, but it's on their
>>> email.barclays.co.uk subdomain as presumably that's the domain they
>>> send mail from - but how are you supposed to know that if they don't
>>> tell you?

> On 6/30/2010 2:25 PM, RW wrote:
>> I suppose they are being realistic about spf - that it's only really
>> useful for whitelisting purposes.

On 04.07.10 23:57, Marc Perkel wrote:
> It's not even useful for white listing as spammers can set up SPF too.

Marc, please stop bullshitting about SPF, finally.
We already know you don't understand how it works.
-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody

Re: How not to implement SPF (nationwide.co.uk)

Posted by Kelson Vibber <ke...@speed.net>.
On Jul 5, 2010, at 6:46 AM, Marc Perkel wrote:
> 
> BTW - does anyone have some big list of domain that when combined with SPF make a good white list?

Well, that would depend on who you and your users want mail from, wouldn't it?

Re: How not to implement SPF (nationwide.co.uk)

Posted by Marc Perkel <su...@junkemailfilter.com>.

On 7/5/2010 1:10 AM, Kelson Vibber wrote:
> On Jul 4, 2010, at 11:57 PM, Marc Perkel wrote:
>    
>> It's not even useful for white listing as spammers can set up SPF too.
>>      
>
> That's not how whitelisting on SPF works.
>
> You don't whitelist *solely* on the presence of SPF.
>
> You whitelist the *combination* of a domain that you want and a positive SPF match.
>
> Let's say you want to whitelist mail from example.com, and you don't want to worry about keeping track of their outgoing servers. You set up whitelisting using SPF such that...
>
> 1. Mail from example.com that doesn't pass SPF =>  neutral, go through normal filtering
> 2. Mail from example.com that DOES pass SPF =>  whitelisted
> 3. Mail from random spammer's domain that passes SPF =>  neutral, go through normal filtering
>
> Multiply steps #1 and #2 by however many domains you want to whitelist, and it's a lot more convenient than keeping track of all their IP addresses yourself, especially if they have a lot of them or change them from time to time..
>
> That's how SpamAssassin uses SPF to whitelist mail.  (See the docs for whitelist_from_spf and similar rules.)  Notice that it really doesn't matter whether spammers set up their own SPF rules.
>
> Actually, you could make use of spammers' SPF records in some circumstances by adding a fourth possibility:
>
> 4. Mail from known spammer's domain that passes SPF =>  blacklisted
>
> OK, that fourth possibility isn't likely to crop up very often, but it's still taking advantage of spammers using SPF...which, once again, doesn't interfere with SPF's usefulness as a component of whitelisting.
>
>
>    

BTW - does anyone have some big list of domain that when combined with 
SPF make a good white list?

-- 
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400


Re: How not to implement SPF (nationwide.co.uk)

Posted by Kelson Vibber <ke...@speed.net>.
On Jul 4, 2010, at 11:57 PM, Marc Perkel wrote:
> It's not even useful for white listing as spammers can set up SPF too.


That's not how whitelisting on SPF works.

You don't whitelist *solely* on the presence of SPF.

You whitelist the *combination* of a domain that you want and a positive SPF match.

Let's say you want to whitelist mail from example.com, and you don't want to worry about keeping track of their outgoing servers. You set up whitelisting using SPF such that...

1. Mail from example.com that doesn't pass SPF => neutral, go through normal filtering
2. Mail from example.com that DOES pass SPF = > whitelisted
3. Mail from random spammer's domain that passes SPF => neutral, go through normal filtering

Multiply steps #1 and #2 by however many domains you want to whitelist, and it's a lot more convenient than keeping track of all their IP addresses yourself, especially if they have a lot of them or change them from time to time..

That's how SpamAssassin uses SPF to whitelist mail.  (See the docs for whitelist_from_spf and similar rules.)  Notice that it really doesn't matter whether spammers set up their own SPF rules.

Actually, you could make use of spammers' SPF records in some circumstances by adding a fourth possibility:

4. Mail from known spammer's domain that passes SPF => blacklisted

OK, that fourth possibility isn't likely to crop up very often, but it's still taking advantage of spammers using SPF...which, once again, doesn't interfere with SPF's usefulness as a component of whitelisting.


Re: How not to implement SPF (nationwide.co.uk)

Posted by Dave Pooser <da...@pooserville.com>.
On 7/5/10 Jul 5, 1:57 AM, "Marc Perkel" <su...@junkemailfilter.com> wrote:

> It's not even useful for white listing as spammers can set up SPF too.

Yes, Marc, but here's the secret to that:
    YOU DON'T WHITELIST THE SPAMMERS!

Ahem. Sorry about that, but since reasoned explanation hasn't been working I
figured yelling might. You see, nobody is suggesting "whitelist_auth *@*" --
that would be stupid. What people ARE saying is that
    whitelist_auth *@mybank.domain
can be a handy tool if mybank.domain has properly configured SPF (or DKIM)
records.

That's it. Not the FUSS, not the ultimate hat-checker. Just a way that I can
make sure legitimate mails from $sender get through while forged messages
pretending to be from $sender don't. This ain't rocket surgery.
-- 
Dave Pooser
Cat-Herder-in-Chief
Pooserville.com



Re: How not to implement SPF (nationwide.co.uk)

Posted by Marc Perkel <su...@junkemailfilter.com>.

On 6/30/2010 2:25 PM, RW wrote:
> On Wed, 30 Jun 2010 20:19:43 +0100
> Ned Slider<ne...@unixmail.co.uk>  wrote:
>
>    
>> so they have no SPF policy? Wrong, they do, but it's on their
>> email.barclays.co.uk subdomain as presumably that's the domain they
>> send mail from - but how are you supposed to know that if they don't
>> tell you?
>>      
> I suppose they are being realistic about spf - that it's only really
> useful for whitelisting purposes.
>
>    

It's not even useful for white listing as spammers can set up SPF too.

-- 
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400


Re: How not to implement SPF (nationwide.co.uk)

Posted by RW <rw...@googlemail.com>.
On Wed, 30 Jun 2010 20:19:43 +0100
Ned Slider <ne...@unixmail.co.uk> wrote:

> so they have no SPF policy? Wrong, they do, but it's on their 
> email.barclays.co.uk subdomain as presumably that's the domain they
> send mail from - but how are you supposed to know that if they don't
> tell you?

I suppose they are being realistic about spf - that it's only really
useful for whitelisting purposes.

Re: How not to implement SPF (nationwide.co.uk)

Posted by Michael Scheidell <sc...@secnap.net>.
On 6/30/10 3:19 PM, Ned Slider wrote:
> ;; ANSWER SECTION:
> email.barclays.co.uk.   3473    IN      TXT     "spf2.0/pra 
> ip4:207.251.70.64/29 ip4:207.251.97.252/31 ip4:63.146.96.192/30 
> ip4:63.146.96.196/31 ip4:207.251.96.0/24 ip4:65.125." "54.0/24 
> ip4:66.165.100.120/29 ip4:208.49.63.128/28 ip4:63.211.90.16/29 -all" 
actually, thats not SPF. :-)

its SENDER-ID
microsoft change the "spf1.0" to "spf2.0" and patented it.

(and they don't use it)
<http://www.openspf.org/SPF_vs_Sender_ID>



-- 
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
 > *| *SECNAP Network Security Corporation

    * Certified SNORT Integrator
    * 2008-9 Hot Company Award Winner, World Executive Alliance
    * Five-Star Partner Program 2009, VARBusiness
    * Best in Email Security,2010: Network Products Guide
    * King of Spam Filters, SC Magazine 2008

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________  

Re: How not to implement SPF (nationwide.co.uk)

Posted by Ned Slider <ne...@unixmail.co.uk>.
On 30/06/10 19:51, Kelson wrote:
> On 6/30/2010 8:37 AM, Ned Slider wrote:
>> My solution is to just filter ALL mail from bank or bank-like domains.
>> The vast majority are phishing anyway with only a few marketing emails
>> (often not from a bank domain) or "your online statement is ready"
>> notifications that I'm sure users can do without.
>
> I wouldn't be so sure that users can do without* those notifications. I
> don't know about the UK, but in the US, banks and utilities are really
> pushing paperless statements. Users might be relying on email from their
> banks to let them know when their credit card bills are ready.
>
>
> *More generally, I don't think it's our place to decide what users can
> and can't do without among email that they've actually requested. False
> positives are one thing. *Deliberately* blocking something on the
> grounds that it's not necessary? That's something else.
>

Yes, apologies, that read badly. Of course I'm not advocating 
intentionally blocking legitimate mail.

In fairness, what I meant to imply is that it's probably easier to 
switch to a default REJECT policy for bank (and bank-like) domains and 
then manually whitelist the genuine stuff than to do it the other way 
around; and that well implemented DKIM/SPF policies on behalf of the 
banks would make that a far easier task. A default policy of ACCEPT no 
longer seems reasonable when 99% of mail claiming to be from bank 
domains is phish.

The situation is further compounded by a lack of clarity from the banks 
surrounding their policies even when they do have one. Take for example, 
Barclays in the UK

$ dig txt barclays.co.uk

;; ANSWER SECTION:
barclays.co.uk.         3526    IN      TXT     "wp-noop://"

so they have no SPF policy? Wrong, they do, but it's on their 
email.barclays.co.uk subdomain as presumably that's the domain they send 
mail from - but how are you supposed to know that if they don't tell you?

$ dig txt email.barclays.co.uk

;; ANSWER SECTION:
email.barclays.co.uk.   3473    IN      TXT     "spf2.0/pra 
ip4:207.251.70.64/29 ip4:207.251.97.252/31 ip4:63.146.96.192/30 
ip4:63.146.96.196/31 ip4:207.251.96.0/24 ip4:65.125." "54.0/24 
ip4:66.165.100.120/29 ip4:208.49.63.128/28 ip4:63.211.90.16/29 -all"

Where on Barclays website does it say we *only* send mail from 
@email.barclays.co.uk and you can safely throw away anything claiming to 
be from @barclays.co.uk? Why not have an SPF policy on barclays.co.uk 
that says this domain doesn't send email (if that's the case)?

IMHO it would be useful to have an up to date list of financial domains 
that do send legitimate mail and their DKIM/SPF policies. Likewise, it 
would be useful to have a list of fake bank-like domains that are 
commonly used for phish (e.g, hsbc-online.co.uk).


Re: How not to implement SPF (nationwide.co.uk)

Posted by Kelson <ke...@speed.net>.
On 6/30/2010 8:37 AM, Ned Slider wrote:
> My solution is to just filter ALL mail from bank or bank-like domains.
> The vast majority are phishing anyway with only a few marketing emails
> (often not from a bank domain) or "your online statement is ready"
> notifications that I'm sure users can do without.

I wouldn't be so sure that users can do without* those notifications.  I 
don't know about the UK, but in the US, banks and utilities are really 
pushing paperless statements.  Users might be relying on email from 
their banks to let them know when their credit card bills are ready.


*More generally, I don't think it's our place to decide what users can 
and can't do without among email that they've actually requested.  False 
positives are one thing.  *Deliberately* blocking something on the 
grounds that it's not necessary?  That's something else.

-- 
Kelson Vibber
SpeedGate Communications - <www.speed.net>

Re: How not to implement SPF (nationwide.co.uk)

Posted by jdow <jd...@earthlink.net>.
From: "Ned Slider" <ne...@unixmail.co.uk>
Sent: Wednesday, 2010/June/30 08:37


>I was a little bit surprised to see a phishing email today from 
> nationwide.co.uk that passed SPF!
> 
> So, upon further investigation we see:
> 
> $ dig txt nationwide.co.uk
> 
> ;; ANSWER SECTION:
> nationwide.co.uk.       5648    IN      TXT     "v=spf1 mx 
> a:mailhost.nationet.com a:mailhost2.nationet.com include:messagelabs.com 
> ~all"
> 
> Great, at least they have an SPF record, but then messagelabs.com lets 
> the side down:
> 
> $ dig txt messagelabs.com
> 
> ;; ANSWER SECTION:
> messagelabs.com.        84771   IN      TXT     "v=spf1 +all"
> 
> 
> So all mail from  nationwide.co.uk will pass SPF. Great. And banks 
> wonder why they get so many phishing emails. Are they really that 
> incompetent or do they just not care?
> 
> I really don't understand why banks don't implement DKIM and/or SPF and 
> make it easier for us to filter phishing emails.
> 
> My solution is to just filter ALL mail from bank or bank-like domains. 
> The vast majority are phishing anyway with only a few marketing emails 
> (often not from a bank domain) or "your online statement is ready" 
> notifications that I'm sure users can do without. Those that do 
> implement DKIM/SPF etc can then be whitelisted.

Filter the banks and have that filter generate a message to the customer
that someone unverifiably claiming to be their bank is trying to send them
email. Include a brief message for them to forward to their bank. That
should get the bank's attention.

{^_^}