SA Bugzilla – Bug 6182
MPART_ALT_DIFF_COUNT trips on valid Apple Mail messages
Last modified: 2021-04-17 04:19:46 UTC
We've recently (as of 2009-06 and 2009-07) received valid ham messages for which the MPART_ALT_DIFF_COUNT test fires. The X-Mailer header is: X-Mailer: Apple Mail (2.935.3) The problem is that the user replied to a message with this MIME structure: multipart/signed multipart/mixed text/plain text/rtf text/plain application/pgp-signature When the sender did so, Apple Mail constructed a message like this: multipart/signed multipart/alternative text/plain* multipart/mixed text/html* text/rtf text/html application/pgp-signature The asterisks denote the parts that were different encodings (text/plain versus text/html) of the same content. Of course, the sane thing to do would've been this: multipart/signed multipart/mixed multipart/alternative text/plain* text/html* text/rtf text/html application/pgp-signature But alas, that's not what "Apple Mail (2.935.3)" did. :( Is there any chance that the MPART_ALT_DIFF_COUNT could be tweaked to avoid penalizing Apple Mail's stupidity? Alas, I cannot attach the original messages, but I could manually construct sample messages with the same bizarre MIME structure...
Created attachment 5403 [details] apple info
Don't spam the list with irrelevant attachments.
Meant to say the bug tracker, but it's also spamming the dev list.
Not a bug. Rules hitting some ham are to be expected. MPART_ALT_DIFF_COUNT is currently scored well below the threshold for all 4 rulesets, so no action is needed. Had there been a shareable sample which scored over 5 when this was submitted, it may have merited attention to limit the score to a lower level or perhaps even adapt to what Mail.app was doing at that time, but no sample exists. Also, in a dozen years of inaction, this may not even be an issue of any sort as both Mail.app and SpamAssassin have advanced substantially.