von Auch wenn sie nur eine Übergangslösung darstellen sollten, so laufen doch in vielen Netzwerken POP3-Connectoren als unschöne Dauerlösung. Mit der Zeit kann dieser auch extrem langsam werden. Woran dies liegen kann und wie man es wieder beschleunigt folgt in diesem Artikel.
Log-File Analyse
Im Fall des POP3-Connectors eines Windows Small Business Servers hilft ein Blick in das Log-File. Dieses muss eventuell vorher noch aktiviert werden.
Dort wird man vermutlich sehr häufig solche Einträge mit der Meldung „Sender denied“ finden:
[t 0] 07/29/20, 15:49:30: Downloading message 1 of 6.
[t 0] 07/29/20, 15:49:30: (POP3) [TX] RETR 1
[t 0] 07/29/20, 15:49:30: (POP3) [RX] +OK
[t 0] 07/29/20, 15:49:30: Sending message 1 to the SMTP recipient bla@test.de…
[t 0] 07/29/20, 15:49:30: (SMTP) [TX] MAIL FROM: <> RET=FULL
[t 0] 07/29/20, 15:49:30: Downloading message 2 of 6.
[t 0] 07/29/20, 15:49:30: (POP3) [TX] RETR 2
[t 0] 07/29/20, 15:49:30: (SMTP) [RX] 250 2.1.0 Sender OK
[t 0] 07/29/20, 15:49:30: (SMTP) [TX] RCPT TO: <bla@test.de> NOTIFY=FAILURE
[t 0] 07/29/20, 15:49:30: (SMTP) [RX] 250 2.1.5 Recipient OK
[t 0] 07/29/20, 15:49:30: (SMTP) [TX] DATA
[t 0] 07/29/20, 15:49:30: (SMTP) [RX] 354 Start mail input; end with .
[t 0] 07/29/20, 15:49:30: (SMTP) [TX]
.
[t 0] 07/29/20, 15:49:30: (POP3) [RX] +OK
[t 0] 07/29/20, 15:49:35: (SMTP) [RX] 554 5.1.0 Sender denied
[t 0] 07/29/20, 15:49:35: Failure hrResult (0x800ccc6f) trying to deliver message id 1:
[t 0] 07/29/20, 15:49:35: SMTPRESPONSE: * * * !Failed! * * *
[t 0] 07/29/20, 15:49:35: * * * * * *
[t 0] 07/29/20, 15:49:35: * * * 0x800ccc6f * * *
[t 0] 07/29/20, 15:49:35: Command: [SMTP_DOT]
[t 0] 07/29/20, 15:49:35: Completed: Yes.
[t 0] 07/29/20, 15:49:35: IxpResult:
[t 0] 07/29/20, 15:49:35: —> —> —> hrResult: 0x800ccc6f
[t 0] 07/29/20, 15:49:35: pszResponse: 554 5.1.0 Sender denied
[t 0] 07/29/20, 15:49:35: uiServerError: 554
[t 0] 07/29/20, 15:49:35: dwSocketError: 0
[t 0] 07/29/20, 15:49:35: pwszProblem:
[t 0] 07/29/20, 15:49:35: Unfamiliar error delivering mail: 554
[t 0] 07/29/20, 15:49:35: Full response details:
[t 0] 07/29/20, 15:49:35: SMTPRESPONSE: * * * !Failed! * * *
[t 0] 07/29/20, 15:49:35: * * * * * *
[t 0] 07/29/20, 15:49:35: * * * 0x800ccc6f * * *
[t 0] 07/29/20, 15:49:35: Command: [SMTP_DOT]
[t 0] 07/29/20, 15:49:35: Completed: Yes.
[t 0] 07/29/20, 15:49:35: IxpResult:
[t 0] 07/29/20, 15:49:35: —> —> —> hrResult: 0x800ccc6f
[t 0] 07/29/20, 15:49:35: pszResponse: 554 5.1.0 Sender denied
[t 0] 07/29/20, 15:49:35: uiServerError: 554
[t 0] 07/29/20, 15:49:35: dwSocketError: 0
[t 0] 07/29/20, 15:49:35: pwszProblem:
[t 0] 07/29/20, 15:49:35: (SMTP) [TX] RSET
Aus irgendeinem Grund werden Nachrichten nicht zugestellt. Und dieser Grund ist meist schnell gefunden. Entweder lag es am Spamfilter des Exchange-Servers oder an irgendwelchen Spam-Regeln, die von den Benutzern selbständig eingestellt worden sind, durch welche die E-Mails abgewiesen wurden. Sollten E-Mails beim POP3-Anbieter mit größerem Anhang aufschlagen, als es der Exchange akzeptiert, dürfte ähnliches passieren.
Problem
In den POP3-Postfächern sammeln sich somit im Laufe der Zeit massig E-Mails an, die aufgrund der Spam-Regeln des Exchange-Servers nie mehr abgeholt werden können. Diese verbleiben aber im Posteingang und werden bei jedem Durchlauf wieder versucht abzuholen. Immer wieder mit dem gleichen Ergebnis.
Lösung
Die ideale Lösung wäre grundsätzlich immer den POP3-Connector los zu werden. Ansonsten hilft in diesem Fall nur das Löschen der betroffenen E-Mails und auch eine entsprechende Vorkehrung zu treffen, sodass die Mails auch im POP3-Posteingang verschwinden. Zumindest etwas hilfreich könnte eine Filterregel beim E-Mail-Provider sein, welche E-Mails mit einem bestimmten Alter löscht oder zumindest in einen anderen Ordner verschiebt.
