Scenario: Un usager appel et un fournisseur ne peut lui envoyer un courriel.
Étape 1: Vérifier si c'est notre serveur qui bloque la réception.
-
A regarder le courriel d'erreur.
- A regarder si le refus vient de nous.
- OUI: Aller à l'étape 2
- NON:
- Est-ce que le fournisseur utiliser son fournisseur internet comme "smarthost" ou "relay" ?
- OUI
- Est-ce que c'est eux qui bloque le courriel ?
- Ce cas arrive quand le fournisseur internet valide avec des RBL l'IP source du courriel. Un refus dans de tel cas veut dire dans la plupart des cas une infection du site du fournisseur par un virus ou malware qui envoi beaucoup de pourriels. A regarder
l'IP dans le courriel de refus, et à aller valider dans les RBL si elle est inscrite.
Le fournisseur doit ce faire de-lister dans ce cas, et surtout régler le problème qui la fait ce faire lister.
- NON
- Utilisez-vous un service antipolluriel externe ?
- OUI
- A regarder les évènements sur l'appareil.
- NON
- Une erreure DNS chez le fournisseur ? Une mauvaise entrée MX du serveur DNS du fournisseur peut causer un problème d'envoi.
Étape 2: Connaître les règles antipourriel utilisées.
- A regarder le courriel d'erreur.
- A regardé l'erreur retournée.
- Si l'erreur vous semble justifiée, alors il faut aviser l'utilisateur que l'usager externe doit modifier quelque chose. (Il est dans une liste RBL, il a un mauvais score de courriel car il a mal écrit le courriel, etc..)
- Si vous ete pas sure que le refus est justifié il faut aller voir un peu plus loin.
Aller a l'étape 3
-
Un exemple dans Exchange 2010:
- 
Étape 3: Ont regarde plus loin dans les "logs".
-
Ont regarde notre AgentLog pour voir la vrai raison du refus:
- A faire cette comme powershell: Get-AgentLog |?{ ($_.p1fromaddress -match "contoso.com" –or $_.p2fromaddresses -match " contoso.com ") -and $_.action –eq "RejectMessage"} (Je suggère de rediriger la commande vers un fichier texte (avec > log.txt en exemple))
- Dans le fichier vous allez voir des ligne comme celle-ci:
- Timestamp : XXXX-XX-XX XX:XX:XX
SessionId : XXXXXXXXXXXXXXXX
IPAddress : X.X.X.X
MessageId :
P1FromAddress : test@contoso.com
P2FromAddresses : {test@contoso.com}
Recipients : {test@contoso.com}
Agent : Sender Id Agent
Event : OnEndOfHeaders
Action : RejectMessage
SmtpResponse : 550 5.7.1 Missing purported responsible address
Reason : MissingPRA
ReasonData : No valid PRA
Diagnostics :
- A partir d'ici il faut diagnostiquer l'erreur et voir si ont peut changer nos règle d'antipourriel.
Étape 4: Les scripts utile.
Get-AntispamFilteringReport.ps1 : Pour avoir un état général de l'antipourriel.
Get-AntispamSCLHistogram.ps1 : Pour avoir un tableau des valeur SCL des pourriels reçus.
Get-AntispamTopBlockedSenderDomains.ps1 : Pour avoir une listes des addresse source le plus souvent bloquée. A ne pas oublier que ces domaines peuvent etre manipuler, donc l'option SenderID nous permet de mieux géré cela.
Get-AntispamTopBlockedSenderIPs.ps1 : Pour avoir une liste des IP qui nous envoi le plus de pourriels. A ne pas oublier que l'ont peut bloquer au niveau du routeur ces IP par après (ou a mettre dans les IP bloquer dans l'antipourriel d'Exchange).
Ceci va éviter du traffic de validation vers les RBL.
Get-AntispamTopBlockedSenders.ps1 : Pour avoir celui qui nous envoi le plus de pourriels.
Get-AntispamTopRBLProviders.ps1 : Pour avoir une liste des RBL et combien de pourriels il ont bloqué. Enlever un RBL si un fournisseur ne peut pas nous envoyé un courriel peut etre dangereux si le RBL bloque beaucoups de pourriels. Donc
a juger de la situation quand ont valide les RBL utilisé.
Get-AntispamTopRecipients.ps1 : Les usagers qui reçoive le plus de pourriels.
S'applique à
Exchange 2007
Exchange 2010
Exchange 2013
