My problem or bad-header?

Mark Martinec Mark.Martinec+amavis at
Mon Jan 23 19:35:02 CET 2012


> > - disable quarantining of mail with bad headers:
> >    $bad_header_quarantine_to = undef;
> >  or:
> >    $bad_header_quarantine_method = undef;
> > 
> > - allow mail with a bad header to be delivered
> >  (which is a default anyway):
> >    $final_bad_header_destiny = D_PASS;
> It strikes me that either of these is foolhardy.  bad_header checks
> are presumably there for a reason.  And presumably that reason is to
> catch people injecting stuff into headers that shouldn't be there...

Broken headers (intentionally or not) or rarely a security concern.
If there is some malware playing on such trick, it will pretty soon
get detected by other checks (virus and spam scanners, banned checks).

To my eyes the main motivation for header checks is to be able to
have some insight in what garbage is flowing around, but more importantly
to be able to detect and fix some internal (local) sources of such
malformed mail, like broken web mail interfaces, out-of-date mail
clients with known problems, home-brewed scripts producing bad mail.

This is why the default for $final_bad_header_destiny is D_PASS
(not a security risk nor a good malware detector), but bad header
quarantining is true (to be able to analyze and fix such sources
of malformed mail).

> > - disable header checks entirely or by-recipient:
> >    @bypass_header_checks_maps = ( 1 );
> Labour intensive and not scalable...
> > - select (enable/disable) individual header checks:
> >    $allowed_header_tests{'mime'} = 0;
> What's the collateral here - given the presumption above?  This one
> seems to be the sanest, but it would be nice to know what I'm letting
> in if I remove it.

If you see broken mime often and from recognized unfixable sources,
either ignore these warnings of turn off the check. If you can fix it
(or notify the right people to do so), so much the better.

This is from release notes:

- new configuration variable %allowed_header_tests, also member of policy
  banks, allows for selectively disabling some of the header checks,
  e.g. checks for non-encoded 8-bit characters. The %allowed_header_tests
  hash contains all available header test names as its keys by default
  (with a value of true);  removing a key, or setting its value to false,
  disables a test, e.g.:
    $allowed_header_tests{'8bit'} = 0;
    $allowed_header_tests{'missing'} = 0;
  Currently available keys (i.e. test names) are:
    other mime 8bit control empty long syntax missing multiple
  each corresponding to its own minor contents category of CC_BADH;

    ccat test
    min  name      description
    ---  -------   -----------
      0  other     (catchall for everything else, normally not used)
      1  mime      Bad MIME (sub)headers or bad MIME structure
      2  8bit      Invalid non-encoded 8-bit characters in header
      3  control   Invalid control characters in header (CR or NUL)
      4  empty     Folded header field made up entirely of whitespace
      5  long      Header line longer than RFC 2822 limit of 998 characters
      6  syntax    Header field syntax error
      7  missing   Missing required header field
      8  multiple  Duplicate or multiple occurrence of a header field
    ccat min:  minor contents category under a major category CC_BADH,
               available in templates as a macro ccat_min;
    test name: corresponding test name - a key in %allowed_header_tests;
    descr.:    description of a header test or MIME subheaders/structure test;


More information about the amavis-users mailing list