Re: [AMaViS-user] Encoding problem

[Mark M. <Mar...@ij...>]

Virna,

You are comming across some interesting problems recently :)

| As I had mentioned in one of my earlier emails to the list, some of the
| mail messages were hanging in the postfix queue due to amavisd not
| accepting them. I have X-Spam-Report turned on for all messages going
| through amavisd. Further investigation revealed that the following code
| *hangs*(note arrows) when trying to process a particular type of message:
| 
| sub hdr($$;$) {
|     my($field_name, $field_body, $structured) = @_;
|     if ($field_name =~ /^(X-.*|Subject|Comments)$/i &&
|         $field_body =~ /[^\011\012\040-\176]/ # nonprintable ...
|     ) { # encode according to RFC 2047
|         $field_body =~ s/\n[ \t]/ /g;  chomp($field_body);   # unfold
| >>>        my($field_body_octets) = !$unicode_aware ? $field_body
| >>>            : Encode::encode($hdr_encoding, $field_body);
|         $field_body = MIME::Words::encode_mimeword($field_body_octets,
|                                                    'Q', $hdr_encoding);
| Further, if I change the call to Encode::encode with a third (CHECK=1)
| argument like so:
|           my($field_body_octets) = !$unicode_aware ? $field_body
|               : Encode::encode($hdr_encoding, $field_body,1);
| then I get the following output in amavis.log:
|   May 29 14:53:19 foo.bar.com amavisd[5848]: (05848-01) TROUBLE in
|   check_mail: forwarding FAILED: "\\x{03f0}" does not map to iso-8859-1
|   at /usr/local/lib/perl5/5.8.0/i86pc-solaris/Encode.pm line 140,
| 
| Clearly, in this case the $field_body for X-Spam-Report is not able to get
| processed by the call to encode and it hangs. The same code can presumably
| hang for other headers with malformed $field_body.

It should have mapped those characters to '?', or so I believed.
If it hangs, it is a bug in Perl, one more in the bag of UTF-8 bugs. Sigh,

| One thing I am trying to understand is why amavisd wants to encode the
| field_bodies if it contains non-Ascii characters?

Because rfc2822 requires it to do so (or better yet: does not allow
non-ASCII characters in headers), and rfc2047 tells how to do it.

See also the the bad_headers.patch in the 20030314 distribution
and the explanatory text in RELEASE_NOTES:

- make available an experimental patch (file: bad_headers.patch,
  not applied by default), which, ...


See if it helps to set environment variables LANG and LC_ALL to "C"
before starting amavisd. Other workarounds welcome.

  Mark