Re: [dmarc-ietf] PSD flag vs Version bump

[Barry Leiba]

> What if MIME-Version changed on every new MIME type?

(I presume you mean "subtype", as we've only defined two new media
types: example (RFC 4735) and font (RFC 8081).)

This is a red herring, as MIME was specifically designed to be
extensible by adding new media types and subtypes, as well as
parameters, charsets, and the like.

We aren't talking about an extension here, but a change to the basic
mechanism of the protocol.  We decided that the change from PSD to
tree walk was sufficiently compatible that it's OK without a version
change.  Removing SPF validation is a less compatible change to the
protocol, and it makes it a different discussion.

Best to avoid analogies: most of them fail and are only distracting.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[Alessandro Vesely]

On Sun 11/Jun/2023 00:32:01 +0200 Richard Clayton wrote:
Personally (and I am not writing on behalf of $DAYJOB$) I think that 
signal "I know things have changed and am setting things up accordingly" 
is most clearly sent by bumping the version number, rather than relying 
on other more subtle syntax changes.



Among changes, besides the tree walk, we have ed25519 and t=.  Compatibility 
seems to be much more at stake with the latter ones than with the former.  In 
fact, if you sign with (only) ed25519, many receivers won't verify.  If you use 
pct=5, like some do, you may be off for some harsh surprises.  In contrast, if 
your record is found by walking the tree rather than looking up the PSL, most 
likely you won't even notice.


We don't need psd=u's, except if we're drawing statistics.

New tags can be added also after DMARCbis is out.  There is a registry already:
https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml#tag
Not all receivers recognize every tag.  There was a project to syntactically 
denote tags that cannot be ignored, and it was abandoned (also) because it 
required a version bump.


Conserving the installed base is important.


I foresee almost no enthusiasm for running two systems in parallel in 
perpetuity. Running the simpler __system__ is clearly better all round 
but I do think that the fact that there are changes should be signalled 
very clearly rather than deduced ... it will make the messaging to the 
masses rather than the cognoscenti so much simpler.



What if MIME-Version changed on every new MIME type?

We'd be running n systems in parallel, with n -> ∞.  Introducing a new system, 
however simpler, would divide the users community, rather than unite them.

https://xkcd.com/927/


Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <20230610210457.b4c22e924...@ary.qy>, John Levine
 writes

>We have two of the largest mail operators in the world saying that if
>they can't tell which org domain scheme domain expects, they won't
>implement the tree walk. We have to do something or we are wasting our
>time.

Clarity is everything ... reducing system complexity matters as well.

Removing the need to consult a (reasonably) current version of the PSL
matters a great deal, because even when operating at the scale that you
can have engineers (and further systems) monitoring for when this does
not happen is complexity that one would wish to dispose of.

ie the new tree walk is an improvement and not just because of the new
features it provides.

Domain owners can learn when the new treewalk is being used by
consulting aggregate reports...  domains that wish to use the features
the new treewalk provides may, in the fullness of time, start reaching
out to the recalcitrant.

For example, if you are gov.uk and running a special DNS system to make
the old approach provide some safety, you may want to turn that system
off, but you can only do that once mailbox provides have changed over.

Meantime the mailbox providers want to know if they are behind the curve
in using the new tree walk... tracking the DMARC records they fetch (or
looking at surveys by people who fetch and count them) will tell them if
domain owners know that things have changed.

Personally (and I am not writing on behalf of $DAYJOB$) I think that
signal "I know things have changed and am setting things up accordingly"
is most clearly sent by bumping the version number, rather than relying
on other more subtle syntax changes.

viz: the version number bump is a clear signal that domain owners know
what is going on (and is really easy to explain to them).

That signal tells mailbox providers which tree walk (and any other
changes) to use and when it is clear that we're into the long tail of
domain owners who have not heard the messaging then is the time to say
"well the new tree walk makes no difference" and delete the old code,
stop fetching the PSL and decommission the monitoring... the final step
is to ignore version 1 records completely (and signal that in aggregate
reports)...

