CF> Your message WAS SUCCESSFULLY RELAYED to:
CF>   <dada@example.net>

CF> This delivery report was generated by the program amavisd-new at host
CF> server.example.net. Our internal reference code for your message is
CF> 13369-14/qbIM9Q2ZHZB7

CF> INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER

CF>   Non-encoded 8-bit data (char E1 hex): Subject: Re[2]: Zpr\341va od
CF>     U\276ivatele[...]

CF> Return-Path: <info@example2.net>
CF> Message-ID: <58749893.20090326182219@argonet.cz>
CF> Subject: Re[2]: Zpráva od U¾ivatele info

CF> WHAT IS AN INVALID CHARACTER IN MAIL HEADER?

CF>   The RFC 2822 standard specifies rules for forming internet messages.
CF>   It does not allow the use of characters with codes above 127 to be
CF>   used directly (non-encoded) in mail header.

CF>   If such characters (e.g. with diacritics) from ISO Latin or other
CF>   alphabets need to be included in the header, these characters need
CF>   to be properly encoded according to RFC 2047. This encoding is often
CF>   done transparently by mail reader (MUA), but if automatic encoding is
CF>   not available (e.g. by some older MUA) it is the user's responsibility
CF>   to avoid the use of such characters in mail header, or to encode them
CF>   manually. Typically the offending header fields in this category are
CF>   'Subject', 'Organization', and comment fields in e-mail addresses of
CF>   the 'From', 'To' and 'Cc'.

CF>   Sometimes such invalid header fields are inserted automatically
CF>   by some MUA, MTA, content checker, or other mail handling service.
CF>   If this is the case, that service needs to be fixed or properly
CF>   configured. Typically the offending header fields in this category
CF>   are 'Date', 'Received', 'X-Mailer', 'X-Priority', 'X-Scanned', etc.

CF>   If you don't know how to fix or avoid the problem, please report it
CF>   to _your_ postmaster or system manager.