Gebruikers van Office 365 hoeven zich doorgaans over de configuratie van hun mailomgeving geen zorgen te maken, Microsoft regelt dit immers. Dan is het ook opvallend als verschillende Office 365 gebruikers af en toe melden dat hun mail door andere organisaties geweigerd wordt. Ze ontvangen dan een Non Delivery Report (NDR) die lijkt op deze:
Delivery has failed to these recipients or groups:
jansen@contoso.com
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
The following organization rejected your message: mailserver.contoso.com.Diagnostic information for administrators:
Generating server: bigfish.comjansen@contoso.com
mailserver.contoso.com #<mailserver.contoso.com #5.0.0 smtp;554 mail server permanently rejected message (#5.3.0)> #SMTP#
Het goed interpreteren van een NDR lijkt wel eens hogere wetenschap, maar het gaat hier met name om de volgende twee delen:
Generating server: bigfish.com
Dit is de server die er niet in geslaagd is om je bericht af te leveren, deze server heeft de foutmelding opgeslagen en aan jou teruggekoppeld. De domein bigfish.com is van Microsoft, dit zijn de servers die uitgaande mail van Office 365 gebruikers proberen te verzenden.
smtp;554 mail server permanently rejected message (#5.3.0)
Dit is het antwoord wat de mailserver van de ontvanger gegeven heeft toen de Office 365 server het bericht af wilde leveren. Een SMTP foutcode die met een 5 begint is een permanente fout, dus heeft bigfish.com het later niet nog eens geprobeerd maar gelijk een NDR opgesteld.
Nu weten we dus dat de mailserver van de ontvanger het bericht geweigerd heeft maar we weten nog niet waarom. Aangezien meerdere gebruikers dit probleem melden bij verzenden naar verschillende domeinen moet er ergens een oorzaak zijn die specifiek aan de servers van Office 365 gerelateerd is. Voor één van onze klanten hebben we dit onderzocht en om toelichting gevraagd aan de beheerder van de ontvangende server. Deze gaf ons de volgende regels uit het logbestand van hun spamfilter:
Mar 29 14:45:37 vps01 qmail-queue-handlers[10396]: from=peter.noorderijk@imara-ict.nl
Mar 29 14:45:37 vps01 qmail-queue-handlers[10396]: to=jansen@contoso.com
Mar 29 14:45:37 vps01 greylisting filter[10397]: Starting greylisting filter...
Mar 29 14:45:37 vps01 greylisting filter[10397]: list type: black, from: tx2outboundpool.messaging.microsoft.com, match string: dsl|pool|broadband|hsd
De oorzaak blijkt een verkeerd geconfigureerde Qmail mailserver te zijn. Deze doet onderzoek naar de verzendende servers en vindt een DNS-record waar het woord ‘pool’ in zit, waarop hij de mail weigert. De bedoeling van die configuratie is om mail verzonden door geïnfecteerde thuiscomputers te weigeren maar deze aanpak blijkt dus niet de juiste.
Nu weten we waar de oorzaak zit, maar nu het oplossen nog. Dit kan alleen de beheerder van de ontvangende mailserver doen, Microsoft of Office 365 Support kunnen hier niets aan doen. Een extra moeilijkheid is dat het hier vaak om gehoste servers gaat met een Plesk control panel waar men weinig in kan configureren, anders dan het spamfilter in zijn geheel aan- of uitschakelen. Als de beheerder wel toegang heeft tot de configuratie kan hij de servers van Microsoft toevoegen aan de whitelist van domeinen:
/usr/local/psa/bin/grey_listing --update-server -domains-whitelist "add:*messaging.microsoft.com"
Veel beter is het natuurlijk om een meer intelligent spamfilter te gebruiken. Mogen we zo vrij zijn om een proefabonnement op Exchange Online Protection aan te bieden? Office 365 gebruikers hoeven zich geen zorgen te maken dat ze mails missen door zo’n misconfiguratie want Exchange Online Protection maakt standaard al deel uit van Exchange Online in Office 365.
Met dank aan collega Peter Noorderijk voor het in bezit krijgen van de logbestanden!
No comments:
Post a Comment