Bypass amavisd-new scanning - Postfix integration

There is a disclaimer for this document located at http://verchick.com/mecham/public_html/spam/. This 'How do I bypass amavisd-new?' topic comes up often on both the Postfix and the amavisd-new mailing lists. While it appears there should be a simple answer, and often there is, it must first be determined exactly what the mail administrator is trying to accomplish. This document is designed to give you some idea of different ways different problems can be solved, so the solutions here are not necessarily designed to be used verbatim. This document assumes amavisd-new is used as an 'after queue' content filter as described in http://www.ijs.si/software/amavisd/README.postfix.txt and you are using amavisd-new version 2.0.0 or newer and Postfix 2.0 or newer. It also assumes you know when a Postfix map needs to be postmap'ed. I illustrate the use of hash: for some tables; your system may use a different data type (like dbm:). Let me start by defining a few terms:
  • spamfilter: The server we are talking about, the Postfix/amavisd-new (e)smtp server.
  • client: A computer that connects to our spamfilter (typically via TCP/IP). This can be another email server, or any other computer or device (typically with an IP address) that wants to send mail to, or through, our spamfilter.
  • sender: the email address the sending machine gives in the MAIL FROM: command - the envelope sender. When I talk about senders, I'm usually referring to senders who are not in domains we control, and they are sending mail to recipients that are in domains we control.
It may be worth mentioning that in Postfix, content_filter and FILTER are mechanisms used to override a given message's transport. All recipients of the message are affected. It is not acceptable to use the FILTER mechanism in a check_recipient_access map to attempt to override the transport for a particular recipient when there is a possibility a message for that recipient may also be addressed to other recipients. The result would be all of those recipients are filtered, whether they are listed in the map or not.

When the FILTER mechanism is used in an access map (I show some examples later), the result is DUNNO, so processing does continue on to the next restriction (if any). I think of it as a selector switch that acts on a given message's transport. The actual act of transporting a message to a destination comes later in Postfix' processing of the message.

Amavisd-new policy banks are intended to be used to alter the processing of a given message depending on the client or sender. There are many per-recipient controls that can also be used in amavisd-new to alter the processing of a message for a given recipient. Lookup tables (either static, SQL or LDAP) are provided as a means of determining certain things such as "does this recipient want to bypass spam checks?" or "is this recipient a spam lover?" or "at what score does this recipient wish to mark a message as spam?". I only give one example of recipient based bypassing (using static maps) and would direct you to amavisd.conf-sample, README.sql, README.ldap, LDAP.schema, and README.lookups supplied with the amavisd-new source code for more examples of recipient based controls.

I will illustrate bypassing spam checks, banned checks, and bad header checks (and provide a few examples of bypassing amavisd-new altogether). You can add virus checks, or remove other checks as required. There is something to consider when using client/sender based bypassing.  In amavisd-new each recipient can be configured to receive malware or not. Bypassing amavisd-new (entirely or via policy banks) may override the personal policies of recipients in hosted domains. This type of bypassing opens up the possibility that malware may be sent to recipients that do not desire it. More often than not, overriding recipients' policies is precisely the desired behavior. For example: if you use the MYNETS policy bank to bypass banned file checks, use of this policy bank may give internal users the ability to send each other (and also remote domains) banned files, regardless of the local recipients' policies. The internal users may want this ability. If their personal policy states that they do not desire spam/banned_files/viruses, they still maintain this policy for mail sent from outside MYNETS. However, in cases where a server is hosting a number of domains - and one or more of those domains wish to opt out of scanning - and a policy bank or content_filter bypass is used to accomplish this, those domains may be given the ability to send malware to the other hosted domains. Make sure you trust those you allow to bypass using these client/sender methods (and other hosted domains are OK with it too). If this is not acceptable, the better option is to use amavisd-new recipient based bypassing for these domains, either per domain/user in SQL or LDAP or with the use of static maps, of which 9. is one example. A thoughtfully constructed dual Postfix setup (generally illustrated in example 12) could also work around this issue.

Suggested reading: http://www.ijs.si/software/amavisd/amavisd-new-docs.html#pbanks. Also see the copy of amavisd.conf-sample that is included with the source code of the version of amavisd-new you are using for examples of policy bank settings. Settings in a policy bank will override current amavisd-new settings. In many examples we bypass checks by redirecting mail to port 10026 or 10027. These port numbers are examples.

