Re: Forgery with SPF/DKIM/DMARC
On Sat, 17 Nov 2018 13:22:55 + 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 , 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
On Sat, 17 Nov 2018, David Jones wrote: On 11/17/18 9:52 AM, John Hardin wrote: From: John D. Smith To: kdeu...@vianet.ca Message-ID: <35706717752563516902.8f4660866aa84...@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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
On 11/17/18 9:52 AM, John Hardin wrote: >> From: John D. Smith >> To: kdeu...@vianet.ca >> Message-ID: <35706717752563516902.8f4660866aa84...@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
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 Date: 11/15/18 10:42 AM (GMT-07:00) To: Other User 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:u...@company.com However, the raw headers show as this... Date: Thu, 15 Nov 2018 18:35:35 +0100 From: User To: other.u...@company.com Message-ID: <860909106225419267.2007038e08376...@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 To: kdeu...@vianet.ca Message-ID: <35706717752563516902.8f4660866aa84...@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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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 Date: >> 11/15/18 10:42 AM (GMT-07:00) To: Other User >> 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:u...@company.com > > However, the raw headers show as this... > >> Date: Thu, 15 Nov 2018 18:35:35 +0100 >> From: User >> >> To: other.u...@company.com >> Message-ID: <860909106225419267.2007038e08376...@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 To: kdeu...@vianet.ca Message-ID: <35706717752563516902.8f4660866aa84...@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
Re: Forgery with SPF/DKIM/DMARC
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, uh...@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
On Fri, 16 Nov 2018 10:39:47 -0500 Kris Deugau wrote: > From: John D. Smith > ... > Looking at a couple of other examples, there are also some in the > form: > > From: =?UTF-8?B?[encoded stuff]= > > where [encoded stuff] decodes to: > > Some User I think this is worth a try: header FROM_NO_COMMA From =~ />\s*<[^"]*$/
Re: Forgery with SPF/DKIM/DMARC
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
On Fri, 16 Nov 2018 at 15:54, Robert Fitzpatrick 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
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 To: other.u...@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: kdeu...@vianet.ca Return-Path: Received: from mail.vianet.ca [209.91.128.17] by pod.pem-lan with POP3 (fetchmail-6.3.26) for (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 ; 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 ) id 1gK1wg-00073v-8J for kdeu...@vianet.ca; Tue, 06 Nov 2018 08:03:07 -0600 Date: Tue, 06 Nov 2018 14:03:06 + From: John D. Smith To: kdeu...@vianet.ca Message-ID: <35706717752563516902.8f4660866aa84...@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]= where [encoded stuff] decodes to: Some User -kgd
Re: Forgery with SPF/DKIM/DMARC
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 > To: other.u...@company.com Did you actually mean that precise form, which looks invalid, or did you mean one of: From: "User " From: User ,
Re: Forgery with SPF/DKIM/DMARC
On Fri, 16 Nov 2018 at 13:45, 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 > > Date: 11/15/18 10:42 AM (GMT-07:00) > > To: Other User > > 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:u...@company.com > > However, the raw headers show as this... > > > Date: Thu, 15 Nov 2018 18:35:35 +0100 > > From: User > > > > To: other.u...@company.com > > Message-ID: <860909106225419267.2007038e08376...@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.
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 Date: 11/15/18 10:42 AM (GMT-07:00) To: Other User 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:u...@company.com However, the raw headers show as this... Date: Thu, 15 Nov 2018 18:35:35 +0100 From: User To: other.u...@company.com Message-ID: <860909106225419267.2007038e08376...@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