Reply to comment

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.
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.

Now let's look at specific requests.

Table of Contents

1. Allow clients on my internal network to bypass scanning by using the MYNETS policy bank.

'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.

2. Use two or more IP addresses to only filter incoming messages (bypass filtering for internal clients).

Derived from . 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

3. Use two or more IP addresses to bypass filtering for different destination domains.

This is from . 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).

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

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

Run:

postmap /etc/postfix/amavis_bypass

to create amavis_bypass.db.
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

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 )]],

};

7. Allow particular senders to bypass scanning - but in a somewhat more secure manner

Read . 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.

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.

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.com', '.example.net'], );

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.com' => 9999,

    '.example.net' => 9999 },

  \$sa_kill_level_deflt,   # catchall default

);

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: .

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

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.

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

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:

           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