Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)
Hi Tim, On Mon, May 10, 2021 at 04:45:02PM -0400, Tim Wicinski wrote: > Ben > > On Wed, Apr 21, 2021 at 1:04 AM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dmarc-psd-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > > > > > -- > > DISCUSS: > > -- > > > > There seems to be a bit of internal inconsistency in Appendix B.2: > > > >Names of PSDs participating in PSD DMARC must be registered this new > >registry. New entries are assigned only for PSDs that require use of > >DMARC. [...] > > > > These two sentences seem to be in conflict, since a PSD can participate > > in PSD DMARC without requiring use of DMARC for all its subdomains. The > > rest of the section is clear that the registry is only intended to be > > for PSDs that do require the use of DMARC for subdomains, so I expect > > that a minor tweak to the wording of "PSDs participating in PSD DMARC" > > would be an appropriate fix. > > > > > I reworded these two sentences to say: > > PSDs that are deploying DMARC and are participating in PSD DMARC > must register their public suffix domain in this > new registry. > > > Does this sound better ? That's at least locally better, though I seem to have lost some of the context as to what the rest of the section says. > > > > > -- > > COMMENT: > > -- > > > > This document is generally in pretty good shape; my comments (and, > > to some extent, my discuss as well) are pretty minor points. > > > > Thanks to Sandra Murphy for the secdir review. I think there were some > > questions in there that are worth a response and possibly clarifications > > in the document. > > > > > Sandra did a strong review and I believe we worked through the issues > raised. I'm happy to hear it; I may have just been misled by the mailarchive entry for the secdir list. > > > Section 1.2 > > > > It seems like the "branded PSD" and "multi-organization PSD" cases would > > benefit from a protocol-level indication and separate handling by > > message recipients. It seems likely that the newly defined np (in > > combination with the preexisting sp) provides the flexibility to > > describe the different cases, but it seems like it would be helpful to > > have some discussion in this document that relates these two cases to > > the actual protocol mechanisms used to achieve them. > > > > > There is no different handling of between a "Branded PSD" and a > "multi-organization PSD". The difference is highlighting the types. I think I agree that the actual mechanics of handling the protocol elements, if they exist, shouldn't really differ for the two cases. It seems that there may be some subjective differences, though, in that it would be really surprising if the "multi-organizational PSD" decided to publish policy for existant subdomains, whereas for branded PSDs that is normal and expected, since in some sense they really ought not be PSDs at all. > > > Section 3 > > > > As Lars and Éric already commented, I suggest using a phrasing that > > includes something like "this experiment" and maybe "proposes", since > > actually formally updating the DMARC specification would procedurally be > > a bit exciting. > > > > > I've updated this text. > > Section 3.2 > > > >np: Requested Mail Receiver policy for non-existent subdomains > > (plain-text; OPTIONAL). Indicates the policy to be enacted by the > > > > I assume that "subdomains" here refers only to direct children (i.e., > > one additional label), not deeper in the hierarchy. It's not entirely > > clear to me whether all readers will do likewise, though... > > > > > It is the direct subdomain. There is discussion inb RFC7489 if a subdomain > does not have a _dmarc DNS record, the _dmarc record at the parent domain is > query/used. (I'm happy to defer to you on whether adding more text to the document to clarify this is warranted.) > > > Section 3.3, 3.6 > > > > It sounds like this entire paragraph is appended to the section? > > In other subsections we are a bit more explicit about where the new text > > is going and what part is the new text. > > > > > I added this text to the beginning of each paragraph: > > If this
Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)
Ben On Wed, Apr 21, 2021 at 1:04 AM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dmarc-psd-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > -- > DISCUSS: > -- > > There seems to be a bit of internal inconsistency in Appendix B.2: > >Names of PSDs participating in PSD DMARC must be registered this new >registry. New entries are assigned only for PSDs that require use of >DMARC. [...] > > These two sentences seem to be in conflict, since a PSD can participate > in PSD DMARC without requiring use of DMARC for all its subdomains. The > rest of the section is clear that the registry is only intended to be > for PSDs that do require the use of DMARC for subdomains, so I expect > that a minor tweak to the wording of "PSDs participating in PSD DMARC" > would be an appropriate fix. > > I reworded these two sentences to say: PSDs that are deploying DMARC and are participating in PSD DMARC must register their public suffix domain in this new registry. Does this sound better ? > > -- > COMMENT: > -- > > This document is generally in pretty good shape; my comments (and, > to some extent, my discuss as well) are pretty minor points. > > Thanks to Sandra Murphy for the secdir review. I think there were some > questions in there that are worth a response and possibly clarifications > in the document. > > Sandra did a strong review and I believe we worked through the issues raised. > Section 1.2 > > It seems like the "branded PSD" and "multi-organization PSD" cases would > benefit from a protocol-level indication and separate handling by > message recipients. It seems likely that the newly defined np (in > combination with the preexisting sp) provides the flexibility to > describe the different cases, but it seems like it would be helpful to > have some discussion in this document that relates these two cases to > the actual protocol mechanisms used to achieve them. > > There is no different handling of between a "Branded PSD" and a "multi-organization PSD". The difference is highlighting the types. > Section 3 > > As Lars and Éric already commented, I suggest using a phrasing that > includes something like "this experiment" and maybe "proposes", since > actually formally updating the DMARC specification would procedurally be > a bit exciting. > > I've updated this text. Section 3.2 > >np: Requested Mail Receiver policy for non-existent subdomains > (plain-text; OPTIONAL). Indicates the policy to be enacted by the > > I assume that "subdomains" here refers only to direct children (i.e., > one additional label), not deeper in the hierarchy. It's not entirely > clear to me whether all readers will do likewise, though... > > It is the direct subdomain. There is discussion inb RFC7489 if a subdomain does not have a _dmarc DNS record, the _dmarc record at the parent domain is query/used. > Section 3.3, 3.6 > > It sounds like this entire paragraph is appended to the section? > In other subsections we are a bit more explicit about where the new text > is going and what part is the new text. > > I added this text to the beginning of each paragraph: If this experiment is successful, this paragraph is added to this setion. Does that help? > Section 4.1 > >o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC > usage: Privacy risks for Organizational Domains that have not > deployed DMARC within such PSDs are significant. For non-DMARC > Organizational Domains, all DMARC feedback will be directed to the > PSO. PSD DMARC is opt-out (by publishing a DMARC record at the > Organizational Domain level) vice opt-in, which would be the more > desirable characteristic. This means that any non-DMARC > organizational domain would have its feedback reports redirected > to the PSO. The content of such reports, particularly for > existing domains, is privacy sensitive. > > It might be worth making some statement about the applicability of PSD > DMARC for such PSDs that do not mandate DMARC usage. (I guess the > following paragraphs mostly play that role, though perhaps editorially > tying them together more clearly is possible.) >
Re: [dmarc-ietf] Roman Danyliw's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)
On Wed, Apr 21, 2021 at 4:38 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-dmarc-psd-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > -- > COMMENT: > -- > > Thank you to Sandra Murphy for the SECDIR review. Please review those > proposed > clarifying edits. > Thanks. I believe we've gone over all of them. > > ** Section 4.1 > Due to the inherent Privacy and Security risks associated with PSD >DMARC for Organizational Domains in multi-organization PSDs that do >not particpate in DMARC, any Feedback Reporting related to multi- >organizational PSDs MUST be limited to non-existent domains except in >cases where the reporter knows that PSO requires use of DMARC. > > Is there any guidance on how the reporter might know “that [the] PSO > requires > use of DMARC”. > In the above paragraphs in this section, it defines Multi-organization PSDs that require DMARC usage and Multi-organization PSDs that do not require DMARC usage. Any Advice? > > ** Section B.2. > -- Please define the semantics of the “status” column and the > expected/possible > values > This is defined in RFC7489, Section 11.4. I added the following text: The "Status" column is defined in Section 11.4. > -- Reconcile the differences between the initial values noted in this this > document and those at http://psddmarc.org/registry.html: o the text in > this > section says “current” for the status column, but the html page has same > values > as set to “active” > > o the PSD names in the initial values of this document are of the form > “.*”, > but the html page has no leading dot (i.e., “.bank” vs. “bank”) > > Thanks, I've reached out to have this corrected tim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote: On 5/10/2021 7:10 AM, Matthäus Wander wrote: I support the use of the namespace declaration. A report with namespace declaration allows for automatic syntax checks with XML Schema Validation. Version numbers, and the like, tend to be a lot less useful than intuition leads one to expect. Automatic syntax checks are a different beast, though. The distinction to make is 'increments' versus 'incompatibilities'. If an new spec merely /adds/ to a previous spec, then the presence of the new constructs is self-declaring. The only requirement is to have the base specification declare that unrecognized constructs are to be ignored. So, versioning adds the illusion of utility, but really only adds unnecessary complexity. I think the format we'll end up with will be pretty compatible with the existing practice, meaning that existing report consumers that use a proper XML parser and ignore unknown tags can work unchanged. I don't think any consumer parses reports "by hands". The added complexity of using proper XML constructs to define the format, as well as properly formatting each instance, enables advanced use of XML parsing tools. Did you notice no site offers aggregate report validation services? Incompatibilities, where new constructs conflict with previous ones, mean that the new specification is not a new version. It is an independent specification. It needs to be labeled accordingly. This is not our case. Even if we find a better TLD for the targetNamespace URL, the format is going to be the first official version of DMARC aggregate report format, following the one(s) in use since 2012. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recipient domain in aggregate reports (#62)
On Mon, 10 May 2021, Alessandro Vesely wrote: Indeed. I check DMARC on all my incoming mail, but it is unlikely that I will ever get around to sending reports. It'd be interesting to know what refrains you to do DMARC aggregate reports. It's a large amount of programming work to manage the database and extract and create the reports. If I had nothing better to do I might do it but it is a very very low priority, particulary considering how small my site is. More to the point, IETF standards tell people what to do if you want to interoperate, not how the document's authors might wish the world were different. You can obviously implement all of DMARC processing on inbound mail without ever sending a report, so in this place MUST is simply wrong. Agreed, SHOULD seems to be the right world here. I'd expect your reply to the above question to provide subject matter for the reasons why an operator may want to not do it. MAY is correct but I can live with SHOULD. 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] Recipient domain in aggregate reports (#62)
NOTE: adjusted ticket number, #23 to #62 On Sat 08/May/2021 20:51:15 +0200 John Levine wrote: It appears that Murray S. Kucherawy said: Personally, I think mandatory reporting wouldn't survive Last Call or IESG Evaluation. Even if it did, there's no mechanism to enforce it ... Indeed. I check DMARC on all my incoming mail, but it is unlikely that I will ever get around to sending reports. It'd be interesting to know what refrains you to do DMARC aggregate reports. For the opposite POV, I can say I generate these reports because they make an interesting, albeit partial, view of my incoming mail traffic. Then, among the silly reasons why I send them: * I don't think any PII leaks out that way, * the spirit of global community suggests helping peers is a Good Thing, * outgoing reports constitute a relevant part of my nanoscopic outgoing traffic, so they help keep my IP warm. More to the point, IETF standards tell people what to do if you want to interoperate, not how the document's authors might wish the world were different. You can obviously implement all of DMARC processing on inbound mail without ever sending a report, so in this place MUST is simply wrong. Agreed, SHOULD seems to be the right world here. I'd expect your reply to the above question to provide subject matter for the reasons why an operator may want to not do it. In addition, there could be reasons for not sending a specific aggregate report, such as locally imposed or remotely requested size limits, and local policy about the target domain, its IP(s), country, or whatever. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
John Levine wrote on 2021-05-10 17:21: > It appears that Matthäus Wander said: >> 1) #33 suggests to add a versioned XML namespace declaration in the root >> element. >> https://trac.ietf.org/trac/dmarc/ticket/33 >> >> I support the use of the namespace declaration. > > >> 4) How does the report generator know which format version the consumer >> supports? > > It doesn't. If we change the schema, a lot of report parsers will break. > What actual > real world problem does this change solve? The schema is broken already. See: https://trac.ietf.org/trac/dmarc/ticket/44 https://trac.ietf.org/trac/dmarc/ticket/45 https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/ The point is to fix the schema. > I haven't seen a lot of ill-formed reports. You obviously haven't tried XSD validation. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
On 5/10/2021 7:10 AM, Matthäus Wander wrote: I support the use of the namespace declaration. A report with namespace declaration allows for automatic syntax checks with XML Schema Validation. Version numbers, and the like, tend to be a lot less useful than intuition leads one to expect. The distinction to make is 'increments' versus 'incompatibilities'.l If an new spec merely /adds/ to a previous spec, then the presence of the new constructs is self-declaring. The only requirement is to have the base specification declare that unrecognized constructs are to be ignored. So, versioning adds the illusion of utility, but really only adds unnecessary complexity. Incompatibilities, where new constructs conflict with previous ones, mean that the new specification is not a new version. It is an independent specification. It needs to be labeled accordingly. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
It appears that Matthäus Wander said: >1) #33 suggests to add a versioned XML namespace declaration in the root > element. >https://trac.ietf.org/trac/dmarc/ticket/33 > >I support the use of the namespace declaration. >4) How does the report generator know which format version the consumer >supports? It doesn't. If we change the schema, a lot of report parsers will break. What actual real world problem does this change solve? I haven't seen a lot of ill-formed reports. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
1) #33 suggests to add a versioned XML namespace declaration in the root
element.
https://trac.ietf.org/trac/dmarc/ticket/33
I support the use of the namespace declaration. A report with namespace
declaration allows for automatic syntax checks with XML Schema
Validation. XSD validators refuse to work without the declaration. It
should be added to the examples in the I-D.
Example report:
http://dmarc.org/dmarc-xml/0.2;>
...
A shorter variant is possible if we change the schema slightly:
http://dmarc.org/dmarc-xml/0.2;>
...
Adapted schema with elementFormDefault:
http://www.w3.org/2001/XMLSchema;
targetNamespace="http://dmarc.org/dmarc-xml/0.2;
xmlns="http://dmarc.org/dmarc-xml/0.2;
elementFormDefault="qualified">
Nit: I'd use 2.0 instead of 0.2.
2) #33 goes further and suggests to remove the tag below
, because it is redundant with the namespace declaration.
I wouldn't recommend the removal. RFC 7489 has introduced tag
1.0 and existing implementations will rely on its
existence. Without , chances are the report consumer interprets
the report as pre-IETF draft version.
3) #70 introduces a new field, but this one is below
and seems to have the purpose to inform about which
DMARC standard has been used for validation.
https://trac.ietf.org/trac/dmarc/ticket/70
Is it useful to announce separate version numbers for the DMARC
algorithm and the report format? I imagine, the RFC 7489 would
do the job for both purposes.
4) How does the report generator know which format version the consumer
supports?
Ideas:
a) Send new format and don't care about old versions.
b) Send new format but avoid compatibility breaking changes in the XML
design. Add new fields, but do not change existing ones like
(cf. #51, #75).
c) Consumer announces supported version in DNS record ("rua2=" or whatever).
d) Send both versions (... for how long?).
Regards,
Matt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
On Sat, May 8, 2021 at 2:12 PM Murray S. Kucherawy wrote: > On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely wrote: > >> > - #62 makes reporting mandatory, which leaves the mail receiver with no >> > means to mitigate the privacy threat. >> > > #62 (assuming it has WG consensus) makes it clear we really want reporting > to be mandatory, but at a glance I don't see any "MUST generate" sort of > language in the draft. It may be in the other draft, but I haven't looked > there yet. This draft does a pretty firm job of extolling the virtues of > report generation, however. > > Personally, I think mandatory reporting wouldn't survive Last Call or IESG > Evaluation. Even if it did, there's no mechanism to enforce it (i.e., > operators that don't want to send such reports simply won't, and that's > that), other than maybe industry peer pressure, so I think what's in the > draft is as close as we can get. > > #62 is not consensus. #62 was the impetus for the proposed text on the topic that is Section 6.7.5 in draft-ietf-dmarc-dmarcbis-01. -- *Todd Herr* | Sr. Technical Program Manager *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
