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 Jones <dj...@ena.com> on 2018/01/17 19:31:39 UTC
From name containing a spoofed email address
Would a plugin need to be created (or an existing one enhanced) to be
able to detect this type of spoofed From header?
From: "hulu@hulumail.com !" <la...@hotmail.com>
https://pastebin.com/vVhGjC8H
Does anyone else think this would be a good idea to make a rule that at
least checks both the From:name and From:addr to see if there is an
email address in the From:name and if the domain is different add some
points?
We are seeing more and more of this now that SPF, DKIM, and DMARC are
making it harder to spoof common/major brands that have properly
implemented some or all of them.
--
David Jones
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
I swear I came across a rule like this just the other day, but now I
can't find it, which is probably a sign of faulty memory. In any
case, the existing HeaderEval Plugin seems like a good place for this
(it already does a check for EnvFrom and From domain mismatches).
On Wed, 17 Jan 2018, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to be able to
> detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at least
> checks both the From:name and From:addr to see if there is an email address
> in the From:name and if the domain is different add some points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are making
> it harder to spoof common/major brands that have properly implemented some or
> all of them.
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Danger of using your real name (was Re: From name containing a
spoofed email address)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Sat, 20 Jan 2018 00:33:32 -0500
"Bill Cole" <sa...@billmail.scconsult.com> wrote:
> On 19 Jan 2018, at 20:02 (-0500), jdow wrote:
> > After your first time being a victim of cyberstalking you'll soon
> > enough wish your "from" line was as generic as mine. People who put
> > their full name in the From: line haven't been mugged yet. I spent
> > a year learning about this 1985-1986.
Wow, that's awful!
[snip]
> OTOH, if I were a woman or looked less like a biker-bar bouncer or
> had a history I'd rather not have widely known, I'd almost surely
> evaluate my risk differently. This is a hard problem that no one has
> yet solved.
One minute of googling "dfs@roaringpenguin.com" will produce a lot
of information including the fact that I'm a member of a fairly
vulnerable group. The info is out there, so at this point I've
stopped worrying about it. The good news is that I do not live in the
United States, whereas most of the people I provoke online do :), so I
have some physical distance to protect me.
> > As a byproduct of this habit of mine, when I see a "To: John" or
> > other name than mine it's automatically spam, especially when it
> > cannot even get the gender right.
Yeah, "Dear Dfs," is a dead giveaway for me.
Regards,
Dianne.
Re: From name containing a spoofed email address
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Jan 2018, at 20:02 (-0500), jdow wrote:
> After your first time being a victim of cyberstalking you'll soon
> enough wish your "from" line was as generic as mine. People who put
> their full name in the From: line haven't been mugged yet. I spent a
> year learning about this 1985-1986.
I think that's variable. I had issues 95-97 with both a herd of Usenet
kooks and the Church of Scientology (for my small role in defending
a.r.s) that included in-person confrontations but I didn't then drop nor
have I since dropped the use of my real name online, (with a partial
exception during my divorce when I reverted to my birth surname before
it was official) despite an attenuated but never really dead trickle of
net-originated hostility for 20+ years. I think one's individual
vulnerabilities make a huge difference, as there are threats that would
literally be laughable to me which would be legitimately and justifiably
terrifying to others. The worst I got was 2 visits from CPS in response
to anonymous 'tips' of child abuse and a threat of a beating from a man
who actually showed up at my door but didn't stay long enough for any
substantive interaction after he made a snap judgement of his
prospects...
OTOH, if I were a woman or looked less like a biker-bar bouncer or had a
history I'd rather not have widely known, I'd almost surely evaluate my
risk differently. This is a hard problem that no one has yet solved.
> As a byproduct of this habit of mine, when I see a "To: John" or other
> name than mine it's automatically spam, especially when it cannot even
> get the gender right.
That can be useful even without a nym in the From header, although it is
helpful to have a tricky name. e.g. no one has ever called me "Willy"
except for a few spammers.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: From name containing a spoofed email address
Posted by jdow <jd...@earthlink.net>.
After your first time being a victim of cyberstalking you'll soon enough wish
your "from" line was as generic as mine. People who put their full name in the
From: line haven't been mugged yet. I spent a year learning about this 1985-1986.
As a byproduct of this habit of mine, when I see a "To: John" or other name than
mine it's automatically spam, especially when it cannot even get the gender right.
{^_-}
On 2018-01-19 08:10, shanew@shanew.net wrote:
> I've got a basic plugin written for this now, but I'd like to do a
> litle more testing before I make it widely available. If you have
> mail samples (ham or spam) with an "@" character in the name part of
> the From field that you're willing to share, let me know.
>
> BTW, I've already run into some false-positive situations, the most
> common being things from yahoogroups, which apparently writes the
> "true" sender address in the name part of From (they also dkim sign,
> so not too hard to work around). I started trying to handle these in
> the plugin itself, but I'm beginning to think these would be better as
> separate rules and then combined as metas to mitigate the actual
> mismatch score.
>
>
> On Wed, 17 Jan 2018, David Jones wrote:
>
>> Would a plugin need to be created (or an existing one enhanced) to be able to
>> detect this type of spoofed From header?
>>
>> From: "hulu@hulumail.com !" <la...@hotmail.com>
>>
>> https://pastebin.com/vVhGjC8H
>>
>> Does anyone else think this would be a good idea to make a rule that at least
>> checks both the From:name and From:addr to see if there is an email address in
>> the From:name and if the domain is different add some points?
>>
>> We are seeing more and more of this now that SPF, DKIM, and DMARC are making
>> it harder to spoof common/major brands that have properly implemented some or
>> all of them.
>>
>>
>
Re: From name containing a spoofed email address
Posted by Paul Stead <pa...@zeninternet.co.uk>.
NOTE: as always, this is testing software - use at your own risk!
I've a bug report open for this particular feature - if added then it would allow for all sorts of addrlists to be built - https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7354
For now, by all means you can either
* create "high profile" detections so you can add further meta rules
* group similar "owners" together
The tags created from the plugin could also be used with askdns to determine "high profile" spoofed from domains and add score accordingly
askdns __FNS_HIGHPROFILE _FNSFNAMEDOMAIN_.some.reputationlist.com A /^127\.0\.0\.1$/
Paul
On 22/01/2018, 21:32, "Alex" <my...@gmail.com> wrote:
fns_add_addrlist (HP_EBAY) *@ebay.com
fns_add_addrlist (HP_PAYPAL) *@paypal.com
fns_add_addrlist (GMAIL) *@gmail.com *@googlemail.com
amazon, banks, western union, etc?
--
Paul Stead
Senior Engineer (Tools & Technology)
Zen Internet
Direct: 01706 902018
Web: zen.co.uk
Winner of 'Services Company of the Year' at the UK IT Industry Awards
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by Alex <my...@gmail.com>.
On Mon, Jan 22, 2018 at 4:06 PM, Paul Stead
<pa...@zeninternet.co.uk> wrote:
> Thanks for that Alex, I've added a version check into the code, hopefully it'll catch everything.
>
> Thanks for other feedback from other users (
Looking good so far. I'll follow up with examples as they hit. Is
there anything further that needs to be done in terms of configuring?
Does the fns_add_addrlist need to be populated further?
fns_add_addrlist (HP_EBAY) *@ebay.com
fns_add_addrlist (HP_PAYPAL) *@paypal.com
fns_add_addrlist (GMAIL) *@gmail.com *@googlemail.com
amazon, banks, western union, etc?
Thanks,
Alex
>
> Paul
>
> On 22/01/2018, 19:18, "Alex" <my...@gmail.com> wrote:
>
> On Mon, Jan 22, 2018 at 11:21 AM, Paul Stead
> <pa...@zeninternet.co.uk> wrote:
> > https://github.com/fmbla/spamassassin-fromnamespoof
> >
> > Reduced quite a few of the FPs after thinking about this over the weekend - feel free to check this out, let me know any feedback
>
> I'm using the current 3.4.2 svn - looks like Util was replaced with
> RegistryBoundaries?
>
> Jan 22 14:13:45 mail01 amavis[21672]: (21672-04) _WARN: rules: failed
> to run __PLUGIN_FROMNAME_EQUALS_TO test, skipping:\n\t(Undefined
> subroutine &Mail::SpamAssassin::Util::uri_to_domain called at
> /etc/mail/spamassassin/Fromnamespoof.pm line 184.\n)
>
> # grep uri_to_domain /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm
> ## DEPRECATED FUNCTION, sub uri_to_domain removed.
> ## Replaced with Mail::SpamAssassin::RegistryBoundaries::uri_to_domain.
>
>
>
>
> --
> Paul Stead
> Senior Engineer (Tools & Technology)
> Zen Internet
> Direct: 01706 902018
> Web: zen.co.uk
>
> Winner of 'Services Company of the Year' at the UK IT Industry Awards
>
> This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
>
> Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
>
> Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Thanks for that Alex, I've added a version check into the code, hopefully it'll catch everything.
Thanks for other feedback from other users (
Paul
On 22/01/2018, 19:18, "Alex" <my...@gmail.com> wrote:
On Mon, Jan 22, 2018 at 11:21 AM, Paul Stead
<pa...@zeninternet.co.uk> wrote:
> https://github.com/fmbla/spamassassin-fromnamespoof
>
> Reduced quite a few of the FPs after thinking about this over the weekend - feel free to check this out, let me know any feedback
I'm using the current 3.4.2 svn - looks like Util was replaced with
RegistryBoundaries?
Jan 22 14:13:45 mail01 amavis[21672]: (21672-04) _WARN: rules: failed
to run __PLUGIN_FROMNAME_EQUALS_TO test, skipping:\n\t(Undefined
subroutine &Mail::SpamAssassin::Util::uri_to_domain called at
/etc/mail/spamassassin/Fromnamespoof.pm line 184.\n)
# grep uri_to_domain /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm
## DEPRECATED FUNCTION, sub uri_to_domain removed.
## Replaced with Mail::SpamAssassin::RegistryBoundaries::uri_to_domain.
--
Paul Stead
Senior Engineer (Tools & Technology)
Zen Internet
Direct: 01706 902018
Web: zen.co.uk
Winner of 'Services Company of the Year' at the UK IT Industry Awards
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by Alex <my...@gmail.com>.
On Mon, Jan 22, 2018 at 11:21 AM, Paul Stead
<pa...@zeninternet.co.uk> wrote:
> https://github.com/fmbla/spamassassin-fromnamespoof
>
> Reduced quite a few of the FPs after thinking about this over the weekend - feel free to check this out, let me know any feedback
I'm using the current 3.4.2 svn - looks like Util was replaced with
RegistryBoundaries?
Jan 22 14:13:45 mail01 amavis[21672]: (21672-04) _WARN: rules: failed
to run __PLUGIN_FROMNAME_EQUALS_TO test, skipping:\n\t(Undefined
subroutine &Mail::SpamAssassin::Util::uri_to_domain called at
/etc/mail/spamassassin/Fromnamespoof.pm line 184.\n)
# grep uri_to_domain /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm
## DEPRECATED FUNCTION, sub uri_to_domain removed.
## Replaced with Mail::SpamAssassin::RegistryBoundaries::uri_to_domain.
>
> Paul
>
> On 19/01/2018, 18:16, "Paul Stead" <pa...@zeninternet.co.uk> wrote:
>
> I too have a plugin written I've been using for a short while from the last time this was brought up, I too would like to get some spamples of spoofed From:name emails.
>
> There are a few FP situations, I get around these by seeing what the difference in between the length of the found email address in From:name and the length of From:name overall.
>
> If anyone is willing to test or provide examples please contact offlist
>
> Paul
>
>
> --
> Paul Stead
> Senior Engineer (Tools & Technology)
> Zen Internet
> Direct: 01706 902018
> Web: zen.co.uk
>
> Winner of 'Services Company of the Year' at the UK IT Industry Awards
>
> This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
>
> Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
>
> Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by Paul Stead <pa...@zeninternet.co.uk>.
https://github.com/fmbla/spamassassin-fromnamespoof
Reduced quite a few of the FPs after thinking about this over the weekend - feel free to check this out, let me know any feedback
Paul
On 19/01/2018, 18:16, "Paul Stead" <pa...@zeninternet.co.uk> wrote:
I too have a plugin written I've been using for a short while from the last time this was brought up, I too would like to get some spamples of spoofed From:name emails.
There are a few FP situations, I get around these by seeing what the difference in between the length of the found email address in From:name and the length of From:name overall.
If anyone is willing to test or provide examples please contact offlist
Paul
--
Paul Stead
Senior Engineer (Tools & Technology)
Zen Internet
Direct: 01706 902018
Web: zen.co.uk
Winner of 'Services Company of the Year' at the UK IT Industry Awards
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by Paul Stead <pa...@zeninternet.co.uk>.
I too have a plugin written I've been using for a short while from the last time this was brought up, I too would like to get some spamples of spoofed From:name emails.
There are a few FP situations, I get around these by seeing what the difference in between the length of the found email address in From:name and the length of From:name overall.
If anyone is willing to test or provide examples please contact offlist
Paul
On 19/01/2018, 16:10, "shanew@shanew.net" <sh...@shanew.net> wrote:
I've got a basic plugin written for this now, but I'd like to do a
litle more testing before I make it widely available. If you have
mail samples (ham or spam) with an "@" character in the name part of
the From field that you're willing to share, let me know.
BTW, I've already run into some false-positive situations, the most
common being things from yahoogroups, which apparently writes the
"true" sender address in the name part of From (they also dkim sign,
so not too hard to work around). I started trying to handle these in
the plugin itself, but I'm beginning to think these would be better as
separate rules and then combined as metas to mitigate the actual
mismatch score.
On Wed, 17 Jan 2018, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to be able to
> detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at least
> checks both the From:name and From:addr to see if there is an email address
> in the From:name and if the domain is different add some points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are making
> it harder to spoof common/major brands that have properly implemented some or
> all of them.
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
--
Paul Stead
Senior Engineer (Tools & Technology)
Zen Internet
Direct: 01706 902018
Web: zen.co.uk
Winner of 'Services Company of the Year' at the UK IT Industry Awards
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
I've got a basic plugin written for this now, but I'd like to do a
litle more testing before I make it widely available. If you have
mail samples (ham or spam) with an "@" character in the name part of
the From field that you're willing to share, let me know.
BTW, I've already run into some false-positive situations, the most
common being things from yahoogroups, which apparently writes the
"true" sender address in the name part of From (they also dkim sign,
so not too hard to work around). I started trying to handle these in
the plugin itself, but I'm beginning to think these would be better as
separate rules and then combined as metas to mitigate the actual
mismatch score.
On Wed, 17 Jan 2018, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to be able to
> detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at least
> checks both the From:name and From:addr to see if there is an email address
> in the From:name and if the domain is different add some points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are making
> it harder to spoof common/major brands that have properly implemented some or
> all of them.
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
On Wed, 2018-01-17 at 13:31 -0600, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to
> be
> able to detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that
> at
> least checks both the From:name and From:addr to see if there is an
> email address in the From:name and if the domain is different add
> some
> points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC
> are
> making it harder to spoof common/major brands that have properly
> implemented some or all of them.
I've been testing this:
header __LOCAL_CRAZY_MULTI_ATS From =~ /.*\@.*\@.*\@/
header __LOCAL_MULTI_ATS From =~ /.*\@.*\..*["\s].*\@[a-zA-Z0-9\-
]+\.[a-zA-Z0-9\-]+/
header __LOCAL_MULTI_ATS_SAME_DOMAIN From =~ /.*\@([a-zA-Z0-9\.\-
]+\.[a-zA-Z0-9\.\-]+).+\@\1[^a-zA-Z0-9\.\-]/i
meta LOCAL_FORGED_DISPLAY_DOMAIN ( __LOCAL_CRAZY_MULTI_ATS || (
__LOCAL_MULTI_ATS && ! __LOCAL_MULTI_ATS_SAME_DOMAIN ) )
describe LOCAL_FORGED_DISPLAY_DOMAIN From header appears to have a
forged domain in part of the address
... which tries to see if there are two @domain.names in the From and
score if they aren't the same domain.
I doubt it's usable yet, and I don't have the mail volume to look for
all the ways it breaks, but it's a start. I would appreciate tweaks.
Re: From name containing a spoofed email address
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
Yes, I think it's a security risk and numerous phishing scams use this.
On 1/17/2018 2:31 PM, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to be
> able to detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that
> at least checks both the From:name and From:addr to see if there is an
> email address in the From:name and if the domain is different add some
> points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are
> making it harder to spoof common/major brands that have properly
> implemented some or all of them.
>
Re: From name containing a spoofed email address
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Jan 2018, at 16:17 (-0500), Chip wrote:
> Do you mean don't whitelist_auth *@example.com *unless* they have
> published spf/dkim?
I can't speak to Dave's meaning (although I value it...) but in fact
whitelist_auth directives only have any effect if the domain has
published SPF or DKIM records (and in the latter case, signs mail.)
Having those directives is harmless if they don't support one of those
authentication mechanisms.
> Certainly paypal and chase (your examples where you would use
> whitelist_auth) have real human users. . .
Nope.
OK, so I don't know about those SPECIFIC domains but in general, major
consumer-facing brand holders are usually smart enough (or hire ESPs
smart enough...) to keep their humans and their non-human bulk senders
segregated by domain and relevant authentication mechanisms. For
example, a decade ago I had personally specific addresses directly under
the audiusa.com and vw.com domains but neither of those domains had ANY
bulk sender addresses except in subdomains and those subdomains shared
NO authentication mechanisms with the base domains that had human users.
PayPal and Chase may have stupider admins & governance today than VWoA
had a decade ago, but I doubt that.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: From name containing a spoofed email address
Posted by David Jones <dj...@ena.com>.
On 01/19/2018 03:17 PM, Chip wrote:
> Okay, trying to understand.
>
> You say:
>
> whitelist_auth *@*.chase.com
> whitelist_auth service@paypal.com
> This would trust emails from any subdomain under chase.com and
> service@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
>
>
> Okay, got that.
>
> But I'm confused when you further explain:
>
> Assuming that real human users with passwords that can be
> compromised are using *@example.com, you would never want to add
> "whitelist_auth *@example.com" except for very specific reasons.
> Example.com should have proper SPF and/or DKIM and the domain
> ownership be verified to be who you think it really is. Then create
> rules and train your Bayes DB for all other variations of these
> major brands and companies to add points and block the spoofing.
>
>
> Do you mean don't whitelist_auth *@example.com *unless* they have
> published spf/dkim?
>
> Certainly paypal and chase (your examples where you would use
> whitelist_auth) have real human users. . .
>
> Thanks in advance for clarifying.
>
Human users would be @chase.com not on a subdomain like
@alertsp.chase.com. It's becoming common practice to use a subdomain
for mass mailings, third-party senders, and automated mailings with
their own SPF and DKIM settings. This is good for us to separate out
the potential compromised accounts from system generated mass mailings
that can be trusted.
For example, we use clickdimensions.ena.com and "delegate" that
subdomain to marketing emails and customer communications from
ClickDimensions.com. There are no human senders sending from that
subdomain so the SPF and DKIM are very specific for ClickDimensions.com
to use. It would be safe to add "whitelist_auth *@*.ena.com" if one
wanted to. You could be absolutely sure that any emails from that
sender would be from my company and if there are any problems, report
them to our abuse mailbox and I would handle it.
>
> On 01/19/2018 03:59 PM, David Jones wrote:
>> On 01/19/2018 02:21 PM, Jeffs Chips wrote:
>>> I would be very interested in knowing what features in SA flag
>>> spoofed email addresses. Knowing the methods used or plugins
>>> available to detect spoofed emails is integral to the project I'm
>>> working on.
>>>
>>
>> That is the million dollar question. If we had a solid way to detect
>> spoofing then the spoofing problem would not exist any more. It's a
>> combination of sending IP reputation (RBLs), authorization (SPF), and
>> authentication (DKIM), and content. These are the main categories of
>> rules which all have to be balanced carefully to accurately detect
>> spam without FPs.
>>
>> The major brands and company names are commonly used in spoofing like
>> Dropbox, Paypal, Bank of America (and other banks), etc. I just got
>> one a few hours ago spoofing LinkedIn.
>>
>> The technique that I have found to work requires these major brands
>> and companies to have properly implemented SPF and/or DKIM usually on
>> a subdomain like alertsp.chase.com or a dedicated email address like
>> service@paypal.com. Then you add an entry like this:
>>
>> whitelist_auth *@*.chase.com
>> whitelist_auth service@paypal.com
>>
>> (No need to add those entries since they are in the default rulesets
>> already.)
>>
>> This would trust emails from any subdomain under chase.com and
>> service@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
>>
>> Assuming that real human users with passwords that can be compromised
>> are using *@example.com, you would never want to add "whitelist_auth
>> *@example.com" except for very specific reasons. Example.com should
>> have proper SPF and/or DKIM and the domain ownership be verified to be
>> who you think it really is. Then create rules and train your Bayes DB
>> for all other variations of these major brands and companies to add
>> points and block the spoofing.
>>
>> If you look at my ena.com, we have DMARC setup with p=reject. This is
>> just about the best thing that we have today to prevent spoofing of
>> ena.com. As more an more major brands and companies wanting to
>> protect their brands and reputation implement DMARC p=reject, we can
>> use this information to block even more spoofing. Of course my domain
>> is not a target of spoofing since we are a small company.
>>
>> Today DMARC support for SA requires setting up OpenDMARC at the MTA
>> (i.e. Postfix) and then adding custom rules to act on those headers.
>> For example, I add a number of points when the sending domain has
>> p=reject and DMARC fails.
>>
>> FYI, there are a huge number of broken SPF records out there. Thanks
>> to Microsoft telling everyone to create brand new SPF records with
>> "-all" without knowing all sources of their email, a lot of legit
>> emails fail SPF checks with the standard Office 365 SPF record.
>>
>
--
David Jones
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Okay, trying to understand.
You say:
whitelist_auth *@*.chase.com
whitelist_auth service@paypal.com
This would trust emails from any subdomain under chase.com and
service@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
Okay, got that.
But I'm confused when you further explain:
Assuming that real human users with passwords that can be
compromised are using *@example.com, you would never want to add
"whitelist_auth *@example.com" except for very specific reasons.
Example.com should have proper SPF and/or DKIM and the domain
ownership be verified to be who you think it really is. Then create
rules and train your Bayes DB for all other variations of these
major brands and companies to add points and block the spoofing.
Do you mean don't whitelist_auth *@example.com *unless* they have
published spf/dkim?
Certainly paypal and chase (your examples where you would use
whitelist_auth) have real human users. . .
Thanks in advance for clarifying.
On 01/19/2018 03:59 PM, David Jones wrote:
> On 01/19/2018 02:21 PM, Jeffs Chips wrote:
>> I would be very interested in knowing what features in SA flag
>> spoofed email addresses. Knowing the methods used or plugins
>> available to detect spoofed emails is integral to the project I'm
>> working on.
>>
>
> That is the million dollar question. If we had a solid way to detect
> spoofing then the spoofing problem would not exist any more. It's a
> combination of sending IP reputation (RBLs), authorization (SPF), and
> authentication (DKIM), and content. These are the main categories of
> rules which all have to be balanced carefully to accurately detect
> spam without FPs.
>
> The major brands and company names are commonly used in spoofing like
> Dropbox, Paypal, Bank of America (and other banks), etc. I just got
> one a few hours ago spoofing LinkedIn.
>
> The technique that I have found to work requires these major brands
> and companies to have properly implemented SPF and/or DKIM usually on
> a subdomain like alertsp.chase.com or a dedicated email address like
> service@paypal.com. Then you add an entry like this:
>
> whitelist_auth *@*.chase.com
> whitelist_auth service@paypal.com
>
> (No need to add those entries since they are in the default rulesets
> already.)
>
> This would trust emails from any subdomain under chase.com and
> service@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
>
> Assuming that real human users with passwords that can be compromised
> are using *@example.com, you would never want to add "whitelist_auth
> *@example.com" except for very specific reasons. Example.com should
> have proper SPF and/or DKIM and the domain ownership be verified to be
> who you think it really is. Then create rules and train your Bayes DB
> for all other variations of these major brands and companies to add
> points and block the spoofing.
>
> If you look at my ena.com, we have DMARC setup with p=reject. This is
> just about the best thing that we have today to prevent spoofing of
> ena.com. As more an more major brands and companies wanting to
> protect their brands and reputation implement DMARC p=reject, we can
> use this information to block even more spoofing. Of course my domain
> is not a target of spoofing since we are a small company.
>
> Today DMARC support for SA requires setting up OpenDMARC at the MTA
> (i.e. Postfix) and then adding custom rules to act on those headers.
> For example, I add a number of points when the sending domain has
> p=reject and DMARC fails.
>
> FYI, there are a huge number of broken SPF records out there. Thanks
> to Microsoft telling everyone to create brand new SPF records with
> "-all" without knowing all sources of their email, a lot of legit
> emails fail SPF checks with the standard Office 365 SPF record.
>
Re: From name containing a spoofed email address
Posted by David Jones <dj...@ena.com>.
On 01/19/2018 02:21 PM, Jeffs Chips wrote:
> I would be very interested in knowing what features in SA flag spoofed
> email addresses. Knowing the methods used or plugins available to
> detect spoofed emails is integral to the project I'm working on.
>
That is the million dollar question. If we had a solid way to detect
spoofing then the spoofing problem would not exist any more. It's a
combination of sending IP reputation (RBLs), authorization (SPF), and
authentication (DKIM), and content. These are the main categories of
rules which all have to be balanced carefully to accurately detect spam
without FPs.
The major brands and company names are commonly used in spoofing like
Dropbox, Paypal, Bank of America (and other banks), etc. I just got one
a few hours ago spoofing LinkedIn.
The technique that I have found to work requires these major brands and
companies to have properly implemented SPF and/or DKIM usually on a
subdomain like alertsp.chase.com or a dedicated email address like
service@paypal.com. Then you add an entry like this:
whitelist_auth *@*.chase.com
whitelist_auth service@paypal.com
(No need to add those entries since they are in the default rulesets
already.)
This would trust emails from any subdomain under chase.com and
service@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
Assuming that real human users with passwords that can be compromised
are using *@example.com, you would never want to add "whitelist_auth
*@example.com" except for very specific reasons. Example.com should
have proper SPF and/or DKIM and the domain ownership be verified to be
who you think it really is. Then create rules and train your Bayes DB
for all other variations of these major brands and companies to add
points and block the spoofing.
If you look at my ena.com, we have DMARC setup with p=reject. This is
just about the best thing that we have today to prevent spoofing of
ena.com. As more an more major brands and companies wanting to protect
their brands and reputation implement DMARC p=reject, we can use this
information to block even more spoofing. Of course my domain is not a
target of spoofing since we are a small company.
Today DMARC support for SA requires setting up OpenDMARC at the MTA
(i.e. Postfix) and then adding custom rules to act on those headers.
For example, I add a number of points when the sending domain has
p=reject and DMARC fails.
FYI, there are a huge number of broken SPF records out there. Thanks to
Microsoft telling everyone to create brand new SPF records with "-all"
without knowing all sources of their email, a lot of legit emails fail
SPF checks with the standard Office 365 SPF record.
--
David Jones
Re: From name containing a spoofed email address
Posted by Jeffs Chips <je...@gmail.com>.
I would be very interested in knowing what features in SA flag spoofed
email addresses. Knowing the methods used or plugins available to detect
spoofed emails is integral to the project I'm working on.
__________________
"Perhaps sleep did not evolve. Perhaps it was the thing from which
wakefulness emerged.” -- Matthew Walker, Sleep Scientist
On Jan 19, 2018 3:12 PM, "Jeffs Chips" <je...@gmail.com> wrote:
Thanks! FYI for some reason Gmail is classifying these emails as spam.
__________________
"Perhaps sleep did not evolve. Perhaps it was the thing from which
wakefulness emerged.” -- Matthew Walker, Sleep Scientist
On Jan 19, 2018 3:11 PM, "John Hardin" <jh...@impsec.org> wrote:
> On Fri, 19 Jan 2018, AJ Weber wrote:
>
> False Positive
>>
>
> i.e. SA incorrectly classifying a message as SPAM.
>
> --
> 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
> -----------------------------------------------------------------------
> Maxim VI: If violence wasn’t your last resort, you failed to resort
> to enough of it.
> -----------------------------------------------------------------------
> 4 days until John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by Jeffs Chips <je...@gmail.com>.
Thanks! FYI for some reason Gmail is classifying these emails as spam.
__________________
"Perhaps sleep did not evolve. Perhaps it was the thing from which
wakefulness emerged.” -- Matthew Walker, Sleep Scientist
On Jan 19, 2018 3:11 PM, "John Hardin" <jh...@impsec.org> wrote:
> On Fri, 19 Jan 2018, AJ Weber wrote:
>
> False Positive
>>
>
> i.e. SA incorrectly classifying a message as SPAM.
>
> --
> 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
> -----------------------------------------------------------------------
> Maxim VI: If violence wasn’t your last resort, you failed to resort
> to enough of it.
> -----------------------------------------------------------------------
> 4 days until John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by John Hardin <jh...@impsec.org>.
On Fri, 19 Jan 2018, AJ Weber wrote:
> False Positive
i.e. SA incorrectly classifying a message as SPAM.
--
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
-----------------------------------------------------------------------
Maxim VI: If violence wasn’t your last resort, you failed to resort
to enough of it.
-----------------------------------------------------------------------
4 days until John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by AJ Weber <aw...@comcast.net>.
False Positive
On 1/19/2018 2:55 PM, Jeffs Chips wrote:
> I am trying to follow this interesting thread - can someone tell me
> what "FP" means?
>
> __________________
> "Perhaps sleep did not evolve. Perhaps it was the thing from which
> wakefulness emerged.” -- Matthew Walker, Sleep Scientist
>
> On Jan 19, 2018 12:02 AM, "Pedro David Marco" <pedrod_marco@yahoo.com
> <ma...@yahoo.com>> wrote:
>
>
>
> >!~ matches are dangerous because they match by default if you
> >don't anticipate all the legitimate formats. The above will FP on a
> >simple email address. It could be rewritten as a __FROM_DOMAINS_MATCH
> >and used in a meta rule.
>
> fool me, your are right, RW, thanks...
>
> >It's also not a complete solution as it doesn't handle third-level
> >domains correctly e.g. in
> >
> >"support@paypal.co.uk <ma...@paypal.co.uk>"
> <jkhjhjk@bogus.co.uk <ma...@bogus.co.uk>>
> >
> >"co" will match "co". This is why it's probably best to do it in perl
> >where the tlds from 20_aux_tlds.cf <http://20_aux_tlds.cf> can be
> used.
>
> you are right as well... but his problem is hard to solve becasue
> subdomains can be almost unlimited
> and even worse... domains can be different but valid, outlook.com
> <http://outlook.com> and hotmail.com <http://hotmail.com> for example.
>
>
>
>
>
Re: From name containing a spoofed email address
Posted by Jeffs Chips <je...@gmail.com>.
I am trying to follow this interesting thread - can someone tell me what
"FP" means?
__________________
"Perhaps sleep did not evolve. Perhaps it was the thing from which
wakefulness emerged.” -- Matthew Walker, Sleep Scientist
On Jan 19, 2018 12:02 AM, "Pedro David Marco" <pe...@yahoo.com>
wrote:
>
>
> >!~ matches are dangerous because they match by default if you
> >don't anticipate all the legitimate formats. The above will FP on a
> >simple email address. It could be rewritten as a __FROM_DOMAINS_MATCH
> >and used in a meta rule.
>
> fool me, your are right, RW, thanks...
>
> >It's also not a complete solution as it doesn't handle third-level
> >domains correctly e.g. in
> >
> >"support@paypal.co.uk" <jk...@bogus.co.uk>
> >
> >"co" will match "co". This is why it's probably best to do it in perl
> >where the tlds from 20_aux_tlds.cf can be used.
>
> you are right as well... but his problem is hard to solve becasue
> subdomains can be almost unlimited
> and even worse... domains can be different but valid, outlook.com and
> hotmail.com for example.
>
>
>
>
>
>
Re: From name containing a spoofed email address
Posted by Pedro David Marco <pe...@yahoo.com>.
>!~ matches are dangerous because they match by default if you
>don't anticipate all the legitimate formats. The above will FP on a
>simple email address. It could be rewritten as a __FROM_DOMAINS_MATCH
>and used in a meta rule.
fool me, your are right, RW, thanks...
>It's also not a complete solution as it doesn't handle third-level
>domains correctly e.g. in
>
>"support@paypal.co.uk" <jk...@bogus.co.uk>
>
>"co" will match "co". This is why it's probably best to do it in perl
>where the tlds from 20_aux_tlds.cf can be used.
you are right as well... but his problem is hard to solve becasue subdomains can be almost unlimitedand even worse... domains can be different but valid, outlook.com and hotmail.com for example.
Re: From name containing a spoofed email address
Posted by RW <rw...@googlemail.com>.
On Thu, 18 Jan 2018 11:52:36 +0000 (UTC)
Pedro David Marco wrote:
> David,
> This rule can do the full job... i have tested it with good
> results.. (Can be tested here: https://regex101.com/r/Vpmhjz/3 ) It
> checks if the level domain next to the TLD in the From:name matches
> the domain next to the TLD in From:email header
> FROM_DOMAINS_MISMATCH
> From !~ /(?:[^<].+?)\@(?:.+?\.)*?(.+?\.)(?:.+?).*?<.+?(\@\1|\@.*?\.\1)/describe
> FROM_DOMAINS_MISMATCH Domain name mismatch in From header
!~ matches are dangerous because they match by default if you
don't anticipate all the legitimate formats. The above will FP on a
simple email address. It could be rewritten as a __FROM_DOMAINS_MATCH
and used in a meta rule.
It's also not a complete solution as it doesn't handle third-level
domains correctly e.g. in
"support@paypal.co.uk" <jk...@bogus.co.uk>
"co" will match "co". This is why it's probably best to do it in perl
where the tlds from 20_aux_tlds.cf can be used.
Re: From name containing a spoofed email address
Posted by "Kevin A. McGrail" <km...@apache.org>.
Makes sense to me. Just trying to check off boxes on open items for 3.4.2
release.
--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sat, Aug 25, 2018 at 9:08 AM, David Jones <dj...@ena.com> wrote:
> On 08/24/2018 07:02 PM, Kevin A. McGrail wrote:
>
>> On 1/18/2018 6:52 AM, Pedro David Marco wrote:
>>
>>> David,
>>>
>>> This rule can do the full job... i have tested it with good results..
>>> (Can be tested here: https://regex101.com/r/Vpmhjz/3 )
>>>
>>> It checks if the level domain next to the TLD in the From:name matches
>>> the domain next to the TLD in From:email
>>>
>>> header FROM_DOMAINS_MISMATCHFrom !~/(?:[^<].+?)\@(?:.+?\.)*?(.+
>>> ?\.)(?:.+?).*?<.+?(\@\1|\@.*?\.\1)/
>>> describe FROM_DOMAINS_MISMATCHDomain name mismatch in From header
>>>
>> Did this ever get considered for a sandbox.
>>
>> Alan Hodgson also had a good posted on one but not tested.
>> Regards,
>> KAM
>>
>
> I am not sure this is going to be worth as sandbox rule. There are going
> to be a high number of system-generated and mass-marketing emails that
> aren't going to match the From: header.
>
> From my experience, this is a local rule that detects high-value display
> names in phishing attempts. For example, the C-level executive's name as
> the Display Name when it comes from gmail.com to the Finance department
> to wire money.
>
> From: "CEO Name Here" <jo...@gmail.com>
>
> Also, DMARC is supposed to help with this spoofing of the From: header. I
> handle this locally with OpenDMARC adding headers used in an SA meta rule.
> This is the best way to handle this until SA natively supports DMARC.
>
> --
> David Jones
>
Re: From name containing a spoofed email address
Posted by David Jones <dj...@ena.com>.
On 08/24/2018 07:02 PM, Kevin A. McGrail wrote:
> On 1/18/2018 6:52 AM, Pedro David Marco wrote:
>> David,
>>
>> This rule can do the full job... i have tested it with good results..
>> (Can be tested here: https://regex101.com/r/Vpmhjz/3 )
>>
>> It checks if the level domain next to the TLD in the From:name matches
>> the domain next to the TLD in From:email
>>
>> header FROM_DOMAINS_MISMATCHFrom
>> !~/(?:[^<].+?)\@(?:.+?\.)*?(.+?\.)(?:.+?).*?<.+?(\@\1|\@.*?\.\1)/
>> describe FROM_DOMAINS_MISMATCHDomain name mismatch in From header
> Did this ever get considered for a sandbox.
>
> Alan Hodgson also had a good posted on one but not tested.
> Regards,
> KAM
I am not sure this is going to be worth as sandbox rule. There are
going to be a high number of system-generated and mass-marketing emails
that aren't going to match the From: header.
From my experience, this is a local rule that detects high-value
display names in phishing attempts. For example, the C-level
executive's name as the Display Name when it comes from gmail.com to the
Finance department to wire money.
From: "CEO Name Here" <jo...@gmail.com>
Also, DMARC is supposed to help with this spoofing of the From: header.
I handle this locally with OpenDMARC adding headers used in an SA meta
rule. This is the best way to handle this until SA natively supports DMARC.
--
David Jones
Re: From name containing a spoofed email address
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 1/18/2018 6:52 AM, Pedro David Marco wrote:
> David,
>
> This rule can do the full job... i have tested it with good results..
> (Can be tested here: https://regex101.com/r/Vpmhjz/3 )
>
> It checks if the level domain next to the TLD in the From:name matches
> the domain next to the TLD in From:email
>
> header FROM_DOMAINS_MISMATCHFrom
> !~/(?:[^<].+?)\@(?:.+?\.)*?(.+?\.)(?:.+?).*?<.+?(\@\1|\@.*?\.\1)/
> describe FROM_DOMAINS_MISMATCHDomain name mismatch in From header
Did this ever get considered for a sandbox.
Alan Hodgson also had a good posted on one but not tested.
Regards,
KAM
Re: From name containing a spoofed email address
Posted by Pedro David Marco <pe...@yahoo.com>.
David,
This rule can do the full job... i have tested it with good results.. (Can be tested here: https://regex101.com/r/Vpmhjz/3 )
It checks if the level domain next to the TLD in the From:name matches the domain next to the TLD in From:email
header FROM_DOMAINS_MISMATCH From !~ /(?:[^<].+?)\@(?:.+?\.)*?(.+?\.)(?:.+?).*?<.+?(\@\1|\@.*?\.\1)/describe FROM_DOMAINS_MISMATCH Domain name mismatch in From header
>Would a plugin need to be created (or an existing one enhanced) to be
>able to detect this type of spoofed From header?
>From: "hulu@hulumail.com !" <la...@hotmail.com>
>https://pastebin.com/vVhGjC8H
>>Does anyone else think this would be a good idea to make a rule that at
>least checks both the From:name and From:addr to see if there is an
>email address in the From:name and if the domain is different add some
>points?
>We are seeing more and more of this now that SPF, DKIM, and DMARC are
>making it harder to spoof common/major brands that have properly
>implemented some or all of them.
>--
>David Jones
----------PedroD
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
On Thu, 18 Jan 2018, RW wrote:
> I think the hard part is handling IDNs, e.g.
>
> "=?UTF-8?B?Zm9vQGLDvGNoZXIuY29t?=" <fo...@xn--bcher-kva.com>
>
> the display name should decode to the UTF-8 byte sequence for
> foo@bücher.com, but I presume the address would be left as the ASCII
> IDN.
>
> In the short term it's probably best to avoid matching on IDNs, but that
> does allow the use of homographs in spoofing ASCII domains.
Yeah, that occured to me, and I decided to set that problem aside for
now (probably someone more familiar with the issues should address
it).
> BTW it's best to only match on the organizational domain, to avoid
> FPs on the likes of:
Do you (or anyone, for that matter) have samples of emails like this
that they could share for me to test against?
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by RW <rw...@googlemail.com>.
On Wed, 17 Jan 2018 15:32:38 -0600 (CST)
shanew@shanew.net wrote:
> I started working on this, and quickly realized the hard part is
> determining/parsing the domain out of the From:name variable.
I think the hard part is handling IDNs, e.g.
"=?UTF-8?B?Zm9vQGLDvGNoZXIuY29t?=" <fo...@xn--bcher-kva.com>
the display name should decode to the UTF-8 byte sequence for
foo@bücher.com, but I presume the address would be left as the ASCII
IDN.
In the short term it's probably best to avoid matching on IDNs, but that
does allow the use of homographs in spoofing ASCII domains.
BTW it's best to only match on the organizational domain, to avoid
FPs on the likes of:
"foo@example.com" <fo...@email.example.com>
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
I started working on this, and quickly realized the hard part is
determining/parsing the domain out of the From:name variable.
Is there any existing code in SA that "recognizes" email addresses
that can be called and/or re-used?
On Wed, 17 Jan 2018, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to be able to
> detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" <la...@hotmail.com>
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at least
> checks both the From:name and From:addr to see if there is an email address
> in the From:name and if the domain is different add some points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are making
> it harder to spoof common/major brands that have properly implemented some or
> all of them.
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by Rupert Gallagher <ru...@protonmail.com>.
Note the clause "__F_DM2". Its purpose is to whitelist legit e-mail from known incompetent admins. You can remove the clause if you wish, and use the global whitelist.cf instead.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
On 22 January 2018 4:05 PM, Rupert Gallagher <ru...@protonmail.com> wrote:
> This is my current solution for a problem that has been discussed many times in this list.
> I wrote it last year, and it serves me well. Feel free to use it, if you find it useful.
>
> This part goes into your local.cf:
>
> header __F_DM1 eval:from_domains_mismatch()
> header __F_DM2 From:addr =~ /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
> meta F_DM ( __F_DM1 && ! __F_DM2 )
> describe F_DM From:name domain mismatches From:addr domain
> priority F_DM -1
> score F_DM 5.0
>
> This part goes into the general HeaderEval.pm:
>
> $self->register_eval_rule("from_domains_mismatch");
> [...]
> sub from_domains_mismatch {
> my ($self, $pms) = @_;
> my $temp;
> $temp = $pms->get('From:addr');
> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> $temp = $pms->get('From:name');
> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain, fromAddrDomain=$fromAddrDomain");
> if ( $fromNameDomain eq "" ) {
> return 0; # all well
> } else {
> if( $fromNameDomain eq $fromAddrDomain ) {
> return 0; # all well, they match
> } else {
> return 1; # mismatch, possibly spam
> }
> }
> }
>
> R.G.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> -------- Original Message --------
> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>
>> Would a plugin need to be created (or an existing one enhanced) to be
>> able to detect this type of spoofed From header?
>>
>> From: ["hulu@hulumail.com](mailto:%22hulu@hulumail.com) !" lanya-f@hotmail.com
>>
>> https://pastebin.com/vVhGjC8H
>>
>> Does anyone else think this would be a good idea to make a rule that at
>> least checks both the From:name and From:addr to see if there is an
>> email address in the From:name and if the domain is different add some
>> points?
>>
>> We are seeing more and more of this now that SPF, DKIM, and DMARC are
>> making it harder to spoof common/major brands that have properly
>> implemented some or all of them.
>>
>> David Jones
Re: From name containing a spoofed email address
Posted by Chris <cp...@embarqmail.com>.
On Fri, 2018-01-26 at 16:26 -0600, shanew@shanew.net wrote:
> Just a hunch, but did you make sure to add the "$self->register..."
> line inside the "sub new {" block with all the others in
> HeaderEval.pm?
>
Yep, sure did, thanks for that. All is well now.
>
> On Fri, 26 Jan 2018, Chris wrote:
>
> > On Mon, 2018-01-22 at 10:05 -0500, Rupert Gallagher wrote:
> >> This is my current solution for a problem that has been discussed
> >> many times in this list.
> >> I wrote it last year, and it serves me well. Feel free to use it,
> if
> >> you find it useful.
> >>
> >> This part goes into your local.cf:
> >>
> >> header __F_DM1 eval:from_domains_mismatch()
> >> header __F_DM2 From:addr =~
> >> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
> >> meta F_DM ( __F_DM1 && ! __F_DM2 )
> >> describe F_DM From:name domain mismatches From:addr domain
> >> priority F_DM -1
> >> score F_DM 5.0
> >>
> >> This part goes into the general HeaderEval.pm:
> >>
> >> $self->register_eval_rule("from_domains_mismatch");
> >> [...]
> >> sub from_domains_mismatch {
> >> my ($self, $pms) = @_;
> >> my $temp;
> >> $temp = $pms->get('From:addr');
> >> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> >> $temp = $pms->get('From:name');
> >> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain =
> >> "$1";
> >> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
> >> fromAddrDomain=$fromAddrDomain");
> >> if ( $fromNameDomain eq "" ) {
> >> return 0; # all well
> >> } else {
> >> if( $fromNameDomain eq $fromAddrDomain ) {
> >> return 0; # all well, they match
> >> } else {
> >> return 1; # mismatch, possibly spam
> >> }
> >> }
> >> }
> >>
> >> R.G.
> >>
> > Just for the heck of it I added the above to my SpamAssassin setup
> at
> > home. However my syslog shows:
> >
> > rules: failed to run __F_DM1 test, skipping:
> > (Can't locate object method "from_domains_mismatch" via package
> "Mail:
> > [...]:SpamAssassin::PerMsgStatus" at (eval 1816) line 19.)
> >
> > I did restart SA after adding this. SA version 3.4.1
> >
> >
>
> --
> Public key #7BBC68D9 at | Shane Williams
> http://pgp.mit.edu/ | System Admin - UT CompSci
> =----------------------------------+-------------------------------
> All syllogisms contain three lines | shanew@shanew.net
> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:48:06 up 8:35, 1 user, load average: 0.42, 0.38, 0.39
Description: Ubuntu 16.04.3 LTS, kernel 4.13.0-32-generic
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
Just a hunch, but did you make sure to add the "$self->register..."
line inside the "sub new {" block with all the others in HeaderEval.pm?
On Fri, 26 Jan 2018, Chris wrote:
> On Mon, 2018-01-22 at 10:05 -0500, Rupert Gallagher wrote:
>> This is my current solution for a problem that has been discussed
>> many times in this list.
>> I wrote it last year, and it serves me well. Feel free to use it, if
>> you find it useful.
>>
>> This part goes into your local.cf:
>>
>> header __F_DM1 eval:from_domains_mismatch()
>> header __F_DM2 From:addr =~
>> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
>> meta F_DM ( __F_DM1 && ! __F_DM2 )
>> describe F_DM From:name domain mismatches From:addr domain
>> priority F_DM -1
>> score F_DM 5.0
>>
>> This part goes into the general HeaderEval.pm:
>>
>> $self->register_eval_rule("from_domains_mismatch");
>> [...]
>> sub from_domains_mismatch {
>> my ($self, $pms) = @_;
>> my $temp;
>> $temp = $pms->get('From:addr');
>> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
>> $temp = $pms->get('From:name');
>> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain =
>> "$1";
>> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
>> fromAddrDomain=$fromAddrDomain");
>> if ( $fromNameDomain eq "" ) {
>> return 0; # all well
>> } else {
>> if( $fromNameDomain eq $fromAddrDomain ) {
>> return 0; # all well, they match
>> } else {
>> return 1; # mismatch, possibly spam
>> }
>> }
>> }
>>
>> R.G.
>>
> Just for the heck of it I added the above to my SpamAssassin setup at
> home. However my syslog shows:
>
> rules: failed to run __F_DM1 test, skipping:
> (Can't locate object method "from_domains_mismatch" via package "Mail:
> [...]:SpamAssassin::PerMsgStatus" at (eval 1816) line 19.)
>
> I did restart SA after adding this. SA version 3.4.1
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by Chris <cp...@embarqmail.com>.
On Mon, 2018-01-22 at 10:05 -0500, Rupert Gallagher wrote:
> This is my current solution for a problem that has been discussed
> many times in this list.
> I wrote it last year, and it serves me well. Feel free to use it, if
> you find it useful.
>
> This part goes into your local.cf:
>
> header __F_DM1 eval:from_domains_mismatch()
> header __F_DM2 From:addr =~
> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
> meta F_DM ( __F_DM1 && ! __F_DM2 )
> describe F_DM From:name domain mismatches From:addr domain
> priority F_DM -1
> score F_DM 5.0
>
> This part goes into the general HeaderEval.pm:
>
> $self->register_eval_rule("from_domains_mismatch");
> [...]
> sub from_domains_mismatch {
> my ($self, $pms) = @_;
> my $temp;
> $temp = $pms->get('From:addr');
> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> $temp = $pms->get('From:name');
> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain =
> "$1";
> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
> fromAddrDomain=$fromAddrDomain");
> if ( $fromNameDomain eq "" ) {
> return 0; # all well
> } else {
> if( $fromNameDomain eq $fromAddrDomain ) {
> return 0; # all well, they match
> } else {
> return 1; # mismatch, possibly spam
> }
> }
> }
>
> R.G.
>
Just for the heck of it I added the above to my SpamAssassin setup at
home. However my syslog shows:
rules: failed to run __F_DM1 test, skipping:
(Can't locate object method "from_domains_mismatch" via package "Mail:
[...]:SpamAssassin::PerMsgStatus" at (eval 1816) line 19.)
I did restart SA after adding this. SA version 3.4.1
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
15:53:56 up 7:41, 1 user, load average: 0.42, 0.71, 0.69
Description: Ubuntu 16.04.3 LTS, kernel 4.13.0-32-generic
Re: From name containing a spoofed email address
Posted by RW <rw...@googlemail.com>.
On Mon, 22 Jan 2018 10:05:14 -0500
Rupert Gallagher wrote:
> This is my current solution for a problem that has been discussed
> many times in this list.
> sub from_domains_mismatch {
> my ($self, $pms) = @_;
> my $temp;
> $temp = $pms->get('From:addr');
> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> $temp = $pms->get('From:name');
> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain =
> "$1"; dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
> fromAddrDomain=$fromAddrDomain"); if ( $fromNameDomain eq "" ) {
> return 0; # all well
> } else {
> if( $fromNameDomain eq $fromAddrDomain ) {
> return 0; # all well, they match
> } else {
> return 1; # mismatch, possibly spam
> }
> }
> }
This is a case-sensitive comparison.
Re: From name containing a spoofed email address
Posted by RW <rw...@googlemail.com>.
On Mon, 22 Jan 2018 17:16:49 -0600 (CST)
shanew@shanew.net wrote:
> Since there's no "@" in From:name, there's clearly not an email
> address there, so there's nothing to compare to the domain part of
> From:addr.
FWIW it doesn't actually check that the @ is part of something that
looks like an email address so would be liable to FP on display names
like "J@CK" or "@sometwittername".
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Thanks to those for being patient with me. I see the issue was I didn't
understand that the spammer is "cramming" or somehow the different
domains get "crammed" into the From:
I mistakenly thought these where two different distinct fields.
On 01/22/2018 06:32 PM, John Hardin wrote:
> On Mon, 22 Jan 2018, Chip wrote:
>
>> Understood, so then what would a From:name that contains a domain look
>> like since it seems the filter needs to compare the domain found in
>> From:addr to From:name in order to pass it as ham.
>
> From: "Joe User (Your Bank) <jo...@yourbank.com>"
> <jo...@phishing.com>
>
>
>> Or am I on another planet altogether here, just say so and I'll shut up.
>>
>> On 01/22/2018 06:21 PM, Chip wrote:
>>> Ah, okay. Thanks for the clarification.
>>>
>>> So this filter, what would it make of that message? Spam or ham?
>>>
>>> On 01/22/2018 06:16 PM, shanew@shanew.net wrote:
>>>> I think what's tripping you up is what parts of the mail "From:addr"
>>>> and "From:name" refer to. In the example you give:
>>>>
>>>> From: blablabla <bl...@gmail.com>
>>>>
>>>> From:name will be "blablabla"
>>>> and
>>>> From:addr will be "blablabla@gmail.com"
>>>>
>>>> Since there's no "@" in From:name, there's clearly not an email
>>>> address there, so there's nothing to compare to the domain part of
>>>> From:addr.
>>>>
>>>> The "bounces.em.secureserver.net" you're referring to is part of the
>>>> EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
>>>> that domain name in any way whatsoever.
>>>>
>>>> On Mon, 22 Jan 2018, Chip wrote:
>>>>
>>>>> I might be wrong here understand I'm still learning, but the
>>>>> purpose of
>>>>> the filter, from what I've been able to grasp, is that it checks the
>>>>> From:addr and From:name values in SA to find
>>>>> their domain and triggering a rule hit if there is a domain in the
>>>>> From:name that doesn't match the domain in the From:addr.
>>>>>
>>>>> In the example I sent From: (as in From:name) contains the domain
>>>>> "gmail.com" - blablabla@gmail.com
>>>>>
>>>>> From:addr contains "bounces.em.secureserver.net"
>>>>>
>>>>> Thus mismatch between From:name that doesn't match the domain in the
>>>>> From:addr.
>>>>>
>>>>> Thus it would identify this message as probably spam, which it is
>>>>> not.
>>>>>
>>>>> Are people talking about a name like "bla@blabla@domain.com"? in this
>>>>> thread meaning the actual "@" character in the "name" or are we
>>>>> comparing domains from the From:add to the domain in the From:name?
>>>>>
>>>>>
>>>>>
>>>>> On 01/22/2018 05:56 PM, RW wrote:
>>>>>> On Mon, 22 Jan 2018 17:44:00 -0500
>>>>>> Chip wrote:
>>>>>>
>>>>>>> Following is the full header with identifiable information
>>>>>>> anonymized.
>>>>>> I don't see what you are getting at, in:
>>>>>>
>>>>>>
>>>>>> From: blablabla <bl...@gmail.com>
>>>>>>
>>>>>> blablabla doesn't contain an "@".
>>>>>>
>>
>
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Finally! Thank you!
On 01/22/2018 06:32 PM, John Hardin wrote:
> On Mon, 22 Jan 2018, Chip wrote:
>
>> Understood, so then what would a From:name that contains a domain look
>> like since it seems the filter needs to compare the domain found in
>> From:addr to From:name in order to pass it as ham.
>
> From: "Joe User (Your Bank) <jo...@yourbank.com>"
> <jo...@phishing.com>
>
>
>> Or am I on another planet altogether here, just say so and I'll shut up.
>>
>> On 01/22/2018 06:21 PM, Chip wrote:
>>> Ah, okay. Thanks for the clarification.
>>>
>>> So this filter, what would it make of that message? Spam or ham?
>>>
>>> On 01/22/2018 06:16 PM, shanew@shanew.net wrote:
>>>> I think what's tripping you up is what parts of the mail "From:addr"
>>>> and "From:name" refer to. In the example you give:
>>>>
>>>> From: blablabla <bl...@gmail.com>
>>>>
>>>> From:name will be "blablabla"
>>>> and
>>>> From:addr will be "blablabla@gmail.com"
>>>>
>>>> Since there's no "@" in From:name, there's clearly not an email
>>>> address there, so there's nothing to compare to the domain part of
>>>> From:addr.
>>>>
>>>> The "bounces.em.secureserver.net" you're referring to is part of the
>>>> EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
>>>> that domain name in any way whatsoever.
>>>>
>>>> On Mon, 22 Jan 2018, Chip wrote:
>>>>
>>>>> I might be wrong here understand I'm still learning, but the
>>>>> purpose of
>>>>> the filter, from what I've been able to grasp, is that it checks the
>>>>> From:addr and From:name values in SA to find
>>>>> their domain and triggering a rule hit if there is a domain in the
>>>>> From:name that doesn't match the domain in the From:addr.
>>>>>
>>>>> In the example I sent From: (as in From:name) contains the domain
>>>>> "gmail.com" - blablabla@gmail.com
>>>>>
>>>>> From:addr contains "bounces.em.secureserver.net"
>>>>>
>>>>> Thus mismatch between From:name that doesn't match the domain in the
>>>>> From:addr.
>>>>>
>>>>> Thus it would identify this message as probably spam, which it is
>>>>> not.
>>>>>
>>>>> Are people talking about a name like "bla@blabla@domain.com"? in this
>>>>> thread meaning the actual "@" character in the "name" or are we
>>>>> comparing domains from the From:add to the domain in the From:name?
>>>>>
>>>>>
>>>>>
>>>>> On 01/22/2018 05:56 PM, RW wrote:
>>>>>> On Mon, 22 Jan 2018 17:44:00 -0500
>>>>>> Chip wrote:
>>>>>>
>>>>>>> Following is the full header with identifiable information
>>>>>>> anonymized.
>>>>>> I don't see what you are getting at, in:
>>>>>>
>>>>>>
>>>>>> From: blablabla <bl...@gmail.com>
>>>>>>
>>>>>> blablabla doesn't contain an "@".
>>>>>>
>>
>
Re: From name containing a spoofed email address
Posted by John Hardin <jh...@impsec.org>.
On Mon, 22 Jan 2018, Chip wrote:
> Understood, so then what would a From:name that contains a domain look
> like since it seems the filter needs to compare the domain found in
> From:addr to From:name in order to pass it as ham.
From: "Joe User (Your Bank) <jo...@yourbank.com>" <jo...@phishing.com>
> Or am I on another planet altogether here, just say so and I'll shut up.
>
> On 01/22/2018 06:21 PM, Chip wrote:
>> Ah, okay. Thanks for the clarification.
>>
>> So this filter, what would it make of that message? Spam or ham?
>>
>> On 01/22/2018 06:16 PM, shanew@shanew.net wrote:
>>> I think what's tripping you up is what parts of the mail "From:addr"
>>> and "From:name" refer to. In the example you give:
>>>
>>> From: blablabla <bl...@gmail.com>
>>>
>>> From:name will be "blablabla"
>>> and
>>> From:addr will be "blablabla@gmail.com"
>>>
>>> Since there's no "@" in From:name, there's clearly not an email
>>> address there, so there's nothing to compare to the domain part of
>>> From:addr.
>>>
>>> The "bounces.em.secureserver.net" you're referring to is part of the
>>> EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
>>> that domain name in any way whatsoever.
>>>
>>> On Mon, 22 Jan 2018, Chip wrote:
>>>
>>>> I might be wrong here understand I'm still learning, but the purpose of
>>>> the filter, from what I've been able to grasp, is that it checks the
>>>> From:addr and From:name values in SA to find
>>>> their domain and triggering a rule hit if there is a domain in the
>>>> From:name that doesn't match the domain in the From:addr.
>>>>
>>>> In the example I sent From: (as in From:name) contains the domain
>>>> "gmail.com" - blablabla@gmail.com
>>>>
>>>> From:addr contains "bounces.em.secureserver.net"
>>>>
>>>> Thus mismatch between From:name that doesn't match the domain in the
>>>> From:addr.
>>>>
>>>> Thus it would identify this message as probably spam, which it is not.
>>>>
>>>> Are people talking about a name like "bla@blabla@domain.com"? in this
>>>> thread meaning the actual "@" character in the "name" or are we
>>>> comparing domains from the From:add to the domain in the From:name?
>>>>
>>>>
>>>>
>>>> On 01/22/2018 05:56 PM, RW wrote:
>>>>> On Mon, 22 Jan 2018 17:44:00 -0500
>>>>> Chip wrote:
>>>>>
>>>>>> Following is the full header with identifiable information
>>>>>> anonymized.
>>>>> I don't see what you are getting at, in:
>>>>>
>>>>>
>>>>> From: blablabla <bl...@gmail.com>
>>>>>
>>>>> blablabla doesn't contain an "@".
>>>>>
>
--
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
-----------------------------------------------------------------------
USMC Rules of Gunfighting #20: The faster you finish the fight,
the less shot you will get.
-----------------------------------------------------------------------
Tomorrow: John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Understood, so then what would a From:name that contains a domain look
like since it seems the filter needs to compare the domain found in
From:addr to From:name in order to pass it as ham.
Or am I on another planet altogether here, just say so and I'll shut up.
On 01/22/2018 06:21 PM, Chip wrote:
> Ah, okay. Thanks for the clarification.
>
> So this filter, what would it make of that message? Spam or ham?
>
> On 01/22/2018 06:16 PM, shanew@shanew.net wrote:
>> I think what's tripping you up is what parts of the mail "From:addr"
>> and "From:name" refer to. In the example you give:
>>
>> From: blablabla <bl...@gmail.com>
>>
>> From:name will be "blablabla"
>> and
>> From:addr will be "blablabla@gmail.com"
>>
>> Since there's no "@" in From:name, there's clearly not an email
>> address there, so there's nothing to compare to the domain part of
>> From:addr.
>>
>> The "bounces.em.secureserver.net" you're referring to is part of the
>> EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
>> that domain name in any way whatsoever.
>>
>> On Mon, 22 Jan 2018, Chip wrote:
>>
>>> I might be wrong here understand I'm still learning, but the purpose of
>>> the filter, from what I've been able to grasp, is that it checks the
>>> From:addr and From:name values in SA to find
>>> their domain and triggering a rule hit if there is a domain in the
>>> From:name that doesn't match the domain in the From:addr.
>>>
>>> In the example I sent From: (as in From:name) contains the domain
>>> "gmail.com" - blablabla@gmail.com
>>>
>>> From:addr contains "bounces.em.secureserver.net"
>>>
>>> Thus mismatch between From:name that doesn't match the domain in the
>>> From:addr.
>>>
>>> Thus it would identify this message as probably spam, which it is not.
>>>
>>> Are people talking about a name like "bla@blabla@domain.com"? in this
>>> thread meaning the actual "@" character in the "name" or are we
>>> comparing domains from the From:add to the domain in the From:name?
>>>
>>>
>>>
>>> On 01/22/2018 05:56 PM, RW wrote:
>>>> On Mon, 22 Jan 2018 17:44:00 -0500
>>>> Chip wrote:
>>>>
>>>>> Following is the full header with identifiable information
>>>>> anonymized.
>>>> I don't see what you are getting at, in:
>>>>
>>>>
>>>> From: blablabla <bl...@gmail.com>
>>>>
>>>> blablabla doesn't contain an "@".
>>>>
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Ah, okay. Thanks for the clarification.
So this filter, what would it make of that message? Spam or ham?
On 01/22/2018 06:16 PM, shanew@shanew.net wrote:
> I think what's tripping you up is what parts of the mail "From:addr"
> and "From:name" refer to. In the example you give:
>
> From: blablabla <bl...@gmail.com>
>
> From:name will be "blablabla"
> and
> From:addr will be "blablabla@gmail.com"
>
> Since there's no "@" in From:name, there's clearly not an email
> address there, so there's nothing to compare to the domain part of
> From:addr.
>
> The "bounces.em.secureserver.net" you're referring to is part of the
> EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
> that domain name in any way whatsoever.
>
> On Mon, 22 Jan 2018, Chip wrote:
>
>> I might be wrong here understand I'm still learning, but the purpose of
>> the filter, from what I've been able to grasp, is that it checks the
>> From:addr and From:name values in SA to find
>> their domain and triggering a rule hit if there is a domain in the
>> From:name that doesn't match the domain in the From:addr.
>>
>> In the example I sent From: (as in From:name) contains the domain
>> "gmail.com" - blablabla@gmail.com
>>
>> From:addr contains "bounces.em.secureserver.net"
>>
>> Thus mismatch between From:name that doesn't match the domain in the
>> From:addr.
>>
>> Thus it would identify this message as probably spam, which it is not.
>>
>> Are people talking about a name like "bla@blabla@domain.com"? in this
>> thread meaning the actual "@" character in the "name" or are we
>> comparing domains from the From:add to the domain in the From:name?
>>
>>
>>
>> On 01/22/2018 05:56 PM, RW wrote:
>>> On Mon, 22 Jan 2018 17:44:00 -0500
>>> Chip wrote:
>>>
>>>> Following is the full header with identifiable information
>>>> anonymized.
>>> I don't see what you are getting at, in:
>>>
>>>
>>> From: blablabla <bl...@gmail.com>
>>>
>>> blablabla doesn't contain an "@".
>>>
>>
>
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
I think what's tripping you up is what parts of the mail "From:addr"
and "From:name" refer to. In the example you give:
From: blablabla <bl...@gmail.com>
From:name will be "blablabla"
and
From:addr will be "blablabla@gmail.com"
Since there's no "@" in From:name, there's clearly not an email
address there, so there's nothing to compare to the domain part of
From:addr.
The "bounces.em.secureserver.net" you're referring to is part of the
EnvelopeFrom (AKA ReturnPath). This particular check doesn't consider
that domain name in any way whatsoever.
On Mon, 22 Jan 2018, Chip wrote:
> I might be wrong here understand I'm still learning, but the purpose of
> the filter, from what I've been able to grasp, is that it checks the
> From:addr and From:name values in SA to find
> their domain and triggering a rule hit if there is a domain in the
> From:name that doesn't match the domain in the From:addr.
>
> In the example I sent From: (as in From:name) contains the domain
> "gmail.com" - blablabla@gmail.com
>
> From:addr contains "bounces.em.secureserver.net"
>
> Thus mismatch between From:name that doesn't match the domain in the
> From:addr.
>
> Thus it would identify this message as probably spam, which it is not.
>
> Are people talking about a name like "bla@blabla@domain.com"? in this
> thread meaning the actual "@" character in the "name" or are we
> comparing domains from the From:add to the domain in the From:name?
>
>
>
> On 01/22/2018 05:56 PM, RW wrote:
>> On Mon, 22 Jan 2018 17:44:00 -0500
>> Chip wrote:
>>
>>> Following is the full header with identifiable information
>>> anonymized.
>> I don't see what you are getting at, in:
>>
>>
>> From: blablabla <bl...@gmail.com>
>>
>> blablabla doesn't contain an "@".
>>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by John Hardin <jh...@impsec.org>.
On Mon, 22 Jan 2018, Chip wrote:
> In the attached image "header" is highlighted. Which one applies in
> this case as there is header=gmail *and* header=secure.net
What you have highlighted has nothing to do with the "From" header in SA
header rules. That content is in the "ARC-Authentication-Results",
"Authentication-Results" and "smtp.mailfrom" headers.
Regarding the example in question:
From: blablabla <bl...@gmail.com>
"From:name" refers to the comment part - "blablabla"
"From:addr" refers to the address (non-comment) part - "<bl...@gmail.com>"
Unfortunately the way that was obscured makes it a little less clear
what's going on. Perhaps this is clearer:
From: John Hardin <jh...@impsec.org>
"From:name" = "John Hardin" (comment part)
"From:addr" = "<jh...@impsec.org>" (address part)
> On 01/22/2018 06:13 PM, John Hardin wrote:
>> On Mon, 22 Jan 2018, Chip wrote:
>>
>>> I might be wrong here understand I'm still learning, but the purpose of
>>> the filter, from what I've been able to grasp, is that it checks the
>>> From:addr and From:name values in SA to find
>>> their domain and triggering a rule hit if there is a domain in the
>>> From:name that doesn't match the domain in the From:addr.
>>>
>>> In the example I sent From: (as in From:name) contains the domain
>>> "gmail.com" - blablabla@gmail.com
>>>
>>> From:addr contains "bounces.em.secureserver.net"
>>
>> "From:addr" is *not* the envelope from address. It is the non-comment
>> part of the message From: header.
--
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
-----------------------------------------------------------------------
USMC Rules of Gunfighting #20: The faster you finish the fight,
the less shot you will get.
-----------------------------------------------------------------------
Tomorrow: John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
In the attached image "header" is highlighted. Which one applies in
this case as there is header=gmail *and* header=secure.net
On 01/22/2018 06:13 PM, John Hardin wrote:
> On Mon, 22 Jan 2018, Chip wrote:
>
>> I might be wrong here understand I'm still learning, but the purpose of
>> the filter, from what I've been able to grasp, is that it checks the
>> From:addr and From:name values in SA to find
>> their domain and triggering a rule hit if there is a domain in the
>> From:name that doesn't match the domain in the From:addr.
>>
>> In the example I sent From: (as in From:name) contains the domain
>> "gmail.com" - blablabla@gmail.com
>>
>> From:addr contains "bounces.em.secureserver.net"
>
> "From:addr" is *not* the envelope from address. It is the non-comment
> part of the message From: header.
>
>
Re: From name containing a spoofed email address
Posted by John Hardin <jh...@impsec.org>.
On Mon, 22 Jan 2018, Chip wrote:
> I might be wrong here understand I'm still learning, but the purpose of
> the filter, from what I've been able to grasp, is that it checks the
> From:addr and From:name values in SA to find
> their domain and triggering a rule hit if there is a domain in the
> From:name that doesn't match the domain in the From:addr.
>
> In the example I sent From: (as in From:name) contains the domain
> "gmail.com" - blablabla@gmail.com
>
> From:addr contains "bounces.em.secureserver.net"
"From:addr" is *not* the envelope from address. It is the non-comment part
of the message From: header.
--
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
-----------------------------------------------------------------------
USMC Rules of Gunfighting #20: The faster you finish the fight,
the less shot you will get.
-----------------------------------------------------------------------
Tomorrow: John Moses Browning's 163rd Birthday
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
I might be wrong here understand I'm still learning, but the purpose of
the filter, from what I've been able to grasp, is that it checks the
From:addr and From:name values in SA to find
their domain and triggering a rule hit if there is a domain in the
From:name that doesn't match the domain in the From:addr.
In the example I sent From: (as in From:name) contains the domain
"gmail.com" - blablabla@gmail.com
From:addr contains "bounces.em.secureserver.net"
Thus mismatch between From:name that doesn't match the domain in the
From:addr.
Thus it would identify this message as probably spam, which it is not.
Are people talking about a name like "bla@blabla@domain.com"? in this
thread meaning the actual "@" character in the "name" or are we
comparing domains from the From:add to the domain in the From:name?
On 01/22/2018 05:56 PM, RW wrote:
> On Mon, 22 Jan 2018 17:44:00 -0500
> Chip wrote:
>
>> Following is the full header with identifiable information
>> anonymized.
> I don't see what you are getting at, in:
>
>
> From: blablabla <bl...@gmail.com>
>
> blablabla doesn't contain an "@".
>
Re: From name containing a spoofed email address
Posted by RW <rw...@googlemail.com>.
On Mon, 22 Jan 2018 17:44:00 -0500
Chip wrote:
> Following is the full header with identifiable information
> anonymized.
I don't see what you are getting at, in:
From: blablabla <bl...@gmail.com>
blablabla doesn't contain an "@".
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
Following is the full header with identifiable information anonymized.
I have other examples of commercial bulk senders suggesting - even
promoting - the idea that it's okay to input your external email address
in the From: of the message editor.
I actually did notice the dmarc=fail as well as dkim=fail and figured
that was meant to indicate something was amiss. But many legitimate
senders take advantage of using their external email addresses in the
From: field because through the course of their business dealings, they
have been known as "external email address" and do not want to use an
email address setup by the bulk sender just so the email passes as ham
(which would be an example of the technology creating the business
rather than the business creating the technology, at least in my view
anyway).
From - Mon Jan 8 11:12:07 2018
X-Account-Key: account8
X-UIDL: GmailId160d6874a8cc3b63
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Delivered-To: recipient-name@gmail.com
Received: by 10.80.170.60 with SMTP id o57csp19987edc;
Mon, 8 Jan 2018 08:07:59 -0800 (PST)
X-Google-Smtp-Source:
ACJfBos0ZEjYGCUohKc4D3Mjmx3Camt6rGbH3R5gevRWB7L7IaHBRie+EWMe3NapqMNqX3UTl2Mf
X-Received: by 10.99.170.13 with SMTP id e13mr9830140pgf.59.1515427678945;
Mon, 08 Jan 2018 08:07:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1515427678; cv=none;
d=google.com; s=arc-20160816;
b=tJEHT+wo4VTi4+6kjBaAMDHymGY2TYeUOMFHq9SgUSfbgMLxoM4c+50i+EgzeB6jgN
ckukID8K6wyK2wEVzWzJO7gG8kuHZs+HAPbBs0abu2KAmKYw6cx8Hl6ZpIijQM5JIdao
xW3vtEiruey37eh1E3rOFGpvn8wI0Eto2fIFTg+zxQwzw5DivVZDz5DO9NC2SVpCKW1o
6w9SZG2eoMcxR/z7EsdWslH7/pEdsYX9vL9It+I0BjsUA0h2RHjbwGiMfnk/8rehj2IC
yVOdvNSN1hlaIPQd+xfom1UDIEdXM6iPjE8CgQFzdew92TXS/JOnrB7mM6daGVYXPIhO
KhAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=arc-20160816;
h=list-unsubscribe:precedence:content-transfer-encoding:mime-version
:subject:message-id:to:from:date:dkim-signature
:arc-authentication-results;
bh=GGN7SrgQk2MoB6O8G3NoJ6r78aPmWaWLd5McGOiHhN0=;
b=iCJAAsuyGq7GJ5yxMaQfuh9q+lpkpxANOhB4LwzvZozFZZQfB37kD8xPo0wQAz+t0t
hEPdrGDlpaDjqoAEQ5nT5fL4V/1gjaB1wlWvzUxjX7d/IG6VCbvthPK+Og4GZuKt3N7I
7mKyHfjodHfs6xh2tJp9HOVoVOvSHUrshDGwI13cU++7gWH6cWS+pL5D053qfKyuxwb0
B8OTXJqm3t4zAmuTJe8YoTBSqvgdsyMpTNPnGIlh2Y35LBnOEL+5jfWgouSSZJl1lvrN
lKk5c3UHwyJv1RtbfpO0dGPZXH43lwvPXFqhKvtxlmv+KThW6C3MHbDVAzXUzBO97H0M
AVGg==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@em.secureserver.net header.s=aug05em
header.b=CbQPsrTP;
spf=pass (google.com: domain of
sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@bounces.em.secureserver.net
designates 198.71.244.36 as permitted sender)
smtp.mailfrom=sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@bounces.em.secureserver.net;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
Return-Path:
<sp...@bounces.em.secureserver.net>
Received: from m205.em.secureserver.net (m205.em.secureserver.net.
[198.71.244.36])
by mx.google.com with ESMTPS id
d62si6851150pga.576.2018.01.08.08.07.44
for <re...@gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 08 Jan 2018 08:07:58 -0800 (PST)
Received-SPF: pass (google.com: domain of
sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@bounces.em.secureserver.net
designates 198.71.244.36 as permitted sender) client-ip=198.71.244.36;
Authentication-Results: mx.google.com;
dkim=pass header.i=@em.secureserver.net header.s=aug05em
header.b=CbQPsrTP;
spf=pass (google.com: domain of
sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@bounces.em.secureserver.net
designates 198.71.244.36 as permitted sender)
smtp.mailfrom=sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@bounces.em.secureserver.net;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=aug05em;
d=em.secureserver.net;
h=Date:From:To:Message-ID:Subject:Mime-Version:Content-Type:
Content-Transfer-Encoding:List-Unsubscribe;
bh=AHOMFUv53O915X4eZO2WOfU/8qI=;
b=CbQPsrTPHETqtlok+3m22uvErHoo7tUpr2ATU2lyTCw9BMSmvhf9CL2Tuqd8YHQyDW6PQf68/CRI
yRL/gEUoqovWXpbWeDxwanDI8c+l4sQfs4nS1VznDTVo0O85Jhgzrn2eW3wpuENBs75qHceow89l
TWu+oEzaVGTPIg3F9cA=
Received: by m205.em.secureserver.net id haebl429tqgj for
<re...@gmail.com>; Mon, 8 Jan 2018 09:06:33 -0700
(envelope-from
<sp...@bounces.em.secureserver.net>)
Return-Path:
<sp...@bounces.em.secureserver.net>
Date: Mon, 08 Jan 2018 09:06:33 -0700
From: blablabla <bl...@gmail.com>
To: recipient-name@gmail.com
Message-ID:
<X1...@a2plmmsworker07.prod.iad2.gdg.mail>
Subject: 2018 Happenings!
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5a539709cfabf_986c3ff3c23bc2fc562928ed";
charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Personalized-By: Temple
X-Mimiaid:
4209-143484028-3396415218-63e97190b1f569cb93ae49eded6fb238c712a605
X-Member-ID: 3396415218
X-Feedback-ID: 143484028:madmimi
Precedence: bulk
X-Sable-ID: sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff
X-Report-Abuse: You can also report abuse here:
https://sable.madmimi.com/abuse/new?id=xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff
X-Virtual-MTA: m205
List-Unsubscribe:
<mailto:sp_xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff@unsubscribes.em.secureserver.net?subject=Unsubscribe
xxxxx.4209.1.d2b5f620ffe1xxxxxxxe5d93421ff>
On 01/22/2018 05:30 PM, shanew@shanew.net wrote:
> This particular effort is looking at the From header, not the EnvFrom
> header (though there is a check From==EnvFrom as well). What we're
> looking for here are things like:
>
> From: "bob@usaa.com" <bg...@gmail.com>
>
> Or look at the pastebin example at the start of the thread.
>
> Also, without seeing the full email, I can't say for sure, while your
> example may be legitimate email, the "dmarc=fail" suggests that the
> sender is, in fact, spoofing that gmail address (as in, it lacks a
> valid DKIM and/or doesn't come from a server approved by gmail's SPF
> record). It's just that spoofing isn't a sure-fire way to determine
> that something is spam (if only...).
>
>
>
> On Mon, 22 Jan 2018, Chip wrote:
>
>> So it's my understanding that SA does the following with this rule,
>> which is it is checking the From:addr and From:name values in SA to find
>> their domain and triggering a rule hit if there is a domain in the
>> From:name that doesn't match the domain in the From:addr.
>>
>> However, when I examine the headers from many legitimate non-spoofed
>> emails from bulk senders such as constantcontact, madmimi, sendgrid,
>> etc. it is very common to find a legitimate sender with a From:addr such
>> as name@gmail.com which clearly conflicts with the domain name in the
>> From:addr, address being, for example, with madmini bulk sending as an
>> example:
>>
>> smtp.mailfrom=sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;
>>
>> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
>> Return-Path:
>> <sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;>
>>
>> Received: from m205.em.secureserver.net (m205.em.secureserver.net.
>> [1xx.xx.xxx.xx])
>>
>> From: balblabla <bl...@gmail.com>
>>
>> would this rule classify that email as probably spam when in fact it
>> most certainly is not.
>>
>> So what am I not understand here?
>>
>> On 01/22/2018 10:20 AM, David Jones wrote:
>>> On 01/22/2018 09:05 AM, Rupert Gallagher wrote:
>>>> This is my current solution for a problem that has been discussed
>>>> many times in this list.
>>>> I wrote it last year, and it serves me well. Feel free to use it, if
>>>> you find it useful.
>>>>
>>>> This part goes into your local.cf:
>>>>
>>>> header __F_DM1 eval:from_domains_mismatch()
>>>> header __F_DM2 From:addr =~
>>>> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
>>>> meta F_DM ( __F_DM1 && ! __F_DM2 )
>>>> describe F_DM From:name domain mismatches From:addr domain
>>>> priority F_DM -1
>>>> score F_DM 5.0
>>>>
>>>> This part goes into the general HeaderEval.pm:
>>>>
>>>> $self->register_eval_rule("from_domains_mismatch");
>>>> [...]
>>>> sub from_domains_mismatch {
>>>> my ($self, $pms) = @_;
>>>> my $temp;
>>>> $temp = $pms->get('From:addr');
>>>> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
>>>> $temp = $pms->get('From:name');
>>>> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain =
>>>> "$1";
>>>> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
>>>> fromAddrDomain=$fromAddrDomain");
>>>> if ( $fromNameDomain eq "" ) {
>>>> return 0; # all well
>>>> } else {
>>>> if( $fromNameDomain eq $fromAddrDomain ) {
>>>> return 0; # all well, they match
>>>> } else {
>>>> return 1; # mismatch, possibly spam
>>>> }
>>>> }
>>>> }
>>>>
>>>> R.G.
>>>>
>>>>
>>>
>>> This looks like a simple and valuable approach that should be
>>> considered for inclusion into SA for everyone. Do you mind opening up
>>> a bug at https://bz.apache.org/SpamAssassin/ in the Plugins section?
>>>
>>> We could put this in for everyone with a low score and give it a trial
>>> run before increasing the score. I will run it locally as well and
>>> see how it goes.
>>>
>>>
>>>>
>>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>>
>>>> -------- Original Message --------
>>>> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>>>>
>>>>> Would a plugin need to be created (or an existing one enhanced) to be
>>>>> able to detect this type of spoofed From header?
>>>>>
>>>>> From: "hulu@hulumail.com <ma...@hulumail.com> !"
>>>>> lanya-f@hotmail.com <ma...@hotmail.com>
>>>>>
>>>>>
>>>>>
>>>>> https://pastebin.com/vVhGjC8H
>>>>>
>>>>> Does anyone else think this would be a good idea to make a rule
>>>>> that at
>>>>> least checks both the From:name and From:addr to see if there
>>>>> is an
>>>>> email address in the From:name and if the domain is different
>>>>> add some
>>>>> points?
>>>>>
>>>>> We are seeing more and more of this now that SPF, DKIM, and
>>>>> DMARC are
>>>>> making it harder to spoof common/major brands that have properly
>>>>> implemented some or all of them.
>>>>>
>>>>> David Jones
>>>>
>>>
>>
>
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
This particular effort is looking at the From header, not the EnvFrom
header (though there is a check From==EnvFrom as well). What we're
looking for here are things like:
From: "bob@usaa.com" <bg...@gmail.com>
Or look at the pastebin example at the start of the thread.
Also, without seeing the full email, I can't say for sure, while your
example may be legitimate email, the "dmarc=fail" suggests that
the sender is, in fact, spoofing that gmail address (as in, it lacks a
valid DKIM and/or doesn't come from a server approved by gmail's SPF
record). It's just that spoofing isn't a sure-fire way to determine
that something is spam (if only...).
On Mon, 22 Jan 2018, Chip wrote:
> So it's my understanding that SA does the following with this rule,
> which is it is checking the From:addr and From:name values in SA to find
> their domain and triggering a rule hit if there is a domain in the
> From:name that doesn't match the domain in the From:addr.
>
> However, when I examine the headers from many legitimate non-spoofed
> emails from bulk senders such as constantcontact, madmimi, sendgrid,
> etc. it is very common to find a legitimate sender with a From:addr such
> as name@gmail.com which clearly conflicts with the domain name in the
> From:addr, address being, for example, with madmini bulk sending as an
> example:
>
> smtp.mailfrom=sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;
> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
> Return-Path:
> <sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;>
> Received: from m205.em.secureserver.net (m205.em.secureserver.net.
> [1xx.xx.xxx.xx])
>
> From: balblabla <bl...@gmail.com>
>
> would this rule classify that email as probably spam when in fact it
> most certainly is not.
>
> So what am I not understand here?
>
> On 01/22/2018 10:20 AM, David Jones wrote:
>> On 01/22/2018 09:05 AM, Rupert Gallagher wrote:
>>> This is my current solution for a problem that has been discussed
>>> many times in this list.
>>> I wrote it last year, and it serves me well. Feel free to use it, if
>>> you find it useful.
>>>
>>> This part goes into your local.cf:
>>>
>>> header __F_DM1 eval:from_domains_mismatch()
>>> header __F_DM2 From:addr =~
>>> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
>>> meta F_DM ( __F_DM1 && ! __F_DM2 )
>>> describe F_DM From:name domain mismatches From:addr domain
>>> priority F_DM -1
>>> score F_DM 5.0
>>>
>>> This part goes into the general HeaderEval.pm:
>>>
>>> $self->register_eval_rule("from_domains_mismatch");
>>> [...]
>>> sub from_domains_mismatch {
>>> my ($self, $pms) = @_;
>>> my $temp;
>>> $temp = $pms->get('From:addr');
>>> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
>>> $temp = $pms->get('From:name');
>>> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
>>> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
>>> fromAddrDomain=$fromAddrDomain");
>>> if ( $fromNameDomain eq "" ) {
>>> return 0; # all well
>>> } else {
>>> if( $fromNameDomain eq $fromAddrDomain ) {
>>> return 0; # all well, they match
>>> } else {
>>> return 1; # mismatch, possibly spam
>>> }
>>> }
>>> }
>>>
>>> R.G.
>>>
>>>
>>
>> This looks like a simple and valuable approach that should be
>> considered for inclusion into SA for everyone. Do you mind opening up
>> a bug at https://bz.apache.org/SpamAssassin/ in the Plugins section?
>>
>> We could put this in for everyone with a low score and give it a trial
>> run before increasing the score. I will run it locally as well and
>> see how it goes.
>>
>>
>>>
>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>
>>> -------- Original Message --------
>>> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>>>
>>>> Would a plugin need to be created (or an existing one enhanced) to be
>>>> able to detect this type of spoofed From header?
>>>>
>>>> From: "hulu@hulumail.com <ma...@hulumail.com> !"
>>>> lanya-f@hotmail.com <ma...@hotmail.com>
>>>>
>>>>
>>>>
>>>> https://pastebin.com/vVhGjC8H
>>>>
>>>> Does anyone else think this would be a good idea to make a rule
>>>> that at
>>>> least checks both the From:name and From:addr to see if there is an
>>>> email address in the From:name and if the domain is different
>>>> add some
>>>> points?
>>>>
>>>> We are seeing more and more of this now that SPF, DKIM, and
>>>> DMARC are
>>>> making it harder to spoof common/major brands that have properly
>>>> implemented some or all of them.
>>>>
>>>> David Jones
>>>
>>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by Chip <je...@gmail.com>.
So it's my understanding that SA does the following with this rule,
which is it is checking the From:addr and From:name values in SA to find
their domain and triggering a rule hit if there is a domain in the
From:name that doesn't match the domain in the From:addr.
However, when I examine the headers from many legitimate non-spoofed
emails from bulk senders such as constantcontact, madmimi, sendgrid,
etc. it is very common to find a legitimate sender with a From:addr such
as name@gmail.com which clearly conflicts with the domain name in the
From:addr, address being, for example, with madmini bulk sending as an
example:
smtp.mailfrom=sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
Return-Path:
<sp_12xxxxx.55xx.1.d2b655xxxxxxxx21fe5d93421ff@bounces.em.secureserver.net;>
Received: from m205.em.secureserver.net (m205.em.secureserver.net.
[1xx.xx.xxx.xx])
From: balblabla <bl...@gmail.com>
would this rule classify that email as probably spam when in fact it
most certainly is not.
So what am I not understand here?
On 01/22/2018 10:20 AM, David Jones wrote:
> On 01/22/2018 09:05 AM, Rupert Gallagher wrote:
>> This is my current solution for a problem that has been discussed
>> many times in this list.
>> I wrote it last year, and it serves me well. Feel free to use it, if
>> you find it useful.
>>
>> This part goes into your local.cf:
>>
>> header __F_DM1 eval:from_domains_mismatch()
>> header __F_DM2 From:addr =~
>> /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
>> meta F_DM ( __F_DM1 && ! __F_DM2 )
>> describe F_DM From:name domain mismatches From:addr domain
>> priority F_DM -1
>> score F_DM 5.0
>>
>> This part goes into the general HeaderEval.pm:
>>
>> $self->register_eval_rule("from_domains_mismatch");
>> [...]
>> sub from_domains_mismatch {
>> my ($self, $pms) = @_;
>> my $temp;
>> $temp = $pms->get('From:addr');
>> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
>> $temp = $pms->get('From:name');
>> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
>> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
>> fromAddrDomain=$fromAddrDomain");
>> if ( $fromNameDomain eq "" ) {
>> return 0; # all well
>> } else {
>> if( $fromNameDomain eq $fromAddrDomain ) {
>> return 0; # all well, they match
>> } else {
>> return 1; # mismatch, possibly spam
>> }
>> }
>> }
>>
>> R.G.
>>
>>
>
> This looks like a simple and valuable approach that should be
> considered for inclusion into SA for everyone. Do you mind opening up
> a bug at https://bz.apache.org/SpamAssassin/ in the Plugins section?
>
> We could put this in for everyone with a low score and give it a trial
> run before increasing the score. I will run it locally as well and
> see how it goes.
>
>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> -------- Original Message --------
>> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>>
>>> Would a plugin need to be created (or an existing one enhanced) to be
>>> able to detect this type of spoofed From header?
>>>
>>> From: "hulu@hulumail.com <ma...@hulumail.com> !"
>>> lanya-f@hotmail.com <ma...@hotmail.com>
>>>
>>>
>>>
>>> https://pastebin.com/vVhGjC8H
>>>
>>> Does anyone else think this would be a good idea to make a rule
>>> that at
>>> least checks both the From:name and From:addr to see if there is an
>>> email address in the From:name and if the domain is different
>>> add some
>>> points?
>>>
>>> We are seeing more and more of this now that SPF, DKIM, and
>>> DMARC are
>>> making it harder to spoof common/major brands that have properly
>>> implemented some or all of them.
>>>
>>> David Jones
>>
>
Re: From name containing a spoofed email address
Posted by David Jones <dj...@ena.com>.
On 01/22/2018 09:05 AM, Rupert Gallagher wrote:
> This is my current solution for a problem that has been discussed many
> times in this list.
> I wrote it last year, and it serves me well. Feel free to use it, if you
> find it useful.
>
> This part goes into your local.cf:
>
> header __F_DM1 eval:from_domains_mismatch()
> header __F_DM2 From:addr =~ /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
> meta F_DM ( __F_DM1 && ! __F_DM2 )
> describe F_DM From:name domain mismatches From:addr domain
> priority F_DM -1
> score F_DM 5.0
>
> This part goes into the general HeaderEval.pm:
>
> $self->register_eval_rule("from_domains_mismatch");
> [...]
> sub from_domains_mismatch {
> my ($self, $pms) = @_;
> my $temp;
> $temp = $pms->get('From:addr');
> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> $temp = $pms->get('From:name');
> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
> fromAddrDomain=$fromAddrDomain");
> if ( $fromNameDomain eq "" ) {
> return 0; # all well
> } else {
> if( $fromNameDomain eq $fromAddrDomain ) {
> return 0; # all well, they match
> } else {
> return 1; # mismatch, possibly spam
> }
> }
> }
>
> R.G.
>
>
This looks like a simple and valuable approach that should be considered
for inclusion into SA for everyone. Do you mind opening up a bug at
https://bz.apache.org/SpamAssassin/ in the Plugins section?
We could put this in for everyone with a low score and give it a trial
run before increasing the score. I will run it locally as well and see
how it goes.
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> -------- Original Message --------
> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>
>> Would a plugin need to be created (or an existing one enhanced) to be
>> able to detect this type of spoofed From header?
>>
>> From: "hulu@hulumail.com <ma...@hulumail.com> !"
>> lanya-f@hotmail.com <ma...@hotmail.com>
>>
>>
>>
>> https://pastebin.com/vVhGjC8H
>>
>> Does anyone else think this would be a good idea to make a rule
>> that at
>> least checks both the From:name and From:addr to see if there is an
>> email address in the From:name and if the domain is different add some
>> points?
>>
>> We are seeing more and more of this now that SPF, DKIM, and DMARC are
>> making it harder to spoof common/major brands that have properly
>> implemented some or all of them.
>>
>> David Jones
>
--
David Jones
Re: From name containing a spoofed email address
Posted by Jeffs Chips <je...@gmail.com>.
Hi Robert. I'm new here. But intrigued by what looks like a good solution.
Without too much detail can you explain the solution a bit? Just want to
get a basic understanding of the workflow. Thank you.
__________________
"Perhaps sleep did not evolve. Perhaps it was the thing from which
wakefulness emerged.” -- Matthew Walker, Sleep Scientist
On Jan 22, 2018 10:05 AM, "Rupert Gallagher" <ru...@protonmail.com> wrote:
> This is my current solution for a problem that has been discussed many
> times in this list.
> I wrote it last year, and it serves me well. Feel free to use it, if you
> find it useful.
>
> This part goes into your local.cf:
>
> header __F_DM1 eval:from_domains_mismatch()
> header __F_DM2 From:addr =~ /\@(pec|legalmail|telecompost)
> (\.[^\.]+)?\.it/
> meta F_DM ( __F_DM1 && ! __F_DM2 )
> describe F_DM From:name domain mismatches From:addr domain
> priority F_DM -1
> score F_DM 5.0
>
> This part goes into the general HeaderEval.pm:
>
> $self->register_eval_rule("from_domains_mismatch");
> [...]
> sub from_domains_mismatch {
> my ($self, $pms) = @_;
> my $temp;
> $temp = $pms->get('From:addr');
> $temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
> $temp = $pms->get('From:name');
> $temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
> dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain,
> fromAddrDomain=$fromAddrDomain");
> if ( $fromNameDomain eq "" ) {
> return 0; # all well
> } else {
> if( $fromNameDomain eq $fromAddrDomain ) {
> return 0; # all well, they match
> } else {
> return 1; # mismatch, possibly spam
> }
> }
> }
>
> R.G.
>
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> -------- Original Message --------
> On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
>
> Would a plugin need to be created (or an existing one enhanced) to be
> able to detect this type of spoofed From header?
>
> From: "hulu@hulumail.com !" lanya-f@hotmail.com
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at
> least checks both the From:name and From:addr to see if there is an
> email address in the From:name and if the domain is different add some
> points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are
> making it harder to spoof common/major brands that have properly
> implemented some or all of them.
>
> David Jones
>
>
>
Re: From name containing a spoofed email address
Posted by David Jones <dj...@ena.com>.
On 01/22/2018 06:40 PM, Alex wrote:
> Hi,
>
>> This part goes into the general HeaderEval.pm:
>>
>> $self->register_eval_rule("from_domains_mismatch");
>> [...]
>
> I'd like to try this, but this is not in the current 3.4.2 svn.
>
I am running this by manually patching the HeaderEval.pm and so far it's
finding a lot of FPs in the short time it has been in place.
I know everyone's mail flow is different but I am not sure it's going to
be useful as a spam indicator on it's own for inclusion in the SA core
distribution. It would need to be combined with commonly spoofed brands
like Fedex, Dropbox, banks, etc. This would require someone maintain a
regex in the public SA rulesets that the spammers could easily get around.
I am trying to solve this spoofing problem by adding commonly spoofed
and safe senders to the 60_whitelist_auth.cf as I find them and manually
verify them. But this is only part of the equation that is subtracting
points for authentic senders. The other side is safely adding points
for those spoofing emails. Again, this may not work in the public SA
rulesets since it's documentation for the spammers.
--
David Jones
Re: From name containing a spoofed email address
Posted by sh...@shanew.net.
Just to add to the confusion, uh, I mean options. Here's what I've
got so far. I'm using it in production currently, but it's still very
young code, so use it at your own risk.
https://github.com/enkidushane/sa-frommismatch/
I purposely avoided using uri_to_domain because it's in flux right
now, but I might go back and add a version check to make use of it.
As I mentioned to Paul privately, seeing others' code strengthens my
opinion that the hard part here is recognizing when an email address /
domain actually needs to be checked. For instance, I require "@" to
be immediately followed be a valid domain character. This avoids
false positives on things like "Events @ GA" (example from my email
stream); on the other hand, it would miss something like "Bob @
usaa.com".
If you try out my plugin, be warned that you will likely get
false-positives on yahoogroups.com. I have yet to decide whether
detection of exceptions like this should be happening in the plugin,
or via some meta combination of rules. If you hit other false
positives, I'd be interested to hear about them.
On Mon, 22 Jan 2018, Alex wrote:
> Hi,
>
>> This part goes into the general HeaderEval.pm:
>>
>> $self->register_eval_rule("from_domains_mismatch");
>> [...]
>
> I'd like to try this, but this is not in the current 3.4.2 svn.
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: From name containing a spoofed email address
Posted by Alex <my...@gmail.com>.
Hi,
> This part goes into the general HeaderEval.pm:
>
> $self->register_eval_rule("from_domains_mismatch");
> [...]
I'd like to try this, but this is not in the current 3.4.2 svn.
Re: From name containing a spoofed email address
Posted by Rupert Gallagher <ru...@protonmail.com>.
This is my current solution for a problem that has been discussed many times in this list.
I wrote it last year, and it serves me well. Feel free to use it, if you find it useful.
This part goes into your local.cf:
header __F_DM1 eval:from_domains_mismatch()
header __F_DM2 From:addr =~ /\@(pec|legalmail|telecompost)(\.[^\.]+)?\.it/
meta F_DM ( __F_DM1 && ! __F_DM2 )
describe F_DM From:name domain mismatches From:addr domain
priority F_DM -1
score F_DM 5.0
This part goes into the general HeaderEval.pm:
$self->register_eval_rule("from_domains_mismatch");
[...]
sub from_domains_mismatch {
my ($self, $pms) = @_;
my $temp;
$temp = $pms->get('From:addr');
$temp =~ /@(.+)/; my $fromAddrDomain; $fromAddrDomain = "$1";
$temp = $pms->get('From:name');
$temp =~ /@([^\@\"\s]+)/; my $fromNameDomain; $fromNameDomain = "$1";
dbg("from_domains_mismatch: fromNameDomain=$fromNameDomain, fromAddrDomain=$fromAddrDomain");
if ( $fromNameDomain eq "" ) {
return 0; # all well
} else {
if( $fromNameDomain eq $fromAddrDomain ) {
return 0; # all well, they match
} else {
return 1; # mismatch, possibly spam
}
}
}
R.G.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
On 17 January 2018 8:31 PM, David Jones <dj...@ena.com> wrote:
> Would a plugin need to be created (or an existing one enhanced) to be
> able to detect this type of spoofed From header?
>
> From: ["hulu@hulumail.com](mailto:%22hulu@hulumail.com) !" lanya-f@hotmail.com
>
> https://pastebin.com/vVhGjC8H
>
> Does anyone else think this would be a good idea to make a rule that at
> least checks both the From:name and From:addr to see if there is an
> email address in the From:name and if the domain is different add some
> points?
>
> We are seeing more and more of this now that SPF, DKIM, and DMARC are
> making it harder to spoof common/major brands that have properly
> implemented some or all of them.
>
> David Jones
Re: From name containing a spoofed email address
Posted by Rupert Gallagher <ru...@protonmail.com>.
Empty Message
Re: From name containing a spoofed email address
Posted by Antony Stone <An...@spamassassin.open.source.it>.
On Friday 19 January 2018 at 07:40:07, Rupert Gallagher wrote:
> See my post of 25/20/2017 to this list.
My calendar doesn't go that far :(
Antony.
--
I wasn't sure about having a beard at first, but then it grew on me.
Please reply to the list;
please *don't* CC me.
Re: From name containing a spoofed email address
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Jan 2018, at 10:20 (-0500), Rupert Gallagher wrote:
> Empty Message
You're repeating yourself...
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: From name containing a spoofed email address
Posted by Rupert Gallagher <ru...@protonmail.com>.
Empty Message
Re: From name containing a spoofed email address
Posted by Rupert Gallagher <ru...@protonmail.com>.
See my post of 25/20/2017 to this list.
Sent from ProtonMail Mobile
On Wed, Jan 17, 2018 at 20:31, David Jones <dj...@ena.com> wrote:
> Would a plugin need to be created (or an existing one enhanced) to be able to detect this type of spoofed From header? From: "hulu@hulumail.com !" https://pastebin.com/vVhGjC8H Does anyone else think this would be a good idea to make a rule that at least checks both the From:name and From:addr to see if there is an email address in the From:name and if the domain is different add some points? We are seeing more and more of this now that SPF, DKIM, and DMARC are making it harder to spoof common/major brands that have properly implemented some or all of them. -- David Jones @hotmail.com>