It's Complicated

Joe's blog over technologie, het leven, en meer.

Onlangs stuitte ik op een heel vreemd probleem met Exchange 2003, IIS 6 en SMTP-domeinen. De omgeving is een gemengd Exchange 2003/2007 site met ongeveer 10 openbare SMTP-domeinnamen waarvoor deze Exchange-org is verantwoordelijk voor. Sinds het begin van mijn tijd als de beheerder voor dit systeem de ontvanger beleid instellingen zijn hetzelfde. Alle SMTP-domeinen zijn opgenomen in de ontvanger beleid, maar sommige zijn uitgevinkt. Al jaren is dit het geval is geweest en we hebben nooit een probleem. Maar iets moet hebben onlangs is gebeurd, want de laatste paar dagen bezig geweest voor mij proberen om erachter te komen wat een postbezorging probleem dat tot gevolg dat alle inkomende post voor verschillende van de legitieme publieke SMTP-domeinen terug te stuiteren naar de afzender veroorzaakt.

Na wat onderzoek en handmatig testen om te proberen te identificeren wat het probleem veroorzaakt, vond ik een vreemd ding. In de IIS 6 metabase op een van de Exchange 2003-servers, de publieke SMTP-domeinen ontbreken van de "domeinen"-toets onder LM \ SMTPSVC \ 1 \ domein. Twee van onze domeinen werden opgesomd, maar de rest ontbraken. Als de domeinen niet zijn vermeld in de IIS-metabase voor SMTP, zal de server weigeren mail gestuurd naar die domeinen omdat zij niet beseffen dat zijn bevoegde voor het ontvangen van mail voor hen. Dus heb ik besloten om een test te doen, opende ik de ontvanger beleid en zet een vinkje bij alle openbare SMTP-domeinen en wachtte een minuut voor het verversen van het IIS-metabase informatie. Toen ik weer gecontroleerd, vond ik alle openbare SMTP-domeinen correct vermeld nu in de IIS-metabase.

Eerder op de dag dat ik probeerde te testen berichten te verzenden via telnet via SMTP. Als ik zou proberen om een test bericht sturen naar een gebruiker op een van de getroffen gebieden zou ik krijg de foutmelding 'Unable to relay for user@domain.com " . Na het verversen van het IIS 6 metabase, waren mijn telnet-test met succes berichten worden aanvaard en ik bevestigde dat de gebruiker ontving hen. Andermaal hebben de ontvanger beleid meer hetzelfde sinds het begin van het AD in deze site. Ik heb geen idee waarom ineens zouden we zien inkomende e-mail problemen. Ik kan alleen maar speculeren wat er zou zijn gebeurd, misschien een eigenaardigheid te wijten aan een onverwachte DC afsluiten, of misschien zijn sommige rare Fluke met IIS 6 en een aantal andere derde partij apps die SMTP-evenement hebben haken dat veroorzaakt. Ik heb echt geen idee en ik heb geen screenshot van de IIS 6 metabase config van vóór de tijd dat we begonnen te problemen.

Wat vast het probleem was om te controleren of alle openbare SMTP-domeinen verscheen in de IIS 6 metabase. Daarna werd verzorgd, postbezorging problemen werden vastgesteld en ik was in staat om met behulp van deze handleiding telnet-test berichten te verifiëren. Dus ik weet wat de probleem was en ik weet wat het vast, ik weet niet wat er feitelijk veroorzaakt het probleem in de eerste plaats.

Als u geen metabase ontdekkingsreiziger hebt, kunt u gebruik maken van de een in de IIS 6 Resource Kit, die beschikbaar is als download van Microsoft.