On Jul 24, 2011, at 11:13 PM, Alex Bobotek wrote: > The use of in-band reporting mechanisms (e.g., message/rfc822 atop an > SMTP relay chain), for all their benefits, have some complications. The > complexity may increase with gateways and longer SMTP relay chains. > > MTAs (and gateways) might need to allow uninhibited passage of malign > embedded spam or virus reports (e.g., based on MIME type, destination > address, or some other mechanism). > > MUAs might need to recognize that a message/rfc822 embedded inside a > feedback report may be unsafe for execution/storage. > > Tony's suggested method, encryption with a declared key, strikes me as a > better mechanism than simply requiring special handling of designated > MIME types. An ignorant MUA would be unable to execute malware, and an > ignorant MTA would pass reported messages freely.
Yup. Something with the power and flexibility of ROT13 might suit that well. > IMHO we should shoot for a more extensible/future-proof reporting > mechanism; one that would be more likely to work beyond an ISP1-->ISP2 > over SMTP reporting scenario. The trend is towards more gateways and > increasing delivery path complexity in general. That's not really what ARF is, though. ARF has had significant uptake mostly because it's very simple, and very well suited to it's original role. I'm not sure whether it'll maintain a useful level of uptake if it's made more complex to use, and aimed at roles it's not well suited to. So I'm not sure whether it's the right place to start when crafting something intended to report all sorts of unrelated things via a variety of channels. ( http://xkcd.com/927/ is probably relevant here). Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
