Re: [dmarc-ietf] Info - DMARC at WEB.DE, GMX, mail.com coming soon

On Mar 9, 2021, at 11:38 AM, Arne Allisat wrote: > >  Just a short info to whom it might interest: > > Very soon, we will go live with DMARC check on incoming mails for all > mailboxes operated by WEB.DE, GMX & mail.com. > That covers several hundreds of recipient domains [1] and roughly 50% o

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy wrote: > > On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely > wrote: > I am wondering whether companies like Dmarcian could implement third-pary > whitelisting. As they receive and analyze DMARC aggregate reports on beh

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

> On May 27, 2019, at 6:59 PM, Scott Kitterman wrote: > > On Monday, May 27, 2019 6:53:17 PM EDT internet-dra...@ietf.org 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

Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports

> On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy wrote: > > On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov > wrote: > Shall I submit an erratum to RFC7489? > > I would, yes. And this should certainly be recorded as something we need to > fix for standards

Re: [dmarc-ietf] DMARCbis issue: Reporting URIs

> On May 27, 2019, at 3:32 PM, John Levine wrote: > > 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

Re: [dmarc-ietf] DMARCbis issue: failure report mail loops

> On May 27, 2019, at 3:22 PM, John Levine wrote: > > Apropos recent discussions, we could recommend that failure reports be > rate limited per recipient both to break loops and to deter indirect > mail bombing. Hi John et al, I've added this suggestion to the tracker: https://trac.ietf.org/t

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

> On May 30, 2019, at 2:13 PM, Murray S. Kucherawy wrote: > > On Wed, May 29, 2019 at 10:13 AM John R Levine > wrote: > As far as I can tell your proposal to break the document in two has > gotten no support at all. Can we stop now? > > What's on topic for the group an

[dmarc-ietf] Publication has been requested for draft-ietf-dmarc-rfc7601bis-03

Tim Draegen has requested publication of draft-ietf-dmarc-rfc7601bis-03 as Proposed Standard on behalf of the DMARC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ___ dmarc ma

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

> On Aug 23, 2018, at 2:39 AM, Murray S. Kucherawy wrote: > > This is the WGLC result. Tim sent me privately a large number of edits which > I cherry picked for things that were broken or obviously wrong and punted on > stuff that seemed less than that. Tim, feel free to argue harder for >

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

> On Aug 3, 2018, at 7:03 AM, Murray S. Kucherawy wrote: > > I feel like we're making a lot more edits here than the WG intended to make. > It's fine if the WG wants to turn this into a larger editorial pass, but I > thought the updates here were tightly scoped before, namely just enough to >

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

To get an early start on shepherding the draft, I gave the draft a top-to-bottom review with an eye towards readability. To ease the editor's burden, I'm avoiding posting a wall of diffs and have opted for sending changes directly to the editor for consideration. I'll leave it up to the editor

Re: [dmarc-ietf] "next steps?" (was: Re: Agenda for IETF 101 DMARC session)

On Mar 13, 2018, at 9:42 AM, Dave Crocker wrote: > >> Phase III: >> Review and refinement of the DMARC specification > > Is there technical work on the base specification that would improve it? The bug tracker contains a few items around clarification, removing ambiguity, correcting min

[dmarc-ietf] report from NL on need for DMARC standards track - open invite for participation

Hi all, last week I met with some of the folks involved with the Dutch Standardisation Forum. I'm reporting on a real need for the DMARC Working Group to make progress. The Netherlands would like to include DMARC into their list of compulsory open standards. Also, in order for the European Comm

[dmarc-ietf] Usage Guide interview (ISP) with David Finger @ Seznam.cz

[This email is part of the series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html ] Usage Guide draft: https://www.ietf.org/id/draft-tdraegen-dmarc-usage-guide-00.txt

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

> On Aug 7, 2017, at 1:21 AM, Bron Gondwana wrote: > > A more cheap and nasty fix, assuming it's too late/complex to change the > protocol more, would be to keep AS, but change the validation to only require > checking the most recent AS, since validating the rest is meaningless. Bron, thanks

Re: [dmarc-ietf] ARC Experimental goals

> On Jul 21, 2017, at 9:27 AM, Dave Crocker wrote: > > On 7/21/2017 6:17 AM, Tim Draegen wrote: >> Dave, are you saying the production of a rich and useful BCP could mark the >> end of Experimental status? > > Yes. Makes sense to me. Perhaps the WG should start co

Re: [dmarc-ietf] ARC Experimental goals

> On Jul 20, 2017, at 4:57 PM, Dave Crocker wrote: > > ARC produces a /chain/ of signatures. There is essentially no operational > experience doing this in real time in the operational Internet. We need to > learn what dependencies and what fragilities are relevant to its use. > > Therefore

Re: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions

> On Jul 20, 2017, at 2:00 PM, Hector Santos wrote: > > Anyway, we been here and there already. I just find it interesting that it > has come to this new manual "unfriendly" administrative policy. It should to > be codify into the integrated specs and everyone will quickly see what needs > to

[dmarc-ietf] current state of the DMARC Usage Guide

Hi all, in preparation for Thursday's in-person meeting, here's a summary of where the DMARC Usage Guide is at: 1) Thread on "Do we really need to do this?". Thread ends with "let's not do this unless there is missing documentation". (https://mailarchive.ietf.org/arch/search/?email_list=dmarc&gb

Re: [dmarc-ietf] selectors in AAR.

> On Jul 6, 2017, at 9:25 PM, Seth Blank wrote: > > In the case of a direct mail flow, the receiver has all the needed > information from the SMTP connection and A-R payload to create a report. None > of this information is present once a message arrives at a receiver in an > indirect manner.

[dmarc-ietf] using selectors to identify sources

> On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy wrote: > > Based on discussions with Seth and Gene earlier, it sounds like the industry > has sadly not taken up the habit of key and selector rotation, and instead > the pairing of "s=" and "d=" now identifies a single source. Ignoring the >

[dmarc-ietf] Usage Guide interview (ISP) with Vladimir Dubrovin @ Mail.Ru

[This email is part of the series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html] Background: Mail.Ru is an early adopter of DMARC -- implementing the technical specification as part of the pre-public pilot group. As the largest provider of email in Russia, M

[dmarc-ietf] Usage Guide interview (ESP) with Alwin de Bruin @ Measure Mail

[This email is the first of a series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html Thanks much to Alwin for being the first to volunteer and to help smooth out the rough spots.] Background: Measure Mail is a Netherlands-based Email Service Provider operating

[dmarc-ietf] Fwd: New Version Notification for draft-tdraegen-dmarc-usage-guide-00.txt

here". If there isn't, it won't be for lack of trying. > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-tdraegen-dmarc-usage-guide-00.txt > Date: June 17, 2017 at 7:32:26 AM EDT > To: "Tim Draegen&q

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

> On Jun 1, 2017, at 5:52 AM, Alexey Melnikov wrote: > > Is there an expired or not yet posted draft on DMARC usage? I think looking > at any written text will help inform the decision. I brainstormed a bit while at M3AAWG with a few people about the DMARC Usage Guide. Then I got the opportuni

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

> On May 31, 2017, at 8:47 AM, Barry Leiba wrote: > > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. > > Does anyone think we *should* proceed with writing this?

[dmarc-ietf] Usage Guide update

A minor update: an Abstract, Intro, and Outline have been written up. Half a dozen people (those that previously volunteered on this list) are putting meat on the bones now to get an initial reviewable draft into place. ___ dmarc mailing list dmarc@iet

Re: [dmarc-ietf] looking for collaborator for Usage Guide

> On Feb 24, 2017, at 10:30 AM, Mike Jones wrote: > > So my recommendation for anyone interested is to read this, > https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03 > . We can > collaborate on where it is incomplete or outdated, a

[dmarc-ietf] looking for collaborator for Usage Guide

Hi all, I'm looking to collaborate with someone on the creation of the DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter as "3. DMARC Usage": https://datatracker.ietf.org/wg/dmarc/charter/ If you or a colleague would be interested in this work, please contact me off list. Than

[dmarc-ietf] phase 1 is done

This working group's "phase 1" is now done. The Chairs will be shepherding the phase 1 interoperability draft: https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability The WG will now move ahead to phase 2: https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki When disc

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

Kurt, I believe so. AFAICT, there was one paragraph you were runnin down, but if you're asking, I'm assuming that's it. Right? =- Tim > On Feb 12, 2016, at 3:32 PM, Kurt Andersen (b) wrote: > > Since there have been no further comments since this version was posted, does > that mean that

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

> On Jan 18, 2016, at 12:49 PM, Kurt Andersen (b) wrote: > > Am I misunderstanding the recommended algorithm? > Maybe the example of @crime.net and @bank.com might add clarity. If both have a p=reject policy, and only @crime.net succ

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

> On Nov 7, 2015, at 9:01 PM, Kurt Andersen (b) wrote: > On the flipside, I don't see what value they add; the ones that gain > consensus will be published in their own right, and the details of the ones > that don't probably aren't interesting to later readers anyway. > > -MSK > > I'm OK eit

Re: [dmarc-ietf] Two new internet-drafts related to forwarded email

> On Oct 17, 2015, at 9:11 AM, Kurt Andersen wrote: > > As one of the editors for the interop document, I have already reviewed it > :-) Yes! I'm hoping your A.R.C. colleagues will chime in, too. > > The ARC spec is explicitly designed to help preserve authentication results > across multi

Re: [dmarc-ietf] Two new internet-drafts related to forwarded email

> On Oct 16, 2015, at 10:41 AM, Kurt Andersen wrote: > > Will look forward to feedback from any interested parties. Hi Kurt, Can you and the editors of these documents review the interoperability issues doc (now in WG last call): https://tools.ietf.org/html/draft-ietf-dmarc-interoperability

[dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"

Hi All, The editing team deems this draft as ready for last call review. Here are the links to the recently posted v07: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > > There's also a htmlized version available at:

Re: [dmarc-ietf] Ping?

> On Jul 16, 2015, at 2:00 AM, Murray S. Kucherawy wrote: > > Hey, so uh, who's waiting on whom for what here? The interoperability issue draft has outstanding edits for version 4, with an emphasis on finishing Section 4: http://trac.tools.ietf.org/id/draft-ietf-dmarc-interoperability-04.txt

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

> On Jun 9, 2015, at 11:44 AM, Franck Martin wrote: > > As comments are dying out, are we close to a last call? There will be another revision to pick up a small batch of grammar nits. Reviews now are appreciated but if you're keen on grammar nits, you might hold off. =- Tim __

Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

> On Mar 18, 2015, at 4:30 PM, Murray S. Kucherawy wrote: > > On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen <mailto:t...@eudaemon.net>> wrote: > Hi Murray & Elizabeth, thanks for wrestling this through the process. The > Working Group can now adopt this as input.

Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Hi Murray & Elizabeth, thanks for wrestling this through the process. The Working Group can now adopt this as input. /goes off to figure out which buttons need to be pushed =- Tim > On Mar 18, 2015, at 4:08 PM, Murray S. Kucherawy wrote: > > FYI: > > -- Forwarded message --

[dmarc-ietf] interoperability draft for review

Hi all, Frank, Eliot, and myself have finished up a first cut at the WG’s 1st real deliverable: • Document describing interoperability issues with DMARC and indirect mail flows and possible methods for addressing them. Please review at your convenience and submit comments, feedback, and

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

> On Jan 17, 2015, at 12:00 PM, Hector Santos wrote: > > I have two concerns. > > It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is 7208 > backward compatible or not? Does DMARC require 7208 operations or 4408 > operations? > > And is this -12 publication "worthy" of eve

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

> On Jan 16, 2015, at 11:08 PM, Murray S. Kucherawy wrote: > > Would the co-chairs object to beginning to track these items using the WG's > tracker? If and when we do decide to crack open the base document for a > Proposed Standard revision, we'd already have an inventory of topics to > cons

[dmarc-ietf] update on 1st draft

Heyo all, The WG's 1st draft (documenting interoperability issues between DMARC and indirect email flows plus possible ways to address them) should be ready for WG-wide review come mid week. Due to the holidays this work was slow to get off the ground, but it's shaping up nicely now. =- Tim

Re: [dmarc-ietf] milestone 1 *almost* done

> On Nov 21, 2014, at 1:54 PM, Rolf E. Sonneveld > wrote: > > does this mean that any work/solutions will not be discussed on this list, > before a reviewable draft is ready? If so, please add me to the discussion > group. No, I was not clear. Discussion of solutions will happen on the maili

Re: [dmarc-ietf] milestone 1 *almost* done

On Nov 21, 2014, at 1:50 PM, Douglas Otis wrote: > > On Nov 21, 2014, at 9:56 AM, Tim Draegen wrote: > >> WG, >> >> PS. A group of editors spontaneously formed during the in-person meeting. >> The group will tackle Milestone 2 — which is to transform iss

[dmarc-ietf] milestone 1 *almost* done

WG, The work found here: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki ..is almost complete. However, there is a note (reinforced by feedback during the recent in-person meeting) to recast the collected issues

Re: [dmarc-ietf] slides for Friday session

> On Nov 14, 2014, at 3:09 AM, Brett McDowell wrote: > > "It will also provide technical implementation guidance and review possible > enhancements elsewhere in the mail handling sequence that could improve DMARC > compatibility." > > Is this exercise within the scope of Milestone 2 [2], i.e.

[dmarc-ietf] slides for Friday session

Slides for tomorrow’s session can be found here: http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf More information on how to attend can be located from day's agenda/schedule: http://tools.ietf.org/agenda/91/#FRIDAY =- Tim ___ dmarc

Re: [dmarc-ietf] Indirect email flows

> On Nov 12, 2014, at 10:59 AM, Franck Martin wrote: > > Could I request the list admins, to drop the subject tagging and the footer > on this list? And if possible remove the removal of the HTML? No. ___ dmarc mailing list dmarc@ietf.org https://ww

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

> On Nov 8, 2014, at 8:38 PM, Franck Martin wrote: > > There are no secret sauces. I thought it was clear this type of language on > this list is frown upon as non constructive? Just a point of clarification here. The original author was referring to decisions that receivers make when proces

[dmarc-ietf] draft IETF 91 WG agenda up for review & input

Hi, this WG’s IETF91 agenda is up for review: http://www.ietf.org/proceedings/91/agenda/agenda-91-dmarc If you have comments, suggestions, or modifications, please feel free to reply here or if you're shy, reply privately. 1/2 of th

[dmarc-ietf] End of thread! was: Re: wiki vs. list?

> On Oct 29, 2014, at 7:20 PM, Hector Santos wrote: > > If they are going to rewrite, then at the very least we MUST make 3rd party > protocol options and algorithms available as well to ALL implementators as > part of the DMARC protocol to complete the total picture. Hi Hector, this thread is

Re: [dmarc-ietf] wiki vs. list?

Hello, please remember to keep this dialogue respectful. Feel free to review: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki ...as it forms the basis for meeting the WG's first milestone. 1/2 of this WG's Chair, =- Tim ___ dmarc mai

[dmarc-ietf] progress towards milestone 1

WG, During the WG's allotted IETF91 time (Friday November 14th @ 9 AM Hawaii time), we’ll need to make a decision as to whether or not we’ve adequately documented all known issues between DMARC and indirect email flows. I don’t think we’re quite there yet, but we’re close. I’ll be spending a

Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage)

On Oct 8, 2014, at 3:20 PM, Scott Kitterman wrote: >> A bit ahead of the WG's focus. > > We have one? Ha! The WG is supposed to be focused on collecting all known issues between DMARC and indirect email flows. Based on the collected set of issues, we'll then switch gears and argue the heck o

Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage)

On Oct 8, 2014, at 1:42 PM, Dave Crocker wrote: > Hmmm... > > I find myself unclear about whether the wiki is intended to be an > alternative to posting one's thoughts, in which case how with the wg see > them? > > I'd expect the wiki to be a place to capture thoughts/issues/decisions > after th

Re: [dmarc-ietf] documenting x-original-from usage

On Oct 3, 2014, at 11:41 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > >> Along an entirely different line of analysis, note that Original-From is >> merely adding complexity to the 'who was the author of this message' >> assessment, very possibly creating yet-another security hole. >

Re: [dmarc-ietf] Modeling MLM behavior

On Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy wrote: > On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen wrote: > On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: > > IMHO, we should specify a credible MLM model, even if that can be > > slightly off topic for the WG, in ord

Re: [dmarc-ietf] documenting x-original-from usage

On Oct 3, 2014, at 12:38 PM, Dave Crocker wrote: > The X-* construct has been deprecated. Yes. Let's collect everything around what people have been using "X-Original-From:" for as a starting point. The application of this header in different contexts brushes up against what the WG is trying

