https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7358
--- Comment #8 from John Woods <jwo...@greatplainsmfg.com> ---
Looks as if I didn't know what I was talking about... After looking through
Message.pm, and reading parts of RFC 1521, I'd like to scratch my previous
comment...
In RFC 1521, Section 7.2.1, it says this:
The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow. Such a delimiter is identical to the previous
delimiters, with the addition of two more hyphens at the end of the
line:
--gc0p4Jq0M2Yt08jU534c0p--
There appears to be room for additional information prior to the
first encapsulation boundary and following the final boundary. These
areas should generally be left blank, and implementations must ignore
anything that appears before the first boundary or after the last
one.
So, any content that follows the --{boundary}-- marker is considered an
"epilogue" area, and must be ignored.
That explains why RW's claw mail utility ignored the epilogue, because claws
MUA was processing the e-mail per RFC 1521.
In this case, it was an attachment with malware. And the MUA(s) Thunderbird and
Outlook 2016 fail to follow RFC to the letter of the law, and malware
potentially infects the workstation.
On a positive note, SpamAssassin properly detected that the epiloque area
existed, and T_TVD_MIME_EPI is in the result.
Is this analysis correct?
--
You are receiving this mail because:
You are the assignee for the bug.
