https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7358
Mark <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from Mark <[email protected]> --- I've reduced the structure to essentials, with added boundary level commentary. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" <-- 1st boundary --BOUNDARY <-- 1st boundary Content-Type: multipart/alternative; boundary="BOUNDARY" <-- 2nd boundary --BOUNDARY <-- 2nd boundary Content-Type: text/plain --BOUNDARY <-- 2nd boundary Content-Type: text/html --BOUNDARY-- <-- 2nd boundary close --BOUNDARY <-- 1st boundary Content-Type: application/zip; name="file.zip" Content-Transfer-Encoding: base64 --BOUNDARY-- <-- 1st boundary close Problem: MIME boundary named "BOUNDARY" is defined twice. The message has two identical closing boundaries. MIME is nested. The MIME structure is supported in the real world (e.g. Thunderbird, Windows Live Mail 2011) and the attachment is shown and accessible. I am not a SA user, and I haven't looked thoroughly at the code. It appears it's implemented like this: 1. search for boundary 2. search for closing boundary and use this as an end marker. The most elegant solution would be to follow nested declarations first and then go back up the structure to the first level to continue parsing. Another possible solution would be to interpret closing boundaries just like (empty) opening boundaries or MIME part endings. This way the structure is interpreted as flat and it does not stop searching after the first closing boundary. If there are any more MIME parts using the same boundary, they can be parsed. With the limited knowledge I have about SA, I'd check the last solution. It may have side effects in some rules similar to those described in bug 3749. -- You are receiving this mail because: You are the assignee for the bug.
