antispam vs. antispam

Wanneer antispam maatregelen te maken krijgen met antispam maatregelen, dan krijg je leuke dingen zoals nested bouncemessages waar je toch even 2x moet naar kijken om te snappen wat er juist gebeurt. Zo is de volgende bounce message een echt pareltje.

Diagnostic-Code: X-Postfix; host [mx.domein.bestemmeling] said: 450 [e-mail bestemmeling]: host mx.domein.bestemmeling said: 450 [e-mail afzender]: Sender address rejected: unverified address: host mx.domein.afzender said: 450 4.7.1 [e-mail afzender]: Recipient address rejected: The HELO/EHLO given does not resolve to [ip adres dat 1 bit verschilt met mx.domein.bestemmeling] - try again later. (in reply to RCPT TO command) (in reply to RCPT TO command)

Oftewel. Ik stuur een email naar een bestemmeling. De bestemmeling contacteert onmiddelijk één van mijn mx’en terug (die bij het from: adres hoort dus) en checkt of hij mail kan sturen naar dat adres. Dit gebeurt tijdens een 2e smtp sessie, die parallell aan de sessie van de oorspronkelijke mail gebeurt. In deze 2e sessie identificeert de mail server van de bestemmeling zich ook met een HELO/EHLO statement, welke dan weer door mijn mx host gechecked wordt.

En daar zit het leuke: de mailname van de server van de bestemmeling identificeert zich blijkbaar met een hostname in dat HELO statement dat ergens met een fout ip adres matched, waardoor mijn MX die test mail dan weer gaat weigeren, en waardoor aldus de bestemmeling mijn oorspronkelijke mail gaat weigeren.

Bent u nog mee? Zoals altijd, een fsck’ing dns problem 🙂

De innesting van die 2 smtp sessies zie je trouwens ook mooi aan de dubbele (in reply to RCPT TO command) (in reply to RCPT TO command) foutmelding op het einde van de bounce message.