Amavis Configuration and Setup Guide

To start configuring Amavis, you'll need to edit the amavisd.conf file, which is usually located in the /etc/amavis directory.

This file contains all the configuration settings for Amavis, including the mail server it's running on and the spam filtering rules.

First, you'll need to specify the mail server Amavis should use to scan incoming mail. This is done by setting the $MYHOME variable in the amavisd.conf file.

This variable should be set to the path of the mail spool directory on your mail server.

Next, you'll need to specify the spam filtering rules that Amavis should use. This is done by setting the $spamassassin_dspam_options variable in the amavisd.conf file.

You can also configure Amavis to use a Bayesian spam filter by setting the $baysian_spam_filter variable.

Make sure to save any changes you make to the amavisd.conf file, as these changes will not take effect until the file is reloaded.

Worth a look: Sieve (mail Filtering Language)

The design priorities of Amavis are reliability, security, adherence to standards, performance, and functionality.

Amavis can read and include Postfix hash files as well as CIDR files, which can be useful if you manage Postfix using files like I do. This feature allows you to reduce the spamscore if you receive an email from someone you wrote a mail to beforehand.

To ensure a smooth setup, it's essential to configure Amavis correctly. If your hostname is not a FQDN, you must set $myhostname and $mydomain accordingly in /etc/amavisd/amavisd.conf.

The design of Amavis is guided by a set of clear priorities.

Reliability is at the top of the list, meaning that Amavis is designed to be stable and consistent in its performance.

Security is also a top priority, with Amavis taking steps to protect against spam and viruses.

Adherence to standards is another key design priority, with Amavis following established protocols and guidelines.

Performance is also important, with Amavis designed to run efficiently and effectively.

Functionality is the final design priority, with Amavis providing a range of features and capabilities to meet the needs of users.

To set up the basic configuration for Amavis, you'll need to make a few tweaks. First, ensure your hostname is a FQDN by setting $myhostname and $mydomain in /etc/amavisd/amavisd.conf.

Adding the clamav user to the amavisuser group is crucial to avoid permission problems. This simple step can save you a lot of headaches down the line.

Finally, restart the services by running the commands: restart clamav-daemon.servicestart amavisd.service and possibly enable it to get everything up and running smoothly.

In Postfix, mynetworks defines who is a trusted sender. This setting is crucial for controlling who can send mail through your server.

mynetworks is a special case because it defines who is an internal sender in Amavis, which might not always match the Postfix setting. This discrepancy can cause issues if not properly configured.

The release notes for Amavis state that both mynetworks settings will likely be identical, but this might not always be the case. This means you should double-check your configurations to ensure they align with your specific setup.

Broaden your view: Sender Policy Framework

Amavis can receive mail messages from an MTA over one or more sockets of protocol families PF_INET (IPv4), PF_INET6 (IPv6) or PF_LOCAL (Unix domain socket), via protocols SMTP, LMTP, or a simple private protocol.

These protocols include SMTP, LMTP, and a private protocol called AM.PDP, which can be used with a helper program like amavisd-milter to interface with milters.

Amavis can also forward mail via SMTP or LMTP over a Unix or INET or INET6 socket, or by a pipe to some external command, such as a sendmail mail submission program.

In a SMTP or a LMTP relay configuration, the amavisd-new can be located on a separate host from the MTA host, and several MTAs may share a single amavisd-new service.

Amavis supports SMTP Command Pipelining (RFC 2920) in both client and server code, and can optionally encrypt sessions using a TLSSTARTTLS (RFC 3207) extension to the protocol.

Here are some of the protocols and interfaces that Amavis supports:

Amavis can also be used with SpamAssassin, where a daemon process amavisd is similar to a spamd process of a SpamAssassin project, but they use different protocols: Amavis speaks a standard SMTP protocol to an MTA, while spamd uses a private protocol with spamc.

If this caught your attention, see: Apache SpamAssassin

Amavis takes security seriously, running its mail processing tasks with reduced privileges under a dedicated user ID and optionally chroot-ed to minimize risks of buffer overflows and memory allocation bugs. This approach helps prevent malicious data from propagating to the system.

Amavis also uses Perl's dynamic memory management to handle protocol handling and mail processing, which reduces the risk of security vulnerabilities. Additionally, it employs the "taint" feature to mark potentially malicious data and only untaints it at strategic points in the data flow.

To further enhance security, Amavis can use external programs like virus scanners and spam scanners, but these can be disabled selectively or as a group if needed. It's also recommended to use fairly recent versions of external programs and Perl modules to avoid known security problems.

To optimize performance, Amavis uses a pre-forked model to manage reusable children, which saves on process creations and startup latency. It also employs various techniques to speed up mail processing, including caching recent body message digests (MD5) and calling spam and virus scanners once per message regardless of the number of recipients.

Curious to learn more? Check out: Spam Bully

Here are some key performance features of Amavis:

To increase the number of processes Amavis uses, you can edit the file /etc/amavis/conf.d/50-user and insert a line like "push @local_config, qw( $max_servers = 10 );" where 10 is the desired number of processes. Be sure to also amend the max_procs line in /etc/postfix/master.cf with the same value.

Amavisd-new runs with reduced privileges under a dedicated user ID to minimize risks of security breaches.

This approach significantly reduces the potential damage that could be caused by a security vulnerability, as a non-privileged user ID can only accomplish so much.

The use of a chroot setup can further limit the damage to what a non-privileged user ID can accomplish in normal setups.

A chroot setup is a way to restrict a process to a specific directory, preventing it from accessing other parts of the system.

Amavis avoids risks of buffer overflows and memory allocation bugs by implementing all protocol handling and mail processing in Perl, which handles dynamic memory management transparently.

Perl's transparent dynamic memory management is a key feature that helps prevent common security issues.

Amavis puts Perl's tainted data feature to good use by avoiding automatic untainting of data and only untainting it explicitly at strategic points, late in a data flow.

This careful handling of tainted data helps prevent security breaches by ensuring that potentially malicious data is not inadvertently propagated to the system.

External programs used by Amavis, such as de-archivers, de-compressors, virus scanners, and spam scanners, can potentially introduce security risks.

These external programs are often implemented in languages like C or C++, which can be more vulnerable to security issues than Perl.

To mitigate this risk, Amavis runs these external programs as an unprivileged user ID and possibly chroot-ed, limiting the potential damage.

It's a good idea to use fairly recent versions of external programs and Perl modules to minimize the risk of security vulnerabilities.

Some known security problems can be avoided by disabling the use of external decoding programs in the Amavisd configuration file or by removing entries from the list @decoders.

Amavis itself is not slow, despite being implemented in an interpreted programming language Perl. It achieves good performance by dealing with data in large chunks and avoiding unnecessary data copying.

Bottlenecks are detected during development by profiling code and benchmarking. A detailed timing report in the log can help recognize bottlenecks in a particular installation.

Certain external modules or programs, like SpamAssassin or some command-line virus scanners, can be very slow and consume most of the processing resources. This makes the resources used by Amavis itself seem relatively small.

Components like external mail decoders, virus scanners, and spam scanners can be selectively disabled if they are not needed. This leaves only the functionality implemented by Amavis itself, such as transferring mail messages and checking mail header section validity.

As a result, mail processing tasks like DKIM signing and verification can be exceptionally fast and even rival implementations in compiled languages.

Recommended read: Duckduckgo Search Not Working

Here are some key features that contribute to Amavis's performance:

To increase the number of processes that amavisd-new uses, edit the file /etc/amavis/conf.d/50-user and insert the line: " $max_servers = X;" where X is the number of processes you wish amavis to use.

IP Address Reputation is a feature in Amavisd-new that helps identify potential spam sources. With version 2.9.0, this feature is enabled by default when a Redis storage back-end is used.

