Getagged : Exchange

in Hard & Software, Hilfe, Netz, PC

Exchange 2010: Header size exeeds maximum size

Ein freundlicher mittelständischer Hoster hat einen seiner Kunden in Kenntnis gesetzt, dass seit einigen Tagen sein tägliches normales Volumen bei der Mailabholung sich um Faktor 40 vergrößert hat und dies mitunter sein Traffic-Volumen massiv auffrisst. Die Mails im Allgemeinen werden mittels POP3-Connector von den externen Konten abgerufen und dann den jeweiligen internen Exchange-Konten zugestellt. Nach Kontrolle der Logs wurde bei einigen Mailkonten ein 552 5.3.4 “Header size exceeds maximum size” beim Abrufen dieser festgestellt.

Für mich persönlich war es mehr als neu, dass die Annahme von Mails auf Grund von einem Limit der Größe des Mail-Headers abgelehnt werden, was zur Folge hatte, dass die teilweise 2-10 MB großen Mails ständig abgerufen, aber nicht zugestellt und ergo auch nicht vom externen Postfach gelöscht wurden. Beim erneuten Abruf wurden diese wieder heruntergeladen und schlugen wie zu erwarten erneut fehl. Und das alle 2 Minuten (wer auch immer das Polling-Intervall eingestellt hat). Ein Teufelskreis …

Es ist ohne Weiteres in der Exchange-Konsole nicht ersichtlich, wie man ein vorhandenes Limit des Mail-Headers vergrößern könnte. Die Größe einer Mail im Allgemeinen, die zugelassen werden soll, kann man jedoch einstellen. Mittels der Exchange-Powershell kann man aber letztendlich das Limit für den Mail-Header einstellen.

set-receiveconnector -identity “SERVERNAME.tld\SMTP-Receive-Connector-Name” -MaxHeaderSize 128kb

Danach akzeptiert ein Exchange 2010 (ebenso ein Exchange 2007) Mails mit “unnatürlich” großen Mail-Headern und der Traffic beim Kunden hat sich erwartungsgemäß wieder beruhigt. Wieso es ein derartiges Limit überhaupt gibt bei M$, erschließt sich mir nicht wirklich. Vielleicht hat ja einer der Leser hierzu eine Idee ;-)

in Hard & Software, Hilfe, PC

Microsoft, Exchange 2010 und Anonymous

Es gibt Anwendungen, die gern einmal Mails versenden: Statusinformationen, Erinnerungen an die User oder auch Hinweis auf Änderungen von Einträgen in einem System. Davon schwirren bei uns im Unternehmen einige herum. Besonders eine alte Anwendung, die aber sehr wichtig ist (welche ist das leider nicht) verschickt gern Mails, wenn ein Anwender Eintragungen bzw. Änderungen von Vorgängen getätigt hat. Das klappte bis vor der Einführung von Exchange 2k10 sehr gut.

Mails versendet diese Anwendung an einen offen verfügbaren SMTP-Server ohne jegliche Anmeldung, weswegen der 2k10 selbstverständlich dicht machte. Hierzu hatte ich einige Lösungshinweise versucht umzusetzen. Ich richtete einen neuen SMTP-Empfangsconnector ein, setzte die Zugriffsberechtigungen auf IP-Ebene, sodass nur spezielle Arbeitsstationen im lokalen Netz erlaubt waren darüber und nur an spezifische Empfänger zu versenden – wer will schon ein offenes Relay haben. Brachte aber alles nichts, denn den eigentlichen PowerShell Befehl, der für die Berechtigungsfreigabe für Anonymous-Zugriffe nötig ist, wollte ums verrecken nicht funktionieren.

Unter dieser Seite gibt es eine Anleitung mit auch eben jenen Befehl, der zum Scheitern verurteilt ist – zumindest auf deutschsprachigen Systemen.

Get-ReceiveConnector “Anonymous Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Der obige Befehl schlägt mit der Meldung fehl, dass der Benutzer bzw. die Gruppe “NT AUTHORITY\ANONYMOUS LOGON” nicht gefunden werden konnte. Selbstverständlich schlägt der fehl, da es sich eben um keine englischsprachige Maschine handelt. Der richtige Befehl lautet ergo:

Get-ReceiveConnector “Anonymous Relay” | Add-ADPermission -User “ANONYMOUS-Anmeldung” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

oder

Get-ReceiveConnector “Anonymous Relay” | Add-ADPermission -User “NT-AUTORITÄT\ANONYMOUS-Anmeldung” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Bei aller Anpassung und Normierung von Pfaden, Junctions, SymLinks auf Grund der Problembeseitigung von unterschiedlichen Pfaden in Abhängigkeit von der Programmsprachversion (zB. “Program Files” zu “Programme”) sollte Microsoft einfach mal die Namen der System-User normieren. Dann klappt es auch besser mit dem TechNet.

in Arbeit, Hard & Software, Hilfe, Kommentar, Kurioses, PC

Erfahrungsbericht: Exchange Server 2003 Fehler

exchange-447e.jpg Fehler im System mag keiner. Wenn ein Programm abstürzt ist es zwar ärgerlich, aber im großen Teil sind keine Daten betroffen. Anders verhält es sich mit einem Fehler beim Exchange Server 2003 von Microsoft. Bei einem Kunden wird seit den Feiertagen der Fehler 447 (Event ID 447 in ESE) in nicht ganz sporadischen – ich würde sagen im Millisekundentakt – Schritten ins Ereignisprotokoll geworfen. Dieses ist seitdem auf eine beachtliche Größe gewachsen voll von 447er Einträgen. Lustig anzusehen, wenn es lustig wäre.

Im Exchange Store hat sich irgendwo in den Datenobjekten mindestens ein Fehler versteckt und den galt es operativ, am Besten ohne Zange, Skalpell und Schlüpfer zu entfernen. Microsoft macht es sich an dieser Stelle sehr leicht und empfiehlt eine Datensicherung vor dem ersten Fehlereintrag einzuspielen. Ganz großes Kino an dieser Stelle, denn das erste Auftreten des Ereignisses war vor den großen Feiertagen, genannt Weihnachten. Ergo wären alle eingegangenen und versendeten Mails futsch. Das ist natürlich nicht im Sinne und Interesse des Kunden, welcher uns auch prompt mit der Reparatur beauftragte. Lieber 10 Mails weg, als 100 oder gar 1000.

Der Fehler 447 verursachte nämlich eine verzögerte oder gar keine Zustellung von externen Mails in den Exchange Store. Diese blieben in der Empfangswarteschlange einfach stecken und frohlockten mit der Meldung “Verzögerte Zustellung”. Genau das Richtige zu Weihnachten. Wenns klemmt bei der Post, dann verzögert sich das auch bei denen.

Weiter lesen …