On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely <[email protected]> wrote: >On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote: > >> The published policy (that's why I suggest dmarc.policy). > > >Published policy can be ambiguous. Say you have p=quarantine; sp=none. > The >MTA chooses which to apply based on the domains (publishing and From:). > So it >makes sense to write the /applied/ published policy. > >I'm not good at designing A-R stanzas, as you know. However, since >dmarc is >already the policy method, why not write dns.policy, since that is >where it >comes from?
The problem with dns as a ptype is that virtually all this is from DNS. I haven't had a chance to study your proposal in detail or coordinate with the other designated experts, but speaking for myself my initial thought is that dns is not a good ptype name. This is specific to DMARC, so I think it's appropriate to say so. >> I'm not sure if disposition belongs in A-R. If it does, it'd be a >local >> policy override, probably policy.dmarc as described now in RFC 8616. > >You mean RFC 7489, don't you? I see nothing about A-R in RFC 8616. Sorry. I meant RFC 8601. >Would it be possible to add a result of "quarantine"? Having >dmarc=fail and >dns.policy=quarantine leaves a good deal of interpretation to the MDA. >If one >could write dmarc=quarantine, a simple string search or regular >expression >would do. That's a great example of why dns.policy= isn't the way to go. It's too generic. If it's dmarc.policy=quarantine, there's no ambiguity. You can't put quarantine as the DMARC result, because that's not what it is. The DMARC result is pass/fail/none. >Currently, I use a comment too. > >Since we're at it, besides the spam folder, is it fine if the MDA sets >IMAP >keyword $Junk[*] or $Phishing[†] or would we dare registering a new >one? It's outside my area of expertise, so I don't have a strong opinion, but I'd be inclined not to register a new one. I think the average user can be confused by too many terms for things that to them are the same. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
