On 29/Jun/11 00:10, Hilda Fontana wrote: > This is the first draft of the split out document for the ARF > reporting. Please review and let me know how best to improve it.
I have a bunch of comments. I just place them below and apologize for a lengthy message. Please trim and edit the subject appropriately if replying inline about just a few topics. * Section 1. Introduction I suggest to grab the final paragraph and the "RFCxxxx" list from Murray's Introduction in dkim-reporting. * Section 3.1. Authentication-Results: Why should one include results "for both DKIM and SPF even if those tests were not actually performed"? [AUTH-RESULTS] does not provide for adding result information for a test that was not performed. For example, "dkim=none" means the message had no signature. To indicate that no authentication was performed one may just write "none", but then that's not for either DKIM or SPF. Why should one copy A-R fields from the reported message? The original fields are still available in the message/rfc822 part of the report. It may be interesting to know which one(s) triggered the report generation. The Auth-Failure field just tells its type. The original message may contain multiple A-R fields by multiple authentication servers. We can assume that the triggering A-R field is the topmost one of the given type. The Reporting-MTA won't necessarily match the authserv-id of any A-R field, because [ARF] defines Reporting-MTA as optional and does not provide it with such semantics. We may invent a new "Verifying-MTA", say, for matching purposes. But is this worth? IMHO, the simplest specification is that the feedback-report part contains just the triggering A-Rs, whether or not they are also present in the message/rfc822 part of the report. * Section 3.2. New ARF header fields The first paragraph says they are "extensions to Section 6.2 of [ARF]", which I couldn't find. I'd mention Section 3.1 of [ARF] instead, and quote that such fields "MUST appear exactly once". * Sections 3.2.1 and 3.3. Failure types. How about defining Auth-Failure as "method/token"? The method would have to be a registered authentication method[*], the token could be either the result (e.g. "fail") or a keyword defined by the specific ARF extension document (e.g. "revoked"). [*] http://www.iana.org/assignments/email-auth/email-auth.xml People would be unable to report an "iprev" failure, if they wanted to, because there is no ARF extension for that. If one writes such an extension, it will have to work without requiring this I-D to be modified, won't it? In this case, Section 3.3 should just specify the field semantics, i.e. its last paragraph. It would also be worth to introduce a new section describing the minimal template that a specific ARF extension should instantiate to register itself, if going for this pattern. Anyway, the I-D references Section 3.3 implicitly from Section 3.2.1 ("The list of valid values is enumerated below") and Section 4 ("as specified elsewhere in this memo"). An xref would be useful. DNS errors on retrieving a RR have a different effect for DKIM than for SPF. The inability to retrieve a (valid) DKIM key deserves its own failure type. For a minor issue, the "Auth-Failure" field bears the same name as this Feedback-Type field's value. This is probably bound to generate confusion when one mentions such phrase with the wrong capitalization. * Section 3.2.2. Required For DKIM Reports People involved in reporting spf (or iprev) will not interested in this section. IMHO, it would be better to just mention that each type-specific ARF extension may define further fields, and move these definitions to dkim-reporting. Anyway, the list misses the DKIM-Canonicalized-Body. I wouldn't suggest that such field be required, as it is unneeded if the failure can be located anywhere else, e.g. reporting bad public key syntax. * Section 7.2. Forgeries. We should state that reports should not be recursively generated against authentication failures for auth-failure reports. Possibly, empty envelope sender addresses should inhibit report generation too. * Section 7.5. Reporting Multiple Incidents I don't think this topic belongs to Security Considerations, although part of it does. IMHO, the main issue is to define the semantics of the Requested Report Interval (ri). Each type-specific ARF extension can then reuse it, and limit itself to defining ri's emplacement. I like very much the idea of exponentially growing intervals for groups of nearly-identical failure reasons. Perhaps, such interval type could be indicated by adding a suffix, e.g. "ri=10e"? (BTW, "inverse-exponential" means logarithmic to calculus-oriented readers, which is probably not what we want to mean.) Apps might have problems complying with such specification. For example, setting up a semaphore for permanent storage of per-type failure counts may imply a whole bunch of requirements that an implementation is not prepared or willing to take. What should it do then, send all or none of them? If we want to allow customizing downgraded behavior we can use yet another suffix, e.g. "ri=10e+" to send all reports in case the reporter app is unable to properly manage exponential Report Intervals. Alternatively, we can specify what downgraded behavior is implied. * Section B.1. The Auth-Failure: field is missing in feedback-report. A DKIM-Signature by example.com is missing in the header. We don't require reports to be DKIM-signed, but by signing the example we can express our preference (somewhere between MAY and SHOULD, I'd guess.) _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
