Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt

I'll initiate WGLC before the weekend. I have some feedback from outside the WG that I will forward, but it's not serious enough to block starting WGLC. On Tue, May 28, 2019 at 5:17 AM Craig Schwartz wrote: > I've reviewed the draft. We plan to implement this as soon as possible > (for .bank

Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records?

On Wed, Apr 10, 2019 at 12:37 PM Dave Crocker wrote: > For the software you know about, how are queries to the DNS performed, > to obtain the TXT records associated with DKIM and/or DMARC? > By default, libopendkim and libopendmarc use the standard C library functions (i.e., res_*()) to do

Re: [dmarc-ietf] Rethinking DMARC for PSDs

On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > Scott, you misunderstand what this type of standard would look like. It > would defines Use Cases that the device should address, with some > acknowledgement to the tradeoffs between perceived risk and

[dmarc-ietf] Fwd: [dbound] Related Domains By DNS (RDBD) Draft

Of possible interest to this working group... -- Forwarded message - From: Brotman, Alexander Date: Mon, Feb 25, 2019 at 9:38 PM Subject: [dbound] Related Domains By DNS (RDBD) Draft To: a...@ietf.org , dbo...@ietf.org Cc: dn...@ietf.org , Stephen Farrell <

[dmarc-ietf] Working group next steps

DMARC colleagues, Tim and I met in Prague to get things rolling in terms of getting us progressing again toward our remaining deliverables. Producing a DMARC on the standards track is the endgame for us. We're keen to identify and focus on work that is in direct service of that goal; anything

Re: [dmarc-ietf] Post-IESG Review edits to RFC7601bis

On Tue, Jan 22, 2019 at 12:09 PM Scott Kitterman wrote: > According to the rules of the registry (as described in RFC 7601), a > designated expert can change entries to deprecated without a specification. > True, but that's not the only change here. Not carrying deprecated entries into 7601bis

Re: [dmarc-ietf] Fwd: Proposed charter spiff to accept EAI clarification within email authentication stack

I'm pretty sure charter adjustments are independent of WGLC (which is to say don't hold up one with the other). -MSK On Tue, Jan 22, 2019 at 10:09 AM Seth Blank wrote: > Scott, does this need to be addressed during WGLC for draft-levine-eaiauth? > > -- Forwarded message - >

[dmarc-ietf] Post-IESG Review edits to RFC7601bis

With the posting of -05, we expect the last DISCUSSes to clear (one already has) and the document can proceed. During DISCUSS discussions, it was pointed out that the ADSP, Sender ID, and DomainKeys specifications bear "Historic" status, and thus they should not be carried forward into the new

Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

On Sun, Jan 6, 2019 at 2:27 AM Scott Kitterman wrote: > Hunk at "page 17, line 44": > > Perhaps another sentence (more for completeness than anything) at the end > of > the new paragraph. Something like, "Additionally, [RFC8463] added a new > signing algorithm in DKIM, ed25519-sha256 and it is

Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

On Sun, Jan 6, 2019 at 12:27 PM Benjamin Kaduk wrote: > > Section 2.3 > > > > > >body: Information that was extracted from the body of the message. > > > [...] > > > interest. The "property" is an indication of where within the > > > message body the extracted content was

Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

Here's what I've come up with. This is a diff between RFC7601 as published and what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IESG review. Please let me know if I've missed anything. I'll post it at the end of the coming week if there are no issues

Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

Hi Eric, thanks for your comments and sorry for the delay in replying. I've applied all of your comments except those below, for discussion: On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla wrote: > > IMPORTANT > S 7.10. > > processing of these is outside of the intended scope of this >

Re: [dmarc-ietf] Alvaro Retana's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

On Tue, Nov 20, 2018 at 9:03 AM Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-dmarc-rfc7601bis-04: No Objection > > -- > COMMENT: >

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

On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: > > > and maybe it can solve the "PSL problem" if we can constrain the problem > > space to just the DMARC issues instead of recreating the > > DBOUND-solve-for-all morass. > > This problem is simpler than DBOUND. Looking up text policies

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

On Wed, Nov 7, 2018 at 11:54 AM Scott Kitterman wrote: > My estimation is that this would change very rarely. If I were developing > software for this, I'd probably check at build time and use that unless > there > are some reason to update. Not that people won't try, but I think not > very >

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

On Wed, Nov 7, 2018 at 10:08 AM Murray S. Kucherawy wrote: > My concern with this approach (which doesn't rise to the level of > objecting to its application as a WG document, though perhaps it should) is > that it is trending toward needing an IANA registry to be queryable in > real

Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...)

On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman wrote: > I don't think it's something we should delay on. In my, admittedly > limited, > experience with these things, once something is in an experimental version > of > an RFC, then it 'has' to be preserved in the name of interoperability with >

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

No objection. I've already got opinions ready to go when it gets accepted. :-) On Mon, Nov 5, 2018 at 3:23 PM Barry Leiba wrote: > > 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

Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...)

Given the intended status is Experimental, is this something that's a showstopper? We have the debate about "fail" versus "invalid" that I believe we consider to be a showstopper for Proposed Standard, but we're willing to let slide for Experimental. Is this the same? -MSK On Mon, Nov 5, 2018

Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack

I proposed adding this right above "Work Items" (it accomplishes the same thing): 4. Incidental related work Any issues related to the email authentication space that are large enough to mandate working group review but do not already fit under the charter of an existing working group can be

Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03

On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef wrote: > Section 7.2. Misleading Results, Second paragraph >>> >>>"Hence, MUAs and downstream filters must take some care with use of >>>this header even after possibly malicious headers are scrubbed." >>> >>> How do you expect an MUA or

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt

On Sat, Nov 3, 2018 at 12:44 PM Scott Kitterman wrote: > >Sorry, what's being deleted? RFC7601bis doesn't (shouldn't!) be > >deleting > >anything; it adds a couple of entries and makes itself authoritative > >for > >the registration of the header field, but otherwise nothing is > >changing. I

Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03

On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef wrote: > Section 7.1. Forged Header Fields > > In addition to a recommended solution, this section has list a potential > alternative solutions which the document then states that it is not > appropriate > for this document to specify which

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt

On Thu, Oct 25, 2018 at 8:03 PM Alexey Melnikov wrote: > 1) I am not sure that deleted IANA registry descriptions (when compared > to RFC 7601) is the best way, considering that this document obsoletes > RFC 7601. I think it would be better to just keep the text and add a > sentence saying that

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

On Sat, Oct 27, 2018 at 7:44 AM John Levine wrote: > In article a...@mail.gmail.com> 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.

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

On Thu, Oct 25, 2018 at 8:15 AM Kurt Andersen (b) wrote: > > Both of these are indeed normative in usage, but I was under the > impression that one could not refer to I-Ds as normative. > At least 7601bis will be an RFC at the same time as this one is, if not sooner. I don't know what the

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

: Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename: draft-ietf-dmarc-rfc7601bis-03.txt > Pages : 48 > Date: 2018-08-22 > > Abstract: >This

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

(back from vacation and catching up) On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank wrote: > There are THREE consumers of ARC data (forgive me for the names, they're > less specific than I'd like): > > 1) The ARC Validator. When the Validator sees a cv=fail, processing stops, > the chain is dead,

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

To the rest of the WG: Is there consensus to make this change or the others being proposed? 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

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

On Tue, Jul 31, 2018 at 4:09 AM, Alessandro Vesely wrote: > > Do you have a suggestion for alternative text? > > Say: > > 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

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

On Mon, Jul 30, 2018 at 8:40 AM, John R Levine wrote: > In authentication service identifiers in EAI-formatted messages, a U-label > and its equivalent A-label are considered to be the same. > > Does that mean the proposed change is appropriate, or the current text is >> sufficient?

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

On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely wrote: > On Sun 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote: > > > So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis- > 02. > > > > Please review the latest version: > >

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

On Sun, Jul 29, 2018 at 5:13 PM, John Levine wrote: > 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

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

On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank wrote: > On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy > wrote: >> >> But (and I think this proves my point) I don't know if "cv=fail" refers >> to an invalid chain or a failed chain. I have to run the

Re: [dmarc-ietf] ARC-16 signature domains

On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote: > 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 >

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

On Fri, Jul 27, 2018 at 10:29 AM, Seth Blank wrote: > On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy > wrote: > >> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote: >> >>> The verification algorithm is straightforward. If you receive a chain >&g

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

On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote: > The verification algorithm is straightforward. If you receive a chain that > ends with cv=fail stop your evaluation, you’re done. There’s no separate > validation path here. > Then why bother signing anything when you affix "cv=fail"? -MSK

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

On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine wrote: > > Ah. I still think it should go, but if you really want to do that, invent > a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more > like corrupt S/MIME bodies. > > I did a bunch of these (for DKIM and SPF at least)

Re: [dmarc-ietf] Sort of erratum on RFC 7601 for 7601bis

Applied for RFC7601bis. I'll post a new version when WGLC ends. On Sun, Jul 22, 2018 at 7:07 PM, John R Levine wrote: > An erratum on RFC7601 just appeared that reports a bug in the ABNF for the > resinfo rule. I think the purported bug is not a bug but his suggested > rewrite to the ABNF is

Re: [dmarc-ietf] Approval of draft-ietf-dmarc-arc-protocol-16

On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana wrote: > This isn't a detailed review, because I haven't had time to do it, but > I've been following the process and I'm happy that ARC-16 is ready as an > experimental standard. > What's an "experimental standard"? -MSK

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

On Wed, Jul 18, 2018 at 1:37 PM, Seth Blank wrote: > > >> My review of -14 noted problems with the abstract. While there have been >> some changes, the Abstract remains too... abstract. While the current text >> is better it really does not provide simple, direct statements about the >>

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

