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

Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd

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 o

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

Re: [dmarc-ietf] Org domaines, not really Comment on draft-ietf-dmarc-psd

se. 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 &q

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

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

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

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

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

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

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,

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,

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

Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

on-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.

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

Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD

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", Ple

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

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

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

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

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 > &g

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 > &g

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.

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

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

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

et 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, P

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 look

[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

[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 befo

Re: [dmarc-ietf] mail loops, Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?

ports 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 Perpetr

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

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 Pe

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

ture 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", Ple

Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?

t 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 _

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;

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

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 e

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.

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

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

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

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

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

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

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

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

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

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

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

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 >>

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

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.

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

Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy

orts 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 o

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

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

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

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

[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

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

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 j

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

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

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.

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

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

Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

isturb. >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

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

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

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

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

Re: [dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted

dd 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

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.

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].

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

Re: [dmarc-ietf] ARC Crypto Algorithm Selection

ackward 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.

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

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”.

Re: [dmarc-ietf] ARC-16 and EAI messages

In article you write: >-=-=-=-=-=- > >I've added the following text as Section 4.1.4 (note fixed typos and >removal of the i= section, which is removed from ARC explicitly): 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

Re: [dmarc-ietf] ARC-16 and EAI messages

In article you write: >The appropriate place for this guidance is likely a second paragraph in 4.1 >(https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1), >as this guidance will apply to the three following header fields. > >Would you mind suggesting a paragraph to add in

Re: [dmarc-ietf] ARC-16 and EAI messages

In article you write: >-=-=-=-=-=- > >I agree ARC should be EAI-ized. > >To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth >are approved by the IESG and properly update 7601 and 6376, then no direct >changes are needed to the ARC spec? > >So the only wording

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

In article you write: >5.1.2 says when a chain fails, to put cv=fail in the AS and only Seal the >ARC Set being added. > >Per the original message and suggested text, I believe 5.1.2 should only >provide the above guidance when it is not otherwise possible to sign the >entire ARC Chain (i.e.

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

In article <4878884.yiV4iTtLKX@kitterma-e6430> you write: >> In authentication service identifiers in EAI-formatted messages, a U-label >> and its equivalent A-label are considered to be the same. > >As an implementer (who's tried really hard to avoid spending cycles on EAI - >sorry), does this

Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken

In article you write: >-=-=-=-=-=- > >On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman >wrote: > >> And if you don't want to make a new one, 5.7.26 (Multiple authentication >> checks failed) seems at least not wrong. To get to this point DKIM, >> DMARC, >> and ARC have failed. > >Is this

[dmarc-ietf] ARC-16 signature domains

The ARC draft clearly says that every ARC header can be signed by whatever domain you want. I understand what that means technically, but I don't understand the semantics of an ARC set where the AMS and AS are signed by different domains. R's, John

Re: [dmarc-ietf] abnf bug in arc-protocol, was Comments on certain drafts

In article <5b55a0f8.1c69fb81.123a9.5...@mx.google.com> you write: >-=-=-=-=-=- > >draft-ietf-dmarc-arc-protocol > >The production “arc-info” includes a semicolon after “instance”, which in turn >has a semicolon at the >end.  However, a great number of Arc-Authentication-Results header fields

Re: [dmarc-ietf] ARC protocol-15 posted

In article you write: >> 9.2 describes the problem, but it's expressed in terms of a DoS attack on >> (primarily) validators. The DNS folk will be more concerned with the >> overall load on the infrastructure caused by ARC, not specifically on >> attack scenarios. So in consulting the DNS

Re: [dmarc-ietf] ARC protocol-15 posted

In article you write: >Given that we've settled on Experimental status, I propose this gets tabled >until that's published. The experiment will establish what benefit ARC can >provide, which I think is the most important output of this work. The >change being suggested here appears to be one

Re: [dmarc-ietf] Any outstanding issues on 7601bis?

In article <2940516.WEBi8fTYBz@kitterma-e6430> you write: >Is the list of EAI affected components of the field complete? As an example, >sometimes email addresses are used for SMTP Auth user IDs (or sometimes just >the local part). I don't know a lot about EAI, but it seems to me that most

Re: [dmarc-ietf] ARC protocol-15 posted

In article you write: >> Anything that comes close to 'do whatever you want with this >> information' demonstrates NON-standardization. Not at all. The point of a standard is to say here is what you do if you want to interoperate. Trying to figure out how to recover when someone else doesn't

Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC

In article <66d513ca-f33d-748b-e394-bceb6e1da...@spamtrap.tnetconsulting.net> you write: >-=-=-=-=-=- > >On 05/15/2018 08:15 AM, Kurt Andersen wrote: >> Manipulating MIME structures in email messages to expose the encrypted >> content: https://efail.de/ > >DKIM will not help protect against

Re: [dmarc-ietf] inheritance and public suffix list

In article you write: >> I think _dmarc as a TXT record is fairly well known. Is there anything >> that would specifically prohibit this? > >gTLDs are not permitted to place TXT records in their zones. That's mostly right. There is

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-01.txt

In article you write: >This includes a registration for "header.a" and John's changes to support >EAI. However, Barry has some concerns with how "local-part" is not left in >a good state by these changes. Those of you in the

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt

In article you write: >Et voila. If you go to the "History" tab and request a diff from the >individual -00 to the working group -00, you can see all of the changes >made relative to RFC7601. Basically it loosens up the

Re: [dmarc-ietf] DMARC-WG F2F @ IETF101

The WG chairs do it online, start here: https://datatracker.ietf.org/accounts/login/?next=/secr/sreq/ R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

In article <01qo3ttohmle000...@mauve.mrochek.com> you write: >This would need to be coordinated with the EAI people/list, but as long >as it isn't controversial I don't see a reason not to put it in. It's not supposed to be controversial, the minimum changes to make stuff work with EAI UTF-8

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

In article <1514939995.3318165.1222346488.5b169...@webmail.messagingengine.com> you write: >Please read my examples again if the problem wasn't clear, because you >don't get security by imagining the best cases where everyone behaves >themselves, you get security by imagining that everybody is

Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing

In article you write: >header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- >auth.xhtml Quite right, need to put it in the IANA considerations of something. FWIW, I added header.s to my SMTP daemon this

Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

In article

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

In article you write: >"Experimental" is perfectly fine. As I understand it, EAI did that first >and went to the standards track after it had some field use. That is true, but it's also true that the standards track version of

<    3   4   5   6   7   8   9   10   >