[Exchange 2003] Mail naar gebruiker komt soms niet aan

[Verwijderd]

Hallo allen,

Een raadsel voor mij:
Voor een bedrijfje doen wij het systeemonderhoud.
Nu doet zich het probleem voor dat als iemand van buitenaf ([e-mail]) een mail stuurt naar dit bedrijf ([e-mail]) een foutmelding krijgt:

De volgende geadresseerde(n) zijn niet bereikt:

[e-mail] op 18-1-2008 9:40
De organisatie waarnaar dit bericht is verzonden, heeft aangegeven dat de e-mailaccount niet bestaat. Controleer het e-mailadres of neem rechtstreeks contact op met de geadresseerde om na te gaan hoe het e-mailadres luidt.
<tccnt01.tcc.local #5.1.1 smtp;550 5.1.1 unknown or illegal alias: [e-mail]>


Andere bedrijven die naar [e-mail] mailen hebben hier geen problemen mee en de mail komt ook gewoon netjes aan.
Wij gebruiken hier exchange2003 met alle nieuwste updates op een SBS2003.
De mail wordt via mx records omgeleid naar de server zelf, dus geen POP accounts.
In het betreffende account is het e-mailadres ook juist en ook de verzender maakt geen spelfout in het e-mailadres.

Iemand enig idee wat er mis gaat? De foutmelding geeft op google een wirwar van hele andere soort problemen.
Dank

[ Voor 5% gewijzigd door Verwijderd op 07-02-2008 13:31 ]

[_H_G_]

mx records pas nog aangepast? misschien kunnen die bedrijven jouw server niet bereiken (door bijv. oude dns gegevens) en gaat de mail naar een back-up server die niet goed geconfigureerd is?

Maar wel vreemd ja

[ Voor 7% gewijzigd door _H_G_ op 24-01-2008 12:21 ]

[DukeBox]

En wat heb je zelf al allemaal geprobeerd ?

Wat als je zelf telnet naar je smtp server en het betreffende account opvraagt ?

[lier]

DukeBox schreef op donderdag 24 januari 2008 @ 12:24:
En wat heb je zelf al allemaal geprobeerd ?

Wat als je zelf telnet naar je smtp server en het betreffende account opvraagt ?

Inderdaad...de enige mogelijke aanpak is om zelf te controleren op welk niveau dit fout gaat. Aangezien je een hele nette boodschap krijgt, verwacht ik dat het adres nog niet bekend was ten tijde van de eerste test. Zou je nog een testmailtje kunnen sturen (de situatie die eerst fout ging) ?

Het gekke is wel dat dit mailtje binnenkomt op de info alias. Dit is de catchall voor alle verkeerde aliassen die gemailt worden

Dit is helemaal niet gek. De melding is een SMTP melding, wat met dat mailtje verder gebeurt is afhankelijk van de instellingen (en loopt dus normaal naar de catchall = meest ranzige en overbodige instelling in een mail server).

[_H_G_]

zoals ik het begreep kan het ene externe bedrijf de persoon wel goed mailen, maar het andere externe bedrijf weer niet. Lijkt mij om dan een gemeenschappelijkheid te zoeken (gebruiken ze toevallig dezelfde mailprovider als jezelf, of kunnen ze allemaal je server niet bereiken).

Maar kan het verkeerd gelezen hebben

[lier]

De enige echte vraag is: is de "tccnt01.tcc.local " de Exchange server waar het account op aangemaakt is ?

[Verwijderd]

hoi lier,

"tccnt01.tcc.local " is niet de Exchange omgeving van dit bedrijf... maar de SMTP van de verzender, als ik de mail index goed uitlees.

Telnet gaat hier prima..en volgens mij zitten ze beiden op een planet verbinding.

mx records zijn al een jaar ofzo aangepast, dus een dns probleem lijkt het me niet.

kortom:
bedrijfa kan het bedrijf wel bereiken op user@domein
bedrijfb kan het bedrijf niet bereiken op user@domein en krijgt die foutmelding

[ Voor 18% gewijzigd door Verwijderd op 24-01-2008 13:22 ]

[lier]

Zou je eens de hele header kunnen posten van de mail ?
Kan je eens vanuit bedrijfb een telnet sessie starten daarmee een mail naar de gebruiker sturen (en dan bij voorkeur alle request & responses hier posten ?

[Verwijderd]

wordt wat lastig, maar ik ga het diegene vragen.
dank

[DukeBox]

Het zou kunnen dat tccnt01.tcc.local niet door de PTR check komt (ik zou zoiets ook niet doorlaten).

[Verwijderd]

hoe kan ik dat controleren? in de logs staat hier niks over vermeld namelijk

[lier]

Verwijderd schreef op donderdag 24 januari 2008 @ 13:49:
hoe kan ik dat controleren? in de logs staat hier niks over vermeld namelijk

Focus je ajb eens op het probleem, de halve wereld mailt via een interne server (waarvan de domeinnaam op .local / .lan / .whatever). Dit staat ook verder helemaal los van de FQDN die gebruikt wordt tijdens de communicatie...

[Leon T]

Kan je controleren welk e-mail adres er genoemd staat in het AD profiel van de gebruiker?

[Verwijderd]

zoals eerder aangegeven, het e-mailadres van de user in AD klopt.

telnet sessies gaan ook normaal, ook van hun kant.

[Kabouterplop01]

Is de accountnaam misschien veranderd in het verleden, terwijl het emailadres hetzelfde is gebleven?

[lier]

Verwijderd schreef op vrijdag 25 januari 2008 @ 11:34:
zoals eerder aangegeven, het e-mailadres van de user in AD klopt.

telnet sessies gaan ook normaal, ook van hun kant.

Als het via telnet goed gaat, moet het op elk andere manier ook goed gaan. Oftewel, het probleem zit aan de verzendende kant en niet de ontvangende kant. Zou het kunnen dat aan de zendende kant het op DNS niveau fout gaat (en de server een verbinding probeert op te bouwen met het verkeerde IP adres) ?

Is de telnet sessie uitgevoerd op basis van het mx record ?

Doet het probleem zich nog steeds voor ?

[Verwijderd]

kleine update;
er zijn inmiddels een twee-tal bedrijven die niet naar deze klant kunnen mailen.
Beiden maken zij gebruik van een KPN Office ADSL verbinding. Dit lijkt mij niet toevallig.

Inmiddels heb ik ook contact gehad met de IT afdeling van deze 2 bedrijven en wij vermoeden dat de relay server van planet (welke wij gebruiken) een of andere blokkade vormt voor mailverkeer van hun kant (KPN Office dsl).

Ik hou jullie op de hoogte

[ Voor 5% gewijzigd door Verwijderd op 06-02-2008 13:19 ]

[Jazzy]

Verwijderd schreef op woensdag 06 februari 2008 @ 13:17:
kleine update;
er zijn inmiddels een twee-tal bedrijven die niet naar deze klant kunnen mailen.
Beiden maken zij gebruik van een KPN Office ADSL verbinding. Dit lijkt mij niet toevallig.

Inmiddels heb ik ook contact gehad met de IT afdeling van deze 2 bedrijven en wij vermoeden dat de relay server van planet (welke wij gebruiken) een of andere blokkade vormt voor mailverkeer van hun kant (KPN Office dsl).

Ik hou jullie op de hoogte

Dat begrijp ik niet goed. Volgens die NDR probeert server tccnt01.tcc.local mail te bezorgen bij de Exchange server en niet de SMTP relayserver van Planet.

Overigens is het wel degelijk relevant dat die server zich identificeert als tccnt01.tcc.local, dit is immers geen geldige naam en steeds meer servers doen tegenwoordig een reverse lookup. Bij het mislukken van deze check droppen ze de mail zonder het verzenden van een NDR. Dat bedrijf (tcc?) moet dit in ieder geval aanpassen.

[alt-92]

Ligt er aan welke relayhost er gebruikt wordt.. is dat mailrelay.planet.nl of mail.planet.nl ?

Die laatste heeft veel striktere settings.

[Verwijderd]

Wij hebben ook een klant die gebruik maakt van de relayserver mail.planet.nl (mailrelay.planet.nl werkt niet....) maar tevens ook problemen heeft om bepaalde domeinen te mailen.

Dit is helaas bij een aantal domeinen maar het geval.


Ook hebben we nog een klant die 'plotseling' ook meldingen vanuit hun klanten krijgen met de melding dat hun mailaddressen niet meer bestaan (dus de server een melding teruggeeft dat het mailadres niet bestaat)

Wellicht een algemeen probleem ergens??

[Jazzy]

Maar dan klopt die NDR toch niet?

[alt-92]

Wat ik wel weet uit eigen ervaring:
Als je domain ooit bij Planet gehost heeft gestaan wil het nog wel eens voorkomen dat de domainnames niet uit een alias lookuptabel worden gehaald.
Planet/KPN users die dan naar dat ex-Planet domain willen mailen krijgen dan óf een irrelevante melding terug, óf helemaal geen melding.
(Dan verdwijnt je mail gewoon in een zwart gat - da's pas lekker...)

Diezelfde tabel wordt niet gebruikt door de mailrelay.planet.nl host, stuur je daar mail overheen werkt het opeens wel.

[Verwijderd]

alt-92 schreef op woensdag 06 februari 2008 @ 22:58:
Wat ik wel weet uit eigen ervaring:
Als je domain ooit bij Planet gehost heeft gestaan wil het nog wel eens voorkomen dat de domainnames niet uit een alias lookuptabel worden gehaald.
Planet/KPN users die dan naar dat ex-Planet domain willen mailen krijgen dan óf een irrelevante melding terug, óf helemaal geen melding.
(Dan verdwijnt je mail gewoon in een zwart gat - da's pas lekker...)

Diezelfde tabel wordt niet gebruikt door de mailrelay.planet.nl host, stuur je daar mail overheen werkt het opeens wel.

zojuist remote ingelogt. outlook expres op de server opgestart met als SMTP mailrelay.planet.nl en dan krijg ik de melding dat ik geen rechten heb om te relayen...

Ik zal morgen de exacte melding even pasten hier naar toe.


Tot zover ik weet heeft dat domein nooit in NL gestaan (dus ook niet Planet) aangezien het domeinnaam in USA geclaimed staat.

[Verwijderd]

het gaat dus om het ontvangen van mail van de relay server van planet "mailrelay.planet.nl" inderdaad..

@alt-92:het klopt dat hun domein eerder gehost is door planet, maar nu al ruim een jaar geleden verhuisd is naar andere hosting.

Wat is volgens jou de oplossing???

@jazzy: die NDR lijkt een Exchange melding ja; maar de mail komt niet eens zover (tot aan onze Exchange server)

nog een update: eerder in mijn TS gaf ik aan dat de mail wel aankwam op de info alias, ook dit gebeurt NIET..

Inmiddels na uren in de wacht contact gehad te hebben Planet, hebben zij mij verzocht een mailtje met het probleem te mailen naar [e-mail], omdat zij verantwoordelijk zijn voor de relay.
Echter zijn zij volgens de reguliere helpdesk telefonisch niet bereikbaar........ grrrrrr

[ Voor 96% gewijzigd door Verwijderd op 07-02-2008 13:34 ]

[alt-92]

Verwijderd schreef op donderdag 07 februari 2008 @ 13:24:
het gaat dus om het ontvangen van mail van de relay server van planet "mailrelay.planet.nl" inderdaad..

@alt-92:het klopt dat hun domein eerder gehost is door planet, maar nu al ruim een jaar geleden verhuisd is naar andere hosting.

Wat is volgens jou de oplossing???

Testen, testen en nog eens testen.
Ik weet niet of je zelf nog een Planet account hebt (die had ik destijds nog wel), maar dan kun je voor jezelf heel snel achterhalen of dat werkt.
Ga ook na of niet-Planet/KPN gebruikers deze problemen niet ondervinden.


stuur mail via de 'standaard' eindgebruikersmailserver (mail.planet.nl) - werkt dat niet, pak dan de mailrelay.
Als dat wel werkt kan je best tegen dat alias-lookup verhaal lopen.

Inmiddels na uren in de wacht contact gehad te hebben Planet, hebben zij mij verzocht een mailtje met het probleem te mailen naar [e-mail], omdat zij verantwoordelijk zijn voor de relay.
Echter zijn zij volgens de reguliere helpdesk telefonisch niet bereikbaar........ grrrrrr

Gewoon stug maar wel beleefd doordrammen dat je een 2elijns medewerker wil spreken, eerstelijns snapt dat toch niet als je over relayhosts, ex-Planet domains , lookuptables en NDRs gaat beginnen...

[Verwijderd]

het probleem lijkt "opgelost"
dit is de deal:
Het domein werd eerder gehost door planet en is dus verhuisd.
De afhandeling hiervan is door planet destijds niet correct afgesloten, waardoor volgens een 2elijns meneer de routing in de DNS tables bij planet nog half actief waren, omdat volgens het systeem het domein nog werd gehost door planet.
Hij moet een aanpassing doen in hun DNS systeem waardoor het opgelost gaat worden. Dit alles zou hooguit 48 uur in beslag kunnen nemen.

Even kort samengevat voor evt mensen met hetzelfde probleem:"
-Exchange 2003 (MX Records) krijgt mail door via mailrelay.planet.nl
-98% van alle mail komt aan, 2% niet.
-opmerkelijk is dat deze 2% allemaal gebruikt maakt van een KPN Office DSL.
-domein werd eerder gehost door planet (1 jaar terug!!)
-domein is verhuisd naar nieuwe hosting
-bellen met 2elijns planet ; hieruit blijkt dat de afhandeling van de domeinverhuizing niet correct is gegaan, sommige DNS instellingen staan nog niet goed.
-planet gaat DNS herstellen en na 48 uur ongeveer moet alle mail dus probleemloos doorkomen

Allen bedankt voor het meedenken, en ik laat nog weten of het ook echt gelukt is.

[ Voor 33% gewijzigd door Verwijderd op 07-02-2008 17:24 ]

[alt-92]

*zucht*
Er is dus nog niks veranderd in vier jaar tijd

[Verwijderd]

[Verwijderd]

Ter info:

Sorry voor late reactie...

Had vanmorgen ook even met planet gebelt, na een aantal moeilijke technische woordjes die ze niet snappen had ik iemand aan de lijn die mij verder kon helpen, ze hebben een domeinnaam die inmiddels al een jaar bij ons in het datacenter gehost is (en bij SIDN ook bij ons staat) nog steeds in de planet/kpn DB staan.....vandaar dat er vanuit veel klanten/personen geen mail binnen kwam omdat simpelweg de alias niet bestond op de server van planet/kpn/whatever.......


Fax verstuurd met opzegging, DNS moet binnen 1 werkdag gefixt zijn.

Waarom dit zich nu pas voordoet sinds 2 weken bij deze klant terwijl het domein al een jaar bij ons is is mijn een raadsel...iemand nog een idee?

[alt-92]

Omdat ze zo nu en dan lopen te klooien met die maildozen (het zijn clusters).
Het is wel een regelmatig terugkerend fenomeen, en zoals je merkt nogal ongrijpbaar als je niet weet waar je naar moet zoeken

Anyways: ik ben blij dat er voor jullie (en je klanten) schot in de zaak zit, en dat je eindelijk wat duidelijkheid hebt

Ik ben zelf al een paar keer tegen dit verhaal aangelopen, en werd vroeger zelfs voor gek verklaard toen ik dat DNS lookup verhaal als oorzaak had gegeven

[ Voor 41% gewijzigd door alt-92 op 07-02-2008 22:05 ]

[Verwijderd]

het probleem is nu echt opgelost.
Alle mail komt aan; geen vage foutrapporten meer!
Zo zie je maar, je moet maar de juiste persoon van een helpdesk aan de lijn krijgen die snapt waar je het over hebt!!! Dank allen.

[Tijsje]

Ik heb ook het probleem dat mail verzonden via planet niet aankomt.
Hoe kan ik testen of het dezelfde fout is?

[_H_G_]

Tijsje schreef op maandag 09 maart 2009 @ 11:47:
Ik heb ook het probleem dat mail verzonden via planet niet aankomt.
Hoe kan ik testen of het dezelfde fout is?

Je zou de verzender moeten vragen om te kijken wat ze als mx record krijgen voor jouw domeinnaam (of je zou het hier kunnen posten en dat iemand met een KPN verbinding even kijkt, maar het beste is natuurlijk om de werkelijke situatie te bekijken).

[Tijsje]

_H_G_ schreef op maandag 09 maart 2009 @ 12:37:
[...]

Je zou de verzender moeten vragen om te kijken wat ze als mx record krijgen voor jouw domeinnaam (of je zou het hier kunnen posten en dat iemand met een KPN verbinding even kijkt, maar het beste is natuurlijk om de werkelijke situatie te bekijken).

Zou iemand met een planet/wxs account eens kunnen kijken? Ik heb even een test adres aangemaakt: [e-mail]
De verzender die het adres niet kon bereiken verzond de mail via deze mail server: helo=psmtp04.wxs.nl
Het MX record zou moeten verwijzen naar: 85.92.147.231

[alt-92]

Laat die verzender dezelfde truuk met de relaymailserver dan proberen?
Lijkt me nuttiger dan dat wij voor jou iets op afstand gaan troubleshooten

[Tijsje]

alt-92 schreef op maandag 09 maart 2009 @ 13:02:
Laat die verzender dezelfde truuk met de relaymailserver dan proberen?
Lijkt me nuttiger dan dat wij voor jou iets op afstand gaan troubleshooten

Ik ken de verzender niet. Wij als reclamebureau doen de hosting voor een klant en deze heeft problemen.
Er zit ook geen relay server tussen, het is de reselling server van pcextreme.
Het is ook niet echt handig als je zelf de fout niet kunt reproduceren

De organisatie waarnaar dit bericht is verzonden, heeft aangegeven dat de e-mailaccount niet bestaat. Controleer het e-mailadres of neem rechtstreeks contact op met de geadresseerde om na te gaan hoe het e-mailadres luidt.
<SERVER.ESVEHA.LOCAL #5.1.1 smtp;550 5.1.1 unknown or illegal alias: ***@gezondwerkenlangstraat.nl>

[_H_G_]

code:

> set type=mx
> gezondwerkenlangstraat.nl
Server:  ns1.wxs.nl
Address:  195.121.1.34

Non-authoritative answer:
gezondwerkenlangstraat.nl       MX preference = 20, mail exchanger = relay.transip.nl
gezondwerkenlangstraat.nl       MX preference = 10, mail exchanger = gezondwerkenlangstraat.nl

relay.transip.nl        internet address = 80.69.67.21
relay.transip.nl        internet address = 80.69.67.19
>

domeinnaam resolved naar 85.92.147.231.

Hmm, weet niet zoveel van mx records. Maar klinkt niet goed? Of is dat een manier van loadbalancen..

[ Voor 13% gewijzigd door _H_G_ op 10-03-2009 16:02 ]

[Tijsje]

_H_G_ schreef op dinsdag 10 maart 2009 @ 15:53:

code:

> set type=mx
> gezondwerkenlangstraat.nl
Server:  ns1.wxs.nl
Address:  195.121.1.34

Non-authoritative answer:
gezondwerkenlangstraat.nl       MX preference = 20, mail exchanger = relay.transip.nl
gezondwerkenlangstraat.nl       MX preference = 10, mail exchanger = gezondwerkenlangstraat.nl

relay.transip.nl        internet address = 80.69.67.21
relay.transip.nl        internet address = 80.69.67.19
>

domeinnaam resolved naar 85.92.147.231.

Hmm, weet niet zoveel van mx records. Maar klinkt niet goed? Of is dat een manier van loadbalancen..

Nee dat was inderdaad niet goed. Gisteren gelukkig ook wijzer geworden bij Planet, ze hadden het domein nooit opgeruimd uit hun systeem dus de mailserver probeerde de mails lokaal af te leveren.