On Tue, Jul 17, 2018 at 10:49 AM, John Levine wrote: > Try this: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc- > rfc7601bis-02=rfc7601 > > Looks OK to me. I have some minor editorial niggles about the wording > of the EAI advice, but the substance is fine. > > [re-adding

Re: [dmarc-ietf] WGLC will be on ARC-16

On Mon, Jul 16, 2018 at 4:02 PM, Barry Leiba wrote: > We have a good set of comments on -15, and thanks, everyone, for that. > Kurt and Seth, please make the changes that make sense based on the > discussion, and publish -16 when you've done that. When I see -16 go > up, I'll put it into

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

On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank wrote: > I've reviewed. All the technical matters look good, and earlier comments > have all been addressed. I have two final comments: > > 1) Section 6.4 mentions changes to section 2.3 which include slightly > different language than in 7601. I see

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

On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton wrote: > > I suggest that as part of WG Last Call that the DNS Directorate be > consulted, largely to socialize this with them so they aren't surprised by > the request load requirements. > Should the draft say more than what Section 9.2 already says?

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

On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton wrote: > On 7/11/18 6:23 PM, Kurt Andersen (b) wrote: > > On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton > wrote: > >> >> So essentially we're creating a bunch of header bloat (creating duplicate >> header fields with different names where that could be

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

or can we WGLC it? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < martijn=40dmarcanalyzer@dmarc.ietf.org> wrote: > In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states > to include the ARC Set currently being added. > However, the signature cannot include the current ARC-Seal

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

On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton wrote: > On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > > > AMS is basically the same as DKIM-Signature, and so it covers body > modifications. When you verify the seal, you must also verify the latest > AMS, which in t

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

On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton wrote: > On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: > > On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton > wrote: > >> Substantive issues: >> >> General: I see lots of references to "authentication state", beginning >> with two references in the abstract,

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

On Sun, Jun 24, 2018 at 9:27 PM, Kurt Andersen wrote: > I've now posted draft 15 of the ARC protocol. It should be ready for last > call - please review with that in mind. Note that the XML was a little > wacky in the Implementation Status section. I'll fix that formatting in the > next rev. >

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

On Mon, Jun 25, 2018 at 9:03 AM, Jeremy Harris wrote: > "any tag not specified here, in any of the three ARC headers, > MUST be ignored". In my view this is the right approach, but keep in mind that what's valid in an AMS header field value is largely defined by what's valid in DKIM, and

Re: [dmarc-ietf] [ietf-smtp] Moving RFC4406 to historic?

On Fri, Mar 23, 2018 at 2:05 PM, Ned Freed wrote: > WFM. +1 -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [ietf-smtp] Moving RFC4406 to historic?

On Fri, Mar 23, 2018 at 12:40 PM, Alexey Melnikov wrote: > On 23 Mar 2018, at 12:27, John R. Levine wrote: > >> I have now posted > >> https://tools.ietf.org/html/draft-andersen-historic-4406-etal-00 for > this > >> task. > >> > >> Please let me know

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

On Wed, Mar 21, 2018 at 2:20 PM, Kurt Andersen (b) wrote: > In the diff I sent in, I also proposed header.s (selector). I think that's > >> important for troubleshooting. Is there a reason you left it out? I can >>> do >>> another draft for it, if you want, but it seems like

Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

On Wed, Mar 21, 2018 at 3:00 PM, wrote: > A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt > has been successfully submitted by Kurt Andersen and posted to the > IETF repository. > > Name: draft-ietf-dmarc-arc-protocol > Revision: 13 > Title:

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

On Tue, Mar 20, 2018 at 10:50 PM, Scott Kitterman wrote: > In the diff I sent in, I also proposed header.s (selector). I think that's > important for troubleshooting. Is there a reason you left it out? I can > do > another draft for it, if you want, but it seems like a

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

ETF. > > Title : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename: draft-ietf-dmarc-rfc7601bis-01.txt > Pages : 48 > Date: 2018-03-20 > >

Re: [dmarc-ietf] OT: Yet another addition to dmarc-rfc7601bis-00

On Mon, Mar 19, 2018 at 5:29 PM, Alessandro Vesely <ves...@tana.it> wrote: > On Sun 18/Mar/2018 13:43:56 +0100 Murray S. Kucherawy wrote: > > On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely <ves...@tana.it > > <mailto:ves...@tana.it>> wrote: > > > &g

Re: [dmarc-ietf] OT: Yet another addition to dmarc-rfc7601bis-00

On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely wrote: > Would it be possible to insert a dnswl method in the new spec? > [...] > I'd prefer to do this as its own document. The current one is feeling very "kitchen sink" already, and this change has more meat to it than the

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

On Mon, Feb 19, 2018 at 2:28 PM, Scott Kitterman wrote: > > 7601bis loosens the language about what's appropriate to send downstream, > > from being only authenticated identifiers to also allowing other related > > stuff that downstream agents might want to use or log.

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

On Sat, Feb 17, 2018 at 3:49 AM, John Levine wrote: > Seems fine, although I've long found 7601 one of the most mysterious RFCs > ever published. > Why's that? (And why wasn't this mentioned when 7601 or any of its antecedents was in last call? No errata?) > The IANA

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

On Sat, Feb 10, 2018 at 10:40 AM, John R. Levine wrote: > Here's some stuff from my EAI authentication draft which it would be nice > if you could fold in. > [...] Is this stuff in scope for this working group? This feels a bit like feature creep. Or should your draft just

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

e IETF. > > Title : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename: draft-ietf-dmarc-rfc7601bis-00.txt > Pages : 48 > Date: 2018-02-07 > &

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

On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) wrote: > On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba > wrote: > >> > I'd like to request a F2F meeting in London at IETF101. I plan to >> create a >> > WGLC-eligible draft as soon as the 7601bis-01

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

On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen wrote: > That is our plan. The change to 7601 is to segment the ABNF for clearer > extension by ARC. Wait and see what Murray puts in and then we can discuss. > > On Jan 20, 2018 09:18, "Hector Santos" wrote: >

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

ubject: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt To: "Murray S. Kucherawy" <superu...@gmail.com> A new version of I-D, draft-kucherawy-dmarc-rfc7601bis-00.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name:

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

On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) wrote: > On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana > wrote: > >> I assume this was the one that you wanted my clarification on? >> > > Yes, thanks > > >> But let's rewrite it as oldest-pass, because

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