In many policy bank examples below I use bypass_spam_checks_maps to bypass spam checks. While bypassing spam checks does reduce time spent processing spam, using spam_lovers_maps as an alternative gives the advantage that some messages may then be auto-learned by the Bayes engine. Often this will aide in feeding needed ham to Bayes. Another alternative is to simply be more permissive in what is allowed. This example is from http://www.ijs.si/software/amavisd/amavisd-new-docs.html#pbanks:
$policy_bank{'MYNETS'} = {  # mail originating from @mynetworks
  virus_admin_maps => ["security\@$mydomain"], # alert of infected local hosts
  spam_admin_maps  => ["abuse\@$mydomain"],    # alert of internal spam
  spam_kill_level_maps => [7.0],  # slightly more permissive spam kill level
  spam_dsn_cutoff_level_maps => [15],
  banned_filename_maps => [
    new_RE(
    # block double extensions in names:
      qr'\.[^./]*\.(exe|vbs|pif|scr|bat|cmd|com|cpl|dll)\.?$'i,
    # allow any name or type (except viruses) within an archive:
      [ qr'^\.(Z|gz|bz2|rpm|cpio|tar|zip|rar|arc|arj|zoo)$' => 0],
    # blocks MS executable file(1) types, unless allowed above:
      qr'^\.(exe-ms)$',
    ),
  ],
};
And here is another MYNETS example where the postmaster is notified if internal users should send spam:
$policy_bank{'MYNETS'} = {  # mail originating from @mynetworks
  spam_admin_maps  => ["postmaster\@$mydomain"], # alert of internal spam
  spam_kill_level_maps => [9.0],
  spam_dsn_cutoff_level_maps => [9999],
  spam_dsn_cutoff_level_bysender_maps => [9999],
};
Now let's look at specific requests:
  • 1. Allow clients on my internal network to bypass scanning by using the MYNETS policy bank.
  • 2. Use two or more IP addresses to only filter incoming messages (bypass filtering for internal clients).
  • 3. Use two or more IP addresses to bypass filtering for different destination domains.
  • 4. Allow a particular client (or clients) to bypass scanning by using an additional port.
  • 5. Allow a particular client (or clients) to bypass scanning by using check_client_access.
  • 6. Allow a particular sender to bypass scanning.
  • 7. Allow particular senders to bypass scanning - but in a somewhat more secure manner.
  • 8. Configure particular senders to use unique banned files settings.
  • 9. Configure particular recipients to bypass checks using amavisd-new @bypass_*_checks_maps.
  • 10 Allow SASL authenticated users to bypass scanning.
  • 11 Bypass checks for internally generated mail (submitted to the 'pickup' service).
  • 12 Bypass amavisd-new by using two copies of Postfix and transport maps.
Index
1. Allow clients on my internal network to bypass scanning by using the 'MYNETS' policy bank. You can use the built in 'MYNETS' policy bank to allow clients included in $mynetworks. Let's assume you allow all (or most) clients on your internal network to send outbound mail through your spamfilter. The IP addresses of these clients are included in Postfix' $mynetworks in main.cf:

mynetworks = 127.0.0.0/8 !192.168.1.1 192.168.1.0/24

In amavisd.conf @mynetworks determines which clients will use the 'MYNETS' policy bank:
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
                  !192.168.1.1 192.168.1.0/24 );
And you would configure the 'MYNETS' policy bank as desired:
$policy_bank{'MYNETS'} = {  # clients in @mynetworks
  bypass_spam_checks_maps   => [1],  # don't spam-check internal mail
  bypass_banned_checks_maps => [1],  # don't banned-check internal mail
  bypass_header_checks_maps => [1],  # don't header-check internal mail  
};
When using the "MYNETS' policy bank, you must use *_send_xforward_command in master.cf: 
smtp-amavis unix    -    -    n    -    2    smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20
(or)
lmtp-amavis unix    -    -    n    -    2    lmtp
    -o lmtp_data_done_timeout=1200
    -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20
This enables forwarding of the client's IP address to amavisd-new.

