Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

On Tue, Jun 11, 2019 at 6:31 AM Scott Kitterman wrote: > On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, Scott wrote: > > > > It would be helpful to the reader if the draft were either clear about > > potential limitations to deployment or more descriptive about the domains > > for which the

Re: [dmarc-ietf] DMARC Coverage

On Sun, Apr 14, 2019 at 6:39 AM Dotzero wrote: > Scott, it's almost certainly an undercount as there are domains which > validate for DMARC but do not send reports. > Not sure why you would say that since he was looking at "coverage for DMARC feedback". Not necessarily for validation. --Kurt

Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02

On Thu, Apr 11, 2019 at 7:57 PM Scott Kitterman wrote: > On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote: > > More substantively, in Appendix A, the case is being advanced for > "concerns > > associated with Multi-organization PSDs that do not mandate DMARC usage". > > I'm not sure

Re: [dmarc-ietf] Rethinking DMARC for PSDs

On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > I don't know how to express my shock at today's conversations. One of > the shocks comes from this: > > We have consensus that the better email filters do not need the DMARC for > PSDs standard, because

Re: [dmarc-ietf] Working group next steps

> > On Tue, Mar 26, 2019 at 5:58 PM Murray S. Kucherawy > wrote: > > > > The working group should, in the short term, focus on development and > > completion of draft-ietf-dmarc-psd. Among the questions to be answered > is > > its urgency: If there is pressure to get this finished and published

Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: > On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: > > > > Instead of using the standard "(+)include:" approach, if domain owners > used > > "?include:" as their mechanism, then that would prevent the

[dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

With the growth of huge platforms that emit mail from the same common set of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up granting a DMARC pass to a lot more potential authors than most organizations would necessarily choose to grant. Instead of using the standard

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

On Sat, Jan 26, 2019 at 12:38 PM John Levine wrote: > 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

Re: [dmarc-ietf] [ietf-smtp] ietf-s...@ietf.org and DMARC with p=quarantine; pct=0

This is worthwhile, if aspirational, input to a future phase of the DMARC WG (added to the distro and moving SMTP to BCC). It is, as you observe, not the current state of the spec. One further complication is that relatively few receivers generate forensic report (ruf), in part due to privacy

[dmarc-ietf] Proposing last call for draft-ietf-dmarc-eaiauth-00

Since we've had no controversy or concerns expressed regarding John's document (draft-ietf-dmarc-eaiauth-00 ), do people feel that it is ready for last call? --Kurt ___ dmarc mailing list

Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss...

On Mon, Jan 14, 2019 at 10:43 AM Scott Kitterman wrote: > > Right, but taking it out of 7601bis would leave the problem then of what's > the > appropriate reference in the registry, which, more generally, is how we > got to > the full text replacement of 7601. Leaving it out of 7601bis would

Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss...

On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman wrote: > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > >wrote: > > > >> On Mon, Jan 14, 2019 at 5:03 AM S

Re: [dmarc-ietf] PSD simplification

On Thu, Dec 13, 2018 at 8:09 AM Dave Crocker wrote: > > Let me suggest a much easier hack... > > Require the registry to publish another DNS record, in its _dmarc > node, which a) asserts either than DMARC is required or that the subtree > is part of a single organization, and b) contain

Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work

On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman wrote: > > > On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman > >wrote: > > > >> > >> Since I'm most familiar wit

Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work

On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman wrote: > > Since I'm most familiar with RFC 7208, I took a more detailed look at the > SPF updates. Much of the current text is a restatement of what RFC 7208 > says. I don't know that we need that. The difference is to make explicit > what was

Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

On Fri, Nov 30, 2018 at 1:40 PM Zeke Hendrickson wrote: > > I feel that restricting the additional PSD check to nonexistent > organizational domains is the best approach, I disagree...see below > as it preserves the opt-in nature of DMARC, granted > limits privacy concerns, No - this

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

On Fri, Nov 30, 2018 at 11:00 AM Alexey Melnikov wrote: > Hi all, > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > I actually agree with this: I think the better answer is to go back to > > "obsoletes" and to have this document include the details of what was > > put in the

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

On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: > 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

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

On Wed, Nov 7, 2018 at 9:42 PM Scott Kitterman wrote: > > The registry is meant to be a solution to the 'what about .com' problem > you mention. It's a solution, not necessarily the best or only one. > > I'd suggest we adopt the draft/work item and then try to figure it out. > +1 - this is a

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

On Wed, Nov 7, 2018 at 2:17 AM Alessandro Vesely wrote: > > Can we have a brief discussion on what exactly is the purpose of the I-D? > The intent is to allow the expression of a DMARC policy which would cover non-existent org domains under a "longest public suffix". Right now, there is no way

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

On Tue, Nov 6, 2018 at 4:52 PM Bron Gondwana wrote: > On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote: > > Throwing it in because we were aiming at the "experimental" designation > seemed to be the easiest way to resolve the non-progressing discussion when >

[dmarc-ietf] Changes in draft-ietf-dmarc-arc-protocol-19

This revision (-19) fixes the following issues from the last call: 1. Alexey's comments regarding the normative/informative classification of John's EAI document and 7601bis; 2. An error discovered in the IANA considerations section; and 3. Provides a sample message with ARC in

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

On Mon, Nov 5, 2018 at 3:13 PM Murray S. Kucherawy wrote: > On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman > wrote: > >> Having reviewed the thread that Kurt pointed me to, it seemed like this >> is >> something only one person wanted. It didn't appear to have a lot of push >> behind it. >> >

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

Explicitly looping in that one person to see if his thoughts have changed over time. --Kurt On Mon, Nov 5, 2018 at 12: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

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

On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman wrote: > On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: > > I think that we could possibly already read this into the existing > charter, > > but the following one sentence patch makes it explicit: > > > > diff --git

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

I think that we could possibly already read this into the existing charter, but the following one sentence patch makes it explicit: diff --git a/dmarc-wg-charter b/dmarc-wg-charter index a1d0fac..c8ac6bc 100644 --- a/dmarc-wg-charter +++ b/dmarc-wg-charter @@ -81,6 +81,9 @@ the working group can

Re: [dmarc-ietf] ARC Multi Proposal

On Fri, Nov 2, 2018, 18:09 John R Levine On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> I mean ARC as it's implemented now, not in our multi-signing draft. > > It seems like a poor implementation choice to be enforcing something > which > > is not part of the s

Re: [dmarc-ietf] ARC Multi Proposal

On Fri, Nov 2, 2018 at 5:51 PM John R Levine wrote: > On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> With the current spec, if you have two AMS or AS with the same i= > >> that's invalid, > > > > No, it is not invalid. > > I mean ARC as it's implemen

Re: [dmarc-ietf] ARC Multi Proposal

On Fri, Nov 2, 2018 at 8:56 AM John Levine wrote: > 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

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

On Thu, Oct 25, 2018 at 4:52 AM Alexey Melnikov wrote: > I've reviewed recent changes and they look like an improvement over > earlier versions. I have a few minor comments: > > 1) I think several references need to be reclassified as Normative: > > [I-D-7601bis] >Kucherawy,

Re: [dmarc-ietf] ARC Crypto Algorithm Selection

On Tue, Oct 23, 2018 at 3:58 AM Scott Kitterman wrote: > Last time I looked at this particular issue, ARC could use any algorithm > that > DKIM uses. Still correct. > As I recall, that was once of the stimuli for the DCRUP working > group (to avoid having rsa-sha1 be valid for ARC by

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

On Mon, Aug 20, 2018 at 7:18 PM, John Levine wrote: > In article gmail.com> 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

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

Seth and I discussed this topic today and I think that the central problem that is being debated has to do with *generating* the DMARC report content. Almost everyone agrees that a broken chain is broken and unredeemable - whether that breakage is structural or whether it is because of

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

I'm still at a bit of a loss as to how one can effectively do a "greedy" seal over a broken chain in a deterministic fashion. I'm also not sure why one would report much of anything (back to the hypothetical sending domain) from a broken chain, given that it has no validity. --Kurt On Fri, Aug

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

On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote: > On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote: > >> Sign one" (I think you mean "seal one") remains ambiguous to me, because >> as Seth said, once I see "cv=fail", I don't care about anything else. Now >> I have a seal nobody cares about,

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

On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long < blong=40google@dmarc.ietf.org> wrote: > > Do we actually have consensus on what to do, though? > > The current proposal seems pretty bad, sign one or all depending on vague > things that might be different per impl. > It does not seem to me like

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

On Fri, Aug 3, 2018 at 7:35 AM, Seth Blank wrote: > On Fri, Aug 3, 2018 at 7:25 AM, John Levine wrote: >> >> > 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 >>

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

On Mon, Jul 16, 2018 at 1: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 will be on ARC-16

Ack - look for it before EOW. --Kurt On Mon, Jul 16, 2018 at 1:09 PM, Seth Blank < seth=40valimail@dmarc.ietf.org> wrote: > Excellent, Kurt and I will make sure the notes from the current > discussions are accounted for and publish -16. > > Thank you, Barry. > > On Mon, Jul 16, 2018 at 1:02

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

On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton wrote: > On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: > > 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

Re: [dmarc-ietf] Message sender as part of ARC chain?

On Thu, Jul 12, 2018, 07:38 Martijn van der Lee wrote: > ... would it be beneficial or harmful (or neutral) for the sender to do so > anyway? > > I can imagine validators taking note of ARC capability of an ADMD for > reputation tracking. If an email is send by a sender known to start the ARC >

Re: [dmarc-ietf] Message sender as part of ARC chain?

On Thu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee < martijn=40dmarcanalyzer@dmarc.ietf.org> wrote: > This is more in regards to the Recommended Usage draft than the ARC spec > itself (and possibly this has been answered elsewhere before). > > Is a message sender allowed (or perhaps even

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

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 avoided) because > there are some MTAs that did not follow the specifications before. That > makes me unhappy,

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

On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy wrote: > 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

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

On Tue, Jul 10, 2018 at 10:48 PM, Murray S. Kucherawy wrote: > 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

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

On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton wrote: > On 6/24/18 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.

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

On Wed, Jun 27, 2018 at 12:52 PM, Jeremy Harris wrote: > On 06/25/2018 05:09 PM, Dave Crocker wrote: > > On 6/25/2018 6:03 AM, Jeremy Harris wrote: > >> On 06/25/2018 04:44 PM, Dave Crocker wrote: > >>> If the creator of the information does not have a reliable way of > >>> knowing what the

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

On Mon, Jun 25, 2018 at 8:16 AM, Jeremy Harris wrote: > On 06/25/2018 04:10 PM, Kurt Andersen (b) wrote: > >>+ this (new?) requirement to check on h-tags for > >> AS mean that a common parse routine for the three > >> header types cannot be us

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

On Tue, Apr 24, 2018 at 2:54 PM, Jeremy Harris <j...@wizmail.org> wrote: > On 24/04/18 22:45, Kurt Andersen (b) wrote: > > On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris <j...@wizmail.org> wrote: > > > >> On 24/04/18 04:02, internet-dra...@ietf.org wrote: >

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

On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris wrote: > On 24/04/18 04:02, internet-dra...@ietf.org wrote: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 > > Section 3.3: > For AMS generation, what is the intention regarding oversigning? > Can you

[dmarc-ietf] Resolving issue #9 (clarify conditions under which to sign and what is being asserted)

https://trac.ietf.org/trac/dmarc/ticket/9 Per my comment on the ticket, I think that this has now been addressed with the updates done in version -13 (primarily the overview in section 1.1: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#section-1.1) Any objections to closing this

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

On Tue, Apr 10, 2018 at 1:44 PM, John Levine wrote: > In article <91efb193-9a81-4626-92ca-bf116826f...@uniregistry.link> you > write: > > This is the relevant text from > >https://newgtlds.icann.org/sites/default/files/ > agreements/agreement-approved-31jul17-en.html > > But

Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0

On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long <bl...@google.com> wrote: > > On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) <kb...@drkurt.com> wrote: > >> *I filed issue 22 after observing a discussion today on another list:* >> >> Pursuant to an email

[dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0

*I filed issue 22 after observing a discussion today on another list:* Pursuant to an email thread on the mailop list, we may want to consider how (or if) to do something about the ways that people have developed different processing handling for p=none vs. p!=none. Here's the example: Does

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

On Thu, Apr 5, 2018 at 1:06 PM, Luis E. Muñoz wrote: > On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote: > > 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

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

On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein < peter.m.goldst...@gmail.com> wrote: > Hi, > > These are both a species of the same problem, yes. The solution so >> far has been to say that you're supposed to match the longest of the >> candidate set... > > > Right. And the suggestion that

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

On Wed, Apr 4, 2018 at 3:32 PM, Brandon Long wrote: > Hmm, I guess this means the set of required/optional fields now stretches > between the DKIM and ARC specs, eh? > > Is t the only one that's now optional? > > For Seal, I have i, a, s, d, b, cv (removed t based on this

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

On Wed, Apr 4, 2018 at 11:19 AM, Peter M. Goldstein < peter.m.goldst...@gmail.com> wrote: > Kurt, > > As you note, this issue has been discussed on-list (and off) a few times. > And it definitely seems clear that some sort of modification to the lookup > algorithm would be required to address the

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

Apologies for the top-posting, but this is exactly the scenario that has been discussed earlier on the list: https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html as well as during the recent IETF101 meeting: https://datatracker.ietf.org/doc/minutes-101-dmarc/ The problem really is

Re: [dmarc-ietf] Strange dmarc lookups

Looks like an abuse campaign doing what it can to mask sending from something like a direct IP based address like @[w.x.y.z] - in this case the IP is reportedly in Madrid. --Kurt On Mon, Mar 26, 2018 at 1:13 PM, John R. Levine wrote: > A friend looking at DNS traces says he's

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

On Fri, Mar 23, 2018, 14:07 Ned Freed <ned.fr...@mrochek.com> wrote: > WFM. > > Ned > > > On Thu, Mar 22, 2018 at 4:08 PM, Ned Freed <ned.fr...@mrochek.com> > wrote: > > > > On 3/22/2018 7:49 AM, Kurt Andersen (b) wr

[dmarc-ietf] Moving RFC4406 to historic?

I just noticed (when reviewing the latest 7601bis version) that Sender-ID was never officially deprecated, i.e., moved to "historic" status. That probably should have been done as part of the SPFbis work. For the sake of people browsing the IETF RFCs, what would it take to make 4406 historic?

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

On Thu, Mar 22, 2018 at 11:47 AM, John Levine wrote: > In article vmm...@mail.gmail.com> you write: > >This includes a registration for "header.a" and John's changes to support > >EAI. However, Barry has some concerns with how

[dmarc-ietf] Resolving issue #8 (spec is too DMARC-heavy)

I'd suggest that -13 has mitigated this issue by replacing many of the "DMARC" mentions with a more generic "email authentication mechanism" phrase. I recommend that we close this issue. Any objections? --Kurt ___ dmarc mailing list dmarc@ietf.org

[dmarc-ietf] arc-protocol-13 info

On Wed, Mar 21, 2018 at 3:00 PM, wrote: > > Title: Authenticated Received Chain (ARC) Protocol > Filename : draft-ietf-dmarc-arc-protocol-13.txt > Date : 2018-03-21 > > The IETF datatracker status page for this draft is: >

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

On Wed, Mar 21, 2018 at 12:44 PM, Murray S. Kucherawy wrote: > 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

Re: [dmarc-ietf] [Request] Presentation in IETF101

On Mon, Mar 19, 2018 at 7:14 PM, Steven M Jones wrote: > I want to thank Yasutaka san for presenting the Virtual DMARC proposal. I > believe the situation he and his colleagues are addressing would benefit > from more attention. > > Aside from changes to the "dmarc=" allowed

Re: [dmarc-ietf] Fwd: DMARC report format syntax error in ARC draft-10 section 9.3

On Sun, Mar 18, 2018 at 6:54 PM, Peter M. Goldstein < peter.m.goldst...@gmail.com> wrote: > Kurt, > > Re: -12, it doesn't appear to capture the feedback in the email Mark > Eissler sent to the list on 2/27. There was also no on-list reply to his > email that I saw, so I wanted to re-raise the

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

This version incorporates various fixes suggested by people since -11. There are a collection of (mostly minor) open issues now logged into the issue tracker (

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

Dr Ian Levy > > Technical Director > > National Cyber Security Centre > > > > Staff Officer : Kate Atkins, kat...@ncsc.gov.uk > > > > *From:* dmarc <dmarc-boun...@ietf.org> *On Behalf Of *Kurt Andersen (b) > *Sent:* 17 March 2018 09:41 > *To:* S

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones <s...@crash.com> wrote: > On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: > > >- Creating a diagnostic report that would have some additional >information (such as sending address) and URLs without going quite as far >

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

Two more items for discussion (coming from a chat that I had with some of the NCSC folks today): 1. Recommendations for protecting against abuse of last-level public domains (such as gov.uk) and first-level NXDOMAIN org domains ( junk.gov.uk) 2. Creating a diagnostic report that would

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

Seems like we might want to discuss specific steps toward the next milestone per our charter. I think that ARC is a method of "support[ing] indirect mail flows" but we haven't even discussed the other brainstorm ideas that were tossed into the charter (listed below). Are all of these items

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

On Mon, Jan 29, 2018 at 7:51 AM, Hector Santos wrote: > > I believe the intent of the domain is his published policy record. If a > restrictive policy is published, the receiver should not presume it did not > mean it. When failure is detected, the author domain with a

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

On Wed, Feb 7, 2018 at 9:53 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) <kb...@drkurt.com> > wrote: > >> On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba <barryle...@computer.org> >> wrote: >

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

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 work lands in a form that > can > > be referenced by the protocol spec. > > > > Ideally

[dmarc-ietf] DMARC-WG F2F @ IETF101

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 work lands in a form that can be referenced by the protocol spec. Ideally we could launch WGLC for the ARC protocol before the end of February. IETF101 would be a great

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

On Wednesday, January 24, 2018, Jeremy Harris wrote: > > Section 5.3 defines the AMS as being identical, with exceptions, > to a DKIM signature header. This might be taken to mean that the > header name is "DKIM-Signature"; clarification would help, > either by giving the

[dmarc-ietf] New versions of the drafts submitted today (1/22)

I submitted new versions with the following highlights: - usage-04: moves the "efficacy" section out of the usage document - protocol-11: - Changes status to "experimental", - adds in the "efficacy" section and - a variety of other notes are incorporated from the last

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

On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker wrote: > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: > >> -01 will be up soon, incorporating the suggested changes in prose and >> ABNF discussed previously on this list. >> > > > If I missed this, I apologize, but would it

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

On Fri, Jan 5, 2018 at 6:52 AM, Bron Gondwana wrote: > Instance number please. Less calculation. > Agreed. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

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 that's clearer. Your case: > > * ARC 1: cv=none, ams.oldest-pass=0 > * ARC 2: cv=pass,

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

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 . . . > I'm uncomfortable with the terminology implied by the term

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

On Wed, Jan 3, 2018 at 8:04 AM, Seth Blank wrote: > > . . .for me "experimental" comes from the fact that there are several open > issues on which there has been lasting discussion within this group with no > resolution that data from an experiment will quickly shine light

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

On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana <br...@fastmailteam.com> wrote: > On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > > As I went through the edits for https://tools.ietf.org/htm > l/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to > under

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

On Tue, Jan 2, 2018 at 7:38 PM, John R. Levine wrote: > I don't see the point of the header.ds field. We already have header.d, > so why not just add header.s? > Yes, quite so. Please see my note from earlier this morning. header.s is already defined for 7601, we just need to

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

On Fri, Dec 29, 2017 at 6:36 PM, John R Levine wrote: > I still don't understand why we need to say more than DKIM did on this >> topic. > > > I don't think this will be super complicated, but I do think it would be a > mistake to try and publish now and then retrofit rather

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

On Fri, Dec 29, 2017 at 1:23 AM, Seth Blank wrote: > The Implementation Status section of the draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-14) > feels out of date. > Yes - I forgot to update that in the -10 version. I've added in information

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

On Fri, Dec 29, 2017 at 12:15 AM, Seth Blank wrote: > I'm beginning a new thread to explicitly address some differences of > opinion in the working group. > > Coming out of IETF99 and surrounding working group conversations ( >

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

On Thu, Dec 21, 2017 at 5:29 PM, Brandon Long wrote: > > > . . .when arc was on standards track, but now that it's experimental . . . > It's not experimental - that was a proposal in Prague when we were considering pushing for WGLC before Singapore. Since we are continuing to

Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains

On Wed, Dec 20, 2017 at 8:29 AM, Ian Levy wrote: > > I need to be able to emulate in some way the effect of SPF and DMARC > records for non-existent first level subdomains under the PSL gov.uk - to > stop spoof mail apparently coming from them being delivered. This is an >

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

I've just posted new drafts of both the protocol and usage documents: Name: draft-ietf-dmarc-arc-protocol Revision: 10 Title: Authenticated Received Chain (ARC) Protocol Document date: 2017-12-19 Group: dmarc Pages: 49 URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-10.txt

Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains

On Mon, Dec 18, 2017 at 2:46 PM, Ian Levy wrote: > > > . . .As part of the UK Government’s Active Cyber Defence programme, we’re > trying to get DMARC across all public facing brands in the UK, starting > with all public sector domains. We’ve found a couple of interesting

