For the sake of expediency, I'm helping Hilda with some of these edits. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of John > R Levine > Sent: Tuesday, December 13, 2011 7:37 PM > To: ARF mailing list > Subject: [marf] comments on draft-ietf-marf-authfailure-report-06 > > I see there's a new version of authfailure-report. Overall it's > getting there, but it still has some severe confusion about RFC 2119 > language. In 2119-ese, MUST means that if you don't do that, it won't > interoperate at all so don't even try. > > In section 3.1 of the draft: > > Authentication-Results: Syntax as specified in [ARF]. Furthermore, > [ARF] specifies this field is OPTIONAL and appears at most once; > for this extension, this field MUST be present if that value is > available. It MUST be formatted according to [AUTH-RESULTS], and > MUST reflect only a single email authentication method failure. > > The ARF RFC doesn't define Authentication-results, RFC 5451 does. > > I don't understand what "MUST be present if that value is available" > means.
I imagine it's copied from the others. The point there is that for SPF (for example), the client IP is needed to paint the whole picture, but for a DKIM report it isn't, and in either case it may not be available. Same for the other parameters; different filtering points in the handling chain have access to different subsets of them. > Referring to 2119, it would mean that if you have cruddy software that > doesn't record the auth results so the value isn't available, it's OK > to send a report without it, but if do you have it available but don't > want to send it, you can't send a report at all, which is silly. I > understand that some people really really REALLY want their reports to > be unredacted, but as we discussed a month or two ago, reporters will > send what they're willing to send and no more, regardless of what an > RFC says. In fact, an auth failure report without this info is often > entirely usable, so just delete this paragraph. Do you really mean "delete this paragraph"? Because we do want the field to be there. RFC5451 gives a standard way to report this result, so it makes sense to either require that it be there, or don't send a report at all. What about: "Syntax as specified in <xref target="AUTH-RESULTS"/>. Furthermore, <xref target="ARF"/> specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present, but MUST reflect only a single authentication method's result." > To report multiple failures for a single message, multiple reports > MUST be generated. > > That sentence says that if you have multiple failures you have to > report all of them, or else don't report anything. Move it to just > above section 3.1 and change it to: > > A single report describes a single authentication failure. > Multiple reports MAY be used to report multiple failures for a > single message. That works. > Then there are several sections like this one with the same MUST > language: > > Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore, > [ARF] specifies this field is OPTIONAL and appears at most once; > for this extension, this field MUST be present if that value is > available. > > The next three similar paragraphs cover Original-Mail-From, Source-IP, > and Reported-Domain. Same problem, same solution, delete all four of them. > I suppose you could say something like it is RECOMMENDED to include > these items to help better diagnose the authentication failure. I'd prefer that last approach. I didn't like the MUST either, but I appeared to be in the minority. > In Section 4, the ABNF, the definition of auth-failure both says that a > token is one of a list of types and that it's imported from [MIME]. > Importing seems wrong since that suggests it can be any tokenish > string, but there's nothing that says that unknown auth-failure types > are ignored. > Suggest removing the references to token and instead enumerate the > failure types, similar to the list of delivery results just below it. That works. > dkim-selector is also defined as a token, but actually it's a sub- > domain. > Import it from [DKIM]. Actually it's even easier to just import "selector" from [DKIM]. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
