[dmarc-ietf] Re: Dmarcbis.org
On Wed, 2 Oct 2024, Neil Anuskiewicz wrote: Or if this domain doesn’t matter I’ll let it expire. Interesting thought but I don't see it being very useful. dmarc.com belongs to a second-tier mail security company in France and hardly anyone even notices. On Oct 2, 2024, at 7:28 AM, Neil Anuskiewicz wrote: I registered it defensively a while back but would happily turn it over to, say, dmarc.org or whomever. 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 To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Review of the dmarc draft documents
On Fri, 30 Aug 2024, Brotman, Alex wrote: Any comments on the alteration for the "ridtxt" that Daniel has included? There was a fair bit of back and forth when we altered that previously. Specifically: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/18/commits/21aa5a8303b65e3725d3dc10e07c4b05c02282a7 I think he's right. I see a lot of junk in the report names and in this case I think it's better to adjust the spec to match reality. I don't see much downside to doing so. 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 To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Review of the dmarc draft documents
On Fri, 30 Aug 2024, Alessandro Vesely wrote: I agree on most changes, possibly except that 05.06.07.08 seems to me an acceptable IPv4 expression, and perhaps the obsolescence note is required (?) Does anyone actually produce reports with extra zeros in the IP addresses? Unless someone has examples, I would not bother. 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 To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Review of the dmarc draft documents
Thanks for your note. I think we've addressed everything in the main
7489bis but some of the stuff in the reporting docs looks like it still
needs to be fixed.
If you're willing to futz with the markdown, pull requests with proposed
changes would be great.
All I-Ds are professionally edited before becoming RFCs so minor
grammatical and formatting problems will be fixed for us.
R's,
John
On Mon, 29 Jul 2024, Daniel K. wrote:
Prodded by 1&1 recently implementing this draft standard, I am looking
through the documents intended to replace RFC7489.
I'm unfamiliar with the IETF process, so please excuse me if I'm
worrying about something that will be handled at a later stage.
1) Errata from RFC 7489 is not incorporated into the text.
There is a list of errata in draft-ietf-dmarc-dmarcbis-33, Section C.9,
RFC 7489 Errata Summary, and it mostly says:
To be addressed in [I-D.ietf-dmarc-aggregate-reporting].
Should this not be done at this stage, or will this be handled by the
I-D to RFC process somehow, by a different editor?
Going through the list I would have expected different resolution
proposals for some of the errata.
Errata: 5365 (filename suffix), 5371 (GZIP RFC reference):
Both seem to be uncontroversial and should be addressed in
[I-D.ietf-dmarc-aggregate-reporting].
Erratum 5440 (changing: "v=DMARC1" to "v=DMARC1;")
The ABNF was changed, so the semicolon is now optional. This is only
relevant for _report._dmarc. type TXT records without tags, where
"v=DMARC1" is now allowed by the updated ABNF.
For normal DMARC Policy Records the p tag is required, and hence a ";"
must be present after the v=DMARC, however optional WSP is allowed so
"v=DMARC ;" or even "v = DMARC1 ;" should be equally valid. The text as
written gives the impression that no WSP is allowed.
Should the _report._dmarc value get its own ABNF with only rua/ruf tags?
Right now I see this record referred to as a TXT RR:
the DNS administrator for the Report Consumer will
need to publish a TXT resource record at [...] with
the value
"v=DMARC1;".
Maybe it could be referred to as a DMARC Report
Erratum 6439 (comparing host vs Organizational Domain)
I believe "Verifying External Destinations" should be updated both in
the aggregate-reporting and failure-reporting drafts.
Erratum 6485 (Report-ID ABNF: allowed value)
See the next item.
Erratum 7835 (Remove duplicate filtering step)
I believe this erratum to be invalid, as the 'duplicate' step is not
really duplicate, it is the same operation applied to different data.
2) Botched ABNF for 'ridtxt' in the txt version of the document.
Looking further, it looks like a problem with conversion due to missing
``` or ~~~ markers around the ABNF in the markdown.
3) ABNF for 'ridtxt' is too strict
Regarding ridtxt, the value for "Report-ID:"; I think I saw some place
or understood from the context, that the relaxed rules was to sanction
the current usage seen in the wild:
dmarc-subject = ... [ %s"Report-ID:" 1*FWS ridtxt ]
ridtxt = ("<" *(ALPHA / DIGIT / "." / "-")
["@" *(ALPHA / DIGIT / "." / "-")] ">")
/ (*(ALPHA / DIGIT / "." / "-")
["@" *(ALPHA / DIGIT / "." / "-")])
The 'ALPHA / DIGIT / "." / "-"' seems overly strict, and it does not
match what's in the wild, where at least "=" "$" "_" and "!" has been
seen by us.
I suggest to relax it further, e.g. as follows:
ridfmt = (dot-atom-text ["@" dot-atom-text])
; from RFC5322
ridtxt = ("<" ridfmt ">") / ridfmt
This also makes it more obvious that the angle brackets are now optional.
Further, At least fortimail and fastmail do not add the required FWS
after "Report-ID:"
4) This warning text is sometimes shown even if
there's no need to wrap the command output:
(the output shown would appear on a single
line
but is wrapped here for publication):
5) Overlap in the examples of dmarcbis and failure-reporting
With some wording differences that seem to stem from text being copied,
the worked on in one draft only.
Entire Domain, Monitoring Mode vs.
Entire Domain, Monitoring Only, Per-Message Reports
failure-reporting should also talk about per-message reports, but
"monitoring mode" is new wording for "monitoring only"
Maybe all examples should go in the main document. That way the examples
does not need to be disentangled from each other.
6) Inconsistent requirements for validating third party report consumers.
In: Per-Message Failure Reports Directed to Third Party, a few
paragraphs apart.
Mail Receivers [that send reports to third parties] may implement
additional checks
vs.
conforming Mail Receivers will implement additional checks
Should the wording be upgraded to a "MUST implement additional checks"?
7) Formal definition
"Keyword" is no longer referenced, and the note about it being imported
from RFC 5321 can be dropped.
8) The tx
[dmarc-ietf] Re: Inconsistent Organizational Domain definition
On Wed, 19 Jun 2024, Alessandro Vesely wrote: There are two considerations which I think are worth being considered. One is that it may sound unnatural to apply the PSD policy when a domain within the organization is publishing a DMARC record at a level they consider adequate. Since that does not happen, I don't see any problem to solve here. IOW, why not let the org domain be just the shortest of the organization domains for which a DMARC record was found? It sounds more natural. In nearly every case, that is exactly what DMARC does. The only time something else might happen is if the domain publishes psd=n to say to use a lower level name. We have discussed this in hundreds of messages over the past several years. I do not understand why anyone would try to relitigate it now. R's, John ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
Re: [dmarc-ietf] Proposal to Enhance Email Trustworthiness via RFC 8617 Modification - ARC
Since nobody else responded, here's my tl;dr -- interesting proposal, but no. The first problem is that there is no appetite to change ARC at this point. The other is that most if not all of the things you propose are not new. I proposed a chained DKIM signaure that lets the signer say who's allowed to forward and resign. No interest, for reasons that in retrospect I think were good ones because it doesn't scale. Ale has been proposing ways to undo list modifications for ages, again no interest. I would suggest spending some time looking at the archives of this list and related ones like DKIM and ietf-822 to see what has been proposed before, so you don't waste your own time reinventing them. Finally, while the IETF is very good at standardizing things that exist and small tweaks, it is not great at inventing new things. That tends to happen in other groups which for mail include M3AAWG and perhaps APWG. If you're interested in this kind of work, you should look into getting involved there, too. R's, John Introduction: This proposal seeks to refine RFC 8617, which governs the Authenticated Received Chain (ARC), to bolster email authentication and trust management. ARC's reliance on intermediaries for maintaining authentication across hops, while beneficial under certain conditions, engenders a dependency on third-party entities. These entities can modify message headers and affix ARC signatures, all without the originating domain's oversight, potentially undermining the system's integrity. Identified Issues: * Dependency on Intermediaries: ARC's framework mandates trust in intermediaries not necessarily under the originating domain's purview, casting doubts on the authentication process's security and integrity. * Absence of a Verifiable Trust Chain: Contrary to DNSSEC-like mechanisms, ARC lacks a transparent trust chain back to the origin, hampering efforts to independently ascertain the original authentication's legitimacy. * Lack of a Standardized Trusted Server List: The current implementation of ARC relies on large providers like Google and Microsoft to maintain lists of trusted servers, which may not be accessible or suitable for smaller providers or self-hosted servers. Furthermore, the criteria and priorities used by these major providers to compile their trusted server lists may not always align perfectly with the needs of smaller or niche providers, raising concerns about transparency and impartiality. Proposed Modifications: We suggest an amendment to RFC 8617 to empower the ARC sequence initiation right from the email's point of departure and to establish a standardized trusted server list. The modification encompasses: * Crystallization of Initial Authentication State: Document the initial SPF, DKIM, and DMARC authentication status as the email exits the originating server, detailing the evidence necessary for authenticity verification. * Documentation of Alterations: Mandate that any intermediary altering the message should annotate the specific changes made, thereby creating a verifiable chain of alterations leading back to the source. * Facilitation of Independent Verification: Introduce a facility allowing recipients to independently verify the ARC's trust chain, thereby eliminating undue reliance on intermediary trust. * Establishment of a Standardized Trusted Server List: * Major email providers will maintain a publicly accessible list of trusted servers, regularly updated and serving as a reference for smaller providers and self-hosted servers. * The list will adhere to a minimum set of standards, including categorization based on authentication capabilities and a machine-readable format for easy integration. * To ensure transparency and impartiality, the process of compiling and maintaining these lists should involve input from a wide range of stakeholders, including smaller providers. Mechanisms should be in place for providers to contribute data, provide feedback, and appeal decisions related to the trusted server lists. * Implementation Guidelines for Smaller Providers: * Smaller providers and self-hosted servers can choose to rely on the standardized trusted server list, with the flexibility to supplement it based on their specific requirements. * ARC implementations for smaller providers will include functionality to fetch and cache the trusted server list, compare intermediary authentication results against the list, and assign trust levels accordingly. Implementation Details Draft: While the full specification of the proposed modifications will require further discussion and refinement with the IETF community, here is a high-level overview of key implementation aspects to be addressed: * Standardized Trusted Server List: * JSON format with mandatory fields (hostname, IP, authentication capabilities, trust score, last update) * HTTPS REST API for access with rate limiting * Daily updates and high availability ens
Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: This WG should have finished a year ago. Unless you think something is so broken that it's worth more months of delay, forget it. To be clear I was suggesting considering deprecating the hardfail modifier only as it’s archaic. I was not saying deprecate SPF. That said, i don’t know what the unexpected consequences of this change would be. I think SPF still has its place. Maybe they’ll make some adjustments over in the SPF working group. It's not a terrible idea, but this is dmarc-bis, not spf-bis. It's way outside the scope of this WG. 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] the long march, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
On Sat, 6 Apr 2024, Scott Kitterman wrote: As a side effect of the switch to the tree walk approach in DMARCbis, this is no longer true. For any subdomain without a DMARC record, the domains above it in the tree are also checked, so you can specify a different policy/ reporting address for groups of subdomains below the org domain (as long as you don't get past the max N value in length). Huh, what? Whatever the tree walk finds is by definition the org domain. It's the same whether you're using it to check alignment or send reports. I can articulate that N=5 is based on the longest email relevant entry in the current PSL. Why N=8 and not N=7 or N=9? Seth says there are people who need N=8 but for business reasons he can't tell us who they are. I'm not thrilled about that but I see little downside to bumping the number up to 8. 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] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: I think clear statement and supporting text explaining clearly that SPF is no longer the policy layer would be a good idea. While it might be slightly out of scope, I have encountered people who think best practice is to enforce with -ALL. We had a long discussion about that which you can read in the list archive at https://mailarchive.ietf.org/arch/browse/dmarc/ Nobody is crazy about SPF but removing it completely is too much of a change. As Ale pointed out, if you don't want people to use SPF for your DMARC validation, make all your SPF entries ? or ~ rather than +. This WG should have finished a year ago. Unless you think something is so broken that it's worth more months of delay, forget it. 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] There is no pony, Overall last-call comments on DMARC
No might about it -- ARC is only useful with domain reputation. Of course, DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I don't see why it's a problem now. Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain identifier that could be used by a reputation system. They avoided saying that they were doing anything about spam and phishing. OTOH, DMARC is explicitly saying that it’s there to do something about phishing. It was totally obvious at the time what DKIM was intended for, so I don't think that's likely to be persuasive. In practice, ARC isn't that bad. IF you're a really big mail system you can collect your own repuations, if you're not so big your users probably subscribe to few enough legit ARC signers that you can manually whitelist them. On my system I think there's about five. It's not like the general spam problem where you have a zillion new identifiers every day most of which are spam but a few are not. Our choices are to say here's what DMARC does, it has these problems, here's how to use it for the situations where it works, here's how to sort of mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC is BAD and we will not endorse it and NOBODY should use it, and the rest of the mail world will say isn't that cute, the IETF is having a tantrum. Or we can say that it’s not ready for standards track yet. The only time I can think of in this space that we have stamped our feet and said something is BAD was with ADSP. But I am troubled by the mandatory requirements imposed by organizations citing an informational RFC, RFC 7489. It makes it seem like standards track doesn’t mean as much as it should. Well, ADSP actually was bad, and DMARC has reinvented much of what was bad about it, but unlike ADSP, it's used by every significant mail system in the world so we're stuck with it. I have heard somewhere that successful standards document actual practice even if the practice is not ideal. It's up to us, we can say nope, not a standard, and people will use it as a standard, or we can say it's not great but here's the standard, and they will use it as a standard. I know which one I'd do. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
I don’t think it’s scope creep at all. The WG charter puts “Review and refinement of the DMARC specification” in phase III, after “Specification of DMARC improvements to support indirect mail flows”. It seems clear to me that standards-track DMARC needs to incorporate those improvements. IESG accepted ARC as an improvement to support indirect mail flows, and I think a complete solution needs to incorporate that. I wish there were better data to support advancing ARC to standards track, and not just from Google (it has to work for smaller players as well). But I am troubled by the possibility that ARC might require domain reputation to avoid ARC header fields supporting From address spoofing. One reason it might work for Google is because they’re big enough to derive their own domain reputation. We’ve not had success with domain reputation at internet scale. No might about it -- ARC is only useful with domain reputation. Of course, DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I don't see why it's a problem now. We've been going around and around for years now. DMARC works pretty well for direct mail flows, so-so for simple indirect flows (forwarders) and really badly for mediated indirect flows (mailing lists.) There is nothing better than ARC to mitigate those problems and this WG certainly isn't going to invent anything now. I agree that at this point we don't have enough evidence to advance ARC, so we can punt the question of what or when to do with it to MAILMAINT or something. Our choices are to say here's what DMARC does, it has these problems, here's how to use it for the situations where it works, here's how to sort of mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC is BAD and we will not endorse it and NOBODY should use it, and the rest of the mail world will say isn't that cute, the IETF is having a tantrum. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Sun, 31 Mar 2024, Jim Fenton wrote: Based on the above problems, I do not think DMARC-bis should be published as a standards track document by IETF. This reminds me of the NAT wars in the 1990s. We all understand that DMARC has a lot of problems, but it's far more widely used than many of the IETF's published standards. It just makes us look insular and out of touch to pretend that it doesn't exist, or if we shut our eyes it will go away. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
I’m probably being pedantic here: is “gov” a domain? Yup, it's a domain. I stand corrected on that. Anything that meets the DNS spec is a domain namen, e.g., argle.bargle.parp is a domain name. If and how particular names might be resolved is a topic to which the IETF and ICANN have given a certain amount of attention. Might be worth bumping up. Examples: execute-api.cn-north-1.amazonaws.com.cn cn-northwest-1.eb.amazonaws.com.cn (Amazon seems to have most of the really long ones) None of those Amazon ones are used for mail so they're irrelevant to DMARC, but see Seth's recent message. He says he's seen mail domains 8 deep. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
Our advice is not to publish a DMARC policy if you want to use mailing lists. We have a lot of experience with message rewriting and I think we have all found that the options range from pretty bad to really bad, so there's nothing to recommend. “Our advice” seems not to be followed by many domains sending to this mailing list, including several significant providers of email products/services. Huh. In the decade this list has been active and the 12,000 messages posted to it, nobody ever noticed that before. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
Entities other than domains: Public suffixes aren’t (necessarily) domains, Of course they're domains. What else could they be? The things that are out of scope are IP addresses, ASNs, magic tokens in the messages, stuff like that. I’m probably being pedantic here: is “gov” a domain? Let's check: $ dig gov soa ; <<>> DiG 9.10.6 <<>> gov soa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63612 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gov. IN SOA ;; ANSWER SECTION: gov. 300 IN SOA a.ns.gov. dns.cloudflare.com. 1711843800 3600 900 604800 300 Yup, it's a domain. Second bullet: “most MUAs display some or all of the contents of that field”. I find this becoming less and less true. Many MUAs that I use, including Apple Mail (iOS) and Outlook, display only the Display Name, which is not authenticated at all as pointed out much later (11.4). Perhaps it should say "can display". I agree you're more likely to see the comment in the From header than the domain these days. I’m not sure how helpful “can display” is if you have to figure out how to display message source or something. Of course, there is also the argument that users’ behavior won’t be any different even if it is displayed. I wouldn't object to taking it out since I agree that it's neither very accurate nor very helpful. I happen to run the registry for seneca.ny.us, watkins-glen.ny.us and other local places and it seems fine to me. Can you give some examples? Mine wasn’t a good example. There are a few public suffixes that have more than 5 labels. Presumably that means there are registered domains that are 6 levels down, and my reading of the tree walk is that a policy published there would never be seen. But who knows if they’re actually sending email. There aren't any in the PSL. That's where the limit of 5 came from. We've had people say there are deeper ones; if there are it wouldn't be hard to bump up the limit from 5 to whatever. Side note: I got well into this document before I realized that DMARC is publishing an assertion of being a public suffix. Some mention of that belongs back in the introduction. A what? It's only using PSDs as a way to figure out the org domain. We certainly don't expect other users of the PSL to switch. Maybe there should be an admonition to say that other applications MUST NOT use a psd=y record for anything. I really don't want to get into speculation about what people might do wrong and tell them not to do that. Our job is to tell people how to interoperate -- if you do what the spec says, it'll work. 4.7 DMARC policy discovery -- Paragraph 3: “domain does not exist”: How is that determined, NXDOMAIN, NODATA? What happens with SERVFAIL (e.g., DNSSEC problem) or no response? And if a domain really doesn’t exist, isn’t that a reason to reject “with prejudice”? As it says later, error handling is up to you. IMO the specification is incomplete if it doesn’t say how nonexistence is determined. I'm pretty sure we went through that, and it's a quality of implementation issue. If you get SERVFAIL, maybe you want to wait and see if it fixes itself, maybe you figure that if people want to get their mail delivered they should have working DNS. I don't see how anything we said would make any real difference to interoperation, and in practice, the DMARC records tend to be pretty close to the MX records so it's unlikely that one would be broken and the other wouldn't. Paragraph 4 bullet 1: “syntactically valid”: It seems like there are a lot of URIs with valid syntax that would not make sense here. What if someone publishes [sip://example.org](sip://example.org) or [gopher://example.org](gopher://example.org)? Another self-inflicted wound, so we don't care. I believe the report documents now say that only mailto: actually works. I proposed an https method similar to what MTA-STS has but nobody was interested. Considering how few people use https MTA-STS reports, it's hard to disagree. Maybe it should be limited to mailto: URIs unless someone publishes an extension to another URI scheme. Look at the report drafts and see what you think. 11.4 Display Name Attacks - This goes to one of the overarching concerns I have about DMARC. I am getting lots of spam and phishing with plausible display names but obvious throwaway addresses controlled by attackers. “Further exploration…needs to be undertaken” is not a sufficient response IMO. I think we should take this section out. There have been a lot of discussions at M3 about what to do about display name attacks and nobody has any idea beyond normal spam filtering. Strongly disagree. The Security Consider
Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
I concur with Jim that rewriting strategies are in scope for the WG according to its charter, especially if we have something to recommend going forward. Our advice is not to publish a DMARC policy if you want to use mailing lists. We have a lot of experience with message rewriting and I think we have all found that the options range from pretty bad to really bad, so there's nothing to recommend. Also keep in mind that there is ARC, and probably follow-ons to it, so we wouldn't be doing people any favors by recommending rewrite strategies that screw up lists and are likely to become obsolete. 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] WGLC review of draft-ietf-dmarc-dmarcbis-30
Below is a number of “minor issues and editorial comments” on dmarcbis-30. I have a larger issue regarding the draft as a whole that I have yet to write up and will post separately. Thanks for the review even though I disagree with a fair amount of it. 2.1 High level goals PSOs: Define this abbreviation on this first use. Since it’s talking about a public suffix, “the domain” doesn’t seem sufficient, maybe “the domain or suffix”. Right. Side note: I’m very dubious about the allowances for DMARC records to be published by public suffixes since the PSO is much less likely to know the usage of the domains under it, and whether a policy like Reject is appropriate. But I suspect the WG decided to include the public suffix policies so this would be a relitigation. PSDs were originally invented for .BANK and .INSURANCE which know exactly what their registrants' policy should be because it's in the contract. Beyond that, since we're not using the static PSL any more, the PSD flag fixes some uncommon cases where the tree walk would otherwise get a wrong answer. We debated this at extreme length and it ain't gonna change now. 2.4 Out of scope Entities other than domains: Public suffixes aren’t (necessarily) domains, Of course they're domains. What else could they be? The things that are out of scope are IP addresses, ASNs, magic tokens in the messages, stuff like that. 4.2 Use of RFC5322.From --- Second bullet: “most MUAs display some or all of the contents of that field”. I find this becoming less and less true. Many MUAs that I use, including Apple Mail (iOS) and Outlook, display only the Display Name, which is not authenticated at all as pointed out much later (11.4). Perhaps it should say "can display". I agree you're more likely to see the comment in the From header than the domain these days. authenticates the individual sender. So the recipient would just be guessing. Last paragraph: I don’t see a profile of RFC5322.From in section 5.7. It's in 5.7.1, From with more or less than one domain is out of scope. 4.5 Flow Diagram This diagram and accompanying explanation doesn’t help me at all. “Solid lines”: Dashed lines, maybe? We should redraw this in SVG with an explanation of what the different kinds of arrows are supposed to mean. 4.6 DNS Tree Walk - Step 2 starts talking about the psd flag without telling what it is. It would be much better if this discussion came after the flags and their meanings was introduced. I’m concerned that some (admittedly rare) public suffixes with multiple components are not well served by this algorithm, such as pvt.k12.ma.us. I happen to run the registry for seneca.ny.us, watkins-glen.ny.us and other local places and it seems fine to me. Can you give some examples? What happens if a domain that is not a public suffix publishes psd=y, either accidentally or maliciously? Its subdomains might get the wrong organizational domain. This seems to me a self-inflicted wound. Side note: I got well into this document before I realized that DMARC is publishing an assertion of being a public suffix. Some mention of that belongs back in the introduction. A what? It's only using PSDs as a way to figure out the org domain. We certainly don't expect other users of the PSL to switch. 4.7 DMARC policy discovery -- Paragraph 3: “domain does not exist”: How is that determined, NXDOMAIN, NODATA? What happens with SERVFAIL (e.g., DNSSEC problem) or no response? And if a domain really doesn’t exist, isn’t that a reason to reject “with prejudice”? As it says later, error handling is up to you. Paragraph 4 bullet 1: “syntactically valid”: It seems like there are a lot of URIs with valid syntax that would not make sense here. What if someone publishes [sip://example.org](sip://example.org) or [gopher://example.org](gopher://example.org)? Another self-inflicted wound, so we don't care. I believe the report documents now say that only mailto: actually works. I proposed an https method similar to what MTA-STS has but nobody was interested. Considering how few people use https MTA-STS reports, it's hard to disagree. Also, don’t a lot of these things that have to do with reporting belong in one or both of those drafts (which I haven’t read yet)? This is just what goes in the DMARC record. The other stuff is indeed in the other drafts. 4.8 Organizational Domain Discovery --- Paragraph 2, bullet 2: “DMARC mechanism does not apply”: What if there is a PSO policy? Or is that covered by the tree walk? (I may have gotten lost here) Yes, it is covered by the tree walk. The PSD stuff is part of the tree walk mechanism. 5\. Policy -- Paragraph 2: “A Domain Owner…may choose not to participate...by not publishing an appropriate DNS TXT reco
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
::00::12.34.56.78 0:0:0:0:0:0::012.034.056.078 The latter yields failure running the example program in the inet_pton(3) man page. See e.g. https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES That's yet another reason not to change the XML spec. Please stop. 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] Fwd: [Technical Errata Reported] RFC7489 (7865)
Apologies, which format should be used. I'm not sure if I should revert to the
one from 7489, or some other prior version.
The one that's in the draft now is fine. Don't add the line with f{4}
which is an insufficiently general special case.
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] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Mon, 25 Mar 2024, Alessandro Vesely wrote:
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Testing yielded a correct fix:
"(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
There are lots of other ways to write it, e.g.
::00::12.34.56.78
0:0:0:0:0:0::012.034.056.078
and they're actually IPv6 addresses. Just take it out, if nobody has
tried to use this form in the past decade, they won't use it now.
Please take my pull request.
Please take out the grammar change.
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] no DMARC result for DKIM testing and policy
On Fri, 22 Mar 2024, Benny Pedersen wrote: to confusion about DMARC and DKIM test flags. This document is already too long and too late. Unless there is an actual problem to solve here, let's close the issue and finish up. why is dkim fail here Because the mailing list modified the message before that header was applied. The IETF's mail server is a mess, and will be completely replaced over the next month. X-Spam-Status No, score=-1.321 tagged_above=-999 required=5 tests=[AUTHRES_DKIM_FAIL=0.5, DKIMWL_WL_HIGH=-0.372, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-2, RCVD_IN_ANONMAILS=1.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=1.3, SPF_PASS=-0.1] autolearn=unavailable autolearn_force=no Authentication-Results mx.junc.eu (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b="Xr+FwPZI"; dkim=pass (1024-bit key) header.d=ietf.org header.b="Xr+FwPZI"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b="qTXLFk6y"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b="IB1/7fRP" Authentication-Results ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b="qTXLFk6y"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b="IB1/7fRP" its already dkim fail at delivery to amsl ? let me see if eitf still breaks my dkim :=) 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] of course no DMARC result for DKIM testing and policy
While I generally agree, DMARC for the last decade didn't have a testing flag. That's new in DMARCbis, so I don't think that's really germane. This particular thing is on us as a working group. RFC 6376 makes it quite clear on page 28 that DKIM verifiers ignore signatures with a t=y flag, and treat them as though they're not there. What else is there to say? If they're not there, the message isn't signed, at least not with that signature. I really hope that nobody is proposing, oh, but DMARC is special so if your DMARC policy has a testing flag, you reach through into your DKIM verifier and pretend that test signatures count. That would require an update to 6376 and updates to every DKIM library to have a way to say "ignore the test flag", and would require DMARC validators to find the policy record before they could do DKIM evaluation. So once again, there is nothing to say here, so let's not say it. 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] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Now with Mike's tweak: Add this to 11.1 Authentication Methods Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies map domain names to sets of authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record. Whenever mail is sent, there is a risk that an overly permissive source may send mail that will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for authentication failures. To avoid this risk one must ensure that no unauthorized source can add DKIM signatures to the domain's mail or transmit mail which will evaluate as SPF pass. If, nonetheless, a Domain Wwner wishes to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the '?' qualifier on the SPF record mechanism associated with that source. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Mon, 18 Mar 2024, Alessandro Vesely wrote: The text should be terser and clearer, possibly with an example. I would be happy to remove the whole thing, since it's only distantly related to defining or implementing DMARC. 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] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact, authorized by the Domain Owner. These false positives may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's requested message handling for authentication failures. I have a problem with this 2nd paragraph and believe it is factually incorrect. The Domain Owner has in fact authorized the message(s) as a result of an overly permissive approach. I would suggest that in fact any resulting DMARC pass is technically NOT a false positive because it is authorized by the overly permissive approach.. Seems to me we it depends on what you think "authorized" means. My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition. Is there some other wording that can make the difference clear? 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] Problem with multiple policies, different alignment
Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server used as AD, and resolvers) They still do that? Wow. At least that won't screw up DMARC evaluators too much. In any event, I don't think it's our job to redesign our specs for the benefit of people who've ignored other IETF standards. 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] DMARCbis WGLC Issue - Description of rua and ruf Tags
On Fri, 1 Mar 2024, Seth Blank wrote: It seems OK but I would say that at this point that mailto: URI are the only ones currently defined. Participating, to this point. Throwing out an idea, that may be spectacularly bad: mailto: is the only function that's ever been used. We even discussed exploring other mechanisms, and consensus was to drop that exploration. I can't find the ticket quickly, but I know it was covered early on during the bis work. Do we just want to dramatically simplify this, and throw the "mailto:"; into the reporting ABNF and call it a day? It would dramatically streamline the text. That would be fine with me. I proposed an http method similar to the one for mta-sts and everyone said no need, mail is plenty fast. I have mta-sts https set up and indeed, basically nobody uses it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"
Together with DMARC p=none as DKIM signature-presence is ignored and thus any email can pass. I don't understand. Me neither. I still don't see any reason to revisit this issue. Nothing has changed since the last time we argued about it. R's, John PS: About RFC 5617 At that time, when DKIM deployment was low (though I have had DKIM since 2009 at least) and DMARC did not exist/heavy-use... it thus got marked historic again. It was also another separate TXT entry to check. That's not how I remember it. The potential side effects of demanding a valid signature on all messages were discouraging enough that ADSP never saw any serious uptake. We documented this in RFC 6377 and proposed some operational solutions, but (as you can see from this list's discussions over the years), it's still a problem today. I'm one of the authors of 5617 and that's the way I remember it too. There was and is no way other than a repuation system to tell whether to take a domain's ADSP seriously, and if you have the reputation, you don't need ADSP. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] (no subject)
On Mon, 6 Nov 2023, Douglas Foster wrote: Since IETF cannot protect its own lists from conspicuous impersonation, it seems poorly qualified to tell anyone else how to do so. Actually, that message had nothing whatsoever to do with impersonation, and everything to do with an obscure configuration error in my mail system. Leaping to conclusions is rarely helpful. 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] p=interoperability p=compliance p=orgname:policyname
Please, no. This WG has already run a year past its sell-by date. Stuff like this will just tell the world that we'll never finish. Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw consensus start to form, I started citing dmarcbis whenever explaining how DMARC works (or should work) to people who need to know. Most are still relying on the original language/assumptions as the basis for their knowledge, so there are going to be questions to answer and operational practices to think about during the transition period (forever). Is there a better place to discuss future topics like this? We've talked about an application statement that suggests how best to use DMARC. But there's a giant installed base, and we would need an extremely good reason to make an incompatible change at this point. We spent months debating the tree walk and establishing that in nearly every case the answers will be the same as now, or if different, no worse, so we figured that was a change that we could get away with. 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] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis
1) a receiver that will forward quarantined messages, and do so without changing the bounce address. Solution: Don't Do That. That's a confounding issue but not the root problem I think. Even if Microsoft were to implement keeping the bounce address, it just means that the spammer has to start with the spoofed return-path address on their initial send. No, I mean that MS needs to put the actual address of the person forwarding the mail as the bounce address. Then it's his reputation in the SPF. No, then it has the forwarding party's signature which isn't aligned with the From header. A spammer could write a From header in anticipation of adding a forwarder's DKIM signature. This already happens with the SPF upgrade scenario. If someone is willing to send mail with their From address and their signature, I think that mail is from them, regardless of how it got there. If this means their reputation takes a hit, they deserve it. 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] Another p=reject text proposal
I do like your suggestion of silent discard rather than bounce, and I would want to see that change made -- perhaps with a note that aggregate reports will still include information about those discards. Having thought about it for a minute, I have a better question. We already know that sites that reject list mail for DMARC failures do not care about mailing lists because if they did care, they wouldn't do that. So I think the chances of them making a change that only benfits lists rounds to zero. Why is it up to the recipient systems (the ones that do not care) to make life easier for lists? Mailing list packages already do lots of analysis of bounce messages. How about if they fix their bounce processing to recognize DMARC failures and do something different. Certainly for the large recipepent systems that handle the bulk of mail these days the rejection messages allcontain words like DMARC or authentication so it's not hard to figure out. Bonus question: if you send a lot of mail to a recipient system that it rejects, you will get a bad reputation and they are likely to view the mail you send with great scepticism, even for the stuff that survives DMARC. Suppressing the bounce messages only makes it harder to figure out why the mail is all disappearing. Extra bonus question: how many minutes will it take for spammers to hope that suppressing the bounces will somehow help them evade filters (whether or not that's true) so they'll start putting List-ID on plain old spam? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS: some of us actaully do want the bounces from our lists, since we have various hacks to evade DMARC and want to know if they don't work. We find this proposal has negative benefit. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
Presumably, a sender who uses DMARC might publish SPF to cover recipients who don't use DMARC, but would prefer that recipients use DMARC (authenticated by DKIM only). I get that, but that's still simultaneously saying "use SPF to authenticate me" and "don't use SPF to authenticate me." If SPF is so unreliable that you don't want people to use it for your DMARC alignment, why would you want them to use it otherwise? I worry this is encouraging security theater, look I have super secure DMARC p=reject and, we won't get our deliverability numbers without a big fuzzy SPF record. R's, John Barry On Fri, Jun 23, 2023 at 1:54 PM John R Levine wrote: My understanding is that if `auth=dkim` then SPF would be ignored from the perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and only SPF is DMARC aligned then it would still be treated as a DMARC fail. That's my understanding. It would be a way for senders to say "yes I checked that all my DKIM signatures are working and aligned, I don't need you to look at SPF and don't want to have the risk of SPF Upgrades. So why do you publish an SPF record? Presumably so someone will accept your mail who wouldn't otherwise, except you just said they shouldn't. Still not making sense to me. 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 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] easier DKIM, DMARC2 & SPF Dependency Removal
My understanding is that if `auth=dkim` then SPF would be ignored from the perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and only SPF is DMARC aligned then it would still be treated as a DMARC fail. That's my understanding. It would be a way for senders to say "yes I checked that all my DKIM signatures are working and aligned, I don't need you to look at SPF and don't want to have the risk of SPF Upgrades. So why do you publish an SPF record? Presumably so someone will accept your mail who wouldn't otherwise, except you just said they shouldn't. Still not making sense to me. 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] easier DKIM, DMARC2 & SPF Dependency Removal
On Thu, 22 Jun 2023, Emanuel Schorsch wrote: I agree with John's point that dkim+spf doesn't make sense in the context of strict DMARC enforcement (I think it provides value for p=none domains Since the aggregate reports tell you what authentication worked, I don't even see that as a benefit. There's also the question how many people would even look at a DMARC v2 tag which would be a prerequisite for the auth tag. confused users misusing that option. I would support allowing the following options for the auth tag: "auth=dkim|spf (default value: same as current state), auth=dkim, auth=spf" The idea is that auth=dkim means you'd publish SPF records but hope people will ignore them, or vice versa for auth=dkim? I still don't get it. 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] easier DKIM, DMARC2 & SPF Dependency Removal
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: I suggest that we do not only drop SPF, but also come up with better ways (simplification, tools, exchange formats) to implement DKIM in order to allow for a smooth transition. I'm scratching my head here. On my system I publish and rotate DKIM keys completely automatically. The only manual config is to edit the list of domains when I add or remove one from my mail server. It's not totally trivial but it's not that hard. I suppose we could encourage people to implement ed25519 signatures since the keys are small and more likely to fit in a single TXT record string for provisioning crudware that doesn't handle multiple strings, but beyond that, what do you have in mind? 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
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] Third party signatures
It is not a commitment at this time. That said, we are interested in solving this problem and welcome collaboratively figuring out the right way to do this. It seems to me that ARC provides the useful parts of third party signatures and, while rather complicated, has the benefit of actually existing. The chain of authority runs from the relay host back to the original rather than the other way around, but that's a lot easier to do mechanically. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
6.1. Data Exposure Considerations Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the domain-level identifiers involved in DMARC validation. Aggregate reports may expose sender and recipient identifiers on domain level, specifically the RFC5322.From domain. No personal information such as individual email addresses, IP addresses of individuals, or the content of any messages, is included in reports. However, low-traffic reports may allow a mapping of 'record' elements to individuals due to a lack of aggregated data. A malicious Domain Owner might add a unique user identifier to messages (e.g., as DKIM selector) that allows a tracking of individual users in aggregate reports. [remaining section unchanged] Looks mostly good to me. By the way, that bit about a malicious Doamin Owner is not hypothetical, and I don't think I'm malicious. Just make it A Domain Owner ... 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] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
Since the only mechanism is mail and nobody's going to S/MIME encrypt their reports, I suggest just deleting it. TLS vs not TLS. I suppose, but that's not up to the report sender. If I say "rua=mailto:rep...@cruddy.org";, and the MX for cruddy.org doesn't do STARTTLS, what are you going to do? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
I removed the small section that faced objections. I updated the ridtxt definition and discovered that mmark was making a mess of those asterisks. When there are more than one/some on a single line, it believes you would like some subset to be defined as "" things. Looks pretty good. Minor points: The first paragraph in 2.6 says: Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism. Since the only mechanism is mail and nobody's going to S/MIME encrypt their reports, I suggest just deleting it. 6.3: Mail Receivers should have no concerns in sending reports as they do not contain personal information. ... Domain Owners should have no concerns in receiving reports as they do not contain personal information. As explained in 6.1, that's not actually true if the domains are small enuogh. In some of my tiny domains I can often recognize individual messages I've sent. I'd just delete these sentences. R's, John -Original Message- From: dmarc On Behalf Of internet-dra...@ietf.org Sent: Monday, April 24, 2023 7:39 PM To: i-d-annou...@ietf.org Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain-based Message Authentication, Reporting & Conformance (DMARC) WG of the IETF. Title : DMARC Aggregate Reporting Author : Alex Brotman Filename: draft-ietf-dmarc-aggregate-reporting-09.txt Pages : 28 Date: 2023-04-24 Abstract: DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. The IETF datatracker status page for this Internet-Draft is: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc- aggregate- reporting/__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7 nLWuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqF46TKSvg$ There is also an HTML version available at: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc- aggregate-reporting- 09.html__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nL WuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEqNRr1SA$ A diff from the previous version is available at: https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft- ietf-dmarc-aggregate-reporting- 09__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuC bVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqFdWqTU2g$ Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ dmarc mailing list dmarc@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! !CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuCbVwCD o_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEDBiM7_A$ 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] list history, Signaling MLMs
I'm assuming that the "long list of stinky possible workarounds" are the existing "whatever" mitigations, and rewriting seems to be acceptable enough as a mitigation to convince large [enterprise] mail systems to move forward with restrictive policies. ... I think you are greatly overestimating the connection between cause and effect here. The people setting the policies have no idea what effect they have on their users, and to the degree they do, they do not care. IETFers at large organizations who support their IETF work, and that have p=reject, tell me they've told the IT departments that the policy is making it hard for them to get their work done and the response is either "duh?" or "not our problem." I intentionally published > "p=quarantine pct=0" specifically to find the MLMs that implemented no mitigations, weighed that against what I knew about which receivers enforced non-mitigated mail, and then made a judgment call to move forward. It sure would be nice if people at other organizations were as concerned about the quality of mail service to their users. But noo. I believe Wei suggested that we need to find a better "whatever" (in the form of an alternative to SPF and DKIM that works with mailing lists) ... I would like a pony, too. But ARC is as good as we have now and after a decade of beating our heads against the wall, I don't think we're going to find anything better. I've suggested a bunch of things that would make lists' life better, and nobody is interested: https://datatracker.ietf.org/doc/draft-levine-may-forward/ https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ 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] Signaling forwarders, not just MLMs
I’ve talked about this before. I ran into a utility company that I conversed with that explicitly didn’t want to use DKIM because they felt their messages should not be forwarded to another provider. I didn’t quite understand the logic, but it was their decision. I believe it, but needless to say, the fact that some people do dumb things don't make them any less dumb. R's, John I definitely favor some language that endorses using both and perhaps even outlines the pitfalls of using only one (can’t forward, both gives you a better chance of success, etc) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Thu, 13 Apr 2023, Dotzero wrote: It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters but there is a calculus regarding the tradeoffs of a very small percentage (in the case of my former a very small fraction of a percent) of email not getting delivered vs the damage caused to recipients of malicious emails involving direct domain abuse. ... Well, yes, I oversimplified a little for effect. In your case, you know all the places that should be sending mail with your name on it, no random third party ESPs or mailing lists, and you know who should be getting it. So if a trickle ends up at mailing lists or ticketing systems or any of the other things that munge messages on the way through, you don't care about that trickle. 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] Signaling forwarders, not just MLMs
Anyone who does forwarding is damaged by DMARC because there are a lot of people who do DMARC on the cheap with SPF only. This brings up another issue, I think: that there should also be stronger advice that using DKIM is critical to DMARC reliability, and using SPF only, without DKIM, is strongly NOT RECOMMENDED. Well, it depends whether you care whather people get your mail. I'm trying to figure out where best to say this, but when you say p=reject, you are saying your mail is *not* important, and if there is any doubt about it, you want recipients to throw it away, even though some of your real mail will get lost. In ADSP I made the equivalent policy "discardable" to reinforce this point. My co-authors weren't happy about it, but they couldn't disagree. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Wed, 12 Apr 2023, Eric D. Williams wrote: No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists ... mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's a failure with DKIM signature invalidation as a result of relaying via mailing lists. My mailing lists put their own DKIM signature on the outgoing mail, and the DKIN spec says to ignore signatures that don't validate, so as far as DKIM is concerned, that mail is fully authenticated. As RFC 6376 says: INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs. It's only DMARC that adds a new and in this case unfortunate rule that requires a DKIM signature that matches the domain in the From header. 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] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
I note that you didn't write "MUST NOT". I heartily concur with "shouldn't" or SHOULD NOT. I still have issues with "MUST NOT". Keep in mind that MUST NOT doesn't mean "do this and you will die", it means "do this and you won't interoperate" which seems exactly correct here. SHOULD NOT means that you have external reasons to believe that you'll interoperate anyway, which doesn't seem right here, unless your plan is to send mail from your p=reject only to people with whom you have private whitelisting agreements. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Tue, 11 Apr 2023, Neil Anuskiewicz wrote: If DMARC can protect domains from spoofing which I believe ends up costing over $14 billion per year. Forget about the $14 billion and think how this crime spree affects people’s view But it obviously can't do that, and what it does do happens at considerable cost. I don't know where that $14B number came from but I am reasonably sure someone pulled it out of his, er, hat. WHen people talk abbout "spoofing", they might mean exact domain impersonation or they might mean lookalikes, or as likely as not mail where the body impersonates someone and the From address is totally unrelated since, as Dave Crocker often reminds us, most users don't look at the return address and a lot of mail software doesn't even show it. DMARC only addresses one modest part of that. If you are someone like Paypal or a big bank, and you have full control over all the routes of your mail, AND IT DOES NOT MATTER IF YOUR MAIL GETS LOST, p=reject makes sense. The farther from that you are, the less sense it makes and the higher the costs you impose on other people. People chronically forget the capitalized part when thinking about the tradeoffs. There are lots and lots of examples of real costs that DMARC imposes on real people that have nothing to do with mailing lists. I used to handle the mail for my local town government. Many of the users asked me to forward their town addresses to Gmail acounts. In 2020 I noticed in my logs that mail from the US Census Bureau was getting lost due to DMARC rejects when I forwarded it. The Census had implemented DMARC in the cheapest possible way, a bunch of SPF records and no DKIM. Losing that mail was a big deal -- this was in preparation for the 2020 census enumeration, and towns care deeply about that since a decade of revenue sharing depends on the census count. Once I noticed the rejects, I knew that the least bad workaround was to have Google pull the mail, so I had to spend time setting up mailboxes for everyone, spend more time explaining to my users what the problem was, and spend their and my time walking them through and checking the setup on their end. This is all actual costs imposed on actual people, none of which would have been needed if the Census just deleted their DMARC record. Maybe they're a phish target, but the way they treated DMARC as a checklist item suggests not. Or there's Yahoo and AOL, who used DMARC to force the costs of their own security failures on the rest of the Internet. (See many previous messages for details.) When we say that mail systems that don't fit the DMARC threat profile shouldn't publish DMARC policies, we have good reasons to say so, and that's what our standards need to say if we're serious about interoperating. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (it might be)
On Mon, 10 Apr 2023, Alessandro Vesely wrote: On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote: It appears that Eric D. Williams said: -=-=-=-=-=- I think the reliance upon list operators is properly placed on that role. It's not a DMARC problem, it's a DKIM problem, I think. No, it's a DMARC problem. DKIM didn't cause any problems for mailing lists (ignoring ill-advised and never used ADSP) until DMARC was layered on top of it, and AOL and Yahoo abused it to foist the support costs on the rest of the world after they let crooks steal their users' address books. That's how it happened. Can we now accept their push? After so many email addresses became public, how about accepting that email addresses being public doesn't have to imply that anyone can impersonate them? No, that's not what happened. People had been faking AOL and Yahoo addresses forever and the providers dealt with it. The problem was that spammers used the stolen address books to send spam from the addresses of people the recipients knew, and they were flooded with complaints "why are my friends spamming me." It's entirely the fault of those providers' poor security. Re impersonating, until DMARC can tell the difference between impersonation and the kinds of ordinary forwarding we've been doing since the 1980s, nope. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
I haven’t done extensive research but here is a live example where treewalk will cause a result change. From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record. _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:dmarc_...@emaildefense.proofpoint.com"; _dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;" "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;"; "ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;"; "fo=1" Good catch, although in this case I think the most likely result is that the people at bmcc.cuny.edu will say "who set up Ret.bmcc.cuny.edu?" I see that bmcc.cuny.edu and cuny.edu both use Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to O365. There's some other strangeness; www.cuny.edu is a CNAME for web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A records pointing to machines running sendmail. It might be interesting to set up a web page where you can put in a mail domain and it'll tell you whether its treatment will change with the tree walk. 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] Not Security considerations - Aggregate reports
On Tue, 15 Nov 2022, Douglas Foster wrote: If a server farm hosts DomainA and DomainB, and I only get DMARC aggregate reports when I send to DomainA, then I can conclude that DomainB is not evaluating DMARC and is therefore more vulnerable to impersonation attacks than DomainA. You can conclude whatever you want, but all you know is that they don't send reports. You don't know whether they are looking at DMARC and for some "security" reason don't send them. In any event, the point of IETF standards is to tell people how to interoperate. It is not our job to try to save people from themselves. If someone doesn't want to use DMARC, that's up to them, not to us or to you. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis Privacy Considerations was: Re: I-D Action: draft-ietf-dmarc-dmarcbis-17.txt
I will agree with Ale somewhat. While we should say that PSDs MUST NOT publish a ruf= tag, it would be prudent also to say that reporters MUST ignore a PSD's ruf= tag in case one is there anyway. Belt and suspenders. How about SHOULD NOT? No. We have already wasted too much time on this exiguous corner case. 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] DMARCbis Privacy Considerations was: Re: I-D Action: draft-ietf-dmarc-dmarcbis-17.txt
So the question: Does anyone *really* think we *do* have to close out these edge cases at the risk of complexity, incompatibility, or other down-sides? ... It can be worse, as in this case where trying to fix the corner case makes things worse for everyone else. I will agree with Ale somewhat. While we should say that PSDs MUST NOT publish a ruf= tag, it would be prudent also to say that reporters MUST ignore a PSD's ruf= tag in case one is there anyway. Belt and suspenders. 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] I-D Action: draft-ietf-dmarc-dmarcbis-17.txt
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 somewhere. Todd, what version of xml2rfc are you using? Are you submitting the rendered versions or just the XML? 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] I-D Action: draft-ietf-dmarc-dmarcbis-17.txt
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, 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] Issue: Domain Owner policy in Section 5
+1, but the concern of not informing suspicious parties about local policies should then be risen in aggregate-reporting, Security Considerations (currently blank), shouldn't it? This is already pretty close to telling spammers how your filters work, so I would not push it. 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
[dmarc-ietf] Today's pull request
Scott's changes about when and how to apply policy Neil's typos cleaned up references to the other I-D's Please review the changes before accepting it. 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] dmarcbis-16 - some minor corrections
If you're feeling really enterprising you can do a github pull request, but sending the suggested changes to this list is fine. On Sat, 27 Aug 2022, Neil Anuskiewicz wrote: Cool! I'll proofread the whole document within two weeks unless there's a tighter timeline. I've heard talk on the list about rounding the bend on the last lap to the finish. In addition to proofreading, I'd rewrite for clarity here and there. Then, of course, you could reject any of it. How exactly would I submit my proposed changes? Thanks. Neil On Sat, Aug 27, 2022 at 7:14 PM John Levine wrote: Thanks, we can always use more proofreading. I'll put those in the next pull request. It appears that Neil Anuskiewicz said: -=-=-=-=-=- I'm not sure if minor things like misspellings, grammar, and other minutia are useful. I figured I'd try to contribute in a small way. If these kinds of suggestions are useful, let me know, and I can do more in the future and maybe dive into slightly more. 1. Introduction says: Abusive email often includes unauthorized and deceptive use of a domain name in the "From" *heaader* field defined in [RFC5322] and *refered* to as RFC5322.From. It should say: Abusive email often includes unauthorized and deceptive use of a domain name in the "From" *header* field defined in [RFC5322] and *referred* to as RFC5322.From. 6. DMARC Feedback When Domain Owners can see what effect their policies and practices are having, they are *better* willing and able to use quarantine and reject policies. It should say: When Domain Owners can see what effect their policies and practices are having, they are *more* willing and able to use quarantine and reject policies. 7. Changes from RFC 7489 says: This section will summarize *thos* changes. It should say: This section will summarize *those* changes. Thanks. Neil -=-=-=-=-=- [Alternative: text/html] -=-=-=-=-=- Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Review comments and issues
I made a git pull request which is intended to include the changes that Barry and Scott recently proposed. I also did a little editorial cleanup on the way clearing up some grammar and tagging the **MUST** and **SHOULD** R's, John PS: if you see some odd looking git commits, I accidentally checked the changes into the main branch, reverted them, them put them in a separate branch for the pull request ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mailing List message authentication
On Mon, 22 Aug 2022, Wei Chuang wrote: I agree with the OP's premise that there needs to be a better authentication method that works with mailing lists. ... Google seems pretty enthusiastic about ARC. Since large mail systems already know where the mailing lists are, I asked why not just skip DMARC checking on list mail. The answer was that lists leak a lot of spam since many do very weak filtering, checking only that the From: address is a subscriber. The point of ARC is to package up the authentication history of a message so the final recipient can retroactively do the filtering that the previous stages didn't. If you look back at the ARC chain and see that a message was aligned when it arrived at a list, which is easy to do, that greatly reduces the chances that the message is spam. I wrote up a proposal for conditional signatures, which lets a sender put a weak DKIM signature on a message that is only valid if it's also signed by a specificed second signer, which would be the list. The original signature just covers a few headers that the list is unlikely to change, but it lets the message continue to be DMARC aligned after a list modifies it. The ARC-ists didn't like it because it requires the original sender to know who's going to re-sign a message, while ARC only looks backward. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I don't think ARC is wonderful but I would be surprised if we could come up with anything better, and doubly surprised if large mail operators like Microsoft and Google who are already doing ARC trials would be interested. 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] now with marldownI-D Action: draft-ietf-dmarc-failure-reporting-04.txt
On Fri, 19 Aug 2022, Alessandro Vesely wrote: Todd and I have found it much easier to edit the markdown version of dmarcbis than hand twiddle the XML codes, and I have twiddled more than my share of XML. I made a pull request with the -04 version converted to markdown and a makefile to create the XML, TXT, and HTML. It took about an hour. The text is largely unchagned other than removing a little extraneous stuff that the WG never discussed. 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] I-D Action: draft-ietf-dmarc-failure-reporting-04.txt
Done on Github copy. I was surprised to see that the markdown version of the draft has disappeared from the github repo. Todd and I have found it much easier to edit the markdown version of dmarcbis than hand twiddle the XML codes, and I have twiddled more than my share of XML. 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] Would this list add an Author: header field? Nope.
This proposal is completely out of scope for this WG. On Thu, 18 Aug 2022, Alessandro Vesely wrote: Hi all, I rewrote this I-D to add the simple method to de-munge From: header fields upon reception, which was briefly discussed on list last week (Girl Scout troops): https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ The changes required to the mailing list settings should be easy. It would allow subscribers to programmatically undo From: munging using Sieve or similar MDA filter. Opinions and comments welcome, preferably off-list, to reduce noise. Best Ale 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] I-D Action: draft-ietf-dmarc-failure-reporting-04.txt
On Wed, 17 Aug 2022, Murray S. Kucherawy wrote: I can't remember if this was discussed previously. I was just responding to the proposed change. Understood, but I am concerned that we are spinning our wheels on changes proposed by individuals that have no support from anyone else. It would be nice if we could wrap up the work we've agreed to and ship our documents. 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] Collecting message metadata, was Time to work on failure reporting
Most receivers don’t provide failure reports but sometimes failure reports (when available) can be useful. I realize there are privacy and regulatory concerns. Would it be possible to reduce the scope of the failure report in general to address the privacy concerns so that they’re more widely implemented? The trade offs might be worth it to have a stripped down failure report if there was a way to do it so the failure report would be useful but not intrusive? The spec allows you to redact all you want, but history has shown that if you send anything at all, there is some risk of PII leaks. Mike noted that there are places that exchange failure reports by private agreement, presumably including protections for PII. I think that's the best one can realistically expect. 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] Time to work on failure reporting
I re-read the I-D and applied some more substantive changes. I don't find the changes improve clarity, but whatever. How about if you fix the markdown so it has the current contents of the draft, and you add a Makefile that can turn the markdown into XML and the XML into text and HTML one can look at. You can use the markdown and makefile in the dmarcbis repo as models. Then push it to github and post an updated draft. Hm... I'd start by posting the updated draft. It'd probably take me some days to learn how to obtain the same XML file starting from a markdown one rather than editing it directly. As the existing draft expires on the 21st, I'd revert the order of operations. If it takes more than an afternoon to fix the markdown to produce an equivalent draft, something is wrong. Perhaps someone else could do the editing? 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] Time to work on failure reporting
It does, it looks like someone did a quick cut and paste to make the markdown. But it's not that long, you're the editor, how about fixing the md so it's useful for editing? It must have been me. I recalled; I searched again for something to generate the md and again found only https://codebeautify.org/html-to-markdown. That way the (bottom) part of the md looks similar to the txt, but it's not usable for editing. I'll fix it next time... How about if you fix the markdown so it has the current contents of the draft, and you add a Makefile that can turn the markdown into XML and the XML into text and HTML one can look at. You can use the markdown and makefile in the dmarcbis repo as models. Then push it to github and post an updated draft. 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] Time to work on failure reporting
I'd rather it be more general, to show where all of the plausible parts go. Message/rfc822 is not more general, is just different. If I implemented failure reporting, I'd choose text/rfc822-headers (and heavy redaction) to reduce PII leakage as much as possible. The point of the example is to show people what the message format is, so I would include all the stuff that would plausibly appear in a failure report. I've anonymized it already, the question is if it's useful to blatantly redact stuff (redac...@yyy.zzz or RFC 6590) so as to encourage readers to implement redaction. The point of the example is to show people what the message format is, so I would not confuse people by trying to show clever redaction. Again, we do not know how other people run their mail system so while I agree that we should remind them that there is likely to be PII in reports, we don't know what they consider to be PII nor how severely they might want to redact them. By the way, it looks like you edited this into the XML rather than the markdown source. It would be nice to have the markdown available for future edits. I agree. However, the md file in the repository is strange as it contains stuff which should be generated. It does, it looks like someone did a quick cut and paste to make the markdown. But it's not that long, you're the editor, how about fixing the md so it's useful for editing? 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] Girl Scout troops vs MLM problems (#70)
On Fri, 12 Aug 2022, Alessandro Vesely wrote: When Dave proposed the Author header, part of the idea was that DMARC could use it rather than From. IIRC that was the Sender: field. No, DMARC decided not to use Sender back when DMARC was new. Dave suggested using Author to work around the From hacking. I still think this is completely out of scope and not worth any more argument. 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] Time to work on failure reporting
The Source-Port field is non-standard so I'd take it out. Defined by RFC 6692. So it is. ARF is such a mess. I'd change text/rfc822-headers to message/rfc822 and add ther a message body or something like [ Message body was here ] Why? I chose a body-less example as it looks more privacy-friendly. I'd rather it be more general, to show where all of the plausible parts go. I need to figure out whether the example is XML or but we can worry about that later. I thought it is the source of the email message. Its artistic content lacks somewhat... :-) For another point, should I redact the addresses? How? Possibilities: Just change them to something like x...@yyy.zzz. It's an example. They don't matter. By the way, it looks like you edited this into the XML rather than the markdown source. It would be nice to have the markdown available for future edits. 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] Time to work on failure reporting
On Thu, 11 Aug 2022, Alessandro Vesely wrote: I added an example, see https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L528 I omit diffs, as the only difference is Appendix A.3 (and I removed an antique Acknowledgments section). I just picked a report I received and anonymized it. How is it? The Source-Port field is non-standard so I'd take it out. I'd also remove at least the ARC and References headers from the message inside example since they make it a lot longer and don't help explain the format. I'd change text/rfc822-headers to message/rfc822 and add ther a message body or something like [ Message body was here ] The goal here is to make it clear that this has to be multipart/report and what goes into the message/feedback-report. I hope anyone reading this already knows what a 5322 message looks like and how to leave out the body. I need to figure out whether the example is XML or but we can worry about that later. 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] Girl Scout troops vs MLM problems (#70)
On Thu, 11 Aug 2022, Murray S. Kucherawy wrote: It only works if all or most lists add Author (none do today, and it would take a long time to get this rolled out if they started), and no other software co-opts and mutates it for whatever reason. Those are big enough conditions that I'm a bit worried about writing a standards-track document that depends on it. When Dave proposed the Author header, part of the idea was that DMARC could use it rather than From. Even if we did that, which would be a bad idea for other reasons, it would take forever for people to change their software. I agree that telling people to change their mailing lists to avoid damage that we caused is outside our scope. And again even if we did that, I can't imagine it surviving IETF last call. 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] Collecting message metadata, was Time to work on failure reporting
On Tue, 9 Aug 2022, Murray S. Kucherawy wrote: I agree with John, I think, that the amount of time we should spend improving failure reporting should be proportional to how much it's used, or how much the community is asking us to do so. ... My small mail system gets failure reports every day, sometimes just two or three, sometimes several dozen, generally depending on how much mail I've sent to large lists like NANOG or ietf@ietf. Mike tells us that there's reports we don't see, sent by private agreement. I think that's enough that we should leave it in. I also see a fair number of reports in wrong format, a consistent wrong format starting with "A message claiming to be from you has failed the published DMARC policy for your domain." from at least two reporters which tells me that there is a DMARC implementation that got the format wrong. Hence I think we should try to improve the description of the report format, with examples, to make it easier to explain to people how to get the format right. I do not think we should change the spec. 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] Girl Scout troops vs MLM problems (#70)
On Wed, 10 Aug 2022, Barry Leiba wrote: Yeh, I have to take serious issue with this: It's not a "tantrum" to say that it's not reasonable to require all mailing list software and every mailing list in the world to change what's worked for decades in order to work around a problem caused by use of a new standard in a way that new standard wasn't designed to be used. Moreover, even if we totally hypothetically did persuade lists to do from de-munging, IT WOULD NOT SOLVE THE PROBLEM. The reason mail providers invented ARC rather than something simpler is so they can look back and do spam filtering that the lists didn't, and deal with spam leaking through lists. I'm not guessing here, that's what they told me. So de-munging has all of the implementation hurdles of ARC, needing to know who's a credible forwarder, but not the key utility. 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] Time to work on failure reporting
Keeping it as-is for backwards compatibility is probably the best option. I'm not sure that it's necessary to keep it as is for backward compatibility. Both RFC 7489 and DMARCbis contain the phrase "unknown tags MUST be ignored" in the General Record Format text, so even if DMARCbis were to strike the 'ruf' tag and the concept of failure reporting entirely, it shouldn't break anything for compliant legacy or updated implementations. Considering how slowly people update their software, even if we deprecated ruf= there's going to be a lot of mail sent to those addresses. As Mike noted, there is a considerable amount of failure reporting by private agreement so someone thinks it's useful. I would prefer to clarify the spec to encourage people who send reports to send them in the right format and otherwise leave it alone. If the current authors of the failure draft don't want to do that, I think I could since the main draft seems pretty close to done. 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] Girl Scout troops vs MLM problems (#70)
Not quite. Lists are already screwed up, AFAICS. Right. Lists were fine until DMARC screwed them up. Because there are more ways for a forwarder to change a message than you or I can describe. That critic applies to my draft, not to unmunging in general. The only change we care about here is the From: field. As I said: It's similar, but the difference is that ARC actually deals with the problem and this doesn't. ARC answers the question the recipients care about, "was this message aligned before it was forwarded?" Your approach doesn't, and can't if the original message was aligned using SPF. ARC's added value is only meaningful for receivers whose reputation system is so sophisticated that that info matters. That is, for global mailbox providers. I don't think it is a good idea to assert that you know how other people's mail systems work. We have ARC, and we know that From munging does not address the spam leakage problem which affects everyone who receives mailing list mail, while ARC does Unless someone else says they think we should engage in this mission creep, this is all I plan to say on this topic. 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] Girl Scout troops vs MLM problems (#70)
Actually, small receivers can simply trust selected, DMARC-aligned mailing lists and restore the original From: in the cases where MLM saved it (w/o ARC). This kind of hack could be set up really quick. > Please please can we stop doing this. Trying to unmunge rewritten From: headers is totally out of scope for this group, and even if it weren't it does not scale Symptomatic treatment is out of scope? Telling people to screw up their lists to avoid damage we caused is blaming the victim. To make an overwrought analogy, it's like the politicians in the US telling schools to add reinforced steel doors to keep out crazy people with guns. Why doesn't it scale? Because there are more ways for a forwarder to change a message than you or I can describe. Isn't that exactly the same problem that ARC poses? It's similar, but the difference is that ARC actually deals with the problem and this doesn't. ARC answers the question the recipients care about, "was this message aligned before it was forwarded?" Your approach doesn't, and can't if the original message was aligned using SPF. 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] Collecting message metadata, was Time to work on failure reporting
On Mon, 8 Aug 2022, Alessandro Vesely wrote: It also misses the fact that "already reported characteristics" is undefined. Right, that's to be defined. Clearly, the criteria differ between SPF and DKIM. We could also define fuzzy criteria. Mike and I just provided separate reasons why that is both a bad idea and not even possible. We have plenty of work already without inventing more. Let's agree not to do this and get back to work on what we've already agreed to do. Does "not to do this" refer to failure reporting as a whole? As is, it is a noise generator that the majority of users decided not to implement. We can see what the group thinks. But it surely would be foolish to spend our limited time trying to define a complex and unworkable redesign of a feature hardly anyone uses. 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] Girl Scout troops vs MLM problems (#70)
Moving this back to the main list: I said: Even if I agreed that it would be a good idea for every mailing list in the world to rewrite From lines so it's harder to tell who the messages are from and you can't reply reliably, there's no way that would survive last call. Remember that a few large mail providers abused DMARC to outsource the cost of leaking their user address books to crooks, and screwed up every mailing list in the world as a side effect. Blaming the victim is not the answer. Unfortunately, there is no good answer. Scott said: Agreed. On my phone I use an MUA which will display either the friendly name or the address, not both. I routinely get messages that I can't tell who they are from without reading the raw header if someone forgets to put their name at the end of the mail because I no longer get their address in the normal display thanks to rewriting. I think, as was discussed at the meeting, what types of domains DMARC is suitable for needs to have some kind of MUST or MUST NOT depending on how it's worded then with some non-normative words in an appendix which discuss options for damage containment when the MUST is ignored. On Sun, 7 Aug 2022, Alessandro Vesely wrote: Saying that domains with human users MUST NOT use DMARC is not a solution either. The wording has to express the explanation Pete gave at the meeting, which sounds very close to RFC 6919. Letting the victim die is not the solution either. Among the solutions that MLMs adopt, some allow to undo From: rewriting at the MDA level. ARC doesn't preclude From munging. ARC verifiers can restore the original From: at rMDA level too. Actually, small receivers can simply trust selected, DMARC-aligned mailing lists and restore the original From: in the cases where MLM saved it (w/o ARC). This kind of hack could be set up really quick. Please please can we stop doing this. Trying to unmunge rewritten From: headers is totally out of scope for this group, and even if it weren't it does not scale and has terrible security problems. (If good guys can put in real rewrites, bad guys can put in fake rewrites, and if a recipient can tell whose rewrites are good enough to unmunge, it can equally well ignore whatever problem the rewrite was supposed to fix.) I will try and write something similar to what Scott suggests, describing the problems without making us look foolish, and mentioning that there are workarounds if you insist on sending p=reject messages on paths that DMARC cannot describe. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting
By remembering failure reports issued in the past, new failures having already reported characteristics (e.g. same forwarder) can be silently ignored. That would greatly reduce noise. This is a horrible idea. It presupposes that failures from the same origin (e.g. same forwarder) at different points in time are the result of the same underlying cause. This may be true in some cases but not true in other cases. Operational environments are not static. Even for short time frames this is a bad approach. It also misses the fact that "already reported characteristics" is undefined. For example, the guy complaining about reports from NANOG messages considers all reports about a message forwarded through NANOG are the same, even though they could have come from a dozen different recipients that don't know about each other. We have plenty of work already without inventing more. Let's agree not to do this and get back to work on what we've already agreed to do. 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] Collecting message metadata, was Time to work on failure reporting
I don't understand what you mean by "no data collection." It is true that you can send a failure report immediately without saving anything for later. “Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905. Perhaps I'm unusually dense today but I still don't understand what any of this has to do with DMARC failure reports. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] It's verified, but pretend that it is not...
On Fri, 5 Aug 2022, Alessandro Vesely wrote: On Fri 05/Aug/2022 04:44:21 +0200 John Levine wrote: DMARC uses available information to produce a result of "Authenticated" or "Not Authenticated". Sometimes, the message can be reliably categorized as "Authenticated" or "Not Authenticated" without reference to the specifics of a domain owner policy. ... But DMARC has never said whether messages are "Authenticated". It says >> whether they are aligned, based on the authentication results from DKIM and SPF. That's not the same thing, and the distinction is deliberate. It's quite possible for a message to be authenticated by DKIM or SPF, but not aligned. The difference w.r.t SPF is that DMARC records have default values. The only mandatory element of a record is dmarc-version. This makes the "implicit" DMARC record quite obvious. While DMARC effectively has a default of p=none and no reports, I don't see how that is relevant. DMARC is about alignment, not authentication. However, it might be worth to note that, among non-DMARC software, there are verifiers which issue a warning when the authenticated identifier is not aligned. Call it dmarcese? Once again, I see no benefit in describing things that are not DMARC. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] no zone cuts, no Shortcuts
I think that Ale's expression that he had difficulty understanding the description of the tree walk as written is a strong sign we still need to improve the language. Of the people involved in this specific discussion, as far as I know, he's the only one who's first language isn't English. That's true for most of the people in the world, so I don't think we can call it quite done. I took a look at the description ot the tree walk in section 4.6 and I didn't see anything to change. I suppose we could add a sentence at the top of the section reiterating some of the discussion in 4.4 that you do tree walks on two domains to see if they are in relaxed alignment, or that you do a tree walk on the RFC5322.From domain to find its policy domain, but those seem marginal. What Ale seemed to be asking for was something saying these aren't zone cuts and it's not the PSL. I don't think that would be a good idea. The list of things we are not doing is unlimited, and mentioning some of them just leads to questions about if you're not doing them, why did you mention them? I'd really like to find someone who's implemented DMARC and isn't on this list, and see what they think. Do we know the people who maintain rspamd? 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] Time to work on failure reporting
That's the reason people set p=quarantine; pct=0; t=y. Indeed, if there is a failure, one would want to fix something. I suggested that, we'll see. This morning on Twitter @mnot noted with alarm that failure reports about list messages give you a pretty good idea about who some of the list subscribers are, which is true, and that it's something a list operator can turn on or off, which is not. List operators can (should? must?) rewrite From:. Blaming the victim? Let's not do that. The best keyword to prevent use of DMARC by domains attending mailing lists would be "MUST (BUT WE KNOW YOU WON'T)" from RFC6919 ;-) Right. I'll try and write something along those lines. In part, the format is difficult because it is not described in the document, but in RFC6591, which in turn refers to RFC5965. Perhaps adding a complete example might help. Not a bad idea. I see a bunch of bad failure reports in the same format so presumably there is one broken library they're using. 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] no zone cuts, no Shortcuts
I still don't see any value in adding text like this. The description of the tree walk is clear enough. On Wed, 3 Aug 2022, Alessandro Vesely wrote: On Tue 02/Aug/2022 14:33:21 +0200 Barry Leiba wrote: I think it is useful to include a brief explanation of why we moved away from the PSL, because that was in the previous version. But we should be very tightly focused when we give any such background, to avoid creating distractions. Here's one more attempt at proposing the text of a complete, free-standing section: There is no general rule to determine domain prefixes. The PSL is the result of the ongoing, ponderous work of a group of volunteers who examine each case. However, DMARC users define DMARC records at their Organizational Domain, so it is possible to discover them based on that. Here we define an algorithm that determines the Organizational Domain for DMARC purposes. For established prefixes, the result is the same as using the PSL. Given a DNS Tree Walk (#dns-tree-walk) which retrieved at least one DMARC record, determine the Organizational Domain by applying the following rules, from the longest domain toward the shortest one: 1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n), this is the Organizational Domain and the selection process is complete. 2. If a valid DMARC record, other than the one for the domain where the tree walk started, contains the psd= tag set to 'y' (psd=y), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete. 3. Otherwise select the record for the domain with the fewest number of labels. This is the Organizational Domain and the selection process is complete. Best Ale 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] no zone cuts, no Shortcuts
How about this: In general, it is not possible to determine the cut points in DNS where a change of management occurs. However, DMARC users define DMARC records at their Organizational Domain, so it is possible to discover them based on that. I'm with Barry. I see no reason to mention zone cuts or anything like zone cuts at all. They are not relevant to DMARC. It would just confuse people. 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] no zone cuts, no Shortcuts
I didn't use zone cut /instead of/ organizational domain. The paragraph I wrote was meant to introduce readers to the network topology onto which organizational domains are defined, so as to justify the algorithm. But zone cuts are irrelevant to the tree walk and have nothing to do with the way we designed the algorithm. The tree walk does exactly the same thing if there are no zone cuts, or there is one at each label. I see no benefit to anyone from adding language about them. 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] Shortcuts: parent-child allows shorter tree walks
On Sun, 31 Jul 2022, Murray S. Kucherawy wrote: You could make the argument that you "usually" find DMARC records at zone cuts, but that's relying on convention or happenstance rather than a standards-quality framework. Right, we went through all of this in the failed DBOUND discussion. If it were true, which it is not, that zone cuts always indicate different management, and that every change of mangagement has a zone cut, we would not be having this discussion because it is trivial to find the zone cuts. But since it is not, we have to do it other ways like the PSL for web cookies and the tree walk for DMARC. I have to say I am somewhat concerned that people are trying to design the way DMARC uses the DNS but do not appear to understand some fairly basic things about the way the DNS works. 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] no zone cuts, no Shortcuts
Sorry, but this is just wrong. DMARC and the tree walk have nothing, and I emphasize nothing, to do with zone cuts. I thought a zone cut marked the boundary where an organization delegates control to another one. No, it's the place where one set of name servers delegates part of their DNS tree to another set. Sometimes the name servers are in different organizations, sometimes they are not. I have also seen situations where a company hosts DNS for several of its customers all in the same zone, with no zone cut between them. In many cases, that would be the org domain, no? Sometimes, but you cannot tell, because DMARC and the tree walk have nothing to do with zone cuts. 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
[dmarc-ietf] Updated PSD example
I made a pull request that changes the PSD example to show how names under a PSD are and aren't aligned, It uses giant.bank.example and mega.bank.example, with bank.example having psd=y. https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/95 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
[dmarc-ietf] Agenda for meeting on Thursday?
Is there an agenda for our session? I don't see one its slot on the 114 website. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] premature optimizations, Shortcuts: parent-child allows shorter tree walks
I hope you agree that .com is a domain. The spec says that in order to discover the Organizational Domain for a domain, I can perform the DNS Tree Walk as needed for any of the domains in question. That way, the domain in question, .com, is the Organizational Domain of itself. That is wrong because .com is a PSD. Oh, perhaps "in question" refers to the three cases mentioned in the Section's intro? It doesn't say so, it says a tree walk "might start" there, without excluding other possibilities. "In question" can legitimately be understood to refer to any domain at hand. Furthermore, the parenthesized reinforcement "if present and authenticated" in a domain in the first shortcut casts a shadow on the requirement that all identifiers except From: must be authenticated —if that requirement were clear, there'd be no need to reinforce it. This corroborates the wrong interpretation. First, if .com had a DMARC record and .com sent mail, it could be both a PSD for lower level domains and it's own organizational domain for itself, so your conclusion is incorrect. We have discussed this multiple times. I think we most recently used .gov.uk as a more realistic example. I think we have been through this more than once and we should not do it again. Second, your "Furthermore..." claim reads to me as because the text says the identifier must be present and authenticated, it will make readers likely to think that the opposite is true. I think you should take a step back and reconsider your suggestion as it doesn't seem at all logical to me. Scott is correct and I wish people would stop trying to reargue decisions we already made. 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] new pull request, PSDs aren't important, was mustard
I made another pass over the draft to clean up some of the descriptions. The discussion of PSDs is shorter and clearer, and I made a few small changes in the tree walk to make it clearer. I think we need to make clear that the RFC5322.From domain, the RFC5321.MailFrom domain, and the DKIM d= domain all have their own organizational domain. It already said that. Are you sure you aren't looking at an old version? https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/52 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] Tree Walk Examples pull request
I made a pull request from Scott's examples, lightly edited. Also added a few lines to the makefile to make a diff between the current and previous versions. 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] what to document about the tree walk
On Fri, 15 Jul 2022, Alessandro Vesely wrote: +1 from me too. Note, though, that the (current) DNS is accidentally correct most of the time, as far as our Tree Walk is concerned. No, it's not an accident. We designed the tree walk based on our knowledge of the way people publish DMARC records. 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] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Fri, 15 Jul 2022, Alessandro Vesely wrote: Organizational Domains are defined as PSD+1, and can have DMARC records I think this would be a good time to review the way relaxed alignment works in sections 4.5 through 4.8 of the draft. Perhaps 0.01% of the time, a tree walk will find a record with a psd tag. The other 99.99% of the time it's the shortest name with a DMARC record, and PSDs are completely irrelevant. (although com currently hasn't). As we have repeatedly discussed, .com and other large gTLDs do not have DMARC records and never will, and that is not a problem. I have to say I am dismayed that we seem to be repeating argunebts about misconceptions that we had already resolved in recent weeks. That doesn't seem like a good use of anyone's time. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Thu, 14 Jul 2022, Scott Kitterman wrote: In my view, standardizing two ways to do policy discovery and alignment would be a substantial danger to interoperability and we'd be stuck with it approximately forever. I agree, it's a self-evidently terrible idea. "Temporary" transition periods inevitably turn out to be permanent, or so close to permanent that we'll all be dead before it's over. What I expect to happen is that we publish 7489bis with the tree walk as the method to find org domains*. There are a handful of widely used libraries that implmenent DMARC, most of which have developers who read this list or are otherwise people we know, so we can encourage them to update their software. Large providers like Google and Microsoft have their own implementations but we know them too. So over perhaps a year the places that upgrade their software will get new libraries and start to use the tree walk. There will always be a long tail of sites that never update their software, but that's life. Fortunately, for the majority of normal mail the old and new methods get the same result, so it's unlikely the long tail will run into problems any worse than they already have with the obsolete software they use, e.g. TLS 1.1 making STARTTLS fail. R's, John * and occasionally PSDs. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed, 13 Jul 2022, John Levine wrote: It appears that Murray S. Kucherawy said: Speaking as an AD now, you should expect me to complain about the "SHOULD" in Section 4.7. I went through and looked at all of the "must" and "should", in both upper and lower case. A lot of the lower case "must" was saying that one thing is the same as another using tortured syntax so I rewrote most of them to be shorter and clearer. The SHOULD in 4.7 is now a MUST, and I trimmed some excess words. Also fixed a similar SHOULD in 5.3. You have to ignore crud in the DMARC record, which I believe is what most if not all DMARC libraries do. In 4.4.1 it said that d=com cannot be an organizational domain because it's a PSD, which I fixed to say because it has no DMARC record. You can't tell it's a PSD because it has no DMARC record and never will but as previously discussed, that doesn't matter. In 5.8 took out a MUST turn an IDN in an A-R header into an A-label, since you don't have to do that. You can see the text diffs here: https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html There's a github pull request with the changes. 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] what to document about the tree walk
A.6 seems to be dealing with a different subject. I can still sketch some text to be added there, though. I attach the diff. I realize this is getting repetitive but: -- PSDs are very, very rare, and users will generally never see them -- long discussions of PSDs will just confuse people -- I don't even think these examples get the tree walk right. Hence, this change is not an improvement. I don't plan to argue further unless we see more support for this very bad idea. 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] what to document about the tree walk
On Mon, 11 Jul 2022, Alessandro Vesely wrote: We are proposing an alternative to the PSL without having any experience of it. I think a Proposed Standard should give full explanations of design choices, so that possible, future amendments can be thoughtful and considered. Could you explain, preferably in detail, why Appendix A.6 in the draft doesn't do that? 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
