Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

On Thu, Sep 28, 2017 at 10:53 PM, Rick van Rein wrote: > > I also should add that the cryptographic design of ARC isn't clear to > me. I pointed out to the ARC authors that there is a lot of *how* but > little or no *why* to underpin what feels to me like a rather complex

Re: [dmarc-ietf] ARC and "fail" again

On Wed, Sep 13, 2017 at 1:03 PM, Murray S. Kucherawy wrote: > At the risk of bringing up the whole "cv=invalid" debate again... > > When a chain is invalid (say, an AMS is missing), Section 9.3 says to add > a seal that only covers itself but uses N+1 for its "i=" value.

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.txt

I've just pushed a new version (-09) of the draft which incorporates the following changes: # v09 * Edits related to Alexey Melnikov's 2017-07-25 message https://mailarchive.ietf.org/arch/msg/dmarc/TJnWqN1HIFpHS0Nhtxq0qnP6EhA * Some changes in response to Dave Crocker's 2017-07-28 message

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: > If we even have a DMARC ARC Policy concept, than that may be enough to > begin pursuing the high cost of experimentation and development here. > > Beyond the protocol and

Re: [dmarc-ietf] ARC signing when *not* modifying the message...

On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana wrote: > > Again - why seal on ingress? It's bogus. > > * check authentication on ingress > * add authentication on egress > > That's the pattern that means something and works. Otherwise your > internal mechanisms are

[dmarc-ietf] ARC signing when *not* modifying the message...

Splitting out this discussion point into a new thread... On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana <br...@fastmailteam.com> wrote: > On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote: > > On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <br...@fastmailteam.com> >

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana wrote: > . . . it's a bad idea to sign if you're not modifying, because then > everybody has to trust you or their chain breaks, even though you didn't do > anything which required signing. > > > In state #1, you don't

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Fri, Aug 11, 2017 at 9:27 AM, Dave Crocker wrote: > > I wanted to try to generate some candidate text that would respond to the > concerns that Bron has raised, but find that I'm not (yet) clear enough > about underlying details of ARC. I don't mean technical details, I

Re: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-08

On Fri, Aug 11, 2017 at 8:28 AM, Dave Crocker wrote: > Folks, > > I posted my review 2 weeks ago and haven't seen any responses. > > From some offlist exchanges, I think some believe the review responses are > merely editorial. They aren't. I did see your post, but have

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana wrote: > . . . If you aren't willing to agree that the most recent liar can > repurpose an existing chain, I'm happy to avoid making the forgery, > otherwise I'll make up a forgery and send it to the list. > > But since you

Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft

On Mon, Jul 31, 2017 at 4:58 PM, Brandon Long wrote: > On Mon, Jul 31, 2017 at 4:53 PM, Gene Shuman wrote: > > To repeat: > > > > But I understand now, simple misunderstanding. > > > > So is this assumption correct? An AAR should look like this: > > > >

Re: [dmarc-ietf] dns failures in the draft

On Mon, Jul 31, 2017 at 4:41 PM, Brandon Long wrote: > > 9.4. Handling DNS Problems While Validating ARC > >DNS failures to resolve or return data which is needed for ARC > >validation SHOULD result in a 421 tempfail during the SMTP > >conversation with the

Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft

On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland wrote: > On 25.07.2017 21:31, Gene Shuman wrote: > > So I think I'm still missing something. Let's imagine an ADMD setup in > > something like the following fashion: > > > > inbound -> policyspf(or some other spf check) ->

Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft

On Tue, Jul 25, 2017 at 9:14 AM, Scott Kitterman wrote: > > Insisting that all results from an ADMD for SPF, DKIM, and DMARC be > collapsed into a single AR header field is a huge change from the way AR > works today. AR was designed for each mechanism to be able to add

Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft

On Mon, Jul 24, 2017 at 6:06 PM, Gene Shuman wrote: > OK thanks. So if I understanding this correctly, we're suggesting, within > the ARC protocol, that the ways in which both DKIM & SPF stamp their info > into AR's is changed, at least when they're part of an ARC aware

[dmarc-ietf] draft-ietf-dmarc-arc-protocol-07 posted

URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-07 Htmlized:

[dmarc-ietf] Speaking notes for IETF99 DMARC meeting (Kurt)

*Herewith are my notes that I was referring to when speaking today - apologies for the weird line spacing that pasted itself in with the text...* *3. Report about handling IETF Mailman* We (Steve, Seth, Kurt) met with Henrik and Robert who support the IETF mailman (2.x) on Tuesday. They are

Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n]

Ack - consider it done and I'll report as such in this morning's session. Thanks for weighing in. --Kurt On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman wrote: > I also very much believe this language should be removed, as it's > unnecessary complexity. > > On Wed, Jul 19,

Re: [dmarc-ietf] Comments on ARC specification

On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov wrote: > I've started implementing ARC and have a few minor comments on the draft: > > 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature > >As with ARC-Seal and DKIM-Signature header fields, the order

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-06.txt

On Tue, Jul 18, 2017 at 8:51 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance of the IETF. > > Title :

[dmarc-ietf] Report from the IETF99 hackathon on ARC

We had 6-8 people through the weekend working on various interoperability things: - Andreas Schulze was able to obtain openarc.org and has stood up a forwarder using OpenARC to process the mail both with verification on the way in and sealing on the way out, but the AMS which are

[dmarc-ietf] Report from the IETF99 hackathon on ARC

We had 6-8 people through the weekend working on various interoperability things: - Andreas Schulze was able to obtain openarc.org and has stood up a forwarder using OpenARC to process the mail both with verification on the way in and sealing on the way out, but the AMS which are

Re: [dmarc-ietf] working arc software for IETF hackathon

On Sat, Jul 15, 2017 at 1:49 AM, Gene Shuman wrote: > Hello, > > For those of you attending the IETF hackathon tomorrow, I have a list of > some software packages that may be of use: > > > > Mailman - https://github.com/ValiMail/mailman/tree/arc > This branch of mailman

Re: [dmarc-ietf] using selectors to identify sources

On Mon, Jul 10, 2017 at 12:48 PM, Brandon Long wrote: > > > On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy > wrote: > >> On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: >> >>> I think it needs to be specified. Receivers

Re: [dmarc-ietf] ARC RFC status to target

On Sat, Jul 8, 2017 at 11:45 AM, Dave Crocker wrote: > On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote: > >> . . . if it's more important to get an RFC published than it is to wait >> for some modicum of deployed maturity -- which will take months, at least, >> I would guess

[dmarc-ietf] IETF99 hackathon, interop, and F2F meetings

For those on the list, but not planning to attend IETF99 next week in Prague, I wanted to let you know about a couple of activities which are planned: 1) Hackathon - Saturday (July 15: 0800 - 2100 CEST) and Sunday (July 16: 0900 - 1330 CEST); project details can be seen at

Re: [dmarc-ietf] ARC cv=invalid

On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman wrote: > > It seems we have two choices available to us upon receipt of an invalid > chain(which is defined as AS b= unable to be computed). > > 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in > the AR.

Re: [dmarc-ietf] ARC cv=invalid

Formerly, On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank wrote: > On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: > >> The google implementation pre-dates cv=invalid, and when I went to >> implement it, I couldn't find a good reason to do so, nor a great

Re: [dmarc-ietf] ARC cv=invalid

On Mon, Jun 19, 2017 at 3:51 PM, Gene Shuman wrote: > Starting a new thread, as this is probably *the* major blocker wrt > OpenARC. . . > Taking your two questions in reversed order: . . .what *precisely* constitutes an invalid chain vs a failing one? I had > previously

[dmarc-ietf] Next version of the draft was delayed due to TSA

