Re: [dmarc-ietf] Rethinking DMARC for PSDs

Your question confirms my core argument:   We do not have consensus around 
email filter requirements because IETF has focused on sender behavior 
rather than recipient behavior.

 To the specifics:
  	By "secure email relay", I am referring to Zixmail-type functioinality.  
It is complex code, generally involving a cloud server (although I would 
prefer keeping it on an appliance under my control).   It is the least bad 
option for demonstrating regulatory compliance when transmitting sensitive 
information to an ad-hoc recipient.  Most organizations need it.   Further 
discussion on this point probably belongs in the MEDUP discussion. 
 Use Cases
  	I receive hositle mail from "server7.badexample.com".   I want to block 
the IP address because I know it is a bad source.   But I also want to 
blacklist the other servers at this organization, so I want hostname 
filtering to block *.badexample.com.  I actually want to block anything 
from this organization, so I really want to block this entity anytime it 
appears in a HELO/EHLO name, a reply-to name, a list header name, a URL 
field, or a message-id field.   But for simplicity in a low-end product 
that meets my budget, I will settle for IP and ReverseDNS filtering.
	  	DMARC has three components:  detecting and enforcing sender DMARC 
policy, collecting feedback information and transmitting it to the sender, 
and interpreting feedback received for the sender domain.   In a low-end 
product, I am only expecting policy enforcement, not the other two 
components.   From a coding standpoint, it seems only slightly more complex 
than SPF enforcement or DKIM signature checking.   From a regulatory 
standpoint, it is mandatory.  If PayPal and Gmail have gone to the trouble 
to request DMARC enforcement, and I am devastated by malware because I did 
not check DMARC information,, then I am guilty of reckless negligence.   So 
yes, DMARC enforcement is essential.
	  	Multi-factor whitelisting is needed because whitelisting (give this 
message high trust because the sender is trustworthy) is only safe if the 
sender is authenticated (the message really came from the trusted sender).  
Sender authenticator requires multiple attributes.

	Example:  CompanyA.com uses HostingSevice.com.   I want to ensure that 
messages from CompanyA.com are not blocked based on spam scoring 
heuristics.   Siingle-factor whitelisting says that I can whitelist the 
sender (and expose myself to atacks from anyone spoofing their domain) or I 
can whitelist the source server (and expose myself to attacks from any 
other client domain at HostingService.com).    When ReverseDNS is not an 
option, i have no feasible way to whitelist HostingService.com, because I 
have no way to know all of their servers and keep the list maintained over 
time.   A related problem is that I should be able to do granular 
whitelisting, for example to ignore only spam scoring while retaining other 
tests.   Many of the examined products provide all-or-nothing whitelist 
mechanisms.
	  	SPF corrections are a related issue, and multi-factor whitelisting 
would be a tolerable but inferior tool for handling the problem.  What is 
really needed is a local override mechanism that can be expressed in SPF 
terms.   SPF omissions can include (a) primary domain omitted a server from 
its list, (b) included domain omitted a server from its list, or (c) an 
entire domain is omitted from the list.   Email filters should provide 
constructs to handle all three;  None of the corrections require 
whitelisting.   I do not necessarily want to guarantee delivery, I just 
want the SPF sender authentication function to be peerformed on accurate 
source data.  
 On EXIM in particular:

 My secondary spam filter is based on EXIM, with a vendor-supplied wrapper 
and user interface.   Because it is secondary, I am protected from some of 
the products weaknesses.
  	Other system administrators routinely complain that when the message 
From-Address is there own domain, the message is not blocked.   The product 
does not fitler on message From -Address, and my research into Exim 
capabilities indicated that the Exim filtering process could not even 
extract the message From-Address to reference in filtering.
	  	The product based on Exim cannot do ReverseDNS filtering.   It looked 
like I might be able to simulate the capability with Exim filter syntax, 
but I gave up because I could not decipher how the vendor implemented its 
wrapper.
	  	The logging is a summary of all of the chatter between sending and 
receiving systems.   The logs entries need to be assembled to present a 
single data record about what happened to this message.   The vendor's GUI 
provides a crude approximation of this process,, but the GUI information 
cannot be exported.  I finally wrote a bunch of complex code to turn the 
log detail into a message data record.
	  	The product based on Exim has only two SPF options:   Off or Block.   
When it is off, it does not check or log SPF results.  When it is on, it 
blocks the message so there is no data on which to evaluate false 
positives.   If a false positive is detected despite the difficulties, the 
product only supports single-factor whitelisting, although it does provide 
granularity by feature.
	  	Since email filtering is a heuristic process,, the message review 
features are as important as the message filtering features.  It should be 
possible to enable any filtering rule in two modes: 	 		without enforcement 
(learn mode) so that effectiveness and false positives can be evaluated and 
corrected prospectively, before the policy is enforced. 		with enforcement 
(policy mode) with sufficient data collected so that false positives can be 
detected and corrected retrospectively, after the policy is enforced. 	

 Consequently, I stand by the assertion that my feature list is the bare 
minimum for anything that claims to be a spam filter.  It is not a complete 
list.  For example RBL checking is also mandatory, but I have not seen that 
as an omitted feature, so it was omitted.   Nothing in this list requires 
proprietary databases that only the richest vendors can offer.

 Doug Foster

----------------------------------------
 From: "Jeremy Harris" <jgh@wizmail.org>
Sent: Monday, April 8, 2019 7:21 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
On 08/04/2019 12:02, Douglas E. Foster wrote:
> I had only these rudimentary requirements:
> [...] A secure-email method for outbound messages with sensitive
> content
Rudimentary? How secure; what's your threat model?
Those two things often don't go together.

(I should declare an interest: Exim developer.)

--
Jeremy

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc