> This method alone guarantees [for software that correctly > interprets well-formed MIME] that the security product > has exactly the same interpretation of the message as any > other software that subsequently receives it. There are a number of logical flaws in your reply, but lets focus on the statement above (I've added the caveat inline for brevity): Firstly, this statement presupposes that there is a single (or at least consensus) way of defining what well-formed MIME is. This just isn't so. There is, for example, no clear guidance on what an agent should do when it receives duplicate fields. RFC822 states "This specification permits multiple occurrences of most fields. Except as noted, their interpretation is not specified here, and their use is discouraged". Because there are multiple fields, there are now multiple interpretations of the same mailbody; you can not produce a single canonical version; you must make a choice. If you choose to detect the multiple occurrences and discard the mailbody at this point (as I have suggested) then the story ends here. If however, you choose to interpret the mailbody (as you have suggested) then at some point you must select one of the possible interpretations to deliver to the ultimate recipient (or you choose to deliver them all, passing on the attack unhindered). The point being that whatever you now choose is arbitrary, and will not be the same as a significant percentage of the receiving agents. Secondly, logic being what it is, the inverse of your statement is also true; the model you have described doesn't only rely on the receiving agent correctly interpreting well-formed MIME, it depends on in *not* interpreting anything that the security product also does *not*. As a simple example, if your security product's interpreter identifies the source mailbody as plain-text and simply places this into your destination mailbody, then it will have passed on the malformed body unimpeded. If the receiving agent interprets it as a valid MIME construct, your security product has failed. Thirdly, the statement assumes that the algorithm that you use to interpret the source mailbody is itself not subject to any flaws. Developing perfect code is a non-trivial task (as a quick browse through the MIMEDefang changelog will show). Although this, of course, applies to any security product that you put in this place, it does somewhat undermine your specific guarantee. > [The rest of the advisory read like a press release or > marketing paper, so it is deleted.] Granted, although I suspect that the irony of you plugging your own product throughout your reply is lost on you. Regards, Martin O'Neal
