Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Oct 2011 23:13:14 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Friday, September 30, 2011 11:58 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt
> 
> Sorry not to get to this sooner.  This draft has problems.  It's
> not ready to ship.
> 
> Sec 3.1 says a report MUST include explicit auth results for both DKIM
> and SPF.  Well, no.  I don't check SPF, so if people are only going to
> accept DKIM failure reports if they also say something about SPF,
> they're not going to get any reports from me.  I expect people who
> check SPF but not DKIM feel the same way, particularly for the large
> fraction of mail that has no DKIM signatures to check.  Suggest just
> removing this clause, and let people report what they're reporting.

I'm gently kicking myself now for not having included reporting result codes in RFC5451 for "not checked".

I think the intent here (as I mentioned to SM) is that this is really a specific profile for ARF use, creating a new feedback type, that originates with sites that do check both; if you don't check both, you simply wouldn't use this feedback type.  It didn't occur to me when I crafted the original versions of this work that there might be sites that don't, and that there's no way to say explicitly "I don’t check {DKIM,SPF}."

I realize now that approach was maybe a bit limiting.

Perhaps one solution might be to go register "not-checked" under RFC5451 for both SPF and DKIM, and then this could be mandatory.  That seems overkill though, unless we can decide we really want that (or that it would be a good idea to do regardless).

Failing that, it does seem to make sense to reduce this to "MUST report at least one of..."

> Original-Envelope-ID and Original-Mail-From: same issue, they're not
> relevant to DKIM, and by the time I check DKIM, it's often after SMTP
> is over and the envelope isn't directly available.  Suggest it say
> they SHOULD be included if they are available.

That makes sense to me, or SHOULD if you're reporting SPF.

> Source-IP: same problem.  If you don't have the source IP, just leave
> it out, don't lie.  (And 0.0.0.0 is totally oldthink.  The value I'm
> not going to include is ::.)

I agree with this one.

> Message-ID: this is just wrong, RFC 5965 does not report it.

I don't agree with this one.  What's wrong with adding this here even though RFC5965 doesn't include it?

To me the stronger argument is that RFC5322 doesn't require it, so this can't either.

> 3.2.1: Delivery-result: what I do with my mail is none of your business.
> This field has to be optional.

Agree.

> 3.3: Why just spf rather than spf-fail, spf-softfail, spf-temperror,
> or spf-permerror? If you're reporting an SPF problem, you presumably
> know what your SPF checker returned.

Seems reasonable, though the applications for this I can think of don't necessarily care, and so the detail of the failure could be included in a comment.

> 4: SPF-DNS.  If you're going to return a snapshot of the SPF record,
> shouldn't you also return all the records it included?

Agree.

-MSK (as participant)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Oct 2011 23:19:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, September 30, 2011 3:14 PM
> To: [email-masked]
> Does requiring the canonicalized header/body be included in the report obviate
> the ability to remove data as described in paragraph 5?  I think the fact that
> these include data that one might want to redact is worth a mention in
> security considerations.  Also, if one is going to redact and then re-
> canonicalize then providing the data is pointless.  So if a sender wants to
> fully redact information there's no benefit to including them.  They should
> only be included if they can be sent unmodified without violating the
> receiver's privacy requirements.

The original intent of the canonicalized header/body fields is to allow a sender, who keeps the same data at the time of signing, can compare it against the receiver's copy of the same data to tell how the signed part of a message was altered in transit.  When doing DKIM debugging, redaction clobbers any hope of finding the real problem.  This is definitely appropriate for coverage in Security Considerations.

With respect to the warning that most implementations will just report "other" a lot of the time, I think it's fair to say that's fine: For sites that agree between themselves that they trust each other and trust the transmission channel, they can agree to send unredacted, detailed reports, and this document says how to do so; for those that do not and have privacy concerns, the spec should accommodate those cases as well.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2011 10:46:30 -0000

>Perhaps one solution might be to go register "not-checked" under RFC5451
>for both SPF and DKIM, and then this could be mandatory.  That seems
>overkill though, unless we can decide we really want that (or that it
>would be a good idea to do regardless).

I don't understand what the problem is with people reporting what
they report.  If they checked both, fine, if not, well, what's
wrong with that?

>though RFC5965 doesn't include it?

What's the point?  Neither SPF nor DKIM use it.  It's in the copy of
the message if you want it, just like all the other headers.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 03 Oct 2011 13:22:38 +0200

On 03/Oct/11 08:13, Murray S. Kucherawy wrote:
> 
> I'm gently kicking myself now for not having included reporting
> result codes in RFC5451 for "not checked".

The General Description in RFC 5451 makes it clear that methods that
were not applied deserve no "method=result" statement.  That spec does
not mandate that _all_ methods be reported, thus leaving it ambiguous
whether unreported methods are not implemented at all or omitted for
any other reason.  IMHO, that's good as it is.

> I think the intent here (as I mentioned to SM) is that this is
> really a specific profile for ARF use, creating a new feedback
> type, that originates with sites that do check both; if you don't
> check both, you simply wouldn't use this feedback type.  It didn't
> occur to me when I crafted the original versions of this work that
> there might be sites that don't, and that there's no way to say
> explicitly "I don’t check {DKIM,SPF}."

I'm unable to see why these methods need to coexist for reporting just
one of them.  Even MTAs that usually check both, may bail out some
checks in particular cases.  Furthermore, to report a message that
simultaneously fails both DKIM and SPF, one needs to send two separate
authfailure reports anyway, since the Auth-Failure field must appear
exactly once (but it is missing in the example, BTW.)

> I realize now that approach was maybe a bit limiting.

Authfailure reporting is non-extensible by design, while RFC 5451 is.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Oct 2011 11:07:10 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, October 03, 2011 4:23 AM
> To: [email-masked]

The absence of "spf=" in an Authentication-Results field doesn't say anything about SPF work done at the verifier.  Could be that it was tested and unreported for all I know.  If the verifier wants to say explicitly "I didn't check this", there's no mechanism to do that right now.

> Authfailure reporting is non-extensible by design, while RFC 5451 is.

I don't agree at all with the first part of that statement.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Oct 2011 16:10:46 -0700

> Sent: Monday, October 03, 2011 3:47 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy

I thought the idea is that the second MIME part of a multipart/report includes things that might be keys to searching logs or otherwise uniquely identifying the message at the sender's side, as well as including the technical specifics of the report.

But you're right that it's duplicated data if the third part is included, and for ARF it always is.

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2011 01:58:32 -0000

>I thought the idea is that the second MIME part of a multipart/report
>includes things that might be keys to searching logs or otherwise
>uniquely identifying the message at the sender's side, as well as
>including the technical specifics of the report.

It never has in the past.  As we said in RFC 5965:

       This section is intended to convey meta-data about the report
       in question that may not be readily available from the included
       email message itself.

>included, and for ARF it always is.

Exactly.  The second section is "here's why we hate this message",
not "here's the message you sent."

R's,
John

PS: Is someone planning to revise the draft and try to fix it?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Oct 2011 21:34:24 -0700

> Sent: Monday, October 03, 2011 6:59 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

In progress.

---

From: "Hilda Fontana" <[email-masked]>
Date: Mon, 3 Oct 2011 21:35:40 -0700

Thanks guys - I am gathering all the changes and am going to do a revision
best I can.
H

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murray S. Kucherawy
> Sent: Monday, October 03, 2011 9:34 PM
> To: [email-masked]
> > Subject: Re: [marf] Comments on
draft-ietf-marf-authfailure-report-01.txt
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf