Getagged : 2010

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 ;-)

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.