Index
2. Use two or more IP addresses to only filter incoming messages (bypass filtering for internal clients). Derived from http://www.postfix.org/FILTER_README.html#remote_only. When we start out, our spamfilter has one IP address assigned to our network interface, one assigned to the loopback interface, and master.cf is configured to listen to them there:
smtp    inet  n       -       n       -       -       smtpd
and in main.cf we listen on all interfaces:
inet_interfaces = all
Let's assume the IP address of the spamfilter's network interface is 192.168.1.2. You would begin by adding a second IP address to this network interface (I do not outline this procedure - it is specific to each operating system). If the current IP address is a public IP address, this assumes you have a spare one available for use. If you have a backup MX server that will also use this type of configuration, then another available address may be needed. We will assign 192.168.1.222. This procedure will require you to reconfigure the clients on your network to use the newly added address. You split the smtpd listener into three listeners (we add 127.0.0.1:smtp because we lost it when we broke out 192.168.1.2:smtp):
192.168.1.2:smtp   inet  n       -       n       -       -       smtpd
127.0.0.1:smtp     inet  n       -       n       -       -       smtpd
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
In main.cf you must remove or comment out: 
#content_filter=smtp-amavis:[127.0.0.1]:10024
You then configure the original IP and 127.0.0.1 to use amavisd-new as it was before, and the new IP we set to override the content_filter. We also prevent connections to 192.168.1.222 from untrusted IP addresses (we only allow internal clients):
192.168.1.2:smtp   inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10024
127.0.0.1:smtp     inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10024
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
    -o mynetworks=127.0.0.0/8,!192.168.1.1,192.168.1.0/24
    -o smtpd_client_restrictions=permit_mynetworks,reject
# 192.168.1.1 is the internal interface of our NAT router
# the NAT router sends all external mail to 192.168.1.2
# internal clients (192.168.1.0/24) are (re)configured to send mail to 192.168.1.222
Create a policy bank in amavisd.conf that listens on port 10026:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'BYPASS';

$policy_bank{'BYPASS'} = {  # those configured to send mail to port 10026
   originating => 1,  # Since amavisd-new 2.5.0
                      # declare that mail was submitted by our smtp client
   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  
};
Because we moved the content_filter setting from main.cf to master.cf we have turned off the content_filter for the pickup service (a possibly desirable side effect). Instead of completely bypassing amavisd-new, another option would be to use the BYPASS policy bank so virus checks (for example) are still performed.
pickup    fifo  n       -       n       60      1       pickup
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
As you can see, by manipulating the overrides for the newly added listener on 192.168.1.222, you can do a number of different things. For example, you could limit access to one particular client (192.168.1.41 in this example):
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
    -o smtpd_client_restrictions=hash:/etc/postfix/amavis_bypass_client,reject
contents of /etc/postfix/amavis_bypass_client:
192.168.1.41 OK

You could use a cidr: map to allow certain networks (networks you do not wish to include in $mynetworks) or a regexp: or pcre: map to allow other chosen clients. Also note that you don't have to send to a policy bank. Since we removed content_filter from main.cf, you could simply bypass amavisd-new by not setting a content_filter:
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
    -o smtpd_client_restrictions=permit_mynetworks,reject
A note on address rewriting: you should only rewrite addresses once. When a content_filter like amavisd-new is used, unless you have chosen to disable address rewriting on the reinjection port (127.0.0.1:10025), you might consider disabling rewriting on the listeners above by adding
    -o receive_override_options=no_address_mappings

Index
3. Use two or more IP addresses to bypass filtering for different destination domains. This is from http://www.postfix.org/FILTER_README.html#domain_dependent. You filter mail for a number of domains, but a couple domains only want virus filtering, and a couple others do not want mail to pass through amavisd-new at all. This presumes you have one or two extra public IP addresses available for use. If you have a backup MX server that will also use this type of configuration, then one or more additional available addresses may be needed. When we start out, our spamfilter has one IP address, and master.cf is configured to listen there:
smtp    inet  n       -       n       -       -       smtpd
and in main.cf we listen on all interfaces:
inet_interfaces = all
Let's assume the IP address of the spamfilter is 192.168.1.2 with a hostname of host.example.com. You would begin by adding a second (and possibly third) IP address to the network interface (I do not outline this procedure - it is specific to each operating system). We will create 192.168.1.222 and 192.168.1.223 and will also create DNS A records for them 'hostip2.example.com' and 'hostip3.example.com' and for the domains that wish to bypass scanning, MX records would be changed so they point to the new hosts. You split the smtpd listener into four listeners (we add 127.0.0.1:smtp because we lost it when we broke out 192.168.1.2:smtp):
192.168.1.2:smtp   inet  n       -       n       -       -       smtpd
127.0.0.1:smtp     inet  n       -       n       -       -       smtpd
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
192.168.1.223:smtp inet  n       -       n       -       -       smtpd
In main.cf you must remove or comment out: 
#content_filter=smtp-amavis:[127.0.0.1]:10024
Then we configure our four listeners:
# host.example.com uses standard amavisd-new configuration
192.168.1.2:smtp   inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10024	
# as does the loopback interface
127.0.0.1:smtp     inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10024	
# hostip2.example.com uses a policy bank listening on port 10026
192.168.1.222:smtp inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10026	
# and hostip3.example.com bypasses amavisd-new altogether	
192.168.1.223:smtp inet  n       -       n       -       -       smtpd
    -o content_filter=