I foresee almost no enthusiasm for running two systems in parallel in
perpetuity. Running the simpler __system__ is clearly better all round
but I do think that the fact that there are changes should be signalled
very clearly rather than deduced ... it will make the messaging to the
masses rather than the cognoscenti so much simpler.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZIT54d2nQQHFxEViEQJweACg4lDlD2TSRG8FoV/cmRtGRnKwVvYAnRpi
S+YOpSRfkBjQATjp3bmb0WXM
=1EKf
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[Scott Kitterman]

On June 10, 2023 9:04:57 PM UTC, John Levine  wrote:
>It appears that Scott Kitterman   said:
>>
>>What's the incentive that any existing DMARC users (senders or receivers) 
>>would have to invest additional resources in another email
>>authentication protocol?
>
>We have two of the largest mail operators in the world saying that if
>they can't tell which org domain scheme domain expects, they won't
>implement the tree walk. We have to do something or we are wasting our
>time.
>
>So how about this: in the tree walk, you look for DMARC records that
>have an explicit psd=y/n/u tag. If you find at least one record with a
>tag, you use the new scheme. If you find no records with a tag, you
>fall back to the old scheme. I think this will let people do
>everything they can do with the current tree walk, while being
>backward compatible. If you want a domain to be an org domain you put
>psd=n, if you want the tree walk to skip it and keep looking, you put
>psd=u, and if it's one of the 0.001% of domains that actually is a
>PSD, you put psd=y.
>
>We already added DiscoveryType to the aggregate report schema so we
>are OK there.

Generally, I think it's fine, but specifically, I think we need to be careful 
about the language.

Using PSL is 7489DMARC.  Using tree walk is DMARCbis.  I don't think we want to 
include all the PSL stuff in the bis document, so I think we need to avoid 
talking about it.

We can update the tag description and include a statement that the presence of 
the tag is an indication that the record has been evaluated as being compatible 
with DMARCbis (which is I think what they actually want).

At the rate we're going on the description of overall interoperability status 
of DMARC, I think there's plenty of time to work out the details.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[John R Levine]

Why not say "SHOULD use tree walk", and then document, as explanation
for "SHOULD" instead of "MUST", non-normative reasons why you might
not?


I don't think that will fly with the VLMPs.  The mandatory PSD seems 
relatively easy to implement, just add it to the template you use for 
everything.


R's,
John


On Sat, Jun 10, 2023 at 5:05 PM John Levine  wrote:


It appears that Scott Kitterman   said:


What's the incentive that any existing DMARC users (senders or receivers) would 
have to invest additional resources in another email
authentication protocol?


We have two of the largest mail operators in the world saying that if
they can't tell which org domain scheme domain expects, they won't
implement the tree walk. We have to do something or we are wasting our
time.

So how about this: in the tree walk, you look for DMARC records that
have an explicit psd=y/n/u tag. If you find at least one record with a
tag, you use the new scheme. If you find no records with a tag, you
fall back to the old scheme. I think this will let people do
everything they can do with the current tree walk, while being
backward compatible. If you want a domain to be an org domain you put
psd=n, if you want the tree walk to skip it and keep looking, you put
psd=u, and if it's one of the 0.001% of domains that actually is a
PSD, you put psd=y.

We already added DiscoveryType to the aggregate report schema so we
are OK there.

R's,
John

PS: Whether we say people SHOULD NOT use SPF is a separate issue.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[Barry Leiba]

Hm...

Why not say "SHOULD use tree walk", and then document, as explanation
for "SHOULD" instead of "MUST", non-normative reasons why you might
not?

Waddyathink?

Barry


On Sat, Jun 10, 2023 at 5:05 PM John Levine  wrote:
>
> It appears that Scott Kitterman   said:
> >
> >What's the incentive that any existing DMARC users (senders or receivers) 
> >would have to invest additional resources in another email
> >authentication protocol?
>
> We have two of the largest mail operators in the world saying that if
> they can't tell which org domain scheme domain expects, they won't
> implement the tree walk. We have to do something or we are wasting our
> time.
>
> So how about this: in the tree walk, you look for DMARC records that
> have an explicit psd=y/n/u tag. If you find at least one record with a
> tag, you use the new scheme. If you find no records with a tag, you
> fall back to the old scheme. I think this will let people do
> everything they can do with the current tree walk, while being
> backward compatible. If you want a domain to be an org domain you put
> psd=n, if you want the tree walk to skip it and keep looking, you put
> psd=u, and if it's one of the 0.001% of domains that actually is a
> PSD, you put psd=y.
>
> We already added DiscoveryType to the aggregate report schema so we
> are OK there.
>
> R's,
> John
>
> PS: Whether we say people SHOULD NOT use SPF is a separate issue.
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD flag vs Version bump

[John Levine]

It appears that Scott Kitterman   said:
>
>What's the incentive that any existing DMARC users (senders or receivers) 
>would have to invest additional resources in another email
>authentication protocol?

We have two of the largest mail operators in the world saying that if
they can't tell which org domain scheme domain expects, they won't
implement the tree walk. We have to do something or we are wasting our
time.

So how about this: in the tree walk, you look for DMARC records that
have an explicit psd=y/n/u tag. If you find at least one record with a
tag, you use the new scheme. If you find no records with a tag, you
fall back to the old scheme. I think this will let people do
everything they can do with the current tree walk, while being
backward compatible. If you want a domain to be an org domain you put
psd=n, if you want the tree walk to skip it and keep looking, you put
psd=u, and if it's one of the 0.001% of domains that actually is a
PSD, you put psd=y.

We already added DiscoveryType to the aggregate report schema so we
are OK there.

R's,
John

PS: Whether we say people SHOULD NOT use SPF is a separate issue.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD Flag

[Alessandro Vesely]

On Mon 06/Dec/2021 23:23:37 +0100 Tim Wicinski wrote:
On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman > wrote:



Unless there's a valid reason for someone to publish PSD=no, I don't think
it should exist and I can't think of a reason.  If you give people a knob,
someone will turn it [if we leave it in, I guarantee you there will be
things written about how essential it is to have psd=no in your DMARC 
record].


What Scott says here. It can not be said enough.  People will attempt anything 
and everything.  Make it simple, and precise.



Then the same holds for t=.  Apart from the fact that there's nothing ambiguous 
in saying psd=no, a handy rule for boolean tags would be that they default to 
"no", but if they appear without value in a record, the assumed value is "yes".



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD Flag

[Tim Wicinski]

On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman  wrote:

>
>
> Unless there's a valid reason for someone to publish PSD=no, I don't think
> it should exist and I can't think of a reason.  If you give people a knob,
> someone will turn it [if we leave it in, I guarantee you there will be
> things written about how essential it is to have psd=no in your DMARC
> record].
>
>
What Scott says here. It can not be said enough.  People will attempt
anything and everything.  Make it simple, and precise.

>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD Flag

[Scott Kitterman]

On December 6, 2021 1:10:02 PM UTC, Todd Herr 
 wrote:
>On Sat, Dec 4, 2021 at 11:28 PM Scott Kitterman 
>wrote:
>
>> I think the addition of the PSD flag to support organizational domain
>> determination is a good change.  I have some quibbles about the exact
>> definition though:
>>
>> >   psd:  A flag indicating whether the domain is a PSD. (plain-text;
>> > OPTIONAL; default is 'n').  Possible values are:
>> >
>> > y:  Domains on the PSL that publish DMARC policy records
>> SHOULD
>> >include this tag with a value of 'y' to indicate that the
>> >domain is a PSD.  This information will be used during
>> policy
>> >discovery to determine how to apply any DMARC policy
>> records
>> >that are discovered during the tree walk.
>> >
>> > n:  The default, indicating that the DMARC policy record is
>> >published for a domain that is not a PSD.
>>
>> Why does this need a value at all?  Why can't the flag just be psd?
>>
>> [snip]
>>
>> All that's needed is to strike "with a value of 'y'" from the second
>> sentence.
>>
>> I think this is simpler and clearer.
>>
>>
>I don't disagree that it's simpler and clearer. However, expressing it as
>psd=(y|n) was chosen to be consistent with the expression of every other
>tag currently defined for DMARC records, all of which "follow the
>extensible "tag-value" syntax for DNS-based key records defined in DKIM" as
>declared in section 5.3, General Record Format.
>
>This doesn't mean we can't break new ground here, but doing so would
>require rewriting the beginning of section 5.3, as well.

Unless there's a valid reason for someone to publish PSD=no, I don't think it 
should exist and I can't think of a reason.  If you give people a knob, someone 
will turn it [if we leave it in, I guarantee you there will be things written 
about how essential it is to have psd=no in your DMARC record].

Good point about section 5.3.  The ABNF would need changing too.  I can provide 
a patch for the change if you would like.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] PSD Flag

[Todd Herr]

On Sat, Dec 4, 2021 at 11:28 PM Scott Kitterman 
wrote:

> I think the addition of the PSD flag to support organizational domain
> determination is a good change.  I have some quibbles about the exact
> definition though:
>
> >   psd:  A flag indicating whether the domain is a PSD. (plain-text;
> > OPTIONAL; default is 'n').  Possible values are:
> >
> > y:  Domains on the PSL that publish DMARC policy records
> SHOULD
> >include this tag with a value of 'y' to indicate that the
> >domain is a PSD.  This information will be used during
> policy
> >discovery to determine how to apply any DMARC policy
> records
> >that are discovered during the tree walk.
> >
> > n:  The default, indicating that the DMARC policy record is
> >published for a domain that is not a PSD.
>
> Why does this need a value at all?  Why can't the flag just be psd?
>
> [snip]
>
> All that's needed is to strike "with a value of 'y'" from the second
> sentence.
>
> I think this is simpler and clearer.
>
>
I don't disagree that it's simpler and clearer. However, expressing it as
psd=(y|n) was chosen to be consistent with the expression of every other
tag currently defined for DMARC records, all of which "follow the
extensible "tag-value" syntax for DNS-based key records defined in DKIM" as
declared in section 5.3, General Record Format.

This doesn't mean we can't break new ground here, but doing so would
require rewriting the beginning of section 5.3, as well.


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] PSD Flag

[Scott Kitterman]

I think the addition of the PSD flag to support organizational domain 
determination is a good change.  I have some quibbles about the exact 
definition though:

>   psd:  A flag indicating whether the domain is a PSD. (plain-text;
> OPTIONAL; default is 'n').  Possible values are:
>
> y:  Domains on the PSL that publish DMARC policy records SHOULD
>include this tag with a value of 'y' to indicate that the
>domain is a PSD.  This information will be used during policy
>discovery to determine how to apply any DMARC policy records
>that are discovered during the tree walk.
> 
> n:  The default, indicating that the DMARC policy record is
>published for a domain that is not a PSD.

Why does this need a value at all?  Why can't the flag just be psd?

>   psd:  A flag indicating whether the domain is a PSD. (plain-text;
> OPTIONAL;).  Presence of this flag indicates that the domain
>   is a PSD and that this DMARC record MUST NOT be considered
>   for determining organizational domain.

This would require a change to the second paragraph of Section 4.6 to go with 
it:

>  For any email message, the Organizational Domain of the RFC5322.From 
>
>  domain is determined by performing a DNS Tree Walk as described in
>  Section 4.5.  The target of the search is a valid DMARC record that
>  contains a psd tag with a value of 'y'.  Once such a record has been
>  found, the Organizational Domain for the DNS domain matching the one
>  found in the RFC5322.From domain can be declared to be the target
>  domain queried for in the step just prior to the query that found the
>  PSD domain.

All that's needed is to strike "with a value of 'y'" from the second sentence.

I think this is simpler and clearer.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc