You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Robert Fitzpatrick <ro...@webtent.org> on 2018/11/16 13:44:52 UTC
Forgery with SPF/DKIM/DMARC
We're having an issue with spam coming from the same company even though
SPF and DKIM is setup with DMARC to reject. Take this forwarded email
for instances....
> -------- Original message --------
> From: User <Us...@company.com>
> Date: 11/15/18 10:42 AM (GMT-07:00)
> To: Other User <ot...@company.com>
> Subject: OVERDUE INVOICE
>
> Sorry for the delay…. This is an invoice reminder. The total for your item is $1,879.17.
>
> THX,
>
> -
>
> User
> T 123.456.7890 | O 123.456.7891
> EMail:User@company.com
However, the raw headers show as this...
> Date: Thu, 15 Nov 2018 18:35:35 +0100
> From: User <Us...@company.com>
> <ar...@creativegroup.com.ec>
> To: other.user@company.com
> Message-ID: <86...@company.com>
> Subject: OVERDUE INVOICE
Could someone suggest a rule to match the signature with the last From
email or envelope from? Or another suggestion how this could be resolved.
Thanks!
--
Robert
Re: Forgery with SPF/DKIM/DMARC
Posted by Dominic Raferd <do...@timedicer.co.uk>.
On Fri, 16 Nov 2018 at 15:54, Robert Fitzpatrick <ro...@webtent.org> wrote:
>
> Dominic Raferd wrote on 11/16/2018 8:50 AM>
> > Please clarify what you mean by 'even though SPF and DKIM is setup
> > with DMARC to reject'? I presume that 'company.com' does not have a
> > DMARC p=reject policy, or else your DMARC program (e.g. opendmarc)
> > should block forged emails from them.
> >
>
> Oh yes, sorry, the names changed to protect the innocent. But now that I
> am confirming, I don't see the _dmarc record setup by the DNS company as
> requested. So, this message with would fail DMARC if setup for
> company.com to reject as you noted? I'll send them the request again and
> see, thanks.
In principle I recommend that everyone set up dmarc with p=reject for
their domains, but it is not to be undertaken lightly because it can
lead to rejection of their genuine but misconfigured emails (and cause
particular problems on mailing lists). I think your request to the
third party is unlikely to have any effect, and the problem you are
having needs to be tackled a different way.
Re: Forgery with SPF/DKIM/DMARC
Posted by Robert Fitzpatrick <ro...@webtent.org>.
Dominic Raferd wrote on 11/16/2018 8:50 AM>
> Please clarify what you mean by 'even though SPF and DKIM is setup
> with DMARC to reject'? I presume that 'company.com' does not have a
> DMARC p=reject policy, or else your DMARC program (e.g. opendmarc)
> should block forged emails from them.
>
Oh yes, sorry, the names changed to protect the innocent. But now that I
am confirming, I don't see the _dmarc record setup by the DNS company as
requested. So, this message with would fail DMARC if setup for
company.com to reject as you noted? I'll send them the request again and
see, thanks.
--
Robert
Re: Forgery with SPF/DKIM/DMARC
Posted by Dominic Raferd <do...@timedicer.co.uk>.
On Fri, 16 Nov 2018 at 13:45, Robert Fitzpatrick <ro...@webtent.org> wrote:
>
> We're having an issue with spam coming from the same company even though
> SPF and DKIM is setup with DMARC to reject. Take this forwarded email
> for instances....
>
> > -------- Original message --------
> > From: User <Us...@company.com>
> > Date: 11/15/18 10:42 AM (GMT-07:00)
> > To: Other User <ot...@company.com>
> > Subject: OVERDUE INVOICE
> >
> > Sorry for the delay…. This is an invoice reminder. The total for your item is $1,879.17.
> >
> > THX,
> >
> > -
> >
> > User
> > T 123.456.7890 | O 123.456.7891
> > EMail:User@company.com
>
> However, the raw headers show as this...
>
> > Date: Thu, 15 Nov 2018 18:35:35 +0100
> > From: User <Us...@company.com>
> > <ar...@creativegroup.com.ec>
> > To: other.user@company.com
> > Message-ID: <86...@company.com>
> > Subject: OVERDUE INVOICE
>
> Could someone suggest a rule to match the signature with the last From
> email or envelope from? Or another suggestion how this could be resolved.
>
> Thanks!
Please clarify what you mean by 'even though SPF and DKIM is setup
with DMARC to reject'? I presume that 'company.com' does not have a
DMARC p=reject policy, or else your DMARC program (e.g. opendmarc)
should block forged emails from them.
Re: Forgery with SPF/DKIM/DMARC
Posted by RW <rw...@googlemail.com>.
On Fri, 16 Nov 2018 10:39:47 -0500
Kris Deugau wrote:
> From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
> ...
> Looking at a couple of other examples, there are also some in the
> form:
>
> From: =?UTF-8?B?[encoded stuff]= <cr...@example.com>
>
> where [encoded stuff] decodes to:
>
> Some User <sp...@example.org>
I think this is worth a try:
header FROM_NO_COMMA From =~ />\s*<[^"]*$/
Re: Forgery with SPF/DKIM/DMARC
Posted by Kris Deugau <kd...@vianet.ca>.
RW wrote:
> On Fri, 16 Nov 2018 08:44:52 -0500
> Robert Fitzpatrick wrote:
>
>> We're having an issue with spam coming from the same company even
>> though SPF and DKIM is setup with DMARC to reject. Take this
>> forwarded email for instances....
[ fake invoice email ]
SPF and DKIM rarely return "fail" on these because the envelope sender
either doesn't publish either, or publishes them and they match. SPF in
particular would usually have nothing to do with the "obvious" From:
address that most people would look at.
> This is a pretty confusing question because it has nothing to do with
> DMARC, SPF, or DKIM, and "same company" reads like "consistent
> spammer".
>
> I think what you're getting at is the use of a local address in the
> author display name:
>
>> From: User <Us...@company.com> <ar...@creativegroup.com.ec>
>> To: other.user@company.com
>
> Did you actually mean that precise form, which looks invalid,
This certainly sounds like a series of fake invoice mails I've been
getting a trickle of reports for, and if so, then yes, that is literally
exactly what's in the original.
I dug through my reporting account's history and found one that came
directly to my own account:
Delivered-To: kdeugau@vianet.ca
Return-Path: <ca...@corpmaqplast.com>
Received: from mail.vianet.ca [209.91.128.17]
by pod.pem-lan with POP3 (fetchmail-6.3.26)
for <kd...@localhost> (single-drop); Tue, 06 Nov 2018 09:05:12 -0500
(EST)
Received: from rla3.dizinc.com (rla3.dizinc.com [72.29.77.172]) by
mx1.vianet.ca (Postfix) with ESMTPS id 83FE2E24D6 for <kd...@vianet.ca>;
Tue, 6 Nov 2018 09:03:08 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=corpmaqplast.com; s=default;
h=Content-Type:MIME-Version:Subject:Message-ID
:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=+EAmfCv8FqMxiASYoMWTcRGrgS++5JXOIOM7h8kgXyw=;
b=n/4UOgM/LfvfnVl8gzWrv7uU/P
6GL1HJgU4KMmU/hsZR6sG5y/ijG09RLmuMK1OAoYULC8P4BewtmtfsDElVGXHU9P3EG6poaMliWeM
RRxcaV8/DMUiFOa2O8Y1Q9F4OXpI8t19pAchCaR+OFs34+Npjwad/wkX/+E82uWs57gs0VJMH76z9
UVynTFc+hRbwEFGdYPi+Gnc+fpvtbO7RN0pqcNOjLQWdEr2RcO2yg1hCPUs6z8HJ7gNYT1Wx7DQEj
y6adnz0tG+sLmqsYYC/67cJYdgHuEfUvUIlCCRVgV38BXGJiDoRSsz6txHAaCYa7bXHZ892FN9EbC
CIVnco0Q==;
Received: from [187.217.80.180] (port=3340 helo=10.1.34.37) by
rla3.dizinc.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim
4.91) (envelope-from <ca...@corpmaqplast.com>) id 1gK1wg-00073v-8J for
kdeugau@vianet.ca; Tue, 06 Nov 2018 08:03:07 -0600
Date: Tue, 06 Nov 2018 14:03:06 +0000
From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
To: kdeugau@vianet.ca
Message-ID: <35...@vianet.ca>
Subject: John D. Smith Factures 0611-KDG47168618-939
In this instance SPF and DKIM passed, so whatever policies richland.edu
might publish they're irrelevant and not checked.
This particular subseries also has an attached Word document, which is
now getting flagged by ClamAV, but IIRC there have been a few that were
either "just" phishing, or linked to malware instead of attaching it to
the message.
Looking at a couple of other examples, there are also some in the form:
From: =?UTF-8?B?[encoded stuff]= <cr...@example.com>
where [encoded stuff] decodes to:
Some User <sp...@example.org>
-kgd
Re: Forgery with SPF/DKIM/DMARC
Posted by RW <rw...@googlemail.com>.
On Fri, 16 Nov 2018 08:44:52 -0500
Robert Fitzpatrick wrote:
> We're having an issue with spam coming from the same company even
> though SPF and DKIM is setup with DMARC to reject. Take this
> forwarded email for instances....
This is a pretty confusing question because it has nothing to do with
DMARC, SPF, or DKIM, and "same company" reads like "consistent
spammer".
I think what you're getting at is the use of a local address in the
author display name:
> From: User <Us...@company.com> <ar...@creativegroup.com.ec>
> To: other.user@company.com
Did you actually mean that precise form, which looks invalid, or did you
mean one of:
From: "User <Us...@company.com>" <ar...@creativegroup.com.ec>
From: User <Us...@company.com>, <ar...@creativegroup.com.ec>
Re: Forgery with SPF/DKIM/DMARC
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 16.11.18 08:44, Robert Fitzpatrick wrote:
>We're having an issue with spam coming from the same company even
>though SPF and DKIM is setup with DMARC to reject. Take this forwarded
>email for instances....
does the mail pass or fail SPF and DKIM?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete
Re: Forgery with SPF/DKIM/DMARC
Posted by RW <rw...@googlemail.com>.
On Sat, 17 Nov 2018 13:22:55 +0000
David Jones wrote:
> 2. Seems like there should be easy rules to detect more than one pair
> of angle brackets and more than on at sign to add points to
> non-standard display names.
The reason I asked about the precise form is that it's not simply
a bracketed address in the display name, the brackets need quoting so
it's not syntactically correct either.
The rule I suggested:
header FROM_NO_COMMA From =~ />\s*<[^"]*$/
targets that specific case.
The NO_COMMA part is because
From: User <Us...@company.com>, <ar...@creativegroup.com.ec>
would be unusual, but it's legitimate and no use to a spammer because it
can fail DMARC on either domain.
Re: Forgery with SPF/DKIM/DMARC
Posted by John Hardin <jh...@impsec.org>.
On Sat, 17 Nov 2018, David Jones wrote:
> On 11/17/18 9:52 AM, John Hardin wrote:
>>> From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
>>> To: kdeugau@vianet.ca
>>> Message-ID: <35...@vianet.ca>
>>>
>>> Couple of things:
>>> 1. Recent discussions on this mailing list showed me that the Message-ID
>>> should never have the recipient's domain in it
>>
>> That's not 100% true.
>>
>> There is no requirement that the sender put a Message-ID on the message.
>> It is valid for your MTA to add a Message-ID onto a message that was
>> received without one. That is likely going to be done using your domain.
>>
>
> Sure. Real MTA/MUA's should be setting a Message-ID header else it will
> look very spammy. Copiers, scanners, and other basic SMTP-enabled
> devices often don't put all of the "standard" headers in their messages
> so they have to be whitelisted safely.
>
> My Postfix MTA doesn't add the Message-ID header and even if it did, it
> would be something like "ena.net" that is not going to match the dozens
> of domains that I filter.
Yeah, in your case it's probably safe to do in SA.
> This strategy seems to have helped stop this type of spam so far without
> over blocking.
>
>> I'd suggest a filter on Message-ID domain would be more appropriate at
>> the MTA level than in SA - if a message is received from outside with a
>> Message-ID having a domain that you control, reject it at that point,
>> before the possibility of adding a local one because it's missing
>> becomes a source of ambiguity.
>>
> I am using MailScanner so that is a drawback not being able to reject
> during the SMTP conversation.
I don't consider MailScanner to be "at the MTA level". I'm not familiar
with PostScript but I'm sure there's a way to configure it to do a check
like that during the SMTP conversation before any external
message-processing tools are called.
> I do try to reject as much as I can at
> the MTA so MailScanner and SA only have to block the tough ones. Most
> spam scores above 30 which is not going to be missed by anyone (not
> something they are expecting to receive).
>
>> I do something similar with HELO. You might want to look into that too -
>> check your logs for the HELOs that spammers are using, there are
>> low-hanging fruit there (that I'm reluctant to discuss publicly).
>
> Interesting. I may have to make some time over the holidays to research
> this a bit more in my logs. My mail filtering is pretty spot on right
> now but if anything gets through I will check the HELO details. Most of
> the things that get through now are zero-hour messages from compromised
> accounts so those HELO's are going to be good and everything else
> (FCrDNS, SPF, DKIM, DMARC) will be legit and pass. I am thinking of
> increasing the time on greylisting to give DCC and RBLs time to catch up
> with compromise accounts.
>
>>> 2. Seems like there should be easy rules to detect more than one pair of
>>> angle brackets and more than on at sign to add points to non-standard
>>> display names.
>>
>> There probably are. A big question is: does that appear enough in the
>> masscheck corpora to be promoted as a useful rule?
>
> I think my ena-week[0-4] (past 5 weeks) masscheckers are still the
> majority of the overall masscheck corpora. I need some help planting
> email addresses out there that will attract more spam of differing types
> or something. I definitely need to get more non-English spam in there.
Heh. Rather than (or in addition to) reject at the MTA level you should be
dumping them into your spam corpora (if you're not already doing that).
We also badly need non-English *ham*.
--
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
-----------------------------------------------------------------------
Usually Microsoft doesn't develop products, we buy products.
-- Arno Edelmann, Microsoft product manager
-----------------------------------------------------------------------
597 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: Forgery with SPF/DKIM/DMARC
Posted by David Jones <dj...@ena.com>.
On 11/17/18 9:52 AM, John Hardin wrote:
>> From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
>> To: kdeugau@vianet.ca
>> Message-ID: <35...@vianet.ca>
>>
>> Couple of things:
>> 1. Recent discussions on this mailing list showed me that the Message-ID
>> should never have the recipient's domain in it
>
> That's not 100% true.
>
> There is no requirement that the sender put a Message-ID on the message.
> It is valid for your MTA to add a Message-ID onto a message that was
> received without one. That is likely going to be done using your domain.
>
Sure. Real MTA/MUA's should be setting a Message-ID header else it will
look very spammy. Copiers, scanners, and other basic SMTP-enabled
devices often don't put all of the "standard" headers in their messages
so they have to be whitelisted safely.
My Postfix MTA doesn't add the Message-ID header and even if it did, it
would be something like "ena.net" that is not going to match the dozens
of domains that I filter.
This strategy seems to have helped stop this type of spam so far without
over blocking.
> I'd suggest a filter on Message-ID domain would be more appropriate at
> the MTA level than in SA - if a message is received from outside with a
> Message-ID having a domain that you control, reject it at that point,
> before the possibility of adding a local one because it's missing
> becomes a source of ambiguity.
>
I am using MailScanner so that is a drawback not being able to reject
during the SMTP conversation. I do try to reject as much as I can at
the MTA so MailScanner and SA only have to block the tough ones. Most
spam scores above 30 which is not going to be missed by anyone (not
something they are expecting to receive).
> I do something similar with HELO. You might want to look into that too -
> check your logs for the HELOs that spammers are using, there are
> low-hanging fruit there (that I'm reluctant to discuss publicly).
>
Interesting. I may have to make some time over the holidays to research
this a bit more in my logs. My mail filtering is pretty spot on right
now but if anything gets through I will check the HELO details. Most of
the things that get through now are zero-hour messages from compromised
accounts so those HELO's are going to be good and everything else
(FCrDNS, SPF, DKIM, DMARC) will be legit and pass. I am thinking of
increasing the time on greylisting to give DCC and RBLs time to catch up
with compromise accounts.
>> 2. Seems like there should be easy rules to detect more than one pair of
>> angle brackets and more than on at sign to add points to non-standard
>> display names.
>
> There probably are. A big question is: does that appear enough in the
> masscheck corpora to be promoted as a useful rule?
>
I think my ena-week[0-4] (past 5 weeks) masscheckers are still the
majority of the overall masscheck corpora. I need some help planting
email addresses out there that will attract more spam of differing types
or something. I definitely need to get more non-English spam in there.
--
David Jones
Re: Forgery with SPF/DKIM/DMARC
Posted by John Hardin <jh...@impsec.org>.
On Sat, 17 Nov 2018, David Jones wrote:
> On 11/16/18 7:44 AM, Robert Fitzpatrick wrote:
>> We're having an issue with spam coming from the same company even though
>> SPF and DKIM is setup with DMARC to reject. Take this forwarded email
>> for instances....
>>
>>> -------- Original message -------- From: User <Us...@company.com> Date:
>>> 11/15/18 10:42 AM (GMT-07:00) To: Other User <ot...@company.com>
>>> Subject: OVERDUE INVOICE
>>> Sorry for the delay…. This is an invoice reminder. The total for your
>>> item is $1,879.17.
>>> THX,
>>> -
>>> User T 123.456.7890 | O 123.456.7891 EMail:User@company.com
>>
>> However, the raw headers show as this...
>>
>>> Date: Thu, 15 Nov 2018 18:35:35 +0100
>>> From: User <Us...@company.com>
>>> <ar...@creativegroup.com.ec>
>>> To: other.user@company.com
>>> Message-ID: <86...@company.com>
>>> Subject: OVERDUE INVOICE
>>
>> Could someone suggest a rule to match the signature with the last From
>> email or envelope from? Or another suggestion how this could be resolved.
>>
>> Thanks!
>>
>
>
> From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
> To: kdeugau@vianet.ca
> Message-ID: <35...@vianet.ca>
>
> Couple of things:
> 1. Recent discussions on this mailing list showed me that the Message-ID
> should never have the recipient's domain in it
That's not 100% true.
There is no requirement that the sender put a Message-ID on the message.
It is valid for your MTA to add a Message-ID onto a message that was
received without one. That is likely going to be done using your domain.
I'd suggest a filter on Message-ID domain would be more appropriate at the
MTA level than in SA - if a message is received from outside with a
Message-ID having a domain that you control, reject it at that point,
before the possibility of adding a local one because it's missing becomes
a source of ambiguity.
I do something similar with HELO. You might want to look into that too -
check your logs for the HELOs that spammers are using, there are
low-hanging fruit there (that I'm reluctant to discuss publicly).
> 2. Seems like there should be easy rules to detect more than one pair of
> angle brackets and more than on at sign to add points to non-standard
> display names.
There probably are. A big question is: does that appear enough in the
masscheck corpora to be promoted as a useful rule?
> 3. I add a point or two for invoice-related subjects just because I want
> to lower the bar for them being caught. Legit invoice senders should
> have other good rules hit that will offset this. I try to make legit
> invoice senders score just below the block threshold so anything
> suspicious like that From: or Message-ID: header will push it over the
> limit.
> You can setup logwatch or grep your mail logs often from cron to alert
> you when your invoice-related rules are hit so you don't cause a problem
> blocking a real invoice in the first month or two as you are tuning your
> rules and scores.
Good suggestions.
--
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
-----------------------------------------------------------------------
Windows and its users got mentioned at home today, after my wife the
psych major brought up Seligman's theory of "learned helplessness."
-- Dan Birchall in a.s.r
-----------------------------------------------------------------------
597 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: Forgery with SPF/DKIM/DMARC
Posted by David Jones <dj...@ena.com>.
On 11/16/18 7:44 AM, Robert Fitzpatrick wrote:
> We're having an issue with spam coming from the same company even though
> SPF and DKIM is setup with DMARC to reject. Take this forwarded email
> for instances....
>
>> -------- Original message -------- From: User <Us...@company.com> Date:
>> 11/15/18 10:42 AM (GMT-07:00) To: Other User <ot...@company.com>
>> Subject: OVERDUE INVOICE
>> Sorry for the delay…. This is an invoice reminder. The total for your
>> item is $1,879.17.
>> THX,
>> -
>> User T 123.456.7890 | O 123.456.7891 EMail:User@company.com
>
> However, the raw headers show as this...
>
>> Date: Thu, 15 Nov 2018 18:35:35 +0100
>> From: User <Us...@company.com>
>> <ar...@creativegroup.com.ec>
>> To: other.user@company.com
>> Message-ID: <86...@company.com>
>> Subject: OVERDUE INVOICE
>
> Could someone suggest a rule to match the signature with the last From
> email or envelope from? Or another suggestion how this could be resolved.
>
> Thanks!
>
From: John D. Smith <jo...@richland.edu> <ca...@corpmaqplast.com>
To: kdeugau@vianet.ca
Message-ID: <35...@vianet.ca>
Couple of things:
1. Recent discussions on this mailing list showed me that the Message-ID
should never have the recipient's domain in it so I setup a local meta
rule to match all of my customer domains that I filter for with an
inbound rule (like ALL_TRUSTED) to add a bunch of points.
2. Seems like there should be easy rules to detect more than one pair of
angle brackets and more than on at sign to add points to non-standard
display names.
3. I add a point or two for invoice-related subjects just because I want
to lower the bar for them being caught. Legit invoice senders should
have other good rules hit that will offset this. I try to make legit
invoice senders score just below the block threshold so anything
suspicious like that From: or Message-ID: header will push it over the
limit.
You can setup logwatch or grep your mail logs often from cron to alert
you when your invoice-related rules are hit so you don't cause a problem
blocking a real invoice in the first month or two as you are tuning your
rules and scores.
--
David Jones