Re: Mails @free envoyés depuis un serveur non reçus
Daniel Huhardeaux a écrit :
> Le 14/10/2019 à 15:18, BERTRAND Joël a écrit :
>> Daniel Huhardeaux a écrit :
>>> Il doit forcément y avoir des logs, que le message soit accepté ou
>>> refusé. Quel logiciel serveur d'envois ?
>>
>> Pas forcément. Le message peut être traité par un mécanisme après
>> l'acceptation (typiquement un milter) qui le supprime silencieusement.
>> Seuls les logs du MX seraient pertinents.
>>
>
> Le serveur réceptionnaire acquiterait la réception du message et
> l'effacerai ensuite sans en informer l'émetteur ? Connais tu de
> semblables cas et pourrais les exposer ? Je n'ai jamais rencontré cela ...
En fait, il y a des milters qui travaillent sur l'enveloppe et d'autres
sur les données. Si je prend mon sendmail des familles (je suis
allergique à Postfix et encore plus à exim pour des serveurs sérieux,
quant à qmail, j'aime mieux ne pas en parler...), il est configuré pour
bouncer en cas de rejet sur l'enveloppe, mais pas en cas d'un traitement
ayant lieu sur le contenu.
Typiquement, sur l'enveloppe, je teste SPF, DKIM, rDNS, adresse IP de
l'expéditeur. Si ça tourne mal, je bounce et le SMTP sait que le message
est rejeté. Mais j'ai aussi des traitements sur les données. Ces
traitements se font _après_ l'envoi un DSN OK au smtp et je ne bounce
plus. Si le message est foireux (virus, pishing ou autres trucs du même
acabit), je jette sans autre forme de procès et le SMTP n'a aucun moyen
de savoir que le message n'est pas arrivé à bon port. C'est pour cela
que la "notification" (et non l'accusé de réception) est important. Il
garanti que le message est arrivé dans la boîte aux lettres du destinataire.
Certains serveurs de FAI sont gérés par des pieds tendres (les domaines
dépendants de SFR, entre autres) et il y a souvent des choses bizarres
(mails qui n'arrivent jamais ou qui sont rejetés pour d'obscures
raisons). Il fut un temps où il n'y avait qu'une seule adresse IPv4 de
MX pour tous les domaines gérés par SFR. Je suppose qu'il y avait
plusieurs machines physiques avec du round robin, mais ce n'était pas au
point. Gmail est aussi merdico-foireux mais dans un autre style. Ils
veulent (enfin voulaient parce qu'ils ont corrigé récemment) des champs
SPFv1. Sauf qu'ils ont configuré IPv6 comme protocole prioritaire et
qu'ils n'arrivaient pas à traiter les champs SPFv1 en IPv6 (!). Les
en-têtes DKIM de gmail sont aussi foireuses (10% des mails en gros, au
début, je pensais que le SMTP n'était pas le bon, même pas !...).
Résultat, les mails passaient aléatoirement. Certains n'arrivaient
jamais sans bounce (j'avais un temps désactivé IPv6 pour gmail pour
éviter le problème). Hotmail est aussi par moment capricieux parce qu'il
utilise une vieille version de SSL qui n'était plus capable de parler
avec les versions Debian. Ça ne bounçait pas, on avait seulement au bout
de cinq jours une notification du rejet.
> Ceci dit, on ne sait pas si les messages envoyés par le serveur de l'OP
> sont effectivement acquités/refusés par le destinataire, donc les logs
> de l'échange doivent exister sur le serveur de l'émetteur.
Ce qui est important, c'est côté MX (plus que SMTP) parce que les
rejets sont gérés côté MX.
Reply to: