Re: [dmarc-ietf] Rethinking DMARC for PSDs

"Douglas E. Foster" <> Mon, 08 April 2019 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E951200D7 for <>; Mon, 8 Apr 2019 04:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6RP6N2fQNMKm for <>; Mon, 8 Apr 2019 04:02:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F46F12006D for <>; Mon, 8 Apr 2019 04:02:37 -0700 (PDT)
X-ASG-Debug-ID: 1554721355-0990573e633e780001-K2EkT1
Received: from ( []) by with ESMTP id ooieDBf8DYjDEotm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 07:02:35 -0400 (EDT)
X-ASG-Whitelist: Client
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=gdxLJzaMc/QDG539l2WTeyk5cBHQI1hpykjWW1pH5hc=; b=UmnJW1NDCdqEMprjynkFcPjUVN2SuoY/Xz7qwQsDmxmPlzqS/Jwc8Ncr2Hq7Qu/rI Cw37x6+QHB3hxt4CfcnBVRYppC/QUnFU34DHvyte+YWU6IkEaiQp+2h5stpwXlgxa gXbvRLFWOFGJM4rv0lkkVD30PEi3j3sjF07B7+4dA=
Received: by via HTTP; Mon, 8 Apr 2019 07:02:26 -0400
From: "Douglas E. Foster" <>
To: <>, "John Levine" <>
Date: Mon, 8 Apr 2019 07:02:26 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=0c98ee675aff48e8a15f888fc383b12c
X-Originating-IP: []
In-Reply-To: <20190408005045.5EC462011B2BFE@ary.qy>
References: <20190408005045.5EC462011B2BFE@ary.qy>
X-Exim-Id: 034c10b67aaf41a7809430c3c3b64c84
X-Barracuda-Start-Time: 1554721355
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 7407
X-Barracuda-BRTS-Status: 1
Archived-At: <>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Apr 2019 11:02:40 -0000

Mr Levine brings up the valid point that there are a lot of mail filters 
with inadequate capabilities.   I determined that my two products have 
inexcusable weaknesses, so I went shopping.   
 I had only these rudimentary requirements:
  	IP filtering 	Reverse DNS filtering 	Multi-factor whitelisting or some 
other safe mechanism for handling SPF policy mistakes. 	DMARC policy 
enforcement 	A secure-email method for outbound messages with sensitive 
content 	No domain spoofing by the product that is supposed to protect from 
domain spoofing. 
 I was blown away when I discovered:
  	Products that could not do IP filtering. 	Products that could do DMARC 
enforcement but not Reverse DNS filtering, and the reverse. 	Vendors who 
had no idea what multi-factor whitelisting meant. 	High-end vendors who did 
domain spoofing in their secure-email solution.  (They have been notified.) 
 Along the way, I was referred to three industry-analyst reports, and was 
equally disappointed that the reports showed no evidence of a theoretical 
framework on which to judge vendor differences.  At least one analyst 
declared the industry "mature", which struck me as odd given the damage 
done by WannaCry and the obvious problems in the products I have been 
 I currently have exactly ONE vendor that is probably adequate, but I 
curtailed the discussion when I realized his costs were way higher than 
what I can interest management in spending.   Overall, it appears product 
vendors have no idea what is actually needed and why.
 Since bad email filters are the problem, why is there no IETF working 
group to define the expected behavior of email filters?    More 
importantly, can we start one NOW?
 I have been preparing to submit an email filter evaluation RFC as an 
individual, since this group seemed uninterested after an earlier post.   
But it would be better as a working group document, and it might become 
 Doug Foster

 From: "John Levine" <>
Sent: Sunday, April 7, 2019 8:51 PM
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
In article <> you 
> The problem:
> Spammers use non-existent domains to achieve identity spoofing, such as
> This is primarily a reception problem, because many recipient mail 
>are not equipped to block this type of fraud. ..

Right, and we can stop right there.

A decent spam filter will treat a nonexistent From: domain or envelope
bounce address as extremely suspicious and send the message into spam
folder purgatory. If someone's filters aren't doing that, it is
unlikely that they're paying much if any attention to DMARC, and no
amount of fiddling with DMARC will make any difference.

My mail server rejects anything with a non-existent bounce address at
SMTP time and I don't think it's ever rejected anything my users would

The solution to this problem is for mail systems to fix their filters,
not to invent yet another mail-breaking hack that they won't use