Create a policy bank in amavisd.conf that listens on port 10026:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'BYPASS';

$policy_bank{'BYPASS'} = {  # those configured to send mail to port 10026
   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  
};
Because we moved the content_filter setting from main.cf to master.cf we have turned off the content_filter for the pickup service. Instead of completely bypassing amavisd-new, another option would be to use the BYPASS policy bank so virus checks (for example) are still performed:
pickup    fifo  n       -       n       60      1       pickup
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
A note on address rewriting: you should only rewrite addresses once. When a content_filter like amavisd-new is used, unless you have chosen to disable address rewriting on the reinjection port (127.0.0.1:10025), you might consider disabling rewriting on the listeners above by adding
    -o receive_override_options=no_address_mappings

Although this may be unlikely, I can see one problem. Spammers often send mail to hosts (A records) instead of heeding MX records so there would be a problem if they decided to send mail for any of your hosted domains to the wrong hostname (IP address).

Index
4. Allow a particular client (or clients) to bypass scanning by using an additional port. This is another handy way to allow an internal mail server (or any clients in $mynetworks or a properly configured access map) to use our spamfilter with less restrictive (or completely bypassed) content_filter settings. You can also control access to the port using your firewall (whether local or external). In master.cf add the additional port, set it to use the policy bank, and configure which clients may access it. Obviously any clients that wish to use the new port would need to be reconfigured to do so. In this example these clients in $mynetworks are also able to use the spamfilter as a relay:
smtp inet  n       -       n       -       -       smtpd
4025 inet  n       -       n       -       -       smtpd
    -o mynetworks=127.0.0.0/8,192.168.1.0/24
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
Create a policy bank in amavisd.conf:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'INTERNAL';

$policy_bank{'INTERNAL'} = {  # Internal mail submitted to port 4025
   originating => 1,  # Since amavisd-new 2.5.0
                      # declare that mail was submitted by our smtp client
   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  
};
Remember that you don't have to send mail to the content filter. As you can see, by manipulating the overrides for the newly added port 4025, you can do a number of different things. For example, you could limit access to one particular client (192.168.1.41 in this example):
4025 inet  n       -       n       -       -       smtpd
    -o content_filter=
    -o smtpd_client_restrictions=hash:/etc/postfix/amavis_bypass_client,reject
contents of /etc/postfix/amavis_bypass_client:
192.168.1.41 OK

You could use a cidr: map to allow certain networks (networks you do not wish to include in $mynetworks) or a regexp: or pcre: map to allow other chosen clients.

A note on address rewriting: you should only rewrite addresses once. When a content_filter like amavisd-new is used, unless you have chosen to disable address rewriting on the reinjection port (127.0.0.1:10025), you might consider disabling rewriting on the listeners above by adding
    -o receive_override_options=no_address_mappings

Index
5. Allow a particular client (or clients) to bypass scanning by using check_client_access. This is simple. We use a policy bank and a check_client_access map to allow 192.168.1.41 to bypass checks. In main.cf:
smtpd_client_restrictions =
    check_client_access hash:/etc/postfix/amavis_bypass

contents of /etc/postfix/amavis_bypass:
192.168.1.41 FILTER smtp-amavis:[127.0.0.1]:10026
Create a policy bank in amavisd.conf that listens on port 10026:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'BYPASS';

$policy_bank{'BYPASS'} = {  # those configured to send mail to port 10026
   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  
};
It is also possible to skip amavisd-new entirely by sending the mail back to Postfix on the reinjection port. This is a bit convoluted but useful if you are still using amavisd-new 20030616p10 which does not support policy banks.
contents of /etc/postfix/amavis_bypass:
192.168.1.41 FILTER smtp:[127.0.0.1]:10025

