David, Your second option, although widely implemented by lots of SMTP solutions, could cause more problems than it solves. I believe that if the message isn't RFC-compliant and coded correctly, it should be rejected, period. Because of how different vendors would implement #2 will allow maliciously-crafted messages to eventually get around defenses. Good security before ease-of-use. And in some cases, sticking to the RFC's will lead to better security in the first place. Example, Microsoft actually had some bragging rights during the MyParty worm attack last month. Because Exchange was RFC-compliant, it rejected outgoing attempts by the worm. Some have guessed that the worm's non-RFC coding was designed to sneak around email-based virus scanners that didn't know how to "re-build" the message "correctly" and find the worm. Roger *************************************************************************** *Roger A. Grimes, VP of IT for GK/PHR Holding Company *Gold Key Resorts and Professional Hospitality Resources *email: rogerg@goldkeyresorts.com *ph: 757-491-2101 x403 *fax:757-491-6550 *932 Laskin Road, Virginia Beach, VA 23451 *Author of Malicious Mobile Code: Virus Protection for Windows by O'Reilly *http://www.oreilly.com/catalog/malmobcode/ *************************************************************************** -----Original Message----- From: David F. Skoll [mailto:dfs@roaringpenguin.com] Sent: Monday, February 18, 2002 10:02 AM To: Valentijn Sessink Cc: bugtraq@securityfocus.com Subject: Re: Non existing attachments, more info On Sat, 16 Feb 2002, Valentijn Sessink wrote: > A couple of people seemed to think that simply interpreting all <CR>'s with > <CRLF>'s should solve the issue, however, that makes things worse, as the > scanner will now be forced to look "the outlook way". I initially made my scanner emulate the Outlook bug; now I see it's the wrong thing to do. I believe the only sane way to handle these kinds of malformed messages is: 1) Reject any message with suspicious characters in the headers (e.g., embedded CR's.) It's pointless for a server-based scanner to try to out-think all the different mail user agents out there. 2) Completely rebuild all incoming messages. The server-based scanner should parse the MIME as best it can, build its own data structure, and then rebuild the message using valid MIME. That way, MUA's are quite likely to "see" the same message that the scanner did. I have implemented these procedures in MIMEDefang; see http://www.roaringpenguin.com/mimedefang/lookout.html for more details. Regards, David.
