On 6/6/2019 7:09 PM, Douglas E. Foster 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
MX does not 'authorize' sending by an IP address, although some
receivers do check for MX as a heuristic. But a heuristic is outside of
any 'standard'.
SPF does register IP to domain name for sending.
* the SMTP Sender-Address is known to be authorized to send for the
Sorry, but the term "SMTP Sender-Address" does not have any specified or
reliable meaning.
message from Address because of either
o domain alignment or
o 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.
I assume you mean the RFC5322-level From: field, as opposed to the
RFC5321-level Mail From command. Except that most users don't actually
see that address because these days most MUAs only display the display
address.
As for end users being deceived, there's quite a bit of experience that
showing users indicators doesn't alter their behavior.
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."
I don't understand what it means to have an option to implement
something that is mandatory. It's mandatory.
Also by saying 'recipient' rather than 'receiver' you appear to be
indicating the end users will do meaningful filtering based on this kind
of information. They won't.
This i equivalent to enforcing basic DMARC rules whether the sender has
a DMARC policy or not. This requires:
That means you are seeking to alter fundamental email semantics by fiat,
globally. Surely you jest.
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.
What do you mean?
For impersonation, Friendly Name and embedded logo images can be
pretty effective without violating SPF / DKIM / DMARC.
That's correct. And there has been extensive discussions looking to do
something about that but there are no proposals on the table, because so
far none has looked viable.
This means that Sender Authentication may produce more false positives
No it doesn't.
The existing authentication mechanisms do a good job of authenticating
what they are authenticating.
It appears that you are seeking to use the information far beyond what
is valid.
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.
You want to bring pressure on list processing developers and/or
operators. Good luck with that.
* Advice to senders to reduce signature complexity. In the general
What does that mean? What specific proposal do you have?
mail stream, the purpose of the DKIM signature is to authenticate
You appear to misunderstand the semantics of DKIM. Please re-read its
specification and supporting document, because they have simple, concise
language about what it does.
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.
I suspect you have been told nothing of the sort.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
