Mail van 1 verzender komt niet aan, hoe troubleshooten?

[Jazzy]

Een buitenlandse relatie klaagt dat hun mail niet bij ons aankomt. Geen ndr, het eindigt in een zwart gat. Aan mij (systeembeheerder) is gevraagd om te kijken of er bij ons wat mis is. In tweede instantie ga ik contact opnemen met de techneuten van onze relatie maar eerst wil ik zoveel mogelijk oorzaken uitsluiten.

Als eerste onze DNS gegevens:

code:

> capway.nl
Server:  [217.148.161.15]
Address:  217.148.161.15

capway.nl       internet address = 217.148.161.16
capway.nl       nameserver = ns7.flaxe-webhosting.be
capway.nl       nameserver = ns8.flaxe-webhosting.be
capway.nl
        primary name server = ns7.flaxe-webhosting.be
        responsible mail addr = root.aidos.flaxe-webhosting.nl
        serial  = 2004030903
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 86400 (1 day)
capway.nl       MX preference = 0, mail exchanger = mail.capway.nl
capway.nl       nameserver = ns7.flaxe-webhosting.be
capway.nl       nameserver = ns8.flaxe-webhosting.be
ns7.flaxe-webhosting.be internet address = 217.148.161.15
ns8.flaxe-webhosting.be internet address = 217.148.161.17
mail.capway.nl  internet address = 217.166.75.20
>

Omdat ik een tijdje geleden klachten kreeg dat een reverse lookup op de naam van onze mailserver niet mogelijk bleek heb ik een PTR record aan laten maken voor 217.166.75.20. Ik weet alleen even niet hoe dat te checken.

Onze mailserver is een vrij standaard Exchange 2000 SP3 machine op Windows 2000 Server maar ik heb het gevoel/vermoeden dat het ergens buiten onze server ligt.

Iemand een idee waar ik moet beginnen met zoeken? Zitten er fouten in de DNS registratie? Waarom verdwijnen iemands mailtjes aan ons bedrijf?

[Verwijderd]

ik ben echt een n00bje op dit gebied al heb ik er vaak zitten kloten..
ik heb ook eens iets in mijn test stuk gehad
en de oplossing was de spam filter...

misschien is dat het ?

[TheRookie]

Hebben jullie anti-spam maatregelen op de Exchange machine draaien ?
Is jullie/hun mailserver misschien op een blacklist terecht gekomen ?

[ShellGhost]

Weet je 100% zeker dat het adres waar hij het heen wilt zenden klopt?
Gebeurd nogal vaak dat er net iets verkeerd staat.

[dajappie]

Jazzy schreef op donderdag 29 september 2005 @ 12:48:
Een buitenlandse relatie klaagt dat hun mail niet bij ons aankomt. Geen ndr, het eindigt in een zwart gat. Aan mij (systeembeheerder) is gevraagd om te kijken of er bij ons wat mis is. In tweede instantie ga ik contact opnemen met de techneuten van onze relatie.
<knip>
Omdat ik een tijdje geleden klachten kreeg dat een reverse lookup op de naam van onze mailserver niet mogelijk bleek heb ik een PTR record aan laten maken voor 217.166.75.20.

Kwam die klacht over die reverse lookup ook van die ene klant of van (een) andere klant(en)? Naast dingen als spam- en virusfilters zijn blacklists en missende reverse lookups veel voorkomende oorzaken. Op zich goed om eerst bij jezelf te kijken maar de logregel uit de versturende mailserver van die klant waar het niet lukt kan je waarschijnlijk precies aangeven waar het aan ligt, scheelt heel veel uurtjes zoek- en giswerk. En als die klant klaagt wil hij ook vast meewerken!

[Jazzy]

TheRookie schreef op donderdag 29 september 2005 @ 12:54:
Hebben jullie anti-spam maatregelen op de Exchange machine draaien ?
Is jullie/hun mailserver misschien op een blacklist terecht gekomen ?

Was ik vergeten te vermelden. Op de mailserver draait Symantec Mail Security for Exchange maar de spam functionaliteit gebruik ik niet, hebben we niet eens een licentie voor.

Ook in de logfiles (verwijderde attachments, virussen, etc.) komt niets voor. Daarom vermoed ik ook dat het buiten ons systeem ligt. Zoiets als dat probleem met het ontbrekende PTR-record, alles werkt behalve bij mailservers die een reverse-lookup doen die vervolgens mislukt en het mailtje als spam geruisloos laten verdwijnen.

Iets af te leiden uit onze gegevens?

[Jazzy]

dajappie schreef op donderdag 29 september 2005 @ 13:00:
[...]


Kwam die klacht over die reverse lookup ook van die ene klant of van (een) andere klant(en)?

Die klachten kwamen alleen van mijn collega's omdat door hun verzonden mail niet bij de ontvanger aan kwam.

