(exch 2003) nieuwe gebruiker krijgt geen mail, wel intern

[Roman]

Heb op een sbs2003 server een nieuwe gebruiker aan gemaakt met als inlog naam de voornaam. Dan als e-mail voornaam.achternaam. Met dat adres kan er verstuurd worden, maar niet ontvangen. Wel kan ik mails ontvangen als [e-mail]. Vreemde is dat intern wel met voornaam.achternaam verstuurd en ontvangen kan worden.

Denk dat ik ergens een stap vergeten ben. Maar volgens mij heb ik alles zo gedaan zoals het in de beschrijving staat er van uitgaand dat het bij SBS2003 het zelfde gaat als bij 2003 advanced/enterprise server. Zelf nog niet al te vaak met SBS gewerkt.

Heb lopen googlen maar dit probleem ben ik niet tegen gekomen. (okee goolge is niet mijn sterke kant).

Heb dus nog extra bij user object in AD Users and computers bij de e-mail adressen het goede adres staan en automatisch uit gevinkt anders maakt hij er automatisch voornaam@ van.

[kroegtijger]

Kijk even in de AD of er een SMTP-adres voor is, anders even maken en die als primary zetten

[Linke Loe]

Post anders ook even de NDR die je krijgt als je vanaf een extern adres mail probeert te versturen...

[Roman]

NDR krijg ik ook niet. De mail verdwijnt gewoon.

Waar precies zou ik die SMTP moeten instellen? Zo veer ik het heb kunnen vinden is de SMTP goed ingesteld. Of moet ik per mail ontvanger voor het ontvangen van mail ook een eigen SMTP omgeving aangeven?

[Jazzy]

In de Server Management console ga je naar Users, daar heb je de gebruiker ook aangemaakt als het goed is. Dubbelklik op zijn account en ga naar het tabblad E-mail Addresses. Controleer daar of het gewenste adres aan de gebruiker gekoppeld is. Ik geloof dat je dit gedaan hebt, maar weet het niet helemaal zeker.

Volgende vraag is hoe je de mail op die locatie binnenkrijgt. Is dat via (batched) SMTP of gebruiken jullie de POP Connector?

[Roman]

Heb de gebruiker aangemaakt met AD Users and Computers (Zei al dat ik weinig met SBS gedaan heb), maar dit zier er het zelfde uit. Hierin staat idd het adres zoals die moet zijn. voornaam.achternaam.

We gebruiken geen pop connector. De mail zou direct op ip van de server binnen moeten komen. Alleen de website wordt extern gehost en het mail verkeer word vanuit daar geredirect naar de exchange server. Vreemde is dat voornaam@ wel aan komt. Voor alle andere gebruikers die reeds bestonden werkt het ook allemaal gewoon.

[Piebas]

oké, maar nu wordt het mij duidelijk, de mail gaat via pop, dan moet het aderes voornaam.achternaam dus ook bekend zijn op de server waar de popbox staat dan zal je mail wel binnen komen.

[Jazzy]

Dan was dit les 1 van de SBS basics: Doe alles wat je kunt in de SBS Server Management console.

Maar goed, nu eens testen waar je mailtje blijft. Van een internetpc zou je eens met telnet een mailtje af moeten leveren aan de server. Zie voor de stappen: How To Test SMTP Services Manually in Windows Server 2003 Doe dit eenmaal met het adres waarvan je weet dat het in de mailbox belandt, en eenmaal met het adres wat problemen geeft.

In de Exchange Management Console ga je nu naar Message Tracking Center om het verloop van de testmailtjes te volgen. Als het goed is geeft dit inzicht in waat het ene mailtje gebleven is.

Protip: gebruik een subject als test12345 in je testmailtje. Zo kun je hem makkelijk terug vinden met message tracking.

Piebas schreef op maandag 25 juni 2012 @ 10:37:
oké, maar nu wordt het mij duidelijk, de mail gaat via pop, dan moet het aderes voornaam.achternaam dus ook bekend zijn op de server waar de popbox staat dan zal je mail wel binnen komen.

Geen POP connector.

[ Voor 16% gewijzigd door Jazzy op 25-06-2012 10:41 ]

[kroegtijger]

Roman schreef op maandag 25 juni 2012 @ 10:32:
Heb de gebruiker aangemaakt met AD Users and Computers (Zei al dat ik weinig met SBS gedaan heb), maar dit zier er het zelfde uit. Hierin staat idd het adres zoals die moet zijn. voornaam.achternaam.

We gebruiken geen pop connector. De mail zou direct op ip van de server binnen moeten komen. Alleen de website wordt extern gehost en het mail verkeer word vanuit daar geredirect naar de exchange server. Vreemde is dat voornaam@ wel aan komt. Voor alle andere gebruikers die reeds bestonden werkt het ook allemaal gewoon.

Waarom zou je de mail laten redirecten? Laat even je MX-record naar je eigen IP verwijzen (en zorg er uiteraard voor dat deze een hogere prio heeft dan die van je hoster), en zorg ervoor dat je op poort 25 kan telnetten naar je server toe.
via mxtoolbox.com kun je controleren of je server goed functioneert. Geef daar het commando smtp:<serveradres> en je krijgt de results of je mailserver goed werkt. Let er vooral op dat je geen open relay bent!!
Mail-verkeer naar @<jouwdomein> komt dan gewoon op je eigen mail-server binnen waar je het verder kan afhandelen. Je zou het eventueel nog via een cloud-dienst als Barracuda kunnen sturen om spam-filtering te doen nog voor het op je server binnen komt, maar dat lijkt me meer iets voor latere zorg. Kijk eerst maar of je dit werkend gaat krijgen

[kroegtijger]

Jazzy schreef op maandag 25 juni 2012 @ 10:40:

Protip: gebruik een subject als test12345 in je testmailtje. Zo kun je hem makkelijk terug vinden met message tracking.
[...]
Geen POP connector.

Dan moet je wel message tracking even aan zetten; default is dit niet het geval!

Kun je doen in Exchange Management Console in de properties van de server. Op tabblad General kun je daar Enable message tracking aanvinken. Je kan kiezen om van tijd tot tijd de logfiles op te laten ruimen. Ik zet ze zelf meestal op 30 dagen. Als users na 30 dagen nog niet hebben geklaagd, was de mail niet zo belangrijk

[wagenveld]

Voordat je MX records gaat aanpassen, als je website hoster email doorstuurt naar je Exchange server (en wellicht antispam erover heen doet) zul je waarschijnlijk daar ook een lijst met bestaande email addressen bijhouden. Kwestie van even (laten) checken of het adres wat je test ook bij hun bekend is. Zou ook verklaren waarom je geen NDR krijgt.

[Roman]

Het MX record staat zo ingesteld dat het direct naar de exchange server gaat. Daar heb ik ook niets aan veranderd. Heb even tracking aangezet en zal een kijken wat er gebeurd.

MXtoolbox.com geeft zover ik het kan zien geen fout aan. Wel geeft die telkens de IP van de hoster aan i.p.v. onze eigen ip.

[kroegtijger]

Roman schreef op maandag 25 juni 2012 @ 11:29:
Het MX record staat zo ingesteld dat het direct naar de exchange server gaat. Daar heb ik ook niets aan veranderd. Heb even tracking aangezet en zal een kijken wat er gebeurd.

MXtoolbox.com geeft zover ik het kan zien geen fout aan. Wel geeft die telkens de IP van de hoster aan i.p.v. onze eigen ip.

En welke load heeft dat MX-record? Staan er misschien meerdere mx-records?
Kun je controleren via CLI

nslookup
set type=mx
<domeinnaam>

De server met de laagste waarde van MX Preference zal als eerste worden aangesproken om mail op af te leveren. (dus de server met preference 5 zal eerst worden geprobeerd, daarna met 10 etc).

En geef je dan wel het juiste adres op ? Dus niet alleen het domein-naam, want die komt bij je hoster uit, maar hetzelfde adres als dat je mx-record is (wat dus weer naar hetzelfde zou moeten verwijzen als wat je externe IP zou moeten zijn).
je kan ook direct op je IP connecten ipv op naam; dan weet je zeker dat je je eigen server aan het testen bent ipv de server van je hoster.
Als het goed is krijg je een melding dat TLS niet functioneert. Dat is standaard op een 2003-exchange het geval. Kan je eventueel wel enablen, maar ik zou hem lekker uit laten staan. Geeft nog wel eens problemen als je het niet goed configureert en er is geen verplichting om het te enablen.

