Re: [dmarc-ietf] About user notification in the MUA
Stan Kalisch asks: And you propose the average user can understand, much less take the time to understand, the substance? Yes. I believe users are worried about spam, and want to make intelligent decisions about whether or not email can be trusted. Unfortunately, our present software denies them access to the available information needed to make intelligent decisions. Dave Crocker observes: There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful. I was not talking about the sender. I was talking entirely about the receiving organization:its spam filter communicating to its MUA to communicate information to the end user based on its local policy. Dave Crocker also observes about end-user signaling failures: It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years and none has demonstrated efficacy. Then lets restate that assertion in all its ugly elitism, and put it into an RFC: Incontrovertible research shows that humans will always act on malicious email, and cannot be taught to do otherwise. Organizations should deploy email if and only if they have automated tools which provide perfect protection from unwanted email. End user training is useless. I have a higher opinion about my users than that. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 8:04 PM, Murray S. Kucherawy wrote: If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products. As best as I have been able to tell, no such plug-ins even exist for Outlook and the other products do not accept extensions. There is an opportunity here for valuable standardization. The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts. Are you claiming that's changed? A 'friendly' amendment, or rather addition: The origination side of an email exchange has no authority over the reception side. Different administrative authorities. Compliance with DMARC is voluntary -- and receiving administrations often implement behaviors that differ from what is requested via DMARC. There is no basis for believing that requests about MUA display will achieve meaningful support on the receive side, nevermind whether they would be at all useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > 1) The original assertion, that DMARC creates a conflict with prior > specifications, appears to be undefended and incorrect. For From > Addressing, It merely establishes some boundaries that the sender and the > recipient choose to consider appropriate.For DKIM, it creates a > use-case for a technology that was initially defined without any use cases. >Consequently, I think this topic is ready for closure. > I claim your assertions here are contradictory. Specifically, by establishing "some boundaries", it is creating a conflict with prior specifications which established none, possibly intentionally. 3) Some of the discussion has been about how to prevent soclal engineering > of the recipient user. This is an important topic, but not directly > related to the project. IETF would do well to establish some > recommendations about how MUAs should behave, so that trust data can be > displayed to the user. A typical user will have access to at least three > different email clients: one on his cell phone, a product-specific web > page, and a desktop product like Outlook or Thunderbird.If I wanted an > organization policy that controlled when Friendly Name was displayed or > DMARC status was displayed, I would have to find and distribute plug-ins to > all of these products. As best as I have been able to tell, no such > plug-ins even exist for Outlook and the other products do not accept > extensions. There is an opportunity here for valuable standardization. > The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts. Are you claiming that's changed? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)
On June 8, 2020 2:35:28 AM UTC, John Levine wrote: >In article , >Scott Kitterman wrote: >>>How about saying that reports MUST include the key used to evaluate >>>the DMARC status, if there was one, and SHOULD include all DKIM keys >>>evaluated. >>> >>>The other ones can be useful, e.g., mailing lists usually resign >their >>>outgoing mail so if you have an idea what what lists are sending you >>>mail, that gives you a strong hint that a DMARC failure is due to >mail >>>from a list. >> >>When you say 'include the key', do you mean put the literal public key >in the report or the selector >>which, in combination with the signing domain, tells one where to find >the record in DNS? > >Sorry, domain and selector. Thanks for clarifying. I think that makes sense. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)
In article , Scott Kitterman wrote: >>How about saying that reports MUST include the key used to evaluate >>the DMARC status, if there was one, and SHOULD include all DKIM keys >>evaluated. >> >>The other ones can be useful, e.g., mailing lists usually resign their >>outgoing mail so if you have an idea what what lists are sending you >>mail, that gives you a strong hint that a DMARC failure is due to mail >>from a list. > >When you say 'include the key', do you mean put the literal public key in the >report or the selector >which, in combination with the signing domain, tells one where to find the >record in DNS? Sorry, domain and selector. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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] DMARC bis: ticket 38: reporting the proper DKIM key(s)
On June 8, 2020 12:02:13 AM UTC, John Levine wrote: >In article > >you write: >>-=-=-=-=-=- >> >>https://trac.ietf.org/trac/dmarc/ticket/38 >> >>The spec is ambiguous about which DKIM key needs to be reported. >> >>The real world problem here is that sometimes the DKIM key(s) which >are >>reported in a row of an aggregate report have nothing to do with the >DKIM >>key used to evaluate the DMARC status within the same row. > >How about saying that reports MUST include the key used to evaluate >the DMARC status, if there was one, and SHOULD include all DKIM keys >evaluated. > >The other ones can be useful, e.g., mailing lists usually resign their >outgoing mail so if you have an idea what what lists are sending you >mail, that gives you a strong hint that a DMARC failure is due to mail >from a list. When you say 'include the key', do you mean put the literal public key in the report or the selector which, in combination with the signing domain, tells one where to find the record in DNS? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 66: define what is means to implement DMARC
In article you write: >-=-=-=-=-=- > >https://trac.ietf.org/trac/dmarc/ticket/66 > >Many different entities participate in DMARC, and to each, there is a >different definition of what is needed to "implement" or participate in >DMARC. I would rather put this in a separate non-normative BCP. >The receiver/MTA: >- partially participating: validates DMARC? My MTA validates DMARC and then does nothing with it other than put the result in an A-R header. It currently only validates ARC on mail that will be run through a mailing list. This can be a rather deep rabbit hole. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)
In article you write: >-=-=-=-=-=- > >https://trac.ietf.org/trac/dmarc/ticket/38 > >The spec is ambiguous about which DKIM key needs to be reported. > >The real world problem here is that sometimes the DKIM key(s) which are >reported in a row of an aggregate report have nothing to do with the DKIM >key used to evaluate the DMARC status within the same row. How about saying that reports MUST include the key used to evaluate the DMARC status, if there was one, and SHOULD include all DKIM keys evaluated. The other ones can be useful, e.g., mailing lists usually resign their outgoing mail so if you have an idea what what lists are sending you mail, that gives you a strong hint that a DMARC failure is due to mail from a list. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About user notification in the MUA
On Sun, Jun 7, 2020, at 7:04 PM, Douglas E. Foster wrote: > The problem with all current notification methods is that they are relatively > primitive, often communicating nothing substantive about the suspicious > message characteristics. And you propose the average user can understand, much less take the time to understand, the substance? Stan___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)
On Sun, Jun 7, 2020 at 16:21 Scott Kitterman wrote: > On Sunday, June 7, 2020 5:23:12 PM EDT Seth Blank wrote: > > https://trac.ietf.org/trac/dmarc/ticket/38 > > > > The spec is ambiguous about which DKIM key needs to be reported. > > > > The real world problem here is that sometimes the DKIM key(s) which are > > reported in a row of an aggregate report have nothing to do with the DKIM > > key used to evaluate the DMARC status within the same row. > > > > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: > > > > The report SHOULD include the following data: > > > > o The identifier evaluated by DKIM and the DKIM result, > > > > Elizabeth Zwicky previously wrote: > > > > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ > > "is genuinely unclear. Often there are multiple identifiers. Does this > mean > > I can pick any one of them? (That does not actually provide sufficient > > interoperability.) If there’s a specific one I should pick, which is it?" > > > > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ > > "I believe they MUST contain any aligned DKIM signature regardless of > > validity and SHOULD contain an entry for each domain, selector, result > > triple." > > > > Is it desirable to clarify this language, such that it is clear which > DKIM > > keys are required to include in a report, and if so, how should the > > appropriate keys be determined? > > In DKIM, I would have thought that the 'identifier' is the d= domain. > Just > based on that text, there's no need to provide the selector. Looking > through > the rest of the list, I don't see anything that indicates the DKIM > selector > should be included in an aggregate report. > > That said, the selector is pretty useful. I'd suggest it's essential for > troubleshooting failures. > > Maybe there's two things here: > > 1. identifier needs a better definition. > > 2. Is there a backward compatible way to specify inclusion of the > selector. Selector is already there, it’s just OPTIONAL. There’s another ticket about making it required. > > Scott K > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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
Re: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)
On Sunday, June 7, 2020 5:23:12 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/38 > > The spec is ambiguous about which DKIM key needs to be reported. > > The real world problem here is that sometimes the DKIM key(s) which are > reported in a row of an aggregate report have nothing to do with the DKIM > key used to evaluate the DMARC status within the same row. > > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: > > The report SHOULD include the following data: > > o The identifier evaluated by DKIM and the DKIM result, > > Elizabeth Zwicky previously wrote: > > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ > "is genuinely unclear. Often there are multiple identifiers. Does this mean > I can pick any one of them? (That does not actually provide sufficient > interoperability.) If there’s a specific one I should pick, which is it?" > > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ > "I believe they MUST contain any aligned DKIM signature regardless of > validity and SHOULD contain an entry for each domain, selector, result > triple." > > Is it desirable to clarify this language, such that it is clear which DKIM > keys are required to include in a report, and if so, how should the > appropriate keys be determined? In DKIM, I would have thought that the 'identifier' is the d= domain. Just based on that text, there's no need to provide the selector. Looking through the rest of the list, I don't see anything that indicates the DKIM selector should be included in an aggregate report. That said, the selector is pretty useful. I'd suggest it's essential for troubleshooting failures. Maybe there's two things here: 1. identifier needs a better definition. 2. Is there a backward compatible way to specify inclusion of the selector. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 2:40 PM, John Levine wrote: I believe the real question is*whether* to show trust data to users and the consensus seems to be don't bother, it only confuses them. It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years and none has demonstrated efficacy. Anyone claiming the contrary needs to provide objective data to substantiate a claim of efficacy. Adding a capability or relying one carries an affirmative obligation to provide a basis for knowing that the cost is justified. So far, there isn't one, for end-user trust notifications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About user notification in the MUA
On 6/7/2020 4:04 PM, Douglas E. Foster wrote: Given that market reality, I conclude that most vendors and their customers believe that user-signalling is useful. The signalling system does not have to prevent every mistake for the signal to be useful. What you are describing has nothing at all to do with system-provided trust assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sunday, June 7, 2020 5:53:08 PM EDT Dave Crocker wrote: > On 6/7/2020 10:53 AM, Stan Kalisch wrote: > > Assuming this can be practically done, I would rephrase this, > > "...[E]stablish how MUAs should display trust data to users." > > Since there has been a demonstrated lack of efficacy in this sort of > display, there needs to be an objective basis for knowing that any new > such requirement will be useful. Good luck with that. > > On 6/6/2020 2:42 PM, Scott Kitterman wrote: > > 1. I think the domain displayed to the end user matters. In my sample > > size of 1, it matters to me. I know I'm not the average user, but > > independent of t > > I might be wrong, but I believe the IETF does not intend to make global > standards on the basis of possible utility for only one engineer working > on the specification. Or two. Or three. > > cf, above. Conveniently, I'm not proposing any new requirements. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement
On Sunday, June 7, 2020 4:37:42 PM EDT Seth Blank wrote: > As Chair, I'm closing ticket #49 and recording the consensus of the group > as in favor of removing the constraint. Thanks. In the discussion about that ticket there was an additional suggestion about making p= optional which was outside the scope of that ticket. I've filed: https://trac.ietf.org/trac/dmarc/ticket/72 to capture that. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About user notification in the MUA
I am trying to play by the rules and not chase topics outside the one assigned, but since several have jumped on my comment, I will follow up briefly. Dave Crocker wrote Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful. Every email filtering product that I have examined has provided a user-signaling system, using one or more of the following: tagging the subject, adding text as a body header or body footerconverting the suspect message into an attachment of a replacement message,soft-quarantining, where the user has unrestricted control to release the message from quarantine. Given that market reality, I conclude that most vendors and their customers believe that user-signalling is useful. The signalling system does not have to prevent every mistake for the signal to be useful. The problem with all current notification methods is that they are relatively primitive, often communicating nothing substantive about the suspicious message characteristics. They also work against other security mechanisms. Any form of tagging breaks DKIM signatures, reducing the credibility of the message if it is auto-forwarded for any reason. The tagging also becomes tattooed to the message and its replies, rather than being restricted to the trust domain that assigned the tag. One example should suffice: a message was tagged with [SPAM?] because the sender had an error in his SPF record and I was trying to enforce SPF. Then when my staff replied, the originator treated the reply as spam because the word SPAM was still in the subject line when he received it! We need a user notification mechanism that is local to the trust domain and does not break DKIM signatures. You have already done the heavy lifting for this interoperability problem with Authentication-Results and ARC I am not expecting a "Standard" that requires every implementation to notify every user in the same way. I am looking for a guidance document that helps vendors to deliver products which permit an organization to implement a notification policy which they find to be effective and appropriate. IETF is the right organization to take this on because the email filter, the mail system, and the multiple MUAs are almost always a multi-vendor configuration. df ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sun, Jun 7, 2020, at 5:40 PM, John Levine wrote: > I believe the real question is *whether* to show trust data to users > and the consensus seems to be don't bother, it only confuses them. I mean, I can't dispute that that's a fair question. Confusion obviously works against the goals behind showing the user the data in the first place. Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/2020 10:53 AM, Stan Kalisch wrote: Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful. Good luck with that. On 6/6/2020 2:42 PM, Scott Kitterman wrote: 1. I think the domain displayed to the end user matters. In my sample size of 1, it matters to me. I know I'm not the average user, but independent of t I might be wrong, but I believe the IETF does not intend to make global standards on the basis of possible utility for only one engineer working on the specification. Or two. Or three. cf, above. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
In article <71cddc80-008c-4f33-bdac-71ebc029b...@www.fastmail.com> you write: >I didn't know the history of the IETF's approach to UI, in particular, but I'm >aware of the research on the nastiness of >solving the UI problem. I mostly wanted to clarify that the problem is, >indeed, *how* to show that data to users, and that no >one has actually ever been able to solve that problem. I believe the real question is *whether* to show trust data to users and the consensus seems to be don't bother, it only confuses them. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports
https://trac.ietf.org/trac/dmarc/ticket/51 In a DMARC aggregate report, a record with a disposition of "none" is ambiguous, as a disposition of "none" at p=none means a different thing (that no action was taken on the message) than a disposition of "none" if the DMARC policy is reject or quarantine (the message passed an aligned authentication check of either SPF or DKIM, and was therefore not subject to policy). It is desirable to have logically distinct disposition responses, and if so, what should be reported in the latter case? As a straw man, "pass" instead of "none"? -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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] DMARC bis: ticket 38: reporting the proper DKIM key(s)
https://trac.ietf.org/trac/dmarc/ticket/38 The spec is ambiguous about which DKIM key needs to be reported. The real world problem here is that sometimes the DKIM key(s) which are reported in a row of an aggregate report have nothing to do with the DKIM key used to evaluate the DMARC status within the same row. In https://tools.ietf.org/html/rfc7489#section-7.2, it says: The report SHOULD include the following data: o The identifier evaluated by DKIM and the DKIM result, Elizabeth Zwicky previously wrote: https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ "is genuinely unclear. Often there are multiple identifiers. Does this mean I can pick any one of them? (That does not actually provide sufficient interoperability.) If there’s a specific one I should pick, which is it?" https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ "I believe they MUST contain any aligned DKIM signature regardless of validity and SHOULD contain an entry for each domain, selector, result triple." Is it desirable to clarify this language, such that it is clear which DKIM keys are required to include in a report, and if so, how should the appropriate keys be determined? -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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] DMARC bis: ticket 66: define what is means to implement DMARC
https://trac.ietf.org/trac/dmarc/ticket/66 Many different entities participate in DMARC, and to each, there is a different definition of what is needed to "implement" or participate in DMARC. Should the spec be clear about the different participants, and what it means for each to participate partially and completely? As a straw man to start conversation (assume this is all wrong): The domain owner: - partially participating: valid record? - complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender? The receiver/MTA: - partially participating: validates DMARC? - complete participation: validates DMARC and ARC, and sends aggregate reports? The intermediary (is this different than a receiver?): - partially: validates DMARC? - complete participation: validates DMARC and validates and seals ARC? -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/7/20 6:16 AM, Douglas E. Foster wrote: > 2) Some of the discussion appeared to resolve around the assertion > that DMARC can have no value. Since that view is not universal, I > think the project can continue with those who do believe that it adds > value. > That's not how it works; this working group is discussing an IETF standards-track specification. This is based on the rough consensus of the entire working group; you can't just go forward with a subset of people who agree. -Jim (with apologies to the WG chairs if I'm venturing into their territory) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
As Chair, I'm closing ticket #69 and recording consensus as remaining with XML for report formatting. This consensus may be revisited if https://trac.ietf.org/trac/dmarc/ticket/42 opens a new reporting mechanism for which JSON is optimal, but the group's current consensus is that even in that case, XML will be sufficient. On Thu, May 21, 2020 at 3:38 AM Alessandro Vesely wrote: > On Wed 20/May/2020 22:00:34 +0200 Hector Santos wrote: > > On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > > > >> I mean, what is the CSV format of the following report, that I sent > yesterday > >> for this list: > > > > Sorry, if I ignored it. > > > > Forgetting fact that you can your report easier to read for consumers, > these > > would be an example of the CSV field headers. > > > > CSV headers: > > > > report_metadata.org_name, report_metadata.email, > report_metadata.report_id, > > report_metadata.date_range.begin, report_metadata.date_range.end > > > > Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, > > Policy_Published.p > > > > record.row, record.row.source_ip.record.count. > record.row.policy_evaluated, > > record.row.policy_evaluated.disposition, > > record.row,policy_evaluated.disposition, > record.row.policy_evaluated.dkim, > > record.row.policy_evaluated.spf > > > > Note: You don't have to stick to redundant "name space" field names. > > > You didn't include auth_results. That's tricky because you can have zero > or > more dkim and spf results. That would bring on a variable number of > columns, > with no hint about which is which. > > As Freddie noted, repeating the headers for every record may sound a > little bit > wasteful, but gzip may come to rescue here too. > > As for readability, aggregate reports are designed to be machine-readable > to > the extreme detriment of any kind of human readability. The best samples > of > such attitude are the date_range elements. HTML provides for a much better > human readability. (Indeed, it is one of the formats you mentioned, as it > is > supported by Google Docs). I attach the HTML equivalent of the data I sent > yesterday. Posters whose From: was rewritten can easily spot their row > —readability meaning exactly that. > > Let me note that such htmlization is the result of a DMARC XSLT applied by > a > mail filter after rua messages authentication but before delivery. That > way, a > readable format of the reports is ready in the mail folder whenever I'd > care to > look at it, *as if it had been written in HTML in the first place*. By > similar > techniques one can obtain JSON, SQL, TXT, …. In the face of such > flexibility, > I'm puzzled by your asking for more. > > > ... Can we get back to work, please? > >>> > >>> Sorry, but I consider a rude, disrespectful and ignorant statement, to > be > >>> saying that. > >> > >> > >> No personal attack intended. I'm being rude because I have the > impression that > >> you are not defending a concrete, well defined need, but instead find > new > >> arguments opportunistically to pursue a vague sense of format fashion. > > > > That's a personal attack. If you don't understand the proposal, you > should back > > off or ask for clarification. > > > I /am/ asking for clarifications. Please excuse my tone if it hurts you. > I'll > try and keep calm, but please restrain from technically flaky arguments > such as > CSV. I think you're perfectly aware of the capabilities I'm exemplifying > here. > They rest on the fact that a report consumer knows in advance the format > of > the data inside the received gzip. Hence, that flexibility would be > destroyed > by the introduction of multiple formats, as they would come randomly at the > mercy of the report generators, any prf= notwithstanding. Not a great > loss, > given your feeling about reporting? > > > >> You shifted from an asserted necessity of producers to a possible desire > >> of consumers.> > > I did no such thing. I won't repeat it, but it appears you didn't > understand > > the proposal. > > > For sure, I don't understand the proposal. Let's start over: > > On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote: > > Just consider, when the spec has XML-only, then for those who use a solid > > JSON I/O system, they are now going to be required to add XML. So for > them, > > its additional development complexity. Everything they probably do JSON > > related. The exception would be DMARC using XML. This alone can delay or > > push aside DMARC Reporting implementation. > > > Does DMARC Reporting implementation mean generation or consumption? > > > On Wed 20/May/2020 02:23:37 +0200 Hector Santos wrote: > > I suggest that there is a new tag that provides a "Preferred Report > Format" > > or "prf=" tag using registered acronymns for long time "standard" > formats. > > For example:> > > prf=cvs,json,xml,afrf,iodef > > > > [...] > > > > The verifier will do what can it offer. The publisher is providing a > > preference, that it may not ge
Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid?
As Chair, I'm closing ticket #63 and recording consensus of the group as leaving this as-is, any guidance around this matter should be left to a BCP or guidance document. On Thu, May 21, 2020 at 6:10 PM Dotzero wrote: > > > On Thu, May 21, 2020 at 5:57 PM Tim Wicinski wrote: > >> (with no hats) >> >> p=none with no reporting is fine, and we should keep it. >> >> One thing the WG could do is a BCP document on operational recommendations >> where there are certain suggestions like this. >> >> tim >> >> +1 >> > > Michael Hammer > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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
Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement
As Chair, I'm closing ticket #49 and recording the consensus of the group as in favor of removing the constraint. On Fri, May 22, 2020 at 1:03 AM Alessandro Vesely wrote: > On Thu 21/May/2020 23:11:54 +0200 Scott Kitterman wrote: > > Agreed. I don't think this is controversial. > > > > Also, I don't see a problem with making the p= tag optional (with an > inferred > > value of None if not present). This is consistent with an existing > SHOULD in > > RFC 7489 and appears to be broadly supported in existing implementations. > > > > I'd propose we close this ticket with the following resolution: > > > > The requirement that the v=DMARC1 tag be first will be retained. > > > > The requirement that the p= tag be second and the requirement that the > p= tag > > is mandatory will be dropped. If the p= tag is not present, the implied > > policy value is None. > > > Please, let's not forget to update the grammar, e.g. as proposed in > https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8 > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sun, Jun 7, 2020, at 3:52 PM, John Levine wrote: > In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write: > >-=-=-=-=-=- > > > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > >> 3) Some of the discussion has been about how to prevent soclal engineering > >> of the recipient user. This is an important > >topic, but not directly related to the project. IETF would do well to > >establish some recommendations about how MUAs should > >behave, so that trust data can be displayed to the user. > > > >Assuming this can be practically done, I would rephrase this, > >"...[E]stablish how MUAs should display trust data to users." > > We have decades of experience that tells us that the IETF is hopeless > at UI design, and our intuition is usually wrong. > > In particular, displaying warnings that "this may be bad" or even > "this is extremely bad" is known not to work. No matter what you say, > people will click through any warning to get to their kitten GIFs or > porn or whatever. I didn't know the history of the IETF's approach to UI, in particular, but I'm aware of the research on the nastiness of solving the UI problem. I mostly wanted to clarify that the problem is, indeed, *how* to show that data to users, and that no one has actually ever been able to solve that problem. Thanks, Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write: >-=-=-=-=-=- > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: >> 3) Some of the discussion has been about how to prevent soclal engineering >> of the recipient user. This is an important >topic, but not directly related to the project. IETF would do well to >establish some recommendations about how MUAs should >behave, so that trust data can be displayed to the user. > >Assuming this can be practically done, I would rephrase this, "...[E]stablish >how MUAs should display trust data to users." We have decades of experience that tells us that the IETF is hopeless at UI design, and our intuition is usually wrong. In particular, displaying warnings that "this may be bad" or even "this is extremely bad" is known not to work. No matter what you say, people will click through any warning to get to their kitten GIFs or porn or whatever. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > 3) Some of the discussion has been about how to prevent soclal engineering of > the recipient user. This is an important topic, but not directly related to > the project. IETF would do well to establish some recommendations about how > MUAs should behave, so that trust data can be displayed to the user. Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." Which is a question many have struggled to answer, given the history of users understandably wanting to pull their hair out over trust data and warnings. Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
In article <14fe18acad53467a8027e680dfc10...@bayviewphysicians.com> you write: >-=-=-=-=-=- >1) The original assertion, that DMARC creates a conflict with prior >specifications, appears to be undefended and incorrect. It should not be controversial that DMARC can only describe a subset of valid Internet mail. The problem arises when people then assert that somehow it is our fault that we are sending mail that DMARC can't describe, typically in ways we've been using for decades, long before anyone thought of DMARC. >2) Some of the discussion appeared to resolve around the assertion that DMARC >can have no value. It clearly has value to Verizon, and it apparently has value to banks and Paypal. I can't see that it has much value for me or my users, since it has screwed up all the mailing lists we use, and for whatever reason we're not big phish targets. R's, John PS: My bank chronically sends out real mail that looks like a total phish, e.g., it says there's a dubious charge on your card, click this button if it's real or that button if it's not, with the URL for neither button having any connection to any domain the bank owns. I know it's real because I know enough about the bank business to recognize the subcontractor they use, but jeez. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
1) The original assertion, that DMARC creates a conflict with prior specifications, appears to be undefended and incorrect. For From Addressing, It merely establishes some boundaries that the sender and the recipient choose to consider appropriate.For DKIM, it creates a use-case for a technology that was initially defined without any use cases.Consequently, I think this topic is ready for closure. 2) Some of the discussion appeared to resolve around the assertion that DMARC can have no value. Since that view is not universal, I think the project can continue with those who do believe that it adds value. 3) Some of the discussion has been about how to prevent soclal engineering of the recipient user. This is an important topic, but not directly related to the project. IETF would do well to establish some recommendations about how MUAs should behave, so that trust data can be displayed to the user. A typical user will have access to at least three different email clients: one on his cell phone, a product-specific web page, and a desktop product like Outlook or Thunderbird.If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products. As best as I have been able to tell, no such plug-ins even exist for Outlook and the other products do not accept extensions. There is an opportunity here for valuable standardization. From: Alessandro Vesely Sent: 6/7/20 6:19 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: If things like DMARC, SPF, and DKIM do nothing more than get abusers to use different domains than they would otherwise, I think that's a win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of >>> the 3 that restricts the choice of domain name. >>> >>> With that in mind, I'll ask you why you think the kind of change you >>> cite is a win. >> 1. I think the domain displayed to the end user matters. In my sample size >> of 1, it matters to me. I know I'm not the average user, but independent of >> the question of how many users it matters to, there are some. > Same with me, but again I'm not the average user. +1, but then we're mailing list subscribers (leaving aside this list's topic.) >> >> 2. When abusers use different domains to send mail, it adds more information >> for filters to work on, so even if this is all about filtering, that works >> better too. > > But when abusers use different domains, the DMARC policy that applies is > controlled by them and is therefore meaningless. And the reports, if any > (probably none), are sent back to the attacker or their designate. > > Filtering might be done based on the DKIM signing domain or thesimilar > envelope-from domain if SPF is used, but neither of those require DMARC. The From: domain was chosen because that's the field that users can see. Now we conjecture that users don't actually see it. Oh boy. Certainly, if the From: domain is not visible we could filter on X-Filter-On-Me: and gracefully avoid the mailing list problem. On closer view, we seem to be discovering that the From: domain is obscured by the display name. We always neglected the display name. Furthermore, by letting the mailing list problem be dodged by creative From: rewriting, such as From: u...@example.com we are granting full citizenship to devious display names. Some clients (e.g. Thunderbird) can show only display name for people in the address book.[*] A close, perhaps formally easier, subject is the IDN homograph attack.[†] Would it make sense to ban, say, the use of the at sign (@) in display names? Best Ale -- [*] https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displayed [†] https://en.wikipedia.org/wiki/IDN_homograph_attack ___ 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] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: If things like DMARC, SPF, and DKIM do nothing more than get abusers to use different domains than they would otherwise, I think that's a win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of >>> the 3 that restricts the choice of domain name. >>> >>> With that in mind, I'll ask you why you think the kind of change you >>> cite is a win. >> 1. I think the domain displayed to the end user matters. In my sample size >> of 1, it matters to me. I know I'm not the average user, but independent of >> the question of how many users it matters to, there are some. > Same with me, but again I'm not the average user. +1, but then we're mailing list subscribers (leaving aside this list's topic.) >> >> 2. When abusers use different domains to send mail, it adds more >> information >> for filters to work on, so even if this is all about filtering, that works >> better too. > > But when abusers use different domains, the DMARC policy that applies is > controlled by them and is therefore meaningless. And the reports, if any > (probably none), are sent back to the attacker or their designate. > > Filtering might be done based on the DKIM signing domain or thesimilar > envelope-from domain if SPF is used, but neither of those require DMARC. The From: domain was chosen because that's the field that users can see. Now we conjecture that users don't actually see it. Oh boy. Certainly, if the From: domain is not visible we could filter on X-Filter-On-Me: and gracefully avoid the mailing list problem. On closer view, we seem to be discovering that the From: domain is obscured by the display name. We always neglected the display name. Furthermore, by letting the mailing list problem be dodged by creative From: rewriting, such as From: u...@example.com we are granting full citizenship to devious display names. Some clients (e.g. Thunderbird) can show only display name for people in the address book.[*] A close, perhaps formally easier, subject is the IDN homograph attack.[†] Would it make sense to ban, say, the use of the at sign (@) in display names? Best Ale -- [*] https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displayed [†] https://en.wikipedia.org/wiki/IDN_homograph_attack ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
