Postfix/Amavis/SA Tips

desactiver le filtrage pour les mails en provenance de la commande sendmail (mail du systeme...)

pour le ’pickup’ dans master.cf.

ces deux lignes permettent de désactiver :

 le filtrage par amavisd
 le filtrage des headers/body

Ne filtrer que sur les mails entrant :

A tip from Wietse Venema (2002-12-12) :

If you want to filter inbound SMTP mail only, then :

/etc/postfix/recipient_access :

That filters all the mail that has at least one recipient in your
domain, and does not filter mail with external recipients only.

(comment : the ’foo:bar’ is what you would traditionally specify
in content_filter option, i.e. smtp-amavis :[127.0.0.1]:10024 )

Postfix en tant que client AUTH dans le cas de l’utilisation d’un relayhost

ajouter ceci au main.cf :

Note : dans cet exemple on considere que le serveur smtp du FAI écoute sur le port 587. Il est bien sur inutile de specifier un port si il ecoute sur le 25.

et dans le sasl_client mettre :

puis postmap sur ce fichier
un chmod pour limiter l’acces en lecture (password en clair)

et postfix reload

Indiquer le type de boites à postfix pour la livraison en virtual domain :

home_mailbox ne concerne que les boites locales.

pour les boites virtuelles c’est le / a la fin du lookup de la table virtual_mailbox_maps qui definit le style de boite maildir

Forcer les utilisateurs du réseau interne a envoyer des emails avec notre domaine uniquement.

main.cf :

/etc/postfix/internal_networks :

/etc/postfix/our_domain_as_sender :

/etc/postfix/not_our_domain_as_sender :

Avec cette règle on oblige les users internes a envoyer les mails avec notre ou nos domaines dans le MAIL FROM.
Ainsi on empeche l’utilisateur de spoofer son adresse email.
Les users externes également seront bloqués systématiquement si ils ont notre ou nos domaines dans le MAIL FROM.

ATTENTION : La limite de cette règle est l’utilisation de l’authentification SASL.
Les users authentifiés pourront alors bypasser l’interdiction.

Dans ce cas il faudra utiliser une règle spécifique ainsi qu’une table relationnelle.
Ce point est détaillé dans l’article sur l’installation complète d’un serveur de mail

Interdire l’envois de mails à partir de l’exterieur sur un alias

(liste de diffusion privée par exemple)
basé sur une plage d’ip différente de mynetworks :

dans /etc/postfix/main.cf, rajouter ou modifier :

contenu de /etc/postfix/local_network

contenu de /etc/postfix/local-ml :

forcing TLS for specific hosts

Mailing List de postfix par Noel Jones :

The simple method is to use a check_client_access map with
reject_plaintext_session. This does not verify the identity of the
remote host other than by IP or name, and is subject to a
man-in-the-middle attack. So while this would insure an encrypted
channel, it would not necessarily insure a secure channel.

Also, this simple example doesn’t address the issue of mail arriving
from some third-party IP using a sender address from the encrypted
domain. Wether such mail should be accepted or rejected depends on
local policy and why you want an encrypted channel in the first place.

# main.cf

# require_encrypted

For a secure, verified channel, you would need to use
"smtpd_tls_req_ccert = yes" and use a check_ccert_access table to
allow them entry. This is best done on a separate IP address not
intended for general public use because of possible interoperability
problems when requesting client certificates.

Mise à Jour des Rules SpamAssassin

• verifier les rules :

• si tout est ok, effectuer la mise a jour des rules officielles :

• Verifier a nouveau :

preparer la mise à jour des rules SARE

• Ajouter chaque liste que l’on veut mettre a jour par sa-update dans un fichier sare-sa-update-channels.txt.