Amavisd-new collects public IP addresses from a mail message's 'Received' trace header fields. These IP addresses are stored in a Redis database with counters for spam, ham, banned, and infected messages.

The counters show the number of messages encountered with each IP address in the past. A timestamp is also kept for the first and last encounter. Infrequently encountered IP addresses are automatically purged from the database by the Redis server.

Whitelisting mail servers is necessary to prevent them from being flagged as spam sources.

A unique perspective: Challenge–response Spam Filtering

Bouncekiller is a feature in Amavis 2.6.0 that helps against Backscatter.

It uses data from the Pen Pals feature to identify and filter out unwanted bounce messages. To work properly, a working SQL logging database or outbound DSN messages with a fully qualified domain name are required.

Parts decoding must not be disabled, which is a default setting. This is easily achieved when all mail from local users is submitted through a domain's official mailer.

DKIM signing and other anti-spoofing techniques like SPF and whitelisting by IP address in Received trace are also recommended.

The $bounce_killer_score should not be enabled when not all outgoing mail can be identified, or genuine bounces and returning MDN messages will be considered spam.

I personally disable this feature in my policy bank for internal mailers to avoid any issues.

Check this out: Domain Name System Blocklist

Amavis is designed to be extremely reliable, meticulously checking the completion status of every system call and I/O operation to prevent mail message loss due to unexpected events like I/O failures or program terminations.

Unexpected events are logged and handled with multiple layers of event handling, ensuring that the program can recover from errors without losing any mail messages. Amavis never takes responsibility for mail message delivery away from the MTA, instead reporting the final success status only after the message has been passed on to the back-end MTA instance and reception was confirmed.

Large mail messages are not kept in memory, so the available memory size does not impose a limit on the size of mail messages that can be processed.

Amavisd's reliability features ensure that mail messages are never lost due to unexpected events like I/O failures or program terminations.

Unexpected events are meticulously checked and logged by amavisd, which handles them with several layers of event handling.

Amavis never takes responsibility for mail message delivery away from an MTA, and only reports success after the message has been passed on and reception was confirmed.

Consider reading: MH Message Handling System

In case of fatal failures, the message stays in the front-end MTA instance's queue to be re-tried later.

Program resources like memory size and file descriptors are controlled to prevent waste and ensure efficient processing.

Large mail messages are not kept in memory, so available memory size doesn't impose a limit on the size of messages that can be processed.

To test the configuration, simply telnet to the amavisd default listening port. You should see something like "Type ehlo 127.0.0.1".

The log level can be raised to check every step of the content filtering, including spam check and virus check. This can be done by checking the /var/log/mail.log.

On messages that go through the content filter, you should see a note. This is a confirmation that the configuration is working as expected.

The guide has been tested on various Ubuntu versions, including 7.10, 10.04 LTS Server, 12.04.3 LTS, 14.04.2 LTS, and 20.04 LTS.

SpamAssassin is integrated in Amavis, so you don't need to start the spamassassin.service. This is a convenient feature that saves you the hassle of setting up a separate spamd daemon.

To enable SpamAssassin support in Amavis, simply comment out a specific line in the /etc/amavis/amavis.conf file. Before restarting the amavisd service, don't forget to run sa-update.

Amavis is its own spamassassin-daemon, meaning it uses the SpamAssassin libraries directly, eliminating the need to configure or start SpamAssassin separately.

SpamAssassin support is seamlessly integrated with Amavis, so you don't need to start the spamassassin service. To enable support for SpamAssassin, comment out the relevant line in /etc/amavis/amavis.conf.

You'll need to edit the SpamAssassin configuration based on your needs. Before restarting the amavisd service, be sure to run sa-update.

Amavis is its own spamassassin-daemon, so you don't need to configure or start spamassassin. This means you won't need to configure razor or pyzor either.

To activate spam and antivirus detection in Amavis, edit /etc/amavis/conf.d/15-content_filter_mode. After making the necessary changes, restart Amavis.

ClamAV is a great tool for virus scanning. The default behaviour of Clamav will fit our needs, with a daemon launched (clamd) and signatures fetched every day.

