SMTP Connector to Postini Outbound Service
nos...@i0ta.com
I am a Postini customer and the administrator of an Exchange 2003
organization. I am trying to send all outbound external e-mail through
Postini's service for the purposes of tracking usage statistics,
filtering any outbound viruses before they get to our customers, and
enforcing attachment policies. So far, I do not have A/V or attachment
policies turned on in my Postini account. I'm merely trying to use
them as a smart host to relay outbound e-mail through.
We have two routing groups each containing a single Exchange 2003
server. Each routing group has a RGC (Routing Group Connector)
allowing e-mail to flow to the server in the other routing group. Each
routing group also has an SMTP Connector. The SMTP connector in the
branch office uses the connector to send e-mail directly out to the
internet via their own connection. The SMTP connector in the office I
work in would like to use the connector to forward e-mail to Postini,
but has been using it to send mail out our own internet connection.
That's the setup. Here's what's happening:
1. I set SMTP connector to use Postini as a smart host. As I said
above, previously it had been working fine sending e-mail directly out
using DNS lookup.
2. So, e-mail begins flowing to the Postini server without issue.
3. After a while, someone will mistype a domain name or e-mail address
and send it out. For example, I tried to send an e-mail to
no...@nowhere.blah.
4. With SMTP Protocol logging set to medium on the Exchange server, an
event is recorded in the application event log saying:
--------------------
Event ID 7004
This is an SMTP protocol error log for virtual server ID 1, connection
#28. The remote host "64.18.4.12", responded to the SMTP command "rcpt"
with "550 Host not found for domain:nowhere.blah - psmtp ". The full
command sent was "RCPT TO: ". This will probably cause the connection
to fail.
--------------------
5. The last sentence in the event is absolutely correct. The
connection does fail and since the connection failed, the entire SMTP
Connector to the Postini server itself fails. With Routing
Engine/Service logging set to medium another event is recorded:
--------------------
Event ID 977
Following connector fails to connect to its target bridge head. [long
connector address omitted]
--------------------
Also, clicking on the connector queue in the queue window gives
"Additional queue information" as "The connection was dropped due to an
SMTP protocol event sink."
6. The first message sent outbound after that event fails, no matter
whether it's to allstate.com or sbcglobal.com or any other legitimate
domain. The rest of the messages are simply queued in the
non-functioning SMTP Connector queue. Here's the event log for the
failed message.
--------------------
Event ID: 7002
This is an SMTP protocol warning log for virtual server ID 1,
connection #30. The remote host "64.18.4.12", responded to the SMTP
command "rcpt" with "451 Cannot connect to domain:allstate.com - psmtp
". The full command sent was "RCPT TO:<[hidden for privacy]> ". This
may cause the connection to fail.
--------------------
7. The SMTP Connector queue continues to build over a period of 10 to
15 minutes as users continue to send outbound e-mail. Eventually,
another event is recorded:
--------------------
Event ID 974
On Master side, the following connector's linkstate is down. Process
Id: 1708 Process location: C:\WINDOWS\system32\inetsrv\inetinfo.exe
[connector address omitted again]
--------------------
8. At this point, all the existing e-mail is transferred to a "Messages
with an unreachable destination" mail queue and the status window lists
the SMTP Connector as "Unavailable".
9. Seconds later, another event is recorded:
--------------------
Event ID 978
Following connector now is ok to connect to its target bridge head.
[same connector address]
--------------------
10. The queue for the connector is marked with a green check and
cleared from the queue window a minute or two later. Another few
minutes roll by and this event is recorded:
--------------------
Event ID 973
On Master side, the following connector's linkstate is up. Process Id:
1708 Process location: C:\WINDOWS\system32\inetsrv\inetinfo.exe [same
connector address]
--------------------
11. At this point the SMTP Connector queue comes back in the queue
window and the substantial amount of jobs that have been queuing for
the past 25 to 30 minutes are transferred from the "Messages with an
unreachable destination" mail queue back to the SMTP Connector queue
where all or most of them are sent out. The status window lists the
connector as "Available" once again.
12. Repeat steps 2 through 11 when another message enters the queue or
is transferred back from the "Messages with an unreachable destination"
queue that has a misconfigured address or whose server is denying
e-mail too, etc... ...basically, any error at all that results in the
smart host denying transfer of the message.
I have played with this for the past 2 days. Nothing I do makes the
SMTP connector become more stable. There has to be other companies
that use Exchange 2003 SMTP connectors to forward outbound mail to
Postini or another equivlient service or setup like this. How are they
working around this issue?
Thanks for any advice or help.
Ed Crowley [MVP]
table entry that directs Exchange how to route mail.
I haven't worked with Postini, but it appears to me that it should not be
returning 550s. I think you probably have it configured wrong, as if your
Exchange server is an external server.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"
<nos...@i0ta.com> wrote in message
news:1160771974....@m7g2000cwm.googlegroups.com...
nos...@i0ta.com
your response, and I'm not sure you understand how Postini functions
either.
I did manage to finally get into Postini's knowledgebase however, and
dig up some information which I post here for you and for others to
benefit from who may have this issue in the future:
---------- Begin Quote from Postini Knowledgebase ----------
Postini's recommendation is to use Microsoft Exchange Connectors with
Postini's Outbound service. However, connectors expect a store and
forward relay (such as another Exchange server) to be receiving all of
its messages. If delivery of a message fails (either a 400-series
deferral or a 500-series error), the connector may stop delivering any
messages to the smarthost until the retry interval expires. Becaise of
this Postini recommends a short retry interval to avoid causing large
queue backups.
Postini's service does not store and forward. Instead, it acts as a
go-between, proxying information between the sender and the recipient.
If a receiving mail server returns a 400-series error to Postini
Outbound, then the SMTP error will be relayed back to the connector,
thus triggering a delay for all outbound messages. 400-series deferrals
can also be thrown by Postini itself, such as when it cannot connect to
the receiving SMTP server.
Other options include installing an additional connector to share the
queue load, installing a gateway server between the Exchange server and
Postini, such as a Microsoft IIS server, or configuring the smart host
in the SMTP Virtual Server instead of the connector. For more details
on these options, see the solutions entitled "Outbound: Configuring
smarthost for single-server MS Exchange 2000/2003" or "Outbound:
Configuring smarthost for multi-server MS Exchange 2000/2003".
Microsoft's IIS email service is a simple but effective mail server
which works consistently with Postini's outbound service. A gateway
server can also run a standalone instance of Exchange or a completely
different platform, such as Sendmail or Postfix on a Unix/Linux
machine.
---------- End Quote from Postini Knowledgebase ----------
So, it's interesting that the SMTP Connector, when set to forward mail
to a smart host, does not behave the same as it does when set to send
e-mail directly out to the Internet. As I posted previously, the
company had been sending it out direct for quite some time without
issues. And there are plenty of times everyday when a recipient's
server returns an error. But, it never halted all other outgoing
e-mail because of it.
Anyway, looks like my solutions are:
1. Decrease the retry level in Exchange, as stated in the KB article
above.
2. Create 5 or 6 duplicate SMTP Connectors all with the same Address
Space and Cost so that they will load balance minimizing the effect of
a failed connector or two or three.
3. Create another SMTP Virtual Server in Exchange and use that somehow
to send the mail to Postini, since setting the smart host option on the
Virtual Server itself works fine.
4. Setup another IIS Server with the SMTP service that can be used to
accept mail from Exchange and route it to Postini.
Hopefully this will be of use to others with a similar issue.
Rich Matheisen [MVP]
[ snip ]
>I have played with this for the past 2 days. Nothing I do makes the
>SMTP connector become more stable. There has to be other companies
>that use Exchange 2003 SMTP connectors to forward outbound mail to
>Postini or another equivlient service or setup like this. How are they
>working around this issue?
--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com
nos...@i0ta.com
than I thought it would. When I first read it, I understood this
sentence:
"When SuppressStateChanges is set to a value of 1 (or any value greater
than 0), all link state traffic generated by a connector state change
on this Exchange Server computer are suppressed."
...to mean that the link state change is not going to be replicated to
the other server in my environment. But it has worked better than that
for me. It has actually caused the SMTP Connector to not register
itself as failed at all when receiving a 500 or 400 series error from
the destination server, thereby keeping the SMTP Connector from cycling
Available/Unavailable and backing up the queue. Thanks again.
For others who run across this thread, I have my server setup with the
registry change that Rich recommended above, all externally bound
e-mail routing through a SMTP Connector with a defined smart host
(Postini), and the SMTP Virtual Server retry suggestions given by
Postini in their knowledgebase, which are:
First retry interval (minutes): 1
Second retry interval (minutes): 1
Third retry interval (minutes): 3
Subsequent retry interval (minutes): 5
I've been running for 3 days like that without an issue and I am
starting to believe that the problem has been fixed.
Rich Matheisen [MVP]
>Rich, thank you very much for that tip. That helped quite a bit more
>than I thought it would. When I first read it, I understood this
>sentence:
[ snip ]
>First retry interval (minutes): 1
>Second retry interval (minutes): 1
>Third retry interval (minutes): 3
>Subsequent retry interval (minutes): 5
>
>I've been running for 3 days like that without an issue and I am
>starting to believe that the problem has been fixed.
And it that doesn't help enough, you can also shorten the "Glitch
Retry Interval" so there isn't a 1 minute wait between retrying a
"server busy" status. Since Postini is acting as a proxy and not a
relay that might be affecting you, too: