Le 16/07/2016 à 16:49, Jan Ceuleers a écrit : > 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 > I think that pursuing this way you will arrive to allowing only text/plain messages.
And use some natural language testing on it because any base64 encoded content can be announced as text/plain
