On Tuesday, October 04, 2011 01:02:13 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Scott Kitterman > > Sent: Tuesday, October 04, 2011 12:48 PM > > To: [email protected] > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > > If we're insisting that we not say you have to report specific ones, > > > then being completely agnostic seems the right path to me. > > > > I don't see how that follows. > > > > Perhaps the method specific stuff needs to move to the method specific > > draft so that if someone wants to (later) do a sender-id draft then the > > can do it. I'd rather ignore it, but I think making it easier for > > someone who cares enough about sender-id (or method foo) can do so > > works too. I don't think overcomplicating the current effort is a good > > idea. > > With the changes you and John proposed to the document in WGLC, the > requirement to report DKIM and SPF results even if you don't check them is > gone, and furthermore you don't have to include the other fields that are > irrelevant to what you did check. It seems to me that leaves us in an > agnostic place with respect to which message authentication methods you're > choosing to execute and report, which satisfies what you and John were > after while also enabling one to report a "sender-id" result. > > What am I missing with this thinking?
I'm not understanding who plans to use sender-id and why add that and not all the other auth-results? Wd do need to define what to do with results for auth-methods one doesn't implement or understand (ignore them). I don't want to force implementers to deal with having to write code for methods they aren't interested in. It's been 5 years since I took a serious look at the Sender ID specs. I do not know how well the SPF modifier proposed in a Sender ID record. There are some subtle differences between the two record types and someone who was interested enough in Sender ID to investigate it should take a look before we move forward on it. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