note :
Channels names are created by prepending the .cf file name found on
the SARE site (http://www.rulesemporium.com/rules.htm) to
".sare.sa-update.dostech.net". If you wanted to include the 70_sare_adult.cf
ruleset, you might do the following :

contenu du fichier sare-sa-update-channels.txt complet

• mise à jour des rules SARE
  sa-update --channelfile /etc/mail/spamassassin/sare-sa-update-channels.txt --gpgkey 856AA88A

• Verification des Rules :
  su -c "spamassassin -D --lint" amavis

• relancer SA soit en relancant amavisd pour ceux qui l’utilise ou bien spamd

Désactiver le Body et Header Checks pour les utilisateurs internes

Kyle Dent
Since Postfix body and header checks do not have a way to whitelist known good clients or IP addresses, administrators generally configure a separate content filter to handle anything more complicated than simple checks that they can confidently apply to all messages. In many situations, however, you might find it helpful to disable body and header checks for internal users. Email from the outside is subject to the checks, but internal messages do not use up processing and memory resources, and you do not risk generating false-positives on messages from your own users. This How-To describes one way to bypass header and body checks for internal senders using the receive_override_options feature that was introduced in version 2.1 (and earlier snapshots) of Postfix. If you are using a version prior to 2.1, the technique described here will not work. This method also requires an additional IP address for your Postfix system.

The idea is simple enough. Set up an additional smtpd instance for your internal users and disable body and header checks for that instance only. We will also disable body and header checks in the pickup daemon so that messages submitted locally (on the same machine) will bypass content checking as well. The second smtpd instance listens on a separate IP address. You should obtain an IP address from your network administrator. If your system has multiple network interfaces, then you may already have a second IP address to use. If one interface is for an internal subnet, use its IP address as the second one. If you don’t have two or more network cards, configure the second IP address as an alias on your single network interface.

Adding an IP Address
If you have two interfaces, and you’ve identified the IP address of the one you will use for internal users, you’re all set. Skip ahead to "Configuring Postfix" below. Otherwise, the task of creating IP address aliases differs across various Unix platforms. Check your system documentation to see how it is done on your operating system. Most Unix platforms use the ifconfig command. You will probably find the information you need in the ifconfig man page. For example, Linux and HP-UX use an index number along with the name of the interface. Configuring the second IP address 192.168.100.12 on Linux, looks like the following :

Other platforms, like FreeBSD and IRIX, use an alias command along with ifconfig, for example :

You will want to configure your system so that the second IP address is automatically set when your system boots up. See your system documentation for the best way to do that. Also, if this second interface is accessible from the Internet, make sure that you configure your firewall so that external systems cannot reach it. It’s meant to be accesed by your internal users only.

Configuring Postfix
Now that you have a second IP address, you need to configure Postfix to start a second instance of smtpd to handle requests over that address. Before getting to that, however, you need to make sure that your primary smtpd does not gobble up all of the IP addresses before your second instance gets a chance at one. You can do that by editing the inet_interfaces parameter in your main.cf file. The parameter inet_interfaces specifies which of your interfaces Postfix should listen on, and by default, it’s set to "all." You want to set it so that Postfix listens on all IP addresses except the one we’re configuring for bypassing content checks. (We’ll get Postfix listening on that one next.)

Edit main.cf and find or add the inet_interfaces parameter. Set it to your main IP address (plus any additional IP addresses you may have excluding the new one). In this example, the main IP address is 192.168.100.11, and it is the only IP address the original smtpd daemon should respond on.

# main.cf

Next we’ll create a new entry in master.cf to add the additional instance of smtpd. This entry is identified by the new IP address plus the smtp port, which it should listen on. The entry includes a configuration option to turn off body and header checks through the receive_override_options parameter :

#
# master.cf
#

Note that the second line must start with whitespace to indicate that it is a continuation of the previous line. There cannot be any spaces between receive_override_options, the equals sign, and no_header_body_checks. If you wanted to make other configuration changes to this instance, you can add them in the same way. Otherwise, this instance will use the same configuration from main.cf other than any of the parameters you override here.

Also create a similar entry for the loopback address and add the same no_header_body_checks feature to the pickup daemon so that all mail submitted locally will also bypass the checks. The entries in the master.cf file (including the original smtpd entry) should look like the following :

You will have to stop and start Postfix after making these changes. A reload is not enough when adding or changing interfaces :

postfix/postfix-script : stopping the Postfix mail system

postfix/postfix-script : starting the Postfix mail system
Be sure to check your log file to make sure there are no errors.

Tell your users to set their email clients to use 192.168.100.12 (or its hostname) as their SMTP server. Then all mail from your local network or from the machine itself will skip body and header checks configured in main.cf.

Summary
Here’s a quick summary of the steps to bypass header and body checks for internal users :

Obtain or identify an IP address to use for internal email relaying. Using either a second interface or IP aliasing configure your system with the second IP address. Make sure that the new address comes up when the system initializes.
Set the parameter inet_interfaces in main.cf so that your original smtpd does not use your new internal IP address.
Add entries to master.cf for the new IP address and for the loopback IP. Include the configuration option

to skip body and header checks. Also, add the same configuration override to the pickup daemon to skip the checks.
Stop and restart Postfix. Check your log file for any problems.

Postfix on an ext3 filesystem

http://www.arschkrebs.de/postfix/postfix_ext3.shtml

Recommended Setup

• use data=journal journalling mode for the $queue_directory (usually /var/spool/postfix).

ext3 was designed to perform full data and metadata journaling. In this mode (called "data=journal" mode), the JBD journals all changes to the filesystem, whether they are made to data or metadata. Because both data and metadata are journaled, JBD can use the journal to bring both metadata and data back to a consistent state.

For the $queue_directory we get no performance penalty, because most queuefiles dont stay in the queue very long, thus they’re written to the journal only and deleted from there.

• mount $queue_directory using the option noatime. Postfix doesn’t care about the atime of a queuefile. Since atime updates affect the file and all directories above it, we get a performance boost by that.

• A simpler way to do this is to mount the whole of /var in data=ordered (the default) mode and then use : chattr -R -S +j +A /var/spool/postfix/

It sets noatime, data=journal and async only in the $queue_directory.
lsattr $queue_directory shows correct flags even for newly created files.
This was noted by Cosimo Alfarano.

• Since we’re using data=journal, we can safely say chattr -R -S /var/spool/postfix ext3 guarantees the integrity of the directory

• make sure that /var/log is not using data=journal journalling mode. data=ordered (the default) gives the same guarantees as data=journal when just appending (and you’re appending to logs only !) — while being faster. This usually means you have to have a partition for /var/log and another one for /var/spool/postfix

• Disable the write-cache for your drive : Linux cannot currently deal with write caches in drives properly, because it cannot tell the drive when to flush the cache. Current disk drives have big caches (2 MB and in excess of that) and can easily swallow several hundred mails at a time. You don’t want that. Tagged Command Queueing (SCSI only in Linux at the moment) partially makes up for that.

Write barrier support is on its way (Chris Mason posted an alpha-quality patch to the linux-kernel and reiserfs mailing lists, it only supports ATA and AIC7XXX SCSI, but no qlogic or LSI SCSI, not sure what file systems are supported), which is supposed to run Linux safely with write caches on, but before this is solid and in the regular kernel, using write caches can kill your file system. All ATA drives I bought recently have had their caches turned on, so watch out. On SCSI, I’ve seen to opposite, all SCSI drives I know of have their fast write cache off.

hdparm -W0 /dev/hda

• Use elvtune -r 4096 -w 8192 for the drive containing your $queue_directory. On soft-RAID devices, you need to use elvtune on each physical drive !

I usually use :

Warning
"Andrew Morton posted on the lkml, "In 2.4.20-pre5 an optimisation was made to the ext3 fsync function which can very easily cause file data corruption at unmount time". This bug only affects people using ext3 in the uncommon "data=journal" mode, or files operating under "chattr -j", and does not affect the 2.5 series of kernels.
Andrew went on to say that "The symptoms are that any file data which was written within the thirty seconds prior to the unmount may not make it to disk. A workaround is to run sync’ before unmounting". He also posted a patch to fix the problem. However, soon thereafter, he posted saying that "that ’fix’ didn’t fix it. Sorry about that". Until a proper fix can be developed, he recommends that people "please avoid ext3/data=journal". Since "data=journal" is not the default ext3 mode, it is unlikely most people running ext3 will be affected by this. However, it is a data corruption bug so you should double-check that you use either "data=ordered" or "data=writeback" as your ext3 mode of operation. "

Hein Roehrig notes : According to http://www.redhat.com/mailing-lists/ext3-users/msg07522.html there is a bug in the Linux kernel 2.4.18 and 2.5.x which makes ext3 data=journal unsafe when both mmap() and write are used on a file. db3 does exhibit this behavior.

IMHO it should be safe to use data=journal on /var/spool/postfix.

Where is the bottleneck ?

credits go to Victor Duchovni et al.
http://www.arschkrebs.de/postfix/postfix_bottleneck.shtml

• Make sure your syslogd is logging asynchronously. In syslog.conf, change :mail.* /var/log/mail.log into: mail.* -/var/log/mail.log

• If you don’t have enough smtpd throughput you will find all the smtpd processes in use.

• If you are using high or variable latency IPC maps such as LDAP, you may find that Postfix cannot achieve the maximum configured smtpd or cleanup concurrency due to high map service connection latency. With LDAP try ldapsource_bind = no.

• If you are able to accept incoming mail quickly, but the queue manager is not able to keep up with the growth rate of the incoming queue, you will find a lot of mail in incoming/.

Consider using Postfix-1.1.X with an in_flow_delay larger than zero increased until the queue manager is able to keep up. The queue manager latency can go up either due to competition for scarce I/O cycles (in_flow_delay will help in this case), or because of slow maps (in_flow_delay may not help in this case : dump the slow maps).

• If the queue manager is keeping up, but the output rate is below the input rate you will see a growing active/ queue. Figure out which transport or destination is dominating the active queue. Arrange for a higher concurrency or lower latency in deliveries to the destination in question. Look at the number of processes for each delivery agent, are any maxed out ?

Basic stuff

• make sure you have a working local DNS cache (djbdns dnscache or BIND running on the machine). Postfix does a lot of DNS queries.
• make sure you are not an open relay (look yourself up on http://relays.osirusoft.com/cgi-bin/rbcheck.cgi)
• make sure you are not drowning in spam bounces, start blocking using the RBL style blacklists

• don’t — if possible — accept mail from envelope senders with invalid domains : add reject_unknown_sender_domain to smtpd_sender_restrictions or smtpd_recipient_restrictions.

• don’t accept mail for non-existing local users : add local_recipient_maps = ... to your main.cf.

• if you have a lot of mail that cannot be delivered on the first attempt, consider using a fallback_relay and/or to increase the maximal_backoff_time to reduce the frequency in which deferred mail re-enters the active queue.

Tuning for higher throughput

Which sub-queue maildrop, incoming, active or deferred is affected ?

• If it’s "maildrop" make sure the pickup service is running. Better get that high-volume mail injector to use "SMTP" rather than command-line sendmail
• If "incoming", make your version of Postfix is 1.1.11 and in_flow_delay is not zero. Also make sure that your queue manager is not being restarted to often through overly frequent changes to virtual_maps or relocated_maps.
• If "active" is full, make sure you have enough "smtp" processes allocated in master.cf. Either raise the limit there from the default "50" to 100 or 200 or 500, or set default_process_limit to also enable more "smtpd" processes. Also set smtp_connect_timeout = 30s without it mail destined to unreachable sites can clog up output processing.
• If the saturation is in the "deferred" queue, stop all those invalid domains from coming into your system, enable some RBL lists, use reject_unknown_sender_domain, look at the log and block the hosts submitting the highest volume of SPAM. 

If your machine relays a high volume of inbound mail arrange to have a separate transport (say "relay") for the domains that are forwarded inbound . Set a high relay_destination_concurrency_limit(say 50). The master.cf entry for "relay" should have -o smtp_connect_timeout=$relay_connect_timeout (no spaces around the = sign !) Then set relay_connect_timeout in main.cf to "5s" or "1s".

If you are doing content filtering for viruses via an SMTP based content filter (the second alternative in FILTER_README) make sure the sending transport (again clone "smtp" in master.cf and call it "filter", "scan" or "vscan") is configured with -o disable_dns_lookups=yes, this is described in FILTER_README.

disable_dns_lookups=yes also helps, when you’re sending all mail to a fixed destination anyway, regardless of MX Records (e.g. when using relayhost=...

Hostname-based Selective Greylisting

Sorry if this has already discussed in the list. I am using a simple
trick (which I call "Hostname-based Selective Greylisting", or
"hbs-greylisting" for short) which is popular in Japan. But AFAICS
there’s no English article or web pages mentioning this technique.

It’s easy, and I believe it’s useful. So here goes.

In normal installation, you check all of incoming connections through
postgrey like :

This is what described in Postgrey documentation. But, this way, you
have to be careful keeping whitelist up-to-date so that your server
won’t reject or put unnecessary delay for messages from legitimate
clients. Also, your database may contain many legitimate clients’
addresses.

Since most of UCE/UBE messages that are blocked by postgrey come from
unresolvable or dynamically-assigned addresses, you can check only
those suspicious clients by postgrey and let others pass unchecked, by
configuring postfix as follows :

main.cf ----

check_client_fqdn ----

This technique is proposed by SATOH Kiyoshi
(http://k2net.hakuba.jp/rgrey/, in Japanese), and getting popularity
among mail administrators in Japan. I call this "Hostname-based
Selective Greylisting" ("hbs-greylisting" for short). (*)

(*) Mr. Satoh calls his technique "S25R + Greylisting". S25R
(Selective SMTP Rejection) is a technique that unconditionally
rejects those hosts that matched regexps unless whitelisted.
(http://www.gabacho-net.jp/en/anti-spam/anti-spam-system.html)
Satoh’s technique is a safer alternative that combines S25R and
greylisting. I thought the name "Selective Greylisting" would be
more apropriate but this is already used by Christian Mock to mean
yet another technique (http://www.tahina.priv.at/~cm/spam/). Hence
I coined a name "Hostname-based Selective Greylisting".

The effect of greylisting is slightly impaired with hbs-greylisting
because UCE/UBEs from hosts that do not match the regexps are no
longer blocked. But there are many benefits :

* Safer - The risk of rejecting legitimate clients becomes lower.
* Easier - The conservative nature of the technique makes maintenance
of whitelist rarely needed.
* Still effective - Almost all of UCE/UBEs that are blocked by normal
greylisting are also blocked by hbs-greylisting. (According to
http://www.gabacho-net.jp/en/anti-spam/anti-spam-system.html,
98% of UCE/UBE-sending hosts matches to the regexps above.)
* Requires less space - Postgrey database now contains less entries.

Now, how do you think ? Comments are welcome.
— 
Best Regards,
MAEDA Atusi

Désactiver le filtrage d’amavisd sur les mails en provenance d’utilisateurs authentifiés par SASL :

Suivant les situations il peut etre interessant de totalement desactiver le filtrage Spam pour les mails en provenance d’utilisateurs authentifiés SASL.

En revanche il est fortement déconseillé de désactiver le filtrage antivirus.

Un solution simple consiste à activer le port 587 (submission) dans le master.cf :

Pour ceux qui ont suivi le tuto sur l’installation du serveur de mail, le port est déjà activé, il suffira d’ajouter la ligne sur le content_filter.

cela force l’utilisation du TLS pour les clients se connectant par ce port, autorise l’utilisation du sasl uniquement et redirige les mails entrant sur une policy bank d’amavisd.

On active le port dans amavisd :

Dans la configuration par défaut des versions amavisd 2.5.1 et supérieures, on trouve un policy bank préconfigurée sur le port 10026 (ORIGINATING).

il suffit d’ajouter les paramètres que l’on souhaite lui appliquer spécifiquement :

on relance amavisd et postfix

Attention : les mails qui arriveront sur le port 25 ne seront pas traités par cette policy banks meme sil le client s’authentifie par SASL.
Seuls les mails arrivant sur le port 587 sont concernés.

NOTE : Les clients doivent spécifier le port explicitement dans leur configuration (par défaut c’est le port 25)