spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Deugau <>
Subject Re: Forgery with SPF/DKIM/DMARC
Date Fri, 16 Nov 2018 15:39:47 GMT
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:
> 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:

Return-Path: <>
Received: from []
	by pod.pem-lan with POP3 (fetchmail-6.3.26)
	for <kdeugau@localhost> (single-drop); Tue, 06 Nov 2018 09:05:12 -0500 
Received: from ( []) by (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;; s=default; 
Received: from [] (port=3340 helo= by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) 
  4.91) (envelope-from <>) id 1gK1wg-00073v-8J for; Tue, 06 Nov 2018 08:03:07 -0600
Date: Tue, 06 Nov 2018 14:03:06 +0000
From: John D. Smith <> <>
Message-ID: <>
Subject: John D. Smith Factures 0611-KDG47168618-939

In this instance SPF and DKIM passed, so whatever policies 
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 <>


View raw message