Improper folded header

[Mark Martinec]

Simon,

> Lately I've been getting a lot of these..
> 
> /var/spool/mail/quarantine/badh-x9ylzx+MCHZB
> ---
> Return-Path: <jaxbar at example.com>
> Delivered-To: bad-header-quarantine
> X-Envelope-From: <jaxbar at example.com>
> X-Envelope-To: <pj at example.net>
> X-Envelope-To-Blocked:
> X-Quarantine-ID: <x9ylzx+MCHZB>
> X-Amavis-Alert: BAD HEADER SECTION Improper folded header field made up
>         entirely of whitespace (char 09 hex): Subject:
>         ...IMOgIHVuIGLD?=\n\t=?UTF-8?B?qWLDqSBzaW5nZSAh?=\n\t
> X-Spam-Flag: NO
 
> Does anyone know which/what client causes this, and how?

Look at the User-Agent or X-Mailer or the last Received header fields
in a quarantined message. Some poorly designed mailers have trouble
wrapping a long header field they generate, commonly a Subject or
References or a To header field.

The
  IncrediMail
seems the be the most persistent offender.

Also seen in:
  Thunderbird 2.0.0.24 (Windows/20100228)
  Synapse

and in some genuine mail from
  redmond.corp.microsoft.com
and
  ieee.org
probably caused by some broken proprietary mailing list, or
webmail or a remailer ("SMTP serializer", whatever that means).

> What is the potential exploitable value of this?
> I.e. if I set amavis to ignore this, what risk do I run
> (even highly theoretical).

The risk is that some non-compliant MUA or mail filter may
inappropriately think the mail header ends at an
all-whitespace line, thus opening a possibility than an
end-user will see a different mail haeder (e.g. Subject, From, ...)
than a mail filter. It is probably not a significant security
risk, but widens a possibility for social engineering / fraud
and spam. If a Content-Type header field ends up being pushed
into a mail body, the MIME structure will not be poperly
decoded and displayed by a MUA.

I'd say if such mail is originating from your users it is
worth investigating and fixing a cause. For other inbound
mail it's probably not worth worrying.

  Mark