On Tuesday, October 04, 2011 10:15:56 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Scott Kitterman Sent: Tuesday, October 04, 2011 10:06 PM > > To: [email protected] > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > No. I think not. Both paragraph 3.2 and 3.3 have DKIM and SPF specific > > requirements that are not sufficient for other authentication types. > > Yes, the actual header might refer to other types, but without the > > additional diagnostic information in from 3.2/3.3. > > Right. So if you're reporting for DKIM, there are extra provisions included > to allow relaying of meta-data specific to that method. If you want don't > want to report on DKIM, you leave out the relevant fields. If you want to > report on something else, you'd have to craft an update to this document. > > For SPF, I don't think there's any meta-data that needs its own field in > this kind of report, since Authentication-Results would carry that > information already. So we're already there.
Providing the DNS records is what would make this really useful. I'd like to see that required for this report type (as I tried to put in my last mail and John suggested). > > At the very least sender-id would have to be added to the list of > > authentication failure types in 3.3 (I propose we not do this and just > > focus on DKIM/SPF). > > If we want to be complete about it, perhaps 3.3 should become an IANA action > to create a registry for authentication failure types. Then someone > wanting to add support for Sender-ID or some other method could register a > new failure mode and all the various extra fields that it requires (if > any). I think this document could be made more generic pretty easily by leveraging the IANA registries that were created by RFC 5451. I think it's reasonable to allow for reports for any authentication type listed in: http://www.iana.org/assignments/email-auth/email-auth.xml And then result codes would come from: http://www.iana.org/assignments/email-auth/email-auth.xml There is a bit of a problem here that the registry doesn't match the RFC 4408 results exactly (fail versus hardfail). That's a bit unfortunate, but the train has left the station. I think this draft should match 5451 terminology. The only SPF faliure type that I think needs to be broken out is temperror. For that type you want the DNS RCODE and query type (TXT versus SPF) and the domain name being looked up to support trouble shooting. I think that this is probably true for all DNS based auth methods. I don't think another IANA registry is needed. I'd like to see this draft add a method independent response for temperror (as above) that should serve for any auth method. I'd like to see 3.2 have an SPF specific requirement for including the record(s) used to process the message. Later RFCs could deal with other methods listed in the registry and add method specific requirements. Since they would encapsulate the method they were dealing with, I don't think a registry is needed. > But you're probably right (as is John) that "spf" should probably be broken > out, since there are more than one DKIM failure mode enumerated already. > > Does that sound right? Only for temperror (and I don't think that's actually SPF specific) as the DNS record(s) and IP address is what you want for all the other failure types. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
