"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: > 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 > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > John Levine > > Sent: Friday, September 30, 2011 11:58 AM > > To: [email protected] > > 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. > > > > 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 > > > > > > > > > > _______________________________________________ > > marf mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