[dmarc-ietf] email orphans - embedded devices

I've created a wiki page to expand upon an often overlooked source of email -- embedded devices. http://trac.tools.ietf.org/wg/dmarc/trac/wiki/EmbeddedDevices These sources of email are often incredibly problematic. Thanks to John Levine for quietly inserting this into the WG's wiki. I'll b

[dmarc-ietf] documenting x-original-from usage

Although a bit forward looking, I've created this page: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/XOriginalFrom ..for people to add their smarts of how X-Original-From is being used today. I haven't fleshed it out with content, please feel free to do so! This page is being linked from th

[dmarc-ietf] Modeling MLM behavior

On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: > IMHO, we should specify a credible MLM model, even if that can be > slightly off topic for the WG, in order to maximize its probability of > being adopted. The rest of this message has some notes to this end. The discussion of interoperabi

[dmarc-ietf] CIVILITY REMINDER - Re: yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage

On Sep 17, 2014, at 5:10 AM, John Levine wrote: >> I would certainly suggest a thing independently of DMARC (thus "both >> technically accurate and real-world-sensible") and, indeed, can't even >> claim credit for it: this has come up before in both the DKIM/ADSP >> discussion and in the origin

[dmarc-ietf] Milestone 1 wiki updated

I've gone through and updated the Wiki to fold in items that the list has discussed: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Please continue to flesh out the existing items and to raise additional items. The devil is in the details. Thanks to Stephen J. Turnbull for t

Re: [dmarc-ietf] Milestones changed for dmarc WG

On Aug 31, 2014, at 2:26 AM, Stephen J. Turnbull wrote: > My feeling is that the DMARC consortium would appreciate a change of > wording like the one I proposed, and I'm all for keeping them happy > and in the club. If the distinction doesn't matter to others, why > not? Hi Stephen, I replied to

Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue

On Aug 29, 2014, at 11:39 PM, Scott Kitterman wrote: > Since this is the WG list, I'm not sure if this is still the right list for > issues with the base spec or not, but here goes ... Right list. Just to set precedent, any thoughts on this issue will be captured in the WG's issue tracker. On

Re: [dmarc-ietf] Milestones changed for dmarc WG

On Aug 30, 2014, at 9:57 AM, Pete Resnick wrote: > We in the WG understand what we mean, and we can certainly be clear about it > in the wiki. But I see no need for a change to the milestone text. Almost had some crosstalk.. Stephen, the wiki is supposed to make this aspect clear, specifically

[dmarc-ietf] How we'll produce deliverables. And we're starting now!

The working group's five milestones [1] all involve the production of documentation. To meet each milestone, the working group will follow a simple process: Collect ideas/issues, edit into document form, review, and then publish (and not necessarily as official IETF documents). To make sure th

Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

On Aug 29, 2014, at 3:07 PM, Douglas Otis wrote: > The charter statement indicates work on a public suffix concept is > out-of-scope. This is fine provided the definition used in the charter is > retained: [snip] > Such policy assertions should be a matter handled within the WG as related > t

Re: [dmarc-ietf] Milestones changed for dmarc WG

On Aug 29, 2014, at 2:09 PM, Dave Crocker wrote: > I'm also wondering about the implied overlap of work, cased on the close > proximity of the final milestones. The final milestones represent parallel work efforts -- and hopefully they're different enough from each other that they can progress i

Re: [dmarc-ietf] Milestones changed for dmarc WG

On Aug 29, 2014, at 2:06 PM, Pete Resnick wrote: > Are you OK with the following edits? > > Dec 2014Complete draft on DMARC interop issues + possible methods to > address > Mar 2015Complete draft on DMARC improvements to better support indirect > email flows > May 2015Complete draft

Re: [dmarc-ietf] Milestones changed for dmarc WG

On Aug 29, 2014, at 12:50 PM, Pete Resnick wrote: > Tim/Ned [Ccing WG]: > > While I think the milestones that appear in the wiki are great for internal > WG management (and in fact I think you could even add more of them), I think > for the external-facing milestones on the charter page, you sh

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

