Re: [dmarc-ietf] Mandatory Sender Authentication

[Dotzero <[e-mail]>]

Comments in-line.


On Thu, Jun 6, 2019 at 1:47 PM Douglas E. Foster <
[e-mail]> wrote:

> >> 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.
>

This is absolutely incorrect. Making sweeping generalizations leads to bad
outcomes. There are MUAs that show the display name.


>
> >> 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.
>

I think you should create such a product. You can then compete in the
marketplace of ideas.

>
> >> 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:
>
>

The IETF is focused on interoperability. What you are proposing in this
section is that somehow the IETF can force vendors to implement
features/functionality in their offerings that is not related to
interoperability. If their customer were clamoring for it I guarantee you
that it would be on their product roadmap.


> Source filtering:
>    Able to block based on both IP address and Reverse DNS.
>
>

There's this crazy thing called RPZ. It is commonly used with RBLs. You
might want to take a look at it.


> 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 receiving system can implement whatever local policy it wants. As far as
I know, there is no Internet police to enforce your demands on what local
policy is implemented.


>
> 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.
>

I'm sorry to burst your bubble, but the Internet is not all about your
personal needs, wants and desires.

>
>
> >> 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.
>

Contrary to your opinion, email authentication is not about stopping
spammers. For example, DMARC was created to mitigate direct domain abuse in
the mail stream. In fact, miscreants were quicker to adopt SPF/DKIM and
DMARC than legitimate senders. This did have the effect of allowing the
assignment of reputation to sending domains.

>
> 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.
>

How large a corpus of mail did you evaluate in making your assertion about
false positives versus true positives? I assume you are aware that there
are people on this list who have examined varieties of different types of
mail streams comprising a corpus of billions of emails.

>
> 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.)
>
>
I love when someone who self admittedly has little or no experience in a
subject such as email standards and interoperability joins a list and
starts lecturing people on how things should/must be.


>
>
> 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.
>

And yet you persist. If you have a product problem you really need to speak
with your vendor. If no vendor supports your needs then perhaps you might
consider it a market opportunity and do a startup. There are participants
and workgroups within IETF that are concerned with security, but perhaps
not with your notion of what security should be. Use TLS much?

Have a good day and good luck with your endeavors.

Michael Hammer

>