Voor de netheid kan je ook nog even bij je ISP je PTR-record laten zetten, maar ook dat zou niet essentieel hoeven zijn voor het functioneren van je server; zeker niet wat betreft het ontvangen van mail.

[ Voor 11% gewijzigd door kroegtijger op 25-06-2012 12:00 ]

[Roman]

In het log bestand zie ik dat de mail op de server aan komt, maar beland niet in de juiste mail box.

Iemand verstand van de log bestanden:

3864785CDF44422CAE07EE8EDC326A45@(company).local 0 0 1286 1 - 0 - - - info@roman(knip) -

2012-6-25 9:45:39 GMT - - - SERVER - (mail adres van ontvanger) 1028 3864785CDF44422CAE07EE8EDC326A45@(company).local 0 0 1286 1 - 0 - - - info@roman(knip) -

2012-6-25 9:45:39 GMT 127.0.0.1 (company.com) - SERVER 127.0.0.1 (mail adres van ontvanger) 1033

[Remco]

Had je nu al geverifieerd of de gebruiker wel over het juiste smtp adres beschikt?
Probeer anders even via telnet rechtstreeks op je server een email aan de gebruiker te versturen. Wellicht dat je dan wat kan met die foutmelding.

[Jazzy]

Roman schreef op maandag 25 juni 2012 @ 12:10:
In het log bestand zie ik dat de mail op de server aan komt, maar beland niet in de juiste mail box.

Iemand verstand van de log bestanden:

Volgens mij zit je nu in de protocol logs, niet in het Message Tracking Center in de Exchange System Manager, of wel?

[Roman]

Een collega heeft het opgelost. Blijkt bij deze opstelling toch iets te zijn met pop. Hij heeft bij de POP3-connection manager de gebruiker toe gevoegd. Vreemde is dat ik dezelfde opstelling op een andere locatie heb en daar hoeft dat niet.

Zou het dan toch zijn dat het MX record niet goed wordt doorgevoerd naar de server? maar waarom werkt dat voornaam@ wel en voornaam.achternaam@ niet?

[Paul]

Je hebt een POP-connector die je in moet stellen, je hebt MX-records waarvan je je afvraagt of die wel goed staan en het ene e-mailadres komt wel aan maar het andere niet?

Mag ik hier voorzichtig vragen of je überhaupt weet hoe e-mail werkt in het algemeen, en wat jullie situatie in het bijzonder is? Niet vervelend bedoeld, maar op deze manier kunnen wij er ook weinig mee.

Met de MX-records stel je in welke mailserver de mailtjes ontvangt zodra iemand een mailtje stuurt. Aangezien je het over POP-boxen hebt lijkt me dat de MX-records naar je provider wijzen? In dat geval moet je een POP-box aanmaken en daar de aliassen op instellen als je een nieuwe medewerker hebt. Vervolgens zeg je tegen de POP-connector dat deze nog een mailbox op moet halen.

Alternatief is dat je een POP-box hebt waar ALLE mail binnenkomt en dat de POP-connector deze box leegPOPt en de mail dan aflevert in de diverse mailboxen. Het is voor mij te lang geleden dat ik de POP-connector van SBS 2003 van dichtbij gezien heb om nog by heart te weten hoe je die dan instelt maar ik meen dat je daar ook wat instellingen kunt doen m.b.t. de verdeling over de mailboxen.

Heb je een mailbox in je Exchange-omgeving waar alle mail terechtkomt die de POP-connector niet in een andere mailbox kwijt kan?

[Roman]

Weet volgens mij wel hoe mail werkt, alleen heb ik geen ervaring met Exchange, heb eigenlijk alleen Novell en een beetje Notes ervaring.

