Scott, your proposal says to remove any reference to organizational domain,
but you don't explain how you will define DKIM and SPF alignment without
reference to organizational domain.

 In your proposal, if the query at step 1 does return a record, and the
record specifies relaxed alignment, then the receiver does not have enough
information to evaluate alignment.

This is not an academic point. The organization I work for relies on
relaxed alignment, and we sometimes create DMARC records for subdomains
(usually because we've identified a subdomain that we're not yet ready to
apply p=none to). I don't see how this will work under your proposal.

Regards,
Joe Humphreys


On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman <[email protected]>
wrote:

>
>
> On November 1, 2021 2:19:02 AM UTC, Douglas Foster <
> [email protected]> wrote:
> >Currently, the Publicssuffix.org list protects the PSL names.   Although I
> >don't believe it is covered anywhere in the DMARC v1 document, any DMARC
> >implementer will have to notice that a PSL name must produce DMARC FAIL,
> >because it cannot be authenticated itself, and it cannot be authenticated
> >by alignment with any other domain name.
> >
> >If we could publish a rule which limits alignment to only work from an
> >authenticated domain name downward to a child subdomain, we would have a
> >secure design, because we would not need to worry about leaving the
> >authenticated organization.   But as long as upward alignment is
> >necessitated by current practice, we need to be concerned about leaving
> the
> >authenticated organization in the upward direction into the PSL.
> >
> >A specific example:
> >MailFrom is "[email protected]" and From is "trustme@com".
> >Any acceptable replacement for the PSL must ensure that this identifier
> >configuration is rejected.
> >
> >When moving up the domain tree, the only way to avoid transiting from an
> >authenticated organization into the PSL, is to know what names are in the
> >PSL.    The alternatives seem to be (a) an externally obtained list, no
> >matter how imperfect, or (b) DNS entries, no matter how imperfect.    The
> >list seems the best option in the near term, but the DNS option might
> prove
> >valuable over time.
>
> What's wrong with what I already proposed?
>
> Your analysis is backwards.  Modulo the few PSDs that have published
> records for PSD DMARC and for receivers that check for it, the DMARC
> results for mail to such domains is none, not fail.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to