Index
6. Allow a particular sender to bypass scanning. I'm mainly talking about allowing a particular sender to bypass banned files checks but this could also be used to allow senders to bypass SpamAssassin. However, if you want to allow a sender to send spam, consider using one of the means to whitelist a sender outlined in the SpamAssassin or amavisd-new documentation. Use amavisd-new's @score_sender_maps for one example. Anyone can spoof the sender address. Allowing a sender to send banned files is to invite disaster. I don't suggest you use this (but if forced to confess, I use it for one sender myself). Look to the following section for a more secure idea. Nonetheless, if you insist on using this simple method, then you should at least limit the damage by only allowing the banned files to pass to a chosen recipient or short list of recipients. Definitely don't use this for a sender in one of your own domains because it is extremely likely you will get mail that spoofs your own addresses. In main.cf:
smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/amavis_senderbypass

contents of /etc/postfix/amavis_senderbypass
sender@example.net FILTER smtp-amavis:[127.0.0.1]:10026
sender@example.org FILTER smtp-amavis:[127.0.0.1]:10026
In amavisd.conf:
$inet_socket_port = [10024,10026];
$interface_policy{'10026'} = 'SENDERBYPASS';

$policy_bank{'SENDERBYPASS'} = {
 bypass_spam_checks_maps => [[qw( recip1@example.com recip2@example.com )]],
 bypass_banned_checks_maps => [[qw( recip1@example.com recip2@example.com )]],
 bypass_header_checks_maps => [[qw( recip1@example.com recip2@example.com )]],
};

Index
7. Allow particular senders to bypass scanning - but in a somewhat more secure manner. Read http://www.postfix.org/RESTRICTION_CLASS_README.html. With this setup we will say: Allow the clients at 10.0.0.13 and 10.0.0.14 to bypass checks, but only if mail sent from those clients is from joe@example.org or tom@example.org and the recipient(s) is (are) either recip1@example.net and/or recip2@example.net. You can use networks instead of clients if absolutely necessary.
smtpd_restriction_classes = from_policy_bank_senders

from_policy_bank_senders =
   check_sender_access hash:/etc/postfix/policy_bank_senders, permit

smtpd_sender_restrictions =
    [... possible other stuff ...]
    check_client_access cidr:/etc/postfix/policy_bank_clients
contents of /etc/postfix/policy_bank_senders:
joe@example.org FILTER smtp-amavis:[127.0.0.1]:10027
tom@example.org FILTER smtp-amavis:[127.0.0.1]:10027
contents of /etc/postfix/policy_bank_clients:
10.0.0.13/32 from_policy_bank_senders
10.0.0.14/32 from_policy_bank_senders
Create a policy bank in amavisd.conf:
$inet_socket_port = [10024,10027];
$interface_policy{'10027'} = 'SENDERBYPASS';

$policy_bank{'SENDERBYPASS'} = {
 bypass_spam_checks_maps => [[qw( recip1@example.net recip2@example.net )]],
 bypass_banned_checks_maps => [[qw( recip1@example.net recip2@example.net )]],
 bypass_header_checks_maps => [[qw( recip1@example.net recip2@example.net )]],
};
Note that due to the needed permit statement in check_sender_access, any messages from the clients '10.0.0.13' and '10.0.0.14' will bypass any additional restrictions in smtpd_sender_restrictions (had there been any), so be very careful with your placement - last is best. As you may notice, adding additional clients/networks, senders and recipients will water down the security. If necessary you can add additional smtpd_restriction_classes that include other unique sender/network or sender/client pairs and additional policy banks but I'm not certain how well this scales.

Index
8. Configure particular senders to use unique banned files settings. If you use 2.3.0 or newer and your intent is to allow a particular sender (or senders) to send certain files that are blocked by the current settings in banned_filename_re, you could first redefine the %banned_rules hash and include a complete custom set of $banned_filename_re settings there. In addition, this hash necessarily includes the 'DEFAULT' set of banned_filename_re settings currently defined in $banned_filename_re and is necessarily positioned after the existing $banned_filename_re new_RE( ... ); setting. For example:
%banned_rules = (
  'ALLOW_EXE' =>  new_RE(
      [qr'.\.(exe|com)$'i => 0],  # pass .exe and .com files
      # block certain double extensions anywhere in the base name
      qr'\.[^./]*[A-Za-z][^./]*\.(exe|vbs|pif|scr|bat|cmd|com|cpl|dll)\.?$'i,
      [ qr'^\.(rpm|cpio|tar)$'       => 0 ],  # allow any in Unix-type archives
      qr'.\.(vbs|pif|scr|cmd|cpl|bat)$'i,  # banned extension - basic
      qr'^\.(lha|cab|dll)$',  # banned file(1) types
      ),
  'DEFAULT' => $banned_filename_re,
);
Then add it to a policy bank:
$inet_socket_port = [10024,10026];
$interface_policy{'10026'} = 'ALLOWEXE';

