Bypass amavis scanning of locally generated mail on a dual Sendmail system

Andy Harrelson aharrelson at
Tue Nov 6 17:57:34 CET 2012

Hi all,

I had been running amavisd-new in conjunction with a dual Sendmail setup 
(outlined in 
for several months when I decided that I wanted locally generated mail to 
bypass the amavis spam/virus scanning process. This is on a web/mail server 
that I monitor closely. There are no other users that I do not personally 
know, so my fear of spam and/or virus contaminated emails being sent out 
from this box are minimal.

I send out a lot of mail that is generated locally on this server in an 
autoresponder-like fashion. That is to say, almost every incoming piece of 
mail will generate an outgoing piece of mail in response. Given that I 
implicitly trust the source, I thought that it was silly to increase the 
load on this machine by burdening amavis with scanning all of this outbound, 
locally generated mail. I figured that I couldn't be the only one using an 
amavis dual Sendmail setup who wanted to bypass scanning of locally 
generated outbound mail, so I began my Google search in earnest.

If you're reading this, then you probably discovered what I discovered: 
turns out that most people who use amavisd-new also use Postfix, not 
Sendmail. If I had wanted instructions for bypassing amavis scanning using 
Postfix as an MTA, I would have had no trouble finding them. However, I 
needed a solution that would work with Sendmail, so I kept looking. And 

Long story short, I never found exactly what I was looking for on the 'net, 
but through a little trial and error, I did find a solution that works. So 
for anyone else who has been frustrated by a lack of information on the 
subject, here's what I ended up doing:


You'll be making changes to two configuration files: the Sendmail 
file (/etc/mail/ and by extension, /etc/mail/ and the 
amavisd config file (/etc/amavisd.conf). Back them up before you go any 
further. If the changes I outline here don't work for you, just restore 
these two files (or in the case of, run m4 on it), then restart 
both Sendmail and amavisd and you should be back to normal.


In Sendmail, locally generated/submitted mail behaves according to the 
definitions and features specified in You will need to define a 
new mailer in your that will forward mail to amavisd on a 
non-standard port, say 10034. You can then modify your amavisd.conf to 
listen to this new port and set up an amavis policy bank to handle all mail 
being sent there.

Open your and append the below snippet. You can name the mailer 
whatever you want. I just thought that "amavis_bypass" was pretty 
descriptive. You may notice the "z" on the end of the F= equate in the below 
mailer definition. I added this to make Sendmail use LMTP, just like the 
default setup of MTA-RX written by Mark Martinec and linked above. If you 
don't want LMTP, just remove the "z" and your Sendmail MSP (Message 
Submission Program) will speak SMTP. Change the port on the last line of the 
mailer definition to whatever you want. I chose 10034.

dnl # AMAVIS_BYPASS - mailer definition used to bypass amavis scanning
Mamavis_bypass,         P=[IPC], F=mDFMuXaz, S=EnvFromSMTP/HdrFromSMTP, 
R=EnvToSMTP, E=\r\n, L=990,
             A=TCP $h 10034

define(`MAIL_HUB', `amavis_bypass:[]')
define(`SMART_HOST', `amavis_bypass:[]')
define(`LOCAL_RELAY', `amavis_bypass:[]')

The MAIL_HUB, SMART_HOST, and LOCAL_RELAY definitions above tell the 
Sendmail MSP to forward all mail it receives to the localhost using the 
amavis_bypass mailer we just created. So, given that we're doing all of this 
in, this tells Sendmail that any and all locally 
generated/submitted mail should be sent to on port 10034. In the 
below steps, we'll modify amavisd to listen on port 10034, and then we'll 
tell amavis what we want done with the mail it receives there.

Before you go on, run your modified through the macro compiler to 
make a new
m4 /etc/mail/ > /etc/mail/

3. MODIFY amavisd.conf

Open your amavisd.conf and tell amavisd to listen on port 10034:
$inet_socket_port = [10024,10034]; # 10034 is used by the Sendmail MSP

Tell amavis what to do with mail arriving on port 10034 by defining a new 
policy bank:
$interface_policy{'10034'} = 'LOCALLY_GENERATED';

$policy_bank{'LOCALLY_GENERATED'} = {  # local mail bypasses virus/spam 
  originating => 1,  # declare that mail was submitted by our smtp client
  # notify administrator of locally originating malware
  virus_admin_maps => ["youremail\@$mydomain"],
  spam_admin_maps  => ["youremail\@$mydomain"],
  bypass_virus_checks_maps  => [1],  # don't virus-check this mail
  bypass_spam_checks_maps   => [1],  # don't spam-check this mail
  bypass_banned_checks_maps => [1],  # don't banned-check this mail
  bypass_header_checks_maps => [1],  # don't header-check this mail

The above tells amavis to skip all checks (virus, spam, banned, and header) 
for mail arriving on port 10034. If you want to retain some of the checks, 
just comment out the appropriate line(s).

4. RESTART Sendmail and amavisd

On my CentOS box:
service amavisd restart
service sendmail restart


Normally in a dual Sendmail setup, the Sendmail MSP will forward mail 
directly to MTA-RX on the regular SMTP port 25, which then passes it along 
to amavisd at localhost:10024 for scanning. After making the changes 
discussed above, the Sendmail MSP should now be forwarding all mail to 
amavisd on port 10034. Amavis will then perform whatever checks you decided 
were necessary before sending mail on its way to MTA-TX.

Observant readers might ask why locally generated mail can't be sent 
directly to MTA-TX, bypassing amavis and its policy banks altogether. I have 
not tried this because I like having the ability to turn scanning back on 
with a simple configuration change and a restart, but I don't see why it 
wouldn't work. If you want to try this, replace port 10034 in your mailer 
definition with whatever port your MTA-TX listens to (probably 10025).

I've been using this setup for a couple months now, and I have not noticed 
any problems. Locally generated mail goes to amavis on port 10034 where I 
can perform whatever scans I want using a custom policy bank. The toll 
amavis now takes on the system has decreased appreciably. Used on a machine 
that does not send out significant amounts of locally generated email, I 
doubt the changes discussed above would be worth the time to implement.

That's all I got. I hope this can help put a few Sendmail users on the right 
track. Thank you for reading. 

More information about the amavis-users mailing list