jdh a écrit:(Ce qui est intéressant c'est qu'il y a des arguments !)
Je parle quand même rarement sans arguments
Mais ça m'arrive ! (et j'aime ça)
jdh a écrit:Bien sur, je reçois, comme tous, des mails "multi-destinataires". Cela devrait faire quelques triplets supplémentaires, non ? Néanmoins, on peut aussi considérer qu'il y a un nombre maxi de destinataires par message (pour postfix, ce doit être le paramètre default_destination_recipient_limit ?).
Je ne parle pas d'une multiple présence dans les destinataires. Je parle vraiment d'une gestion de ré-émission effectuée par certain bots: evidemment, ce n'est pas une gestion intelligente. Simplement une ré-émission périodique.
jdh a écrit:Quel est le problème ? Ces triplets ne sont pas destinés à être stockés pendants un temps très long : le temps est réglable : on conseille 15 minutes, je crois. La taille de cette base doit être adaptée au nombre de mails reçus multiplié par un nombre maxi de destinataires (raisonnablement 10 ou 15). La non utilisation d'alias collecteur devrait aussi limiter la liste de destinataires à la liste réelle. Cela revient aux éternels problèmes de "garbage collecteur".
Avant de répondre à cette phrase, j'aimerais que tu détaille sur quel point précédent tu te bases pour rédiger cette réponse. Ca me permettra de ne pas répondre n'importe quoi, n'importe comment.
jdh a écrit:Bien évidemment, tu pousses le raisonnement à l'extrême (et non "relativement répandu"). Je ne gère pas des dizaines (centaines, milliers) de milliers de boites (avec le tuyau qui va avec). Ce n'est pas le sujet de ce forum. Les méthodes et outils de FAI leur sont propres (et nous échappent).
Relis bien: je parle d'un cas concret (postfix / posgrey), et par la suite, le service _devient_ critique. Le nombre de boites gérées n'est pas un facteur déterminant dans la prise en compte du côté critique du service. Le domaine d'activité de la structure, le marché, et plusieurs autres paramètres que je me garderai bien de lister exhaustivement font qu'un service SMTP *peut* devenir critique. Même pour 10 comptes.
Alors forcément, le rapport entre 10 et 10000 boites est extrêmement important. Reste qu'entre monter une archi de pinpin qui répond à un besoin d'un instant 'T ' (MTA/MDA/MSA sur la même machine) ou une archi qui s'adaptera dans le temps (MTA/MDA/MSA distribués) sans la remettre en cause dans son intégralité à chaque évolution, le rapport est identique (10 / 10000).
jdh a écrit:La rfc 821 est bien vieille (1982 ! et remplacée par la RFC 2821 en 2001) mais elle mentionne néanmoins quand même les codes 4xx :
4yz Transient Negative Completion reply
The command was not accepted and the requested action did not occur. However, the error condition is temporary and the action may be requested again. [...] the sender-SMTP is encouraged to try again
A un mois près (octobre 2008): RFC 5321.
Evidemment que la rfc 821 prévoyait ce genre. Aussi, je peux t'assurer que les daemons de cette époque n'implémentaient absolument pas cette gestion, l' "encouragement", n'étant que optionnel (je te certifie qu'il existe encore sur le Net des daemons de ce type). Par ailleurs, dans les dernières mise à jour, l' "encouragement" est remplacé par
Each reply in this category might have a different time value, but the SMTP client SHOULD try again. Ce qui est une large différence.
jdh a écrit:Concernant
Mon infra envoie un mail vers la tienne qui fait un greylisting dessus. C'est moi qui supporte le coût de ta politique antispam. Merci
ton infra respecte la rfc : elle doit donc gérer la file d'attente ! Faut-il préférer gérer une retransmission à un blacklistage sans procès ?
Bien sûr qu'elle gère les files d'attentes. Mais pour de vraies indisponibilités. Pas pour un semblant d'indisponibilité qui ne sert qu'à vérifier si je respecte ton message 4xy et que je ne suis pas un spammer. Le fait que tu fasses semblant de ne pas être dispo me fait _supporter_ le coût de ta lutte antispam, que je respecte ou pas les RFCs.
Qui plus est, mon infra respectant la RFC, si je la passe en relais ouvert, ou que je fais de l'emailing de masse avec, ton greylisting ne te servira rien, je te submergerai de manière importante.
jdh a écrit:Il est bien connu qu'il n'y a aucune garantie en temps d'arrivée avec smtp. (Dans les petites structures, j'ai du mal à faire comprendre que l'on ne peut fetcher les mails à moins de 5', d'ailleurs avec Windows SBS qui intègre un "fetchmail", au contraire d'Exchange, est réglé à 15').
Je ne reviendrai pas là-dessus, surtout dans la manière de penser de notre pays: "oui les autres" et ses variantes. Depuis bien longtemps, je propose aux utilisateurs et décideurs d'appeler leur correspondant pour qu'ils vérifient que leur mail est bien arrivé. Une infinitésimale part de ces personnes note le caractère absurde de cette solution.
jdh a écrit:Je regrette cependant que beaucoup croient aux RBL et refuse le greylisting ... alors qu'il n'a pas du tout les inconvénients des RBL !
Et moi je regrette que les RBLs soient refusées en bloc en y opposant le greylisting (sans aucune attaque à ton encontre).
jdh a écrit:(Le 15 au coq a gagné : Postfix est-il meilleur que qmail ??)
Oui beaucoup de ballons échappés cependant.
Si la question est sérieuse, je ne peux que te conseiller de travailler un temps avec Postfix ou Exim et un temps avec qmail. Tu auras ton propre avis sur la question. Le mien, je pense que maintenant tu le connais