$policy_bank{'ALLOWEXE'} = {
 banned_filename_maps => ['ALLOW_EXE'], # more permissive banning rules
};
In main.cf:
smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/amavis_allow_exe
The contents of /etc/postfix/amavis_allow_exe: 
sender@example.net FILTER smtp-amavis:[127.0.0.1]:10026
Now, however, this sender may be able to send .exe files to anyone in any of your domains, and of course as always, the sender can be spoofed. See the previous section for a way to make this more secure by using Postfix' smtpd_restriction_classes.

Index
9. Configure particular recipients to bypass checks using amavisd-new @bypass_*_checks_maps. Amavisd-new new uses @bypass_*_checks_maps static maps as a way to bypass checks for listed recipients/domains. SQL and LDAP lookups have similar settings. However, because multiple recipients may be involved, if one of those recipients disagrees that a scan should be bypassed, the scan will occur. Listing a recipient/domain in a @bypass maps does not guarantee delivery of the message. To work around this issue it is also necessary to place those recipients/domains in complimentary @*_lovers_maps. Let's take an example where you have one domain that is currently listed in a @spam_lovers_maps:
@spam_lovers_maps = ( ['.example.com', ], );
Now we have example.net that wants to bypass all checks except virus checks. There is also one recipient at example.com that wants the same thing:
@bypass_spam_checks_maps 
   = @bypass_banned_checks_maps
   = @bypass_header_checks_maps
   = @banned_files_lovers_maps
   = @bad_header_lovers_maps = ( ['.example.net', 'user1@example.com'], );

@spam_lovers_maps = ( ['.example.net', 'user1@example.com'], );
Notice how I saved typing by assigning maps to other maps. Also note that if mail is scanned and then passed, depending on the spam_kill_level for a given recipient, a copy of the message may still get quarantined (as well as passed). To prevent this additional useless step it might be a good idea to set spam_kill_level to a high level. For example, if using static maps:
$sa_kill_level_deflt = 8.00;

@spam_kill_level_maps = (
  { '.example.net' => 9999,
    'user1@example.com' => 9999 },
  \$sa_kill_level_deflt,   # catchall default
);

Index
10. Allow SASL authenticated users to bypass scanning. Typically SASL users already submit messages to the submission port (587) or the smtps port (465):
submission	inet n      -       n       -       -       smtpd
    -o smtpd_etrn_restrictions=reject
    -o smtpd_sasl_auth_enable=yes	
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       n       -       -       smtpd
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
If that is the case, it is simple to override the content_filter and (optionally) use a policy bank (to at least perform virus checks):
submission	inet n      -       n       -       -       smtpd
    -o smtpd_etrn_restrictions=reject
    -o smtpd_sasl_auth_enable=yes	
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
smtps     inet  n       -       n       -       -       smtpd
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
Create a policy bank in amavisd.conf:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'SASLBYPASS';

$policy_bank{'SASLBYPASS'} = {  # mail from submission and smtps ports
   originating => 1,  # Since amavisd-new 2.5.0
                      # declare that mail was submitted by our smtp client
   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  
};
If for some reason SASL users connect to port 25, as an alternate method you could have all clients in Postfix' $mynetworks and SASL auth senders bypass checks and let everything else fall through to a catchall that sets the content_filter. Since clients in $mynetworks will (optionally) use the policy bank, be careful if you are behind a gateway whose IP address is included in $mynetworks (and the gateway acts as a proxy in such a way that mail appears to come from the IP address of the gateway). While using the same policy bank above, in main.cf:
content_filter = smtp-amavis:[127.0.0.1]:10026

smtpd_data_restrictions =
    reject_unauth_pipelining
    permit_mynetworks
    permit_sasl_authenticated
    check_client_access regexp:/etc/postfix/filter-catchall.regexp
