Onderwerp: probleem mail naar externe MX

Hallo,

Wij hebben een klant dat zijn eigen mailserver gebruikt. Daarom hebben wij in plesk de MX record gewijzigd naar zijn server.
Dit werkt allemaal goed. Dus alsde buitenwereld mails verstuurd dan komen ze aan.

Maar op server staan enkele scripts die ook moeten mailen naar die persoon. En die moeten dus ook die externe MX gebruiken. En daar loopt het fout.

De berichten blijven in de queue staan, ze staan wel als remote gequeued maar ze worden niet verzeonden.

De "mail" in plesk staat uitgeschakeld. Dus onder het tabje "mail" voor deze domeinnaam.
Lang geleden toen we nog is zo'n klant hadden, hadden we net hetzelfde probleem... en daar was de oorzaak dat in plesk de mail nog aan stond.

/usr/local/psa/var/log/

ik heb de maillogs bekeken. En hij probeert wel te verzenden, maar geen enkele foutmelding, ik zie ook dat hij af en toe alles opnieuw probeert te verzenden.

Maar dan staat er enkel het volgende:

Dec 19 05:42:15 server1 qmail: 1198039335.460615 starting delivery 290: msg 13502505 to remote xx@xx.be
Dec 19 05:42:15 server1 qmail: 1198039335.460994 status: local 0/10 remote 1/20
Dec 19 05:42:15 server1 qmail-remote-handlers[26900]: Handlers Filter before-remote for qmail started ...
Dec 19 05:42:15 server1 qmail-remote-handlers[26900]: from=yy@yyy.be
Dec 19 05:42:15 server1 qmail-remote-handlers[26900]: to=xx@xx.be

Meer staat er niet in :s geen geweigerd, of geaccepteerd... niks.

Al het ander mail verkeer loopt prima. Server verstuurt vlekkeloos naar hotmail en alle andere providers.

Weet iemand wat het problemen zou kunnen zijn ?

Alvast veel dank !

licht puntje ... ik heb hun server IP is door de logs gesleurd en ik krijg:

Dec 19 15:56:37 server1 qmail: 1198076197.489427 delivery 489: deferral: Connected_to_81.241.239.185_but_connection_died._( #4.4.2)/

Die 442 wordt gegeven door de server van je klant lijkt wel. De exchange die ze daar draaien vind ik persoonlijk viesbah, maar vraag eens aan je klant welke foutmelding zij daar krijgen?

Hoe heb je het mx record ingesteld als ik vragen mag? En ja het kan natuurlijk ook aan de ontvangende server liggen natuurlijk.

domein.be. MX (10) mail.domein.be.
mail.domein.be A 123.123.213.212

DNS zou in orde moeten zijn. Ik heb lokaal al is proberen pingen naar mail.domein.be. Ook extern al is wat ping tests gedaan. en opvragen van DNS.

Ik heb extern een mail test laten lopen op een mail adres van hun. Het resultaat;

MX records preference exchange IP address (if included)
10 mail.domein.be [81.2xx.2xx.1xx]
SMTP session

[Contacting mail.dom.be [81.xxx.xx.1xx]...]
[Connected]
220 dom.be Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 19 Dec 2007 18:00:22 +0100
EHLO m
250-dom.be Hello [66.98.244.52]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
VRFY test
252 2.1.5 Cannot VRFY user, but will take message for <test@dom.be>
RSET
250 2.0.0 Resetting
....
[Connection closed]

iemand een idee?

Ik heb zonet gezien dat hij al die mails in de queue opnieuw heeft proberen te verzenden... maar zonder resultaat.

en connection died staat er de laatste uren ook niet meer tussen...

weet iemand aan wat dit kan liggen ... of hoe je dit verder kan testen ?

bendankt!

UPDATE. Wat ik wel dikwijls achter 1 van de pogingen zie staan is het volgende (in logfiles)

Dec 19 19:07:48 server1 relaylock: /var/qmail/bin/relaylock: mail from 127.0.0.1:56864 (localhost)

kan dit hiermee iets te maken hebben ?

Niemand een idee wat dit kan veroorzaken?

Met al die xxx-jes en yyy-tjes heb ik geen idee. Let er in ieder geval op dat je als afzender adres een geldige afzender gebruik, let op zaken als spf.
Probeer eens een afzender te gebruiken waarvoor die exchange server de mail niet afhandeld.

Je klant kan messagetracking in Exchange aanzetten. Eventueel loggings van SMTP op maximaal zetten.. dan zou er iets te zien moeten zijn..

Check ook even of Reversed DNS voor je Plesk machine ingesteld staat. Het kan zijn dan die Wintendo machine wacht op een DNS reply. Sommige machines nemen geen mail aan als reversed DNS voor de aanbiedende machine niet geconfigureerd staat.

Als je dan geluk hebt krijg je een 4xx error waardoor het soms dagen kan duren voordat je mail daadwerkelijk gebounced wordt door je Plesk server en je dan pas de reden krijgt waarom.

Voor mails die op de server zelf naar "eigen", lokale domains gestuurd worden, bijv. vanuit een of andere webapplicatie (denk aan een contactformulier), wordt voor aflevering niet in het DNS gekeken. Daarvoor wordt altijd geprobeerd ze op de eigen machine af te leveren.
Die MX-records hebben dus geen effect.

Hoe je dit kunt voorkomen/omzeilen weet ik helaas ook niet.

Je gebruikt geen exim maar met exim kan dat om de desbetreffende domeinnaam in /etc/localdomains te verwijderen en te plaatsen in /etc/remotedomains

Ik neem aan dat jouw MTA ook zoiets moet hebben.

Je laatste logregel geeft aan dat de remote server je mail niet accepteert (4xx voor tijdelijk, 5xx zou permanent zijn).

Dit kan inderdaad meerdere redenen hebben, en je zal de klant dus moeten vragen wat er bij hun in de logging verschijnt.

Wat mogelijke problemen kunnen zijn:
- je eigen PTR records zijn niet in orde (reversed DNS) > doe een traceroute naar het IPadres van je versturende server, krijg je geen hostname terug dan kan het zijn dat de Exchangeserver je mail daarom niet aan neemt en de connectie afschiet.
- De remote exchange server heeft een andere reden gevonden waarom je Plesk server niet mag afleveren, zoals een RBL list waar je op terecht gekomen bent, foutieve authenticatie (indien gebruikt), een blocklist of een andere anti spam instelling
- Er zit een firewall tussen (bij jou, of bij je klant) die zich bemoeit met het SMTP verkeer. Ik heb dit zien gebeuren met bijvoorbeeld Cisco PIX kugh..."firewalls"... (verwijder "fixup protocol smtp 25" uit je PIX config)

Wat je kan doen:
- je klant de logging door laten spitten op jou IPadres
- bovenstaande zaken controleren, en anders een TCPdump mee laten draaien op connecties naar hun ipadres

Suc6!