[EXCH 2010]Uitgaande mail wordt gebounced (Error 554)

[MrDry]

Wij maken gebruik van een POP mail account (Basic Business Mail van xs4all) om onze mail te versturen en ontvangen (via een POP connector).
Nu lopen wij tegen het probleem aan dat email naar een bepaald domein wordt gebounced en de verzender
een NDR krijgt.

Waarschijnlijk controleert de ontvanger of het IP adres van de verzende server bestaat. In de onderstaande header is dat ons lokale domein wat uiteraard niet te pingen valt.

HEADER:

code:

p01c12m063.mxlogic.net #554 Denied [511a8405.0.4269245.00-2382.5703742.p01c12m063.mxlogic.net] (Mode: normal) ##

Oorspronkelijke berichtkoppen:

Received: from SERVER-01.rietvink.local ([fe80::42c8:ed7f:8031:93a8]) by
 SERVER-01.rietvink.local ([fe80::42c8:ed7f:8031:93a8%10]) with mapi id
 14.01.0355.002; Thu, 6 Sep 2012 15:11:49 +0200
From: "xxxx"
To: "[e-mail]"
Subject: xxxxxxxxxxxxxxxx
Thread-Topic: xxxxxxxxxx
Thread-Index: Ac2MJCXX/TDnk+WbQdC9UZYQ3nKKggADPkGQ
Date: Thu, 6 Sep 2012 13:11:47 +0000
Message-ID: <[e-mail]>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.0.14]
Content-Type: multipart/mixed;
    boundary="_004_3D7AAAB08F579E409DB8DD4F6E89D2818EE768SERVER01rietvinkl_"
MIME-Version: 1.0

In het verleden hebben we dit probleem ook gehad. Toen is ons domein op de whitelist van de ontvanger gezet maar dit is uiteraard geen structurele oplossing.

Ik heb op de SBS2011 SendConnector onze FQDN ingevuld alleen zie ik deze niet terug in onze headers. Ook heb ik gewisselt tussen verzenden via DNS of via smarthost (xs4all). Dit zie ik wel terug in de headers maar beiden worden gebounced.

Iemand een idee hoe ik dit probleem oplos?

[CMD-Snake]

In de header staat de servernaam met DNS suffix. Enige manier om dat dan op te lossen is om het .local domein aan de kant de zetten en de hele boel in een .nl (of zoiets) domein te zetten. Niet echt handig imho. De default setup van SBS is een lokaal domein en daarnaast gescheiden een openbaar domein waar vandaan de mails komen etc.

Maar is dit wel jouw probleem om op te lossen? De tegenpartij zal dit probleem vaker hebben van mensen die een vergelijkbare inrichting hebben van hun domeinen. Ze moeten dan maar een grote whitelist gaan aanleggen.

[Question Mark]

CMD-Snake schreef op vrijdag 07 september 2012 @ 10:27:
In de header staat de servernaam met DNS suffix. Enige manier om dat dan op te lossen is om het .local domein aan de kant de zetten en de hele boel in een .nl (of zoiets) domein te zetten.

Lijkt mij persoonlijk handiger om dat binnen Exchange gewoon even aan te passen.

When a Mail Transfer Agent (MTA) such as Microsoft Exchange starts a SMTP conversation with another MTA, it will use a ‘HELO\EHLO’ hostname as a greeting. Some MTA’s will check this hostname to see if it matches the rDNS entry. If they do not match, the mail may be rejected. For this reason it is important that the Send Connector is using the correct FQDN to send mail. You can clarify what this is by using the Get-SendConnector as below:

Get-SendConnector | ft Id*,fq*

This will show you the FQDN used and the Identity of each connector.

You can use the Set-Sendconnector to set this to the public rDNS.

Set-SendConnector <Identityname> -Fqdn <rdns.example.com>

It’s as simple as that. (you can use the Exchange Management Console if you prefer, Org config –> Hub –> Send connectors)

[MrDry]

Ten dele heb je gelijk. Het 'hele' MKB werkt met SBS servers. Maar dit probleem lopen we al meerdere malen tegen aan. Blijkbaar worden spam filters hier en daar extreem scherp gezet....

[nl1klb]

Ik heb geen oplossing voor het probleem, maar wel een richting
Ik laat mijn server checken of er een MX record bestaat voor de mailserver die verstuurt naar mijn server.
In jouw geval is die er niet. Als jij mij wat zou versturen lukt het dus ook niet...

http://www.mxtoolbox.com

De bovenstaande site gebruik ik ervoor.
Ikzelf heb bijvoorbeeld een intern MX record, dan wel benaderbaar van buiten, én een MX record bij mijn ISP voor als de boel uitvalt. Misschien ook een tip?

[CMD-Snake]

Question Mark schreef op vrijdag 07 september 2012 @ 11:16:

Lijkt mij persoonlijk handiger om dat binnen Exchange gewoon even aan te passen.

Weer wat geleerd.

MrDry schreef op vrijdag 07 september 2012 @ 11:16:
Ten dele heb je gelijk. Het 'hele' MKB werkt met SBS servers. Maar dit probleem lopen we al meerdere malen tegen aan. Blijkbaar worden spam filters hier en daar extreem scherp gezet....

Ik vraag me af of deze check dan wel goed spam weert. Als een spammer van bijvoorbeeld lijkt te spammen vanaf een domein van een grote ISP komt het wel door. Maar jouw legitieme mails komen niet door.

Uiteindelijk heeft de tegenpartij voornamelijk zichzelf door deze gebrekkige manier van filteren.

[MrDry]

Question Mark schreef op vrijdag 07 september 2012 @ 11:16:
[...]

Lijkt mij persoonlijk handiger om dat binnen Exchange gewoon even aan te passen.


[...]

Mijn FQDN staat al goed. Stond overigens ook al in mijn OP.

[diehard889]

niet stiekum een back presure probleem ?

http://www.msexchange.org...-exchange-2010-part1.html

[Hero of Time]

MrDry schreef op vrijdag 07 september 2012 @ 12:08:
[...]


Mijn FQDN staat al goed. Stond overigens ook al in mijn OP.

Nee, die staat niet goed. rDNS werkt niet op .local domeinen, dus zelfs als je een FQDN hebt, moet deze wel buiten je eigen domein te resolven zijn. Mail sturen met een FQDN van domain.local werkt niet, maar example.org wel. Je geeft bij je Exchange server aan wat je sending FQDN is voor de email. Ik mag iig hopen dat je met [e-mail] oid mailt, en niet met [e-mail].

[kroegtijger]

Hero of Time schreef op vrijdag 07 september 2012 @ 13:56:
[...]

Nee, die staat niet goed. rDNS werkt niet op .local domeinen, dus zelfs als je een FQDN hebt, moet deze wel buiten je eigen domein te resolven zijn. Mail sturen met een FQDN van domain.local werkt niet, maar example.org wel. Je geeft bij je Exchange server aan wat je sending FQDN is voor de email. Ik mag iig hopen dat je met [e-mail] oid mailt, en niet met [e-mail].

Dit inderdaad Je moet jezelf bij de ontvangende mailserver kenbaar maken door je FQDN aan te geven. Steeds meer servers gaan vervolgens via reverse DNS controleren of het afzendende IP diezelfde FQDN heeft staat (je PTR-record dus). Pas als dat matched wordt een mail geaccepteerd door de server, en daarna volgen er mogelijk nog vervolg-checks met spam-filtering e.d.

makkelijkste manier om je FQDN te controleren is even een telnet op poort 25; je server zal zich dan presenteren met een FQDN. Daarna controleer je nog even via een ping -a of je PTR staat ingesteld (zo niet, dan bij je ISP regelen), en daarmee zou het moeten werken. Uiteraard wel even controleren of je niet met .local probeert te mailen

[Question Mark]

Hero of Time schreef op vrijdag 07 september 2012 @ 13:56:
[...]

Nee, die staat niet goed. rDNS werkt niet op .local domeinen, dus zelfs als je een FQDN hebt, moet deze wel buiten je eigen domein te resolven zijn. Mail sturen met een FQDN van domain.local werkt niet, maar example.org wel.

^^ dat dus... Staat overigens ook in mijn quote:

You can use the Set-Sendconnector to set this to the public rDNS.

Controleer dat dus even. Aardige kans dat het dan wel werkt.

[MrDry]

Get-SendConnector | ft Id*,fq* verwijst echt naar ons .nl domein. Ik kan die FQDN van buitenaf gewoon
bereiken.

Ping -a is ook geen probleem alleen een telnetsessie geeft onze lokale domeinnaam weer en niet de FQDN.

[lier]

Waarom maak je gebruik van een POP account in plaats van de mail door je Exchange doos te laten ontvangen? En is het een optie om te versturen via een smarthost (de mailserver van de betreffende provider)?

CMD-Snake schreef op vrijdag 07 september 2012 @ 11:33:
Uiteindelijk heeft de tegenpartij voornamelijk zichzelf door deze gebrekkige manier van filteren.

"gebrekkig"!? Laat de verzender maar zijn best doen!

[MrDry]

lier schreef op vrijdag 07 september 2012 @ 15:23:
Waarom maak je gebruik van een POP account in plaats van de mail door je Exchange doos te laten ontvangen? En is het een optie om te versturen via een smarthost (de mailserver van de betreffende provider)?

Van oudsher gebruiken we een popconnector. Werkt prima. Is misschien handiger om op bSTMP over te stappen. Maar dat lost het probleem nu niet op

Het gebruik van de smarthost van xs4all heb ik geprobeert. Resultaat is gelijk: bounce.

[lier]

MrDry schreef op vrijdag 07 september 2012 @ 15:55:
Het gebruik van de smarthost van xs4all heb ik geprobeerd. Resultaat is gelijk: bounce.

Oei...dan doe je toch iets niet goed.