Exchange 2007 Edge-Transport - Greylisting - QueueGlitchRetryInterval

15/04/2009 - 21:03 von Markus Schröder | Report spam
Hallo Leute,

heute habe ich mich den halben Tag mit einem Problem rumgeàrgert,
am Ende Gott sei Dank die Lösung gefunden, frage mich jedoch, warum die
Default-Werte so adminunfreundlich versteckt ist.

Problem:

Zielserver greylistet. (siehe wikipedia).
d.h. wenn der einliefernde Mailserver noch nicht in der Whitelist des
Zielservers steht,
erhàlt der ET ein 450 Mailbox temporàr nicht erreichbar. oft mit dem
Hinweis, das nach 300 Sekunden eine erneute Zustellung erfolgen soll. (Habe
auch schon làngere Intervalle im Log entdeckt.)
Der EdgeTransport versucht munter jede Minute die Email abzuliefern, was so
aussieht:


220 Welcome to ESMTP with servermails.com 1.7 server.,
EHLO mx01.xxx.org,
250-Hello mx01.xxx.org,
250-AUTH LOGIN,
250-ENHANCEDSTATUSCODES,
250 PIPELINING,
510440,sending message
MAIL FROM:<M.Schroeder@xxx.de>,
RCPT TO:<info@yyy.de>,
RCPT TO:<mail@yyy.de>,
450 4.5.0 You are greylisted for 300 seconds - Please try again 300 seconds
later and the mail will be accepted. You will find help about the
Greylisting at http://www.servermails.com,
503 5.5.0 Bad sequence of commands,
503 5.5.0 Bad sequence of commands,
QUIT,
221 Signing Off,
Local


und quitierte schlussendlich mit einem NDR:

Hello #571 5.7.1 Blocked by blocklist: Delivery not authorized, connection
refused. ##



Ausgiebiges googlen und probieren brachte die Erkenntnis...

Wenn ich bei diesem Mailserver innerhalb der 300 Sekunden mehrfach versuche
die Mail los zuwerden, scheine ich nicht auf die Whitelist zu kommen.
Andere Mailserver stören sich nicht daran und nach dem 5
Einlieferungsversuch klappt es dann ja im Allgemeinen.

Nach folgender Anpassung hat's geklappt:

http://technet.microsoft.com/de-de/...98043.aspx
Öffnen Sie die folgende Datei in Notepad: C:\Programme\Microsoft\Exchange
Server\Bin\EdgeTransport.exe.config.
Ändern Sie im Abschnitt <appSettings> folgende Zeile:
<add key="QueueGlitchRetryInterval" value="00:00:30" />

denn Wert also auf 00:05:01 gestellt und siehe da, es geht!
Erste Email abgeliefert, 301 Sekunden gewartet und durchgekommen!

Auch wenn greylisting nicht RFC Konform ist und dazu nur ein RFCC existiert,
so wird es doch von vielen genutzt. jetzt frage ich mich, wieviele unserer
Nutzer haben schon aus diesem Grund einen NDR erhalten?!

Habt Ihr àhnliche Erfahrungen gemacht ???

Eins noch, ich weiß nicht ob es beim alten Exchange oder einem Linux-MTA
gewesen ist,
aber ich erinnere mich an die meiner Meinung nach ideale Umsetzung der
Wiederholungsversuche, die ist in etwa so gewesen:

1. Versuch failed.
2. Versuch nach 5 Minuten
3. Versuch nach 20 Minuten.
4. Versuch nach 1 Stunde
5. Versuch nach 4 Stunden
6. Versuch nach 12 Stunden
7. NDR oder so weiter...


So einen hab ich noch: Wàre "Set-TransportServer dmz-et1 -
TransientFailureRetryInterval 00:05:01" nicht sinnvoller gewesen als den
Glitch anzupassen???


Schönen Abend noch.

Gruß
Markus Schröder
 

Lesen sie die antworten

#1 Steinsdorfer Walter
15/04/2009 - 23:19 | Warnen spam
Hi,

heute habe ich mich den halben Tag mit einem Problem rumgeàrgert,
am Ende Gott sei Dank die Lösung gefunden, frage mich jedoch, warum die
Default-Werte so adminunfreundlich versteckt ist.

Problem:

Zielserver greylistet. (siehe wikipedia).
d.h. wenn der einliefernde Mailserver noch nicht in der Whitelist des
Zielservers steht,
erhàlt der ET ein 450 Mailbox temporàr nicht erreichbar. oft mit dem
Hinweis, das nach 300 Sekunden eine erneute Zustellung erfolgen soll.
(Habe auch schon làngere Intervalle im Log entdeckt.)



Es gibt auch kürzere. Im Prinzip reichen ein paar Sekunden.

Der EdgeTransport versucht munter jede Minute die Email abzuliefern, was
so aussieht:


220 Welcome to ESMTP with servermails.com 1.7 server.,
EHLO mx01.xxx.org,
250-Hello mx01.xxx.org,
250-AUTH LOGIN,
250-ENHANCEDSTATUSCODES,
250 PIPELINING,
510440,sending message
MAIL FROM:,
RCPT TO:,
RCPT TO:,
450 4.5.0 You are greylisted for 300 seconds - Please try again 300
seconds later and the mail will be accepted. You will find help about the
Greylisting at http://www.servermails.com,
503 5.5.0 Bad sequence of commands,
503 5.5.0 Bad sequence of commands,
QUIT,
221 Signing Off,
Local


und quitierte schlussendlich mit einem NDR:

Hello #571 5.7.1 Blocked by blocklist: Delivery not authorized, connection
refused. ##



Ausgiebiges googlen und probieren brachte die Erkenntnis...

Wenn ich bei diesem Mailserver innerhalb der 300 Sekunden mehrfach
versuche die Mail los zuwerden, scheine ich nicht auf die Whitelist zu
kommen.



das ist definitiv gegen RFC und das Greylisting des Gegenüber ist falsch
konfiguriert.

Andere Mailserver stören sich nicht daran und nach dem 5
Einlieferungsversuch klappt es dann ja im Allgemeinen.



so sollte es sein.


Nach folgender Anpassung hat's geklappt:

http://technet.microsoft.com/de-de/...98043.aspx
Öffnen Sie die folgende Datei in Notepad: C:\Programme\Microsoft\Exchange
Server\Bin\EdgeTransport.exe.config.
Ändern Sie im Abschnitt <appSettings> folgende Zeile:
<add key="QueueGlitchRetryInterval" value="00:00:30" />

denn Wert also auf 00:05:01 gestellt und siehe da, es geht!
Erste Email abgeliefert, 301 Sekunden gewartet und durchgekommen!

Auch wenn greylisting nicht RFC Konform ist und dazu nur ein RFCC
existiert,



das es nicht RFC-konform ist ist wohl strittig. Meine Persönliche Meinung
ist das es bessere Maßnahmen gibt wie Greylisting.

so wird es doch von vielen genutzt. jetzt frage ich mich, wieviele unserer
Nutzer haben schon aus diesem Grund einen NDR erhalten?!




nö, ich würde mich bei "àne.yx" beschweren.

Eins noch, ich weiß nicht ob es beim alten Exchange oder einem Linux-MTA
gewesen ist,
aber ich erinnere mich an die meiner Meinung nach ideale Umsetzung der
Wiederholungsversuche, die ist in etwa so gewesen:

1. Versuch failed.
2. Versuch nach 5 Minuten
3. Versuch nach 20 Minuten.
4. Versuch nach 1 Stunde
5. Versuch nach 4 Stunden
6. Versuch nach 12 Stunden
7. NDR oder so weiter...



Nö, der NDR sollte erst spàter kommen. Ein DSN mit der Mitteilung: Die
Nachricht konnte noch nicht zugestellt werden darf nach 12 Stunden aber mal
rausgehen.



So einen hab ich noch: Wàre "Set-TransportServer dmz-et1 -
TransientFailureRetryInterval 00:05:01" nicht sinnvoller gewesen als den
Glitch anzupassen???



Ansichtssache, bei E2k3 war es in der Registry zu finden.

Viele Grüsse aus München

Walter Steinsdorfer
MVP Exchange Server
www.exusg.de
http://msmvps.com/blogs/wstein

Ähnliche fragen