Invalid Character code in header

nodrog · Post by **nodrog** » Thu Dec 20, 2018 12:34 pm

Hi

I am currently trialling the Network edition with a view to replacing our exchange servers.
We use an external email service for spam/malware filtering (Mimecast) which forwards the filtered emails on to our exchange servers. I have configured a single email address in Mimecast to forward straight to my test Zimbra server.

Whilst all of the emails are delivered to Zimbra server, a large proportion of them (around 85%) show as an attachment to a warning email stating:

Code: Select all

WARNING: bad headers - Improper use of control character (char 0D hex):
 Authentication-Results: relay.mimecast.com;        spf=pass smtp.[...]

Character code 0D is the carriage Return.

If I look at the email header from Mimecast for the email verification from this Zimbra forum it shows the following:

Code: Select all

Subject: =?UTF-8?B?V2VsY29tZSB0byAiWmltYnJhIEZvcnVtcyI=?=
To: =?UTF-8?B?bm9kcm9n?= <me@here.com>
From: <forums-noreply@zimbra.com>
Reply-To: <forums-noreply@zimbra.com>
Sender: <forums-noreply@zimbra.com>
MIME-Version: 1.0
Message-ID: <b8c8b587e18921d09ac4708281d9339f@forums.zimbra.org>
Date: Thu, 20 Dec 2018 12:09:28 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And again the header as it appears in my Zimbra client:

Code: Select all

Received: from eu-smtp-1.mimecast.com (eu-smtp-delivery-1.mimecast.com [91.220.42.227])
	by zimbra.msqpartners.com (Postfix) with ESMTP id DB158120A9B
	for <me@here.com>; Thu, 20 Dec 2018 12:08:41 +0000 (UTC)
Received: from edge01e.zimbra.com (edge01e.zimbra.com [52.7.157.95]) (Using
 TLS) by relay.mimecast.com with ESMTP id
 uk-mta-139-UHQH0sFTOROjoVK-LlYeuQ-1; Thu, 20 Dec 2018 12:08:38 +0000
Received: from localhost (localhost [127.0.0.1])
	by edge01e.zimbra.com (Postfix) with ESMTP id 89D741338CC
	for <me@here.com>; Thu, 20 Dec 2018 07:08:35 -0500 (EST)
Received: from edge01e.zimbra.com ([127.0.0.1])
	by localhost (edge01e.zimbra.com [127.0.0.1]) (amavisd-new, port 10032)
	with ESMTP id oOPfHohQkWhe for <me@here.com>;
	Thu, 20 Dec 2018 07:08:34 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by edge01e.zimbra.com (Postfix) with ESMTP id C64E31338CD
	for <me@here.com>; Thu, 20 Dec 2018 07:08:34 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 edge01e.zimbra.com C64E31338CD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zimbra.com;
	s=C2AA288C-EE47-11E2-9BB0-E820BDD9BDBF; t=1545307714;
	bh=LHPwe17f5Jy0qYER4IZki/lrO3wPdBqhSs5DT4Fsb+4=;
	h=To:From:MIME-Version:Message-ID:Date;
	b=QNiFEkihM2mFiWEwWETgkRWK1CVBnIkBOgqAUG0TViFtnUFIsZRXzTTJhzWWToK9S
	 qcd8W6fx3Ik2uKTMUsREp8/Y1JhseKmKTPYCUOPeFIoQ34h6B7enp8aWfcfFi10Gon
	 dK2pvKeq1Y49FD1Im8eQhsjAcj4zVDrP4Iyyw5w4=