[dmarc-ietf] Preventing abuse of public-suffix-level domains

I know that there had been some very preliminary thoughts about protecting the PSL domains themselves, but those never got very far (they were in the context of the DBOUND WG). I've heard from one of my contacts that country-level TLDs like gov.za are being used for attacks and that there is not

Re: [dmarc-ietf] SHA1 and short keys, threat or menace

On Wed, Dec 13, 2017 at 7:57 PM, Peter M. Goldstein < peter.m.goldst...@gmail.com> wrote: > Great. If there's group consensus I can take updating the test suite as > an action item. Any objections? > Make it so :-) ___ dmarc mailing list

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

On Fri, Dec 1, 2017 at 7:55 PM, Murray S. Kucherawy wrote: > 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

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

On Fri, Dec 1, 2017 at 7:38 AM, Murray S. Kucherawy wrote: > . . . Or if we really want it in A-R, register it accordingly, independent > of ARC. > > But if we want to do that last thing, I'd like to have some sort of > discussion on the record for changing the scope of A-R,

Re: [dmarc-ietf] Proposed ARC "Protocol Elements" section

On Thu, Nov 23, 2017 at 2:18 AM, Seth Blank wrote: > All- there has been back and forth about the current draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing > context for a new reader to understand the purpose of ARC and how the > components fit

Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

On Fri, Nov 3, 2017 at 8:01 AM, Murray S. Kucherawy wrote: > On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba > wrote: > >> We also need to understand whether there's really anything we intend >> to do with DMARC. Do we *know* what we might do? Do we

Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100

On Wed, Nov 1, 2017 at 5:02 PM, Hector Santos wrote: > You should at least have a meeting to decide what you are going to do with > DMARC. It should be turned into a Proposed Standard. This is on the roadmap charter for the working group but we are not yet to the point of

<    1   2   3   >