vendredi 9 février 2007, par
pour le ’pickup’ dans master.cf.
ces deux lignes permettent de désactiver :
le filtrage par amavisd
le filtrage des headers/body
A tip from Wietse Venema (2002-12-12) :
If you want to filter inbound SMTP mail only, then :
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 )
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
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
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
(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 :
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.
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.
su -c "spamassassin -D --lint" amavis
su -c "spamassassin -D --lint" amavis
preparer la mise à jour des rules SARE
sa-update --import GPG.KEY
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 :
echo "70_sare_adult.cf.sare.sa-update.dostech.net" >> sare-sa-update-channels.txt
contenu du fichier sare-sa-update-channels.txt complet
sa-update --channelfile /etc/mail/spamassassin/sare-sa-update-channels.txt --gpgkey 856AA88A
su -c "spamassassin -D --lint" amavis
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 :
ifconfig eth0:0 192.168.100.12 netmask 255.255.255.0
Other platforms, like FreeBSD and IRIX, use an alias command along with ifconfig, for example :
ifconfig ef0 alias 192.168.100.12 netmask 255.255.255.255
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.
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.
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 :
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 stop
postfix/postfix-script : stopping the Postfix mail system
# postfix start
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.
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.
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.
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.
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
elvtune -r 4096 -w 8192for the drive containing your $queue_directory. On soft-RAID devices, you need to use elvtune on each physical drive !
I usually use :
"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.
credits go to Victor Duchovni et al.
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).
local_recipient_maps = ...to your main.cf.
Tuning for higher throughput
Which sub-queue maildrop, incoming, active or deferred is affected ?
default_process_limitto also enable more "smtpd" processes. Also set
smtp_connect_timeout = 30swithout it mail destined to unreachable sites can clog up output processing.
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=...
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’
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 :
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.
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
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.
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)