X-Virus-Scanned: amavisd-new at zimbra.com
Received: from edge01e.zimbra.com ([127.0.0.1])
	by localhost (edge01e.zimbra.com [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id G3G4p-8IizUg for <me@here.com>;
	Thu, 20 Dec 2018 07:08:34 -0500 (EST)
Received: from web02e (ec2-52-5-150-234.compute-1.amazonaws.com [52.5.150.234])
	by edge01e.zimbra.com (Postfix) with ESMTPSA id 9E9FB1338CC
	for <me@here.com>; Thu, 20 Dec 2018 07:08:34 -0500 (EST)
Subject: =?UTF-8?B?V2VsY29tZSB0byAiWmltYnJhIEZvcnVtcyI=?=
To: =?UTF-8?B?bm9kcm9n?= <me@here.com>
From: <forums-noreply@zimbra.com>
Reply-To: <forums-noreply@zimbra.com>
Sender: <forums-noreply@zimbra.com>
MIME-Version: 1.0
Message-ID: <b8c8b587e18921d09ac4708281d9339f@forums.zimbra.org>
Date: Thu, 20 Dec 2018 12:09:28 +0000
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: phpBB3
X-MimeOLE: phpBB3
X-phpBB-Origin: phpbb://forums.zimbra.org
X-AntiAbuse: Board servername - =?UTF-8?B?Zm9ydW1zLnppbWJyYS5vcmc=?=
X-AntiAbuse: User_id - 1
X-AntiAbuse: Username - =?UTF-8?B?QW5vbnltb3Vz?=
X-AntiAbuse: User IP - 109.231.197.210
X-MC-Unique: UHQH0sFTOROjoVK-LlYeuQ-1
Authentication-Results: relay.mimecast.com;	spf=pass smtp.mailfrom=forums-noreply@zimbra.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Impersonation-Protect: Policy=Standard Impersonation Protection Definition;Similar Internal Domain=false;Similar Monitored External Domain=false;Custom External Domain=false;Mimecast External Domain=false;Newly Observed Domain=false;Internal User Name=false;Reply-to Address Mismatch=false;Targeted Threat Dictionary=false;Mimecast Threat Dictionary=false;Custom Threat Dictionary=false;
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I believe it is the Authentication-Results line that is causing the problem.
At the moment this is hampering the trial as I cannot deploy to test users when the majority of emails are not coming through properly.

So, is this an issue with Mimecast? If it is I suspect it will be a long winded issue to resolve.
Is it possible to disable the check in Zimbra?

Any suggestions appreciated.

Thanks

JDunphy · Post by **JDunphy** » Thu Dec 20, 2018 3:42 pm

That is odd...They should have a NL also after that CR...
This is amavis which is what drives the virus checking, spamassassin, and does some validation/checks, etc itself so I'll point you to where you can disable this and search for additional information. I have never seen this error myself.

Code: Select all

grep defang_by_ccat /opt/zimbra/conf/amavisd.conf

I believe you need to comment or set this to 0 and restart amavis

Code: Select all

$defang_by_ccat{CC_BADH.",3"} = 1;  # NUL or CR character in header

Here are other categories:

Code: Select all

# minor categories to CC_BADH:
#   0: other,  1: bad MIME,  2: 8-bit char,  3: NUL/CR,  4: whitespace line,
#   5: long line,  6: syntax,  7: missing req. field,  8: multiple field

#$defang_by_ccat{&CC_BADH.",1"} = 1; # bad MIME syntax
#$defang_by_ccat{&CC_BADH.",2"} = 1; # non-encoded 8-bit character
#$defang_by_ccat{&CC_BADH.",3"} = 1; # NUL or CR
#$defang_by_ccat{&CC_BADH.",4"} = 1; # all-whitespace line
#$defang_by_ccat{&CC_BADH.",5"} = 1; # long header line
#$defang_by_ccat{&CC_BADH.",6"} = 1; # header field syntax error
#$defang_by_ccat{&CC_BADH.",7"} = 1; # missing required field
#$defang_by_ccat{&CC_BADH.",8"} = 1; # multiple field where at most one allowed
#$defang_by_ccat{&CC_BADH} = 0;  # turn off for CC_BADH,*

ref: https://sourceforge.net/p/amavis/mailma ... e/1206842/
https://sourceforge.net/p/amavis/mailma ... /17353276/

You could also turn off the entire checking as a last resort but you would lose a lot of features IMO.
https://wiki.zimbra.com/wiki/How_to_byp ... ith_amavis

nodrog · Post by **nodrog** » Thu Dec 20, 2018 4:33 pm

Thank you.
That sounds just what I am looking for. I will give it a go this evening.

king0770 · Post by **king0770** » Thu Dec 20, 2018 4:52 pm

You could turn on amavisBadHeaderLover for the domain.

zmprov md example.com amavisBadHeaderLover TRUE

L. Mark Stone · Post by **L. Mark Stone** » Thu Dec 20, 2018 6:50 pm

That's very odd. I'm a Mimecast Partner and I would recommend you open a Support Case with Mimecast. I haven't seen that before.

nodrog · Post by **nodrog** » Fri Dec 21, 2018 11:57 am

Thank for all your help guys.

Here's a strange one...
I amended and set this to 0 in amavisd.conf:

Code: Select all

$defang_by_ccat{CC_BADH.",3"} = 1;  # NUL or CR character in header

However when I reboot the server it reverts back to a 1

Do I need to add it to amavisd-custom to prevent it getting overridden?

Also turning on amavisBadHeaderLover seems to have no effect either.
Still getting the bad header warnings through.

nodrog · Post by **nodrog** » Fri Dec 21, 2018 1:40 pm

Apparently the amavis.conf file is generated by a cron job from amavisd.conf.in
Amending the latter file has made it persistent.

L. Mark Stone · Post by **L. Mark Stone** » Fri Dec 21, 2018 1:55 pm

nodrog wrote:Apparently the amavis.conf file is generated by a cron job from amavisd.conf.in
Amending the latter file has made it persistent.

A large percentage of Zimbra's components' configuration files are rewritten upon starting Zimbra up, as well as when the zmconfigd daemon observes a change.

For a bit of history trivia, in Zimbra's earlier days the majority of the configs that were not stored in localconfig were stored in *.in files. Over time, the use of *.in files was deprecated in favor of other mechanisms, but a few remain. amavisd.conf.in is one of them.

When you do a Zimbra version upgrade, amavisd.conf.in will be rewritten with the newer version bundled with the later version of Zimbra, so it's a good idea to document your amavisd.conf.in customizations now, and add them to your Zimbra upgrade work plan. Indeed, to make such changes persistent across Zimbra upgrades as I understand it was one of the primary drivers that spurred the move away from using .in files.

Hope that helps,
Mark

JDunphy · Post by **JDunphy** » Fri Dec 21, 2018 5:09 pm

nodrog wrote:Apparently the amavis.conf file is generated by a cron job from amavisd.conf.in
Amending the latter file has made it persistent.

Yes a reboot will eventually call zmamavisdctl. Note this might help in the future as you experiment. If you restart it like this - adding "norewrite":

Code: Select all

% su - zimbra
% [zimbra@tmail ~]$ /opt/zimbra/bin/zmamavisdctl restart norewrite
Stopping amavisd... done.
Stopping amavisd-mc... done.
Starting amavisd-mc...done.
Starting amavisd...done.

Because of this in the start section in zmamavisdctl... any argument after start or restart will force it not to rewrite your config files when you are testing.

Code: Select all

      if [ x$2 = "x" ]; then
        rewriteconfig
      fi
      /opt/zimbra/common/sbin/amavisd -X no_conf_file_writable_check -c \
        /opt/zimbra/conf/amavisd.conf &

Here is the entire thing played out.

Code: Select all

# su - zimbra
[zimbra@tmail conf]$ ls -lt amavisd.conf
-r--r----- 1 zimbra zimbra 39743 Dec 21 08:11 amavisd.conf
[zimbra@tmail conf]$ /opt/zimbra/bin/zmamavisdctl restart nodrog
Stopping amavisd... done.
Stopping amavisd-mc... done.
Starting amavisd-mc...done.
Starting amavisd...done.
[zimbra@tmail conf]$ ls -lt amavisd.conf
-r--r----- 1 zimbra zimbra 39743 Dec 21 08:11 amavisd.conf
[zimbra@tmail conf]$ /opt/zimbra/bin/zmamavisdctl restart    
Stopping amavisd... done.
Stopping amavisd-mc... done.
Starting amavisd-mc...done.
Starting amavisd...done.
[zimbra@tmail conf]$ ls -lt amavisd.conf
-r--r----- 1 zimbra zimbra 39743 Dec 21 08:25 amavisd.conf

To continue your understanding...
Note that zmprov modifies ldap variables and amavisd logic can change depending on those variables which is why it is permanent across upgrades and desirable when possible as Mark mentions.
Zimbra has a tool that can rewrite config files and observe things changing to rewrite them... You can see what variables and files it thinks in this location. (sticking with amavis)

Code: Select all

% ls /opt/zimbra/conf/zmconf*  /opt/zimbra/conf/attrs
ls /opt/zimbra/conf/zmconf*  /opt/zimbra/conf/attrs
/opt/zimbra/conf/zmconfigd.cf  /opt/zimbra/conf/zmconfigd.log4j.properties

/opt/zimbra/conf/attrs:
amavisd-new-attrs.xml  zimbra-attrs.xml  zimbra-ocs.xml

/opt/zimbra/conf/zmconfigd:
postfix_content_filter.cf          smtpd_relay_restrictions.cf
smtpd_end_of_data_restrictions.cf  smtpd_sender_login_maps.cf
smtpd_recipient_restrictions.cf    smtpd_sender_restrictions.cf

If you look inside amavisd-new-attrs.xml, you can see some of the things that Rick mentioned such as amavisBadHeaderLover. Other examples would be to allow email unchecked for viruses or spam to users, value of scoring where spam is sent to the users junk folder, etc.

It is a pretty flexible system and most of the services work this way. The command line admin interfaces have great flexibility and most things can be done as a result if the admin console is lacking to a specific problem ...So it has a little bit of a learning curve to figure out how the pieces fit together but between support, the wiki ("how to articles"), and these forums, there has been a ton of sharing over the years to most problems people have run into. Once you have solved your problem in this post, if you could edit your title as Solved that will help future admins looking for answers.

philreynolds16 · Post by **philreynolds16** » Mon Feb 25, 2019 7:31 pm

nodrog wrote:Apparently the amavis.conf file is generated by a cron job from amavisd.conf.in
Amending the latter file has made it persistent.

So did that fix your bad headers problem?

Zimbra Forums

Invalid Character code in header

Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header

Re: Invalid Character code in header