Vreemd mail probleem

[raymondkrah]

Ik heb hier een de volgende software combinatie:

Centos 4.6
APF Firewall + BFD
Exim 4.69
Directadmin 1.31.5

Met de volgende DNS config voor het domein:


Nu kunnen wij helaas maar een deel van onze mail ontvangen en een deel niet.
De niet ontvangen berichten worden met meldingen beantwoord dat de bezorging van de email vertraagd is.
Nu hebben wij hier verder gezocht naar het probleem en hebben moeten ervaren dat bijna iedereen die deze fouten krijgt en ons niet kan mailen gebruik maakt van een Microsoft Exchange Server 2003 / 2007 versie.

En het volgende komt er constant uit bij het DNS Reporten op www.dnscolos.com:
Failed Mailserver connection test
HELO, MAIL FROM, RCPT TO, QUIT Connect to mailserver mail.wesensit.com FAILED (could be greylisting)

Ook de configs zijn al 10x gecontroleerd maar er kan geen enkele fout gevonden worden ?

heeft misschien hier iemand een idee wat dit kan zijn of wat we hier aan kunnen doen ?

Edit:
Ik was vergeten erbij te vermelden dat er ook geen entries in de log file van mail server gedaan wordt over het ontvangen of weigeren van deze niet aankomende emails

[ Voor 7% gewijzigd door raymondkrah op 01-07-2008 10:00 ]

[CyBeR]

Dit soort dingen zijn niet te controleren zonder informatie over om welke domeinnaam 't gaat, welke server, en wat er in de logs komt.

[gertvdijk]

• Is Exim running?
• Poort 25 open?
• Kan je telnetten naar poort 25 en kan je een mail versturen daarmee?
• Wordt het betreffende domein geaccepteerd in Exim? (test Exim met exim4 -bt [e-mail])

[ Voor 28% gewijzigd door gertvdijk op 01-07-2008 10:13 ]

[raymondkrah]

Het gaat hierbij om een Dell Poweredge 1950 met volgende specs:
Intel(R) Pentium(R) D CPU 3.20GHz
2 GB Geheugen
500 GB Sata 2 HDD

Hij draait op het virtu netwerk.

En bij dit probleem gaat het vooral om het domein: wesensit.nl

En in de logfiles van de server worden alleen entries gemaakt voor de wel aankomende mails bij ons en niet van die emails die niet bij ons aankomen vreemd genoeg.
En ook in de rejectlog, processlog en paniclog is geen spoor van die niet aankomende mails te vinden.

[raymondkrah]

Bedankt voor je reply gertvdijk.

Ja ik kan emailen via telnet over poort 25.
Ook de extra poort 587 staat open als extra SMTP poort.

exim -bt *********@hccnet.nl
*********@hccnet.nl
router = lookuphost, transport = remote_smtp
host hcc1.schonemail.nl [80.253.112.47] MX=20

En bij het domein van 1 van de servers die niet kan mailen naar ons krijg ik ook ongeveer zoon uitkomst als hierboven.

Maar dit lijkt me niet echt het probleem te zijn omdat emails van andere servers wel gewoon aankomen die bijvoorbeeld ook exim, sendmail, etc... gebruiken. Maar niet van bijvoorbeeld een Exchange Server ofzo

[ Voor 71% gewijzigd door raymondkrah op 01-07-2008 10:18 ]

[gertvdijk]

raymondkrah schreef op dinsdag 01 juli 2008 @ 10:10:
Maar dit lijkt me niet echt het probleem te zijn omdat emails van andere servers wel gewoon aankomen die bijvoorbeeld ook exim, sendmail, etc... gebruiken. Maar niet van bijvoorbeeld een Exchange Server ofzo

Bedoel je interne mailservers?
Tja, die zijn dan toegelaten als relay machine op basis van zijn ip, lijkt mij.

En als je via telnet wel mail kan afleveren, maar met een mailserver van buitenaf wordt het geweigerd zou je nog eens kunnen kijken of het mis gaat in de TLS laag (ESMTP). Maar dat zou je allemaal moeten kunnen zie in je logs.
Als je echt niets ziet daarin zal je moeten kijken of het op het niveau van het OS/firewall niet al misgaat. Daarvoor is een log vanaf een machine vanwaar het niet lukt wel erg handig.

raymondkrah schreef op dinsdag 01 juli 2008 @ 10:10:
exim -bt *********@hccnet.nl
*********@hccnet.nl
router = lookuphost, transport = remote_smtp
host hcc1.schonemail.nl [80.253.112.47] MX=20