With the contents of /etc/postfix/filter-catchall.regexp:
/^/ FILTER smtp-amavis:[127.0.0.1]:10024
If necessary, you could exclude certain SASL or $mynetworks clients from the policy bank by creating another access map (here I place it in smtpd_sender_restrictions):
smtpd_sender_restrictions =
    check_client_access hash:/etc/postfix/use_normal_amavis

# contents of /etc/postfix/use_normal_amavis:
192.168.1.13 FILTER smtp-amavis:[127.0.0.1]:10024
The main drawback to this whole approach is you have to be very careful about adding any access lists or restrictions in smtpd_data_restrictions that OK/PERMIT something/someone prior to "check_sender_access regexp:/etc/postfix/filter-catchall.regexp" because they would use the more permissive default policy bank (or optionally use no content_filter at all). The order of any access lists would be critical and testing would be in order. This approach uses 'permit then deny' as opposed to 'deny then permit'.
Another possibility. If you are using Postfix 2.3.x, and SpamAssassin 3.1.4 or newer, you can use this to reduce the spam score for SASL auth messages; this is from: http://wiki.apache.org/spamassassin/DynablockIssues.

Postfix quick fix: Get latest versions of Postfix (at least 2.3.0) and SpamAssassin (at least 3.1.4). Add 'smtpd_sasl_authenticated_header = yes' to the Postfix main.cf. With that set, SpamAssassin should catch such authenticated emails as ALL_TRUSTED, bypassing possible SPF and RBL problems.

Make sure your trust path is set up correctly. For example:
# explicitly set our internal_networks (might be the same or similar to mynetworks) 
clear_internal_networks 
internal_networks 127/8 
internal_networks 333.333.333.333/24 
internal_networks 10.10.10.10/24 
# add the same to trusted_networks, 
# and possibly other computers/networks whose mail we trust 
clear_trusted_networks 
trusted_networks 127/8 
trusted_networks 333.333.333.333/24 
trusted_networks 10.10.10.10/24
http://marc.theaimsgroup.com/?l=spamassassin-users&m=115112073816917
http://wiki.apache.org/spamassassin/TrustPath
Here is also another way to reduce the spam score for SASL auth users that can be used with Postfix version 2.1 or newer. This should add a 'X-SMTP-Auth: no' header to all messages except authenticated. The SpamAssassin rule then adds -10 points if this header is missing:
# In main.cf:
smtpd_data_restrictions =
    reject_unauth_pipelining
    permit_sasl_authenticated
    check_client_access regexp:/etc/postfix/add_auth_header.regexp
	
# In /etc/postfix/add_auth_header.regexp:
/^/ PREPEND X-SMTP-Auth: no

# In SpamAssassin's local.cf:
header __NO_SMTP_AUTH X-SMTP-Auth =~ /^no$/m
meta SMTP_AUTH !__NO_SMTP_AUTH
describe SMTP_AUTH Message sent using SMTP Authentication
tflags SMTP_AUTH nice
score SMTP_AUTH -10
I suggest you do not use X-SMTP-Auth literally. I would obscure this by using a X-something-else header name of your choice, and if you have more than one machine, I suggest using something different on each. In order to prevent confusion (the header would end up getting written again after the message was processed by amavisd-new), you should override smtpd_data_restrictions on the amavisd-new reinjection port. In master.cf add
  -o smtpd_data_restrictions= 
127.0.0.1:10025    inet    n    -    n    -    -    smtpd
    -o content_filter=
    -o smtpd_data_restrictions=
    [other typical amavisd-new reinjection port overrides]
Credit for this one goes to Bill Boebel and Viktor.

Index
11. Bypass checks for internally generated mail (mail picked up by the 'pickup' daemon - this type of mail is dropped into the maildrop queue by programs such as mail, mailx and sendmail via the Postfix compatible sendmail command). With the way I worded that, this may be obvious. Simply override the content_filter for the pickup service in master.cf. Note that doing so is not always appropriate. You may have local users or a web form using the sendmail command to deliver mail to the outside world. It may not be a good idea to allow this mail to pass unchecked, so I also illustrate using a more permissive policy bank to check this mail.
pickup    fifo  n       -       n       60      1       pickup
    -o content_filter=
If you would like to still perform virus checks (for example):
pickup    fifo  n       -       n       60      1       pickup
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
Create a policy bank in amavisd.conf:
# change this from the original setting
$inet_socket_port = [10024, 10026];

# add these
$interface_policy{'10026'} = 'VIRUSONLY';

