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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Sep 2011 10:55:40 -0700

Actually, in going back through the list, I found this:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murray S. Kucherawy
> Sent: Thursday, August 18, 2011 2:02 PM
> To: [email-masked]
> Subject: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt
> 
> Also in Section 3.3, for "granularity", we might want to mention that
> this is supported in [OLD-DKIM] but not in [DKIM] since it's undergoing
> update now and the whole concept of key granularity has been removed.
> We would then change the existing [DKIM] reference to [OLD-DKIM], and
> add one called [DKIM] that points to the one that's currently in the
> RFC editor queue.  (Barry, check my math on this one, please.)

It looks like this one got missed.  Anyone have any particular comments, especially Barry?

> If there's no other feedback, do people think we're ready to start a
> WGLC on this one?

Re-asking this.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 Sep 2011 15:58:41 -0400

> It looks like this one got missed.  Anyone have any particular comments, especially Barry?

I thought I'd replied to this before, but I guess not.
Do we really want to talk about "old-dkim" at this point?  Shouldn't
we have a failure reason of "other" anyway, and just eliminate
"granularity" and say that any other failure reason is reported as
"other"?

>> If there's no other feedback, do people think we're ready to start a

I think we're ready.  The above issue can be resolved during WGLC.

Let's say that this now officially starts working-group last call on
draft-ietf-marf-authfailure-report-02 (
http://tools.ietf.org/html/draft-ietf-marf-authfailure-report ), said
last call to end on 30 September.  Everyone, please review this
version and give it a yay or nay.  Please post issues, and also post
notes that you've reviewed this version and it's ready to go.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Sep 2011 13:06:43 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, September 13, 2011 12:59 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt
> 

I'd be fine with removing it as "overtaken by events".

> notes that you've reviewed this version and it's ready to go.

Reviewed, ready to go.

<chair> The datatracker will show this WGLC closing 9/27, but we'll let it roll the extra three days.  I'll also take this one up as document shepherd. </chair>

-MSK, as participant, except as noted

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Sep 2011 11:17:31 -0700

Reminder: WGLC closes today on this document.

---

From: "John Levine" <[email-masked]>
Date: 30 Sep 2011 18:57:34 -0000

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.

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.

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 ::.)

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

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

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.

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?

R's,
John

---

From: "Hilda Fontana" <[email-masked]>
Date: Fri, 30 Sep 2011 14:19:47 -0700

John,

Thanks for your comments.  I disagree on a couple of points.

First - the overall point of this is to be able to better report on
authentication headers.  If you are only doing dkim then the dkim reporting
is probably a better bet than this one.    This is meant to be the next step
for marf for reporting authentication failures in a uniformed way.

For 3.2.1 delivery result - you can default to other but the preference
would be to keep it as a MUST 

Thanks
H

> John Levine
> Sent: Friday, September 30, 2011 11:58 AM
> To: [email-masked]
> 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.
> 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.
> 
> 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
> ::.)
> 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.
> 
shouldn't
> you also return all the records it included?
> 
> R's,
> John
> 
> 
> 
> 
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 Sep 2011 18:13:35 -0400

"If you are only doing dkim then the dkim reporting is probably a better bet 
than this one.": Currently the SPF draft covers only publishing informaton in 
DNS about requesting SPF based reports.  All the informaiton about how to 
report the authentication failure is in this draft.  The same is true for the 
DKIM draft, so I have no idea what that statement means.

Making providing information about both technlogies when only one might be in 
use seems exactly backwards.  Including information about SPF (or DKIM) when 
only DKIM (or SPF) are being used is going to be confusing at best.

BTW, this confusion is not theoretical for me.  I'm involved in one project 
where we get dummy data from one source that we know doesn't have it and so we 
have to use our out of band knowledge to hard code around this for that data 
source.  It's a serious issue.

Original-Envelope-Id, Original-Mail-From, Arrival-Date, Source-IP. Message-ID, 
and Reported-Domain are all optional in ARF.  They should only be required 
here if they are relevant to the support understanding the information in the 
authentication results header.  For example, Mail From is completely unrelated 
to DKIM an so there's no reason to include it in a DKIM related ARF.

I think this draft needs a step back to allow reporting of only the 
authentication results one actually has and only the information relevant to 
that result.

I've always found inclusion of delivery results in a message about auth 
failure a bit odd (seem somewhat orthogonal).  If you're going to keep it 
required, you should probably add myob as an option (mind your own business) 
(not a serious proposal, but my guess is virtually all of these will be 
returned as "other").  Since most senders won't provide this type of 
information, I think it's senseless bloat to require the field.

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.

Paragraph 5 could be reduced to a pointer to an appropriate security 
consideration in paragraph 7 and to the redaction draft.  As long as it's 
clear the receiver needs to make sure the data they include complies with 
their privacy requirements (which I think belongs in security considerations) 
the rest it really off topic for this draft.

Scott K

On Friday, September 30, 2011 02:19:47 PM Hilda Fontana wrote:
> > Subject: Re: [marf] Comments on
> > draft-ietf-marf-authfailure-report-01.txt
> > 
> > accept

---

From: "John R Levine" <[email-masked]>
Date: 30 Sep 2011 21:42:17 -0400

> would be to keep it as a MUST

I think you're misunderstanding what a standard is.  It says, if you want 
to interoperate with other people, here's how you do it.  No IETF 
standard can ever force people to do anything they don't want to.

So if it says you MUST return a delivery result, what you're actually 
saying is that if you're not going to send a delivery result, don't bother 
to send anything.  You would probably prefer to get some reports than no 
reports, so MUST is utterly counterproductive.

I also note it is fairly common for people simply to ignore parts of 
standards they think are silly, so no matter what you say, people will 
send reports with only DKIM info for DKIM failures, only SPF info for SPF 
failures, and no delivery results.  Experience suggests that successful 
standards are written to maximize the likelihood that people will 
implement them as written, so you don't write requirements that are likely 
to be ignored.

It appears we all agree that some things in the draft are just wrong, like 
the Message-ID, so this draft needs to recycle at least once more.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.