Quelles étapes de diagnostic puis-je faire si mes e-mails sont envoyés, mais ne sont pas reçus, même pas comme spam?

J'ai un problème où tous les e-mails envoyés à certains destinataires sont envoyés mais n'arrivent jamais, pas même en tant que spam, sans erreurs, tandis que les e-mails envoyés à tout le monde fonctionnent correctement. Je suis perplexe et je cherche des moyens de diagnostiquer ce qui se passe.

• J'ai envoyé des courriels à un client la semaine dernière, à partir d'Outlook 2016. J'ai maintenant constaté qu'ils n'avaient jamais été reçus. J'ai essayé d'envoyer des e-mails à d'autres sur leur domaine et il semble qu'aucun d'eux ne reçoive mes e-mails, mais d'autres sur d'autres domaines ne le font pas.
• J'ai vérifié mon dossier «envoyé» et ils semblent identiques à tous les autres messages envoyés. Je n'ai eu aucun rapport de livraison ou quelque chose de similaire, et ils sont dans le dossier "envoyé" et non dans "boîte d'envoi". J'ai également essayé CCing moi-même dans mes derniers courriels à ces personnes - ils envoient certainement.
• J'ai vérifié auprès du client en question, et il n'a jamais rien reçu de moi, pas même dans un dossier spam . Je peux recevoir des e-mails de leur part, mais ils ne reçoivent rien de moi - pas même mes réponses à leurs e-mails.
• Le premier e-mail contenait deux petites pièces jointes PDF (500 Ko), mais le même sort est arrivé aux e-mails de suivi qui n'avaient pas de pièces jointes. Pas d'images ou de liens dans les e-mails. Il s'agissait d'e-mails normaux liés au travail adressés à une à trois personnes avec lesquelles j'ai eu des échanges d'e-mails dans le passé via la même adresse e-mail et Outlook. Ils sont aussi dans le même pays que moi.
• Il n'y a eu aucune réponse d'erreur de livraison ou quelque chose de similaire. Le premier e-mail de ce type a été envoyé à 8 h 55 vendredi dernier, il y a donc plus de 5 jours, et rien n'a été reçu de mon côté ou du leur.
• Leurs courriels m'arrivent bien - et en fait, mes premiers courriels qui ont échoué étaient des réponses à leurs propres courriels. J'ai également reçu des e-mails vers ce domaine normalement il y a à peine deux semaines.

• J'ai essayé divers e-mails de test sur ce domaine et rien ne passe:

  • Les courriels innocents qui disent simplement "Ceci est un courriel de test" et similaires n'arrivent jamais
  • Les e-mails de Webmail et de mon application de messagerie Android n'arrivent pas de la même manière que les e-mails d'Outlook (et ne fournissent pas non plus de rapports de livraison - tout échoue silencieusement)
  • Les e-mails envoyés en utilisant la 3G de mon téléphone subissent le même sort que les e-mails envoyés en utilisant mon WiFi
  • J'ai également créé un nouveau compte de messagerie sur le même domaine (par exemple test@my-domain.compour accompagner mon habitude my-name@my-domain.com), et il avait exactement le même problème (testé à l'aide de webmail).
  • Pour tester si je pourrais avoir une sorte de paramètres SMTP foirés qui bloquent les réceptions de livraison de rebond, j'ai envoyé un e-mail à hg1ugtvr34vrgfrt2t@ashfrlwejbtlwerhtklhejtkghwerkbjhrw.com en pensant qu'il n'existe probablement pas. J'ai reçu un rebond parfaitement normal "Échec de la remise du courrier: retour du message à l'expéditeur" - je suis donc en mesure de recevoir des rebonds, je ne suis tout simplement pas envoyé depuis ce domaine pour une raison quelconque.
  • Les courriels qui leur sont envoyés, par exemple, depuis mon compte Gmail personnel, sont bien reçus (donc j'utilise ceci entre-temps jusqu'à ce que ce problème soit résolu)

L'e-mail provient de mon propre domaine - j'ai envoyé des e-mails à d'autres personnes à partir de la même adresse e-mail et du même Outlook et ils ont bien été reçus. Gmail les marque occasionnellement comme spam, ce que j'examine, mais les autres clients semblent n'avoir aucun problème.

A part ça, je ne vois rien de plus. Je suis sûr qu'il n'y a pas assez ici pour diagnostiquer mon problème, donc je ne demande pas de solution, mais pour les étapes de diagnostic que je peux prendre , par exemple:

• Y a-t-il quelque chose "sous le capot" que je peux regarder dans Outlook, comme l'envoi d'un rapport ou d'un journal?
• Existe-t-il des types de journaux liés au serveur ou au domaine qui devraient être pertinents? Mon domaine est attribué à un serveur SMTP sur un VPS Centos.
• Existe-t-il des types de liste noire ou d'intervention de sécurité que je devrais connaître et vérifier pour empêcher un e-mail d'atteindre un dossier spam?

J'ai vu cette question que les e-mails n'étaient pas reçus par certaines personnes , ce qui est similaire mais avec deux différences:

• Ils utilisent un système d'envoi de masse, j'utilise régulièrement Outlook, un e-mail à la fois.
• La réponse acceptée accuse la liste grise - cependant, mon premier e-mail manquant date de vendredi dernier (il y a cinq jours), et apparemment la liste grise retarde les e-mails entre 15 minutes et "quelques jours".

Comme l'a suggéré Tyson, j'ai essayé http://mxtoolbox.com/ mais malheureusement, il n'a donné aucun indice (du moins, aucun indice que je puisse voir). Au cas où j'aurais raté quelque chose, voici les résultats:

Vérification de la liste noire

Vérification de XX.XX.XX.XX par rapport à 95 listes noires connues ...

Listé 0 fois avec 1 timeouts

[beaucoup de tiques vertes puis à la fin de la liste:]

TIMEOUT IPrange RBL Project [response time:] 0

Ce n'est donc dans aucune liste noire connue. Je ne sais pas pourquoi la vérification IPrange RBL a échoué, mais j'ai vérifié manuellement sur http://iprange.net/rbl/lookup/ et je n'y suis pas non plus.

Vérification SMTP:

Le temps de connexion est donc un peu lent (je ne sais pas pourquoi, je vais y réfléchir), mais je ne vois pas pourquoi cela ferait parfois disparaître complètement les courriers envoyés.

http://intodns.com donne également des graduations vertes pour tous les contrôles MX de mon domaine.

J'ai essayé de parcourir les fichiers journaux sur le serveur (Centos / Linux):

• /var/log/maillog- ce sont tous vides. Je pense que ce sont des journaux sendmail, et je n'utilise pas actuellement sendmail, donc cela a du sens.
• /var/log/exim/reject.logest plein de tentatives de force brute rejetées dovecot. Je l'ai fail2banet je vais vérifier mes paramètres de pare-feu, etc. pour voir si je peux les arrêter même en essayant, mais je ne pense pas que cela soit lié
• /var/log/exim/main.log contient également de nombreuses tentatives de force brute rejetées, mais contient également des enregistrements de certains e-mails réellement envoyés:

Voici un e-mail à trois personnes sur le même domaine qui a échoué pour les trois personnes (j'ai modifié certaines des chaînes alphanumériques et remplacé les adresses IP par TXT.LIKE.TH.IS):

2016-02-12 08:55:41 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:55:49 1aU9Vw-0004vq-EG <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=1443429 id=000001d17563$920b5cf0$7b1622d0$@my-domain.com
2016-02-12 08:55:51 1aU9Vw-0004vq-EG => alice.domain@receives-nothing.org <alice.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> brian.domain@receives-nothing.org <bob.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> carol.domain@receives-nothing.org <carol.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG Completed

Voici un e-mail à une personne qui a réussi (a été reçu par le destinataire):

2016-02-12 08:58:20 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:58:23 1aU9YU-0004w0-IN <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=23133 id=003101d61537$874b04a0$59e01ed0$@my-domain.com
2016-02-12 08:58:26 1aU9YU-0004w0-IN => zak.receives@email-normally.org <zak.receives@email-normally.org> R=dnslookup T=remote_smtp H=cluster4.eu.messagelabs.com [UK.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:58:26 1aU9YU-0004w0-IN Completed

Je ne vois aucune différence significative entre les deux. Avant et après les deux, ce ne sont que des débris de force brute et d'autres courriels.

Je ne sais pas quelle est la signification de cluster5.us.messagelabs.comou cluster4.eu.messagelabs.comest, mais les adresses IP associées sont les deux adresses IP de MessageLabs.

Googling messagelabs.com a publié cet article de blog , qui semble pertinent et suggère que (par coïncidence) mes deux clients sont abonnés à MessageLabs, mais pour les différences importantes qui a) contrairement à l'auteur, je n'ai même pas de non-livraison réception et b) si MessageLabs bloquait mon e-mail, je ne vois pas pourquoi ils le bloqueraient pour un de leurs clients mais pas pour un autre.

Le dépannage des e-mails peut être divisé en problèmes "expéditeur" et "destinataire". Puisque vous pouvez envoyer à d'autres personnes, le côté Envoi fonctionne probablement bien. Vous devez rechercher le côté Destinataire pour localiser le problème.

La consultation des journaux est une bonne étape et peut vous dire où vos messages parviennent et où ils ne le sont pas. Le flux de messagerie normal se présente comme suit:

1. Vous envoyez de votre logiciel de messagerie vers votre serveur

2. Votre serveur envoie à son serveur

3. Leur serveur envoie à leur client de messagerie

Dans ce cas, vous pouvez voir dans les journaux que leur serveur semble être

cluster5.us.messagelabs.com

Messagelabs est un service de filtrage des e-mails qui appartient désormais à Symantec. Des services de filtrage des messages comme celui-ci sont utilisés pour supprimer tous les courriers indésirables et indésirables avant que les messages ne soient envoyés au logiciel client. Cela signifie que les messages bloqués par messagelabs n'apparaîtront pas dans les dossiers de spam ou de courrier indésirable du logiciel client. Ils disparaîtront simplement et le destinataire n'en verra jamais aucun signe. En de rares occasions, ils peuvent recevoir un message disant "qu'un message de quelqu'un@exemple.com a été bloqué. Contactez votre service informatique pour le débloquer".

Cela ressemble beaucoup à ce qui s'est produit ici. Techniquement, vous devriez obtenir une réponse de rebond de messagelabs comme le gars dans le lien que vous avez publié, mais ce n'est pas garanti. Ils peuvent simplement supprimer votre message en silence s'ils pensent qu'il s'agit de spam. Habituellement, messagelabs fournira une interface pour le service informatique de leur client où les messages bloqués peuvent être libérés. Vous pouvez demander à votre contact dans l'entreprise de vérifier auprès de son équipe informatique tout message bloqué depuis votre adresse e-mail. Vous pouvez au moins le faire si vous avez un autre moyen de les contacter!

Autres étapes de dépannage générales utiles: Si vous n'avez pas eu accès aux fichiers journaux, vous pouvez découvrir ce que le serveur devrait être pour n'importe quel domaine en recherchant les «enregistrements MX»

Par exemple ici: http://mxtoolbox.com/

L'enregistrement MX est ce qu'un serveur de messagerie recherche pour savoir où envoyer votre e-mail.

Vous pouvez ensuite établir une connexion manuelle au serveur répertorié dans l'enregistrement mx pour voir s'il accepte les e-mails et quels messages d'erreur vous pouvez recevoir. Utilisez un programme telnet comme Putty: http://www.putty.org/ et telnet au serveur de messagerie sur le port 25. Certaines des commandes dont vous aurez besoin sont répertoriées ici: http://www.yuki-onna.co. uk / email / smtp.html

Alors maintenant, vous pouvez vous connecter à leur serveur de messagerie et envoyer un e-mail en utilisant votre adresse e-mail comme adresse "De" et voir comment le serveur répond directement. Tout code d'erreur par e-mail renvoyé peut être recherché dans google ou ici: http://www.serversmtp.com/en/smtp-error

