On Wed, Jun 29, 2011 at 7:25 AM, Alessandro Vesely <[email protected]> wrote:
> 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. > for automation it would be useful for the headers to be standard - so if dkim was not checked perhaps dkim="" would be preferable to dkim=none - to your point above but I think its worth including to try to standardize the format > > > * 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.) > ok > > _______________________________________________ > marf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/marf > -- Hilda L Fontana VP, Technology eCert, Inc. One Market Street, Suite 3600 San Francisco, CA 94105 p: 626.676.8852 f: 415.651.8932 **eCert - Trust the MessageTM *www.ecertsystems.com* <http://www.ecertsystems.com/> * * ---------------------------------------- CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIAL and is intended only for the use of the addressee. Any unauthorized use, disclosure, distribution, dissemination, or copying is strictly prohibited and may be unlawful. If you are not the intended recipient, you are prohibited from any further viewing of the e-mail or any attachments or from making any use of the e-mail or attachments. If you believe you have received this e-mail in error, please notify us immediately and permanently delete the e-mail, any attachments, and all copies from any drives or storage media and destroy any printouts of the e-mail or attachments and any copies of such printouts. Thank you for your cooperation. <http://www.ecertsystems.com/>
_______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