Vreemde is dat ik 2 dezelfde omgevingen heb, beide gaan via hetzelfde bedrijf de buiten wereld in. In de ene omgeving heb ik bij de provider geen mailboxen aangemaakt, daar gaat alles via de exchange server. Dus de post word direct afgeleverd bij onze mail server. Op dezelfde manier is de andere omgeving ingesteld. Blijkt ook dat voornaam@ gewoon aankomt zonder hiervoor een pop verbinding en mailbox bij de provider gemaakt te hebben, maar voornaam.achternaam@ komt niet aan. Zie deze wel op de server binnen komen, maar komt dan toch in de box van de provider terecht en moet deze dan via pop trekken. En dat is iets wat ik vreemd vind.

Heb gisteren nog voor de test in de andere omgeving mijn mail-adres gewijzigd zoals ik dat geleerd heb, en dat werkt.

Dus tot zover komt het mailtje op de server aan, maar komt niet in de juiste mailbox, komt dan terug bij de provider (deze staat ingesteld als 2nd mail server, voor het geval dat de eerste uitvalt en dus ook als mail door de eerste server geweigerd word. Hiervoor moet dan idd pop worden ingesteld als daar mailboxes aangemaakt zijn.) Dus ga ik er van uit dat het MX record goed staat. Anders zou toch helemaal niets aan komen.

Dus de vraag is waar gaat het fout...

[Paul]

'Forward unresolved recipients' staat ingesteld naar de server van de provider? Ok, dan staat er bij de provider blijkbaar een catch-all POP-box die je vervolgens leegtrekt?

Staat er in dsa.msc / Active Directory Users & Computers (of in Server Management) bij je user in het tabblad 'E-mail Addresses' wel echt '[e-mail]'? Zodra dat daar bij staat zou de gebruiker e-mail die aan Exchange wordt aangeboden naar dat adres gewoon moeten ontvangen?

Wat zie je in de logs en in je telnetsessie als je handmatig een mailtje stuurt naar dat adres?

[Roman]

Eigenlijk is het een beetje anders om. De provider redirect alle mail naar de exchange server en als die een fout geeft neemt de provider het over. Dit verkeer blijkt dus wel bij de mail server aan te komen.

Ja daar staat uiteraard voornaam.achternaam en niet alleen voornaam, daarom begrijp ik niet waarom de wel de voornaam binnen komt en de voornaam.achternaam niet. Heb daar juist de voornaam@ niet in staan.

Telnet zal ik nog even testen.

[kroegtijger]

Roman schreef op dinsdag 26 juni 2012 @ 12:05:
Eigenlijk is het een beetje anders om. De provider redirect alle mail naar de exchange server en als die een fout geeft neemt de provider het over. Dit verkeer blijkt dus wel bij de mail server aan te komen.

Ja daar staat uiteraard voornaam.achternaam en niet alleen voornaam, daarom begrijp ik niet waarom de wel de voornaam binnen komt en de voornaam.achternaam niet. Heb daar juist de voornaam@ niet in staan.

Telnet zal ik nog even testen.

Als er een smtp-adres voor bestaat en mail komt eerst op je exchange binnen, dan zou het goed moeten gaan. Wat zegt je message tracking dan?

[Jazzy]

Roman schreef op dinsdag 26 juni 2012 @ 09:52:
Een collega heeft het opgelost. Blijkt bij deze opstelling toch iets te zijn met pop. Hij heeft bij de POP3-connection manager de gebruiker toe gevoegd. Vreemde is dat ik dezelfde opstelling op een andere locatie heb en daar hoeft dat niet.

Jullie MX record verwijst blijkbaar naar een POP server. SBS 2003 heeft een POP Connector die POP mailboxen leeg kan trekken en de mail vervolgens in je mailboxen kan deponeren. Dit heeft een aantal nadelen, onder andere een extra laag van beheer. Zoals je inmiddels gemerkt hebt.

[Roman]

ja kwam er idd achter dat SBS een pop extractor heeft. Was idd nieuw voor me. Maar het MX record verwijst naar het IP adres waar de exchange server achter staat. Maar toch blijkt daar iets raars fout te gaan. Intern gaat al het verkeer goed. Dus ook de telnet tests gaan goed. Denk dat ergens tussen provider die het MX verkeer door zou moeten sturen iets fout gaat. Terwijl ik het wel op de server binnen zie komen.

