On Wed 30/Dec/2020 17:22:07 +0100 Dotzero wrote:
On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas <[email protected]> wrote:
On 12/30/20 7:35 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[email protected]> wrote:
On 12/30/20 5:48 AM, Todd Herr wrote:
I propose to add two new result name codes, named after the policy
requests:
dmarc=quarantine, and
dmarc=reject (of course, you only see this if the filter didn't
honor the request).
I do not support this, because quarantine, reject, and none are not
Authentication Results, but are instead both policy requests and
disposition decisions.
Then we should remove DMARC from auth-res altogether because it is not an
authentication mechanism. Either we fully support DMARC in auth-res or
remove it. This half-assed state of unlessness serves nobody.
I disagree. DMARC has rules that determine whether or not a message is
deemed to be authenticated - did it pass SPF or DKIM and did it do so
with a domain that aligns with the RFC5322.From domain. The currently
valid states for those rules are pass, fail, temperror, and permerror.
They are not enough to convey the information needed. That's why I propose an
addition.
Policy and disposition (none, quarantine, reject) apply to decisions made
based on the authentication results; they are not states for the
authentication checks themselves.
They become states for the authentication check in the moment that we publish
that dmarc=quarantine means the message failed DMARC check and the DMARC record
asked that the message be quarantined in that case.
Todd clearly said that a mailbox provider currently has to resort to temporary
header fields in order to communicate results of authentication checks to a
downstream, non-standard agent. Perhaps like so:
X-Authentication-Results: dmarc=quarantine?
Mail systems are not the prerogative of large mailbox providers who roll out
their own code. Standards exist to allow compliant code to interoperate.
DMARC != Auth-res. Auth-res provides all kinds of useful information than
just pass/fail. For DMARC Auth-res should provide what the policy was at a
bare minimum. But none of this seems to have any normative language
anywhere which is a problem unto itself. DMARC in auth-res seems to be an
orphan.
You just stated the case as to why this discussion should be ruled out of
scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan"
This is the IETF DMARC working group, not the AUTH-RES working group.
Indeed. Auth-Res values and meaning are defined precisely in the document we
are writing. RFC 8601 is extensible, and it only covers methods that were
already in use in 2009, when RFC 5451 came out.
You gave the example of someone writing a crappy Thunderbird extension as a
reason for the working group to change its focus.
The code that Philippe Lieser wrote is strictly conforming to standards. It is
crappy only because the DMARC standard is, at least as far as specifying
authentication methods is concerned.
Perhaps getting the extension author to fix their extension might be a more
fruitful effort.
By my bitty knowledge of Philippe's reasoning, I'd bet he'd ask what RFC says
where to get a different status than what his add-on displays. Of course he's
not going to tentatively parse every known A-R comment.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
