| Server IP : 85.214.239.14 / Your IP : 216.73.216.99 Web Server : Apache/2.4.65 (Debian) System : Linux h2886529.stratoserver.net 4.9.0 #1 SMP Mon Sep 30 15:36:27 MSK 2024 x86_64 User : www-data ( 33) PHP Version : 8.2.29 Disable Function : NONE MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : OFF Directory : /proc/3/task/3/cwd/proc/3/cwd/proc/3/cwd/usr/share/doc/amavisd-new/ |
Upload File : |
# Problem description
Emails which consist of multiple parts (`Content-Type: multipart/*`)
incorporate boundary information stating at which point one part ends and the
next part begins.
A boundary is announced by an Content-Type header's `boundary` parameter. To
our current knowledge, RFC2046 and RFC2045 do not explicitly specify how a
parser should handle multiple boundary parameters that contain conflicting
values. As a result, there is no canonical choice which of the values should or
should not be used for mime part decomposition.
It turns out that MIME::Parser from MIME-tools chooses the last `boundary`
parameter of a Content-Type-header, while several mail user agents choose the
first occuring one. As a consequence, Amavis will apply some of its routines to
content that a receiving MUA will not see, and vice-versa will not apply them
to content that the receiving MUA will see. Such routines are at least
- the banned-files check, and
- the virus check, unless
- Amavis feeds the whole email into the virus scanner, and
- the virus scanner implements its own email parsing that aligns with the
receiving MUA's parser implementation.
MIME::Parser does not provide a choice which of multiple `boundary` parameters
shall be used for parsing, but it will give feedback in such a case [1], which
Amavis can react to.
Emails with ambiguous content, like multiple `boundary` parameters as described
above, will be categorized as `CC_UNCHECKED,3`, since Amavis has no information
about the recipient's MUA's parser implementation.
# Recommendation
Legitimate emails are not expected to have ambiguous content, so an Amavis setup
should treat them harshly. The new default configuration for `CC_UNCHECKED,3` is
defanging:
```
$defang_by_ccat{CC_UNCHECKED.",3"} = 1; # ambiguous content (e.g. multipart boundary)
```
Another possibility would be quarantining, e.g. via
```
$quarantine_to_maps_by_ccat{CC_UNCHECKED.",3"} = [1];
$quarantine_method_by_ccat{CC_UNCHECKED.",3"} = 'local:unchecked-ambiguous-%m';
```
and/or discarding/rejecting the email:
```
$final_destiny_maps_by_ccat{CC_UNCHECKED.",3"} = D_REJECT; # or D_DISCARD
```
[1] https://metacpan.org/release/DSKOLL/MIME-tools-5.514/changes