En bij het domein van 1 van de servers die niet kan mailen naar ons krijg ik ook ongeveer zoon uitkomst als hierboven.

Ja, een hccnet.nl mail moet naar buiten, die moet niet lokaal worden bezorgd neem ik aan.
Het ging mij om je eigen domein. Die moet lokaal worden afgeleverd natuurlijk.

[ Voor 24% gewijzigd door gertvdijk op 01-07-2008 10:22 ]

[Anoniem: 85345]

Tja... eigenlijk moet je de headers hebben van een van de mails die dan gebounced is door je server, misschien kun je die vragen aan iemand die de bounce mail terug krijgt.

Ik kan gewoon mailen naar je domein, echter heb ik geen exchange tot mijn beschikking alleen maar unix hier:

Vanaf het ip waar ik dit op geprobeerd heb klopt de reverse dns ook nog eens niet, dus daar checked je server ook niet eens op... daar kan het dus ook niet aan liggen.

code:

macbook:~ mark$ telnet wesensit.nl 25
Trying 87.249.115.114...
Connected to wesensit.nl.
Escape character is '^]'.
220 server.wesensit.nl ESMTP Exim 4.69 Tue, 01 Jul 2008 10:02:33 +0200
HELO xs4all.nl
250 server.wesensit.nl Hello xs4all.nl [194.151.188.250]
MAIL FROM: <[e-mail]>
250 OK
RCPT TO: <[e-mail]>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
test
.
250 OK id=1KDapX-0005yZ-3l
quit
221 server.wesensit.nl closing connection
Connection closed by foreign host.

[DJSmiley]

offtopic:
Misschien een idee om je DNS te splitsen, volgens mij draai je zowel ns1 als 2 op dezelfde doos. Doos down is dus volledig onbereikbaar en direct bouncen van op dat moment gestuurde mails

[raymondkrah]

Ehm bedankt voor je reply dit zou kunnen ja.
Ik zal het nogmaals gaan controleren.

Maar even ter voor de duidelijkheid. Alle servers die email naar ons toe zenden zijn externe server ook die Exchange is van een van onze klanten en waarvan we dus geen mail ontvangen.

[raymondkrah]

Ja het gaat om 1 server die beide ns records draait.
Maar het vreemde is dat ik persoonlijk ook nog ongeveer zoon systeem heb draaien en deze geeft niet deze problemen.
Dus heb ik ook al met die server erbij de mailserver configs, dns configs en firewall configs gechecked maar dat bleek allemaal wel in orde en toch blijft de wesensit.nl deze fout maken

[gertvdijk]

raymondkrah schreef op dinsdag 01 juli 2008 @ 10:25:
Maar even ter voor de duidelijkheid. Alle servers die email naar ons toe zenden zijn externe server ook die Exchange is van een van onze klanten en waarvan we dus geen mail ontvangen.

Heb je Exim gecompileerd met de discriminateMS option?

Zou je even wat kunnen posten van de logs van een Exchange server? Dat lijkt me dan wel interessant worden.
Welke DNSBL heb je in gebruik? (als je dat gebruikt)

[ Voor 18% gewijzigd door gertvdijk op 01-07-2008 10:32 ]

[raymondkrah]

haha nee maar het lijkt wel zoiets als die optie zal bestaan ja

[remco_k]

raymondkrah schreef op dinsdag 01 juli 2008 @ 09:58:
...
En het volgende komt er constant uit bij het DNS Reporten op www.dnscolos.com:
Failed Mailserver connection test
HELO, MAIL FROM, RCPT TO, QUIT Connect to mailserver mail.wesensit.com FAILED (could be greylisting)

en

raymondkrah schreef op dinsdag 01 juli 2008 @ 10:08:
En bij dit probleem gaat het vooral om het domein: wesensit.nl

Ligt het aan mij of zie ik een verschil tussen .com en .nl ?

Denk ook even aan de greylisting, maar gezien de andere reakties die wel kunnen mailen lijkt me dat niet.

[raymondkrah]

ehm oke nee beide adressen moeten eigenlijk .nl zijn.

Hier dan nog even dezezelfde test restultaten ven het .nl domein.
Failed Mailserver connection test
HELO, MAIL FROM, RCPT TO, QUIT Connect to mailserver mail.wesensit.nl FAILED (could be greylisting)

[gertvdijk]

remco_k schreef op dinsdag 01 juli 2008 @ 10:33:
Ligt het aan mij of zie ik een verschil tussen .com en .nl ?

Scherp.
Maar:

$ host -t a mail.wesensit.com
mail.wesensit.com   	A	87.249.115.114
$ host -t a wesensit.nl
wesensit.nl         	A	87.249.115.114
$ host -t mx wesensit.nl
wesensit.nl         	MX	10 mail.wesensit.nl
$ host -t a mail.wesensit.nl
mail.wesensit.nl    	A	87.249.115.114

Is dus allemaal 1 en dezelfde server.

Maar omdat het van zo'n grote test site en Exchange servers niet lukt... is het misschien een onterechte DNS BlackListing.

[ Voor 10% gewijzigd door gertvdijk op 01-07-2008 10:39 ]

[raymondkrah]

ja omdat er maar 1 server draait.
maar dit mag dacht ik niet het probleem zijn aangezien er veel meer servers zo draaien zonder dit soort van problemen

[raymondkrah]

De volgende blacklists heb ik nu gecontroleerd:
dsn.rfc-ignorant.org
zen.spamhaus.org
dul.dnsbl.sorbs.net
bl.spamcop.net

in geen 1 van deze staat een record voor deze server.
Tevens heb ik de klant een mail laten sturen naar een andere server die ook een soort gelijke config heeft en ook alles op 1 server draait en hierop komen de emails zonder problemen aan.

[Anoniem: 85345]

Diegene die jou probeert te mailen, krijgt toch een bounce mail terug... zorg er nou eens voor dat je van diegene de headers van die bounce mail krijgt... dan weet je gewoon veel meer.

[gertvdijk]

raymondkrah schreef op dinsdag 01 juli 2008 @ 10:57:
De volgende blacklists heb ik nu gecontroleerd:
dsn.rfc-ignorant.org
zen.spamhaus.org
dul.dnsbl.sorbs.net
bl.spamcop.net

in geen 1 van deze staat een record voor deze server.
Tevens heb ik de klant een mail laten sturen naar een andere server die ook een soort gelijke config heeft en ook alles op 1 server draait en hierop komen de emails zonder problemen aan.

Je moet de blacklist controleren die jij gebruikt natuurlijk.
En je controleert dan niet je server adres, maar die van de remote server die faalt mail af te leveren op de jouwe.

Anoniem: 85345 schreef op dinsdag 01 juli 2008 @ 10:59:
Diegene die jou probeert te mailen, krijgt toch een bounce mail terug... zorg er nou eens voor dat je van diegene de headers van die bounce mail krijgt... dan weet je gewoon veel meer.

Als je alles bounct heb je geen nette config imo. Mail rejecten voordat het wordt geaccepteerd kan prima met het SMTP protocol (je kan de hele e-mail checken voordat je hem accept, precies zoals een post-check zou gaan). De afzender krijgt alleen een mail van zijn versturende mailserver dat de afleverpoging mislukt. Spambots doen dit natuurlijk niet en zo krijg je geen ellendige joejob bounces van mails die je nooit hebt gestuurd.

[ Voor 35% gewijzigd door gertvdijk op 01-07-2008 11:06 ]

[raymondkrah]

Ja oke ik heb even gecontroleerd of het externe domein van de klant geblacklist staat maar dat is dus ook niet het geval.

Ook heb ik nu een mailtje doorgestuurd gekregen met de email die de Exchange server naar de gebruiker terug geeft:

woensdag 25 juni 2008

De bezorging van uw bericht bij de volgende geadresseerden of distributielijsten is vertraagd:

*****@wesensit.nl

Onderwerp: RE: digitaal

Het bericht is nog niet bezorgd. Er wordt nog altijd geprobeerd het bericht namens u te bezorgen.

Er wordt geprobeerd dit bericht te bezorgen tot 27-6-2008 7:58:11 (GMT+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen. U ontvangt een melding als het bericht niet voor die tijd kan worden bezorgd.

_____
Verzonden door Microsoft Exchange Server 2007

[Anoniem: 85345]

Als je alles bounct heb je geen nette config imo. Mail rejecten voordat het wordt geaccepteerd kan prima met het SMTP protocol (je kan de hele e-mail checken voordat je hem accept, precies zoals een post-check zou gaan). De afzender krijgt alleen een mail van zijn versturende mailserver dat de afleverpoging mislukt.

Het gaat er toch niet om hoe net de config is in dit verhaal. Ik zeg toch ook niet dat zijn server alles bounced (dat kan ik helemaal niet weten)... Feit is nog steeds dat je meer informatie hebt wanneer je de headers kan bekijken van een bouncemail, ongeacht welke server de mail heeft gebounced.

In de BODY vd bouncemail staat idd alleen maar dat de aflever poging is mislukt... Daarom vroeg ik ook aan hem om de HEADERS te checken, hierin staat nl. ook de reden van de mislukte aflever poging.

Spambots doen dit natuurlijk niet en zo krijg je geen ellendige joejob bounces van mails die je nooit hebt gestuurd.

Je bedoelt "backscatter", hier kan je genoeg tegen doen... Ik snap niet psies wat je hier mee wilt zeggen. Het gaat in deze post ook niet over wat te doen tegen backscatter, Volgens mij heb ik echt eerder gelezen in dit topic dat de afzenders een bounce mail krijgen, het lijkt mij toch echt handig dat hij daarvan de headers probeerd te krijgen.

[Anoniem: 85345]

Ook heb ik nu een mailtje doorgestuurd gekregen met de email die de Exchange server naar de gebruiker terug geeft:

woensdag 25 juni 2008

De bezorging van uw bericht bij de volgende geadresseerden of distributielijsten is vertraagd:

*****@wesensit.nl

Onderwerp: RE: digitaal

Het bericht is nog niet bezorgd. Er wordt nog altijd geprobeerd het bericht namens u te bezorgen.

Er wordt geprobeerd dit bericht te bezorgen tot 27-6-2008 7:58:11 (GMT+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen. U ontvangt een melding als het bericht niet voor die tijd kan worden bezorgd.

_____
Verzonden door Microsoft Exchange Server 2007

Aan de BODY van de email heb je niks... Vraag een kopie van de HEADERS!!!

[gertvdijk]

Ik zie denk ik een probleem in je DNS config.
Je hebt helemaal geen goed MX record! Achter het getal 10 moet nog het adres (met punt) en het gaat natuurlijk niet alleen om je subdomein mail.

wesensit.nl.	MX	10 mail.wesensit.nl.
mail	A	<je ip>

Dit kan het platformspecifieke in dit verhaal natuurlijk wel verklaren. Als de Microsoft software minder fail-safe is voor deze DNS config fout gaat het natuurlijk mis.

[ Voor 70% gewijzigd door gertvdijk op 01-07-2008 12:06 ]

[raymondkrah]

hierbij de headers

MIME-Version: 1.0
From: <[e-mail]>
To: <[e-mail]>
Date: Mon, 23 Jun 2008 17:35:18 +0200
Content-Type: multipart/report; report-type=delivery-status;
boundary="03786a29-8c60-4b2e-bf6b-de85fabc367a"
X-MS-Exchange-Organization-SCL: -1
Content-Language: nl-NL
Message-ID: <3d1e32e6-8db8-4090-b9fc-210990d9c22a>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
<[e-mail]>
Thread-Topic: test
Thread-Index: AcjU+V2t+zOhsQTJRjSDWqfSsqn1+gAKwDEQAAiXz00=
Subject: Bezorging vertraagd: RE: test
X-TM-AS-Product-Ver: SMEX-8.1.0.1092-5.500.1027-15990.000
X-TM-AS-Result: No-22.416400-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No

domein naam is vervangen voor domain.

[gertvdijk]

raymondkrah schreef op dinsdag 01 juli 2008 @ 12:16:
hierbij de headers

Hier ga je niet veel aan kunnen zien. Zoek eens in de logs van die Exchange machine. Waarschijnlijk zie je ergens staan dat een DNS lookup failed of dat er geen MX record beschikbaar is. En anders dat er iets in de SMTP connectie misgaat. In elk geval iets.

[raymondkrah]

Oke bedankt voor al jullie tips die hebben ons de oplossing stukken dichter bij gebracht doordat wij punt voor punt konden afhaken wat het zekers niet kon zijn.

Uit eindelijk heb ik hier een config option genaamd smtp_enforce_sync toegevoegd aan de exim configuratie. Deze zorgt ervoor dat er geen synchrone verbindingen worden gemaakt waarvoor de server een goed extern domein op moet geven wat dus een " Microsoft Exchange" server vaak niet doet omdat het nogal vaak voorkomt dat deze hun interne domein door sturen naar de SMTP server.

De optie smtp_enforce_sync heb ik dus toegevoegd in de exim.conf met de waarde false (smtp_enforce_sync = false) zodat de SMTP server niet meer het IP aanhand van het externe domein gaat opsporen en zo kan de exim de verbinding niet meet droppen van wege een verkeerd domein / ip maar ontvangt de emails gewoon.

Mja ze waren hier ook blij hebben ze genoeg te lezen van een paar weken

En nogmaals bedankt voor jullie tips en hulp

Edit:

Ik constateer dus nu ook dat deze fout:

Failed Mailserver connection test
HELO, MAIL FROM, RCPT TO, QUIT Connect to mailserver mail.wesensit.nl FAILED (could be greylisting)

tevens opgelost is en nu de volgende output geeft:

Pass Mailserver connection test
HELO, MAIL FROM, RCPT TO, QUIT Connect to mailserver mail.wesensit.nl Success
250 Accepted

[ Voor 16% gewijzigd door raymondkrah op 01-07-2008 14:56 ]

[gertvdijk]

raymondkrah schreef op dinsdag 01 juli 2008 @ 13:35:
Deze zorgt ervoor dat er geen synchrone verbindingen worden gemaakt waarvoor de server een goed extern domein op moet geven ...

In de RFC van het SMTP protocol wordt beschreven dat de commando's altijd synchroon moeten zijn.

Replies to SMTP commands serve to ensure the synchronization of
requests and actions in the process of mail transfer and to guarantee
that the SMTP client always knows the state of the SMTP server.
Every command MUST generate exactly one reply.

Dan zouden alle default configs van MS Exchange + Exim dan niet met elkaar kunnen communiceren, omdat de waarde van smtp_enforce_sync default true is (zie doc).
En als werkelijk je probleem in het niet synchroon communiceren van de MS Exchange server zit dan zou je dit altijd terug moeten zien in de logs van Exim. Spambots doen dit vaak en ik zie het dan ook in de logs terug. Alle drops van Exim zie je terug.

code:

2008-03-05 17:22:58 SMTP protocol synchronization error (next input sent too soon: pipelining was advertised): rejected "" H=87.68.22.114.cable.012.net.il (c1222fb62dc9402) [87.68.22.114] next input="\r\n------=_NextPart_000_0007_01C87FB6.39C44A80\r\nContent-Type: text/html;\r\n ch"

Volgende de Exim documentatie doet de optie smtp_enforce_sync dan ook heel wat anders dan wat jij ons vertelt:

raymondkrah schreef op dinsdag 01 juli 2008 @ 13:35:
Deze zorgt ervoor dat er geen synchrone verbindingen worden gemaakt waarvoor de server een goed extern domein op moet geven wat dus een " Microsoft Exchange" server vaak niet doet omdat het nogal vaak voorkomt dat deze hun interne domein door sturen naar de SMTP server.
[...]
zodat de SMTP server niet meer het IP aanhand van het externe domein gaat opsporen en zo kan de exim de verbinding niet meet droppen van wege een verkeerd domein / ip maar ontvangt de emails gewoon.

En de Exim documentatie:

The SMTP protocol specification requires the client to wait for a response from the server at certain points in the dialogue. Without PIPELINING these synchronization points are after every command; with PIPELINING they are fewer, but they still exist.

Some spamming sites send out a complete set of SMTP commands without waiting for any response. Exim protects against this by rejecting a message if the client has sent further input when it should not have. The error response “554 SMTP synchronization error” is sent, and the connection is dropped. Testing for this error cannot be perfect because of transmission delays (unexpected input may be on its way but not yet received when Exim checks). However, it does detect many instances.

The check can be globally disabled by setting smtp_enforce_sync false. If you want to disable the check selectively (for example, only for certain hosts), you can do so by an appropriate use of a control modifier in an ACL (see section 40.19). See also pipelining_advertise_hosts.

Dus ik ben wel benieuwd waar je jouw informatie vandaan hebt gehaald.

Grappig ook dat als je nu googlet dat je dan alleen dit topic tegenkomt met informatie die samenhangt met Microsoft Exchange.

Goed dat je probleem blijkbaar is opgelost, maar voor mij is je uitleg alles behalve bevredigend. Hiermme wil ik niet lullig overkomen... Imo strookt jouw uitleg gewoon totaal niet met het controleerbare.

[ Voor 18% gewijzigd door gertvdijk op 02-07-2008 01:17 ]