On Wed, Jan 3, 2018 at 5:50 PM, Kurt Andersen (b) wrote: > While I wait for Bron's confirmation that my understanding matches his > (see email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank < > s...@sethblank.com> wrote: > >> >> . . .text for . . . arc.closest-fail

Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) wrote: > While John Levine cited the benefits of the "experimental" approach taken > for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/ > gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play > nice" mess

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

On Thu, Dec 28, 2017 at 7:57 PM, John Levine wrote: > In article

Re: [dmarc-ietf] ARC draft: Call for ARC Implementations to be included

The second bullet on 14.4 can go. The third one can go once a new version of OpenDMARC is out, which can happen in early January. On Thu, Dec 28, 2017 at 5:23 PM, Seth Blank wrote: > The Implementation Status section of the draft ( >

Re: [dmarc-ietf] ARC draft-10 Security Considerations - questions and request

On Thu, Dec 28, 2017 at 5:21 PM, Seth Blank wrote: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-13 > > Beyond my notes below, the Security Considerations section feels weak, and > like it should at least inherit DKIM's security considerations. >

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

On Fri, Dec 22, 2017 at 9:37 AM, John Levine wrote: > In article x0hj...@mail.gmail.com> you write: > >"Experimental" is perfectly fine. As I understand it, EAI did that first > >and went to the standards track after it had some

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

On Thu, Dec 21, 2017 at 3:18 PM, Seth Blank wrote: > That is also what I remember, and why I proposed the Experimental > Considerstions as part of the primary draft and not the usage guide. > > Kurt had some strong opinions on why they belonged in the usage guide, > which I

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

On Wed, Dec 20, 2017 at 4:39 PM, Brandon Long wrote: > I think algorithm rotation is more challenging for ARC than it is for > DKIM, since with DKIM you can just sign with both... but for ARC, there's a > chain of signers and the you have to handle links not being able to

[dmarc-ietf] OpenARC v0.1.0 available

There's now an open source implementation of ARC available for download if anyone wants to try practice rather than theory, and you can be an integral part of the experiment. Here's the release announcement. -- The Trusted Domain Project is pleased to announce the availability of the first

Re: [dmarc-ietf] Proposal to invoke a 7601bis effort

On Fri, Dec 1, 2017 at 3:23 PM, Scott Kitterman wrote: > > Isn't Dispatch ( https://datatracker.ietf.org/wg/dispatch/about/ ) the > proper > venue to discuss this (as the successor to appswg)? > No; "art" is the right list for general ART area topics. DISPATCH is the

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

On Fri, Dec 1, 2017 at 11:52 AM, Dave Crocker wrote: > The more-difficult question is what the basis of analysis should be? An > inherent problem with "in this working group" or the like is just how small > a sampling of the email industry it is. It makes it too easy for

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

On Fri, Dec 1, 2017 at 10:09 AM, Kurt Andersen (b) wrote: > > Where would you like to gather such a consensus? Is this DMARC-WG > sufficient or would you want input from a wider community? > Here's fine. Or the ART list, or ietf-822. Or really, anywhere the IETF considers

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank wrote: > Replace 5.1.1 with: > > 5.1.1. ptypes and properties for arc-info > > Certain information pertinent to ascertaining message disposition can be > lost in transit when messages are handled by intermediaries. For example, >

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

On Wed, Nov 29, 2017 at 9:17 AM, Kurt Andersen (b) wrote: > While I have a number of issues with the details of the proposal, I'll > tackle those in another thread. The fundamental problem that I have with > the whole "experiment" approach is that it is something like throwing

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

On Thu, Sep 7, 2017 at 10:11 AM, Seth Blank wrote: > I'll go over this in more detail and post substantive comments sometime in > the next day or so, but at first glance, a crucial change in 5.1 was missed > and the draft language still makes a normative change to 7601 ("data

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

On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana <br...@fastmailteam.com> wrote: > On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote: > > On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long <bl...@fiction.net> wrote: > > We went down the path of including a diff of

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

On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote: > We went down the path of including a diff of the message in the headers, > but you run up against more complicated changes that make that > challenging. Ie, mailing lists which strip attachments. If all we cared > about

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

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker wrote: > On 8/18/2017 10:00 AM, Seth Blank wrote: > >> >> Right now, we've got deployed code that we know works and improves the >> landscape. Everything else is - rightly or wrongly - conjecture. >> > > > Personal Point of

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

On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank wrote: > On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana > wrote: >> >> I laugh as well, but it's more than p=reject isn't enough in the ARC >> world, because it doesn't distinguish between: >> a) I'm OK

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

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <br...@fastmailteam.com> wrote: > On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: > > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <br...@fastmailteam.com> > wrote: > > While there exists A SINGLE SITE wh

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

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > Goodness,

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

On Tue, Jul 25, 2017 at 10:00 AM, Alexey Melnikov wrote: > I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so > some of the issues identified below might no longer be relevant: > > 1) The new abstract doesn't even use the word "email". This needs to be >

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen wrote: > > I don't understand. Mediators ARC sign, the header is everything you need >> for this identification, is it not? >> > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the

Re: [dmarc-ietf] Agenda for IETF99 F2F

Status reports are great list material. I don't think it's useful for mic time. Unless something specific about OpenARC is germane to the draft(s), I feel we have plenty of other stuff to discuss during face time. On Sun, Jul 16, 2017 at 9:51 AM, Barry Leiba wrote: >

Re: [dmarc-ietf] [arc-discuss] openarc defer messages

On Sat, Jul 15, 2017 at 2:43 AM, Kurt Andersen wrote: > On Sat, Jul 15, 2017 at 11:28 AM, Juri Haberland > wrote: > >> On 15.07.2017 10:33, Kurt Andersen wrote: >> >> > But if the parsing fails, then it was hanging and causing message >> deferral, >> >

Re: [dmarc-ietf] Agenda for IETF99 F2F

Why is OpenARC's status an IETF agenda item? On Sat, Jul 15, 2017 at 12:46 AM, Kurt Andersen wrote: > If there are any missing items, please let us know as early as you can. > Here's the proposed agenda: https://datatracker. > ietf.org/meeting/99/agenda/dmarc/ > > --Kurt > >

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

On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) wrote: > > 1) Include the additional information in the AAR which is wanted > downstream for a DMARC report to be emitted from a receiver N hops away - > this requires additional fields to the basic RFC7601 A-R spec > This

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

On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) wrote: > Regarding timelines, I think that we can have wishes and hopes, but, since > we will now be holding our seventh(!) interop event during the IETF99 > hackathon, I don't expect that "months" is even the right scale upon

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

On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <s...@sethblank.com> wrote: > On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy <superu...@gmail.com> > wrote: > >> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank <s...@sethblank.com> wrote: >> >>> Or may

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

On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker wrote: > 2. The mechanics of cascading signatures that ARC does /is/ unusual > and possibly unique. I believe the only operationally established exemplar > in this space is the X.509 cert signature hierarchy. However it is an

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

On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker wrote: > I've come to believe that it makes more sense, at this stage, to seek a > status of Experimental. That's not meant as a criticism of the work, but > rather to accurately reflect the current understanding of ARC dynamics.

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

On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan wrote: > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. I think that is aligned with (but not entailed by) >

<    1   2   3   4   5   6   7   8   9   >