Hoe kun je zoiets controleren eigenlijk?

[ShellGhost]

Jazzy schreef op donderdag 29 september 2005 @ 13:04:
[...]
Die klachten kwamen alleen van mijn collega's omdat door hun verzonden mail niet bij de ontvanger aan kwam.

Hoe kun je zoiets controleren eigenlijk?

Je kan met outlook een notification aanhangen, dat zodra iemand het mailtje gelezen/geopend heeft een bevestiging stuurt dat hij 'm gelezen heeft.
Dit is niet een normaal mailtje wat je eerst moet tiepen.

[GlowMouse]

Jazzy schreef op donderdag 29 september 2005 @ 13:04:
[...]
Die klachten kwamen alleen van mijn collega's omdat door hun verzonden mail niet bij de ontvanger aan kwam.

Hoe kun je zoiets controleren eigenlijk?

C:\>nslookup 217.166.75.20
Server: [...]
Address: [...]

Name: mail.capway.nl
Address: 217.166.75.20

Gaat dus goed naar mail.capway.nl

[JoetjeF]

Weten zij wel zeker dat het mailtje bij jullie systeem is aangekomen? Hebben ze een SMTP log waarin duidelijk staat dat het mailtje door jullie server is geaccepteerd?

[Angelfire]

Wat je hebt is een best lastig probleem, er zijn niet echt methodes (behalve de piep methode) om te controleren of je mail niet ontvangt die je wel zou moeten ontvangen.

Voor wat betreft je probleem:
Volgens de SMTP specificaties is het niet jouw probleem, maar van de verzender. Als de verzender nl. een reverse lookup doet naar je MX record om te controleren of je wel bent wie je zegt dat je bent, dan houdt de verzender zich niet aan de SMTP specs. Dit probleem kom ik vaker tegen en jij kan er niet echt iets aan doen behalve melden dat de verzender iets doet wat niet mag. Veel black list filters gebruiken eenzelfde truuk.

Ik vind het vervelend om met "vingertjes" te wijzen, maar nu is het niet anders. Lees er de RFC voor SMTP maar op na, daar staat precies in wat wel en niet mag...

Edit:
De "ontvangstbestiging" geeft nog niet aan dat het mailtje in de mailbox van de ontvanger staat. Van mijn systemen krijg je de ontvangsbevestiging van de antivirus gateway dat zij het bericht hebben geaccepteerd, dan ligt ie nog niet in de mailbox, mijn clients mogen geen outbound leesbevestiging sturen, dus ook daar heb je niets aan. Dat systeem is dus niet waterdicht, verschillende mail clients gaan verschillend om met dit soort berichten.

[ Voor 23% gewijzigd door Angelfire op 29-09-2005 13:24 ]

[Jazzy]

JoetjeF schreef op donderdag 29 september 2005 @ 13:13:
Weten zij wel zeker dat het mailtje bij jullie systeem is aangekomen? Hebben ze een SMTP log waarin duidelijk staat dat het mailtje door jullie server is geaccepteerd?

Zoals ik al zei, ik wil eerst zoveel mogelijk zelf checken voordat ik bij hun aanklop.

Inderdaad, onze reverse lookup klopt:

code:

Reverse DNS for 217.166.75.20
Generated by www.DNSstuff.com
Location: Netherlands

Preparation:
The  reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 217.166.75.20 is found by looking up the PTR record for
 20.75.166.217.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking d.root-servers.net for 20.75.166.217.in-addr.arpa PTR record:  
       d.root-servers.net says to go to tinnie.arin.net. (zone: 217.in-addr.arpa.)
Asking tinnie.arin.net. for 20.75.166.217.in-addr.arpa PTR record:  
       tinnie.arin.net [69.25.34.195] says to go to ns2.kpn.net. (zone: 166.217.in-addr.arpa.)
Asking ns2.kpn.net. for 20.75.166.217.in-addr.arpa PTR record:  Reports mail.capway.nl. [from 194.151.228.50]

Answer:
217.166.75.20 PTR record: mail.capway.nl. [TTL 86400s] [A=217.166.75.20]

Hey, nu wordt het interresant. Als ik bij de DNS gegevens van hun domein kijk dan zie ik:

code:

domein.de MX preference = 80, mail exchanger = mail.domein.de
mail.domein.de    internet address = 81.209.129.xx

Als ik een reverse lookup doe op dit IP-adres dan (b)lijkt er geen PTR-record te zijn:

code:

Answer:
81.209.129.xx PTR record: 81-209-129-xx.citynet.de. [TTL 0s] [A=None] *ERROR* A record does not point back to original IP.

(laatste cijfers vervangen door xx, domeinnaam door domein)

Blijkbaar doet een server onderweg (de onze?) toch een reverse lookup en zal om die reden de mail weigeren. Klopt dit?

