> I’m one of those people who prefer for “xxx considerations” sections to be a
> descriptive discussion
> of the xxx issues and not contain new normative requirements.
I disagree, and certainly the Security Considerations sections are
normative and often use BCP 14 key words.
> the statement above sounds a little like the normative language is moving
> because it only addresses
> an interoperability issue.
It's moving in order to (1) put the requirements for senders and
recipients in one place in order to make the reasoning clear and (2)
to allow a broader discussion of the issues and the reasons without
cluttering the sections that lay out the protocol. I think it's
important to put the requirements and the reasons for those
requirements in the same place: its clearer to readers and it
emphasizes the needs for the requirements.
> [Is there a significance to the indentation of the 3rd, 6th, and 8th
> paragraphs below?]
It calls out the requirements clearly. The rest of the text explains
why, and the indented text contains the requirements concisely.
> > not an address authorized for the sending domain. DKIM signatures
> > will generally remain valid in these relay situations.
>
> Is “generally” true here? I think I have seen exceptions to DKIM signatures
> being valid on relayed
> messages, although I can’t dig up any examples right now.
You seem to be answering the question you're asking. I know of none
of these relays that break DKIM signatures, but we hear that some do.
So, "generally" means it's not wrong. I'm happy to use a different
word or phrase if you suggest one.
> > It is therefore critical that domains that host users who might
> > post messages to mailing lists SHOULD NOT publish p=reject.
> > Domains that choose to publish p=reject SHOULD implement
> > policies that their users not post to Internet mailing lists.
>
> A few paragraphs earlier discussed “alumni” and role-based addresses. But now
> it sounds like only
> mailing lists are important. It would seem that domains that send messages to
> alumni and role-based
> addresses also SHOULD NOT publish p=reject. But there’s no way for those
> domains to know when
> they’re sending to such addresses.
The relaying for alumni and roles will ("generally", as noted)
maintain DKIM authentication, which mitigates the issue for those
types, and we already put the MUST requirement of not using SPF alone
with p=reject. So this requirement need only be for mailing lists, as
they're the cases that (again, generally) break DKIM signatures.
> I agree with Murray’s comment: a SHOULD NOT like this need to cite what the
> exceptions are.
> “Our domain is very worried about domain spoofing” and the like don’t seem
> like a suitable
> exceptions to me.
I think the explanatory text makes the situation abundantly clear,
without the need for further clarification here. As I've said, I
prefer MUST NOT here, but it's clear to me that we will not get rough
consensus on that, and SHOULD NOT will still cover the situation
reasonably. And, like it or not, "we're worried about spoofing" *will
be* the reason this is ignored. Do you (or Murray) really want to say
that explicitly? I certainly don't.
> > It is therefore critical that receiving domains MUST NOT reject
> > incoming messages solely on the basis of a p=reject policy by
> > the sending domain. Receiving domains must use the DMARC
> > policy as part of their disposition decision, along with other
> > knowledge and analysis.
>
> Isn’t this basically just factoring address alignment along with DKIM and SPF
> pass into spam filters?
> I’m pretty sure spamassassin already does that, even without DMARC.
Not just that, no. Receiving domains might consider various
allow-lists, contents of recipients' address books, message content
filtering, knowledge of common mailing list managers, and other such
factors.
Barry
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