Une fois que vous avez vérifié que vous pouvez vous connecter au serveur, il peut vous indiquer pourquoi votre e-mail est rejeté comme spam ou pour une autre raison, mais la raison peut ne pas être facile à déchiffrer. À ce stade, je vous suggère de demander au client messagelabs de contacter son numéro de support avec les codes d'erreur (ou leur absence) que vous avez reçus de son serveur. Comme vous n'êtes pas client de messagelabs, vous ne pouvez pas enregistrer de problème ou demander à messagelabs de vérifier les paramètres sur le compte de son client. Leur client devra le demander lui-même. Ce serait similaire pour tout autre fournisseur de filtrage de courrier.

Espérons que le code d'erreur vous pointe vers un problème particulier, comme le fait que votre serveur soit répertorié dans une liste de blocage ou qu'il manque un enregistrement SPF et que vous pouvez résoudre ce problème vous-même, car traiter avec un fournisseur de filtrage du courrier à la troisième main n'est jamais amusant. Le dernier problème que j'ai eu comme celui-ci a pris plus de trois mois à résoudre avant que le défaut ne soit localisé et que messagelabs ne l'ait corrigé.

Je m'en remettrai à la réponse de kubanczyk pour plus de détails sur les paramètres SPF et DKIM car ils semblent être bien plus informés que moi!

Bonne chance!

Vos journaux SMTP sortants indiquent que la destination a accepté le message. Si le serveur de messagerie de destination est assez aimable pour envoyer un rebond pour une raison quelconque, c'est tout ce que vous obtenez. Mis à part demander au client (qui ne sait peut-être pas) ce qui est arrivé à l'e-mail, il n'y a pas grand-chose que vous puissiez faire à part deviner. Vous pouvez également consulter les en-têtes de transport d'un message que vous avez reçu du client.

Voici une fiche technique du produit pour la solution MessageLabs (regardez les actions de contrôle à la page 2)

Le système de messagerie de ce client utilise donc une solution de sécurité de messagerie d'entreprise, qui offre des politiques potentiellement complexes pour bloquer, refuser, modifier, filtrer, analyser, rediriger le courrier, etc. en fonction de facteurs communs tels que:

1. En-têtes de transport (ce message a-t-il été analysé par un autre produit? A-t-il été marqué pour le chiffrement? Est-il signé? Est-ce que je fais confiance au système de messagerie source?)
2. Destinataires (Qui est autorisé à envoyer un e-mail à qui?)
3. Sujet, restrictions de pièces jointes (Est-ce que 'V1AGArA' dans le sujet? Contient-il un .exe?)
4. Mots-clés restreints dans le texte?
5. Le texte du message a-t-il été classé? (Ce message a-t-il été marqué comme abusif? Contient-il des informations personnelles?)

La liste se rallonge de plus en plus. Je ne connais pas très bien l'offre de MessageLab, mais je travaille avec un produit similaire que les services de conformité, de gouvernance, de risque et de sécurité informatique de la grande banque adorent, car il permet à ces services de filtrer, auditer, archiver, réviser, analyser, catégoriser, bloquer courrier avec un niveau de détail extrêmement granulaire. Beaucoup de nos clients sont légalement tenus de faire des choses courantes comme:

1. Mettre en quarantaine le courrier entrant et sortant qui peut constituer une violation potentielle des réglementations financières en redirigeant le message de manière transparente vers l'équipe juridique de l'entreprise pour examen et approbation.
2. Réécrivez les participants sur les messages entrants ou sortants en fonction du contenu du message.
3. Bloquer le message à partir de boîtes aux lettres spécifiques en fonction du contenu ou des mots clés
4. Expurger et réécrire des parties du message en fonction de l'analyse des documents
5. Appliquez des restrictions supplémentaires et contrôlez les actions en fonction de la région. Un exemple serait dû à la réglementation ITAR d'un de mes clients. Tous les courriers électroniques de certaines régions géographiques devaient avoir des politiques d'analyse de contenu supplémentaire appliquées avec de grands sous-ensembles de volume de courrier nécessitant une approbation manuelle pour atteindre les boîtes aux lettres des utilisateurs finaux.

Et bien sûr, étant donné que tout peut se produire et se produira dans les e-mails d'entreprise, le serveur de messagerie de destination peut toujours ignorer votre message et forger une réponse 200 OKou une 250 COMPLETEDréponse à votre relais. Cela arrive ... Je connais certains clients qui ont configuré des relais de messagerie pour acheminer le courrier vers un black holerelais afin d'éliminer les boucles de routage frauduleuses. Le courrier d'entreprise est toujours amusant :)

Mise à jour: cette réponse décrit un moyen d'obtenir un rapport de diagnostic sur n'importe quel e-mail (le contenu des e-mails, les en-têtes et la configuration du serveur). Bien que très utile pour améliorer les paramètres de mon serveur, malheureusement même après avoir corrigé tout ce qui est soulevé ici, mes e-mails ne passent toujours pas. Je vais le laisser ici car d'autres pourraient avoir plus de chance que moi.

J'ai trouvé plusieurs services de test de messagerie en ligne gratuits. Ils génèrent une adresse e-mail unique, vous lui envoyez un e-mail puis cliquez sur un lien, et il fournit un rapport sur la façon dont divers filtres anti-spam connus évalueraient cet e-mail particulier.

Ils sont généralement conçus pour tester les newsletters, mais convenaient parfaitement à mes besoins.

Je ne savais pas quoi essayer, mais le premier que j'ai essayé - https://www.mail-tester.com/ - a donné des résultats utiles.

J'ai utilisé un faux test@my-domain.comcompte de messagerie pour ceux-ci, car avoir un service gratuit pour tester les comptes de messagerie pour le spam puis vendre ces comptes de messagerie aux listes de spam est un modèle commercial trop évident ... :-)

Le rapport m'a donné des pistes utiles à suivre. Voici leur verdict:

Pas mal. Certaines boîtes de réception peuvent toujours vous refuser

5/10

Et une capture d'écran de leur diagnostic:

(le "message du corps contient des erreurs" n'est pas aussi mauvais qu'il y paraît, il indique simplement qu'il n'y a pas de lien de désabonnement, car il suppose à tort que je teste une newsletter)

C'est ce que je cherchais: des choses actionnables à essayer et à réparer, en l'absence de tout échec de livraison.

Je vais donc maintenant rechercher pourquoi mes adresses e-mail pointent vers le nom d'hôte VPS maître vps.my-domain.com au lieu du nom d'hôte du serveur de messagerie mail.my-domain.com, et j'examinerai pourquoi les entrées SPF - que j'ai définies il y a des mois et que les outils MX disent très bien - ne se sont pas entièrement propagés.

Cela ressemble en particulier à la racine de mon problème particulier: une bizarrerie de la configuration du serveur que, j'imagine, certaines configurations considéreront comme non pertinente et d'autres considéreront louche:

Mise à jour...

Mauvaise nouvelle ... J'ai corrigé tous les problèmes soulevés dans le rapport Mail Tester (pour toute personne intéressée, consultez mes questions de panne de serveur sur le problème d'adresse HELO et le problème de propagation SPF ). Mes e-mails obtiennent maintenant un 10/10 parfait de Mail Tester ...

Hou la la! Parfait, vous pouvez envoyer

10/10

... mais mes e-mails ne sont toujours pas reçus par ce domaine étrange. Je commence à penser que je dois avoir été en quelque sorte ajouté à une liste noire spécifique à l'organisation (peut-être que quelqu'un a cliqué sur le bouton "spam" par erreur au lieu de "répondre" ou "archiver" ... vous ne savez pas si cela expliquerait cela?) .

Je vais essayer ma conjecture sauvage ici. Je vois que vous utilisez SPF et DKIM. Il y a donc aussi une possibilité que vous utilisiez DMARC (surtout si votre MX se trouve être exim).

Maintenant, il y a une chance que votre courrier soit envoyé à reçoit- rien.org et là vous obtenez un message de rebond (un courrier de retour indiquant la raison pour laquelle ils ne peuvent pas accepter votre courrier). Mais, par expérience, de nombreuses organisations, en particulier les grandes, ont des mécanismes sévèrement bâclés pour envoyer des messages de rebond . En particulier, Lotus Domino envoie chaque fois un DKIM erroné, car il copie votre signature DKIM sur leur message textuellement. D'autres erreurs plus subtiles ont également tendance à se produire souvent.

De nombreux messages de rebond échouent SPF. (La raison technique est qu'ils ont correctement MAIL FROM: <> et qu'ils pourraient avoir un problème avec leur EHLO.) Donc, s'ils ont une politique DMARC, cela les laisse suspendus sur DKIM uniquement, ce qui a également beaucoup de problèmes. Logiquement:

DMARC = (SPF ou DKIM) et (vérification d'alignement de l'identité de l'en-tête)

Essayez donc de désactiver temporairement la vérification DMARC, DKIM, SPF du courrier entrant sur votre MX. (Cela signifie que vous ne devez pas modifier vos enregistrements DNS uniquement vos paramètres d'exim.) Envoyez-les par courrier et attendez quelques heures pour un rebond, puis réactivez DMARC, DKIM, SPF.

Souvent, les fournisseurs de courrier ont des roules étranges en place et suppriment automatiquement les courriers qui correspondent aux roules.
Nous avons eu ce problème:
un fournisseur de messagerie a supprimé nos e-mails en fonction de l'adresse postale car une autre entreprise (qui a envoyé des spams) était située à la même adresse ...
Je voudrais donc:
- envoyer un courrier électronique sans contenu (également sans votre pied de page normal) et sans pièce jointe à une boîte aux lettres, qui ne reçoit pas vos e-mails
=> S'il peut être reçu, une partie de votre contenu normal est marqué comme "mauvais"
Dans tous les cas, je demanderais à votre partenaire ( qui ne reçoivent pas vos e-mails) pour le nom du fournisseur, puis appelez leur hotline.

J'ai eu un problème similaire. L'utilisateur final indique qu'un e-mail MSOutlook à un e-mail externe spécifique ne s'affiche jamais. Les e-mails étaient dans ses éléments envoyés. Elle n'a jamais reçu un non livrable. MSExchange l'a montré comme étant transféré avec succès vers un autre système de messagerie. L'utilisateur externe envoyé par e-mail ne l'a pas vu dans son courrier indésirable ou indésirable.

Solution. Vider son cache pour le courrier électronique de cet utilisateur externe. Adresse e-mail copiée et collée à partir d'un e-mail reçu de cette personne et cela fonctionne maintenant. Allez comprendre.

J'ai trouvé ces "informations" sur le site Web de Microsoft, j'espère que cela aide au moins un peu. SOURCE => Les e-mails sortants Outlook ne sont pas reçus par les destinataires

QUESTION:

Les gens ne reçoivent pas les e-mails que j'envoie via Outlook. Ils apparaissent comme ayant été envoyés avec succès dans mon dossier Envoyés, et je ne reçois aucun message disant qu'ils n'étaient pas livrables. Ils ne se retrouvent pas dans les dossiers de spam ou de courrier indésirable de mes destinataires.

RÉPONSE:

Si vous rencontrez des problèmes avec cela, il existe un thread où quelqu'un dans Outlook 2007 a rencontré le même problème et a été résolu en modifiant certaines propriétés de port. Tout le mérite revient à Lisa, l'OP qui a publié sa solution: => (Lire la question et la réponse ci-dessous)

QUESTION:

Exécution d'Outlook 2007 sur Vista ... les messages sortants ne vont pas, mais dites "terminé" dans la boîte aux lettres sortante. Les messages ne sont pas reçus par les destinataires et n'apparaissent pas dans le dossier envoyé. Y a-t-il une solution à cela? L'ordinateur suivant est Windows 7, même programme, n'ayant pas le problème. Connecté au même réseau et Internet est très bien.

RÉPONSE:

Quel est le type de compte de messagerie configuré dans Outlook (POP, IMAP, MAPI ou EXCHANGE)? Voyez-vous les e-mails dans la boîte d'envoi ou ceux-ci quittent-ils la boîte d'envoi? Essayez de vous envoyer un e-mail et vérifiez si vous pouvez recevoir l'e-mail de test. Démarrez également le système en mode de démarrage minimal, puis essayez d'envoyer l'e-mail et de vérifier. Reportez-vous au lien ci-dessous pour démarrer le système en mode de démarrage minimal: http://support.microsoft.com/kb/929135 (longue procédure détaillée.)

Remarque: assurez-vous de redémarrer le système en mode normal une fois le problème résolu.