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. 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. Regards, Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Atkins Sent: Sunday, July 24, 2011 9:28 PM To: Message Abuse Report Format working group Subject: Re: [marf] FW: Feedback on: ARF feedback typeVirus/_report subdomain On Jul 24, 2011, at 8:28 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Tony Hansen >> Sent: Sunday, July 24, 2011 8:20 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report >> subdomain >> >> I definitely understand the concerns of passing around the malware via >> email. If we feel that they *must* be sent, we *could* encrypt the >> attachment (pick your poison, such as AES), and include the password in >> another header. > > <participant> > I'm less concerned about it. An FBL is typically addressed to a person or a piece of software specifically equipped to handle abusive email, usually by prior arrangement. It's not like the FBL mail containing a piece of malware is being sent scattershot at people that aren't prepared to receive it. > </participant> >From experience, many FBL handlers are behind the primary corporate MX. Often configured to avoid filters. Sometimes not. Sometimes configured to do so until the MX (which is not under control of the people operating the FBL eater) is upgraded or outsourced. If FBL messages contain hostile content they're fairly likely to be silently dropped or quarantined at a small fraction of recipients today. That fraction would probably increase if more organizations than the current selection (ESPs and some ISPs) start to take advantage of them - which is something I'd really like to happen in the case of FBLs based on detection of malware emission. Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
