Cette version majeure de Postfix apporte la nouveauté tant attendue : le support DSN (Delivery Status Notification). Les DSN sont les accusés de réception de message serveur que les administrateurs de messageries demandaient à Wietse Venema à cor et à cri depuis de nombreuses années. Le non support des DSN était la dernière lacune importante de Postfix et leur intégration va renforcer l'implantation grandissante de Postfix dans les entreprises en remplacement du fameux mais vieillissant Sendmail.
Nouveautés importantes de la version 2.3 :
- support DSN : enfin ;-)
- améliorations importantes du support TLS
- implémentation de l'API MILTER Sendmail pour compatibilité avec les greffons de filtrage de mail développés pour Sendmail (support partiel : pas de modifications au niveau du corps des messages)
- support des codes d'erreur étendus (RFC 3463)
- amélioration du support SASL : authentification SMTP
- ...
To: Postfix announce postfix-announce at postfix dot org
cc: Postfix users postfix-users at postfix dot org
Subject: Postfix 2.3 stable release available
A few months later than usual, Postfix stable release 2.3 is now available. The release was postponed until Postfix was complete enough for today's email environment. Hopefully I can now spend more time doing new projects.
You can find the Postfix 2.3.0 source code via the mirror sites listed at http://www.postfix.org/. If it's not there today, then it should show up in the course of the next 24 hours.
435112 Jul 11 17:24 postfix-2.3.0.HISTORY
35125 Jul 11 16:40 postfix-2.3.0.RELEASE_NOTES
2770830 Jul 11 17:25 postfix-2.3.0.tar.gz
280 Jul 11 17:25 postfix-2.3.0.tar.gz.sig
What follows is a very much compressed summary of what has changed.
See the RELEASE_NOTES file for compatibility issues that may affect your site. The HISTORY file gives a blow-by-blow account of what happened over the past 1+ year.
Wietse
- DSN (delivery status notification) support as described in RFC 3461 .. RFC 3464. This gives email senders control over notification of successful, delayed, and failed delivery. DSN involves extra parameters to the SMTP "MAIL FROM" and "RCPT TO" commands, as well as extra Postfix sendmail command line options for mail submission.
See DSN_README for details, including how to limit the amount of information that you are willing to disclose.
- Major updates to the TLS (SMTP encryption and authentication) support. Postfix 2.3 introduces a configuration user interface that is based on the concept of TLS security levels (none, may, encrypt, verify, secure) and that can more effectively deal with DNS spoofing. The old configuration user interface, with multiple boolean parameters to enable or enforce TLS, is still supported but will be removed after a few releases. See TLS_README for details.
- Milter (mail filter) application support, compatible with Sendmail version 8.13.6 and earlier. This allows you to run a large number of plug-ins to reject unwanted mail, and to sign mail with for example domain keys. All Milter functions are implemented except the one that replaces the message body (this will be added later).
All this and more is described in MILTER_README.
- Enhanced status codes (RFC 3463). For example, status code 5.1.1 means "recipient unknown". Mail clients can translate these status codes into text in the user's own language, and greatly improve the user experience. Enhanced status codes can be specified in Postfix access tables, in header/body_checks content filter rules, in "rbl" reply templates, and so on.
- Configurable bounce messages with support for non-ASCII character sets. Details are in the bounce(5) manual page.
- Plug-in support for SASL authentication in the Postfix SMTP server and client. With this, Postfix can support multiple SASL implementations without conflicting source code patches. Postfix 2.3 has Dovecot SASL support built into the SMTP server. As before, support for Cyrus SASL is available as add-on feature for the Postfix SMTP server and client. See SASL_README for more information.
- Support for sender-dependent ISP accounts, in the form of sender-dependent relayhost lookup and sender-dependent SASL username/password lookup.
- The Postfix SMTP client now implements both the SMTP and LMTP protocols. This means that a lot of features have become available for LMTP mail delivery, including the shared TCP connection cache.
- After TLS handshake failure, the SMTP client will now reconnect to the same server to try plaintext delivery (if TLS policy permits). Earlier Postfix versions would skip the server and defer delivery if no alternate MX host was available.
- All delay logging now has sub-second resolution. Besides the total delay, Postfix logs separate delays for different stages of delivery (time in queue, time in queue manager, time to set up connection, and time to deliver). This gives better insight into the nature of performance bottle necks.
- Smarter utilization of cached SMTP connections. When one destination has multiple inbound SMTP servers, the Postfix SMTP client will now send less mail via the slower ones, and more mail via the faster ones.
- Support for empty MX records. Older Postfix versions treat this as a malformed response and defer mail delivery.
Aller plus loin
- Postfix (2 clics)
- Miroir téléchargement version 2.3 (0 clic)
- Documentation Postfix en français (17 clics)
# Enfin les DSN
Posté par Drolez Ludovic . Évalué à 3.
Pour exim 4 y'a un patch, sendmail est ok, postfix aussi : ca devient bon !
[^] # Re: Enfin les DSN
Posté par Grumbl . Évalué à 7.
[^] # Re: Enfin les DSN
Posté par inico (site web personnel) . Évalué à 6.
Après, le mail peut être rejeté.
Tu recevra donc 2 mail mailer-deamon: 1 avec la confirmation de traitement, l'autre avec le motif de rejet.
[^] # Re: Enfin les DSN
Posté par Grumbl . Évalué à 6.
[^] # Re: Enfin les DSN
Posté par inico (site web personnel) . Évalué à 6.
Le prog qui ecoute sur le port 25 se contente d'ecrire un fichier qu'un autre programme parse pour voir si c'est pour lui et passe le mail au programme définit dans la conf (generalement antispam/antivirus) puis passe le résultat au programme finale qui generalement ecris le mail dans /var/mail/user.
1 programme 1 fonction.
Ca fonctionne trés bien et ca réduit les risque de faille (surtout au niveau de ce qui tourne en root).
[^] # Re: Enfin les DSN
Posté par denisb . Évalué à 5.
check_helo_access hash:/etc/postfix/helo_checks,
est là pour cela ( à mettre après permit_mynetworks, ) . normalement, cela vire tous les usurpateurs de ton nom de domaine au niveau du helo
avec le fichier helo_checks des ce genre :
mail.mon_domaine 554 you are me!
mon_domaine 554 you are not me!
123.123.123.123 554 you are not 123.123.123.123!
localhost 554 you are not me!
Avec cela tu vires presque tous les virus et vers avant le passage par l'antivirus (gros gain !).
[^] # Re: Enfin les DSN
Posté par Raphaël G. (site web personnel) . Évalué à 3.
(linuxfr et pas mal se serveur smtp ont cette politique et je peux pas envoyer de mail dessus a cause de ça :'(
[^] # Re: Enfin les DSN
Posté par imalip . Évalué à 2.
Ce qu'il propose comme test, c'est vérifier que la machine émetrice du mail n'essaie pas de s'identifier comme faisant partie du domaine de la réceptrice quand elle envoie son HELO.
Le probleme que tu cites, c'est quand le serveur SMTP faite une requete DNS sur l'IP pour vérifier que la machine est correctement déclarée. De mémoire, juste pour mon compte, ca filtre entre 250 et 400 spams par semaine.
[^] # Re: Enfin les DSN
Posté par Colin Leroy (site web personnel) . Évalué à 3.
Sinon, ça me semble normal, si tu veux avoir un serveur SMTP accepté par les autres, tu fais ça dans les règles. Si le reverse d'une IP ne pointe pas sur la même IP, c'est mal configuré.
[^] # Re: Enfin les DSN
Posté par Raphaël G. (site web personnel) . Évalué à 2.
(j'ai AUCUN contrôle sur le dns qui s'occupe du reverse et mon fournisseur de dédié a n'y fait rien)
Et on ne m'a JAMAIS répondu qu'une RFC codait ce genre de "pseudo-norme"...
Et cette "pseudo-règle" y a une règle je ne suis jamais tombé dessus, a part qu'on m'ai dit que des spammeurs ne la remplissent pas.
Les docs sur le sujet j'en ai soupé !
Pour savoir configurer un serveur smtp postfix (notament pour pouvoir mettre les compte en db sql)
Bref j'arrive a comprendre les anti-spams (spamassassin, bogofilter, etc), au moins si ça dépasse un certain score paf dehors !
(mais ce genre de règles a la con, c'est vraiment dégueulasse, ça vous vire peut-être des mails, mais vous empêchez les autres de vous contacter)
Et je passe sous silence les "gignols" (et je suis gentil) qui sont incapable de se mettre une adresse de mail qui les accepte tous
(on se retrouve a ne pas pouvoir contacter ni l'utilisateur ni même la personne qui se prétend admin)
Et je vais pas non plus me plaindre des admins qui refusent de whitelister l'ip du serveur en question (Ça leur coûte quoi ? Au pire si il se prennent un spam de chez moi c'est plainte et je passe par la case amende+prison, mais j'assume je spam pas !)
A cause de qui je ne peux pas écrire sur leur liste de diffusion, même mandriva/php/plf acceptent mes mail !!!
(sur mandriva je tourne a un score de -0.7 au lieu de -2.5 pour les autres)
Bref, a cause des "conneries" de ces admins je me retrouve a me prendre le chou a utiliser un webmail pour envoyer mes mails
Qui me parle de simplicité/facilité/etc
C'est dire ce genre de connerie me fait me retrouver sur des site comme hotmail (que je déteste), mais leur pub dans les messages est tout ce que j'ai trouvé pour ennuyer les admins en question...
Mais c'est vrai un spamassasin c'est très dur a configurer...
(pour info sous mandriva un coup d'urpmi et c'est torché, au pire ajouter deux lignes pour scanner a la vollée)
Pour info faite une petite recherche sur rapsys@free.fr, c'est un mail qui est partout sur internet (une tite recherche sur google et vous verrez), et bien j'ai 0 faux positif (a part les mails du parti-pirate, mais ça sera réglé prochainement) avec un spamassassin(score max 5)+bogofilter.
Entre 2spam passé au travers le mois dernier, pour une moyenne de 300-500spam/mois (j'ai beaucoup de mailing listes)
[^] # Re: Enfin les DSN
Posté par William Steve Applegate (site web personnel) . Évalué à 6.
pour les logiciels de spam les plus pourris, utilisez smtpd_helo_required = yes, strict_rfc821_envelopes = yes et smtpd_data_restrictions = […] reject_unauth_pipelining. Il n'y en a plus beaucoup mais c'est toujours ça de pris
Pour les spammeurs plus évolués mais toujours très bêtes, utilisez smtpd_sender_restrictions = […] reject_unknown_sender_domain. Oui, oui, il y en a encore qui n'ont pas compris qu'il vaut mieux forger une adresse dans un domaine existant. Et c'est une erreur 4xx, donc ça ne fait pas de dégâts lors des problèmes DNS
Pour les innombrables zombies qui traînent, utilisez smtpd_helo_restrictions = […] check_helo_access hash:/etc/postfix/access, reject_non_fqdn_hostname, reject_invalid_hostname. 99 % des machines sans FQDN sont des zombies sous Windows, les 1 % restants sont le résultat d'admins incompétents. Dans le fichier access qui va bien (j'en fais un pour chaque type de restrictions, mais c'est à vous de voir), vous passez à REJECT 127.0.0.1, localhost, la ou les IP, noms d'hôtes et domaines de la machine. Blam, c'est comme du Baygon jaune, les horribles spams tombent raides
Pour ceux qui ont réussi à passer, utilisez smtpd_recipient_restrictions = […] check_policy_service inet:127.0.0.1:60000 et installez Postgrey. Là, c'est le Baygon vert
Enfin, installez AMaViS, ClamAV, SpamAssassin, et utilisez les systèmes de filtrage de Postfix pour y faire passer ceux qui ont passé tout ça
Le résultat, sur les serveurs où j'ai mis en place ces méthodes, a été très positif, pas loin de 90 % de nos spams ont disparu. Ce n'est pas encore la panacée universelle, mais ça soulage !
Envoyé depuis mon PDP 11/70
[^] # Re: Enfin les DSN
Posté par Raphaël G. (site web personnel) . Évalué à 2.
(comme moi ?)
Grâce a vous chapeau messieurs dans quelques années les noms de domaines seront whitelistés, et il faudra payer (ou subir de la pub) pour pouvoir envoyer un mail a tous !!!
Moi ça commence vraiment a m'ennuyer sévère ces gens qui commence a se baser sur les noms de domaines et adresse de source...
Franchement spamassassin c'est fait pourquoi ?
(Ils blackliste les ip de mon FAI : neuf téléphone, ce qui m'empêche d'utiliser un postfix local, mon fai me fait chier avec son smtp a deux balle, sa pub, l'impossibilité d'utiliser mon ip @free et tout ce que j'ai c'est un dédié refilé en attente de désactivation :'(
Bref avec vos super règles de baygon et autre pensez au moins a laisser passer les abeilles butineuses, car ce que vous être en train de faire c'est de DÉCOURAGER L'UTILISATION DU MAIL qui est^WÉTAIT universelle et gratuite !!!
Certes le spam c'est casse pied, mais avec vos conneries vous êtes en train de tuer l'e-mail gratuit.
Oui, je pense très fort au mail garantis de chez yahoo et compagnie payant...
Mais que seront ces services ?
=> il y aura le même spam (rapport prix/avantage qui devra rester avantageux pour l'utilisateur lambda)
=> les utilisateurs payeront
=> vous pourrez pas virer le domaine (effets collatéraux trop important)
=> tout le monde sera perdant.
Bref c'est mon coup de gueule contre ces admins qui font des choix sans penser au conséquences, ni même réfléchir a utiliser une whiteliste
(pour qu'au moins ceux qui envoie des mails légitimes puissent prouver leur valeur et ne pas être bloqués)
Une petite recherche google me sort ça :
http://www.freesoftwaremagazine.com/articles/focus_spam_post(...)
"Some administrators also use the reject_unknown_hostname option to ignore servers whose hostnames can’t be resolved, but in my experience this causes TOO MANY FALSE positives from LEGITIMATE systems with transient DNS problems or other harmless issues.
You can test the effect of these rules, without activating them on a live system, by using the warn_if_reject option to cause Postfix to send debugging information to your maillog without actually processing them. For example, line 6 could be replaced with:
warn_if_reject,
reject_non_fqdn_hostname,
This way the results can be observed without the risk of inadvertently getting false positives."
Bref, des règles de filtrages trop stricte c'est comme le flash, ça semble très bien marcher, mais ça fait fait régresser tout le monde...
Pour info le filtre a spam de mandriva est a 7, je n'ai été bloqué qu'une fois (j'avais mis en fichier joint un fichier txt qui listait les noms de paquets affectés) et j'ai vu peu de spam dessus comme quoi on a pas besoin de pourrir la vie des gens...
[^] # Re: Enfin les DSN
Posté par imalip . Évalué à 4.
Et tu proposes comme lien d'explication une page qui donne comme conseil d'appliquer la regle (check_helo_access) a laquelle tu as répondu "Et tu vire plein de mail de gens qui utilisent un smtp dont le reverse ne pointe pas sur l'ip".
Nan, serieux, tu lis les posts auxquels tu réponds ?
[^] # Re: Enfin les DSN
Posté par Raphaël G. (site web personnel) . Évalué à 2.
(mais ce discours m'a rappelé de mauvais discours d'admins obtus...)
[^] # Re: Enfin les DSN
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Enfin les DSN
Posté par Raphaël G. (site web personnel) . Évalué à 2.
moonhub.be => 80.86.187.237
80.86.187.237 => serverxxx.xxx.xx
serverxxx.xxx.xx => not found: 3(NXDOMAIN)
(mon cas)
Et j'ai pas accès au dns de xxx.xx (enfin le vrai domaine, j'anonymise un peu là) donc je peux pas rendre mon dns valide...
ps : j'envoie mes mail avec mon adresse email rapsys DOT free AT fr depuis ce serveur et c'est bloqué par linuxfr...
pour le ehlo ben mon serveur utilise moonhub.be
# Problème
Posté par peck (site web personnel) . Évalué à 10.
Tout le monde sait que c'est le meilleur et l'utilise partout.
[^] # Re: Problème
Posté par Anonyme . Évalué à 4.
[^] # Re: Problème
Posté par _gryzor_ . Évalué à 8.
Tu vois qu'en fouillant un peu, on trouve toujours du troll ;)
[^] # Re: Problème
Posté par albert . Évalué à 2.
mais postfix reste mon préféré (le plus secure (à par Qmail, mais bon c'est pas tres libre)) et par rapport à exim il tient bien mieux la charge ;-)
cherchons sur google les tests des 3 MTA ;-)
[^] # Re: Problème
Posté par Colin Leroy (site web personnel) . Évalué à 6.
Par contre il me semble que Sendmail a pas mal à envier à Postfix au niveau de la configuration et de l'historique de la sécurité...
[^] # Re: Problème
Posté par thom_ra . Évalué à 5.
Non, réponds pas, je suis déjà dehors ;-)
[^] # Re: Problème
Posté par iznogoud . Évalué à 1.
Maintenant, le vrai challenge est de trouver le nom de la variable qu'on veut utiliser, mais quand on en arrive a ce genre de point la, je dirais que ton sendmail commence a sentir bon le serveur configure aux petits oignons.
Un sendmail, pour ce que j'en ai vu, c'est vachement plus configurable qu'un postfix (mais pour ca, faut pas avoir peur du camboui et de m4).
Sinon, pour le support de MILTER, je dirais : bien, mais dommage, MILTER etant tres souvent utilise pour la modification du message justement, qu'une bonne partie de l'interet du support de l'API tombe.
Bravo a l'equipe postfix :)
[^] # Re: Problème
Posté par Prosper . Évalué à 5.
C'est de moins en moins vrai , et c'est carrement plus d 'actualité chez tout bon FAI qui se respecte . A vrai dire , les seuls qui utilisent encore sendmail sont les vieux unixiens qui connaissent que ca.
[^] # Re: Problème
Posté par Erwan Le Gall (site web personnel) . Évalué à 2.
Je pense que les utilisations de sendmail sont plus historique qu'autre chose non ?
Pour les nouvelles installations ce doit être sans doute des personnes qui maîtrisent fortement l'outil.
[^] # Re: Problème
Posté par iznogoud . Évalué à 4.
Tout a fait, sendmail est le premier serveur digne de ce nom. Et il est encore dans le peloton de tete de ce qui se fait de mieux en terme de securite/performances/stabilite (soit dit en passant, la securite de sendmail a ete il fut un temps un probleme, mais ca a ete corrige en fait assez rapidement).
Et pour les nouvelles installations, je connais au moins une personne qui n'installera jamais que du sendmail, c'est le responsable du serveur mail de l'Universite de Zaragoza. Il en a une maitrise assez impressionnante (il patche sa configuration directement dans les fichiers resultant du m4, le tout sans doc, et sans se tromper. C'est tres bluffant a voir).
[^] # Re: Problème
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Parce que, lorsque le chef demande une modif', c'est plus sympa d'éditer nonchalamment un fichier quelques minutes plutôt que de se mettre à compulser frénétiquement le Bat Book dans l'espoir de trouver l'option cryptique qu'on cherchait. Je dirais que les Sendmail vont se raréfier au fur et à mesure que les dinos barbus les ayant installés partent et sont remplacés par de nouveaux admins plus au fait d'autres MTA.
Envoyé depuis mon PDP 11/70
[^] # Re: Problème
Posté par Yves Agostini (site web personnel) . Évalué à 3.
d'après sécurity space :
http://www.securityspace.com/s_survey/data/man.200606/mxsurv(...)
34 % pour sendmail
20 % pour exchange
16 % pour exim
12 % pour postfix
# orthographe
Posté par Gohar . Évalué à 1.
[^] # Re: orthographe
Posté par Achille Fouilleul (site web personnel) . Évalué à 3.
Cf. http://fr.wiktionary.org/wiki/%C3%A0_cor_et_%C3%A0_cri
[^] # Re: orthographe
Posté par Gohar . Évalué à 2.
# VERP vs DSN
Posté par Victor . Évalué à 4.
http://cr.yp.to/proto/verp.txt
Postfix supporte VERP aussi :
http://postfix.traduc.org/index.php/VERP_README.html
JE ne m'y connais pas assez pour les comparer (VERP vs DSN, pas Qmail vs Postfix :), quelqu'un a-t-il un avis sur la question ?
[^] # Re: VERP vs DSN
Posté par tuiu pol . Évalué à -3.
Le seul argument qu'on peut vraiment opposer à Qmail c'est qu'il n'est pas libre (ok argument de poid)
[^] # Re: VERP vs DSN
Posté par Aurélien Bompard (site web personnel) . Évalué à 6.
Que pour faire un truc à la con, genre vérifier que l'utilisateur existe pendant la transaction SMTP (pour éviter de se faire blacklister par spamcop), tu as au moins une dizaine de patches différents, sur lequels 5 sont des améliorations successives d'un même patch, 3 ne sont plus maintenues, et 1 est buggé à mort et 1 correspond à un cas ultra particulier avec des valeurs hardcodées partout ?
Non, c'est clair que le choix est vite fait.
(et paf, les deux pieds dedans)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.