I took a look and it looks to me like all the section references are
there. Which ones are missing?
According to the diff provided on the web site [1], quite a few in the
following hunks of the diff:
The section numbers are all there in the markdown and the XML, so it's a
rendering problem s
On Monday, August 29, 2022 5:17:38 PM EDT John R. Levine wrote:
> > Why did you remove the specific paragraph pointers for the references? Is
> > that the norm in IETF documents? It seems to me it makes things less
> > clear.
> I took a look and it looks to me like all the section references are
Why did you remove the specific paragraph pointers for the references? Is that
the norm in IETF documents? It seems to me it makes things less clear.
I took a look and it looks to me like all the section references are
there. Which ones are missing?
Regards,
John Levine, jo...@taugh.com, P
On Monday, August 29, 2022 1:54:31 PM EDT Todd Herr wrote:
> On Mon, Aug 29, 2022 at 1:29 PM Alessandro Vesely wrote:
> > Is it so? My understanding is that psd=y is ignored when it is the first
> > step in a tree walk. That way you can have From: u...@psd.example.com
> > authenticated by d=exam
On Mon 29/Aug/2022 19:54:31 +0200 Todd Herr wrote:
On Mon, Aug 29, 2022 at 1:29 PM Alessandro Vesely wrote:
My understanding is that psd=y is ignored when it is the first step in
a tree walk. That way you can have From: u...@psd.example.com
authenticated by d=example.com, or helo=mailout.exa
It appears that Scott Kitterman said:
>Unless you are something like .gov or .us.com you don't need to use psd=y. I
>think this is likely to lead to confusion and mis-deployment. The only reason
>to use psd=n is if the entity above yours in the DNS tree has a DMARC record
>without psd=y and
It appears that Scott Kitterman said:
>Why did you remove the specific paragraph pointers for the references? Is
>that
>the norm in IETF documents? It seems to me it makes things less clear.
They're supposed to be there. I changed
section 999 of [@!RFC]
to
[@!RFC, section 999]
On Mon, Aug 29, 2022 at 1:29 PM Alessandro Vesely wrote:
>
> Is it so? My understanding is that psd=y is ignored when it is the first
> step in a tree walk. That way you can have From: u...@psd.example.com
> authenticated by d=example.com, or helo=mailout.example.com on a bounce.
>
>
I'm curiou
On Monday, August 29, 2022 1:48:57 PM EDT Alessandro Vesely wrote:
> On Mon 29/Aug/2022 18:27:11 +0200 Scott Kitterman wrote:
> > On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote:
> >> Also, I am reminded that since this document will obsolete RFC 9091 if
> >> approved, we need to i
On Mon 29/Aug/2022 18:27:11 +0200 Scott Kitterman wrote:
On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote:
Also, I am reminded that since this document will obsolete RFC 9091 if
approved, we need to incorporate the Privacy Considerations from that
document instead of referencing
On Mon 29/Aug/2022 17:27:07 +0200 Scott Kitterman wrote:
On Monday, August 29, 2022 7:50:18 AM EDT Douglas Foster wrote:
Some organizations have subtrees within their DNS structure that represent
client sub-organizations, which are unaffiliated for purposes of relaxed
authentication. [...]
T
On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote:
> On Monday, August 29, 2022 10:59:55 AM EDT Todd Herr wrote:
> > Version created from the pull request John mentioned on-list on August 28.
>
> Thanks.
...
>
> Also, I am reminded that since this document will obsolete RFC 9091 if
On Fri, Aug 26, 2022 at 8:52 AM Alessandro Vesely wrote:
> > NEW
> > If the set produced by the DNS Tree Walk contains no DMARC policy record
> > (i.e., any indication that there is no such record as opposed to a
> > transient DNS error), then the DMARC mechanism does not apply to this
> > messag
On Mon, Aug 29, 2022 at 11:10 AM Scott Kitterman
wrote:
> On Monday, August 29, 2022 10:59:55 AM EDT Todd Herr wrote:
> > Version created from the pull request John mentioned on-list on August
> 28.
>
> Thanks.
>
> Why did you remove the specific paragraph pointers for the references? Is
> that
On Monday, August 29, 2022 7:57:26 AM EDT Douglas Foster wrote:
> As currently defined, psd=u seems to contain no information and be
> identical to no token. I see no value in defining a tag that has no
> meaning.
>
> It could optionally be defined to mean "this is an organizational subdomain
>
On Monday, August 29, 2022 7:50:18 AM EDT Douglas Foster wrote:
> Not strongly opinionated about location.
>
> For the first insertion: Since the definition of psd=n occurs in the
> policy record, and after the tree walk, this seems to fit in with the psd=n
> definition.
>
> Some organizations
On Monday, August 29, 2022 10:59:55 AM EDT Todd Herr wrote:
> Version created from the pull request John mentioned on-list on August 28.
Thanks.
Why did you remove the specific paragraph pointers for the references? Is that
the norm in IETF documents? It seems to me it makes things less clear.
Version created from the pull request John mentioned on-list on August 28.
On Mon, Aug 29, 2022 at 10:58 AM wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conforman
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
As currently defined, psd=u seems to contain no information and be
identical to no token. I see no value in defining a tag that has no
meaning.
It could optionally be defined to mean "this is an organizational subdomain
which will lead to a psd=n tag". Then if the Tree Walk ends on anything
oth
Not strongly opinionated about location.
For the first insertion: Since the definition of psd=n occurs in the
policy record, and after the tree walk, this seems to fit in with the psd=n
definition.
Some organizations have subtrees within their DNS structure that represent
client sub-organizatio
21 matches
Mail list logo
