On 16/07/16 15:59, Michael Fox wrote: > So, are there other obvious ways to recognize encrypted contents, other than > "Content-Type: multipart/encrypted"?
Theoretical (and therefore possibly entirely impractical) answer: Encrypted data contains a high amount of entropy, meaning that it does not compress well. So that might be a way to detect encryption. Trouble is, this method would also flag already-compressed data, even if the compression has not been password-protected (and so arguably is not encrypted). So you could try a 2-step process: check whether the data is compressible. If it is, assume that it is not encrypted. If it is not, then check whether you can use the well-known MIME types or file extensions to determine whether it contains compressed attachments. If you can automatically decompress the attachment (i.e. without a password), run the second check again, just to ensure that the decompressed file does not again contain encrypted data. This is expensive and recursive, so possibly open to a DoS attack (unless you can put an upper bound on resource usage of the milter that does this). Unless you also disallow compressed content even if not password-protected, in which case you can omit the second step and therefore the recursion. Furthermore, you would not find steganographically hidden encrypted content this way. Jan
