[Bug 6182] New: MPART_ALT_DIFF_COUNT trips on valid Apple Mail messages

[bu...@bugzilla.spamassassin.org]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6182

           Summary: MPART_ALT_DIFF_COUNT trips on valid Apple Mail
                    messages
           Product: Spamassassin
           Version: 3.2.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: Rules
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: ralston@pobox.com


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...

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.