# 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
