On Tue, 14 Sep 2004, David F. Skoll wrote: > On Tue, 14 Sep 2004, advisories wrote: > > > - It identifies the MIME message as malformed and blocks it. > > - It fails to interpret the MIME field (or message). > > > The first of the two would be the correct behaviour for a security > > conscious product, > > I disagree. There is one, and only one, way for gateway security > products to securely handle MIME messages: > > Build a data structure representing the MIME message, and then throw > away the original message, re-generating a *valid*, well-formed MIME > message from the data structure. > > This method alone guarantees[1] that the security product has exactly > the same interpretation of the message as any other software that > subsequently receives it. It also has the benefit of providing a > "reasonable" interpretation for common MIME errors---blocking all mail > that deviates even the slightest from the official MIME specifications > would result in a significant fraction of all e-mail being blocked. Two points: 1. A quibble. As you implicitly note, both canonicalizing MIME messages and dropping malformed ones are secure approaches. Dropping all incoming messages would also be a secure approach. It's fair to argue that canonicalizing is the more useful policy, but not that it is the only secure one. 2. Your logic sounds convincing, but interposing a proxy that systematically changes incoming messages raises red flags in my mind. Naive obscenity filters have created all sorts of problems doing this sort of thing. Yours is a more sophisticated approach, but I still see the potential for strange interactions between the gateway security product's MIME implementation and those of sending and receiving programs. Have you found this to be a problem, for those who've been using this filter? ----------------------------------------------------------------- David Covin dcovin@xxxxxxxxxxxxxxxxxxx MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA
