Exchange: mailtjes in queue

[Nadir]

Beste forumleden,

Op mijn werk ziet de netwerkconfiguratie er globaal zo uit:
Meerdere domeincontrollers, een isa-server die toegang tot internet regelt en een exchange server voor de mail.
inbound mail komt binnen op de isa server die de mail doorstuurt naar een 'barracude spam firewall 300' en die stuurt de goedgekeurde mail weer door naar onze exchange server.
Outbound mail wordt door exchange via de isa-server naar internet gestuurd (dus barracuda is alleen voor inbound mail)

Nu het probleem:
- Soms krijg ik een klacht dat mensen mail naar een bestaand email adres sturen en dan meteen een NDR (Non Delevery Report) krijgen met de melding: U beschikt niet over de juiste machtigingen om e-mail naar deze geadresseerde te verzenden. Neem contact op met de systeembeheerder voor meer informatie < exchange.domeinnaam.nl #5.7.1 smtp; 550 5.7.1 Unable to relay for email@adres.nl >
Vaak lukt het de volgende dag om zonder problemen mail naar hetzelfde email adres te sturen. Het probleem doet zich dus willekeurig voor. Een heel enkele keer gebeurt dit zelfs voor interne email adressen.
- Bij Exchange System Manager zie ik bij Queues een handjevol mails staan die soms enkele uren in de queue blijven staan met diverse retry's. Ook hier betreft het mailtjes aan met zekerheid wèl bestaande email adressen. Vaak is ´s morgens vroeg de queue weer helemaal leeg. Er worden honderden mails per dag verstuurd en in de queue staan maar enkele mailtjes met retry´s (misschien 10 tot 20 mailtjes, meer niet)

De mails kunnen gevolgd worden in het Tracking Centre, maar daar zie ik weinig bijzonders. Bij NDR mails staat alleen in de laatste regel dat er een NDR gegenereerd is, verder volgde het mailtje de normale route.

Waar ik zelf aan gedacht heb:
- Sommige spam filters traceren mail terug via MX record om te zien of afzender bestaat. Zou een conflict mogelijk zijn omdat inbound mail door barracuda afgehandeld word en outbound afkomstig is van onze exchange server? Met andere woorden: De mail is van een andere server afkomstig dan de route naar het reply adres... (hoewel het pas ná de isa server een andere route volgt.)
- Of zou het misschien een configuratiefoutje zijn in onze DNS? Dit omdat exchange blijkbaar enkele mailtjes niet uit zijn queue verzonden krijgt. Alleen zou ik dit wel vreemd vinden omdat het maar af en toe en willekeurig fout gaat.

Wie zou mij een aanwijzing kunnen geven waar ik naar kan zoeken om de oorzaak van dit probleem te vinden? Ik zou bijzonder blij zijn met een oplossing voor dit probleem.

 

[dvanleur]

Wordt de ISA server als Smarthost gebruikt of alleen als route naar het internet toe?

 

[Nadir]

Nee, de isa fungeert niet als smarthost.

 

[dvanleur]

Als je mailtje verstuurd naar buiten toe weet je ook wat in de mailheader staat als verstuurde server adres en naam?

 

[Nadir]

Ja, inderdaad.
Maar in de meeste gevallen komt de mail ook op een juiste manier aan. Het maakt het zo ingewikkeld dat het probleem niet reproduceerbaar is, omdat het alleen af en toe mis gaat. Ik verwacht dan ook niet dat ik configuratiefouten uit de mailheader kan halen...
Of begrijp ik jou verkeerd wat ik uit die header op kan maken?

In de header zie ik inderdaad dat de mail vanaf onze exchange server komt. Het IP adres is vanaf internet wel hetzelfde dan de barracuda box, die dus alle inbound mail opvangt. Intern op het netwerk heeft de barracuda natuurlijk wel een ander IP adres; en natuurlijk een andere naam dan de exchange server.

 

[dvanleur]

Waar ik aan zit te denken is dat de exchange server niet de juiste naam meegeeft met het versturen.

Waar je naar kunt kijken is wat de naam is van jullie server in een mail header (bv mail.xxxxx.xx) daarna kun je kijken wat je krijgt te zien als je een nslookup doet van het ip adres dat gebruikt wordt voor het versturen.

 

[Nadir]

Omdat er al een tijdje geen activiteit is in dit draadje, wil ik graag even aangeven hoe het nu met het probleem staat.
- Het bleek dat de inheritable permissions niet goed stonden. Met andere woorden, de permissies werden niet naar onderliggende child objecten doorgegeven: (Exchange System Manager | rechtsklik | Secury | Advance | Vinkje aan bij: allow inheritable permissions from the parent to propagate to this object and all child objects.)
Hierna bleven bepaalde mailtjes niet meer (lang) in de queue hangen.
- Het probleem met de NDR's hebben we nog steeds. Bij een check met ons eigen domein bij mxlookup tool geeft aan dat de reverse dns niet helemaal goed staat. Helaas kan ik dit niet zelf in de dns editor instellen, maar moet een verzoek naar de provider gestuurd worden om dit op te lossen. (Om het nog wat lastiger te maken, bleken we al een tijdje terug voor bepaalde ip adressen gebruik te maken van een andere provider, maar de dns stond nog altijd bij de vorige provider ingesteld te staan. Om dit te verhuizen, zal DNS tot maximaal twee dagen niet goed naar ons IP-adres verwijzen.)
Hopelijk wordt het NDR probleem opgelost als we dit goed doorgevoerd hebben.

Ik zal dit draadje op opgelost zetten, er vanuit gaande dat de reverse dns inderdaad de oorzaak is.

dvanleur: Hartelijk dank voor het meedenken!

 

[dnties]

Nadir,

1. Graag nog de eerste paragraaf afmaken: Wáár in de System Manager gebruik je de rechter muisknop?
2. Bij de 2de paragraaf lijk je te vermelden dat je een SMTP-connector had ingesteld staan die voor bepaalde e-maildomeinen een 'smart host' van een andere provider gebruikte dan standaard.
Vraag jezelf eens af of je niet gebruik kunt maken van een smart host van de huidige provider om al je mail over te versturen? (meestal in de vorm van smtp.providernaam.nl of mail.providernaam.nl). Je bent dan ook van reverse dns-problemen af.
Let ook op dat je als reverse dns niet iets laat instellen als 123-456-234-456-providernaam.nl, maar een 'echte' naam, zoals mail.mijndomein.nl (er zijn mailservers die de eerste vorm beschouwen als een dynamisch ip-adres, ook al is het een gewoon zakelijk, niet wisselend ip-adres).

Daarnaast is het altijd een goed idee om mailservers waar onverwachte NDR's vandaan komen even te bezoeken met een Telnet <smtp-server> 25
en daar een mailsessie mee te starten. Hoe, kijk even hier, en bedenk dat typefouten niet met Backspace te verbeteren zijn.
Met zo'n telnet sessie weet je ook of bijv. Greylisting bij de andere partij van toepassing is (oftewel: In eerste instantie wordt geen mail-sessie toegestaan, maar een half uur (of welke termijn ook) later wel vanaf hetzelfde ip-adres. Dit is een anti-spam maatregel).

Succes,

Tijs.

 

[Nadir]

Allereerst excuses voor mijn late reactie...

1 - in de system manager ging ik via First Organisation | Servers | [Servernaam] | First Storage Group.
Hieronder hebben wij 3 verschillende mailbox store's. Ik bedoelde een rechtsklik op die mailbox store's en dan via 'Properties' het tabblad security.
Ik was inderdaad nogal onduidelijk bij mijn uitleg.
2 - Ik sprak van een dns-check door onze eigen exchange in te vullen op http://www.mxtoolbox.com/ - Deze tool gaf aan dat onze reverse dns niet goed stond.
Reverse DNS staat inmiddels goed. Hiervoor heb ik wat administratieve wijzigingen moeten doorvoeren. Dit had te maken dat we aansluitingen bij meerdere providers hebben en domeinnaam bij nog eens een derde. Vandaar mijn verwarrende verhaal, waardoor jij op het verkeerde been werd gezet en waarschijnlijk daardoor veronderstelde dat we van een smart host gebruik maken.

Het lijkt erop dat de oplossing uiteindelijk in het goedzetten van de reverse dns gezocht moest worden.

De reden en werking van greylisting is mij nog niet helemaal duidelijk; ik zal er eens op 'googlen'.

en Tijs: bedankt voor je reactie.

Nadir.

 

[dnties]

Geen probleem!

Wat ik nog bedoelde is dat je het probleem met reverse dns had kunnen oplossen door alle mail te sturen via een smart host van de provider (zoals smtp.bbned.nl, smtp.xs4all.nl, mail.home.nl etc.)

Dat het nu goed werkt is goed nieuws! Reverse DNS moet goed staan (zoals je gemerkt hebt), anders kun je inderdaad tegen 'weigerachtige' mailservers aanlopen.

Verdere reacties niet nodig. Bedankt voor je terugmeldingen.

Tijs.