Problème persistant de délai d'attente SMTP avec Spacemail sur Discourse (VPS, Docker)

Soutien
1

Bonjour à l’équipe de support/communauté Discourse,

Je lutte depuis plusieurs jours pour résoudre un problème avec les e-mails sortants de mon instance Discourse. J’exécute Discourse dans un conteneur Docker sur un VPS Spaceship (Phoenix, US). Mon fournisseur de messagerie est Spacemail (SMTP).

Problème :

  • Discourse ne parvient pas à envoyer d’e-mails. Chaque tentative d’envoi d’un e-mail de test aboutit à une erreur de délai d’attente :

    • Net::ReadTimeout with #<TCPSocket:(closed)>

    • Ou : execution expired

  • Le problème persiste, que j’utilise mail.spacemail.com ou smtp.spacemail.com comme serveur SMTP.

Ce que j’ai essayé :

  • Vérifié tous les paramètres SMTP (adresse, port 465 pour SSL, e-mail complet comme nom d’utilisateur, mot de passe correct) avec le support de Spaceship/Spacemail.

  • Réinitialisé et ré-entré le mot de passe SMTP plusieurs fois.

  • Confirmé avec le support Spacemail qu’il n’y a aucune restriction ou blocage de leur côté.

  • Telnet depuis le VPS vers mail.spacemail.com sur le port 465 réussit (la connexion s’ouvre, aucun problème de pare-feu).

  • Modifié la MTU du réseau Docker à 1400 comme suggéré sur les forums Discourse et redémarré Docker et le conteneur Discourse.

  • Essayé à la fois destroy/start et un rebuild complet de l’application Discourse.

  • Vérifié que Redis, PostgreSQL et tous les autres services fonctionnent correctement dans le conteneur.

  • Vérifié que tous les enregistrements DNS (MX, SPF, DKIM) sont configurés et propagés.

  • Testé depuis plusieurs navigateurs et appareils pour exclure les problèmes côté client.

  • Envoyé et reçu avec succès des e-mails en utilisant le même compte Spacemail dans Gmail (le SMTP fonctionne en dehors de Discourse).

Environnement :

  • Discourse exécuté dans Docker sur un VPS Ubuntu 22.04 (Spaceship, Phoenix, US)

  • Fournisseur SMTP : Spacemail

  • Paramètres SMTP : SSL, port 465, mail.spacemail.com (également essayé smtp.spacemail.com)

  • Tous les enregistrements DNS sont corrects et propagés

Journaux :

  • Aucune erreur dans les journaux Discourse, à l’exception du délai d’attente lors de l’envoi d’e-mails.

  • Redis et les autres services s’exécutent sans conflit.

  • Les timeouts des workers Unicorn coïncident avec les tentatives d’envoi d’e-mails.

Contexte supplémentaire : Aujourd’hui seulement, j’ai passé environ 7 heures à travailler avec le support Spacemail via chat en direct pour résoudre ce problème. Malgré leurs efforts et la confirmation que tout est correctement configuré de leur côté, le problème persiste.

Ce dont j’ai besoin :

  • Des conseils sur ce qu’il faut vérifier ou essayer d’autre ?

  • Existe-t-il un moyen d’obtenir des journaux de débogage SMTP plus détaillés de la part de Discourse ?

  • Quelqu’un a-t-il rencontré un problème similaire avec Spacemail ou un autre fournisseur ?

Merci beaucoup pour votre temps et votre soutien !

2

Pouvez-vous confirmer que vous avez suivi l’installation officielle ?

3

Oui, j’ai suivi le guide officiel d’installation de Discourse pour Docker. Si vous le souhaitez, je peux fournir des détails sur ma configuration ou sur les ajustements que j’ai dû apporter à mon environnement VPS.

4

Détails du journal d’erreurs :

Lorsque j’essaie d’envoyer des e-mails depuis Discourse, je reçois systématiquement une erreur de délai d’attente dans les journaux des tâches :

Job exception: Net::ReadTimeout
net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
net-protocol-0.2.2/lib/net/protocol.rb:209:in `readline'
net-smtp-0.5.1/lib/net/smtp.rb:1017:in `recv_response'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `block in do_start'
net-smtp-0.5.1/lib/net/smtp.rb:1027:in `critical'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `do_start'
net-smtp-0.5.1/lib/net/smtp.rb:642:in `start'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:318:in `block (2 levels) in perform'
... (trace complète disponible sur demande)

Description : Cette erreur se produit chaque fois que Discourse tente d’envoyer un e-mail. Le Net::ReadTimeout indique que Discourse attend une réponse du serveur SMTP (Spacemail), mais ne la reçoit pas à temps. Tous les tests réseau et TLS (openssl, telnet) réussissent, et le SMTP fonctionne dans des clients externes, donc le problème semble être spécifique à la communication ou à l’authentification SMTP de Discourse.

Si vous avez besoin de la trace complète ou de plus de détails, je peux les fournir.

5

Je ne connais pas du tout ce vps. Si vous êtes tout au début de votre configuration, vous pouvez essayer de recommencer avec un nouveau serveur plutôt que de continuer à vous acharner. Essayez peut-être un autre fournisseur si cela ne fonctionne toujours pas.

6

J’ai essayé :

  1. Zap-Hosting
  2. Ultra-Host
  3. Et maintenant spaceship, où j’ai tous les enregistrements DNS, le domaine, la boîte aux lettres.
7

Avez-vous essayé Troubleshoot email on a new Discourse install ?
Désolé que cela ait été une telle lutte pour vous. Ça ne devrait pas être si difficile !

8

Oui, je l’ai fait… Puis j’ai créé le compte administrateur via une commande SSH. Après cela, j’ai vu l’erreur : « Job exception: Net::ReadTimeout »

9

Résumé des étapes de dépannage effectuées :

  • Installation de Discourse sur un VPS Spaceship (Phoenix, US) en utilisant le guide d’installation Docker officiel.

  • Création du compte administrateur via la commande SSH.

  • Configuration du SMTP avec Spacemail (mail.spacemail.com, port 465, SSL, email complet comme nom d’utilisateur, mot de passe correct).

  • Réinitialisation et re-saisie du mot de passe SMTP plusieurs fois.

  • Essai de mail.spacemail.com et smtp.spacemail.com comme serveurs SMTP.

  • Vérification auprès du support Spacemail qu’il n’y a aucune restriction ou blocage de leur côté.

  • Confirmation que tous les enregistrements DNS (MX, SPF, DKIM) sont corrects et propagés.

  • Envoi et réception réussis d’e-mails en utilisant le même compte Spacemail dans Gmail (le SMTP fonctionne en dehors de Discourse).

  • Test de la connexion SMTP depuis le VPS en utilisant telnet et openssl (poignée de main TLS et bannière SMTP reçues avec succès).

  • Modification du MTU du réseau Docker à 1400 et redémarrage de Docker et du conteneur Discourse.

  • Vérification que Redis, PostgreSQL et tous les autres services fonctionnent correctement dans le conteneur.

  • Essai de destroy/start et de rebuild complet de l’application Discourse après chaque modification.

  • Vérification des journaux : uniquement des erreurs Net::ReadTimeout lors de l’envoi d’e-mails, aucune autre erreur.

  • Assurage que “Enable SMTP” est activé dans l’interface d’administration de Discourse.

  • Plusieurs jours et environ 7 heures passées en chat en direct avec le support Spaceship/Spacemail pour dépanner ce problème.

Malgré toutes ces étapes, Discourse ne parvient toujours pas à envoyer d’e-mails et renvoie systématiquement une erreur Net::ReadTimeout.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet ``mail.spacemail.com`` 465Tentative de connexion à 198.177.121.32…Connecté à ``mail.spacemail.com``.Caractère d’échappement : ‘^\]’.

(app.yml) ENV :
env:LC_ALL: en_US.UTF-8LANG: en_US.UTF-8LANGUAGE: en_US.UTF-8

DISCOURSE_DEFAULT_LOCALE: en

UNICORN_WORKERS: 4

DISCOURSE_HOSTNAME: citygaming.icu

DISCOURSE_DEVELOPER_EMAILS: ‘info@citygaming.icu’

DISCOURSE_SMTP_ADDRESS: mail.spacemail.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: info@citygaming.icu
DISCOURSE_SMTP_PASSWORD: “” –> J'utilise des caractères spéciaux
DISCOURSE_SMTP_ENABLE_START_TLS: false
DISCOURSE_SMTP_SSL: true
DISCOURSE_SMTP_DOMAIN: citygaming.icu
DISCOURSE_NOTIFICATION_EMAIL: forum@citygaming.icu

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# openssl s_client -connect mail.spacemail.com:465
CONNECTED(00000003)
depth=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN = *.spacemail.com
verify return:1
---
Certificate chain
 0 s:CN = *.spacemail.com
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Jun 11 00:00:00 2025 GMT; NotAfter: Jun 27 23:59:59 2026 GMT
 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
 2 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
 3 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Feb  1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGhzCCBO+gAwIBAgIRALFmOQOqKiGafcbqHk5JTvcwDQYJKoZIhvcNAQEMBQAw
YDELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBQdWJsaWMgU2VydmVyIEF1dGhlbnRpY2F0aW9uIENBIERWIFIz
NjAeFw0yNTA2MTEwMDAwMDBaFw0yNjA2MjcyMzU5NTlaMBoxGDAWBgNVBAMMDyou
c3BhY2VtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKh
nnzi9sR4SQlEzDG0OSThJ7rj+zNyhq9KTYZtLLxSPtcI6ggnjOa0AbahjA5UXxjkT
RTWZfStyGucwK/eTL8pjU8aXl64vUFZK/jF0xiKcWFZ0J15+iqrP5zcv+yoHA9LE
OwelNDUE+c2/EDEhLbIqaIeKKxsS5aQ0JiTENfux/JbzcoI7vUsqJUsFiLCk7ane
+wc0viVE5YPTqc96VVhiuJu2IHwVSK6IsUXndbDXRQbkbwxORiX15pY83u3+uiiB
b/ZRfRILOZ29uYPsx3GH7Vqm4yJ7Iev4ueZ6z6Vd+lznH9iv8TZIWkWfxJ0oCDLm
ZMRe+DojBpAk/00+UtcCAwEAAaOCAwAwggL8MB8GA1UdIwQYMBaAFGjAEhYYDq/O
9oemMlejRlFdywcnMB0GA1UdDgQWBBS0oqCQUczn3dZIyiDOM+8KV4WqfTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURWUjM2LmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKQYDVR0RBCIwIIIPKi5zcGFjZW1h
aWwuY29tgg1zcGFjZW1haWwuY29tMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgA
dvCWl2S/VViXrfdDh2g3CEJ36fA61fak8zZuRqQ/D8qpxgAAAZdghNBMAAAEAwBH
MEUCIFwL6ylPjJme/WFO/xYNOoHIa6Qsod+6aZhCwPI1LODMAiEA+ljJB2bm4c2f
iD3IyuNzzR5cwDrgofUQZJftzXwq7W0AdgAZhtTHKKpv/roDb3gqTQGRqs4tcjEP
rs5dcEEtJUzH1AAAAZdghM+2AAAEAwBHMEUCIQCwY+9LQ8itV7FcOB5tcj9JsbL/
8oVh8ksyJP9uDfevjQIgGN/Nix3skQI2nJm6hOZDptJzt2ZkBv22ebwoFHmoGPgA
dgAOV5S8866pPjMbLJkHs/eQ35vCPXEyJd0hqSWsYcVOIQAAAZdghM9yAAAEAwBH
MEUCIDIR5KyuY2IHnP8pnEUCIKAGNFcSvEjY0Z3NIExZTL9rAiEAoMphPacQ7X1D
KACpJ06ijnzmZ2siXehW9oVOJCsd5K8wDQYJKoZIhvcNAQEMBQADggGBACbbMQWM
wFCA6UdMsFyK/5oU9O5YT7Bpo0MvhOADjGZNe37DsEMfjc4asr0Sx8VaXoPJUlV5
HKoPr13lkpG6HI6TXfFzr/uUbn6aUjMoEqjuAKTWh5leggMwXqxw7fRA8NKEpI/d
VcRiZW/I3JXvYiE2PmJawcum7pU8RuuEFyOq/9i47WkLtPyCvuMk8wkzHbxOU4ie
MYFvTvlbYoaZm9x95xAtkch3xF5MBPK9TLdgawNYrdJ4uXVYBebvx2ZSX7qr/AY8
T6AEdRtiuANfCqC0vXShDqG3hE+yeonza1ntUCKzVHvQVZTlXa12GNaxbczrw3Hd
D0tk6Xkx8K7YTq3dXoYzKYt+Lg2OFTpV13m26O9FYI5cwqI0CasiBdCvd/DpHBv/
iaPWNxLa2iyR/TSQyLkvWZmqStwrgg+dykA/nsD1fUq7X0qCmqxL2iUE9+ZZ3Mi3
JtgSj9qKdUYBSpfCX3h+8bPG5j4pretcVh7Ve81jCu1n2NwY0b9stGWx2A==
-----END CERTIFICATE-----
subject=CN = *.spacemail.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 7057 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
New Session Ticket arrived after handshake:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 8FACA20AB7071487B74738E7FA28813C1CA106651D80EB46D271486C67E4432B
    Session-ID-ctx:
    Resumption PSK: F99B4B27314220CB53DEE7B1D852B2AE360D39472E1F020806FAC5D40A72F206636EA0B50545C9F1875BCACB5FD35F07
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 23 bd a5 51 88 3e 2e 7f-eb 8d 81 00 95 7a a7 8b   #..Q.>.......z..
    0010 - ce 97 c1 5e 12 02 2a 46-de d9 96 d7 06 f0 b1 47   ...^..*F.......G
    0020 - 1d 79 69 7f 8e 9d f4 4a-6a cb ec 00 42 70 d6 6b   .yi....Jj...Bp.k
    0030 - a1 37 1b 9d 61 47 4a e1-16 13 bc bb e7 ee f8 de   .7..aGJ.........
    0040 - 26 fb c1 00 b0 15 76 f0-80 a3 14 8b 10 f2 c7 ab   &.....v.........
    0050 - 5c 54 cb b3 16 e2 d2 ab-36 97 c9 82 14 1d 45 d4   \T......6.....E.
    0060 - d7 4d c0 fc 9e 77 e3 44-c8 87 16 13 3a 1f c2 02   .M...w.D....:...
    0070 - 65 03 51 14 bf ab d0 0e-51 e5 9e 95 07 ef 33 f5   e.Q.....Q.....3.
    0080 - 48 9c 89 8e d9 8e 1f ea-38 3a 21 2a c1 64 44 a8   H.......8:!*.dD.
    0090 - b2 9a 69 f2 ca fa 9e 57-12 14 36 32 fb 40 b1 06   ..i....W..62.@..
    00a0 - 9e a4 b8 21 19 90 65 f8-6d ce 2d 6f 53 e0 72 23   ...!..e.m.-oS.r#
    00b0 - 5b ca b8 f8 79 bd 07 9e-97 95 d4 d3 d5 f6 25 93   [...y.........%.
    00c0 - 33 02 71 1d 55 be 9c d3-14 32 bb 9b 4e 65 67 78   3.q.U....2..Negx

    Start Time: 1758479949
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
220 SpaceMail.com Mail Node
1 « J'aime »
10

Essayez les ports 587 ou 2525 (essayez d’abord le 587), est-ce que cela fonctionne ? 587 est le port mentionné dans le guide d’installation.

1 « J'aime »
11

Merci pour votre suggestion. Mon fournisseur de messagerie (Spacemail) ne prend officiellement en charge que le port 465 avec SSL pour le SMTP. Cependant, j’ai également testé le port 587 avec STARTTLS dans le cadre du dépannage (avec le support), mais le problème de délai d’attente persiste.

12

J’ai effectué une installation standard deux fois la semaine dernière avec deux fournisseurs d’e-mail différents, et je sais que cela fonctionne. Je soupçonne que spacemail ne convient pas aux e-mails transactionnels réels.

Bien que je n’aie aucune idée si cela fonctionne

4 « J'aime »
13

Rien n’est bloqué du côté de Spaceship ou Spacemail. J’ai passé sept heures à en discuter avec leur support hier, et ils ont confirmé que tous les ports nécessaires sont ouverts et que le SMTP fonctionne de leur côté. Ils m’ont envoyé ici pour d’autres dépannages. De plus, le port 2525 n’est pas pris en charge par Spacemail, je ne peux donc pas l’utiliser comme alternative.

14

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# sudo ufw status
Statut : actif

To Action From

---

443/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22022/tcp ALLOW Anywhere
465/tcp ALLOW Anywhere
443/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
22022/tcp (v6) ALLOW Anywhere (v6)
465/tcp (v6) ALLOW Anywhere (v6)

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse#

1 « J'aime »
15

Je ne suis pas sûr que cela aide puisque vous avez déjà vérifié l’accès au port via telnet, mais vous pourriez essayer d’envoyer un e-mail avec Swaks (il devrait y avoir un paquet Ubuntu disponible pour cela). Je le trouve assez utile pour déboguer les problèmes de messagerie.

16

Peut-être essayer un service d’e-mails transactionnels comme Brevo ou Mailgun ? Si cela fonctionne, vous voudrez peut-être l’utiliser à la place. D’après ce que je peux voir, comme l’a dit Lilly, je ne vois aucune indication qu’il s’agisse d’un service d’e-mails transactionnels.

Je viens de demander à leur support et ils ont dit :

Bien que Spacemail ne prenne pas directement en charge les e-mails transactionnels, vous pouvez utiliser le protocole SMTP pour connecter votre boîte aux lettres Spacemail à votre formulaire de contact ou à tout outil qui envoie automatiquement des e-mails.

1 « J'aime »
17

Le problème se situe du côté du vaisseau spatial. Parce que j’ai essayé GOOGLE SMTP, et cela fonctionne et j’ai reçu un e-mail de test.
Aujourd’hui, j’ai transmis cela aux techniciens du vaisseau spatial via le support du vaisseau spatial. Je vous informerai si des détails sont nécessaires directement de votre part.

2 « J'aime »
18

C’est (à mon avis) une approche mal informée de leur part en raison du désordre absolu autour du port 465.

Le port 465 (SMTPS) est TRÈS souvent bloqué dans les environnements VPS comme mesure anti-spam car c’est le port historique utilisé pour la communication TLS MTA-MTA. De nos jours, il a été réattribué à SUBMISSIONS (SUBMISSION + TLS implicite), mais je ne prévois pas que les fournisseurs VPS le débloquent un jour en raison du fait qu’il y aura toujours des MTA écoutant le trafic MTA-MTA sur ce port.

Le port 587 (SUBMISSION) est explicitement le port de soumission de courrier MUA-MTA et c’est ce qui devrait être utilisé pour la soumission de courrier authentifiée en combinaison avec STARTTLS.

Même ainsi, le port 587 est toujours parfois bloqué par des fournisseurs VPS mal informés.

Nonobstant mon coup de gueule à ce sujet, je vois que vous pouvez vous connecter à ce port, alors que se passe-t-il si vous envoyez manuellement un e-mail depuis le VPS et depuis le conteneur via le port 465 ?

2 « J'aime »
19

@errorexee avez-vous pu résoudre votre problème ?

1 « J'aime »
20

Ce sujet a été automatiquement fermé 14 jours après la dernière réponse. Les nouvelles réponses ne sont plus autorisées.