My problem or bad-header?

[Simon Brereton]

Makes perfect sense -thanks!

Simon



On 23 January 2012 13:35, Mark Martinec <Mark.Martinec+amavis at ijs.si> wrote:
> Simon,
>
>> > - 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
>  legend:
>    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;
>
>
> Mark