Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Dotzero <[e-mail]>]

On Thu, Aug 13, 2020 at 10:08 PM John Levine <[e-mail]> wrote:

> In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=
> [e-mail]> you write:
> >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
> >from a similar problem as PRA in the SenderId draft. There is no way to
> >validate that the specific intermediary is authorized by the (From) domain
> >originating the email through it's generic signalling that it
> >authorizes intermediaries. This means that any source can emit a message
> >claiming to be a legitimate intermediary just as any source could game PR
> >to gain a neutral result.
>
> That's a feature, not a bug. I want recipients to be able to assess
> the mail my lists send on its own merits.
>

And recipient domains do just that using local policy override. DMARC
policy is at best a request to the Validator/Receiving Domain. If a
Validator/Receiving Domain chooses to honor the published DMARC policy for
a domain such as p=reject, then they are in fact assessing the mail your
lists send based on the merits as they see them. The same goes if they
decide to not honor that published DMARC policy and accept mail from your
lists. Earlier in my DMARC journey I felt that MLMs should adjust and send
list mail as themselves. Now I have come to the conclusion that they should
reject list submissions from accounts at domains which publish a DMARC
policy of p=reject. Domains should not be able to externalize their
internal problems to others.

>
> >One could achieve similar outcomes using
> >only reputation and local policy override of DMARC policy.
>
> Only if you believe that the domain on the From: line is automatically
> more credible than the one on the Sender: line. The whole third party
> problem is that the people sending their mail through lists or
> whatever are in fact doing so legitimately, but for various reasons
> their organizations' DMARC policies lie and say they aren't.
>

I think you are misusing the term "credible". Domains which are publishing
p=reject policies are making an assertion regarding mail purporting to be
authorized by their domain. It is not an assertion that their mail is
"good" or should be delivered to a recipient or even given preferential
treatment with regard to filters or policy. The assertion is simply that
mail purporting to be authorized by my domain must pass either SPF or DKIM
validation or else we request that in the event of neither of these
properly validating for a particular email message, please reject this
message. Don't think of it as being about "legitimate" or "not legitimate".
There is a certain (normally small) amount of mail that fails to validate
even when it passes directly from the outbound MTA to the recipient
domain's MTA. The sending domain is accepting that this otherwise valid
mail may (SHOULD?) be rejected by the receiving domain. The organizations
DMARC policies aren't lying. They are simply saying "If this then that."

This ultimately goes back to the elephant in the room. Does an individual
user's use of an account at a domain trump the organization's right to
define how an account at a domain may/should be used? I absolutely agree
that in an ideal world this issue should not be externalized yet here we
are. This is why I made the point above that lists should respect DMARC
policy and not accept submissions from domains with DMARC p=reject
policies. It becomes "Not your circus and not your monkey". and forces the
problem back to the domain and it's users. If an MLM isn't modifying the
message then the DKIM signature should survive and this discussion is
irrelevant. I think this covers the range of MLM use cases that have been a
topic of discussion. If the MLM admin really wants to poke those domains
publishing p=reject then they can respond to user subscribe attempts or
submissions that are rejected with an explanation that they need to go have
a meaningful discussion with their mail admin/IT staff/domain account
provider or whoever is responsible for publishing p=reject for tht domain
but still allowing users to sign up for MLMs or attempt to use other
intermediaries. popcorn is of course optional.

Michael Hammer