[ Voor 19% gewijzigd door Jazzy op 29-09-2005 20:29 ]

[Brahiewahiewa]

Zo te zien zit d'r een PiX tussen je Exchange servert en het internet

code:

SMTP - 25 220 ********************************************************0*2************************2******200********0***0200

Zet op die PiX het SMTP filter eens uit en probeer het dan nog een keer

Ziet http://honor.trusecure.co...ards/2001-May/010742.html

[ Voor 14% gewijzigd door Brahiewahiewa op 29-09-2005 13:56 ]

[dajappie]

Jazzy schreef op donderdag 29 september 2005 @ 13:22:
[...]
Zoals ik al zei, ik wil eerst zoveel mogelijk zelf checken voordat ik bij hun aanklop.

Blijkbaar doet een server onderweg (de onze?) toch een reverse lookup en zal om die reden de mail weigeren. Klopt dit?

Kan maar zo blijft het gissen, zoals eerder gesuggereerd check je eigen maillogs eens, alle ordentelijke mailservers maken daarin keurig melding van geweigerde mailtjes en om welke reden.

En doen Cisco PIX'jes in hun SMTP-filter ook lookups? Dan zijn er vast meer klagende klanten...

[Brahiewahiewa]

dajappie schreef op donderdag 29 september 2005 @ 14:02:
[...]En doen Cisco PIX'jes in hun SMTP-filter ook lookups? Dan zijn er vast meer klagende klanten...

Nope; die PiXjes doen vooral aan het silently droppen van alles wat ze niet (willen) begrijpen. En dan krijg je dit soort problemen.

[Jazzy]

Brahiewahiewa schreef op donderdag 29 september 2005 @ 14:05:
[...]
Nope; die PiXjes doen vooral aan het silently droppen van alles wat ze niet (willen) begrijpen. En dan krijg je dit soort problemen.

Het is een PIX 515E die ik beheer met de PDM. Kun je me een eindje op weg helpen?

[Jazzy]

Okay, niet alleen via de PDM dus, heb de config even bekeken. Ik heb alleen een regel die zegt:

code:

fixup protocol smtp 25

[Verwijderd]

In dit document:

Also, certain configurations of Microsoft Exchange Server require the use of commands not allowed by MailGuard. In this scenario, MailGuard must be disabled using the no fixup protocol smtp 25 command.

[Jazzy]

Okay, nog een mogelijke oorzaak weggenomen. Probleem met het ontbreken van het PTR-record is dat mijn server helemaal geen reverse-lookup doet en dus ook niet om die reden zal droppen.

Toch zal ik ze adviseren om dat te fixen waarna we eens nauwkeurig kunnen gaan testen. Kan ik misschien ook zelf doen door met Telnet van buitenaf een SMTP-sessie sessie op te zetten en een mail te maken voor een lokale gebruiker met als afzender [e-mail]. Dat kan toch?

[dajappie]

Even googlen op telnet+smtp en je bent er al, zie bv http://www.yuki-onna.co.uk/email/smtp.html, dan weet je iig of het aan jouw machine ligt of extern.

[ Voor 22% gewijzigd door dajappie op 29-09-2005 16:33 ]

[Brahiewahiewa]

Jazzy schreef op donderdag 29 september 2005 @ 15:42:
... Kan ik misschien ook zelf doen door met Telnet van buitenaf een SMTP-sessie sessie op te zetten en een mail te maken voor een lokale gebruiker met als afzender [e-mail]. Dat kan toch?

Dat kan, maar ik betwijfel of je er veel mee opschiet.
't Probleem met die PiX is dat-ie bepaalde commando's niet doorlaat. Als jij via een telnet sessie dat mailtje verstuurt, zul je dat met alleen de basic commando's doen en die worden wel door de PiX doorgelaten.

Wat je zou kunnen doen, is een mailtje sturen naar [e-mail] en dan afwachten of de non-delivery binnenkomt.

[ Voor 9% gewijzigd door Brahiewahiewa op 29-09-2005 22:37 . Reden: removed [ot] ]

[Jazzy]

Brahiewahiewa schreef op donderdag 29 september 2005 @ 20:24:
[...]
Dat kan, maar ik betwijfel of je er veel mee opschiet.
't Probleem met die PiX is dat-ie bepaalde commando's niet doorlaat. Als jij via een telnet sessie dat mailtje verstuurt, zul je dat met alleen de basic commando's doen en die worden wel door de PiX doorgelaten.

Maar nu niet meer dus want ik heb die regel uitgezet.

Wat je zou kunnen doen, is een mailtje sturen naar [e-mail] en dan afwachten of de non-delivery binnenkomt.

Goede tip, zo kan ik makkelijk troubleshooten zonder telkens een mail te laten sturen!