On Fri 04/Aug/2023 21:14:18 +0000 Scott Kitterman wrote:
On August 4, 2023 4:16:39 PM UTC, Wei Chuang
<weihaw=40google....@dmarc.ietf.org> wrote:
At IETF-117, I restarted the proposal for a policy "auth=" tag based on the
proposal here
<https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>.
The "auth=" policy allows for restriction of SPF in scenarios where it
might be problematic but still retains its availability in DMARC by
default. I didn't hear objections at 117, so below is some proposed
language for "auth=" for dmarc-ietf-dmarc-dmarcbis.
-Wei
=====
1. Introduction, 3rd paragraph insert after first sentence:
In addition, the choice of permitted authentication methods, SPF or DKIM,
method MAY be explicitly specified, potentially to restrict the supported
authentication methods.
4.3 Authentication Mechanisms append:
Domain Owners and PSOs MAY explicitly specify the supported authentication
methods via the "auth=" tag. The value is a colon ':' separated list of
supported authentication methods without whitespace. The order of the list
isn't any significant, and unknown methods are ignored. An aligned passing
result for any listed method indicates a DMARC pass. An empty list
indicates no authentication method is specified and DMARC is disabled. If
unspecified with a policy tag "auth=", this indicates that both DKIM and
SPF are supported.
5.3 General Record Format insert:
auth: Indicates the supported authentication methods. If more than one
method is specified, they are colon ':' separated without whitespace. The
order of the list is not significant and unknown methods are ignored. An
empty list indicates no authentication method is specified and DMARC is
disabled.
dkim: Authenticate with DKIM
spf: Authenticate with SPF
5.4. Formal Definition insert:
dmarc-auth = <empty> / "dkim" / "spf" / "dkim:spf" / "spf:dkim"
I'd drop the requirements of not having whitespace. If we opt for a
colon-separated list, why not stick with DKIM's sig-h-tag syntax? That is:
dmarc-auth = %s"auth" equals *WSP [dmarc-method]
*( *WSP ":" *WSP dmarc-method )
dmarc-method = %s"dkim" / %s"spf"
Table:
Tag Name Value Rule
auth dmarc-auth
I'm still not convinced we need this, but I can live with it.
We need it after the often-cited paper showing how to reliably obtain
spf=pass using current free-mailbox providers. With the current spec, that
sloppy SPF settings translates to dmarc=pass, with no possibility to amend it.
In 5.3 you need to specify the tag is optional and that the default (to be used
in the absence of the tag) is spf:dkim. That is necessary to preserve backward
compatibility with existing records (which I think is essential for DMARCbis).
BTW, Section 5.4 seems to be missing a number of %s'.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
