Ma boîte se charge de transmissions de FSE (feuilles de soins
électroniques) cryptées entre des cabinets et des boîtes mails ouvertes
pour chaque praticien de façon à ce qu'ils puissent les traiter chez
eux sur leur matériel.
Ensuite le praticien les renvoie de la même manière. Un petit logiciel
propriétaire est installé à cet effet sur son PC et se charge de la
récupération et aussi de l'envoi.
Chacun de ces envois est en fait un simple mail crypté, et c'est un
process équivalent à la télétransmission aux caisses des FSE (qui suit
d'ailleurs ces échanges).
Un chirurgien, télé-transmettant directement lui-même de sa clinique
connaît en ce moment quelques déboires aléatoires: les FSE sont bien
envoyées mais n'arrivent pas aux caisses. Son soucis a mis en évidence
que:
/- les envois sont bien effectués par le serveur SMTP de son FAI
(Orange),
/- ils semblent ne pas arriver à destination sur les serveurs des
caisses.
Nous avons connu le même phénomène, non pas lors d'envois aux caisses
mais d'envois vers les praticiens alors que:
/- nous utilisons nos propres serveurs SMTP & DNS, implémentés sur
chacun de nos PC,
/- ces envois sont émis avec comme adresse émettrice une adresse
hébergée dans notre domaine vers des adresse hébergées de même dans
notre propre domaine (chez Infomaniak).
Nous avons planché là dessus pendant deux jours pleins avec les
développeurs (Pratilog) des logiciels réalisant ces opérations en
multipliant les tests en situation, dans nos bureaux évidemment dans un
premier temps (notre FAI Numericable-pro) puis dans les locaux de KPMG
(notre expert-comptable) qui nous a ouvert son espace de co-working et
son wifi une après-midi pleine et jusqu'à 22 heures de façon à tester
aussi son FAI (Orange)... Les techs d'Infomaniak étaient eux aussi de
la partie en guettant en temps réel l'arrivée sur leurs serveurs de nos
envois.
Il en ressort que:
/- les logs de nos serveurs SMTP montrent que les envois sont bien
expédiés,
/- les démons reçus démontrent clairement que les envois ont lieu mais
sont refusés avec comme argument "Spam mail rejected",
/- ils n'arrivent jamais à destination,
/- nous avons testé par des serveurs SMTP externes (Orange,
Numericable, Free, SFR, Gmail, Infomaniak) avec le même résultat.
/- toutefois le même logiciel utilisé pour un envoi de mail classique
(c'est une option pour l'envoi de petits mails avec ou sans PJ) permet
la distribution sans accroc du mail.
/- dans ces mêmes conditions des envois à partir d'Outlook, Eudora The
Bat! sont acheminés sans soucis.
Nous en avons tous déduit que la responsabilité de la dissolution du
mail dans le web incombait finalement au FAI.
Numericable contacté a évoqué la migration Numericable/SFR de ses
serveurs comme une éventuelle possibilité de ce dysfonctionnement et
avancé un retour à la normale sous une semaine (passée depuis hier).
Nous avons eu l'idée que le FAI lit les envois qui passent sur son
réseau et filtre selon les headers et nous avons cherché quels
pourraient être les headers discriminants entre ces envois obérés et
ceux qui passent.
Return-path est parfois nécessaire à la bonne distribution du mail mais
il est présent dans chaque envoi. Nous nous sommes aperçu que les
headers Mailer et X-mailer sont en cause. Leur absence provoque la
disparition du mail envoyé. Jamais vu ça auparavant et je peux faire
des envois avec PowerShell en pagaille, il n'y a que les headers To,
From, la date et l'ID et le Return-path et ça ne coince pas.
À ce point là trois questions subsistent:
1/- Pourquoi uniquement un type particulier de mail ? L'encodage
quoted-printable automatiquement produit par le logiciel lorsque la
commande d'envoi vers un destinataire est passée est peut-être à
revoir, toutefois avec les deux headers ça passe donc on y viendra plus
tard. Et question corollaire pourquoi ces deux headers bloquent
certains mails et pas d'autres ?
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à
lire les headers du flux et filtrer aussi drastiquement sans avertir ?
C'est cette question là qui me turlupine un peu... Beaucoup même...
--
... Michel
les petits renardeaux dans la clairière du CTV
Merci d avoir pris le temps de me répondre. Jean-Pierre Kuypers Wrote in message:
Les FAI ne sont pas concernés à ce niveau.Par contre les gestionnaires / administrateurs / responsables deserveurs SMTP, oui.Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen desavoir où les transmettre.
Vu que les mails en question sont émis par le serveur SMTP ('ESMTP') installé sur le PC en question je crains pourtant que ce soit bien le seul FAI qui soit en cause. Le logiciel produisant le mail à été du coup et durant les tests recompilé pour intégrer Mailer et X-mailer. Heureusement qu on travaille en étroite collaboration avec ce développeur et qu ils sont cool et réactifs. Ce comme ca qu on a pu valider les deux headers manquants fautifs.
Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question: Validé? Par qui ? RFC n? ?
Les courrielleurs bien tempérés prennent soin de les générer à l'envoi.Un message sans elles pourrait bien provenir d'un robot .../... Malheureusement il y a des faux positifs et je comprends que cela soitpénalisants.
Toutafé d accord. Nous utilisons The Bat ! essentiellement et Outlook accessoirement voire Eudora parfois (j ai toujours eu un faible pour Édora mais sa gestion UTF8 pose trop de tracas) sans soucis de ce type. Nous n avons pas la main sur le logiciel de Pratilog mais ils ont réagi de suite ét deux concert avec nous et les autres.
trois questions subsistent: On ne voit pas la question 3/- ...
Eh eh. Je m a gourré. J'sais plus compter. Seule perdure la vraie question: Qui a autorité pour définir les headers requis ? RFC numéro? M étant quand même refadé les RFC j ai pas trouvé de recommandation sur Mailer et X-mailer (juste sur Return-path qui est déjà inscrit par tous les logiciels), donc je m interroge sur cette nécessité. Par ailleurs je pense que ce sont bien les serveurs réseau du FAI qui surveillent le flux transféré et, dans ce cas, analysent simplement les headers. Est-ce légal ou faut il avertir la CNIL ;) -- Bisous à ta souris. ... Michel les petits renardeaux dans la clairière du CTV
Merci d avoir pris le temps de me répondre.
Jean-Pierre Kuypers <Kuypers@address.invalid> Wrote in message:
Les FAI ne sont pas concernés à ce niveau.Par contre les gestionnaires / administrateurs / responsables deserveurs SMTP, oui.Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen desavoir où les transmettre.
Vu que les mails en question sont émis par le serveur SMTP
('ESMTP') installé sur le PC en question je crains pourtant que
ce soit bien le seul FAI qui soit en cause.
Le logiciel produisant le mail à été du coup et durant les tests
recompilé pour intégrer Mailer et X-mailer. Heureusement qu on
travaille en étroite collaboration avec ce développeur et qu ils
sont cool et réactifs. Ce comme ca qu on a pu valider les deux
headers manquants fautifs.
Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question:
Validé? Par qui ? RFC n? ?
Les courrielleurs bien tempérés prennent soin de les générer à l'envoi.Un message sans elles pourrait bien provenir d'un robot .../... Malheureusement il y a des faux positifs et je comprends que cela soitpénalisants.
Toutafé d accord. Nous utilisons The Bat ! essentiellement et
Outlook accessoirement voire Eudora parfois (j ai toujours eu un
faible pour Édora mais sa gestion UTF8 pose trop de tracas) sans
soucis de ce type.
Nous n avons pas la main sur le logiciel de Pratilog mais ils ont
réagi de suite ét deux concert avec nous et les autres.
trois questions subsistent: On ne voit pas la question 3/- ...
Eh eh. Je m a gourré. J'sais plus compter.
Seule perdure la vraie question:
Qui a autorité pour définir les headers requis ? RFC numéro?
M étant quand même refadé les RFC j ai pas trouvé de
recommandation sur Mailer et X-mailer (juste sur Return-path qui
est déjà inscrit par tous les logiciels), donc je m interroge sur
cette nécessité.
Par ailleurs je pense que ce sont bien les serveurs réseau du FAI
qui surveillent le flux transféré et, dans ce cas, analysent
simplement les headers. Est-ce légal ou faut il avertir la CNIL
;)
--
Bisous à ta souris.
... Michel
les petits renardeaux dans la clairière du CTV
Merci d avoir pris le temps de me répondre. Jean-Pierre Kuypers Wrote in message:
Les FAI ne sont pas concernés à ce niveau.Par contre les gestionnaires / administrateurs / responsables deserveurs SMTP, oui.Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen desavoir où les transmettre.
Vu que les mails en question sont émis par le serveur SMTP ('ESMTP') installé sur le PC en question je crains pourtant que ce soit bien le seul FAI qui soit en cause. Le logiciel produisant le mail à été du coup et durant les tests recompilé pour intégrer Mailer et X-mailer. Heureusement qu on travaille en étroite collaboration avec ce développeur et qu ils sont cool et réactifs. Ce comme ca qu on a pu valider les deux headers manquants fautifs.
Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question: Validé? Par qui ? RFC n? ?
Les courrielleurs bien tempérés prennent soin de les générer à l'envoi.Un message sans elles pourrait bien provenir d'un robot .../... Malheureusement il y a des faux positifs et je comprends que cela soitpénalisants.
Toutafé d accord. Nous utilisons The Bat ! essentiellement et Outlook accessoirement voire Eudora parfois (j ai toujours eu un faible pour Édora mais sa gestion UTF8 pose trop de tracas) sans soucis de ce type. Nous n avons pas la main sur le logiciel de Pratilog mais ils ont réagi de suite ét deux concert avec nous et les autres.
trois questions subsistent: On ne voit pas la question 3/- ...
Eh eh. Je m a gourré. J'sais plus compter. Seule perdure la vraie question: Qui a autorité pour définir les headers requis ? RFC numéro? M étant quand même refadé les RFC j ai pas trouvé de recommandation sur Mailer et X-mailer (juste sur Return-path qui est déjà inscrit par tous les logiciels), donc je m interroge sur cette nécessité. Par ailleurs je pense que ce sont bien les serveurs réseau du FAI qui surveillent le flux transféré et, dans ce cas, analysent simplement les headers. Est-ce légal ou faut il avertir la CNIL ;) -- Bisous à ta souris. ... Michel les petits renardeaux dans la clairière du CTV
Jean-Pierre Kuypers
In article (Dans l'article) , les renardeaux wrote (écrivait) :
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à lire les headers du flux et filtrer aussi drastiquement sans avertir ?
Les FAI ne sont pas concernés à ce niveau. Par contre les gestionnaires / administrateurs / responsables de serveurs SMTP, oui. Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen de savoir où les transmettre. Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises. Les lignes Mailer et X-mailer en font partie. Les courrielleurs bien tempérés prennent soin de les générer à l'envoi. Un message sans elles pourrait bien provenir d'un robot et donc petre du pourriel. De plus, la lutte contre les inondations et autres propagations de messages malveillants et/ou non sollicités pousse à analyser plus avant le contenu même des messages afin de bloquer ceux qui pourraient sembler inappropriés. Malheureusement il y a des faux positifs et je comprends que cela soit pénalisants.
À ce point là trois questions subsistent: 1/- 2/-
On ne voit pas la question 3/- ... -- Jean-Pierre Kuypers Veuillez avertir les phrases dans leur con- texte avant de fonder sciemment.
In article (Dans l'article) <mn.c8087e3920193a72.121394@ctv.zone>, les
renardeaux <les.renardeaux@wanadur.grr.invalid> wrote (écrivait) :
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à
lire les headers du flux et filtrer aussi drastiquement sans avertir ?
Les FAI ne sont pas concernés à ce niveau.
Par contre les gestionnaires / administrateurs / responsables de
serveurs SMTP, oui.
Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen de
savoir où les transmettre.
Dans l'en-tête, certaines lignes sont maintenant considérées comme
nécessaires ou requises.
Les lignes Mailer et X-mailer en font partie.
Les courrielleurs bien tempérés prennent soin de les générer à l'envoi.
Un message sans elles pourrait bien provenir d'un robot et donc petre
du pourriel.
De plus, la lutte contre les inondations et autres propagations de
messages malveillants et/ou non sollicités pousse à analyser plus avant
le contenu même des messages afin de bloquer ceux qui pourraient
sembler inappropriés.
Malheureusement il y a des faux positifs et je comprends que cela soit
pénalisants.
À ce point là trois questions subsistent:
1/-
2/-
On ne voit pas la question 3/- ...
--
Jean-Pierre Kuypers
Veuillez avertir les phrases dans leur con-
texte avant de fonder sciemment.
In article (Dans l'article) , les renardeaux wrote (écrivait) :
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à lire les headers du flux et filtrer aussi drastiquement sans avertir ?
Les FAI ne sont pas concernés à ce niveau. Par contre les gestionnaires / administrateurs / responsables de serveurs SMTP, oui. Sans lire et interpréter l'en-tête des messages, il n'y a pas moyen de savoir où les transmettre. Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises. Les lignes Mailer et X-mailer en font partie. Les courrielleurs bien tempérés prennent soin de les générer à l'envoi. Un message sans elles pourrait bien provenir d'un robot et donc petre du pourriel. De plus, la lutte contre les inondations et autres propagations de messages malveillants et/ou non sollicités pousse à analyser plus avant le contenu même des messages afin de bloquer ceux qui pourraient sembler inappropriés. Malheureusement il y a des faux positifs et je comprends que cela soit pénalisants.
À ce point là trois questions subsistent: 1/- 2/-
On ne voit pas la question 3/- ... -- Jean-Pierre Kuypers Veuillez avertir les phrases dans leur con- texte avant de fonder sciemment.
Jean-Pierre Kuypers
In article (Dans l'article) <5d8b3710$0$14379$, renardeaux wrote (écrivait) :
Jean-Pierre Kuypers Wrote in message: Vu que les mails en question sont émis par le serveur SMTP ('ESMTP') installé sur le PC en question je crains pourtant que ce soit bien le seul FAI qui soit en cause.
Et le serveur SMTP d'origine, il ne s'adresse pas à un autre serveur SMTP ?... La fonction du FAI, c'est normalement de fournir un accès à Internet, couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son ressort.
Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question: Validé? Par qui ? RFC n? ?
Il semblerait que ces lignes ne soient justement pas standard <https://tools.ietf.org/html/rfc2076> Je laisse au gestionnaire / responsable du serveur SMTP, le choix de la validité de politique de sécurité, etc. -- Jean-Pierre Kuypers
In article (Dans l'article) <5d8b3710$0$14379$426a74cc@news.free.fr>,
renardeaux <les.renardeaux@ctv.zoll.invalid> wrote (écrivait) :
Jean-Pierre Kuypers <Kuypers@address.invalid> Wrote in message:
Vu que les mails en question sont émis par le serveur SMTP
('ESMTP') installé sur le PC en question je crains pourtant que
ce soit bien le seul FAI qui soit en cause.
Et le serveur SMTP d'origine, il ne s'adresse pas à un autre serveur
SMTP ?...
La fonction du FAI, c'est normalement de fournir un accès à Internet,
couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et
comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son
ressort.
> Dans l'en-tête, certaines lignes sont maintenant considérées comme
> nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question:
Validé? Par qui ? RFC n? ?
Il semblerait que ces lignes ne soient justement pas standard
<https://tools.ietf.org/html/rfc2076>
Je laisse au gestionnaire / responsable du serveur SMTP, le choix de la
validité de politique de sécurité, etc.
In article (Dans l'article) <5d8b3710$0$14379$, renardeaux wrote (écrivait) :
Jean-Pierre Kuypers Wrote in message: Vu que les mails en question sont émis par le serveur SMTP ('ESMTP') installé sur le PC en question je crains pourtant que ce soit bien le seul FAI qui soit en cause.
Et le serveur SMTP d'origine, il ne s'adresse pas à un autre serveur SMTP ?... La fonction du FAI, c'est normalement de fournir un accès à Internet, couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son ressort.
Dans l'en-tête, certaines lignes sont maintenant considérées comme nécessaires ou requises.Les lignes Mailer et X-mailer en font partie.
C est l essentiel de ma question: Validé? Par qui ? RFC n? ?
Il semblerait que ces lignes ne soient justement pas standard <https://tools.ietf.org/html/rfc2076> Je laisse au gestionnaire / responsable du serveur SMTP, le choix de la validité de politique de sécurité, etc. -- Jean-Pierre Kuypers
Marc SCHAEFER
Jean-Pierre Kuypers wrote:
La fonction du FAI, c'est normalement de fournir un accès à Internet, couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son ressort.
Dans l'idéal, oui. Il y a toutefois certains opérateurs qui bloquent le port 25, ou qui redirigent ou interceptent les sessions: Par exemple, Swisscom https://medium.com/cloudready-ch/swisscom-utilise-doffice-un-man-in-the-midle-pour-smtp-83ccecefe71e C'est affreux, et on n'y pense pas toujours quand on debuggue un problème.
La fonction du FAI, c'est normalement de fournir un accès à Internet,
couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et
comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son
ressort.
Dans l'idéal, oui. Il y a toutefois certains opérateurs qui bloquent
le port 25, ou qui redirigent ou interceptent les sessions:
Par exemple, Swisscom
https://medium.com/cloudready-ch/swisscom-utilise-doffice-un-man-in-the-midle-pour-smtp-83ccecefe71e
C'est affreux, et on n'y pense pas toujours quand on debuggue
un problème.
La fonction du FAI, c'est normalement de fournir un accès à Internet, couche 3 du modèle OSI del'ISO. Ensuite ce qu'on y transport et comment, TCP, UDP, et au-dessus, ce n'est normalement plus de son ressort.
Dans l'idéal, oui. Il y a toutefois certains opérateurs qui bloquent le port 25, ou qui redirigent ou interceptent les sessions: Par exemple, Swisscom https://medium.com/cloudready-ch/swisscom-utilise-doffice-un-man-in-the-midle-pour-smtp-83ccecefe71e C'est affreux, et on n'y pense pas toujours quand on debuggue un problème.
Eric Demeester
Bonsoir, J'ai lu les échanges précédents. Administrant un serveur SMTP, j'ai eu l'occasion de faire un peu le tour des motifs de rejet de courriels par les serveurs de destination, je ne sais pas si j'ai tout compris de ta problématique ni ça pourra aider ici, mais au cas où... les renardeaux (Wed, 25 Sep 2019 00:08:19 +0200 - fr.comp.mail) :
Nous avons connu le même phénomène, non pas lors d'envois aux caisses mais d'envois vers les praticiens alors que: /- nous utilisons nos propres serveurs SMTP & DNS, implémentés sur chacun de nos PC,
Le premier problème qui me vienne à l'esprit est celui évoqué par Marc, à savoir le filtrage ou reroutage de ce qui sort du port 25 sur des IP considérées comme résidentielles (mêmes des IP fixes soit-disant professionnelles vendues à prix d'or par les FAI peuvent être coinsidérées comme résidentielles). Avoir un serveur SMTP sur une machine chez soi derrière une IP résidentielle est à mon sens une cause potentielle de contrariété, mieux vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un port autre que le 25 (souvent 587 mais c'est juste une convention). Le mien est chez Online, mais je suppose qu'Infomaniak peut héberger ça, puisque tu travailles avec eux.
/- ces envois sont émis avec comme adresse émettrice une adresse hébergée dans notre domaine vers des adresse hébergées de même dans notre propre domaine (chez Infomaniak).
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ? Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de courriers de Microsoft (outlook.com, etc.) rejettent les messages sans autre forme de procès ; avec, les messages passent mais finissent en indésirables.
/- les logs de nos serveurs SMTP montrent que les envois sont bien expédiés, /- les démons reçus démontrent clairement que les envois ont lieu mais sont refusés avec comme argument "Spam mail rejected",
Quels sont les serveurs refusant les envois ? Ceux du FAI, des serveurs intermédiaires ou ceux des destinataires finaux ?
/- nous avons testé par des serveurs SMTP externes (Orange, Numericable, Free, SFR, Gmail, Infomaniak) avec le même résultat.
Avec quel From: dans les messages expédiés ?
/- toutefois le même logiciel utilisé pour un envoi de mail classique (c'est une option pour l'envoi de petits mails avec ou sans PJ) permet la distribution sans accroc du mail. /- dans ces mêmes conditions des envois à partir d'Outlook, Eudora The Bat! sont acheminés sans soucis.
Il faut comparer les en-têtes émis par les différents logiciels pour des emails classiques et les emails cryptés, à mon avis c'est là qu'est l'os.
Nous en avons tous déduit que la responsabilité de la dissolution du mail dans le web incombait finalement au FAI.
La seule influence possible du FAI dans l'histoire est le refus d'expédier le message parce qu'il sort d'une IP résidentielle sur le port 25, d'où l'intérêt de savoir quel est le serveur qui rejette le message.
Numericable contacté a évoqué la migration Numericable/SFR de ses serveurs comme une éventuelle possibilité de ce dysfonctionnement et avancé un retour à la normale sous une semaine (passée depuis hier).
Euh, Numéricâble en matière de compétences en la matière, comment dire...
1/- Pourquoi uniquement un type particulier de mail ?
Encore une fois, à serveur d'envoi identique, comparer les en-têtes des messages qui sont distribués et ceux qui sont rejetés.
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à lire les headers du flux et filtrer aussi drastiquement sans avertir ? C'est cette question là qui me turlupine un peu... Beaucoup même...
Le FAI fait ce qu'il veut pourvu que ce soit précisé dans ses CGU, mais à mon avis le problème est ailleurs. En résumé, ne pas envoyer les courriers depuis sa machine mais par l'intermédiaire d'un serveur SMTP correctement configuré (domaine, clé DKIM, champ SPF) devrait à mon sens résoudre le problème. En espérant avoir compris la question :)
Bonsoir,
J'ai lu les échanges précédents.
Administrant un serveur SMTP, j'ai eu l'occasion de faire un peu le tour
des motifs de rejet de courriels par les serveurs de destination, je ne
sais pas si j'ai tout compris de ta problématique ni ça pourra aider
ici, mais au cas où...
Nous avons connu le même phénomène, non pas lors d'envois aux caisses
mais d'envois vers les praticiens alors que:
/- nous utilisons nos propres serveurs SMTP & DNS, implémentés sur
chacun de nos PC,
Le premier problème qui me vienne à l'esprit est celui évoqué par Marc,
à savoir le filtrage ou reroutage de ce qui sort du port 25 sur des IP
considérées comme résidentielles (mêmes des IP fixes soit-disant
professionnelles vendues à prix d'or par les FAI peuvent être
coinsidérées comme résidentielles).
Avoir un serveur SMTP sur une machine chez soi derrière une IP
résidentielle est à mon sens une cause potentielle de contrariété, mieux
vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un port autre
que le 25 (souvent 587 mais c'est juste une convention). Le mien est
chez Online, mais je suppose qu'Infomaniak peut héberger ça, puisque tu
travailles avec eux.
/- ces envois sont émis avec comme adresse émettrice une adresse
hébergée dans notre domaine vers des adresse hébergées de même dans
notre propre domaine (chez Infomaniak).
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec
un domaine correspondant à une clé DKIM valide renseignée dans la zone
du domaine, la clé privée qui va bien dans le trousseau du serveur
d'envoi, ainsi que les enregistrements SPF dans la zone du domaine
attestant que l'adresse IP du serveurs d'envoi est bien habilitée à
envoyer des courriels avec un From: du nom de domaine en question ?
Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de
courriers de Microsoft (outlook.com, etc.) rejettent les messages sans
autre forme de procès ; avec, les messages passent mais finissent en
indésirables.
/- les logs de nos serveurs SMTP montrent que les envois sont bien
expédiés,
/- les démons reçus démontrent clairement que les envois ont lieu mais
sont refusés avec comme argument "Spam mail rejected",
Quels sont les serveurs refusant les envois ? Ceux du FAI, des serveurs
intermédiaires ou ceux des destinataires finaux ?
/- nous avons testé par des serveurs SMTP externes (Orange,
Numericable, Free, SFR, Gmail, Infomaniak) avec le même résultat.
Avec quel From: dans les messages expédiés ?
/- toutefois le même logiciel utilisé pour un envoi de mail classique
(c'est une option pour l'envoi de petits mails avec ou sans PJ) permet
la distribution sans accroc du mail.
/- dans ces mêmes conditions des envois à partir d'Outlook, Eudora The
Bat! sont acheminés sans soucis.
Il faut comparer les en-têtes émis par les différents logiciels pour des
emails classiques et les emails cryptés, à mon avis c'est là qu'est
l'os.
Nous en avons tous déduit que la responsabilité de la dissolution du
mail dans le web incombait finalement au FAI.
La seule influence possible du FAI dans l'histoire est le refus
d'expédier le message parce qu'il sort d'une IP résidentielle sur le
port 25, d'où l'intérêt de savoir quel est le serveur qui rejette le
message.
Numericable contacté a évoqué la migration Numericable/SFR de ses
serveurs comme une éventuelle possibilité de ce dysfonctionnement et
avancé un retour à la normale sous une semaine (passée depuis hier).
Euh, Numéricâble en matière de compétences en la matière, comment
dire...
1/- Pourquoi uniquement un type particulier de mail ?
Encore une fois, à serveur d'envoi identique, comparer les en-têtes des
messages qui sont distribués et ceux qui sont rejetés.
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à
lire les headers du flux et filtrer aussi drastiquement sans avertir ?
C'est cette question là qui me turlupine un peu... Beaucoup même...
Le FAI fait ce qu'il veut pourvu que ce soit précisé dans ses CGU, mais
à mon avis le problème est ailleurs.
En résumé, ne pas envoyer les courriers depuis sa machine mais par
l'intermédiaire d'un serveur SMTP correctement configuré (domaine, clé
DKIM, champ SPF) devrait à mon sens résoudre le problème.
Bonsoir, J'ai lu les échanges précédents. Administrant un serveur SMTP, j'ai eu l'occasion de faire un peu le tour des motifs de rejet de courriels par les serveurs de destination, je ne sais pas si j'ai tout compris de ta problématique ni ça pourra aider ici, mais au cas où... les renardeaux (Wed, 25 Sep 2019 00:08:19 +0200 - fr.comp.mail) :
Nous avons connu le même phénomène, non pas lors d'envois aux caisses mais d'envois vers les praticiens alors que: /- nous utilisons nos propres serveurs SMTP & DNS, implémentés sur chacun de nos PC,
Le premier problème qui me vienne à l'esprit est celui évoqué par Marc, à savoir le filtrage ou reroutage de ce qui sort du port 25 sur des IP considérées comme résidentielles (mêmes des IP fixes soit-disant professionnelles vendues à prix d'or par les FAI peuvent être coinsidérées comme résidentielles). Avoir un serveur SMTP sur une machine chez soi derrière une IP résidentielle est à mon sens une cause potentielle de contrariété, mieux vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un port autre que le 25 (souvent 587 mais c'est juste une convention). Le mien est chez Online, mais je suppose qu'Infomaniak peut héberger ça, puisque tu travailles avec eux.
/- ces envois sont émis avec comme adresse émettrice une adresse hébergée dans notre domaine vers des adresse hébergées de même dans notre propre domaine (chez Infomaniak).
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ? Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de courriers de Microsoft (outlook.com, etc.) rejettent les messages sans autre forme de procès ; avec, les messages passent mais finissent en indésirables.
/- les logs de nos serveurs SMTP montrent que les envois sont bien expédiés, /- les démons reçus démontrent clairement que les envois ont lieu mais sont refusés avec comme argument "Spam mail rejected",
Quels sont les serveurs refusant les envois ? Ceux du FAI, des serveurs intermédiaires ou ceux des destinataires finaux ?
/- nous avons testé par des serveurs SMTP externes (Orange, Numericable, Free, SFR, Gmail, Infomaniak) avec le même résultat.
Avec quel From: dans les messages expédiés ?
/- toutefois le même logiciel utilisé pour un envoi de mail classique (c'est une option pour l'envoi de petits mails avec ou sans PJ) permet la distribution sans accroc du mail. /- dans ces mêmes conditions des envois à partir d'Outlook, Eudora The Bat! sont acheminés sans soucis.
Il faut comparer les en-têtes émis par les différents logiciels pour des emails classiques et les emails cryptés, à mon avis c'est là qu'est l'os.
Nous en avons tous déduit que la responsabilité de la dissolution du mail dans le web incombait finalement au FAI.
La seule influence possible du FAI dans l'histoire est le refus d'expédier le message parce qu'il sort d'une IP résidentielle sur le port 25, d'où l'intérêt de savoir quel est le serveur qui rejette le message.
Numericable contacté a évoqué la migration Numericable/SFR de ses serveurs comme une éventuelle possibilité de ce dysfonctionnement et avancé un retour à la normale sous une semaine (passée depuis hier).
Euh, Numéricâble en matière de compétences en la matière, comment dire...
1/- Pourquoi uniquement un type particulier de mail ?
Encore une fois, à serveur d'envoi identique, comparer les en-têtes des messages qui sont distribués et ceux qui sont rejetés.
2/- Les FAI sont-ils fondés (est-ce de leurs prérogatives légales) à lire les headers du flux et filtrer aussi drastiquement sans avertir ? C'est cette question là qui me turlupine un peu... Beaucoup même...
Le FAI fait ce qu'il veut pourvu que ce soit précisé dans ses CGU, mais à mon avis le problème est ailleurs. En résumé, ne pas envoyer les courriers depuis sa machine mais par l'intermédiaire d'un serveur SMTP correctement configuré (domaine, clé DKIM, champ SPF) devrait à mon sens résoudre le problème. En espérant avoir compris la question :)
les renardeaux
Bonjour, Le message du mercredi 25/09/2019 (cf. <250920191229030025% ), Jean-Pierre Kuypers dixit, stipule notammant :
Il semblerait que ces lignes ne soient justement pas standard <https://tools.ietf.org/html/rfc2076>
C'est bien ce que je disais. Mais ça passe avec néanmoins... -- ... Michel les petits renardeaux dans la clairière du CTV
Bonjour,
Le message du mercredi 25/09/2019 (cf.
<250920191229030025%Kuypers@address.invalid> ), Jean-Pierre Kuypers
dixit, stipule notammant :
Il semblerait que ces lignes ne soient justement pas standard
<https://tools.ietf.org/html/rfc2076>
C'est bien ce que je disais. Mais ça passe avec néanmoins...
--
... Michel
les petits renardeaux dans la clairière du CTV
Bonjour, Le message du mercredi 25/09/2019 (cf. <250920191229030025% ), Jean-Pierre Kuypers dixit, stipule notammant :
Il semblerait que ces lignes ne soient justement pas standard <https://tools.ietf.org/html/rfc2076>
C'est bien ce que je disais. Mais ça passe avec néanmoins... -- ... Michel les petits renardeaux dans la clairière du CTV
les renardeaux
Bonjour, Le message du mercredi 25/09/2019 (cf. <qmfn42$an9$ ), Marc SCHAEFER dixit, stipule notammant :
https://medium.com/cloudready-ch/swisscom-utilise-doffice-un-man-in-the-midle-pour-smtp-83ccecefe71e C'est affreux, et on n'y pense pas toujours quand on debuggue un problème.
Je suis allé voir. Ça promet... -- ... Michel les petits renardeaux dans la clairière du CTV
Bonjour,
Le message du mercredi 25/09/2019 (cf.
<qmfn42$an9$1@shakotay.alphanet.ch> ), Marc SCHAEFER dixit, stipule
notammant :
Bonjour, Le message du mercredi 25/09/2019 (cf. <qmfn42$an9$ ), Marc SCHAEFER dixit, stipule notammant :
https://medium.com/cloudready-ch/swisscom-utilise-doffice-un-man-in-the-midle-pour-smtp-83ccecefe71e C'est affreux, et on n'y pense pas toujours quand on debuggue un problème.
Je suis allé voir. Ça promet... -- ... Michel les petits renardeaux dans la clairière du CTV
les renardeaux
Bonjour, Le message du mercredi 25/09/2019 (cf. ), Eric Demeester dixit, stipule notammant :
Bonsoir,
Bonsoir Eric,
Le premier problème qui me vienne à l'esprit est celui évoqué par Marc, à savoir le filtrage ou reroutage de ce qui sort du port 25 sur des IP considérées comme résidentielles (mêmes des IP fixes soit-disant professionnelles vendues à prix d'or par les FAI peuvent être coinsidérées comme résidentielles).
Numericale ne vendait pas à prix d'or mais cache bien ses IP fixes derrière des proxy, alors c'est pas mieux. Mais leur abonnement pro ne bloque *jamais* le port 25.
Avoir un serveur SMTP sur une machine chez soi derrière une IP résidentielle est à mon sens une cause potentielle de contrariété, mieux vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un port autre que le 25 (souvent 587 mais c'est juste une convention). Le mien est chez Online, mais je suppose qu'Infomaniak peut héberger ça, puisque tu travailles avec eux.
On a adopté ça parce qu'à une époque c'était vraiment galère. Pas mal de mails se perdaient en route. Du coup on a implémenté ce ptit soft et le trafic n'a plus jamais connu d'errance, jusqu'alors...
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ?
Yes, Sir! Infomaniak fournit le SPF évidemment et un DKIM également. Sauf que si je sors par le port 587 vers le SMTP d'Infomaniak je n'aurais pas le DKIM. Pour ça si je ne m'abuse il faudrait que j'utilise leur webmail. Or mon logiciel est bien sûr autonome. Mon serveur local ne permet pas l'implantation de la clé DKIM. Faudrait peut-être que je regarde du côté de hMailServer qui permet la gestion des clés DKIM si je me souviens bien.
Avec quel From: dans les messages expédiés ?
Une adresse de notre domaine chez Infomaniak.
Il faut comparer les en-têtes émis par les différents logiciels pour des emails classiques et les emails cryptés, à mon avis c'est là qu'est l'os.
C'est ce qu'on a fait pour finir d'arriver à la conclusion que seuls Mailer et X-mailer étaient discriminant dans la distribution.
Euh, Numéricâble en matière de compétences en la matière, comment dire...
Toutafé !
En résumé, ne pas envoyer les courriers depuis sa machine mais par l'intermédiaire d'un serveur SMTP correctement configuré (domaine, clé DKIM, champ SPF) devrait à mon sens résoudre le problème.
Comme je le disais le DKIM d'Infomaniak est activé uniquement depuis leur webmail. Leur serveur SMTP ne la passe pas. Donc trouver un serveur SMTP local et lui fournir leur clé ? -- ... Michel les petits renardeaux dans la clairière du CTV
Bonjour,
Le message du mercredi 25/09/2019 (cf.
<1g6noedafg4q22jk7hfh3ktko5gj2s645e@4ax.com> ), Eric Demeester dixit,
stipule notammant :
Bonsoir,
Bonsoir Eric,
Le premier problème qui me vienne à l'esprit est celui évoqué par
Marc, à savoir le filtrage ou reroutage de ce qui sort du port 25 sur
des IP considérées comme résidentielles (mêmes des IP fixes
soit-disant professionnelles vendues à prix d'or par les FAI peuvent
être coinsidérées comme résidentielles).
Numericale ne vendait pas à prix d'or mais cache bien ses IP fixes
derrière des proxy, alors c'est pas mieux. Mais leur abonnement pro ne
bloque *jamais* le port 25.
Avoir un serveur SMTP sur une machine chez soi derrière une IP
résidentielle est à mon sens une cause potentielle de contrariété,
mieux vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un
port autre que le 25 (souvent 587 mais c'est juste une convention).
Le mien est chez Online, mais je suppose qu'Infomaniak peut héberger
ça, puisque tu travailles avec eux.
On a adopté ça parce qu'à une époque c'était vraiment galère. Pas mal
de mails se perdaient en route.
Du coup on a implémenté ce ptit soft et le trafic n'a plus jamais connu
d'errance, jusqu'alors...
J'imagine que dans les en-têtes des courriers émis, il y a un From:
avec un domaine correspondant à une clé DKIM valide renseignée dans
la zone du domaine, la clé privée qui va bien dans le trousseau du
serveur d'envoi, ainsi que les enregistrements SPF dans la zone du
domaine attestant que l'adresse IP du serveurs d'envoi est bien
habilitée à envoyer des courriels avec un From: du nom de domaine en
question ?
Yes, Sir! Infomaniak fournit le SPF évidemment et un DKIM également.
Sauf que si je sors par le port 587 vers le SMTP d'Infomaniak je
n'aurais pas le DKIM. Pour ça si je ne m'abuse il faudrait que
j'utilise leur webmail. Or mon logiciel est bien sûr autonome.
Mon serveur local ne permet pas l'implantation de la clé DKIM. Faudrait
peut-être que je regarde du côté de hMailServer qui permet la gestion
des clés DKIM si je me souviens bien.
Avec quel From: dans les messages expédiés ?
Une adresse de notre domaine chez Infomaniak.
Il faut comparer les en-têtes émis par les différents logiciels pour
des emails classiques et les emails cryptés, à mon avis c'est là
qu'est l'os.
C'est ce qu'on a fait pour finir d'arriver à la conclusion que seuls
Mailer et X-mailer étaient discriminant dans la distribution.
Euh, Numéricâble en matière de compétences en la matière, comment
dire...
Toutafé !
En résumé, ne pas envoyer les courriers depuis sa machine mais par
l'intermédiaire d'un serveur SMTP correctement configuré (domaine,
clé DKIM, champ SPF) devrait à mon sens résoudre le problème.
Comme je le disais le DKIM d'Infomaniak est activé uniquement depuis
leur webmail. Leur serveur SMTP ne la passe pas.
Donc trouver un serveur SMTP local et lui fournir leur clé ?
--
... Michel
les petits renardeaux dans la clairière du CTV
Bonjour, Le message du mercredi 25/09/2019 (cf. ), Eric Demeester dixit, stipule notammant :
Bonsoir,
Bonsoir Eric,
Le premier problème qui me vienne à l'esprit est celui évoqué par Marc, à savoir le filtrage ou reroutage de ce qui sort du port 25 sur des IP considérées comme résidentielles (mêmes des IP fixes soit-disant professionnelles vendues à prix d'or par les FAI peuvent être coinsidérées comme résidentielles).
Numericale ne vendait pas à prix d'or mais cache bien ses IP fixes derrière des proxy, alors c'est pas mieux. Mais leur abonnement pro ne bloque *jamais* le port 25.
Avoir un serveur SMTP sur une machine chez soi derrière une IP résidentielle est à mon sens une cause potentielle de contrariété, mieux vaut proposer un SMTP hébergé accessible en SMTP/AUTH sur un port autre que le 25 (souvent 587 mais c'est juste une convention). Le mien est chez Online, mais je suppose qu'Infomaniak peut héberger ça, puisque tu travailles avec eux.
On a adopté ça parce qu'à une époque c'était vraiment galère. Pas mal de mails se perdaient en route. Du coup on a implémenté ce ptit soft et le trafic n'a plus jamais connu d'errance, jusqu'alors...
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ?
Yes, Sir! Infomaniak fournit le SPF évidemment et un DKIM également. Sauf que si je sors par le port 587 vers le SMTP d'Infomaniak je n'aurais pas le DKIM. Pour ça si je ne m'abuse il faudrait que j'utilise leur webmail. Or mon logiciel est bien sûr autonome. Mon serveur local ne permet pas l'implantation de la clé DKIM. Faudrait peut-être que je regarde du côté de hMailServer qui permet la gestion des clés DKIM si je me souviens bien.
Avec quel From: dans les messages expédiés ?
Une adresse de notre domaine chez Infomaniak.
Il faut comparer les en-têtes émis par les différents logiciels pour des emails classiques et les emails cryptés, à mon avis c'est là qu'est l'os.
C'est ce qu'on a fait pour finir d'arriver à la conclusion que seuls Mailer et X-mailer étaient discriminant dans la distribution.
Euh, Numéricâble en matière de compétences en la matière, comment dire...
Toutafé !
En résumé, ne pas envoyer les courriers depuis sa machine mais par l'intermédiaire d'un serveur SMTP correctement configuré (domaine, clé DKIM, champ SPF) devrait à mon sens résoudre le problème.
Comme je le disais le DKIM d'Infomaniak est activé uniquement depuis leur webmail. Leur serveur SMTP ne la passe pas. Donc trouver un serveur SMTP local et lui fournir leur clé ? -- ... Michel les petits renardeaux dans la clairière du CTV
JKB
Le Wed, 25 Sep 2019 19:33:48 +0200, Eric Demeester écrivait :
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ? Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de courriers de Microsoft (outlook.com, etc.) rejettent les messages sans autre forme de procès ; avec, les messages passent mais finissent en indésirables.
Je ne vois pas pourquoi. Si les champs SPF sont valides, tu ne te fais pas jeter par les serveurs de Microsoft et ça n'apparaît pas dans les indésirables (sauf si ton serveur est blacklisté quelque part). JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Wed, 25 Sep 2019 19:33:48 +0200,
Eric Demeester <neuneu@potiron.invalid> écrivait :
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec
un domaine correspondant à une clé DKIM valide renseignée dans la zone
du domaine, la clé privée qui va bien dans le trousseau du serveur
d'envoi, ainsi que les enregistrements SPF dans la zone du domaine
attestant que l'adresse IP du serveurs d'envoi est bien habilitée à
envoyer des courriels avec un From: du nom de domaine en question ?
Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de
courriers de Microsoft (outlook.com, etc.) rejettent les messages sans
autre forme de procès ; avec, les messages passent mais finissent en
indésirables.
Je ne vois pas pourquoi. Si les champs SPF sont valides, tu ne te
fais pas jeter par les serveurs de Microsoft et ça n'apparaît pas
dans les indésirables (sauf si ton serveur est blacklisté quelque
part).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Wed, 25 Sep 2019 19:33:48 +0200, Eric Demeester écrivait :
J'imagine que dans les en-têtes des courriers émis, il y a un From: avec un domaine correspondant à une clé DKIM valide renseignée dans la zone du domaine, la clé privée qui va bien dans le trousseau du serveur d'envoi, ainsi que les enregistrements SPF dans la zone du domaine attestant que l'adresse IP du serveurs d'envoi est bien habilitée à envoyer des courriels avec un From: du nom de domaine en question ? Parce que sans tout ça, pour ne prendre qu'un exemple, les serveurs de courriers de Microsoft (outlook.com, etc.) rejettent les messages sans autre forme de procès ; avec, les messages passent mais finissent en indésirables.
Je ne vois pas pourquoi. Si les champs SPF sont valides, tu ne te fais pas jeter par les serveurs de Microsoft et ça n'apparaît pas dans les indésirables (sauf si ton serveur est blacklisté quelque part). JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
les renardeaux
Bonjour, Le message du samedi 28/09/2019 (cf. <qmnif2$9b8$ ), Marc SCHAEFER dixit, stipule notammant :
les renardeaux wrote:
DKIM et DMARC ne sont un gage d'authenticité qu'auprès de d'acteurs de bonne foi eux-mêmes probes.
Tout à fait, c'est pour ça que je privilégie la signature de bout en bout avec GPG. Mais ce n'est pas faisable pour tout le monde, en particulier avec les attaques récentes DoS sur les serveurs de clé.
Moi itou. Sauf que là il s'agit de mails déjà cryptés (algorythme 'sécu'), ce qui ne change rien. J'ai essayé des envois de diverses sortes de mails, y compris GPG et en essayant avec les deux logiciels (que j'ai sous la main (gpg4usb et GPA/Kleopatra). Quel que soit le mail ça bloque sur ce point des headers. Bon, on a recompilé l'exe pour qu'il expédie avec les bons headers et tout passe, mais ça me met en rogne ce comportement unilatéral. Internet ne peut pas être un lieu où des acteurs (FAI, FSI, etc) peuvent s'arroger un droit de police. -- ... Michel les petits renardeaux dans la clairière du CTV
Bonjour,
Le message du samedi 28/09/2019 (cf.
<qmnif2$9b8$1@shakotay.alphanet.ch> ), Marc SCHAEFER dixit, stipule
notammant :
les renardeaux <les.renardeaux@wanadur.grr.invalid> wrote:
DKIM et DMARC ne sont un gage d'authenticité qu'auprès de d'acteurs
de bonne foi eux-mêmes probes.
Tout à fait, c'est pour ça que je privilégie la signature de bout en
bout avec GPG. Mais ce n'est pas faisable pour tout le monde, en
particulier avec les attaques récentes DoS sur les serveurs de clé.
Moi itou.
Sauf que là il s'agit de mails déjà cryptés (algorythme 'sécu'), ce qui
ne change rien.
J'ai essayé des envois de diverses sortes de mails, y compris GPG et
en essayant avec les deux logiciels (que j'ai sous la main (gpg4usb et
GPA/Kleopatra).
Quel que soit le mail ça bloque sur ce point des headers.
Bon, on a recompilé l'exe pour qu'il expédie avec les bons headers et
tout passe, mais ça me met en rogne ce comportement unilatéral.
Internet ne peut pas être un lieu où des acteurs (FAI, FSI, etc)
peuvent s'arroger un droit de police.
--
... Michel
les petits renardeaux dans la clairière du CTV
Bonjour, Le message du samedi 28/09/2019 (cf. <qmnif2$9b8$ ), Marc SCHAEFER dixit, stipule notammant :
les renardeaux wrote:
DKIM et DMARC ne sont un gage d'authenticité qu'auprès de d'acteurs de bonne foi eux-mêmes probes.
Tout à fait, c'est pour ça que je privilégie la signature de bout en bout avec GPG. Mais ce n'est pas faisable pour tout le monde, en particulier avec les attaques récentes DoS sur les serveurs de clé.
Moi itou. Sauf que là il s'agit de mails déjà cryptés (algorythme 'sécu'), ce qui ne change rien. J'ai essayé des envois de diverses sortes de mails, y compris GPG et en essayant avec les deux logiciels (que j'ai sous la main (gpg4usb et GPA/Kleopatra). Quel que soit le mail ça bloque sur ce point des headers. Bon, on a recompilé l'exe pour qu'il expédie avec les bons headers et tout passe, mais ça me met en rogne ce comportement unilatéral. Internet ne peut pas être un lieu où des acteurs (FAI, FSI, etc) peuvent s'arroger un droit de police. -- ... Michel les petits renardeaux dans la clairière du CTV
