You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marc Perkel <su...@junkemailfilter.com> on 2012/08/22 17:22:32 UTC
Rules Needed to verify bank fraud
I'd like to make a suggestion as to how to block a lot of fraud. This
would involve making a list of domains similar to the successful
freemail list plugin. The idea is to block email that spoofs major
institutions such as banks, credit cards, ebay, and other organizations
that want to try to get your password.
So - we start by compiling a list of banks that are often spoofed and
look at the received lines. The idea being that good email from these
institutions will come from host names that either match their domains,
or match the SPF. If it matches it's good - if it doesn't - it's bad.
Of course you also have to look for forged received lines - but that can
be done and in fact can be a rules to detect forgery. For example - if
there's a received line that says wellsfargo.com that is followed by an
IP with no RDNS, that would probably be spam.
We could also trigger rules on any email that is encouraging you to go
somewhere and give up your password. Spammers often try to get access to
your email account so they can spam in your name. Again - legit password
reset emails sould be easily detectable with very good accuracy.
I think these rules would not only be very effective but would really
hit spammers hard. It would make fraud less successful and less
profitable in the case of bank fraud spam. In the case of trying to get
your email password it will also reduce spam in that if people don't get
suckered then the spammers get less email passwords to spoof users, this
will cut them off at the source. So this would be an important step
forward in the fight against spam. I'm hoping that you all get inspired
by this and take on the challenge.
Anyhow - I'm hoping to start a discussion on this in the hope of someone
creating a plugin that will be part of SA.
Here's my initial list of domains to protect:
2checkout.com
2co.com
aa.com
abbey.co.uk
abbey.com
adobe.com
adp.com
aib.ie
amazon.com
americanexpress.com
anz.com
anz.com.au
aplfcu.org
authorize.net
bancorpsouth.com
banknorth.com
bankofamerica.com
bankofoklahoma.com
bankofthewest.com
bankwest.com
bankwest.com.au
banorte.com
barclays.co.uk
bmm.com.au
bmo.com
bofa.com
boh.com
cahoot.co.uk
cahoot.com
capitalone.com
careerbuilder.com
careercantre.com
centralbank.net
charterone.com
charteronebank.com
chase.com
chasebank.com
cibc.ca
citibank.com
citizensbank.com
clearmountainbank.com
commbank.com.au
compassbank.com
csfcu.coop
cu.org
cua.com.au
cuna.org
dhl.com
downeysavings.com
e-gold.com
ebay.co.uk
ebay.com
egg.com
egold.com
eppicard.com
etrade.com
fbi.gov
federalreserve.gov
firstbanks.com
firstdata.com
fleetbank.com
fmb.com
fnb.co.za
halifax-online.co.uk
halifax.co.uk
hsbc.co.uk
hsbc.com
huntington.com
id.apple.com
intl.paypal.com
int.paypal.net
ipaypal.com
irs.gov
iub.com
lasallebank.com
lcnb.com
lloyds.co.uk
lloydstsb.co.uk
mashreqbank.com
mastercard.com
matasano.com
maxfcu.com
mazuma.org
mbna.com
moneygram.com
nab.com.au
nacha.net
nacha.org
nafcu.org
natwest.co.uk
natwest.com
navyfcu.org
ncacu.org
ncua.gov
nwolb.com
orangesavingsbank.com
paypal.com
pvfcu.org
raiffeisen.ro
rbc.com
rbcroyalbank.ca
rbcroyalbank.com
rbs.co.uk
regionsbank.com
royalbank.ca
royalbank.com
royalbankofcanada.com
santander.co.uk
schwab.com
secu.com
security.com
snsbank.nl
southtrust.com
sprint.com
standardbank.co.za
stgeorge.com.au
suncoastfcu.org
suntrust.com
suntrustbank.com
tcfbank.com
td.ca
treas.gov
uboc.com
uc.com
unionplanters.com
usbank.com
visa.com
visa.com.br
vonage.com
wachovia.com
wamu.com
wellsfargo.co.uk
wellsfargo.com
westernunion.com
worldbank.org
8u8.com
adultfriendfinder.com
allstate.com
americangreetings.com
aol.nl
apn.net.au
ato.com.au
blizzard.com
bloomberg.com
citysex.com
craigslist.com
craigslist.org
dhl.com
ebayinc.com
everydayrewards.com.au
fabulous.com
facebook.com
facebookmail.com
fedex.com
flickr.com
friendfinder.com
greetings.com
hallmark.com
hallmark.org
hinet.net
idf.gov.il
linkedin.com
mailout.com
microsoft.com
microsoft.windowslive.com
monster.com
no-ip.org
noreply.com
passport.com
pay.com
pge.com
pse.com
skype.com
swip.net
target.com
teamccm.com
test.com
twitter.com
un.org
ups.com
ups.us
usga.org
vetproductsdirect.com
walgreens.com
wikipedia.org
windowslive.com
yahoo.com.cn
yahoo.com.hk
yahoo.com.in
yahoo.com.uk
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: Rules Needed to verify bank fraud
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 23/08/12 12:08, RW wrote:
> On Thu, 23 Aug 2012 01:33:56 +0100
> Ned Slider wrote:
>
>> # Fedex
>> header __LOCAL_FROM_FEDEX Return-Path:addr
>> =~ /\@fedex\.com$/i meta
>> LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL)&&
>> __LOCAL_FROM_FEDEX) describe LOCAL_SPF_FEDEX
>> Fedex SPF Fail
>>
>> and if I want to make sure all the legit fedex mail gets through I
>> can further whitelist mail from fedex that passes SPF
>>
>> whitelist_from_spf *@fedex.com
>> whitelist_from_spf *@*.fedex.com
>>
>> and that will virtually guarantee all the spam/viruses claiming to be
>> from fedex are blocked and all the legitimate mail from fedex gets
>> through.
>
> Provided that SPF hasn't been broken by email forwarding.
>
If it's a plugin then just disable the plugin (or don't enable the
plugin) on systems that accept mail from forwarders which break SPF.
Re: Rules Needed to verify bank fraud
Posted by RW <rw...@googlemail.com>.
On Thu, 23 Aug 2012 01:33:56 +0100
Ned Slider wrote:
> # Fedex
> header __LOCAL_FROM_FEDEX Return-Path:addr
> =~ /\@fedex\.com$/i meta
> LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) &&
> __LOCAL_FROM_FEDEX) describe LOCAL_SPF_FEDEX
> Fedex SPF Fail
>
> and if I want to make sure all the legit fedex mail gets through I
> can further whitelist mail from fedex that passes SPF
>
> whitelist_from_spf *@fedex.com
> whitelist_from_spf *@*.fedex.com
>
> and that will virtually guarantee all the spam/viruses claiming to be
> from fedex are blocked and all the legitimate mail from fedex gets
> through.
Provided that SPF hasn't been broken by email forwarding.
Re: Rules Needed to verify bank fraud
Posted by Mark Martinec <Ma...@ijs.si>.
> I guess what we are looking for is a plugin that can take a list of
> commonly abused domains known to have valid SPF records or valid DKIM
> signatures, and to be able to apply a (stronger) score to those messages
> that fail the SPF and/or DKIM test.
Several common domains that do provide a DKIM signature
are already handled by 60_adsp_override_dkim.cf
Mark
Re: Rules Needed to verify bank fraud
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
I think the idea has merit. Can you open a bug in bugzilla, please? My
goals are to get some more polish on masscheck and put out a 3.4.0 rc1
and deal with the 3.4.X infrastructure changes. After that I'll offer
to work with you on this if no one steps up by then.
regards,
KAM
Re: Rules Needed to verify bank fraud
Posted by Alexandre Boyer <bi...@gmail.com>.
That's my opinion too.
Therefor the community will have to contribute to the list of which
domain to add or not.
Alex, from osmose.
Bow before me, for I am root.
On 12-08-23 07:20 PM, Jason Haar wrote:
> Great idea - but don't under-estimate the amount of work. Someone
> thought there'd be "only" 20-30 domains to be covered - but I'd say
> that's actually 20-30 domains PER COUNTRY.
>
> Here in New Zealand we get a lot of phishing attacks using New Zealand
> banks - just like you get spam referring to your own country banks.
> However, it appears almost none of the NZ banks have heard of SPF. Of
> the first three I could think of, only one had a SPF record - and it
> looks like they've outsourced email too (I can't believe any financial
> institution would outsource email! Gahhh!)
>
>
Re: Rules Needed to verify bank fraud
Posted by Jason Haar <Ja...@trimble.com>.
Great idea - but don't under-estimate the amount of work. Someone
thought there'd be "only" 20-30 domains to be covered - but I'd say
that's actually 20-30 domains PER COUNTRY.
Here in New Zealand we get a lot of phishing attacks using New Zealand
banks - just like you get spam referring to your own country banks.
However, it appears almost none of the NZ banks have heard of SPF. Of
the first three I could think of, only one had a SPF record - and it
looks like they've outsourced email too (I can't believe any financial
institution would outsource email! Gahhh!)
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Rules Needed to verify bank fraud
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 23/08/12 18:18, Marc Perkel wrote:
> Let's take wellsfargo.com (Wells Fargo Bank) as an example.
>
> If the FCrDNS of the connecting server is *.wellsfargo.com it is ham.
> If wellsfargo.com is in the received lines and not forged it is ham.
> If wellsfargo.com is in the received headers and it is forged it is spam.
> If wellsfargo.com is in the received lines and there are IP in received
> with invalid FCrDNS then it is forged.
> If wellsfargo.com is not in the received headers then it is spam.
>
Aren't you just massively over-complicating something that should be
really simple. Wells Fargo publish an SPF record that will tell you if
it's real or forged and SA already checks that. You really don't need to
look any further. Wells Fargo are telling you with some authority, these
are the IP addresses we authorise to send mail from our domain.
> Most all banks can be detected with 100% accuracy with these rules.
>
> For banks that let 3rd parties send email for them we can add specific
> exceptions including if the SFP lists it, or a list of known 3rd parties
> that pass the bank's email.
>
> Here's why this is important. It hits the fraud community hard. Takes
> the money out. Makes spam less profitable.
>
>
Re: Rules Needed to verify bank fraud
Posted by Marc Perkel <su...@junkemailfilter.com>.
Let's take wellsfargo.com (Wells Fargo Bank) as an example.
If the FCrDNS of the connecting server is *.wellsfargo.com it is ham.
If wellsfargo.com is in the received lines and not forged it is ham.
If wellsfargo.com is in the received headers and it is forged it is spam.
If wellsfargo.com is in the received lines and there are IP in received
with invalid FCrDNS then it is forged.
If wellsfargo.com is not in the received headers then it is spam.
Most all banks can be detected with 100% accuracy with these rules.
For banks that let 3rd parties send email for them we can add specific
exceptions including if the SFP lists it, or a list of known 3rd parties
that pass the bank's email.
Here's why this is important. It hits the fraud community hard. Takes
the money out. Makes spam less profitable.
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: Rules Needed to verify bank fraud
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 23/08/12 04:31, Kevin A. McGrail wrote:
> On 8/22/2012 8:33 PM, Ned Slider wrote:
>> So if I hit all mail claiming to be sent from fedex.com that fails SPF
>> I can easily weed out all the fakes:
>>
>> # Fedex
>> header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
>> meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) && __LOCAL_FROM_FEDEX)
>> describe LOCAL_SPF_FEDEX Fedex SPF Fail
>>
>> and if I want to make sure all the legit fedex mail gets through I can
>> further whitelist mail from fedex that passes SPF
>>
>> whitelist_from_spf *@fedex.com
>> whitelist_from_spf *@*.fedex.com
>>
>> and that will virtually guarantee all the spam/viruses claiming to be
>> from fedex are blocked and all the legitimate mail from fedex gets
>> through. It's no different with banks.
>>
>> However, this approach doesn't scale particularly well. It's OK for 10
>> or 20 domains, but for many more it would be far easier to manage
>> using a plugin.
> So really want you want is a plugin that can take a list of domains that
> we've verified support SPF using -all and make that a stronger score?
>
> Regards,
> KAM
>
I guess what we are looking for is a plugin that can take a list of
commonly abused domains known to have valid SPF records or valid DKIM
signatures, and to be able to apply a (stronger) score to those messages
that fail the SPF and/or DKIM test.
If it were a plugin then those using email forwarding that breaks SPF
and/or DKIM could easily disable the plugin making the system easy to
manage.
IMHO, talking SPF, it doesn't really matter if it's -all or ~all (hard
or soft fail), here SA isn't making a policy judgement but rather
creating a set of rules that differentiate spam from ham, or in this
case attempting to differentiate mail that really is sent from paypal et
al versus that which isn't (I'm struggling for the correct terminology
here as it really isn't spam vs ham as we really don't care if it's
solicited mail or not, just that it's genuinely sent not fraudulently
sent). In much the same way as SA currently scores SPF_NEUTRAL >
SPF_SOFTFAIL > SPF_FAIL which is the logical reverse of what the policy
suggests, but that is what the corpus scoring model says is more effective.
So just as with the above, the plugin rule should look to be a good
indicator of spam/abuse/fraud/phish or whatever you care to call it
versus mail genuinely sent from these domains.
As an example, paypal.com uses ~all, but I'm going to treat that as a
FAIL in SA the same as I would treat -all.
I guess it comes down to looking closely at a list of domains and
deciding if there is evidence:
(a) that they are commonly abused
and
(b) that they have an SPF and/or DKIM policy that we can leverage to
differentiate legitimate mail from abuse
at which point they would make a suitable candidate for inclusion on the
plugins list of domains.
Re: Rules Needed to verify bank fraud
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
Well i can help with a plugin to automate things but i can only automate something once it is done a few times. Have you written the rules you think will help for say two of the domain's?
Have you collected example ham and spam?
You have a good idea but without specifics, i don't know the pattern we are looking for that matches this subset of domains.
Regards,
KAM
Marc Perkel <su...@junkemailfilter.com> wrote:
On 8/22/2012 8:31 PM, Kevin A. McGrail wrote:
> On 8/22/2012 8:33 PM, Ned Slider wrote:
>> So if I hit all mail claiming to be sent from fedex.com that fails
>> SPF I can easily weed out all the fakes:
>>
>> # Fedex
>> header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
>> meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) &&
>> __LOCAL_FROM_FEDEX)
>> describe LOCAL_SPF_FEDEX Fedex SPF Fail
>>
>> and if I want to make sure all the legit fedex mail gets through I
>> can further whitelist mail from fedex that passes SPF
>>
>> whitelist_from_spf *@fedex.com
>> whitelist_from_spf *@*.fedex.com
>>
>> and that will virtually guarantee all the spam/viruses claiming to be
>> from fedex are blocked and all the legitimate mail from fedex gets
>> through. It's no different with banks.
>>
>> However, this approach doesn't scale particularly well. It's OK for
>> 10 or 20 domains, but for many more it would be far easier to manage
>> using a plugin.
> So really want you want is a plugin that can take a list of domains
> that we've verified support SPF using -all and make that a stronger
> score?
>
> Regards,
> KAM
>
>
>
My idea it to take a list of the most spoofed domains and create rules
around them so that we can be 100% accurate on blocking and passing
those specific domains. Most of these domains should be easy to detect
once we know where they send legitimate email from. This would be a
devastating blow to spammers.
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: Rules Needed to verify bank fraud
Posted by Marc Perkel <su...@junkemailfilter.com>.
On 8/22/2012 8:31 PM, Kevin A. McGrail wrote:
> On 8/22/2012 8:33 PM, Ned Slider wrote:
>> So if I hit all mail claiming to be sent from fedex.com that fails
>> SPF I can easily weed out all the fakes:
>>
>> # Fedex
>> header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
>> meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) &&
>> __LOCAL_FROM_FEDEX)
>> describe LOCAL_SPF_FEDEX Fedex SPF Fail
>>
>> and if I want to make sure all the legit fedex mail gets through I
>> can further whitelist mail from fedex that passes SPF
>>
>> whitelist_from_spf *@fedex.com
>> whitelist_from_spf *@*.fedex.com
>>
>> and that will virtually guarantee all the spam/viruses claiming to be
>> from fedex are blocked and all the legitimate mail from fedex gets
>> through. It's no different with banks.
>>
>> However, this approach doesn't scale particularly well. It's OK for
>> 10 or 20 domains, but for many more it would be far easier to manage
>> using a plugin.
> So really want you want is a plugin that can take a list of domains
> that we've verified support SPF using -all and make that a stronger
> score?
>
> Regards,
> KAM
>
>
>
My idea it to take a list of the most spoofed domains and create rules
around them so that we can be 100% accurate on blocking and passing
those specific domains. Most of these domains should be easy to detect
once we know where they send legitimate email from. This would be a
devastating blow to spammers.
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: Rules Needed to verify bank fraud
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 8/22/2012 8:33 PM, Ned Slider wrote:
> So if I hit all mail claiming to be sent from fedex.com that fails SPF
> I can easily weed out all the fakes:
>
> # Fedex
> header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
> meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) &&
> __LOCAL_FROM_FEDEX)
> describe LOCAL_SPF_FEDEX Fedex SPF Fail
>
> and if I want to make sure all the legit fedex mail gets through I can
> further whitelist mail from fedex that passes SPF
>
> whitelist_from_spf *@fedex.com
> whitelist_from_spf *@*.fedex.com
>
> and that will virtually guarantee all the spam/viruses claiming to be
> from fedex are blocked and all the legitimate mail from fedex gets
> through. It's no different with banks.
>
> However, this approach doesn't scale particularly well. It's OK for 10
> or 20 domains, but for many more it would be far easier to manage
> using a plugin.
So really want you want is a plugin that can take a list of domains that
we've verified support SPF using -all and make that a stronger score?
Regards,
KAM
Re: Rules Needed to verify bank fraud
Posted by John Hardin <jh...@impsec.org>.
On Thu, 23 Aug 2012, Ned Slider wrote:
> So if I hit all mail claiming to be sent from fedex.com that fails SPF I
> can easily weed out all the fakes:
>
> # Fedex
> header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
> meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) && __LOCAL_FROM_FEDEX)
> describe LOCAL_SPF_FEDEX Fedex SPF Fail
>
> and if I want to make sure all the legit fedex mail gets through I can
> further whitelist mail from fedex that passes SPF
>
> whitelist_from_spf *@fedex.com
> whitelist_from_spf *@*.fedex.com
See also from less than a year ago:
http://spamassassin.1065346.n5.nabble.com/Blacklisting-based-on-SPF-td46063.html
As suggested there:
blacklist_from *@fedex.com
whitelist_from_spf *@fedex.com
blacklist_from *@*fedex.com
whitelist_from_spf *@*fedex.com
...which gives a neutral score to legitimate fedex.com mail.
Maybe we need a builtin primitive for the above to add five points or so
(greylist?) rather than ending up neutral:
blacklist_from_spf_fail *@fedex.com
blacklist_from_spf_fail *@*.fedex.com
--
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
-----------------------------------------------------------------------
One difference between a liberal and a pickpocket is that if you
demand your money back from a pickpocket he will not question your
motives. -- William Rusher
-----------------------------------------------------------------------
2 days until the 1933rd anniversary of the destruction of Pompeii
Re: Rules Needed to verify bank fraud
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 23/08/12 00:07, RW wrote:
> On Wed, 22 Aug 2012 17:40:23 +0100
> Ned Slider wrote:
>
>> On 22/08/12 16:22, Marc Perkel wrote:
>>> I'd like to make a suggestion as to how to block a lot of fraud.
>>> This would involve making a list of domains similar to the
>>> successful freemail list plugin. The idea is to block email that
>>> spoofs major institutions such as banks, credit cards, ebay, and
>>> other organizations that want to try to get your password.
>>>
>>> So - we start by compiling a list of banks that are often spoofed
>>> and look at the received lines. The idea being that good email from
>>> these institutions will come from host names that either match
>>> their domains, or match the SPF. If it matches it's good - if it
>>> doesn't - it's bad.
>>>
>>
>> I've already done it and I can confirm it works brilliantly.
>>
>> By default I score mail from all such domains with an arbitrary high
>> score which will cause them to be tagged as spam (say 8 points) and
>> then whitelist them with SPF and/or DKIM which negates the above
>> score allowing legitimate mail to pass untagged.
>>
>> If commonly forged/spoofed/phished domains don't use SPF or DKIM then
>> I have little sympathy for them and it makes it harder for us to help
>> them.
>
> My bank outsources it's email to a email marketing company. I think
> this sort of thing is quite common. The received header has nothing to
> do with the the bank. It passes spf, but the domain is not one it
> uses for anything else.
>
But mail from the bank should still be sent using one of their own
domains (envelope from address) regardless of who is responsible for
handing the delivery. In this case the bank should set up an SPF record
on their domain that includes IP address/range of the email marketing
company responsible for delivery.
This is exactly what SPF is intended for. The fact mail bight be
delivered by a 3rd party marketing company is completely irrelevant.
If mail claiming to be from "my bank" passes SPF (or DKIM) then there is
a good chance it was actually sent by them. If it fails SPF (or DKIM)
then you should assume that it's not really from them (although
unfortunately it seems even some banks have a hard time getting SPF right).
> Lots of spam passes SPF, so this sounds fairly limited to me.
>
This is *not* what SPF is intended for.
We are not proposing testing all mail with SPF/DKIM, only mail claiming
to be from those domains that are regularly the targets of
fraud/phish/spoofing. Probably only 20-50 domains max I'd guess.
Take a recent example, and not even one that's banking related. My
spamtraps are currently inundated with spam claiming to be from fedex
with an attachment (virus) for me to open about a parcel delivery. A
common scam for sure.
Now without even knowing what a valid email from fedex looks like I can
see fedex.com has an SPF record:
$ dig txt fedex.com
;; ANSWER SECTION:
fedex.com. 10658 IN TXT "v=spf1
redirect=_spf.infosec.fedex.com"
So if I hit all mail claiming to be sent from fedex.com that fails SPF I
can easily weed out all the fakes:
# Fedex
header __LOCAL_FROM_FEDEX Return-Path:addr =~ /\@fedex\.com$/i
meta LOCAL_SPF_FEDEX ((SPF_SOFTFAIL || SPF_FAIL) && __LOCAL_FROM_FEDEX)
describe LOCAL_SPF_FEDEX Fedex SPF Fail
and if I want to make sure all the legit fedex mail gets through I can
further whitelist mail from fedex that passes SPF
whitelist_from_spf *@fedex.com
whitelist_from_spf *@*.fedex.com
and that will virtually guarantee all the spam/viruses claiming to be
from fedex are blocked and all the legitimate mail from fedex gets
through. It's no different with banks.
However, this approach doesn't scale particularly well. It's OK for 10
or 20 domains, but for many more it would be far easier to manage using
a plugin.
Re: Rules Needed to verify bank fraud
Posted by Greg Troxel <gd...@ir.bbn.com>.
RW <rw...@googlemail.com> writes:
> My bank outsources it's email to a email marketing company. I think
> this sort of thing is quite common. The received header has nothing to
> do with the the bank. It passes spf, but the domain is not one it
> uses for anything else.
I think the point is that if we know that bank X outsources to email
company Y, we can encode that in a database, and mail that claims to be
From X but isn't from Y is suspicious. Essentially a lookaside version
of DKIM.
Re: Rules Needed to verify bank fraud
Posted by RW <rw...@googlemail.com>.
On Wed, 22 Aug 2012 17:40:23 +0100
Ned Slider wrote:
> On 22/08/12 16:22, Marc Perkel wrote:
> > I'd like to make a suggestion as to how to block a lot of fraud.
> > This would involve making a list of domains similar to the
> > successful freemail list plugin. The idea is to block email that
> > spoofs major institutions such as banks, credit cards, ebay, and
> > other organizations that want to try to get your password.
> >
> > So - we start by compiling a list of banks that are often spoofed
> > and look at the received lines. The idea being that good email from
> > these institutions will come from host names that either match
> > their domains, or match the SPF. If it matches it's good - if it
> > doesn't - it's bad.
> >
>
> I've already done it and I can confirm it works brilliantly.
>
> By default I score mail from all such domains with an arbitrary high
> score which will cause them to be tagged as spam (say 8 points) and
> then whitelist them with SPF and/or DKIM which negates the above
> score allowing legitimate mail to pass untagged.
>
> If commonly forged/spoofed/phished domains don't use SPF or DKIM then
> I have little sympathy for them and it makes it harder for us to help
> them.
My bank outsources it's email to a email marketing company. I think
this sort of thing is quite common. The received header has nothing to
do with the the bank. It passes spf, but the domain is not one it
uses for anything else.
Lots of spam passes SPF, so this sounds fairly limited to me.
Re: Rules Needed to verify bank fraud
Posted by Alexandre Boyer <bi...@gmail.com>.
Yep, you are damn right. I work in a company where I maintain a list for
canadian banks and more. It's a pain, but it's effective.
Should a few responsible of us contribute, it would greatly help.
Alex, from osmose.
Bow before me, for I am root.
On 12-08-24 02:03 PM, Matt Garretson wrote:
> In my experience, banks and financial institutions tend to be among the
> worst offenders against sane bulk mailing practices. SPF or DKIM will
> be broken or inconsistently applied, and sender/relay domains seem to
> vary with the weather. I think it will be tough to nail down all the
> valid domains a bank might use to contact its clients. You'd think that
> banks would care enough to do things right, but in many cases they
> really seem not to.
>
> The general technique proposed is effective, but I think that trying to
> create and maintain a list like this for more than a handful of banks
> will be a hassle at best, and will be highly prone to false positives.
>
> It might still be worth trying, but I just wanted to vent my pessimism. :)
>
Re: Rules Needed to verify bank fraud
Posted by Matt Garretson <ma...@assembly.state.ny.us>.
In my experience, banks and financial institutions tend to be among the
worst offenders against sane bulk mailing practices. SPF or DKIM will
be broken or inconsistently applied, and sender/relay domains seem to
vary with the weather. I think it will be tough to nail down all the
valid domains a bank might use to contact its clients. You'd think that
banks would care enough to do things right, but in many cases they
really seem not to.
The general technique proposed is effective, but I think that trying to
create and maintain a list like this for more than a handful of banks
will be a hassle at best, and will be highly prone to false positives.
It might still be worth trying, but I just wanted to vent my pessimism. :)
Re: Rules Needed to verify bank fraud
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 22/08/12 16:22, Marc Perkel wrote:
> I'd like to make a suggestion as to how to block a lot of fraud. This
> would involve making a list of domains similar to the successful
> freemail list plugin. The idea is to block email that spoofs major
> institutions such as banks, credit cards, ebay, and other organizations
> that want to try to get your password.
>
> So - we start by compiling a list of banks that are often spoofed and
> look at the received lines. The idea being that good email from these
> institutions will come from host names that either match their domains,
> or match the SPF. If it matches it's good - if it doesn't - it's bad.
>
I've already done it and I can confirm it works brilliantly.
By default I score mail from all such domains with an arbitrary high
score which will cause them to be tagged as spam (say 8 points) and then
whitelist them with SPF and/or DKIM which negates the above score
allowing legitimate mail to pass untagged.
If commonly forged/spoofed/phished domains don't use SPF or DKIM then I
have little sympathy for them and it makes it harder for us to help them.
For me the hardest thing was collating accurate information for which
domains use SPF and or DKIM, especially for domains where you don't see
any legitimate mail. I'm happy to share what I have.
I have previously suggested on this list using a plugin similar to
freemail for such usage but no one has run with it. I'd do it but
unfortunately my perl skills are not up to the task so my implementation
is simply based on a cobbled together set of SA rules.
...and it doesn't even need to be rocket science - you'd be amazed how
well this rule works on my mail flow:
header FROM_CONTAINS_BANK From =~ /\bbank(?:ing)?\b/i
describe FROM_CONTAINS_BANK From contains bank