The TSA policies that took my laptop away from me when returning via Dubai derailed my plans to get the next draft of the I-D completed. I'm planning to work on it in transit to M3AAWG so that I can post an update on Friday after reaching Lisbon. --Kurt

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Jun 1, 2017 11:48 PM, "Seth Blank" wrote: I'm slightly confused. I have a strong sense that the d= tag should be the same between the AS and AMS within an ADMD. I can absolutely see why the s= might legitimately vary. However, I can't seem the harm in the d= tag differing.

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy wrote: > Another way to look at it: A-R is meant to be a channel to record what > authentication was done and what thing in the visible message got > authenticated So, for SPF which does not authenticate *anything* in

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <kb...@drkurt.com> > wrote: > >> There's another question that had been raised by Seth about whether d= >> needs to match wit

Re: [dmarc-ietf] cv=invalid

On Thu, Jun 1, 2017 at 5:32 AM, Murray S. Kucherawy wrote: > > If a verifier decides an ARC is invalid, it's supposed to set > "cv=invalid", when generating its own ARC-Seal. This seems odd; we're > cryptographically signing a chain that is known to be broken, meaning the >

[dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

For the sake of discussion: I'd like to suggest that writing a DMARC usage guide under a BCP sort of moniker is not a useful activity for this WG. There are lots of white papers and other "how to use DMARC" guides available on the internet. What value would it add to have something preserved in

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Wed, May 31, 2017 at 5:26 PM, Alexey Melnikov <aamelni...@fastmail.fm> wrote: > Hi Kurt, > > On 31 May 2017, at 06:49, Kurt Andersen (b) <kb...@drkurt.com> wrote: > > even if we need to discuss the next steps, we haven't done that on the >> list yet, so we >

[dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC)

(Reposting with adjusted subject) On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) <kb...@drkurt.com> wrote: > Barry et al, > > On Wed, May 31, 2017 at 1:14 AM, Seth Blank <s...@valimail.com> wrote: > >> The current spec defines an arc authres method ( >> ht

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Wed, May 31, 2017 at 2:11 AM, Barry Leiba wrote: > > Anyone who wants to work on this at the Hackathon, please register > (free) for the hackathon > ... > sooner is better, so we can track who's

Re: [dmarc-ietf] Authentication-Results stamp for ARC

Barry et al, On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: > The current spec defines an arc authres method ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1). > > We believe there should also be registered ptypes and properties, that > should

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote: > This might be a non-issue, but we're asking this question specifically > because we've run into an implementation issue within openarc that feels > weird and seems like a matter the WG may want to weigh in on. > > Our

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Tue, May 30, 2017 at 12:49 AM, Barry Leiba wrote: > We've had one request for a DMARC session in Prague, with no further > response from the working group. > > We've had one suggestion for an interop test in Prague, with no > further response from the working group. >

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

On Fri, May 5, 2017 at 2:30 PM, Seth Blank wrote: > > At the end of an ARC chain, we’re generally left with an i=1 AAR with only > SPF, DKIM, and DMARC pass/fail, and potentially a local_policy report which > says arc=pass|fail. As a domain owner at p=none who wants to get to

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

On Thu, May 4, 2017 at 3:58 PM, Brandon Long wrote: > > The comment is obviously completely unspecified, though maybe some > inferences can be done... though I'm not sure what it's saying myself. > > Are we attempting to dictate the comment? Or is that just an example and > it

Re: [dmarc-ietf] Just posted dmarc-arc-protocol-03 . . .

On Tue, May 2, 2017 at 4:59 PM, Brandon Long <bl...@google.com> wrote: > On Fri, Apr 28, 2017 at 4:04 PM, Kurt Andersen (b) <kb...@drkurt.com> > wrote: > >> Based on the dialog around the AAR header unclarity in section 5.1.3, I >> adjusted the first paragraph

[dmarc-ietf] Just posted dmarc-arc-protocol-03 . . .

Based on the dialog around the AAR header unclarity in section 5.1.3, I adjusted the first paragraph to read: ARC-Authentication-Results is a copy of the Authentication-Results header > field [RFC7601] value with the corresponding ARC-set instance (“i=”) tag > value prefixed to the

Re: [dmarc-ietf] ARC adoption

-dmarc-discuss On Tue, Jun 28, 2016 at 3:09 PM, Steven M Jones wrote: > + dmarc@ietf.org list to capture for ARC discussion/archive > > On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > > > Kurt just mention adoption in his last message. > > Adoption is a good point,

