On Friday, February 28, 2014 18:06:36 J. Trent Adams wrote:
> DMARC Folks -
...
> To support this effort, we are asking the community for input as we
> prepare the current version for submission to the ISE. We are seeking
> concise statements that can be incorporated into the specification
> primarily with a focus toward clarity, readability, and utility. While
> we're happy to continue cataloging suggestions for future work, our goal
> is primarily to tighten up this version of the document. Please send
> your comments to this IETF discussion list within the next week as we
> intend to submit the final version of the specification to the ISE by
> the close of the meeting in London.
>
> Current Specification:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
...
I didn't have time for a detailed review of the entire document, but I did
take a look at the SPF aspects of it and do have comments:
In Section 4, the next to last paragraph currently is:
A Domain Owner may find that although its messages pass a particular
authentication scheme's checks, it wishes not to have Mail Receivers
consider those results as evidence that the message was authorized.
In this case, the Domain Owner simply declines to advertise
participation in those schemes. For example, if the results of path
authorization checks ought not be considered as part of the overall
DMARC result for a given Author Domain, then the Domain Owner does
not publish an SPF policy record.
It's slightly more correct to end with "SPF policy record that can produce an
SPF pass result." It is rare, but I have seen SPF records published that were
only meant to produce fail results from known forgery sources. Something like
"v=spf1 -ip4:xxx.xxx.xxx.xxx ?all". A record like this could never trigger a
DMARC pass.
Section 3.1.4.2. SPF-authenticated Identifiers says:
DMARC provides the option of applying SPF in a strict mode or a
relaxed mode.
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
domain must have the same Organizational Domain. In strict mode,
only an exact DNS domain match is considered to produce identifier
alignment.
5.2. General Record Format includes:
aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether
strict or relaxed SPF identifier alignment is required by the
Domain Owner. See Section 3.1.4.2 for details.
The language doesn't seem quite parallel between the two. 3.1.4.2 talks about
strict or relaxed mode while 5.2 talks about strict or relaxed SPF identifier
alignment. I figured out what it means, but it confused me for a minute (and I
knew what meant to say before I read it). I'd recommend changing (in
3.1.4.2):
DMARC provides the option of applying SPF in a strict mode or a
relaxed mode.
to
DMARC provides the option of applying SPF in strict or relaxed
identifier alignment modes
and also changing (in section 5)
aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether
strict or relaxed SPF identifier alignment is required by the
Domain Owner. See Section 3.1.4.2 for details.
to
aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether
strict or relaxed SPF identifier alignment mode is required by the
Domain Owner. See Section 3.1.4.2 for details.
I think similar changes for DKIM in 3.1.4.1 and the adkim definition would be
an improvement.
Since I've bitched about it enough previously, I'll mention that the
discussion about SPF policy versus DMARC policy in 6. Policy Enforcement
Considerations (from -01) resolves my concerns about that text.
In section 10.2.4 there is a discussion about what must be included from the
validation checks if there is an SPF pass. I don't see any companion in
formation about what information to carry forward from the SPF validation if
it's not pass. I wonder if it should be included. It should be, in addition
to the domain, the SPF result (there are several possible results that would
cause it not to pass for DMARC purposes) along with any explanatory text (most
all SPF implementations provide information beyond the bare result to assist
in troubleshooting).
In 15.5, there is the phrase, "If malicious or unaware users can gain control
of the SPF record or signing practices for a subdomain, ...". I think that
should be "If malicious or unaware users can gain control of the SPF record or
DKIM signing practices for a subdomain, ..."
I B.1.1, the SPF alignment examples, I think it might be a bit confusing.
When Mail From is in the same organizational domain and not the same, it's (in
my experience) a subdomain to the From domain, not the other way around (which
is what the example has). I think the example would make more sense to most
readers if the Mail From/From was reversed in the second example. This would
also be more consistent with the example in B.3.1.
I think this is significantly improved from -00, which is the last one I really
had a chance to review.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
