------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1004
Summary: demime bug in uuencode detection heuristics
Product: Exim
Version: N/A
Platform: All
OS/Version: All
Status: NEW
Severity: bug
Priority: high
Component: Content Scanning
AssignedTo: tom@???
ReportedBy: ice@???
CC: exim-dev@???
there's a bug in the heuristics in demime.c that is supposed to detect inline
uuencoded content.
i have such an acl entry:
deny message = Malformed MIME container ($demime_reason) (ID:
$message_exim_id)
demime = *
condition = ${if >{$demime_errorlevel}{0}{1}{0}}
control = no_mbox_unspool
this has been working fine for ages, but recently i've been getting reports
that it started rejecting legitimate messages (hence the no_mbox_unspool for
debugging). upon lots of head scratching it turned out that in the
not-too-distant-past some user agents started to mark forwarded messages with a
"Begin forwarded message:" line.
demime.c:mime_check_uu_start() falsely identifies this as the beginning of an
inlined uuencoded part, puts the parser into MIME_UU_MODE_UNCONFIRMED state,
and things then go downhill, as (obviously) whatever follows is rather unlikely
to be actual uuencoded content.
i believe the mime_check_uu_start() should be a bit more strict when deciding
whether a line is really a uu begin block; probably only lines that match
"(?i)^begin\s+[0-7]+\s+\S+$" should be considered one (this is based on what
gnu sharutils seems to consider a valid `begin' line), and perhaps,
circumstances permitting, drawing a final conclusion should be deferred until
the complete message is read (thus a matching "`\nend\n" marker can be
located).
considering that this is also a sort of a security feature to protect less
fortunate clients from parsing not completely good content, there might be
other implications i'm not aware of, but in it's current form the only choice
there is not to reject messages with level 1 errors, because it really is
rejecting perfectly legitimate and real-life messages.
so far i believe this to be triggered by messages that at one point have passed
through a (relatively recent version of) apple mail (desktop or mobile).
i am setting priority to `high' because i'm expecting this to be more and more
of a problem, as updates are applied to apple products and new apple products
are sold (and seems they are sold at a fast pace).
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