Re: [dmarc-ietf] Meeting in Berlin... or no?

On Fri, Jun 3, 2016 at 3:44 PM, Barry Leiba wrote: > My sense is that we don't need to meet face to face in Berlin. We > have lots of things to discuss on the list, but we're not stuck on > issues that need in-person time. > Agreed. --Kurt

[dmarc-ietf] Other potential work items for the ARC spec

Allessandro Veseley had suggested (on the arc-discuss) list that the semantics and construction of the ARC sets could be defined in a generalized DKIM-like recipe. When I had discussed this with Dave Crocker, he pointed out that such an idea would align with the (never quite finalized) DOSETA (

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely <ves...@tana.it> wrote: > On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote: > > > > What would an AS[0] assertion provide that would not be already asserted > by > > the originator's DKIM-

[dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

Updated the subject line to start a new thread. . .sorry for the confusion. On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) <kb...@drkurt.com> wrote: > On Thu, May 5, 2016 at 6:54 AM, Tim Draegen <t...@eudaemon.net> wrote: > >> The WG will now move ahead t

Re: [dmarc-ietf] phase 1 is done

On Thu, May 5, 2016 at 6:54 AM, Tim Draegen wrote: > The WG will now move ahead to phase 2: > > https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki > > When discussing methods and techniques that address an interoperability > issue, please explicitly reference

Re: [dmarc-ietf] Moving on to our next phase?

On Fri, Apr 1, 2016 at 12:06 PM, Ned Freed <ned.fr...@mrochek.com> wrote: > > > On 1 Apr 2016, at 19:13, Kurt Andersen (b) <kb...@drkurt.com> wrote: > > > > > > Since we've completed the task of identifying the interoperability > problems with some mitiga

[dmarc-ietf] Moving on to our next phase?

Since we've completed the task of identifying the interoperability problems with some mitigations (phase I), is it time for us to move on to our next activity phase? Also, is there some admin-magic that has to happen to move a document from "draft" to "hey! all done!" status? (

Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

On Tue, Mar 15, 2016 at 1:04 PM, Terry Zink wrote: > Office 365 already supports something like this for our customers to cut > down on Business Email Compromise. Maybe 5% of our customers have DMARC > records, yet we treat all inbound email destined to them as

[dmarc-ietf] Are we done with last call on the interop document?

On Mon, Jan 18, 2016 at 11:54 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. Filename: draft-ietf-dmarc-interoperability-14.txt > Pages : 25 > Date: 2016-01-18 >

[dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1)

While revising the interop document, I am adding a note about the situation with multiple domains in a syntactically correct RFC5322.from header (section 6.6.1). The last paragraph of that section reads: > > The case of a syntactically valid multi-valued RFC5322.From field presents > a particular

Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability

On Tue, Dec 8, 2015 at 10:26 AM, Eliot Lear wrote: > > I need a bit more time to review this text, but I want to point out that > one of my main issues was that an example or two that highlights the > fields or the SMTP exchange would be helpful. I am willing to toss > something

Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

On Sat, Nov 7, 2015 at 4:36 PM, Murray S. Kucherawy wrote: > On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin > wrote: > >> While the I-D will likely expires they will not be removed from the >> website, so references will still work, so I don't see as

Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

Removing the editorial fixes which I've incorporated into the recently posted -09, I'm responding inline below to the discussion questions. On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy wrote: > > Section 4.1.3.3: > > - Is that fist bullet talking about things like

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-08.txt

On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy wrote: > Sorry it took me so long to get to this, but here's the review I managed > to crank out on my flight to Tokyo today. It's largely editorial. > Thanks for the notes - I've started folding them into the source XML

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt

Thanks to all who have contributed comments and suggestions. I'll wait until mid-next week to fold them all into the document. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

On May 15, 2015 2:59 PM, Hector Santos hsan...@isdg.net wrote: On May 15, 2015, at 8:09 PM, Terry Zink tz...@exchange.microsoft.com wrote: With all due respect to the amazing abilities of this list to bikeshed, could we try to return this particular thread to the question(s) raised by

<    1   2   3