On Feb 10, 2012, at 9:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Scott Kitterman >> Sent: Friday, February 10, 2012 4:16 AM >> To: [email protected] >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >> >> Allesandro provided a scenario that I think is reasonable. If you add: >> >> (i.e. a message with DKIM pass for the same domain) >> >> at the end and change "expected to fail" to "not definitive" I think >> I'm good. > > Slightly different, and assuming I got your proposal right: > > Similarly, if a report generator applies SPF to arriving messages, and that > evaluation produced something other than a "Pass", "None" or "Neutral" > result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be > generated as it might be a forgery and thus not actionable. A valid > exception would be specific knowledge that the SPF result is not definitive > for that domain under those circumstances (e.g., a message that is also > DKIM-signed by the same domain, and that signature validates). > > That work?
We're imposing an awful lot of detailed micromanagement on an application developer that's probably making assumptions about the heuristics they chose for their app that aren't generally applicable, and generally discussing detailed implementation decisions about something we're not developing (and, mostly, have little experience developing). Can we just say what we'd like the end result to be, and leave it to the developer to make the choices needed to get there? Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
