On Jun 29, 2011, at 9:44 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of J.D. >> Falk >> Sent: Wednesday, June 29, 2011 7:24 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt >> >> If Delivery-Result: is required, then I expect we'll see a lot (perhaps >> a majority) of implementations being intentionally non-standard and >> omitting it anyway. Mailbox providers tend to be /very/ touchy about >> who they'll share exact delivery results with, and for good reason: the >> bad guys have lots of incentives to try to trick their way into >> delivery feedback results that they can use to tune their spamming >> systems. >> >> I'd urge making that an optional field, or possibly include a >> null/refused value. > > Just to be clear, you mean that in the context of auth-failure reports > specifically, and not ARF in general?
I was only thinking about the auth-results context for now, but I'd imagine I'll make a similar point for /any/ ARF extension that tries to convey the results of a post-receipt (after 250) spam filtering module. This is from experience, not philosophy. > I'm thinking if you're willing to update your feedback generation system to > support auth-failure reports, then you understand what's involved and would > be willing to do this as well. But I don't run an FBL myself (yet) so I > admit this is speculation. Getting into philosophy now, I think that conflating authentication results with inbox/spam folder placement is a layer violation. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
