Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Dec 2013 12:08:51 -0800

On Fri, Dec 6, 2013 at 11:51 AM, <[email-masked]> wrote:

>
> A new version of I-D, draft-kucherawy-dmarc-base-02.txt
> has been successfully submitted by Murray S. Kucherawy and posted to the
> IETF repository.
>
> Filename:        draft-kucherawy-dmarc-base
> Revision:        02
> Title:           Domain-based Message Authentication, Reporting and
> Conformance (DMARC)
> Creation date:   2013-12-06
> Group:           Individual Submission
> Number of pages: 78
> URL:
> http://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-base-02.txt
> Status:
> http://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base
> Htmlized:        http://tools.ietf.org/html/draft-kucherawy-dmarc-base-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-base-02
>
> Abstract:
>    This memo presents a proposal for a scalable mechanism by which a
>    mail sending organization can express, using the Domain Name System,
>    domain-level policies and preferences for message validation,
>    disposition, and reporting, and a mail receiving organization can use
>    those policies and preferences to improve mail handling.
>
>    The email ecosystem currently lacks a cohesive mechanism through
>    which email senders and receivers can make use of multiple
>    authentication protocols to establish reliable domain identifiers,
>    communicate policies about those identifiers, and report about mail
>    using those identifiers.  This lack of cohesion has several effects:
>    receivers have difficulty providing feedback to senders about
>    authentication, senders therefore have difficulty evaluating their
>    authentication deployments, and as a result neither is able to make
>    effective use of existing authentication technology
>
>    The enclosed proposal is not intended to introduce mechanisms that
>    provide elevated delivery privilege of authenticated email.  The
>    proposal presents a mechanism for policy distribution that enables a
>    continuum of increasingly strict handling of messages that fail
>    multiple authentication checks, from no action, through altered
>    delivery, up to message rejection.
>

This version addresses most of the feedback that's been posted to date.  It
doesn't include unresolved things that are still being discussed on the
list.

The diff link is probably going to be useful to most people given the size
of the document.

Have at it!

-MSK

---

From: Michael Stevens <[email-masked]>
Date: Sat, 7 Dec 2013 17:45:49 +0000

> The diff link is probably going to be useful to most people given the size

Tiny comments, second paragraph ending "effective use of existing
authentication technology".

p8 "   2.  Log details required to generate forensic and aggreagate
reports"

spelling mistake in aggreagate?

Michael

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2013 23:41:44 -0000

In case it wasn't obvious, in new 11.2.2, the use of "!~q!}{." as the
unique-id in the filename was a hint that you might want to reconsider
the ABNF in section 11.2.1 that defines unique-id as a MIME token,
which can be nearly any random text characters, and instead constrain
it to characters that won't confuse shell scripts or simpleminded
filename parsers and the like.  (I know that bad people can send
anything they want as a filename, but this way you can just reject
stuff with crud in the name rather than trying to handle it.)

In the existing mail reports, the unique-id is optional, and when I
looked through the reports I've gotten, the only reporter that uses
one is Linkedin.  Theirs is always the string "dhalia" which isn't
very unique so I expect it's a bug.

I'd suggest changing the unique-id ABNF on page 37 to

     unique-id = 1*(LETTER | DIGIT)

Speaking of ABNF, in section 5.3 are all the tags and values intended
to be case independent, including v=DMARC1?  If not, you have to turn
them into unreadable hex.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 Dec 2013 16:55:49 -0800

> very unique so I expect it's a bug.

It is not a bug, and it is not unique. It depends where you report is generated from. We can generate several reports for the same (timestart,timeend,domain). The unique id allows you to know you have not received a duplicate.

This is one of the purpose of this uniqueid: to avoid to have to collate all the data in one location.

see https://github.com/linkedin/dmarc-msys/blob/master/dmarc_report.py#L44 and https://github.com/linkedin/dmarc-msys/blob/master/dmarc_report.py#L171

---

From: John R Levine <[email-masked]>
Date: Sat, 7 Dec 2013 20:00:28 -0500 (EST)

> This is one of the purpose of this uniqueid: to avoid to have to collate all the data in one location.

Oh, OK.  Usually people pick something that doesn't look like the the name 
of the programmer's girlfriend, or maybe his cat.

In any event, it still looks like limiting the unique ID to letters and 
digits won't break anything.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 Dec 2013 17:22:46 -0800

On Dec 7, 2013, at 5:00 PM, John R Levine <[email-masked]> wrote:

> Oh, OK.  Usually people pick something that doesn't look like the the name of the programmer's girlfriend, or maybe his cat.

You lack imagination... :P

> 
> In any event, it still looks like limiting the unique ID to letters and digits won't break anything.
> 

Agreed