Tuning Postfix + Spamassassin [Résolu] - Installation - Linux et OS Alternatifs
Marsh Posté le 25-02-2016 à 12:37:34
Salut ! J'ai quelques questions sur ta config ! Y'a quelques trucs que je ne comprends pas trop.
Pourquoi tu configures smtpd_milters dans main.cf pour l'override ensuite dans ton master.cf ? Pourquoi ne pas mettre directement :
smtpd_milters = unix:/opendkim/opendkim.sock |
dans ton main.cf et enlever les lignes inutile de ton master.cf ?
La même pour smtpd_sasl_auth_enable, tu déclares smtpd_sasl_auth_enable=yes dans ton main.cf et tu le remet dans ton master.cf.
Et pourquoi tu forces les connections en TLSv1 ? Pourquoi ne pas laisser le choix entre du TLSv1 / TLSv1.1 / TLSv1.2 et donc utiliser du 1.2 quand c'est possible ?
D'ailleurs, avec ta config TLS (smtp(d)_tls_CAfile=/configuration/ssl/DigiCertCA.crt), tu chopes pas uniquement des "Untrusted TLS connection established from" & "Untrusted TLS connection established to" ?
Marsh Posté le 29-02-2016 à 01:16:55
Salut FxT² !
Merci bcp pour ta réponse.
En fait pour tout ça j'ai suivi plusieurs tuto que j'avais trouvé sur internet..
Je vais enlever les lignes que tu me dis dans le master.cf concernant opendkim et sasl_auth.
Pour les connections TLS il faut donc que je mette :
Code :
|
C'est bien ça ?
D'ailleurs, avec ta config TLS (smtp(d)_tls_CAfile=/configuration/ssl/DigiCertCA.crt), tu chopes pas uniquement des "Untrusted TLS connection established from" & "Untrusted TLS connection established to" ? |
Oui c'est exactement ce que j'ai...
Merci pour ton aide
Marsh Posté le 29-02-2016 à 16:33:39
Après quelques recherches il semblerait que mettre dans main.cf :
Code :
|
Ne permet d'avoir que la vérification des éventuelles signatures des messages reçus.
Et que si on veut que les messages sortant soient bien signés il faut ajouter aussi à master.cf
Code :
|
En ce qui concerne la partie suivante :
D'ailleurs, avec ta config TLS (smtp(d)_tls_CAfile=/configuration/ssl/DigiCertCA.crt), tu chopes pas uniquement des "Untrusted TLS connection established from" & "Untrusted TLS connection established to" ? |
Savez-vous quelle est la bonne configuration à faire ?
Marsh Posté le 01-03-2016 à 11:39:27
Salut,
Je n'ai pas l'air d'avoir de problème avec les messages sortants avec uniquement :
Dans main.cf :
# OpenDKIM |
http://www.mail-tester.com/web-kDsxeA
---------
-o sert à override la configuration globale pour un service spécifique. Par exemple, si tu veux de l'opportunistic TLS (may) en IN sur tous les services sauf submission.
Dans main.cf :
smtpd_tls_security_level = may |
Mais dans master.cf, tu vas override cette ligne de conf uniquement pour submission :
submission inet n - - - - smtpd |
---------
K-ny13 a écrit :
|
Oui et non :
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 |
Pas besoin de plus.
Marsh Posté le 01-03-2016 à 12:50:11
K-ny13 a écrit : En ce qui concerne la partie suivante :
|
Si tu es sur debian :
$ apt install ca-certificates |
Dans ton main.cf :
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt |
Pour du rpm : http://rpm.pbone.net/index.php3?st [...] &srodzaj=3
------------------
La conf que j'utilise en ce moment (si vous voyez des incohérences/erreurs ou des choses que je pourrais optimiser, n’hésitez pas à me le dire !) :
# SMTP Out |
Pour la cipherlist, j'utilise les recommandations de bettercrypto.org.
Marsh Posté le 01-03-2016 à 18:20:26
Ok merci c'est corrigé.
A première vu ta configuration me semble très bien.
Je suis sous RedHat 6 et ca-certificates est déjà installé.
Mais en fait je ne vois pas vraiment quel est le problème avec le certificat ?
Marsh Posté le 01-03-2016 à 20:48:01
Avec la configuration suivante :
smtp_tls_CAfile = /configuration/ssl/DigiCertCA.crt |
Tu vérifies le certificat des MTA auxquels tu te connectes uniquement avec le certificat intermédiaire de ton autorité de certification (DigiCert).
Donc forcément, tu te retrouves avec quasiment que des "Untrusted TLS connection established to".
alors qu'avec :
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt |
Tu vérifies la signature a l'aide des CA certificate présent dans le Mozilla CA Certificate Store.
postfix/smtp[25804]: Trusted TLS connection established to gmail-smtp-in.l.google.com[64.233.167.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) |
Je te cache pas que c'est vraiment du pinaillage (pour un serveur mail), mais perso, ça me stresse de voir du Untrusted.
Après, est-ce c'est qu'il est vraiment utile (dans ton environnement) de vérifier la signature des certificats (en IN/OUT) ? Dans quelle mesure ça impacte les performances ? C'est des questions auxquelles je pourrais pas répondre, c'est d'ailleurs pour ça que je poste un peu sur ton topic, j'aimerais bien l'avis d'HFR.
Autrement, t'as trouvé des infos sur ce qui pourrait influencer le delay a (time before queue manager, including message transmission) ?
Marsh Posté le 02-03-2016 à 15:47:44
D'accord je comprend mieux, merci.
Mon problème initial concernant le delay a est résolu.
En fait, lors de mes tests de charge j'y suis aller un peu fort.. 100 000 mails/5min (soit 333 mails/s). Toutefois sans Spamassassin la charge était tenu.
Plusieurs choses peuvent influencer le delay a :
- Réseau saturé.
- Capacité d'entrée/sortie du disque.
- Charge CPU
- Mémoire RAM insuffisante.
- Limite du nombre de processus client SMTP simultané/concurrent.
Dans mon cas ce n'était pas un problème réseau, ni de vitesse des disques, ni d'un manque de mémoire.
J'ai alors augmenté le nombre de CPU (de 2vCPU à 4vCPU) et cela m'a permis de diviser par deux le temps moyen d'envoi des mails. Mais, bien que divisé par 2, le delay a était toujours trop élevé.
Le CPU n'était donc pas réellement la source du problème.
J'ai continué mes recherches et je suis tombé sur : http://postfix.traduc.org/index.ph [...] ming_queue
qui explique que la seule manière de réduire la congestion est soit de réduire le taux d'entrée soit d'augmenter le taux de sortie. Cette dernière proposition se traduit soit par une augmentation de la concurrence soit par la réduction de la latence de livraison.
Tous les nouveaux messages entrant dans Postfix sont écrits par le service cleanup dans la file d'attente "entrante".
Le paramètre in_flow_delay est utilisé pour limiter le taux d'arrivée lorsque le gestionnaire des files d'attente commence à faiblir. Le service cleanup attendra $in_flow_delay secondes avant de créer un nouveau fichier en file d'attente s'il ne peut obtenir de "jeton" du gestionnaire des files d'attente.
Depuis que le nombre de processus cleanup est limité dans la plupart des cas par la concurrence des serveurs SMTP, le taux d'entrée peut excéder le taux de sortie de plus de "nb de connexions SMTP" / $in_flow_delay messages par secondes.
Avec une limite de processus à 100 et un in_flow_delay de 1 seconde, le couple est assez fort pour limiter un injecteur simple à 1 message par seconde, mais pas assez pour infléchir un taux d'entrée excessif provenant de plusieurs sources au même moment.
La limite par défaut des processus "smtp" fixée à 100 est assez élevée pour beaucoup de sites et peut être abaissée pour les sites disposant d'une faible bande passante (à n'utiliser que si le réseau est saturé). Lorsqu'on trouve que la file d'attente croît sur un système "peu actif" (CPU, I/O disque et réseau non saturés) la raison résultante de la congestion est une insuffisante concurrence face à la charge. Si le nombre de connexions sortantes SMTP (en état ESTABLISHED ou SYN_SENT) atteint la limite des processus, que le courrier est traité lentement et que le système et le réseau ne sont pas chargés, il faut augmenter la limite des processus "smtp" et/ou "relay" !
Dans ma configuration, "smtp" reçoit le mail, l'envoi à Spamassassin pour analyse qui le renvoi à "smtp" pour qu'il délivre le message. Le goulot d’étranglement était au niveau de Spamassassin avec un nombre de processus actif simultanément bien inférieur au processus "smtp" ce qui provoqué la congestion des mails et donc l'augmentation du delay a.
Dans mon cas augmenter le CPU, augmenter le nombre de processus à 200 et augmenter le nombre de processus spamd (pour spamassassin) semble avoir résolu mon problème.
Je pense repasser à 2vCPU. Avec le bon réglage du nombre de processus je pense que c'est suffisant.
Contenu de mon fichier /etc/sysconfig/spamassassin :
Code :
|
Lien utile : http://postfix.traduc.org/index.ph [...] .html#rope
Marsh Posté le 17-02-2016 à 18:26:12
Bonjour,
Nous avons 2 serveurs SMTP derrière un F5 qui gère la répartition de charge sur les 2 serveurs.
Tout est installé/paramétré et fonctionne correctement (Postfix + Spamassassin).
Avant la mise en production je voudrais optimiser le tout car lors de mes tests de charge j'ai pu constater un gros ralentissement pour délivrer les mails.
Nos serveurs doivent pouvoir livrer entre 800 000 et 1000 000 de mails sur 24h.
Chaque serveur dispose de 4vCPU et 8Go RAM.
La partie "a" du delai (delay=a/b/c/d) augmente beaucoup lors de gros envoi. Quels sont les paramètres qui influence ce temps ?
Quels conseils pouvez-vous me donner pour optimiser Postfix + Spamassassin ?
Voici le contenu de quelques fichiers de configurations :
Extrait de main.cf
Contenu de master.cf :
Contenu de /etc/sysconfig/spamassassin :
Merci d'avance pour votre aide !
Message édité par K-ny13 le 09-03-2016 à 11:26:00