P
Pitti
Hello,
I have had this problem long time now, and I have been received a very
good trick from "Dan Thompson [MSFT]" / March 2009.
That trick helped me a lot, but didn't give me total fix to the problem.
Problem is that SBS2008 POP3 Connector is trying to deliver emails to
Exchange Server, but fails because those emails are not "standard"
emails. Every email, that is "standard" email, are delivered just fine
to Exchange, but those emails, that aren't "standards" are still staying
on ISP's POP3 Email Server.
Non "standard" email has return path: mailer-daemon - text, and that
makes it non-standard email.
Exchange server has some kind of "filter", which says that this email
cannot be received at all, so it will be rejected. If someone knows how
this "filter" will be disabled, I would be very pleased about quidance.
Here is quote about Dan Thompson technical description:
Also found in this web site
http://www.tech-archive.net/Archive...blic.windows.server.sbs/2009-03/msg00163.html
Exchange will close an SMTP connection after a certain number of
protocol errors (5 by default). (see the MaxProtocolErrors property of
the ReceiveConnector object at:
http://technet.microsoft.com/en-us/library/aa998618.aspx)
When the SBS 2008 pop3connector downloads a message from a POP3 mailbox,
it needs to figure out what the "return path" for the mail should be,
which it does by reading the email's headers. The pop3connector does not
do validation of the header value--it lets Exchange take care of that.
If the header value that the pop3connector chooses is malformed, when it
is sent to the Exchange server (as part of the "MAIL FROM" command),
Exchange will reject it with a 501 error. That counts as a "protocol
error", and therefore is counted against the MaxProtocolErrors limit.
Since the pop3connector was not able to deliver the mail, and does not
know if the mail is safe to delete, it leaves the mail on the POP3 server.
If there are 5 of these messages in your POP3 mailbox, then there will
be 5 "protocol errors" in the pop3connector's SMTP session, which hits
the limit, and Exchange will end the session with a transient error
(4xx). When this happens, the pop3connector recognizes that the error is
transient, and will retry again at the next scheduled download period.
But since those 5 malformed messages are still in the POP3 mailbox, the
same thing will continue to happen, with no "forward progress" being made.
The workaround is to increase the “MaxProtocolErrors” property of the
internal receive connector, which is called “<COMPUTERNAME>\Windows SBS
Fax Sharepoint Receive <COMPUTERNAME>”, and then restart the Exchange
Transport service for the change to take effect (and you’ll have to
restart the pop3connector service, too, since it depends on the Exchange
Transport service). Unfortunately, you can’t set that property from the
Exchange management GUI, so you have to do it from an (elevated)
Exchange Powershell prompt. Here are the instructions:
From an elevated Exchange Management Shell (Exchange Powershell window)
(right click on “Start-->Microsoft Exchange Server 2007-->Exchange
Management Shell” and then choose “Run as administrator”) run the
following Powershell commands:
Set-ReceiveConnector -Identity ($Env:computername + "\Windows SBS Fax
Sharepoint Receive " + $Env:computername) -MaxProtocolErrors 500
Stop-Service pop3connector
Restart-Service -force MSExchangeTransport
Start-Service pop3connector
That will increase the MaxProtocol errors (of the internal receive
connector only) to match the pop3connector’s max emails downloaded per
session. Once you get 500 messages with malformed headers stacked up in
the POP3 mailbox, though, you’ll still have to delete them manually.
Q. Why might you be getting emails with malformed headers?
A. It seems there are some buggy (perhaps deliberately) spam servers out
there. Or it could be non-compliant mail software (like whatever
software generated "Return-Path: <MAILER-DAEMON>" header that started
this thread).
Thanks for advance!
Jani
I have had this problem long time now, and I have been received a very
good trick from "Dan Thompson [MSFT]" / March 2009.
That trick helped me a lot, but didn't give me total fix to the problem.
Problem is that SBS2008 POP3 Connector is trying to deliver emails to
Exchange Server, but fails because those emails are not "standard"
emails. Every email, that is "standard" email, are delivered just fine
to Exchange, but those emails, that aren't "standards" are still staying
on ISP's POP3 Email Server.
Non "standard" email has return path: mailer-daemon - text, and that
makes it non-standard email.
Exchange server has some kind of "filter", which says that this email
cannot be received at all, so it will be rejected. If someone knows how
this "filter" will be disabled, I would be very pleased about quidance.
Here is quote about Dan Thompson technical description:
Also found in this web site
http://www.tech-archive.net/Archive...blic.windows.server.sbs/2009-03/msg00163.html
Exchange will close an SMTP connection after a certain number of
protocol errors (5 by default). (see the MaxProtocolErrors property of
the ReceiveConnector object at:
http://technet.microsoft.com/en-us/library/aa998618.aspx)
When the SBS 2008 pop3connector downloads a message from a POP3 mailbox,
it needs to figure out what the "return path" for the mail should be,
which it does by reading the email's headers. The pop3connector does not
do validation of the header value--it lets Exchange take care of that.
If the header value that the pop3connector chooses is malformed, when it
is sent to the Exchange server (as part of the "MAIL FROM" command),
Exchange will reject it with a 501 error. That counts as a "protocol
error", and therefore is counted against the MaxProtocolErrors limit.
Since the pop3connector was not able to deliver the mail, and does not
know if the mail is safe to delete, it leaves the mail on the POP3 server.
If there are 5 of these messages in your POP3 mailbox, then there will
be 5 "protocol errors" in the pop3connector's SMTP session, which hits
the limit, and Exchange will end the session with a transient error
(4xx). When this happens, the pop3connector recognizes that the error is
transient, and will retry again at the next scheduled download period.
But since those 5 malformed messages are still in the POP3 mailbox, the
same thing will continue to happen, with no "forward progress" being made.
The workaround is to increase the “MaxProtocolErrors” property of the
internal receive connector, which is called “<COMPUTERNAME>\Windows SBS
Fax Sharepoint Receive <COMPUTERNAME>”, and then restart the Exchange
Transport service for the change to take effect (and you’ll have to
restart the pop3connector service, too, since it depends on the Exchange
Transport service). Unfortunately, you can’t set that property from the
Exchange management GUI, so you have to do it from an (elevated)
Exchange Powershell prompt. Here are the instructions:
From an elevated Exchange Management Shell (Exchange Powershell window)
(right click on “Start-->Microsoft Exchange Server 2007-->Exchange
Management Shell” and then choose “Run as administrator”) run the
following Powershell commands:
Set-ReceiveConnector -Identity ($Env:computername + "\Windows SBS Fax
Sharepoint Receive " + $Env:computername) -MaxProtocolErrors 500
Stop-Service pop3connector
Restart-Service -force MSExchangeTransport
Start-Service pop3connector
That will increase the MaxProtocol errors (of the internal receive
connector only) to match the pop3connector’s max emails downloaded per
session. Once you get 500 messages with malformed headers stacked up in
the POP3 mailbox, though, you’ll still have to delete them manually.
Q. Why might you be getting emails with malformed headers?
A. It seems there are some buggy (perhaps deliberately) spam servers out
there. Or it could be non-compliant mail software (like whatever
software generated "Return-Path: <MAILER-DAEMON>" header that started
this thread).
Thanks for advance!
Jani