For more Clamav configuration options, check the configuration files in /etc/clamav.

We need to add the clamav user to the amavis group and vice versa, so Clamav can access files to scan. This is crucial for the integration with Amavis.

Be aware that virus scanning in general has a rather high memory consumption. On small cloud instances, VPS, or routers, you might be concerned about the memory consumption, which can be around 200-350mb.

To get started with Amavis, you'll need to install a few essential packages. Install amavisd-new, which will serve as the core of your Amavis setup. This will also give you the opportunity to install some useful dependencies like 7zip and unrar to help your filters scan compressed files.

You'll also need to install ClamAV, a popular anti-virus scanner, to ensure your emails are scanned for malware.

Here's a quick rundown of the necessary packages to install:

With these packages installed, you'll be well on your way to setting up Amavis.

To set up amavisd-new, you'll need to install it, along with some optional dependencies. Install amavisd-new, and consider installing 7zip and unrar as well, so your filters can examine compressed files.

You'll also need to install ClamAV, which will be used as your anti-virus scanner.

Here are the steps to install these packages:

Once you've installed these packages, you can move on to configuring amavisd-new.

When it comes to installing amavisd-new, you may have come across packaged versions that can make the process easier.

Some packaged versions are available, but they are only provided and supported by their respective authors or maintainers.

These packaged versions may not be based on the most recent version of amavisd-new.

You may be able to find other packaged versions, but it's up to you to let the community know.

Amavis can read and include Postfix hash files as well as CIDR files.

This feature is especially useful if you manage Postfix using files, as it eliminates the need to configure Amavis separately.

The idea behind this feature is to reduce the spamscore for emails sent by people you've contacted before, effectively implementing a soft-whitelisting system.

This soft-whitelisting feature was first introduced in Amavis version 2.4.2.

Amavis also gained Redis-support in version 2.8.1, which likely provides better support in version 2.9.0.

To get Amavis up and running, you need to meet a few pre-requisites. Both incoming and outgoing mail must pass through Amavis, unless you're running a relay or smarthost.

You'll need to configure your mail server to use Amavis for both SMTP and submission. This is a crucial step, so make sure to get it right.

To ensure Amavis can distinguish between incoming and outgoing mail, you must update @mynetworks and @local_domains_maps to reflect your network's reality. Don't forget to include your local domains in @local_domains_maps.

Postfix's XFORWARD protocol extension must be enabled, or you can use the AM.PDP+milter. If you're using a Milter for inbound mail, you won't need to change anything. However, if you're using an after-queue filter for your clients, make sure to enable the XFORWARD extension in your master.cf.

The lmtp_send_xforward_command should be set to yes, and if you're using SMTP instead of LMTP, use smtp_send_xforward_command.

To enable the pen pals feature, you'll need to set the $penpals_bonus_score to a positive value, such as 1.0. You can start with a small value and increase it later if needed.

The $penpals_threshold_low and $penpals_threshold_high variables control the SA score threshold for exempting mail from pen pals checks. The default value for $penpals_threshold_low is 1, and for $penpals_threshold_high, it's undef.

The $penpals_halflife variable determines the exponential decay time constant for the pen pal bonus. It defaults to 7 days, which means the bonus is halved every 7 days since the last mail sent by a local user to the current message's sender.

If you're experiencing issues with filtering, adding specific domains to the list in /etc/amavis/conf.d/50-user may help. This is especially useful if you receive mail for other domains.

The Amavis-New FAQ provides valuable information on how to add these domains. If you're still having trouble, try changing the permissions on /var/lib/amavis/tmp.

You can also modify the AllowSupplementaryGroups setting in /etc/clamav/clamd.conf to see if that resolves the issue. Restarting all services, with Amavisd-new being the last one to start, can help troubleshoot errors associated with Amavisd-new, Spamassassin, Postfix, or Clamav.

After restarting, check /var/log/mail.log to see if the error has gone away.