|
|
SA Bugzilla – Full Text Bug Listing |
- Home
- | New
- | Browse
- | Search
- | [?]
- | Reports
- | Help
- | New Account
- | Log In
- | Forgot Password
|
|
|
SA Bugzilla – Full Text Bug Listing |
| Summary: | MPART_ALT_DIFF_COUNT trips on valid Apple Mail messages | ||
|---|---|---|---|
| Product: | Spamassassin | Reporter: | James Ralston <ralston> |
| Component: | Rules | Assignee: | SpamAssassin Developer Mailing List <dev> |
| Status: | NEW --- | ||
| Severity: | minor | CC: | adrianawolf12, jquinn+SAbug |
| Priority: | P5 | ||
| Version: | 3.2.5 | ||
| Target Milestone: | Undefined | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | apple info | ||
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. |
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...