On Aug 24, 2014, at 10:35 PM, Kurt Andersen wrote: > > Once the milestones discussion has settled..., Ned and myself will create > > an outline of topics and work items that, when worked through, should have > > the WG arrive at its deliverables. > > > > =- Tim > > What about adopting a somew

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

On Aug 23, 2014, at 10:34 AM, Miles Fidelman wrote: > I did notice the absence of anything related to process. How are we going to > get to a "document (that) captures all known interoperability issue between > DMARC and indirect email flows?" If this were an RFC, there'd be an author > or au

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

On Aug 23, 2014, at 12:30 PM, Dave Crocker wrote: > On the other hand, a common exercise in a wg organizing bof is to look > for a show of hands for interesting in specific topics and willingness > to work on them. > > Perhaps an informal query like that, here, would be useful? Yes, I'll post su

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

On Aug 21, 2014, at 2:04 AM, Eliot Lear wrote: >>- EOY 2014: Deliverable #1 (above document + possible methods to address). > > That seems quite short a period between adoption and approval, and I > question whether you will get sufficient review at a time when in > America there is Thanksgiv

Re: [dmarc-ietf] [apps-discuss] Start of DMARC WG + proposed milestones

On Aug 18, 2014, at 11:50 AM, MH Michael Hammer (5304) wrote: > Is the DMARC Usage Guide the same as the BCP or is it a different document? > If it is a different document, is the BCP going to be one of the milestones > for the WG or is it off the table? They are one and the same.

[dmarc-ietf] Start of DMARC WG + proposed milestones

Hello world of email, The DMARC WG is getting started [1]. This IETF working group's goal is to address interoperability issues with indirect email flows, to document operational practices, and to mature the existing DMARC base specification. If you would like to join please visit the DMARC W

Re: [dmarc-ietf] Draft DMARC working group charter

On Jul 1, 2014, at 12:00 PM, Dave Crocker wrote: > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? Dave, I'm not sure if you're asking, but I think the WG Charter is good enough. Consensus++ __

[dmarc-ietf] Draft DMARC working group charter

On Jun 23, 2014, at 1:44 AM, Barry Leiba wrote: > Let's please stop all the other discussions for now, and say that the > purpose of the mailing list is, for now, to discuss > the charter proposal and converge on a charter for a working group. > > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

Stephen! Welcome! No one said making sausage was pretty. :-( On May 29, 2014, at 6:21 AM, Stephen J. Turnbull wrote: > Tim Draegen writes: > >> John, you are very difficult to communicate with, maybe because >> you're easily insulted, even when there is no insult.

Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection

On May 29, 2014, at 3:05 AM, John R Levine wrote: > Really, that makes no difference. I don't want Yahoo or anyone else to pay > us to screw up our mail software to work around them -- I want them to spend > their money to fix things so we don't have to. Yes, I get it, I guess in my own jaded

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

On May 28, 2014, at 8:48 PM, Douglas Otis wrote: > Dear Tim, > > All that is needed is a few bandaids? Hi Doug, I don't see the problem space as allowing bandaid approaches. The widespread ability to build controls on top of stable domain level identifiers is relatively new. In my view, peop

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

On May 28, 2014, at 12:37 PM, John Levine wrote: >> Its not clear to me that gmail.com needs to tell another service to trust >> the OAR from a given third party, the choice to trust that service could >> easily be up to the receiving service. > > Good point. That's why I keep saying that one or

[dmarc-ietf] spec missing ABNF for "fo" tag

Hi, Section 5.3. of the DMARC spec is missing ABNF for the "fo" tag. The necessary changes could be (I'm no ABNF master): Adding to "dmarc-record" definition: [dmarc-sep dmarc-fopt] And adding the actual definition: dmarc-fopt= ( "0" / "1" / "d" / "s" ) dmarc-fo = "fo" *WSP

Re: [dmarc-ietf] ADSP to Historic?

+1 Bonus pluses for inserting some forward reference so that naive ADSP deployers know where to go next. =- Tim On Sep 11, 2013, at 7:03 PM, Dave Crocker wrote: > > just looking for initial reactions, to judge whether to make the formal > request. a +/- 1 certainly qualifies. ___