>> 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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