Ik laat het lekker via de pop extractor lopen, en ga dan even rustig uitzoeken waar het fout loopt.

En nog wat meer informatie inwinnen over SBS, blijken toch wat dingen anders te zijn dan bij een 2003 Advanced/enterprise versie.

[Jazzy]

De juiste term is POP Connector, ik zeg het even omdat dit het makkelijker maakt om relevante informatie te vinden. En als we het er toch over hebben, de versies van Exchange 2003 zijn Standard en Enterprise, niet Advanced.

[Roman]

Ok pop connector. Check.

Ja klopt bij 2000 hete dat advanced. Moet mijn kennis weer eens up to date brengen

[Jazzy]

Exchange 2013 binnenkort.

[kroegtijger]

Jazzy schreef op woensdag 27 juni 2012 @ 12:12:
Exchange 2013 binnenkort.

Als dat net zoals 2010 is, zal de POP-connector niet meer routeren naar andere mailboxen. Dan moet je dus 3rd party tools als POPcon gaan gebruiken.

[Roman]

Na.. hebben toch geen geld voor een upgrade. Hebben niet eens geld voor een 2de harddisk voor een softwareraid te maken

[Paul]

Roman schreef op woensdag 27 juni 2012 @ 09:04:
Maar het MX record verwijst naar het IP adres waar de exchange server achter staat. [..] Denk dat ergens tussen provider die het MX verkeer door zou moeten sturen iets fout gaat.

Does not compute Wijst het MX-record nu naar een A-record met _jullie_ IP-adres of naar een IP-adres dat ergens bij de provider uitkomt?

Om welk domein gaat het, dat voorkomt misschien verwarring doordat we dan zelf kunnen zien wat er in de DNS staat Dan hoeven wij heel wat minder te gokken en diverse scenario's uit te tekenen

[Jazzy]

Het MX-record met de hoogste/laagste prio kan wel naar hun externe IP verwijzen waarbij de firewall niet luistert op poort 25, er wordt dan teruggevallen op het andere MX-record waar de POP-server op luistert.

[Paul]

Uiteraard, maar een provider stuurt geen 'MX-verkeer' door. Ik kan daar wel een definitie voor verzinnen (MX-records wijzen naar provider, provider scant op spam / virussen en stuurt de mail daarna door naar de Exchange-server van de klant) maar Roman zegt juist dat het MX-record naar de Exchange-server staat.

Als dat echt het geval is dan is het niet logisch dat Exchange het adres dat bij de gebruiker in het lijstje aliassen staat niet accepteert en dat je het dan (en volgens mij is dat in deze eerder een complicerende factor, in ieder geval voor ons aan deze kant van het forum ) maar in de POP-connector regelt

[Jazzy]

Ik heb de aanname gedaan dat de TS niet helemaal kan overzien hoe de configuratie werkt, hij heeft het over meedere MX records en ziet daar het IP-adres van hun ADSL/modem/firewall en ook van hun 'website'. Die laatste zal dan de ISP zijn waarbij voor iedere gebruiker een POP box is aangemaakt.

Dat verklaart waarom de collega nog 'iets met POP' moest doen, hij heeft het extra mailadres toegevoegd op de POP server van de ISP. Tenminste, dat is wat ik er van maak.

[Roman]

Het is een rare opstelling hier. Iig verwijst het MS record met de hoogste prio naar een A-record die weer verwijst naar het IP van de exchange, of beter gezegd naar het externe IP van de DSL aansluiting waar de exchange server achter staat. Mail verkeer gaat ook door. Blijkt dus daaraan dat als ik met voornaam@ stuur het wel aan komt en met voornaam.achtermnaam niet.

Als nu helemaal niets aan zou komen zou ik idd zeggen er gaat ergens wat met de communicatie fout. Maar aangezien de ene wel aan komen en de andere niet weet ik niet direct waar ik dit zou moeten zoeken.

Iig staat de SMTP naam in het user object op voornaam.achternaam en alleen voornaam heb ik eruit gehaald. En toch komt het aan. Heb wel het userobject zelf op alleen voornaam staan (maakt het inloggen wat makkelijker), alias is dan weer voornaam.achternaam.

En ISP is uiteraard een Business aansluiting zodat port 25 en 110 nergens geblokkeerd word. Versturen gaat uiteraard prima. URL wordt dan weer door een ander bedrijf gehost (strato.de).

[Jazzy]

Kun je anders de domeinnaam eens geven? Mag ook per PB als je dat prettiger vind.

Kan zijn dat ik het even gemist heb, maar had je nu de 'probleemmail' al getraceerd met Message Tracking? Dat geeft je wellicht iets meer inzicht in de mailflow.

[Paul]

Jazzy schreef op donderdag 28 juni 2012 @ 08:48:
Ik heb de aanname gedaan dat de TS niet helemaal kan overzien hoe de configuratie werkt

Idem Alleen had ik de mail-flow anders in mijn hoofd (meer zoals er nu ook weer [na jouw reactie] is opgeschreven). Zo zie je maar dat het nog best lastig is om het simpel allemaal op te schrijven.

@Roman, inderdaad zou de domeinnaam helpen (eventueel per PM inderdaad als je die liever niet wereldkundig koppelt aan je GoT-nick).

Aangezien het via POP wel binnenkomt neem ik dan aan dat Exchange ingesteld staat om unresolved recipients door te sturen (een backup MX-record wordt niets gevraagd als de eerste reageert dat het e-mailadres niet bekend is)?

'De SMTP-naam in het user object', is dat het veld 'E-mail' op het tabblad 'General' of bedoel je daarmee het Primary SMTP Address op het tabblad 'E-mail Addresses'? Hoeveel / welke entry's staan er op dat tabblad?

Edit: @ Kroegtijger: Uiteraard, maar hij heeft het over 'de', niet één van de Ik probeer gewoon zoveel mogelijk informatie van de TS te krijgen, pas daarna (na diagnose) kunnen we kijken wat de oplossing is

[ Voor 10% gewijzigd door Paul op 28-06-2012 10:08 ]

[kroegtijger]

Paul schreef op donderdag 28 juni 2012 @ 09:57:
[...]
'De SMTP-naam in het user object', is dat het veld 'E-mail' op het tabblad 'General' of bedoel je daarmee het Primary SMTP Address op het tabblad 'E-mail Addresses'? Hoeveel / welke entry's staan er op dat tabblad?

Hoeft niet per sé het primary SMTP Address te zijn. Primary is hetgeen waar je mee uitstuurt, maar met de rest kan je ook ontvangen.
TS kan ook nog even kijken of de RUS wel loopt; anders kun je adressen toevoegen wat je wilt, maar als er niets wordt bijgewerkt houd het op

[Roman]

Ik pm jullie 2 even het url. (/edit kan tijger geen PM sturen)

probleem is dat ik het niet opgezet heb maar over genomen. En ik ging er eigenlijk vanuit dat beide locaties hetzelfde zouden zijn. Zoals gezegd doet de ene het zonder problemen en de andere niet.

Met SMTP adres bedoel ik idd dat bij Mail-Adressen. Bij General is gewoon haar 1e mail adres ingevuld en bij Mail-adresses staat deze ook en nog 2 andere. Er van uitgaande dat ze op deze 3 adressen kan ontvangen en met het adres in general verstuurd. Dan vind het vreemd dat ze mail ontvangen die juist niet een van deze 3 adressen is.

Wat is RUS? (even voor de onduidelijkheid, zit hier op een Duitse SBS.... zoek me te pletter naar de juiste functies)

[Paul]

Als ik het opzoek dan heb je één MX-record en die loopt naar de provider.

Je provider ontvangt de mail en gooit het waarschijnlijk linea recta in de POP-box die je met de POP-connector ophaalt. Geen enkele instelling in Exchange (behalve bij de POP-connector) zal dus doorgevoerd worden lijkt me.

De reden dat de voornaam wel werkte zonder aanpassingen is dat de POP-connector standaard al naar accountnamen kijkt en die kwam overeen.

Kun je loggen (op de firewall) of er überhaupt inbound verkeer naar poort 25 is?

