chown -R amavis.amavis /var/clamav                  

chown -R amavis.amavis /var/log/clamav/

chown -R amavis.amavis /var/run/clamav/

chown -R amavis.amavis /var/amavis/ 

chown -R amavis.amavis /var/amavis/tmp

chown -R amavis.amavis /var/amavis/quarantine

service spamassassin restart

service clamd restart

service amavisd restart

service dovecot restart

service postfix restart

service amavisd status

yum -y update amavisd-new* clamav clamav-devel* clamd spamassassin

sa-update

freshclam -v

Disk Space

du -h --max-depth=1

#### Quentain Directory

   cd  /var/amavis/quarantine/

   rm -rf *

   rm -rf /var/amavis/quarantine/*

echo > /var/amavis/amavis.log

 cd /var/amavis

 mkdir -p quarantine 

 chown -R amavis.amavis /var/amavis/quarantine

---------------------------------------------------------------------------------------------

# amavis.conf

$sa_spam_subject_tag = '***Spam*** ';

RELEASING A MESSAGE FROM A QUARANTINE WITH AMAVISD-RELASE

Fist you need to find message inside the messages log file (usually /var/log/messages)

May 10 10:06:56 ns1 amavis[12774]: (12774-13) Blocked SPAM, [207.46.22.35] [207.46.22.35] <cnfrmpro@microsoft.com> -> <mymail@domain.tld>, quarantine: spam-1lvc624m6MVB.gz, Message-ID: <BY2MSFTVSMTP03Dfn8e0003d305@by2msftvsmtp03.phx.gbl>, mail_id: 1lvc624m6MVB, Hits: 7.743, size: 3013, 4325 ms

As you can see above, it is spam-1lvc624m6MVB.gz

Now you can release specific message with

[root@mail ~]# amavisd-release spam-1lvc624m6MVB.gz

And you will see something like

250 2.0.0 Ok, id=rel-1lvc624m6MVB, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 403206AF07CE

Now you just need to check your inbox and you should see the message.

Betreff: VIRUS (Eicar-Test-Signature) in mail FROM [0.1.2.3] petersen@univention.de bzw. Betreff: VIRUS (Eicar-Test-Signature) in mail TO YOU from petersen@univention.de  A virus was found: Eicar-Test-Signature Scanner detecting a virus: Clam Antivirus-clamd Content type: Virus ... The message has been quarantined as: L/virus-L+qGRZNCxJKd 

The original e-mail is not delivered to the recipient, but added to the Amavis quarantine queue.

Solution:

These e-mails can be redelivered from the quarantine if required. This can be done with the tool amavisd-release:

amavisd-release L/virus-L+qGRZNCxJKd

Alternatively, the e-mail can also be sent to another user, e.g.

amavisd-release L/virus-L+qGRZNCxJKd admin@example.com

----------------------------------------------------------

A cron job with the following command can be used to delete the emails in the quarantine after one month, for example:

find /var/lib/amavis/virusmails/ -type f -mtime +31 -delete

--------------------------------

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Stop spamassassin from processing outgoing mail with postfix / amavisd on Centos

# vi /etc/postfix/master.cf

                -----------------------------

# service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100)

# ==========================================================================

smtp inet n - n - - smtpd submission inet n - n - - smtpd

# -o smtpd_enforce_tls=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

#####################################################

Disable 'Considered UNSOLICITED BULK EMAIL, Apparently From You'

# vi /etc/amavisd/amavisd.conf

$final_banned_destiny = D_REJECT;

Don’t forget to restart you amavis service using

The name of the server: guinazu.turbo-x.com.br

try localhost instead and restart amavisd.

sudo /etc/init.d/amavis restart

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

***UNCHECKED*** gets added to the subject

 $undecipherable_subject_tag = '***UNCHECKED*** ';    to  $undecipherable_subject_tag = '';  

then restart amavisd:

bypass amavisd for some senders

1) I created the file /etc/amavisd/whitelist

where I inserted the addresses of the senders that I wanted to whitelist, one per line.

it works also for whole domains (but without the @)

Example:

2) in /etc/amavisd/amavisd.conf I decommented AND modified the following section:

Checked the logs and the headers of the messages... it works perfectly! 

############################################################

######faruq

     12 # @bypass_virus_checks_maps = (1);  # controls running of anti-virus code

     13 # @bypass_spam_checks_maps  = (1);  # controls running of anti-spam code

     16 ######faruq

 @bypass_virus_checks_maps = ([qw(junkmail@worldcm.net)]);

 @bypass_spam_checks_maps = ([qw(junkmail@worldcm.net)]);

 @bypass_banned_checks_maps = ([qw(junkmail@worldcm.net)]);

#################################################

Don't do virus and spam checks for outgoing email

#  vi /etc/amavisd/amavisd.conf

@local_domains_maps = ( [".$mydomain"] ); # list of all local domains

@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10

                          10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 203.76.150.162/32 );

$policy_bank{'MYNETS'} = { # mail originating from @mynetworks

           originating => 1, # is true in MYNETS by default, but let's make it explicit

           os_fingerprint_method => undef, # don't query p0f for internal clients

           # don't perform spam/virus/header check.

           bypass_spam_checks_maps => [1],

           bypass_virus_checks_maps => [1],

           bypass_header_checks_maps => [1],

};

#####

systemctl restart amavisd

Amavis bypass scanning from localhost

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.

Disable spam virus scanning for outgoing mails

To disable spam/virus scanning for outgoing mails, you can add bypass settings in Amavisd config file: /etc/amavisd/amavisd.conf (RHEL/CentOS) or /etc/amavis/conf.d/50-user (Debian/Ubuntu) or /usr/local/etc/amavisd.conf (FreeBSD).

• • bypass_spam_checks_maps

  • bypass_virus_checks_maps

  • bypass_header_checks_maps

  • bypass_banned_checks_maps

These settings can be added in setting block $policy_bank{'ORIGINATING'}:

$policy_bank{'ORIGINATING'} = {     [...OMIT OTHER SETTINGS HERE...]      # don't perform spam/virus/header check.     bypass_spam_checks_maps => [1],     bypass_virus_checks_maps => [1],     bypass_header_checks_maps => [1],      # allow sending any file names and types     bypass_banned_checks_maps => [1], }

Restarting Amavisd service is required after changing settings.

### BYPASS LOCAL EMAILS ##@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10                  192.168.0.11/16                 );  $policy_bank{'MYNETS'} = {  # mail originating from @mynetworks   bypass_spam_checks_maps      => [1],  # don't spam-check internal mail   bypass_banned_checks_maps    => [1],  # don't banned-check internal mail   final_spam_destiny           => D_PASS,   final_banned_destiny         => D_PASS,   bypass_virus_checks_maps     => [1],   bypass_header_checks_maps    => [1],   final_virus_destiny          => D_PASS, };

local_domains_maps

# @bypass_virus_checks_maps = (1);  # controls running of anti-virus code

# @bypass_spam_checks_maps  = (1);  # controls running of anti-spam code

# $bypass_decode_parts = 1;         # controls running of decoders&dearchivers

$daemon_user  = 'amavis';     # (no default;  customary: vscan or amavis), -u

$daemon_group = 'amavis';     # (no default;  customary: vscan or amavis), -g

$mydomain = 'example.com';   # a convenient default for other settings (change it)

$MYHOME = '/var/spool/amavisd';   # a convenient default for other settings, -H (remove the comment in front)

@local_domains_maps = ( [".$mydomain","myotherdomain.net"] );  # list of all local domains. If you have multiple domains, add the here.

$myhostname = 'host.example.com';  # must be a fully-qualified domain name! (remove the comment in front)

                            ---------------xxxxxxxxxxxxx--------------------------

postfix bypass amavis completely for specific domains

or

i added the following line to /etc/postfix/main.cf

header_checks = pcre:/etc/postfix/whitelist.pcre

and in the /etc/postfix/whitelist.pcre file i have a single line

info@xxxxxxxxx.yyy FILTER  SMTP:[127.0.0.1]:10025

where SMTP:[127.0.0.1]:10025 is (AT LEAST I THINK IT IS!) the transport everything returns to after amavis, so emails are delivered. 

1

-------------------------------------------------------------------------------------------------------------------------

  In /etc/postfix/main.cf

In /etc/amavis/conf.d/50-user (You can also create a separate policy file such as 40-policy)

Modify /etc/postfix/master.cf as below

Don’t forget to reload/restart postfix after doing this. Also reload amavis.

------------------------------------------

XXXXX XXXXX XXXXXXX XXXXXX XXXXXX XXXXXXXX XXXXXXXXXX XXXXX XXXXXX XXXX       

In the amavisd-new configuration the following settings need to be changed. To do this, edit the /etc/amavisd.conf configuration file with you favourite editor.

$mydomain = 'example.com';   # a convenient default for other settings @mynetworks = qw( 127.0.0.0/8 [::1] ); $sa_spam_subject_tag = '[Spam] ';

When the email is passed on to amavisd-new, an additional “Received” header is added to the email. If you don’t want to show this information on outgoing emails, the following configuration added to the /etc/amavisd.conf configuration file will avoid these headers being added.

# disable the "Received" headers to be added to the mail header $allowed_added_header_fields{lc('Received')} = 0;

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Disabling oubout Amavisd scanning

If you send out email through port 587 (submission), you can disable content filter (spamassassin, clamav, DKIM, disclaimer) completely by modify 'submission' entry in /etc/postfix/master.cf like below:

What it does is simply appending line '-o content_filter=', then Postfix won't invoke any content filter for clients who send out email through port 587.

WARNING: DKIM signing is provided by Amavisd, so above modification means your outgoing mails won't be signed with a DKIM key.

To speed up Amavisd, here's some tips:

*) use a tmpfs to speed up disk I/O (it uses memory directly instead of hard disk): http://www.arschkrebs.de/postfix/amavisd_tmpfs.shtml

*) Set '$max_servers' to the number of your CPUs. And it MUST be the same as the number defined in /etc/postfix/main.cf. For example:

*) Bypass one more check in amavisd.conf (in $policy_bank):

*) Disable SNMP tracking if you don't use it at all. It's used by 'amavisd-nanny' and 'amavisd-agent'.

*) Retire an Amavisd child process after that many accepts. Default is 20, you can increase it on a busy server, for example, 40, or even lager.

-----------------------------------------------------------

Amavis send bounce emails to sender for banned files - result in Backscatter

how to make amavis notify spam mail to sender

Re: [AMaViS-user] How to restore/resend banned email

FW: Undeliverable mail, invalid header section

I'm sending mail out through amavis for spam checking, and back in. There are extra "Received:" headers being addedWhen sending an e-mail, 

the local Amavis (at the sending side) reports a BAD HEADER. This happens with every e-mail. The e-mail is forwarded, but I presume an Amavis-installation at the receiving side will not accept it.

554 5.6.0 Bounce, id=32125-04 - BAD HEADER                       [sending mail errorERROR]

#vi /etc/amavisd/amavis.conf

$insert_received_line = 1;    [change 0]

You can turn off the "Received: " header in amavisd-new with 

$insert_received_line = 0; 

---------------------------------xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#$QUARANTINEDIR = '/var/virusmails';

$QUARANTINEDIR = '/var/amavis/quarantine';

------------------------------------------------------------------------------------------------

 460 ###Amamvis.conf

 $final_virus_destiny      = D_DISCARD;  # (data not lost, see virus quarantine)

 $final_banned_destiny     = D_REJECT;   # D_REJECT when front-end MTA

 $final_spam_destiny       = D_BOUNCE;

 $final_bad_header_destiny = D_BOUNCE;     # False-positive prone (for spam)

-----------------

Re: Error 554 5.6.0 with bad header

OR

$allowed_header_tests{'8bit'} = 0;

$allowed_header_tests{'missing'} = 0;

--------------------------------------------------

---------------------------------------------------------------------

Postfix, Amavis & outgoing mails: How to notify the sender

-------------------------------------------------

Bypass amavisd-new scanning - Postfix integration

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 fromhttp://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

--------XXXXXXXXXXXXXXXXXXXXXXXXXXXX_-----------------------------------------------------------------

AMaViS: deal with SPAM, Viruses, Banned attachments, and Bad headers.

Once undesirable mail is found, AMaViS has the ability to quarantine, discard and/or allow the undesirable mail to pass and be delivered to destination address(es).

Amavisd-new can place useful information in the header of processed eMails, notifying people of taken actions and also “defang” undesirable messages.

When AMaViS “defangs” eMails, the original message can be encapsulated as attachment of a notice, delivered to destination address.

The critical point of AMaViS configuration is to decide what action should be taken when an undesirable message is found.

Settings that deal with viruses, banned attachments, and bad headers:

Possible settings for the $final_*_destiny variables are: D_PASS,D_BOUNCE, D_REJECT and D_DISCARD.

In this context, indeed, two possible settings for the $*_quarantine_to variables will be analyzed: these variables can either be configured, orundefined.

$*_quarantine_to variables define where the quarantined items will be stored, or (assigning an empty value means “no place for quarantined items to go”.

When an undesirable email is found, following actions will be taken configuring $final_*_destiny variables (for undesirable eMail messages):

D_PASS: Mail will pass to recipients, regardless of bad contents. If a quarantine is configured, a copy of the mail will go there, if not, at least the recipient received the mail.

Note that including a recipient in a @*_lovers_maps is functionally equivalent to setting $final_*_destiny = D_PASS; for that recipient.

D_BOUNCE: Mail will not be delivered to its recipients. A non-delivery notification (bounce) will be created and sent to the sender.

Exceptions: Bounce (DSN) will not be sent if a virus name matches @viruses_that_fake_sender_maps, or to messages from mailing-lists (Precedence: bulk|list|junk), or for spam level that exceeds the $sa_dsn_cutoff_level.

If a quarantine is configured, a copy of the mail will go there, if not eMail message will be lost, but if the mail was legitimate, the sender should receive notification of the disposition of the message.

D_REJECT: Mail will not be delivered to its recipients. AMaViS will send the typical 55x reject response to the upstream MTA and that MTA may create a reject notice (bounce) and return it to the sender.

This notice is not as informative as the one created using D_BOUNCE, so usually D_BOUNCE is preferred over D_REJECT.

If a quarantine is configured, a copy of the mail will go there, if not eMail message will be lost, but the sender should be notified their message was rejected.

D_DISCARD: Mail will not be delivered to its recipients and the sender normally will NOT be notified.

If a quarantine is configured, a copy of the mail will go there, if not eMail message will be lost. Note that there are additional settings available that can send notifications to persons that normally may not be notified when an undesirable message is found, so it is possible to notify the sender even when using D_DISCARD.

Commonly, D_DISCARD method is preferred for SPAM or Viruses, as creating a DSN is usually a bad idea for several reasons, among them the fact that if the mail is “MalWare” or originated by BOTNets, sender address is probably undeliverable or non existent, or worse it is a real address that has been forged.

Practical examples of how a system might be configured:

When a virus is detected, the mail will be discarded.

If a message containing a banned file is received, the sender may (or may not) be sent a notification, and the message will be quarantined to the email address listed here.

Typically it is up to the system administrator to review what is in this mailbox, and either forward the message to the recipient, or delete the message.

If a message is received that contains a malformed header, the message will be sent to the recipient, and a copy will be sent to a quarantine area on the local machine. This copy can be examined by the administrator and a determination made whether there should be any further action to prevent similar email from entering the system. Malformed headers, while annoying, are typically not a security risk.

SPAM is different than the other types of undesirable mail because in addition to “quarantine, discard and/or allow the mail to pass”, there are 2 more actions that can occur: it is possible to rewrite the Subject line in the eMail that is passed to the recipients to notify them that the message is possible SPAM and generate SPAM-related informations in the header of the mail.

SpamAssassin’s only goal in life is to come up with a numerical score. Very low scores and negative scores may be considered HAM (NON-SPAM) and higher scores may be considered SPAM.

Usually a score of 5.0 is the target demarcation-point between HAM and SPAM, but unfortunately legitimate mail does on occasion score higher – and spam lower.

It is completely up to eMail System Administrator to decide what score will be the demarcation point between HAM and SPAM.

These work exactly the same as described above in the first group. In other words, these two spam settings are parallel to the settings of the other three types of undesirable mail.

These settings are numeric values that will be compared to the score produced by SpamAssassin.

$sa_tag_level_deflt sets at which score the X-Spam-Status, X-Spam-Score and X-Spam-Level headers are added.

Setting this to undef or -999 means every message that is considered local will have these informative headers added, SPAM or not.

The domain the mail is addressed to must match an entry in @local_domains_maps (or other lookup table that provides the same functionality) to be considered local.

Note that for this particular setting, undef means ‘lower than any possible score’.

$sa_tag2_level_deflt is the level at which the Subject line of the email will be prepended with whatever is assigned to the $sa_spam_subject_tagvariable (assuming $sa_spam_modifies_subj is true).

This is done for mail that (once again) is considered local and will actually reach a recipient. The X-Spam-Status extra header will change from “NO”to “YES” and a new X-Spam-Flag: YESheader will be added.

$sa_kill_level_deflt is the score at which actions are taken with the SPAM message. Once an email scores at this level, $final_spam_destiny settings (D_PASS, D_BOUNCE, D_REJECT or D_DISCARD) will occur.

Practical examples of how a system might be configured:

If a message reaches the score set in $sa_kill_level_deflt the message will not be delivered to its recipients and sender will not be notified.

A copy of the mail will go to the email address configured.

Any message that is addressed to a recipient that is considered local will have X-Spam-Status, X-Spam-Score and X-Spam-Level headers added.

Mail that scores at 5.0 or above will have ‘[SPAM] ‘ prepended to the Subject line. The X-Spam-Status extra header will change from “NO” to “YES” and a new ‘X-Spam-Flag: YES’ header will be added.

This is the level that triggers the D_DISCARD action assigned to $final_spam_destiny and is also the level at which quarantining occurs (if a quarantine is configured).

Additional SPAM related settings:

Using D_DISCARD, this setting has no purpose instead, using D_BOUNCE, this set a level at which the sender will no longer be notified.

If SPAM is quarantined, it is possible to delete high scoring spam (therefore reducing the number of items in the quarantine). This setting allows to discard quarantined spam at this level and above.

It only makes sense to maintain the relationship:

sa_tag_level <= sa_tag2_level <= sa_kill_level < sa_dsn_cutoff <= sa_quarantine_cutoff_level

Tags: AMaViS, AntiSPAM, AntiVirus, AV, Bad Header, Banned Attachments, eMail, Spam, Virus,Viruses

This entry was posted on Tuesday, April 24th, 2012 at 12:01 PMand is filed under . You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

------

Amavis send bounce emails to sender for banned files - result in Backscatter

how to make amavis notify spam mail to sender

--------