$policy_bank{'VIRUSONLY'} = {  # mail from the pickup daemon
   originating => 1,  # Since amavisd-new 2.5.0
                      # declare that mail was submitted by our smtp client
   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  
};
Or continue normal scanning, yet be more permissive:
$interface_policy{'10026'} = 'PERMISSIVE';

$policy_bank{'PERMISSIVE'} = {  # mail from the pickup daemon
   originating => 1, # declare that mail was submitted by our smtp client
   spam_kill_level_maps => [9.0],  # more permissive spam kill level
};
Note: In the first example we had to override the content_filter because we set a content_filter in main.cf. An alternative would be to instead set the content_filter in master.cf (override the content filter for the smtpd daemon). Doing so confines the setting to messages received via the smtpd daemon (or daemons if required):
smtp   inet  n       -       n       -       -       smtpd
    -o content_filter=smtp-amavis:[127.0.0.1]:10024

Index
12. Bypass amavisd-new by using two copies of Postfix and transport maps. Initially this is the most difficult to construct method of bypassing amavisd-new but provides the most control and may offer other benefits not discussed here. What I document here is not the complete solution. Because of the many ways Postfix can be configured, I'm sure you will have a number of additional issues when you set this up, one of which is carefully controlling access to the second IP address. Having only tested this for a short time myself, it's possible there are better ways to configure this. You would be wise to make a backup of your current settings, and even more wise to test on a non-production box. I do not document how to create a second copy of Postfix, you will have to look elsewhere for that. Here is a start:
http://www.advosys.ca/papers/postfix-instance.html
http://archives.neohapsis.com/archives/postfix/2005-12/0695.html
http://archives.neohapsis.com/archives/postfix/2006-03/0977.html
http://souptonuts.sourceforge.net/postfix_sbr.html
           1.2.3.11       1.2.3.22
Internet-> postfix1-----> postfix2 --> to local or nexthop server
               \   ----->   /    
                amavisd-new
We will use the example where each instance of Postfix has its own IP address (but keep in mind you could instead set the second copy of Postfix up on a different port). We disable the content_filter directive (everywhere) and instead direct mail to amavisd-new via the transport table. You may still wish to use the FILTER directive for certain clients and/or senders to send messages to an amavisd-new policy bank as described many times in previous examples. If you want mail addressed to example.com or ted@example.net to bypass amavisd-new, you could create entries in the transport table for the postfix1 instance that read:
example.com relay:[1.2.3.22]
ted@example.net relay:[1.2.3.22]
or you could alternately relay the messages directly to the next hop server (or deliver locally) but this may add unnecessary complexity. If you want to send mail to amavisd-new, you would also use the transport table for postfix1:
example.org smtp-amavis:[127.0.0.1]:10024
example.net smtp-amavis:[127.0.0.1]:10024
The postfix2 transport table may possibly remain unchanged. Since amavisd-new will not return mail to the same instance of Postfix, a change in amavisd.conf would be needed:
$forward_method = 'smtp:1.2.3.22:10025';# we send mail to postfix2 after processing
#$notify_method = $forward_method; # notifications go to the same place
In /etc/postfix/master.cf you disable the reinjection port:
#127.0.0.1:10025        inet    n       -       n       -       -       smtpd
#    -o content_filter=
# [ ... other overrides...]
#    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
and in /etc/postfix2/master.cf you change the IP address and mynetworks of the reinjection port:
1.2.3.22:10025        inet    n       -       n       -       -       smtpd
    -o content_filter=
 [ ... other overrides...]
    -o mynetworks=127.0.0.0/8,1.2.3.11,1.2.3.22
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
 [ ... other overrides...]	
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
and comment out the smtp-amavis transport:
#smtp-amavis    unix    -       -       n       -       2       smtp
#    -o smtp_data_done_timeout=1200
#    -o smtp_send_xforward_command=yes
#    -o disable_dns_lookups=yes
#    -o max_use=20
In /etc/postfix/main.cf you no longer use the amavis content_filter and you may need to reconfigure inet_interfaces:
#content_filter = ....
inet_interfaces = 1.2.3.11 127.0.0.1
In /etc/postfix2/main.cf you no longer use the amavis content_filter and you may need to reconfigure inet_interfaces:
#content_filter = ....
inet_interfaces = postfix2.example.com
myhostname = postfix2.example.com
Gary V
mr88talent at yahoo dot com
02 DEC 2006