Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
In article you write: >In practice, I don't know how common it is for clients to consume this >header. They have to if they're adding ARC seals on the way out. Other than that I don't have much idea either. On my system my mailing list software looks at it them to decide how much DMARC hackery to do but again I don't know how common that is. Since the point of the text is that you can only trust your own A-R headers, presumably the code that adds them and that consumes them are at least partly under the same management so I'd think they could agree on their quoting practices. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
In article you write: >> this specification MUST delete any discovered instance of this header >> field that claims, by virtue of its authentication service >> identifier, to have been added within its trust boundary but that did >> not come directly from another trusted MTA. > >In my opinion, a header that does not conform to the specified >authres-header-field in the RFC, is not an Authentication-Results >header, has no authentication service identifier, and as such cannot >claim anything in the context of the RFC. ... Honestly, it doesn't matter. The only A-R headers you can trust are the ones that your own system added, and the point of that text is that you should delete ones that look like yours but that you didn't add. We leave other people's A-R headers in case they might be useful to do forensics, and we have a slightly different version of them in ARC chains which again are only trustworthy if you know who added the ARC seals. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [Last-Call] Opsdir last call review of draft-ietf-dmarc-psd-08
In article <1904862.B7rBbPpL6e@sk-desktop> you write: >> Scott, please prepare a new version of the I-D based upon your comments, >> but don't post it until IETF Last Call finishes and all other feedback, if >> any, has been folded in. >> >> Seth, as co-Chair > >Done. The updated version (XML, text, and rfcdiff) can be found in the WG >GitHub repository [1]. Internet drafts are intended to be cheap and plentiful. I'd encourage you to post what you have. If it needs further tweaks and another posted version or two, that's not a big deal. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article <6b4c7533-ebee-796b-e00e-a2bb40750...@arcsin.de> you write: >To decide for an authserv-id whether to pull sub-domain from 5321 or >6531, one needs to know if the message is internationalized. But to >obtain that information, one must have parsed all message header fields, >per 6531 sec 3.6, including A-R, that is still waiting to be parsed. In systems that keep ASCII and EAI mail separate, that info will be in the metadata, whether it arrived in an SMTP session with the SMTPUTF8 option. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article <4013d967-852c-e299-0973-03ba21db5...@arcsin.de> you write: >Ok, that is definitely an external factor, isn't it? The information, if >the system which processed the email, handles EAI, is not contained >within the A-R header. Is the information even available in the DATA >portion of an SMTP transaction? Can one look inside an .eml file and >decide if that email has been processed by an EAI capable system? Maybe. The EAI flag is sent on the MAIL TO command. See RFC 6531, sec 3.4. If the recipient system adds the usual Received: header, it should include a "WITH UTF8SMTP" or "WITH UTF8SMTPS" clause. I have no idea what's in a .eml file, since the only spec I've seen for it is whatever some version of Outlook does. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article <5c650beb-f0b7-5cae-3070-b7005dec9...@arcsin.de> you write: >> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, >> it's invalid under 5321 and valid under 6531. > >I thought we established that as soon as the authserv-id has non-ASCII >UTF-8 characters, the mail is automatically - by definition - a 6531 mail: Sorry if it seemed like I said that. It's either a potentially valid EAI message or a definitely invalid ASCII message. If your system doesn't handle EAI mail, it's invalid. If there are bytes with the high bit set but they're not a UTF-8 sequence, or they're not a UTF-8 character allowed in an authserv-id it's invalid even if you handle EAI. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article you write:
>> authserv-id = sub-domain *("." sub-domain)
>>; Where sub-domain is imported from 5321 for ASCII mail
>>; and 6531 for EAI mail.
>
>, given identical input, disagree on the validity of the A-R header of
>that input. Can you please show an example?
It's the one you found. If the authserv-id has a non-ASCII UTF-8 character,
it's invalid under 5321 and valid under 6531.
>> EAI and ASCII mail are separate mail streams. The component that is
>> parsing the A-R header had better know ahead of time whether your
>> system is treating them separately.
>
>Can you elaborate on this paragraph? Know what ahead of time? It sounds
>like you agree, that the validity of an A-R header does depend on
>external factors, not solely on the A-R content.
Right. ASCII mail and EAI mail are handled as separate streams, even if
they share a mail server. See this old blog post of mine:
https://jl.ly/Email/i18n3.html
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article you write:
>"If the authserv-id is UTF-8, then it might be UTF-8"
Yes.
>This seems equivalent to
>
>> authserv-id = sub-domain *("." sub-domain)
>>; Where sub-domain is imported from 6531 for
>>; any mail
No, it's 6531 for EAI messages, and 5321 for ASCII messages.
EAI and ASCII mail are separate mail streams. The component that is
parsing the A-R header had better know ahead of time whether your
system is treating them separately.
Since 6531 is a strict superset of 5321, if your system handles EAI
messages (many still don't) then you can treat them all as EAI, give
or take issues with forwarding messages with A-R headers to non-ASCII
recipients.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article you write: >> The intention in 8601 is pretty clear, even though the ABNF doesn't agree: > >Yes, the RFC says the authserv-id can contain UTF-8, but its author >stated that he intended it to be "either a plain old ASCII domain name >or an A-label". One does not need UTF-8 for that. If authserv-id were not > >> authserv-id = value > >but > >> authserv-id = token ; token from RFC2045 > >wouldn't the author's intent have been covered as well, without any >reference to RFC6531/6532? You'll have to ask Murray what he meant, although as we've seen section 2.5 specifically says that an EAI authserv-id "may be expressed in UTF-8." In an EAI message, an A-R header has to allow UTF-8 characters in mailboxes, so it might as well allow them in other places including domain names and the authserv-id. R's, John PS: for anyone who might suggest one could "punycode" a mailbox, don't even think about it. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article , Damian Lukowski wrote: >> Does this mean that a parser would need to know if the message has been >> sent with SMTPUTF8 in order to pass or refute U-labels? The definition of an EAI message is separate from SMTPUTF8. As a close approximation, any message which has an x80 bit set in a character in the header is an EAI message. -- 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] Definition of "value" in RFC8601
In article you write:
>>I don't see any reason to exclude them. We could do this:
>>
>> authserv-id = sub-domain *("." sub-domain)
>>
>>Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI
>>mail.
>
>That does allow IP address literals. Do we want that?
No, take a look at RFC 5321 and search for "address-literal". You'll see
they're always an alternative to a domain. Sub-domain is trivial:
sub-domain = Let-dig [Ldh-str]
Ldh-str= *( ALPHA / DIGIT / "-" ) Let-dig
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article you write: >I've definitely seen non domain-name based authserv-ids, but they are rare >and tend to be from opendmarc. We can certainly fix that in opendmarc. My proposal says they're syntactically domain names, not that they actually have to exist in the DNS. What do those ID's look like? The only things I can think of likely to fail would be exotica like foo..bar that can't be parsed into DNS labels. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article <230d0260-c254-99d3-0995-1ab05c326...@arcsin.de> you write: >Shall authserv-id contain UTF8-non-ascii or not? The intention in 8601 is pretty clear, even though the ABNF doesn't agree: 2.5. Authentication Service Identifier Field Every Authentication-Results header field has an authentication service identifier field (authserv-id above). Specifically, this is any string intended to identify the authentication service within the ADMD that conducted authentication checks on the message. This identifier is intended to be machine-readable and not necessarily meaningful to users. Note that in an EAI-formatted message, this identifier may be expressed in UTF-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] Definition of "value" in RFC8601
In article <3295240.vh5t8hYAJM@sk-desktop> you write:
>> If you want it to be a domain, the ABNF should say:
>>
>> authserv-id = domain-name
>> This is not strictly backward compatible with the current text, but I
>> don't think I've ever seen an authserv-id which wasn't syntactically a
>> domain name.
>
>I've seen bare host names used. I guess that's syntactically a domain name
>also, but might not be what you expect if you assume it's really a domain
>name. It probably doesn't matter.
I don't see any reason to exclude them. We could do this:
autbserv-id = sub-domain *("." sub-domain)
Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI mail.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definition of "value" in RFC8601
In article you write: >-=-=-=-=-=- > >Hmm, we didn't include this in RFC 8616 either, I could imagine that it >should be punycoded also, though it really depends on whether in 6532 or >5322. This is another mistake in the ABNF in 8601. The point of 6532 is that with the exception of Message-IDs, any header fields that used to be limited to ASCII can now contain UTF-8 printable characters. If you're putting an A-R header on an EAI message, it has to allow UTF-8 since lots of the fields in an A-R header can contain mailboxes and other UTF-8 strings. I realize that the authserv-id is usually a domain name, in which case it would be reasonable to represent it as A-labels, but it doesn't have to be. The only, and I mean ONLY, strings that are "punycoded" are the characters in IDN labels that follow xn--. To pick a common point of confusion, you absolutely cannot "punycode" a mailbox name. R's, John >On Sat, Mar 28, 2020 at 3:39 AM Damian Lukowski wrote: > >> Hello, >> >> RFC8601 section 2.2 defines >> >> > authserv-id = value >> > ; see below for a description of this element >> > [...] >> > The "value" is as defined in Section 5.1 of [MIME], with >> > "quoted-string" updated as specified in [RFC6532]. >> [MIME] (RFC2045) section 5.1 >> >> > value := token / quoted-string >> > token := 1*> > or tspecials> >> >> The token is not said to be updated by [RFC6532] as is quoted-string, so >> by my interpretation non-ASCII cannot be used without quotes. >> >> If so, then current implementations of OpenDKIM and OpenDMARC are wrong >> or imcomplete, as they do not check for Non-ASCII AuthservID and produce >> headers like >> >> > Authentication-Results: öde; dkim=none; dkim-atps=neutral >> Is my understanding correct? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum
In article you write: > [SPF] on the other hand >has an A-R example that is domain-name only, so I assumed that >smtp.mailfrom in spf context was more loosely defined via RFC7001's >pvalue (that is, with the optional local-part@). I'm pretty sure the example is wrong, and was copied verbatim from wrong examples going back to RFC5451. RFC8601 sec 2.7.2 refers to RFC 7208 for "mailfrom". RFC 7208 sec 1.1.3 says that the MAIL FROM, which I whink we can assume is the same thing, is the RFC5321.MailFrom from RFC 5598. RFC 5598 says that's a mailbox, not a domain name. gain, if you look at the existing implementations, they put the address in spf smtp.mailfrom, not just the domain name. R's, John PS: I have always found it frustrating that I have to chase through a dozen documents to find the syntax of A-R. I understand the desire not to try to keep two copies of definitions in sync, but as we've seen, that doesn't always lead to the result you want. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum
In article you write: >>> Every implementation I know puts space between multiple propspec's >>> which the current syntax wouldn't allow >> my understanding was that RFCs decide whether an implementation is >> incorrect or in the case of a series, not up-to-date. If the authors >> decided to update the RFC instead, then I'd be happy of course. In general you're right, but it sometimes happens that the RFC has mistakes and what it says is not what the WG intended. In this case I'm quite sure that the intent is that spaces between propspecs are required and the ABNF in 8601 is wrong. Erratum 5435 misunderstood how ABNF works and somehow we all missed that. If you look through the archives of the WG you'll see that 8601 is intended to be a compatible update to 7601, and as you noted the ABNF change is definitely not compatible. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum
In article you write: >Hello DMARC working group, > >I am going through the changes between RFC7601 and RFC8601 and try to >understand the implication of the change introduced by erratum 5435. >The new resinfo definition uses 1*propspec, that is, by my understanding >of [1] and [2], potentially multiple consecutive propspecs without >obvious delimiters. ... It says: resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] [ CFWS 1*propspec ] I think both the erratum and RFC 8601 are wrong, and it should say: resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 1*( CFWS propspec ) Every implementation I know puts space between multiple propspec's which the current syntax wouldn't allow >The spf method defines smtp.helo and smtp.mailfrom. RFC8601, RFC7601 and >RFC7001 have only examples of the form smtp.mailfrom=domain-name. >However, RFC7208 shows a local-part@domain-name form in [3], so I must >assume a parser for an RFC8601 resinfo needs to recognize both forms. So >consider That's a mistake in the examples in Appendix B. The example at the bottom of page 21 is correct -- the value for smtp.mailfrom is a mailbox, not a domain name. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd
In article you write: >> Consider: From f...@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com >> >Yeah, I'm familiar with the nature of the attack. But based on what >amounts to the hallway track, it feels like the perspective of the DNS >community these days is that the currently deployed DNS infrastructure >could easily deal with such an attack, ... The DNS crowd is finally admitting to themselves that Sturgeon's Law applies to the DNS, too, and a little more crud will be lost in the large amoung ot noise. I gather than people are implementing RFC 8020 which makes this attack less effective. >The issue PSD is attempting to address is mail sent as a nonexistent >subdomain. For example, irs.gov doesn't have a subdomain called >auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send >email as m...@auditors.irs.gov without limitation. ... I have less sympathy for that argument. I do a hard reject of any mail with a nonexistent bounce address which I don't think is unusual. PSD as I understand it is to address the same issue the organizational domain does, but a level up, in a group of organizations that have some administrative connection. The issue is people who publish A and MX records without covering DMARC records. They're not supposed to do that but they do, and PSD is one way of figuring out who needs to fix what. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07
In article you write: > Since information about existing implementations gets removed as a doc >passes through the editor's hands, I'm not sure why it would matter to >update a section that will be removed. Only if we ask them to. I don't see anything in the draft asking them to take that section out. I'd prefer to leave them in, since hints about where to find working code are always helpful even if out of date. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Org domaines, not really Comment on draft-ietf-dmarc-psd
In article , Murray S. Kucherawy wrote: >>> >>> >>> I think what Dave proposed about PSL separation from DMARC is entirely >>> appropriate and pragmatic, and in fact probably easy enough: DMARC is >>> changed so that it says the organizational domain is determined using some >>> process [currently] external to DMARC, and then a second document explains >>> how that process is accomplished using the PSL (and/or PSD, depending on >>> when the experiment result comes in). The current DMARC spec essentially says the first part, that you have to find the org domain but waves its hands about how. I really would not want to make the PSL a requirement for any spec. The people who maintain it say in large letters on their web site not to use it for any new applications. There's no technical bar to doing something else. I have running code for a DNS lookup technique that does everything the PSL does without a tree walk at https://github.com/jrlevine/bound The problem is that we seem unable to agree on any PSL or not-PSL like thing. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
In article you write: >So we could decide on doing a combinatory of #3 and #1, with the right >mechanisms. Publishing a list of PSD superdomains in the DNS is pretty trivial using my dbound scheme, and should typically find out whether any name needs a PSD check with one DNS query. The total zone for the PSL is under 10K records, so doing a local mirror should be easy, too. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
In article <79b1cbe6-8a53-9157-63de-210fd2bad...@dcrocker.net> you write: >This goes to the essential challenge of a proposal like PSD. It >embodies a particular model, in the absence of clarity about the model >or broad-based discussion of its appropriateness. (Note, for example, >that my review offered some discussion of that sort but got no comment >on that discussion.) > >In effect, it creates a strategic solution -- that is, a long-lived and >embedded mechanism -- without a clear and broad understanding of the >organizational space it is working in. I've been talking to some of the PSL people, and they seem really stuck. They know they don't have a way to describe vanity single-registrant TLDs, and I don't even want to suggest that they might want to describe something like PSD, with a super-authority above a suffix boundary. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
In article you write: >https://datatracker.ietf.org/doc/draft-brotman-rdbd/ > >which defines a mechanism where two domains can state they are related, or >not related via DNS records. >What one wishes to use this information is left to them. > >It would be great to get y'all giving feedback If it's useful at all, which I don't think it is, it's definitely not useful for PSD since it's intended to describe cross-tree relationships, not the vertical ones that the PSL identifies and that PSD needs. This proposal also invents yet another signature scheme, presumably for the benefit of people who don't think DNSSEC will ever work, which is strange since the lead author works for Comcast who have what is probably the world's biggest set resolvers that validate and use DNSSEC and DANE. R's, John PS: It's not that I think there are no cross-tree relationships to describe, it's that we know from Andrew Sullivan's failed SOPA proposal that doing it one label at a time rather than subtree to subtree isn't viable. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL
In article you write: >Just to be clear: The policy for changes to that registry is "Expert >Review", but since the action that put it there was a document with IETF >consensus, I'm pretty hesitant about just approving this change based on a >formal request. I'd rather at least see some consensus discussion about >it, or even better, a revision/update to RFC8601. Hey, wait, Expert Review is supposed to be considerably looser than RFC Required. Since there's no danger of running out of token names, I'd encourage you to accept new ptypes if they have a clear spec and a plausible use case. In this instance, I think the description in the I-D is OK, but for the use case I would like some evidence that someone, somewhere is implementing it and doing something with the result. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Two new fields in aggregate reports
In article <682972a4-38e4-f5b2-3180-c5a03a3a0...@tana.it> you write: >Looking at aggregate reports, you cannot tell whether an authentication failure >is a sacrosanct signaling of your domain being abused rather than a legitimate >user going through external forwarders. Sure you can, you look at the IP address and see who it is. In my reports I see bursts of authentication failures from hosts that are obviously mailing list servers, and lots of failures in China which are random spambots. >In theory, reports can be something more than a debugging aid. It has the >potential to assemble a community where bad actors are identified and >dismissed. No, that's not what they're for and they don't have the necessary info. There are systems that compile data for IP reputation but that's not what DMARC is. The point of DMARC is to try to tell "is this message really from X", not "is this message spam." R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Two new fields in aggregate reports
In article you write: >What is the purposes of the aggregate and non-aggregate reports? What are >non-goals? I asked several times here, >nobody answered. Perhaps a discussion on the goals and non-goal would help. As far as I know, the point of DMARC reports is to help domain owners understand who is sending mail that purports to be from them. In a large organization it can be remarkably hard to track down every mail server in every department or every subcontractor that might be sending real mail with the domain in the From: header. The domain owners use the reports to do things like update SPF records to include all of the sending hosts, update server configs to add DKIM signatures, or to fix servers that are adding invalid signatures, and often to shut rogue servers down that shouldn't have been sending mail in the first place. I can't see how spam scores would be of any use for any of these tasks. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua reports?
In article <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> you write: >I've noticed that, even though RFC7489 appendix C states that the >'envelope_from' element has a minOccurs of '1', this element is missing >quite frequently. It's not missing, it's empty. That's not the same thing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
In article <97b7d4320e77f9be84703677eba79686ec769f75.ca...@aegee.org> you write: >Hello John, > >the "... reject at SMTP level" is at least for messages, directed to an >address, which does not support the >concept of >quarantining. > >Please propose what shall a site do, receiving a message, subject to >quarantining, for an address, that does >not support quarantining. It should do what RFC 7489 says: ... Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Are you really saying your mail system has no spam folders, no way to adjust spam filtering, and no way to mark messages as suspicious (e.g., add "PROBABLY SPAM" to the subject line)? If the problem is that it's an address that goes to some software robot rather than being seen by people, do whatever you want. That's an edge case for DMARC. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
In article you write: >Current wording for p=quarantine > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > >Amendment to the wording for p=quarantine: > >… or reject at SMTP level. ... No. We really, really, don't like changes that aren't backward compatible. You can do what you want but there is no chance I would ever make p=quarantine a signal to reject, and I think I am not atypical. R's, John PS: You can of course do whatever you want on your own system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
Catching up on my mail after a laptop disaster, ... In article <4600949.rz9u5RyGOV@l5580> you write: >I think comments should be free-form. If we want data that can be machine >parsed, we should specify it. > >I think the above works in ABNF terms. It's: > >Authentication-Results:" authserv-id; method=result ptype.property=value >ptype.property=value I agree. We all put the DKIM stuff in comments but that's silly. If it's worth recording, it's worth doing in a way that we all agree about and can parse. R's, John -- Regards, John Levine, jo...@iecc.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] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >Most MTAs will also follow CNAMEs. Should they be included (along with >other things like DNAME records) within the scope of existence? I'm a >little concerned that we are making a special definition of "non-existence" >which differs from the standard DNS concepts of NODATA and NXDOMAIN without >having a correspondingly special name. Good catch, you have to chase CNAME and DNAME before deciding whether you've found A//MX. >I'm not sure how well this maps to what we describe. I'm also concerned >that a wildcard null MX record at the org level would end up having all >subdomains "exist", but the policy that should be applied would be the more >restrictive "np" policy, not the (possibly) more permissive "sp" policy. That sounds fairly deep into "don't do that" territory. If you are clever enough to publish a wild card MX, you should be clever enough to publish an appropriate DMARC record. Keep in mind that wildcards don't work the way many people think they do, so if you have *.foo.com along with a.foo.com, then the wildcard will match b.foo.com, but not b.a.foo.com. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD
In article <132dd4e4-616a-47f5-a4a3-681067c86...@amazon.com>, Flaim, Bobby wrote: >-=-=-=-=-=- >Amazon supports this draft and effort . > >This current DMARC extension (IETF DMARC PSD) >draft<https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/> would make it >easier for our direct customers (registrants) to setup a common DMARC policy >for all their subdomains. It looks like you may be misunderstanding what PSD is. If someone registers, say, pickle.deal, right now they can put an sp= tag in the record at _dmarc.pickle.deal which sets the policy for .pickle.deal. That's the way that organizational domains work. PSD lets you publish _dmarc.deal and have that apply by default to the whole TLD, .deal and ..deal and so forth. R's, John -- Regards, John Levine, jo...@iecc.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] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >Firstly, I'm a little concerned with the sentence which says 'Note that >"np" will be ignored for DMARC records published on subdomains of >Organizational Domains and PSDs due to the effect of the DMARC policy >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't >think that is an accurate portrayal. ... I think what it means is that if there's a DMARC record on a subdomain, it won't see any np= in the org domain or the PSD. I agree the wording could be better. I also don't understand what possible meaning an np= on a subdomain record would have. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article <2902055.CzhLQO0xIX@l5580> you write: >Here's the definition we have in the draft now: > >> 2.6. Non-existent Domains >> >>For DMARC [RFC7489] purposes, a non-existent domain is a domain name >>that publishes none of A, , or MX records that the receiver is >>willing to accept. This is a broader definition than that in >>NXDOMAIN [RFC8020]. > >That's what I was expecting this new tag to apply to (and I think matches >their expectation, but they can speak for themselves). That's OK. >Another way to say what's in 2.6 now might be: > >... a domain for which there is a NODATA response for A, , and MX records. Not so OK -- if there's no records at all at or below a name you really will get NXDOMAIN. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >-=-=-=-=-=- > >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote: > >> I am much more concerned with adding another tag that can only be used in >> a PSD-DMARC record. I would be much more open to make a "normative" change >> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC >> record, than to make this a special case for PSD-DMARC records. >> > >I am also concerned with adding any new policy-related tags, due to the >confusion they create that limits adoption. However, a very clear case for >an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov and >.mil have stated they also want this behavior. Others have shared similar >opinions privately. How do they feel about NODATA, which is not the same as NXDOMAIN? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd
In article <3a6e6f9ac98c4e60af1075760efde...@verisign.com> you write: >> I don't plan any changes except for those in response to last call comments. >> Unless I get direction otherwise, I don't plan any updates until after last >> call is >> over. >> >> Please review this one. > >Repeating what I suggested earlier: > >https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk That seems OK to me. We don't need to say anything specifically to ICANN. Should PSD turn out to be popular, this will be an input to an ICANN process to allow the PSD record at the top of a TLD zone. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd
I wasn't thinking this would go in the doc, just for background. Autocorrectly, John On 27 Jun 2019 12:23, "Hollenbeck, Scott" wrote: > > > -Original Message- > > From: dmarc On Behalf Of John Levine > > Sent: Thursday, June 27, 2019 6:52 AM > > To: dmarc@ietf.org > > Cc: superu...@gmail.com > > Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd > > > > >I concur. Does anyone know of such a policy statement from ICANN? I > > >don't recall it being present in, say, any of the DNS RFCs, but there > > >are so many of those now... > > > > Hi from ICANN 65 in Marrakech. > > > > The gTLD registry contracts say directly or indirectly what's allowed in > > each > > TLD zone. Here's the language in the base registry agreement that the new > > TLDs all use: > > > > https://newgtlds.icann.org/sites/default/files/agreements/agreement- > > approved-31jul17-en.html#exhibitA.1 > > > > For the older TLDs, notably .com, the contract refers to Consensus > > Policies, > > which are at https://www.icann.org/resources/pages/registrars/consensus- > > policies-en > > > > One of those policies is the Registry Services Evaluation Policy > > (RSEP) which is at > > https://www.icann.org/resources/pages/registries/rsep/policy-en > > > > Here's the list of RSEP requests: > > > > https://www.icann.org/resources/pages/rsep-2014-02-19-en > > > > Adding a dmarc record to individual TLD would need an RSEP, for which an > > RFC would likely be helpful but probably not essential. The RSEP process > > for > > things that are not politically controversial is not particularly hard. > > > > Adding them to all of the TLDs could be a new consensus policy, or maybe a > > change to the base agreement. How to do that is above my pay grade. > > The ICANN minutiae is probably way more detail than is needed in the > document. I'd be more comfortable if there were text in the Introduction > along the lines of what Murray said in his last note (paraphrased here > slightly): "Please note that today's operational and policy reality prevents > this experiment from being deployed globally. If the experiment shows that > PSD solves a real problem at a large scale, the results could prove to be > useful in the development of policies outside of the IETF that would permit > its ubiquitous deployment". > > Scott > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd
I wasn't thinking this would go in the doc, just for background. Autocorrectly, John On 27 Jun 2019 12:23, "Hollenbeck, Scott" wrote: > > > -Original Message- > > From: dmarc On Behalf Of John Levine > > Sent: Thursday, June 27, 2019 6:52 AM > > To: dmarc@ietf.org > > Cc: superu...@gmail.com > > Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd > > > > >I concur. Does anyone know of such a policy statement from ICANN? I > > >don't recall it being present in, say, any of the DNS RFCs, but there > > >are so many of those now... > > > > Hi from ICANN 65 in Marrakech. > > > > The gTLD registry contracts say directly or indirectly what's allowed in > > each > > TLD zone. Here's the language in the base registry agreement that the new > > TLDs all use: > > > > https://newgtlds.icann.org/sites/default/files/agreements/agreement- > > approved-31jul17-en.html#exhibitA.1 > > > > For the older TLDs, notably .com, the contract refers to Consensus > > Policies, > > which are at https://www.icann.org/resources/pages/registrars/consensus- > > policies-en > > > > One of those policies is the Registry Services Evaluation Policy > > (RSEP) which is at > > https://www.icann.org/resources/pages/registries/rsep/policy-en > > > > Here's the list of RSEP requests: > > > > https://www.icann.org/resources/pages/rsep-2014-02-19-en > > > > Adding a dmarc record to individual TLD would need an RSEP, for which an > > RFC would likely be helpful but probably not essential. The RSEP process > > for > > things that are not politically controversial is not particularly hard. > > > > Adding them to all of the TLDs could be a new consensus policy, or maybe a > > change to the base agreement. How to do that is above my pay grade. > > The ICANN minutiae is probably way more detail than is needed in the > document. I'd be more comfortable if there were text in the Introduction > along the lines of what Murray said in his last note (paraphrased here > slightly): "Please note that today's operational and policy reality prevents > this experiment from being deployed globally. If the experiment shows that > PSD solves a real problem at a large scale, the results could prove to be > useful in the development of policies outside of the IETF that would permit > its ubiquitous deployment". > > Scott > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd
>I concur. Does anyone know of such a policy statement from ICANN? I don't >recall it being present in, say, any of the DNS RFCs, but there are so many >of those now... Hi from ICANN 65 in Marrakech. The gTLD registry contracts say directly or indirectly what's allowed in each TLD zone. Here's the language in the base registry agreement that the new TLDs all use: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1 For the older TLDs, notably .com, the contract refers to Consensus Policies, which are at https://www.icann.org/resources/pages/registrars/consensus-policies-en One of those policies is the Registry Services Evaluation Policy (RSEP) which is at https://www.icann.org/resources/pages/registries/rsep/policy-en Here's the list of RSEP requests: https://www.icann.org/resources/pages/rsep-2014-02-19-en Adding a dmarc record to individual TLD would need an RSEP, for which an RFC would likely be helpful but probably not essential. The RSEP process for things that are not politically controversial is not particularly hard. Adding them to all of the TLDs could be a new consensus policy, or maybe a change to the base agreement. How to do that is above my pay grade. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] spec nit - which DKIM to report
In article <7cd366d2-ab8d-cce8-67ff-59b79183c...@tomki.com> you write: >As mentioned by Elizabeth recently: (Elizabeth please chime in if this >doesn't capture your meaning) > >the spec does not define *which* DKIM signature should be reported in >the DMARC RUA created by a receiver. The proposed resolution to this is >that if the receiver does not provide the complete set of DKIM >signatures found, they should provide (in order of preference) >1. a signature which passed DKIM in strict alignment with the From: >header domain >2. a signature which passed DKIM in relaxed alignment with the From: >header domain >3. some other signature that passed DKIM >4. some other signature that didn't pass DKIM This seeems overcomplex. How about saying the reports SHOULD include all valid DKIM reports. If they can't, they can't, and I don't see any benefit in offering advice on how not to comply. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] nit - data integrity
In article <0a8b5459-8a9a-7a5b-d169-4c183c43a...@tomki.com> you write: >Examples: >- raw SPF 'fail' should never result in DMARC-SPF 'pass' >- raw SPF 'pass' out of alignment with header_from should never result >in DMARC-SPF 'pass' >- raw DKIM not being shown should never result in DMARC-DKIM 'pass' >etc I'm sorry, but I don't understand this at all. The DMARC spec is quite clear about what SPF and DKIM results are required for DMARC alignment, and this has no connection I can see with the alignment rules. I also don't know what you mean by a "raw DKIM" or what it means to show it or what you mean by "raw SPF" pass or fail. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
In article <29174612-a051-8066-9dde-2afaf181c...@dcrocker.net> you write: >The high-level point I'm trying to make is that control messages -- such >as DMARC reports -- need to be handled in a fashion that works >automatically and at scale. Since looping is a well-known problem for >such messages, they need to be generated and handled in a way that >prevents the problem. Right. you can give all the advice you want about sending stuff in ways that's intended to prevent responses, but since some people will always ignore your good advice, and any single party only controls one leg of the loop, the only unlateral way to limit the damage is rate limiting. It's fine to tell people to use null bounce addresses and from: addresses that don't ask for dmarc reports, but you need to rate limit anyway. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
In article <01d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> you write: > I am aware that the DKIM specification says to treat an >unverifiable signature as a non-signature. This is not a sufficient reason >to release your own organization's signatures onto the internet when you can >or should know that they will fail validation. Not to belabor the obvious, but the spec says what it says even if you personally wish it said something else. The way to make systems interoperate is to implement the actual spec. R's, John -- Regards, John Levine, jo...@iecc.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 issue: Reporting URIs
In article you write: >>>>>> "JL" == John Levine writes: > >JL> implement it. If people are interested in an https PUT scheme it >JL> would be easy enough to define one, > >I find that the http POST scheme for TLSRPT works very well. It looks straightforward enough. Do people actually use it? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis issue: Reporting URIs
Section 6.3 says that ruf and rua tags can take any URI, but only define the meaning of a mailto: URI. Either it should define some other URI schemes or it should say that only mailto: URIs are valid. Back in the olden days there was an http or https scheme that we took out because it was ill specified, and nobody but me had tried to implement it. If people are interested in an https PUT scheme it would be easy enough to define one, but only if someone says they want to use it. For large reports it could be somewhat faster than mailto both because the report body isn't base64 encoded and the report goes straight to the https server and doesn't get relayed as mail does. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis issue: failure report mail loops
Apropos recent discussions, we could recommend that failure reports be rate limited per recipient both to break loops and to deter indirect mail bombing. -- Regards, John Levine, jo...@iecc.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] mail loops, Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
In article <20190525183556.horde.zvg1bnsybvs_enkzpkjl...@webmail.aegee.org> you write: >Consider this scenario: an email from a domain, with DMARC policy >“p=reject; ruf=postmaster@domain” fails validation. A >message-specific report is sent to postmaster@domain. The report is >bounced (or there is any reply on it) and the reply is again From: >that domain and does not validate DMARC. On further consideration, I was reminded about all the mail loops I had to deal with back when I was running autoresponders. What I discovered is that there is nothing you can put in your messages which will prevent mail loops, since there will always be someone at the other end that will respond anyway. What you have to do is rate limit. For example, if you see that you've sent more than five failure reports in an hour to a particular address, don't send any more reports to that address during the next hour, even if mail comes in that would get a report. You can tune the time period and threshhold, but so long as the time period is longer than a cycle of the mail loop, they don't matter much. -- Regards, John Levine, jo...@iecc.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] Debugging and preventing DKIM failures- suggestion
In article <433a2fcbcab9452d8ca4b3ac99dc5...@bayviewphysicians.com> you write: > 2) Recover from Subject header changes that break signatures. This idea has come up, let us say, once or twice before. If you're trying to undo what mailing list software does and reconstruct the signature, that is a rathole of no return. Also keep in mind that malicious parties can change the signature, too, and there's no way I know of to tell a malicious rewrite from a benign one. ARC is designed to deal with this situation. Take a look. -- Regards, John Levine, jo...@iecc.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] Debugging and preventing DKIM failures- suggestion
In article <54fb29a0-517a-430e-af5b-cb079cc3d...@aegee.org> you write: >-=-=-=-=-=- > >Hello Douglas, > >1) Check the Authentication-Results header. An implementation could put there >additional information as comment. A >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust >the previous hop. Common case: aliases >to random servers. That would be my suggestion. You can put whatever you want into comments in the A-R header. -- Regards, John Levine, jo...@iecc.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] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
In article <115e2cd4-af67-4a8d-85ba-567ba74d3...@aegee.org> you write: >-=-=-=-=-=- > >Hello Grant, > >it is a misconfiguration, but it still creates a mail loop for the site, that >is not misconfigured. > >To what I can say the emails are accepted at SMTP time and then bounced. > >I not asking to modify DMARC, but to recommend sending message-specific, >individual failure reports FROM: <>, in >order to be protected from “misconfiguration attacks”. Given that we've seen one report loop in seven years, my inclination would be to suggest that you simply blackhole whatever IP their bounces are coming from and leave it at that. -- Regards, John Levine, jo...@iecc.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] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
In article <20190526050958.horde.6vaaxrzkglqyej4uov0v...@webmail.aegee.org> you write: >Hello John, > >in case of modernwebsite.pl: > >DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100; >rua=mailto:postmas...@modernwebsite.pl; >ruf=mailto:postmas...@modernwebsite.pl; aspf=s;adkim=s;" > >Emails to postmas...@modernwebsite.pl are answered with “Undelivered >Mail Returned to Sender”. The answers do not align to the DMARC >policy reject, so a new message-specific failure repot is sent. Just out of curiosity, where do the reports come from? I see their SPF record says "mx a". ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Improving feedback using additional status codes
In article <1ee3bd2ebd204746a0d0641e186ca...@bayviewphysicians.com> you write: > PROPOSAL > > When a recipient detects an SPF or DKIM problem, it can provide immediate >feedback to the sender with message status codes. No. If people want status reports, they'll ask for them. On the other hand, if I were a spammer, I would think your proposal was great because it makes it a lot easier to probe and figure out how your spam filtering works. -- Regards, John Levine, jo...@iecc.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] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
In article <20190525183556.horde.zvg1bnsybvs_enkzpkjl...@webmail.aegee.org> you write: >Consider this scenario: an email from a domain, with DMARC policy >“p=reject; ruf=postmaster@domain” fails validation. A >message-specific report is sent to postmaster@domain. The report is >bounced (or there is any reply on it) and the reply is again From: >that domain and does not validate DMARC. In turn a new >message-specific report is sent and this loop ends, when some disk >gets full. With FROM:<> or NOTIFY=NEVER there would be no such loop. The trickle of failure reports I get are from addresses like these: forensicdm...@seznam.cz mailn...@segv.crash.com dmarc-nore...@linkedin.com opendm...@hamartun.priv.no prvs=1020be0dc4=nore...@manthorp.com I would expect that any mail sent to those addresses is unlikely to provoke a failure report, no matter how mangled it is when it arrives. We've had failure reports for almost seven years and I don't ever recall someone getting into a mail loop so it's not a problem in practice. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
In article <20190523225213.c214620147b...@ary.qy>, John Levine wrote: >In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write: >>There are domains that would like to receive reports, but whose usage of >>mail doesn't make it useful to express a policy. Conversely, there are >>domains that want to express a policy but aren't interested in reports. >>I'd like to advocate that DMARC be split up into two different documents >>dealing with reporting and policy separately. If it's useful to have a >>separate document that defines what it means to be "DMARC-compliant" >>that is referenced by both, that would be OK. > >Given that we already have one document, I would be very strongly >opposed to this. It's fine to fix things that are wrong, but trying >to restructure it retroactively will inevitably lead to accidental >incompatibilities. On the other hand, if you want to write separate non-normative tutorials for the reporting part and the policy part, sure, go ahead. -- Regards, John Levine, jo...@iecc.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 issue: Separating reporting and policy
In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write: >There are domains that would like to receive reports, but whose usage of >mail doesn't make it useful to express a policy. Conversely, there are >domains that want to express a policy but aren't interested in reports. >I'd like to advocate that DMARC be split up into two different documents >dealing with reporting and policy separately. If it's useful to have a >separate document that defines what it means to be "DMARC-compliant" >that is referenced by both, that would be OK. Given that we already have one document, I would be very strongly opposed to this. It's fine to fix things that are wrong, but trying to restructure it retroactively will inevitably lead to accidental incompatibilities. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary?
>I took a look at the non-comment content of the public portion of the PSL to >get an idea of the scope of this problem. Here's the distribution of lengths >of public suffixes: > >one: 3077 >two: 3821 >three: 1986 >four: 3 I only see 1527 with no dot. Since there's only 1532 TLDs it's hard to see where another 1500 could come from. The other numbers look right. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records?
In article you write: >On 4/10/2019 8:37 PM, Scott Kitterman wrote: > print(response.additional) >> [] >Turns out that's what I was especially hoping to see. As I understand it, your design depends on putting NXDOMAIN signals in the additional section to show that there aren't any boundaries between the names it returns. How do you plan to do that? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-eaiauth-05: (with COMMENT)
In article <155486669171.19715.14014281020759221500.idtrac...@ietfa.amsl.com>
you write:
>I agree with Benjamin's DISCUSS comment: this document needs to better
>explain the consequences of the inability to match %{s} and %{l}.
It has no consequences at all. As Scott noted, it documents what the code does
now.
He talks about
>it from a security perspective, but I think there's also a discussion to be had
>here about whether this disadvantages users who elect to have non-ASCII
>characters in their mailbox names.
I have to object here -- this is asking us to put a tutorial about SPF
into this minor update document. Anyone who is familiar with SPF
knows that local part macros are useless and it makes no difference.
Even if they weren't useless and we we wanted to encode UTF-8 local
parts in the DNS, that doesn't work because the semantics of local
parts and of domain names and the way they are interpreted are very
different. The obvious problem is case folding which has in the past
kind of mostly worked because the ASCII DNS case folding rule and
ASCII mail case folding conventions happen to be similar, but it goes
straight downhill from there with characters other than ASCII letters
and digits. This has been argued to death many times, and again this
is not the place for a tutorial.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Rethinking DMARC for PSDs
In article you write: >This neglects the benefit to the domain operators of receiving the reports >about abuse of their domain space. For the end recipient of the bogus >traffic, there is no difference. I agree that the reports are useful, regardless of the policy. I just wish we could figure out how to do this without reinventing the PSL. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Rethinking DMARC for PSDs
In article you write: > The problem: > Spammers use non-existent domains to achieve identity spoofing, such as >tax.example.gov.uk > This is primarily a reception problem, because many recipient mail filters >are not equipped to block this type of fraud. .. Right, and we can stop right there. A decent spam filter will treat a nonexistent From: domain or envelope bounce address as extremely suspicious and send the message into spam folder purgatory. If someone's filters aren't doing that, it is unlikely that they're paying much if any attention to DMARC, and no amount of fiddling with DMARC will make any difference. My mail server rejects anything with a non-existent bounce address at SMTP time and I don't think it's ever rejected anything my users would want. The solution to this problem is for mail systems to fix their filters, not to invent yet another mail-breaking hack that they won't use anyway. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)
In article <14007257.XvzNgCV7GG@kitterma-e6430> you write: >There's no change in security considerations because there's no change in the >protocol. We're merely more clearly documenting the interaction. I'll leave >it to the chairs/author/shepherd to decide how to respond to the discuss, but >I think "we're just documenting how it implicitly works" is a more likely road >to success than "meh, no one really uses that". Oh, of course. What I was trying to say was that's why we didn't try to invent a way to make it work with EAI mailboxes. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
In article <3bebe973-0536-96cd-983e-240ba4346...@dcrocker.net> you write: >Comments eagerly sought, of course. This seems sorta kinda like my dbound draft, only with _tagged TXT records rather than a new rrtype, and (unless I missed something) a hope that somehow you can use a yet to be invented cache to avoid walking up the tree, where mine used wildcards to do one lookup per boundary regardless of the tree depth. I can see that the tradeoffs are different but I don't see why they're better. R's, John >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt >has been successfully submitted by D. Crocker and posted to the >IETF repository. > >Name: draft-dcrocker-dns-perimeter >Revision: 00 >Title: DNS Perimeter Overlay >Document date: 2019-04-02 >Group: Individual Submission >Pages: 20 >URL: >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Email security beyond DMARC?
In article <002a01d4de81$18ac27b0$4a047710$@bayviewphysicians.com> you write: >Can one of you elaborate on the potential connection between PeP and DMARC, >or more generally, the connection beteen PeP and spam filtering? I presume that PeP would make spam filtering much harder since the filters can't look inside the messages. Be careful what you wish for, and remember that bad guys can use all our shiny toys, too. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=reject
In article you write: >-=-=-=-=-=- > >If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature >is successfully decrypted, so DKIM passes; what good is checking alignment >and rejecting a message? The short answer is that bad guys can publish SPF and DKIM just as well as good guys. Anecdotally, it appears that bad guys are better at it than good guys. The point of DMARC is not just that a message is authenticated, but that it is authenticated by the same domain that's on the From: line, which makes it highly likely that the message is actually from who it appears to be from, rather than from some random crook with an SPF record and a DKIM signer. There are certainly plenty of ways that DMARC can do unfortunate things but in this case it's working as intended. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth
In article you write: >> Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth? >> If I don't see anything within the next week, I will hit the "request >> publication" button in the datatracker. I have a version that fixes a few typos and has a new paragraph pointing out that DKIM relaxed header canonicalization folds the header names to lower case, but those names are still restricted to ASCII so nothing changes. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article you write: >Hello John, > >DMARC reports for p=none are not supposed to be useful, as they do not depend >on the policy. Sorry, but that assertion is completely wrong. Please see RFC 7489. >If the question is about how to get reports on failing DKIM validation only on >unexpectedly smashed >messages, then I >recall the last discussion on ietf-d...@ietf.org: No, that is not the question. Please review the previous messages. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt
In article <6596039.Rh8MxG5e5K@kitterma-e6430> you write: >The current PSL is over 12K lines long. What we're talking about here is >probably .1% to 1% that size. Indeed, but since everyone has the PSL anyway to find organizational domains, who cares about the size? The point of asking the PSL people to do it is to find a credible third party to evaluate "all your domains belong to us" assertions. > Leaving aside for a moment the mechanism, would >people review the latest draft and see if they think the privacy issues are >adequately described and if they require some kind of mitigation? I think it's fine. At the end where you talk about failure reports, you might note that since they contain actual messages, any domain where the admistrator does not normally read its users' mail already has the same issues. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article <974c2d00017358cdf3b78037e4276234db2cfdee.ca...@aegee.org> you write: >Hello John, > >On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: >> … The failure reports are almost >> entirely useless. Of the ones I get, the majority are random Chinese >> spam that happened to forge one of my domains on the From line, the >> rest are from mailing lists where I wouldn't expect DMARC to pass. >How do you define a useful report and for which purpose do you want to receive >reports? A useful report would be one that was a message that one of my users had actually sent and was smashed in a way I didn't expect. > I mean, when does sending reports to p=none make sense. The feedback reporting doesn't depend on the policy. Please review section 7 of RFC 7489. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article you write: >sending a notification, when DMARC does not match is comparable to sending a >notification/feedback loop, when a user >clicks a message as spam. No, it isn't. When the user clicks the spam button, she has taken a specific step to notify someone about the message. DMARC forensic reports are entirely automated. But once again, I am pretty sure the people who you would need to persuade are not on this mailing list, or any IETF mailing list. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article you write: >reiterating over the arguments against sending reports to the ruf= …dmarc >address, the first provided reason was, that >such report will not match the expectations of the users. I'm pretty sure that the people you think you are arguing with are not on this mailing list. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you write: >How can a domain owner communicate, that its users agree to have >investigations on forensic reports, where DKIM >signatures failed (fot the purpose of avoiding repeating errors in DKIM >signing/validation)? In particular, that there >is no expectation of the users that a deleted message is erased and that the >domain owner, DNS staff and email staff >function good as whole? I suppose they could try to put it in the terms of service, but I wouldn't begin to guess whether that would be enforcable or even legal in places with the GDPR and other privacy laws. More to the point, I wouldn't bother. The failure reports are almost entirely useless. Of the ones I get, the majority are random Chinese spam that happened to forge one of my domains on the From line, the rest are from mailing lists where I wouldn't expect DMARC to pass. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.ca...@aegee.org> you write: >What are the privacy concerns in this simple scenario that speak against >sending a DMARC/DKIM report to sending server, >telling that the DKIM validation fails? The person reading the DMARC reports had enough authority to put a record in the DNS, but that is not the same thing as being able to read all of the users' mail. In large mail systems, different staff have different roles, and very few of them can look at users' mail. -- Regards, John Levine, jo...@iecc.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] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)
In article you write: >happened in the deployed universe. So now we have a registry entry for the >"body" ptype which isn't deprecated, but possibly no live uses of it. ... I'd leave it there, at least so nobody inadvertently reuses the ptype name. Apropos the comment about VBR, as far as I can tell nobody uses it so I'm not inclined to spend much effort on it, but the text in -04 is fine. If someone wants to put U-labels in their VBR headers, it's OK with me. R's, JOhn ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt
In article <3104294.rU99Ex2XNH@kitterma-e6430> you write: >My understanding is that, since, as you say, PSOs (like .bank) have a pre- >existing relationship with their registrants, they don't need PSD DMARC to >audit their registrant's policies. For an entity like that, it offers the >chance to get feedback on other, presumably non-existent, domains so as to >better understand abuse patterns within the PSD they manage. It also gives >them a mechanism to express a reject policy for those domains, which does not >currently exist. This may help improve rejection of cousin domains by >receivers. > >For single entity PSDs, like for a very large Internet company that is, >conveniently not named after a large South American rain forest (so they can >get it registered), it offers other advantages. In cases like this, the PSD >operates like an organizational domain except for the fact that in the current >DMARC instantiation, their record won't work for subdomains. PSD DMARC would >enable '.example' to publish a single record for all lower level entries in >the zone. That all seems reasonable but it still feels like a lot of mechanism for marginial benefit, particularly since we have no clue who's going to run it if we can't foist it off on Mozilla. I wonder if there's any way to get the PSL to tag vanity TLDs. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax
In article <43ae9a84-75e3-1292-d3f4-68f3a7445...@spamtrap.tnetconsulting.net>
you write:
>However I still feel like /requiring/ exact case is contrary to the idea
>of "Be liberal in what you accept and conservative in what you send.".
Yup. See
https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance
a/k/a "Postel was wrong".
>I don't see any security implications in accepting the following:
>
>dmarc-version = ("v" / "V") *WSP "=" *WSP ("D" / "d") ("M" / "m") ("A" /
>"a") ("R" / "r") ("C" / "c") "1"
Please see the previous several dozen messages, particularly the one
about the brown M&M's. If you know that someone didn't read the spec,
you can only guess what else they got wrong, and you're not doing
anyone a favor by doing that.
>I agree that this is contrary to the letter of the specification.
>However I think it is completely within the spirit. Especially when
>dealing with DNS data which is inherently / invariable human entered.
Once again, please try not to assume that everyone's experience is the
same as yours. On my DNS server, the DMARC records are generated
automatically when I add a new mail domain and their syntax is
correct. (Or every DMARC record is wrong, but I would notice that
pretty soon.) On the large systems which these days host most mail
it's hard to see how they could do it manually.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax
In article <7c8aa4a8-7d75-db07-7e97-82d9b0ffb...@gmail.com> you write: >If more flexibility is viewed by the community as desirable, then the >community should enhance the specification to allow it. This improves >robustness while retaining a firm, clear and precise standard. Do keep in mind that most of the DMARC records I've looked at follow the spec. They may not have the expected policy, but the syntax is fine. If a small minority get it wrong, I think it's better to educate and fix them than to try to guess when someone misreads the spec in a way that leads them to screw up the syntax of the record, but not to screw up anything else. Remember, that if your software rewrites an invalid record into a correct one, you are trying to read the mind of the person who wrote the misformed record. I can guess what v=dmarc1 was supposed to say but I have no clue what pct:1 is supposed to mean. Let's not start. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Nitpicky questions about DMARC record syntax
I am staring at RFC 7489, and at a bunch of purported DMARC records (see previous message.) The RFC says that all records must start with "v=DMARC1". Is it OK if they start with "v=dmarc1"? It says that record is a DKIM tag-value list, and the DKIM ABBF defines all the characters with hex escapes rather than letters which tells me that it's specifically saying that case matters. How about if there's a space before the v=DMARC1? The tag-value syntax allows FWS before the first tag, but 7489 says in several places Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. R's, John PS: I know it's not hard to write a parser that can accept mutant forms. The question is whether that's a good idea. From a quick look, people who get v=DMARC1 wrong often get other things wrong, too. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt
In article <5126347.eOcQ2jtf8Q@kitterma-e6430> you write: >This update removes the IANA registry (which is what I think I was supposed to >do based on the feedback to date). I also bulked up the Privacy/Security >considerations descriptions since they are no longer mitigated. > >I'd like feedback on the best path forward. Essentially this draft replaces >the IANA registry with an undefined way to know where PSD DMARC is >appropriate. I think we need something better than that, but I didn't know >what. The more I look at this, the less I understand what problem it solves. If you manage a zone that can publish a PSD policy, you have some kind of relationship with the zone members so you should be auditing their policies anyway. To take a non-random example, I looked at the 2700 names in .BANK. There are 122 with no DMARC at all, which PSD might help, but there are also 164 with p=none, 29 with p=quarantine, 7 with pct=N where N is not 100, 4 with multiple policies, and about 30 where the DMARC record is invalid. Assuming your goal is to get everyone to p=none, PSD doesn't impress me as offering significant help. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD simplification
In article <2046741.GJeexbxHFF@kitterma-e6430> you write: >In previous examples, this has been analogized to the Verisign sitefinder >debacle. Personally, I think it's worse. Without an external check, this is >a tool for enhancing the surveillance capacity of authoritarian regimes. This is starting to sound like the drunk looking for his keys by the streetlight. I grant the hypothetical point you're making, but if I were a cruel government, funky DMARC records would not be near the top of my list of intrusive techniques. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD simplification
>I think it would be interesting to get more details from John Levine on his >experience with this as he has (in a later message in the thread) mentioned >he's getting this kind of data now for odd architectural reasons. I'm the legacy registry for seneca.ny.us, a rural county just north of here. One of my registrants is the county government, at co.seneca.ny.us. I have an MX on seneca.ny.us so people can write to me at hostmas...@seneca.ny.us if someone in the county wants to registers a name. They have lots of people at @co.seneca.ny.us. I have my usual dmarc record at _dmarc.seneca.ny.us, and I've noticed that since they don't publish a dmarc record (or much of anything else, since their mail is outsourced to O365 and they're not very sophisticated), I get all of their dmarc reports. In this case it's not a big deal, they know who I am, I know who they are, local governments aren't supposed to keep secrets, and the reports don't show anything surprising, but one can imagine situations where it could be an issue. I suppose in principle it might be a problem if some of their mail showed up in failure reports, although since my policy is p=none and as far as I can tell nobody there sends mail to mailing lists, there aren't many of those. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD simplification
In article <1b0bef4b-61e6-776c-79e8-89631efa8...@dcrocker.net> you write: >So I think that the functional goal of kitterman-dmarc-psd is fully >satisfied by merely doing a version of the 3A update to DMARC, directing >the client to query the immediate parent of the organizational domain, >if the OD has been queried and no DMARC record has been found. Given that anything we do to handle public suffix defaults will need some code changes, this seems about the simplest change that would do the trick. I am aware of two security or privacy issues that might come up. If we used a DNS scheme like my DBOUND one, whoever runs the DNS policy server can see all the queries and will have some idea of the mail traffic from various names. This approach doesn't have that problem. The DNS operator can tell that someone is asking about a subdomain, but not which subdomain. The other is that the DMARC record might have rua= and ruf= and get detailed reports about subdomains. This is not an unreasonable concern -- I am the legacy registrar for various .ny.us domains and my DMARC reports tell me a lot about one of my registrants who sends a lot of mail. (Real mail, they're the county govermnent.) This is easily addressed by clients ignoring the report advice in the OD parent record. One issue that is not our problem but might be Scott's is that in ICANN contracted TLDs, they're not allowed to publish TXT records at _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special permission to do so. I happen to know the people who evaluate the applications (as do many other people here) and I'm sure they would say yes for those two TLDs, but it would involve some time and money. This might actually be a feature, since a similar appplication for _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more scepticism. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
In article you write: >> AIUI, local parts don't get puny-coded. > >Even when attempting to look them up via the macro mechanism? No, never. There is no way to re-code a UTF-8 local part. Don't even ask. If it sounds like I've had this argument before, I have and I really don't want to have it again. R's, John PS: even if we were to invent some crock like turning UTF-8 into hex, it would not work because there are a vast number of ways to encode strings in UTF-8 that look identical, and there is no plausible way to normalize them all. It's not like ASCII case folding. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
In article you write: >> what was already implicit; s and l macros will never match if the local >> part of the email address contains non-ascii characters. >> > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it seems >like they should be able to match without any problems. No. No, no, no, no. In EAI mail, e-mail address local parts are UTF-8. You cannot translate them into anything else and you very specifically cannot "punycode" them. Using the term punycode in IDNA2003, which is obsolete, was a serious mistake, since it led people to all sorts of bogus conclusions. In IDNA2008 domain names, and only in domain names, there are U-labels which contain a large subset of UTF-8 encoded Unicode, and there are A-labels which consist of ASCII starting with XN--. There is a two-way algorithm to convert between U-labels and A-labels. There is no punycode. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write: >2. Externalize signaling about PSD participation. As discussed in the >Privacy Considerations (section 4.1), we were concerned about the privacy >implications of feedback on organizational domain traffic for organizational >domains that don't participate in DMARC being inappropriately captured by >public suffix operators. It seems to me this horse left the barn a long time ago. Mail systems routinely check domains in HELO and in MAIL FROM against DNSBLs, which is at least as loggy as anything a DNS version of this check will do. Also, if you really want to keep people from logging your queries, you can set up a local mirror of the DNS zone, and update it in the usual way with AXFR and IXFR. Whatever one might have in mind for a text version of this, a binary AXFR would be about as fast and IXFR of just the occasional change faster. Take a look at my DBOUND proposal. I think it would be just the ticket for this application. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
In article you write: >-=-=-=-=-=- > >John's document reminded me of how CAA records are done, They >push all the processing outside the DNS servers. >Like CAA, we should make the RRTYPE require no special resolver processing >and then we can get the RRTYPE fairly quickly to start. In my proposal it's just a container, nothing special. The magic all comes from the closest encloser rule for wildcards, which is unrelated to rrtype. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
In article <20181109135829.horde.kt-9atgfd77p2otpu6pn...@andreasschulze.de>, A. Schulze wrote: > When evaluating "www.foo.example.com", the first query would be to > "www.foo.example._bound.com". If the reply to this is "BOUND 0 0 > com", then the second query would go to > "www.foo._bound.example.com". > >I ask myself if DNS query minimisation could be contrary to the query >sequence for subdomains. >QNAME minimization is normally performed by recursive resolvers. So it >should not disturb. >But for cases where an application implement that logic it would be >good to point to RFC 7616. I worry that if we try to enumerate every possible dumb way someone might implement even a very simple design, we will end up with a very very very long document. R's, John -- Regards, John Levine, jo...@iecc.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] Request to accept a new I-D into the WG work items
In article you write: >-=-=-=-=-=- > >I dug up John's old DBOUND draft to refresh myself and it's nice and >straightforward. I could not find if John shard the link >so here it is: > >https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt > >(hope that is OK John) That is fine. I thought it was pretty straightforward, too. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
In article <0e28da8c-09a6-4e64-ad5e-3741efe60...@kitterman.com> you write: >Unfortunately, I didn't come up with an idea for how to do this in DNS. This >seems like a legitimate issue >for the WG to work through. There were two DNS proposals in DBOUND, a more complex one from Casey Deccio and a simpler one from me. Mine would certainly work for identifying org domains. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC Multi Proposal
In article <9957335.dUWMaE32Bo@kitterma-e6430> you write: >Does it have to be any harder than that? I hope not but it's still not backward compatible so it's not really any better. With the current spec, if you have two AMS or AS with the same i= that's invalid, so if you start putting both rsa and ed25519 seals, old verifiers will probably fail. It'd be interesting to mock up dual seals, send them to Gmail et al, and see what they think. I suppose we could invent new headers EAMS and EAS and EAAR for the second and later version of seals, but ugh. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Milestones changed for dmarc WG
In article <82509274-bc89-495b-bd94-6d1f7846d...@kitterman.com> you write: >Is this milestone really done? The protocol document references >draft-ietf-dmarc-arc-multi, which >isn't done yet. Doesn't it need to be done too before this gets checked off >(there is no separate >milestone for multi). I gather there are practical issues: we don't see any way to do algorithm rotation in a way that is backward compatible with existing implemntations, and we'd like to publish something that matches the running code. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted
In article , Jeremy Harris wrote: >> New version: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-06 > >How about another subsection 5.x saying when Originating ADMDs should >take any ARC action? For starting a new ARC chain I assume the answer >is normally "don't" - but perhaps there is an exception when a message >is already DKIM-signed, or when SPF for it would be invalidated by >forwarding (despite it being in-theory a local ADMD source)? Seems to me that's pretty simple: you should add an ARC seal when you do something that might break DMARC validation, which means modifying the contents of the message (breaks DKIM) or remailing a message (breaks SPF.) It is my impression that if your message already has a local A-R header, it's a good candidate for adding an ARC seal. If not, it probably isn't even though you could in principle add your own A-R which only has arc=none. R's, John -- Regards, John Levine, jo...@iecc.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] Request to accept a new I-D into the WG work items
In article you write: >I'd like to recommend that we (DMARC-WG) accept >https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work >queue. It aligns with our charter already. OK with me. I'd like a clearer explanation of what problem it solves, but that should be fixable. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt
In article <3eea2f77-8aea-4f49-80f3-d96b639c3...@isode.com> you write: > Note that in an EAI-formatted message, this identifier may be > expressed in UTF-8. > >So I decided to check whether this statement is actually true. Oops. >OLD: > >"value" is as defined in Section 5.1 of [MIME]. > >NEW: > >"value" is as defined in Section 5.1 of [MIME], with "quoted-string" >updated as specified in RFC 6532. That seems the smallest adequate fix. In general EAI allows UTF-8 in fields that humans look at, but not ones just for computers like message-IDs. The alternative would be to leave the old text and add a note that says in the common case that the identifier is a domain name, IDNs are represented as A-labels. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18
In article you write: >-=-=-=-=-=- >At least 7601bis will be an RFC at the same time as this one is, if not >sooner. I don't know what the plans are for the other one. Also see Scott's LC comment on 7601bis. There's a bunch of stuff in 7601 not in the new draft, so 7601bis is really an update, not a replacement for 7601. R's, JOhn ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC Crypto Algorithm Selection
In article , Seth Blank wrote: >ARC inherits all the DKIM mechanisms by reference. So whateverâs valid for >DKIM (the list you provided) is whatâs valid for ARC. >> DKIM, as updated by the DCRUP work, has two valid crypto algorithms: >> >> rsa-sha256 >> ed25119-sha256 I would defer working on this until we clarify how algorithm switching will work. One place that ARC differs from DKIM is that many DKIM signatures are OK but you can only have one ARC seal per forward. In draft-ietf-dmarc-arc-multi-02 we say how I think it can work, but it's not quite backward compatible. R's, John -- Regards, John Levine, jo...@iecc.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 ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article you write: >My contention to Seth is that in a multi-hop scenario, the *only* report >with meaningful data will be the one from the handler who made the "fail" >determination and any subsequent reports are untrustworthy. Assuming that "subsequent" means earlier in the chain, I agree. >Do the other folks on this thread agree that our main point of contention >has to do with the ability to generate the DMARC report (or the data >scoping thereof)? Yes. I understand what to do with "here's a valid chain" and "it was broken when I got it", but not "here's a broken chain you may or may not be able to reconstruct." R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article <799c2b18-97fe-6e22-f2cf-49245ae9c...@gmail.com> you write: >So the extra mechanism is intended an efficiency hack. No, it also documents the fact that the chain was broken when it arrived at the cv=fail signer. Without it, a subsequent hop can't tell. It probably won't make much difference to spam filters, but it could be useful if you're trying to find and fix forwarders that make gratuitous changes. I think there's a modest benefit to signing with cv=fail, and since you can't count on having a chain (even an invalid one) signing as if it were cv=none seems reasonable. R's, John PS: Once there is a cv=fail seal, there doesn't seem to be any point to adding any more seals in later hops. It's dead, Jim. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02
In article you write: >-=-=-=-=-=- > > To the rest of the WG: Is there consensus to make this change or the >others being proposed? Not that I've seen. I thought we agreed to make changes to support ARC, to handle EAI, and to fix any actual errors. Other than that, leave it alone. R's, John > >I feel like we're making a lot more edits here than the WG intended to >make. It's fine if the WG wants to turn this into a larger editorial pass, >but I thought the updates here were tightly scoped before, namely just >enough to allow ARC to do what it needs. > >I'm inclined to resist, absent consensus, any changes that are other than >(a) something ARC needs, or (b) something clearly incorrect. > >On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely wrote: > >> >> In that case, if the producer intent is not to harm or mislead, the >> trust >> >> in this field's content would be proportional to the estimated >> quality of >> >> the producer's software. Consumer's wisdom is key. >> > >> > How is a receiver to know anything about the estimated quality of the >> > producer's software? ... ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 and EAI messages
In article you write: >> It doesn't say that in 4.1.2, even though it's sort of implicit since >> i= means something else. I'd say so explicitly in a fifth bullet >> after where it says "three (3) differences." > >One of those differences says: > >* the presence of the “instance tag”. Additional information on the >“instance tag” can be found in Section 4.2.1. The instance tag replaces the >DKIM “AUID” tag; > >This language could probably be cleaned up to say "the 'i' (AUID) tag is >not imported from DKIM. Instead, it is replaced by the "instance tag" as >defined in Section 4.2.1" > >Then section 4.1.3 should use the identical language as well. Please do. Experience tells us that the more clearly you lay something out, the less likely we are to screw it up. I don't remember what AUID is without looking it up but i= is obvious. R's, John PS: There's still four bullets after the three (3) differences. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
