Re: [dmarc-ietf] Mandatory Sender Authentication

["Douglas E. Foster" <[e-mail]>]

>> 1. By 'sender', which actor in the sequence do you mean? The term is
highly ambiguous.
  
 By Sender Authentication, I mean message "From Address" authentication.   
This involves two rules:
  	The sending IP address is known to be authorized to send for the SMTP 
Sender-Address because of MX or SPF, and  	the SMTP Sender-Address is known 
to be authorized to send for the message from Address because of either  	 
		domain alignment or  		a verifiable DKIM signature for the domain of the 
message From-Address.   	

 The message From-Address is what the user sees, so it seems important to 
know that the user is not being deceived by an impersonator.

>> 2. Your certitude presumes an empirical foundation, given how often 
good
theory does not make good practice. People have been working in this
space for a very long time and one might have expected the industry to
have latched on such a simple requirement were it that clear it was
/the/ essential requirement. Please document the basis for your certitude.
  
 What I actually intend is that "a recipient has a viable option to 
implement mandatory sender authentication."
 This i equivalent to enforcing basic DMARC rules whether the sender has a 
DMARC policy or not.   This requires:
  	An email filter that understands SPF, DKIM, and DMARC. 	An email filter 
that provides local policy options to detect, evaluate, and override false 
positives. 	A sufficiently low level of false positives that the recipient 
organization is willing to commit the administrative resources to 
investigating and correcting false positives. 
 These conditions are sorely lacking, as explained in the next section.

>> 3. What made you think that 'sender' authentication is not already
happening at a sufficient level? What is the basis for believing it
 isn't already being used by filtering agents well enough?
  
 I have been doing a market survey, and it suggests that many vendors do 
not understand the problem or do not believe it needs to be solved.  I 
began with these minimal screening requirements:
  
 Source filtering:
    Able to block based on both IP address and Reverse DNS. 
  
 A surprising number of vendors only supported one of these filters.
  
 Sender authentication:
    Able to enforce sender DMARC policies.   (No requirement to support 
feedback processing)
    Able to override an incorrect SPF policy using a multi-factor rule 
(source server + sender domain).
  
 A surprising number of devices that supported DMARC filtering could not do 
ReverseDNS filtering.
  
 More recently, I realized that the only effective way to correct an SPF 
policy is to use SPF syntax.   I have not yet seen any product that does 
so, but I have more products to review.
  
 For the first pass, I had no filtering criteria related to content 
filtering.
  
 Results
 ----------
 These vendors could not meet all four criteria:
  	Barracuda (appliance, hybrid, and cloud products) 	Sophos (3 appliance 
products, 2 cloud products) 	Edgewave 	Forcepoint 	Fortinet 	Trend Micro 
	Dell SonicWall 	Symantec 	SpamExperts / SonicWall Mail 
 Some of these were evaluated based on reviews of the administrative 
manuals, others based on a sales process.
  
 On the higher-end solutions:
  
 I discounted Cisco Talos and Proofpoint because their secure email 
solutions do domain spoofing.
  
 BAE Solutions was dropped because their sales process required me to sign 
a non-disclosure agreement.   Based on what we did discuss, it did not 
appear that they could meet the four requirements.
  
 Kaspersky was ignored because of mistrust of the Russian government.
  
 The following products appeared to meet the minimum requirements, but for 
most of them I do not have access to the administrator manual until I 
commit to a product trial.
  	Cloudswift 	Mimecast 	Fortinet 	FireEye 
 I am in early discussions with AT&T / MessageLabs, but have no asssessment 
yet.
  
  
 >> 4. Consider the limitations to 'sender' authentication.

I am spending a lot of time thinking about the limitations of sender 
authentication.   For a spammer domain, SPF / DKIM / DMARC are easy.   For 
impersonation, Friendly Name and embedded logo images can be pretty 
effective without violating SPF / DKIM / DMARC.
  
 This means that Sender Authentication may produce more false positives 
than true positives.   Given the labor cost of addressing the mistakes, it 
is an open question whether the effort is worthwhile.   For the moment, I 
am hoping so.  I manage two very different mail streams, and the one that 
has higher spam levels appears to benefit from enforcing SPF and DMARC.  
Neither environment has products with adequate tools for implementing SPF 
exceptions, so I do not know how long I can leave the features enabled.   
Since you are involved in the Sender Authentication standards process, I 
assume you agree that Sender Authentication has potential to add value.
 
 To minimize false positives, I would like to see:
  	Pressure on list forwarders to either not break signatures, or follow 
the IETF example of replacing the original from with the list domain and 
signing the new message with the list domain.
	  	Advice to senders to reduce signature complexity.   In the general mail 
stream, the purpose of the DKIM signature is to authenticate the sender, 
and the protected data serves the purpose of a unique key for the signature 
process, to prevent replay attacks.   Uniqueness should be achievable using 
three headers:  To, From, and Date.   Subject and Message-ID should not be 
used as they are two fields that are likely to be altered in transit.    
(Using DKIM signatures for content validation is only viable if the sender 
is known with confidence and an exception management process is in place.  
These conditions may exist for specific sender-receiver pairs, but they 
will not exist as a default condition.) 
 But I have already been told that IETF is not interested in Recipient 
product problems, and is not concerned with security, which has left me 
very disappointed.
  
  
 Doug Foster