RUS is Recipient Update Service, het stukje dat er voor zorgt dat de e-mailadressen van accounts automatisch worden aangemaakt; daar is ook dat vinkje onderaan de lijst voor, daarmee kun je dat uitzetten voor dat account.

[ Voor 17% gewijzigd door Paul op 28-06-2012 13:20 ]

[Roman]

Als ik het goed begrepen heb van mijn collega gaat die eerst naar de provider van daaruit direct door naar de exchange server. En als de exchange hem weigert gaat die terug naar de provider om hem dan in een pop box te probben als die er is. Als er daar geen pop box is krijg ik een NDR terug gestuurd.

Op de server zie ik in de logs (zoals op de vorige pagina) dat de mail binnen komt maar ergens niet goed wordt doorgevoerd.

Wat ik nog zou kunnen is bij het MX record het directe IP invullen. Maar als ik de mail. URL ping krijg ik het IP van de exchange server.

/edit RUS, ok. Heb dat vinkje bij de eerste keer wel aan staan gehad, dan een keer uit en nu weer aan. Zonder verschil.

[ Voor 9% gewijzigd door Roman op 28-06-2012 13:27 ]

[kroegtijger]

Je kan de RUS ook forceren door met rechts in de management console erop te klikken.
En mn PM is nu ingeschakeld

[ Voor 65% gewijzigd door kroegtijger op 28-06-2012 13:40 ]

[Paul]

Roman schreef op donderdag 28 juni 2012 @ 13:26:
Als ik het goed begrepen heb van mijn collega gaat die eerst naar de provider van daaruit direct door naar de exchange server. En als de exchange hem weigert gaat die terug naar de provider om hem dan in een pop box te probben als die er is. Als er daar geen pop box is krijg ik een NDR terug gestuurd.

Ah zo, dat kan, dat doen wij ook (nadat het is gecheckt op spam en virussen, al gaat het bij ons niet naar een POP-box als het niet op Exchange bestaat).

Je ziet echt mailtjes (ook naar het bewuste adres) binnenkomen via de firewall naar Exchange, terug naar de provider en dan via POP weer naar binnen?

Op de server zie ik in de logs (zoals op de vorige pagina) dat de mail binnen komt maar ergens niet goed wordt doorgevoerd.

Ik heb pas één pagina Roman in "(exch 2003) nieuwe gebruiker krijgt geen mail, wel intern"

Welk logbestand is dat?

Wat ik nog zou kunnen is bij het MX record het directe IP invullen. Maar als ik de mail. URL ping krijg ik het IP van de exchange server.

Vanwaar die 'maar'? Nergens in de MX-lookup (zie je DM) zie je mail.roman(knip) terug, dat is ergens een instelling bij je provider.

[Roman]

Hey ik heb de rus gevonden... Heet hier Empfängeraktualisierungsdienste Weer wat geleerd ...

Die had ik idd geactualiseerd toen ik bezig was.

het log was die van exchange zelf, niet van de firewall. Weet alleen even niet welk log, maar er stond excat op het tijdstip dat ik de mail verstuurde (uiteraard van extern) een entery in met het exacte mail adres van de ontvanger erin. Zie een paar post eerder.

[ Voor 47% gewijzigd door Roman op 28-06-2012 15:40 ]

[Jazzy]

Roman schreef op donderdag 28 juni 2012 @ 15:36:
het log was die van exchange zelf, niet van de firewall. Weet alleen even niet welk log,

Ik heb al eerder gezegd dat dit protocol logging is en dat je beter Message Tracking kunt gebruiken. Als je niet weet wat dat is, gooi de termen dan even in Google. Ik zeg het niet voor niets.

[kroegtijger]

Jazzy schreef op donderdag 28 juni 2012 @ 16:33:
[...]
Ik heb al eerder gezegd dat dit protocol logging is en dat je beter Message Tracking kunt gebruiken. Als je niet weet wat dat is, gooi de termen dan even in Google. Ik zeg het niet voor niets.

Hint: Het is een tool
Uiteraard moet je dan message tracking wel enabled hebben staan, maar dat heb ik hierboven al eerder beschreven hoe dat gaat in 2003 volgens mij