Sortie de Postfix 2.3

Posté par  . Modéré par Amaury.
Étiquettes :
0
12
juil.
2006
Internet
La nouvelle version 2.3 de Postfix est sortie en version stable, après 9 Releases Candidates et quelques mois de retard.

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
  • ...
L'annonce complète de l'auteur de Postfix Wietse Venema avec toutes les nouveautés :

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

  • # Enfin les DSN

    Posté par  . Évalué à 3.

    Super les DSN ! Si cette techno finit par être implémentée par tous, les gens qui ont pour habitude de faire semblant de ne pas avoir reçu *le* mail super important n'auront plus d'excuses !
    Pour exim 4 y'a un patch, sendmail est ok, postfix aussi : ca devient bon !
    • [^] # Re: Enfin les DSN

      Posté par  . Évalué à 7.

      ça va être pratique pour les spammers pour savoir si les adresses qu'ils emploient correspondent ou non à des personnes ?
      • [^] # Re: Enfin les DSN

        Posté par  (site web personnel) . Évalué à 6.

        DSN dit juste que le mail a bien été traité par le serveur e-mail.
        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  . Évalué à 6.

          Cool : Déjà que ça me faisait bien rigoler de recevoir les mails d'un fier anti-virus m'expliquant qu'il avait intercepté les virus envoyés par un quelconque boulet vérolé usurpant accidentellement mon adresse, maintenant, j'en recevrai trois !
          • [^] # Re: Enfin les DSN

            Posté par  (site web personnel) . Évalué à 6.

            C'est du à l'architecture de postfix.
            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  . Évalué à 5.

            la directive

            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  (site web personnel) . Évalué à 3.

              Et tu vire plein de mail de gens qui utilisent un smtp dont le reverse ne pointe pas sur l'ip...
              (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  . Évalué à 2.

                Bip, mauvaise réponse

                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  (site web personnel) . Évalué à 3.

                Faux, c'est pas la même chose dont il parle :)
                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  (site web personnel) . Évalué à 2.

                  Sauf que tes règles je peux rien y faire...
                  (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  (site web personnel) . Évalué à 6.

              Pour ma part, les expériences que j'ai connu indiquent que la très grande majorité des spams peuvent être bloqués avec les étapes suivantes :

              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  (site web personnel) . Évalué à 2.

                Et avec tes règles tu a pensé au type légitime qui ne veux/peux pas passer par le smtp de son FAI pourrave
                (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  . Évalué à 4.

                  Alors la, je dois dire, tres, tres fort. Tu reussis a lui reprocher d'utiliser une regle de filtrage qu'il ne mentionne pas. Cherche bien, il n'y a aucune mention dans son post de la commande reject_unknown_hostname. Ni meme de reject_unknown_client qui semble etre celle qui te pose réellement probleme.

                  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  (site web personnel) . Évalué à 2.

                    Navré dans ce cas, je présente toutes mes excuses au(x) personne(s) concernée(s), je ne suis pas un expert de postfix...
                    (mais ce discours m'a rappelé de mauvais discours d'admins obtus...)
                    • [^] # Re: Enfin les DSN

                      Posté par  (site web personnel) . Évalué à 2.

                      Pour info j'ai activé les règles dont le monsieur au-dessus parle (reject_non_fqdn_hostname etc), et en effet ça bloque des mails venant de quoi ? De serveurs dont le helo ressemble à : "ehlo -1278473456". J'ose espérer qu'aucun vrai admin ne met ça comme nom de machine (en plus c'est même pas le /etc/hostname même si ça peut l'être, mais un paramètre de postfix).
                      • [^] # Re: Enfin les DSN

                        Posté par  (site web personnel) . Évalué à 2.

                        En tout cas ça bloque les serveurs de mail avec la configuration suivante :
                        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  (site web personnel) . Évalué à 10.

    Le problème avec postfix c'est qu'il n'y a même pas de troll.
    Tout le monde sait que c'est le meilleur et l'utilise partout.
    • [^] # Re: Problème

      Posté par  . Évalué à 4.

      En même temps, Sendmail reste la solution la plus utilisée, et de très loin, et aussi la mieux éprouvée niveau stabilité.
      • [^] # Re: Problème

        Posté par  . Évalué à 8.

        Et en même temps, Exim est quand même bien meilleur, d'ailleurs il est par défaut dans la Debian, qui est la meilleure distribution.

        Tu vois qu'en fouillant un peu, on trouve toujours du troll ;)
        • [^] # Re: Problème

          Posté par  . Évalué à 2.

          l'utilisation de sendmail tient a son support de la charge, exim tient difficilement la charge et postfix en peu mieux, mai sendmail quand on veux traité de nombreux mails (+100000) par traitements

          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  (site web personnel) . Évalué à 6.

        Je ne crois pas que Postfix aie quoi que ce soit à envier à Sendmail au niveau stabilité. Postfix est incassable ;-)

        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  . Évalué à 5.

          Qu'est-ce que tu reproches à la configuration de Sendmail ?

          Non, réponds pas, je suis déjà dehors ;-)
          • [^] # Re: Problème

            Posté par  . Évalué à 1.

            Tant qu'on n'est pas a faire des trucs etranges, ce qui peut amener dans de rares cas a bidouiller les fichiers .m4, la configuration se fait en un seul fichier, a coups de var = val.

            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  . Évalué à 5.

        En même temps, Sendmail reste la solution la plus utilisée

        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  (site web personnel) . Évalué à 2.

          Je ne vois pas pourquoi changer un sendmail qui marche depuis 7 ans. Bien sûr la question de la sécurité se pose.
          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  . Évalué à 4.

            Je pense que les utilisations de sendmail sont plus historique qu'autre chose non ?

            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  (site web personnel) . Évalué à 3.

            > Je ne vois pas pourquoi changer un sendmail qui marche depuis 7 ans.
            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  (site web personnel) . Évalué à 3.

          une réponse avec des chiffres :
          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  . Évalué à 1.

    À cor et à cris
  • # VERP vs DSN

    Posté par  . Évalué à 4.

    Qmail (oui c'est pas libre, si vous voulez :) implemente VERP qui est un procedé different de DSN mais qui permet de remplir les memes fonctions (plus d'autres) selon son auteur :
    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  . Évalué à -3.

      Pas sur VERP vs DSN mais Qmail vs Postfix on a moyen de troller pdt un moment si tu veux :D
      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  (site web personnel) . Évalué à 6.

        Euh, et peut-être aussi que pour avoir la moindre fonctionnalité qui sort de l'ordinaire du mail sous Qmail, il faut appliquer une quinzaine de patches ?
        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.