We use the Microsoft Exchange Hosted Filtering Service for all of our inbound 
and outbound e-mail.  Lately, we have had a large spike in e-mails with large 
attachments that are not coming through in a timely fashion.  It seemed to 
get worse after we applied SP2 for server 2003, but there were deferrals 
before that point, so it is hard to say if that is conclusive.  We use CA 
etrust AV connector for Exchange V7.0, which I have disabled (did not seem to 
make much difference), then uninstalled (as per a forum post which said that 
as AV sinks are tightly integrated with Exchange, disabling alone might not 
resolve the problem).  There seemed to be some improvement after uninstalling 
the AV connector, but that is hard to say.  I am basing it off the number of 
messages in deferral at any given time.

If I run a deferral report in the EHS admin centre, these are the types of 
messages I am seeing:

2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed out 
while sending message body 

 2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed out 
while sending end of data -- message may be sent more than once.

The problem only seems to occur with messages with large attachments (above 
1.5 MB).  EHS tech support has not been much help, as they say the problem is 
on our end.

Also, if I look at "current sessions" under the SMTP virtual server, there 
are usually several (up to ten at a time) sessions in there from the EHS 
servers (SMTP is closed to all other IPs) with connected times sometimes over 
600 seconds (I think EHS times out after approx. 10 minutes).

Researching this problem has not turned up much.  The "path MTU discovery" 
issue comes up frequently, but that would be a problem for outbound e-mail, 
not inbound.

I am not enough of a network guru to analyze this with packet traces.  Any 
suggestions?

We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our 
internet connection is a fixed wireless, 1.5 MB symettrical.

Just to be clear, this is for inbound messages coming from EHS to you, 
correct? And outbound messages bound for EHS are working fine?

Perhaps something with the Astaro appliance? I'm not familiar with them - is 
it newly added to your configuration or have you recently change the 
setup/software on it?

"Glen Martin" <Silmarillion@community.nospam> wrote in message 
news:D5CF0BC0-B039-431C-AA22-F7561318DA36@microsoft.com...
> We use the Microsoft Exchange Hosted Filtering Service for all of our 
> inbound
> and outbound e-mail.  Lately, we have had a large spike in e-mails with 
> large
> attachments that are not coming through in a timely fashion.  It seemed to
> get worse after we applied SP2 for server 2003, but there were deferrals
> before that point, so it is hard to say if that is conclusive.  We use CA
> etrust AV connector for Exchange V7.0, which I have disabled (did not seem 
> to
> make much difference), then uninstalled (as per a forum post which said 
> that
> as AV sinks are tightly integrated with Exchange, disabling alone might 
> not
> resolve the problem).  There seemed to be some improvement after 
> uninstalling
> the AV connector, but that is hard to say.  I am basing it off the number 
> of
> messages in deferral at any given time.
>
> If I run a deferral report in the EHS admin centre, these are the types of
> messages I am seeing:
>
> 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed out
> while sending message body
>
> 2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed out
> while sending end of data -- message may be sent more than once.
>
> The problem only seems to occur with messages with large attachments 
> (above
> 1.5 MB).  EHS tech support has not been much help, as they say the problem 
> is
> on our end.
>
> Also, if I look at "current sessions" under the SMTP virtual server, there
> are usually several (up to ten at a time) sessions in there from the EHS
> servers (SMTP is closed to all other IPs) with connected times sometimes 
> over
> 600 seconds (I think EHS times out after approx. 10 minutes).
>
> Researching this problem has not turned up much.  The "path MTU discovery"
> issue comes up frequently, but that would be a problem for outbound 
> e-mail,
> not inbound.
>
> I am not enough of a network guru to analyze this with packet traces.  Any
> suggestions?
>
> We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our
> internet connection is a fixed wireless, 1.5 MB symettrical.

Yes, this is for inbound messages.  I assume outbound is working correctly - 
I have not had any complaints (whereas I have had numerous complaints about 
inbound).

The deferral messages are a bit of a unique tool, as they let me see the 
messages on the sending server.  Normally I would not know what was happening 
on the sending server, if we did not use EHS.

The Astaro is a Linux-based appliance, and it is not new - we have been 
using it for a couple of years.  There has not been any major changes on it 
recently.

"Michael Dragone" wrote:

> Just to be clear, this is for inbound messages coming from EHS to you, 
> correct? And outbound messages bound for EHS are working fine?
> 
> Perhaps something with the Astaro appliance? I'm not familiar with them - is 
> it newly added to your configuration or have you recently change the 
> setup/software on it?
> 
> "Glen Martin" <Silmarillion@community.nospam> wrote in message 
> news:D5CF0BC0-B039-431C-AA22-F7561318DA36@microsoft.com...
> > We use the Microsoft Exchange Hosted Filtering Service for all of our 
> > inbound
> > and outbound e-mail.  Lately, we have had a large spike in e-mails with 
> > large
> > attachments that are not coming through in a timely fashion.  It seemed to
> > get worse after we applied SP2 for server 2003, but there were deferrals
> > before that point, so it is hard to say if that is conclusive.  We use CA
> > etrust AV connector for Exchange V7.0, which I have disabled (did not seem 
> > to
> > make much difference), then uninstalled (as per a forum post which said 
> > that
> > as AV sinks are tightly integrated with Exchange, disabling alone might 
> > not
> > resolve the problem).  There seemed to be some improvement after 
> > uninstalling
> > the AV connector, but that is hard to say.  I am basing it off the number 
> > of
> > messages in deferral at any given time.
> >
> > If I run a deferral report in the EHS admin centre, these are the types of
> > messages I am seeing:
> >
> > 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed out
> > while sending message body
> >
> > 2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed out
> > while sending end of data -- message may be sent more than once.
> >
> > The problem only seems to occur with messages with large attachments 
> > (above
> > 1.5 MB).  EHS tech support has not been much help, as they say the problem 
> > is
> > on our end.
> >
> > Also, if I look at "current sessions" under the SMTP virtual server, there
> > are usually several (up to ten at a time) sessions in there from the EHS
> > servers (SMTP is closed to all other IPs) with connected times sometimes 
> > over
> > 600 seconds (I think EHS times out after approx. 10 minutes).
> >
> > Researching this problem has not turned up much.  The "path MTU discovery"
> > issue comes up frequently, but that would be a problem for outbound 
> > e-mail,
> > not inbound.
> >
> > I am not enough of a network guru to analyze this with packet traces.  Any
> > suggestions?
> >
> > We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our
> > internet connection is a fixed wireless, 1.5 MB symettrical. 
>

Hello Customer,

Thank you for posting here.

According to your description, I understand that some big income email will 
delay. If I have misunderstood the problem, please don't hesitate to let me 
know.

Based on my research, I suggest we try the following steps to narrow down 
this issue:

1. Check your Exchange SMTP log to see if the email receive your Exchange 
server:

Enable SMTP logging and gather SMTP log to troubleshoot the issue:
 
A. Open Exchange System Manager, expand Servers -> <Server name> -> 
Protocols -> SMTP, right-click "Default SMTP Virtual Server" and click 
Properties.
 
B. Under the General tab, check the option "Enable Logging".
 
C. With "W3C Extended Log File Format", click "Properties".
 
D. Under "General Properties", make sure "Use local time for file naming 
and rollover" is CHECKED.
 
E. Switch to the "Extended Properties", and then select to enable All the 
logging Options.
 
F. Click OK to apply the modification.
 
G. Right-click Default SMTP Virtual Server and click Stop.
 
H. Right-click Default SMTP Virtual Server and click Start to restart the 
SMTP server.
 
I. Reproduce the issue, repeat step G to stop Default SMTP Virtual Server, 
copy out or zip the SMTP log files in the 
"%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart the 
"Default SMTP Virtual Server". 

2. Use the Message Tracking to track the email:

a. Enable Message Tracking on by right-click your Exchange server in ESM 
and click Properties.

For more information, please check the "Message Tracking" section in the 
following KB article.
257265 XCON: General Troubleshooting for Exchange 2000 Transport Issues
http://support.microsoft.com/kb/257265/en-us

b. Please:

a) Search for the message in Tools \ Message Tracking Centre. (You can use 
the "Sender" "Recipients" as search criteria.)
b) Double click to open it.
c) Post the error information here.
 
3. Please try to bypass the Astaro firewall and test this issue.

4. I suggest performing the following steps to determine the MTU setting:

On the SBS server:
1). To get the MTU Size maximum, you may need to have the following command 
on one of internal client connected to SBS server directly. 
ping <SBS_IP_address> -f -l <packet_size>
and on SBS server, please ping the POP3 mail server with following command
ping <POP3MailServer_IP_address> -f -l <packet_size>
Being:
<SBS_IP_address or POP3MailServer_IP_address > - the IP address from the 
internal network.
<packet_size> - the packet size to test the maximum MTU packet size. 
You can use some <packet_size> parameters to get the packet ideal size. 
This can be identified by the ping results, for example, ping 192.168.18.8 
-f -l 5000 
If the ping result is like below: 

Pinging [192.168.18.8] with 5000 bytes of data: 
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set. 
Ping statistics for 192.168.18.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
 
You may need to decrease the <packet_size> until encounter a non fragmented 
packet size the link can answer like below: 

Pinging [192.168.18.8] with 1472 bytes of data: 
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128 
Ping statistics for 192.168.18.8:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
Or else, in this case, the maximum MTU Size is 1472. It is the default 
number for SBS 2k3 server. 

If the router Maximum MTU size is smaller than the one on the SBS server, 
you may need following steps:
Modifying the MTU Size: 
1)Go to the key: 
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
ces
2)Go the key corresponding to the NIC GUID
3)Create a Dword parameter 'MTU' with the value small than router size
4)Restart the client machine
 
References:
Diagnoses and Treatment of Black Hole Routers
http://support.microsoft.com/?id=159211
TCP/IP and NBT Configuration Parameters for Windows XP
http://support.microsoft.com/?id=314053

I hope these steps will give you some help. 

Thanks and have a nice day!

Best regards,

Terence Liu(MSFT)

Microsoft CSS Online Newsgroup Support

Get Secure! - www.microsoft.com/security

=====================================================
This newsgroup only focuses on Exchange technical issues. If you have 
issues regarding other Microsoft products, you'd better post in the 
corresponding newsgroups so that they can be resolved in an efficient and 
timely manner. You can locate the newsgroup here: 
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx

When opening a new thread via the web interface, we recommend you check the 
"Notify me of replies" box to receive e-mail notifications when there are 
any updates in your thread. When responding to posts via your newsreader, 
please "Reply to Group" so that others may learn and benefit from your 
issue.

Microsoft engineers can only focus on one issue per thread. Although we 
provide other information for your reference, we recommend you post 
different incidents in different threads to keep the thread clean. In doing 
so, it will ensure your issues are resolved in a timely manner. 

For urgent issues, you may want to contact Microsoft CSS directly. Please 
check http://support.microsoft.com for regional support phone numbers.

Any input or comments in this thread are highly appreciated.
=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Thread-Topic: Message deferrals from EHS
| thread-index: Ach5juSIzi7dCMESR2SKm3YzoCpozw==
| X-WBNR-Posting-Host: 207.46.19.168
| From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
| Subject: Message deferrals from EHS
| Date: Wed, 27 Feb 2008 14:20:00 -0800
| Lines: 39
| Message-ID: 
| MIME-Version: 1.0
| Content-Type: text/plain;
| 	charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
| Newsgroups: microsoft.public.exchange.connectivity
| Path: TK2MSFTNGHUB02.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.exchange.connectivity:3595
| NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
| X-Tomcat-NG: microsoft.public.exchange.connectivity
| 
| We use the Microsoft Exchange Hosted Filtering Service for all of our 
inbound 
| and outbound e-mail.  Lately, we have had a large spike in e-mails with 
large 
| attachments that are not coming through in a timely fashion.  It seemed 
to 
| get worse after we applied SP2 for server 2003, but there were deferrals 
| before that point, so it is hard to say if that is conclusive.  We use CA 
| etrust AV connector for Exchange V7.0, which I have disabled (did not 
seem to 
| make much difference), then uninstalled (as per a forum post which said 
that 
| as AV sinks are tightly integrated with Exchange, disabling alone might 
not 
| resolve the problem).  There seemed to be some improvement after 
uninstalling 
| the AV connector, but that is hard to say.  I am basing it off the number 
of 
| messages in deferral at any given time.
| 
| If I run a deferral report in the EHS admin centre, these are the types 
of 
| messages I am seeing:
| 
| 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed out 
| while sending message body 
| 
|  2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed out 
| while sending end of data -- message may be sent more than once.
| 
| The problem only seems to occur with messages with large attachments 
(above 
| 1.5 MB).  EHS tech support has not been much help, as they say the 
problem is 
| on our end.
| 
| Also, if I look at "current sessions" under the SMTP virtual server, 
there 
| are usually several (up to ten at a time) sessions in there from the EHS 
| servers (SMTP is closed to all other IPs) with connected times sometimes 
over 
| 600 seconds (I think EHS times out after approx. 10 minutes).
| 
| Researching this problem has not turned up much.  The "path MTU 
discovery" 
| issue comes up frequently, but that would be a problem for outbound 
e-mail, 
| not inbound.
| 
| I am not enough of a network guru to analyze this with packet traces.  
Any 
| suggestions?
| 
| We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our 
| internet connection is a fixed wireless, 1.5 MB symettrical.
|

Any logging on the Astaro give us any clues?

"Glen Martin" <Silmarillion@community.nospam> wrote in message 
news:4732DC41-82A4-4F71-99D6-606C33197B41@microsoft.com...
> Yes, this is for inbound messages.  I assume outbound is working 
> correctly -
> I have not had any complaints (whereas I have had numerous complaints 
> about
> inbound).
>
> The deferral messages are a bit of a unique tool, as they let me see the
> messages on the sending server.  Normally I would not know what was 
> happening
> on the sending server, if we did not use EHS.
>
> The Astaro is a Linux-based appliance, and it is not new - we have been
> using it for a couple of years.  There has not been any major changes on 
> it
> recently.
>
> "Michael Dragone" wrote:
>
>> Just to be clear, this is for inbound messages coming from EHS to you,
>> correct? And outbound messages bound for EHS are working fine?
>>
>> Perhaps something with the Astaro appliance? I'm not familiar with them - 
>> is
>> it newly added to your configuration or have you recently change the
>> setup/software on it?
>>
>> "Glen Martin" <Silmarillion@community.nospam> wrote in message
>> news:D5CF0BC0-B039-431C-AA22-F7561318DA36@microsoft.com...
>> > We use the Microsoft Exchange Hosted Filtering Service for all of our
>> > inbound
>> > and outbound e-mail.  Lately, we have had a large spike in e-mails with
>> > large
>> > attachments that are not coming through in a timely fashion.  It seemed 
>> > to
>> > get worse after we applied SP2 for server 2003, but there were 
>> > deferrals
>> > before that point, so it is hard to say if that is conclusive.  We use 
>> > CA
>> > etrust AV connector for Exchange V7.0, which I have disabled (did not 
>> > seem
>> > to
>> > make much difference), then uninstalled (as per a forum post which said
>> > that
>> > as AV sinks are tightly integrated with Exchange, disabling alone might
>> > not
>> > resolve the problem).  There seemed to be some improvement after
>> > uninstalling
>> > the AV connector, but that is hard to say.  I am basing it off the 
>> > number
>> > of
>> > messages in deferral at any given time.
>> >
>> > If I run a deferral report in the EHS admin centre, these are the types 
>> > of
>> > messages I am seeing:
>> >
>> > 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed 
>> > out
>> > while sending message body
>> >
>> > 2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed 
>> > out
>> > while sending end of data -- message may be sent more than once.
>> >
>> > The problem only seems to occur with messages with large attachments
>> > (above
>> > 1.5 MB).  EHS tech support has not been much help, as they say the 
>> > problem
>> > is
>> > on our end.
>> >
>> > Also, if I look at "current sessions" under the SMTP virtual server, 
>> > there
>> > are usually several (up to ten at a time) sessions in there from the 
>> > EHS
>> > servers (SMTP is closed to all other IPs) with connected times 
>> > sometimes
>> > over
>> > 600 seconds (I think EHS times out after approx. 10 minutes).
>> >
>> > Researching this problem has not turned up much.  The "path MTU 
>> > discovery"
>> > issue comes up frequently, but that would be a problem for outbound
>> > e-mail,
>> > not inbound.
>> >
>> > I am not enough of a network guru to analyze this with packet traces. 
>> > Any
>> > suggestions?
>> >
>> > We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our
>> > internet connection is a fixed wireless, 1.5 MB symettrical.
>>

Not sure - I am in a bit over my head on this one.  I am not even sure what 
to look for.  We do not use an SMTP proxy, but we do use IPS rules.

I will post the SMTP logs as per Terrence's post - hopefully that is a good 
starting point.  Would be nice to at least narrow it down.

I will post the

"Michael Dragone" wrote:

> Any logging on the Astaro give us any clues?
> 
> "Glen Martin" <Silmarillion@community.nospam> wrote in message 
> news:4732DC41-82A4-4F71-99D6-606C33197B41@microsoft.com...
> > Yes, this is for inbound messages.  I assume outbound is working 
> > correctly -
> > I have not had any complaints (whereas I have had numerous complaints 
> > about
> > inbound).
> >
> > The deferral messages are a bit of a unique tool, as they let me see the
> > messages on the sending server.  Normally I would not know what was 
> > happening
> > on the sending server, if we did not use EHS.
> >
> > The Astaro is a Linux-based appliance, and it is not new - we have been
> > using it for a couple of years.  There has not been any major changes on 
> > it
> > recently.
> >
> > "Michael Dragone" wrote:
> >
> >> Just to be clear, this is for inbound messages coming from EHS to you,
> >> correct? And outbound messages bound for EHS are working fine?
> >>
> >> Perhaps something with the Astaro appliance? I'm not familiar with them - 
> >> is
> >> it newly added to your configuration or have you recently change the
> >> setup/software on it?
> >>
> >> "Glen Martin" <Silmarillion@community.nospam> wrote in message
> >> news:D5CF0BC0-B039-431C-AA22-F7561318DA36@microsoft.com...
> >> > We use the Microsoft Exchange Hosted Filtering Service for all of our
> >> > inbound
> >> > and outbound e-mail.  Lately, we have had a large spike in e-mails with
> >> > large
> >> > attachments that are not coming through in a timely fashion.  It seemed 
> >> > to
> >> > get worse after we applied SP2 for server 2003, but there were 
> >> > deferrals
> >> > before that point, so it is hard to say if that is conclusive.  We use 
> >> > CA
> >> > etrust AV connector for Exchange V7.0, which I have disabled (did not 
> >> > seem
> >> > to
> >> > make much difference), then uninstalled (as per a forum post which said
> >> > that
> >> > as AV sinks are tightly integrated with Exchange, disabling alone might
> >> > not
> >> > resolve the problem).  There seemed to be some improvement after
> >> > uninstalling
> >> > the AV connector, but that is hard to say.  I am basing it off the 
> >> > number
> >> > of
> >> > messages in deferral at any given time.
> >> >
> >> > If I run a deferral report in the EHS admin centre, these are the types 
> >> > of
> >> > messages I am seeing:
> >> >
> >> > 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed 
> >> > out
> >> > while sending message body
> >> >
> >> > 2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed 
> >> > out
> >> > while sending end of data -- message may be sent more than once.
> >> >
> >> > The problem only seems to occur with messages with large attachments
> >> > (above
> >> > 1.5 MB).  EHS tech support has not been much help, as they say the 
> >> > problem
> >> > is
> >> > on our end.
> >> >
> >> > Also, if I look at "current sessions" under the SMTP virtual server, 
> >> > there
> >> > are usually several (up to ten at a time) sessions in there from the 
> >> > EHS
> >> > servers (SMTP is closed to all other IPs) with connected times 
> >> > sometimes
> >> > over
> >> > 600 seconds (I think EHS times out after approx. 10 minutes).
> >> >
> >> > Researching this problem has not turned up much.  The "path MTU 
> >> > discovery"
> >> > issue comes up frequently, but that would be a problem for outbound
> >> > e-mail,
> >> > not inbound.
> >> >
> >> > I am not enough of a network guru to analyze this with packet traces. 
> >> > Any
> >> > suggestions?
> >> >
> >> > We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our
> >> > internet connection is a fixed wireless, 1.5 MB symettrical.
> >> 
>

Hi Terrence,

Thanks for all your suggestions.  I enabled the logs for a while this 
morning, long enough to capture several of the timeout messages.  What can I 
do with them to get them to you?  I cannot attach a file to a post to the 
forums, and the file is too large to just paste in-line in a post.

I have checked again with EHS tech support about the number of deferrals 
that I am seeing, and they have confirmed that it is not normal to see that 
many on an ongoing basis.  Also, some of the deferred messages do eventually 
get through.  I have one with a 6MB attachemtn that I sent to my address here 
from my home address.  It was sent Tuesday at 2:05 pm, and did not arrive in 
my mailbox here until today at 10:57 am.

A few more questions:

How can message tracing help me with this problem?  The affected messages 
are not being delivered in a timely fashion, and I am assuming I can not 
track a message which has not yet been received.  Sorry for my ignorance on 
this.

As we are not a large business, I am not sure what I can do to bypass the 
firewall.  I do not want to open my mail server up to any unecessary risks.  
We only have one firewall and one internet connection for the whole company.  
Any suggestions on methodology to eliminate the firewall as a possibile issue?

I have verified the server MTU is 1472 (your post mentioned SBS - we are 
running Server 2003 Standard Edition SP2), but as I mentioned in my previous 
post, that would apply to our outbound e-mail, whereas I am trying to 
troubleshoot inbound mail.  If the MTU is a problem, it would be on the EHS 
side.

Thanks for the help so far!

"Terence Liu [MSFT]" wrote:

> Hello Customer,
> 
> Thank you for posting here.
> 
> According to your description, I understand that some big income email will 
> delay. If I have misunderstood the problem, please don't hesitate to let me 
> know.
> 
> Based on my research, I suggest we try the following steps to narrow down 
> this issue:
> 
> 1. Check your Exchange SMTP log to see if the email receive your Exchange 
> server:
> 
> Enable SMTP logging and gather SMTP log to troubleshoot the issue:
>  
> A. Open Exchange System Manager, expand Servers -> <Server name> -> 
> Protocols -> SMTP, right-click "Default SMTP Virtual Server" and click 
> Properties.
>  
> B. Under the General tab, check the option "Enable Logging".
>  
> C. With "W3C Extended Log File Format", click "Properties".
>  
> D. Under "General Properties", make sure "Use local time for file naming 
> and rollover" is CHECKED.
>  
> E. Switch to the "Extended Properties", and then select to enable All the 
> logging Options.
>  
> F. Click OK to apply the modification.
>  
> G. Right-click Default SMTP Virtual Server and click Stop.
>  
> H. Right-click Default SMTP Virtual Server and click Start to restart the 
> SMTP server.
>  
> I. Reproduce the issue, repeat step G to stop Default SMTP Virtual Server, 
> copy out or zip the SMTP log files in the 
> "%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart the 
> "Default SMTP Virtual Server". 
> 
> 2. Use the Message Tracking to track the email:
> 
> a. Enable Message Tracking on by right-click your Exchange server in ESM 
> and click Properties.
> 
> For more information, please check the "Message Tracking" section in the 
> following KB article.
> 257265 XCON: General Troubleshooting for Exchange 2000 Transport Issues
> http://support.microsoft.com/kb/257265/en-us
> 
> b. Please:
> 
> a) Search for the message in Tools \ Message Tracking Centre. (You can use 
> the "Sender" "Recipients" as search criteria.)
> b) Double click to open it.
> c) Post the error information here.
>  
> 3. Please try to bypass the Astaro firewall and test this issue.
> 
> 4. I suggest performing the following steps to determine the MTU setting:
> 
> On the SBS server:
> 1). To get the MTU Size maximum, you may need to have the following command 
> on one of internal client connected to SBS server directly. 
> ping <SBS_IP_address> -f -l <packet_size>
> and on SBS server, please ping the POP3 mail server with following command
> ping <POP3MailServer_IP_address> -f -l <packet_size>
> Being:
> <SBS_IP_address or POP3MailServer_IP_address > - the IP address from the 
> internal network.
> <packet_size> - the packet size to test the maximum MTU packet size. 
> You can use some <packet_size> parameters to get the packet ideal size. 
> This can be identified by the ping results, for example, ping 192.168.18.8 
> -f -l 5000 
> If the ping result is like below: 
> 
> Pinging [192.168.18.8] with 5000 bytes of data: 
> Packet needs to be fragmented but DF set.
> Packet needs to be fragmented but DF set.
> Packet needs to be fragmented but DF set.
> Packet needs to be fragmented but DF set. 
> Ping statistics for 192.168.18.8:
> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>  
> You may need to decrease the <packet_size> until encounter a non fragmented 
> packet size the link can answer like below: 
> 
> Pinging [192.168.18.8] with 1472 bytes of data: 
> Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128 
> Ping statistics for 192.168.18.8:
>  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
> Approximate round trip times in milli-seconds:
>     Minimum = 0ms, Maximum = 0ms, Average = 0ms
>  
> Or else, in this case, the maximum MTU Size is 1472. It is the default 
> number for SBS 2k3 server. 
> 
> If the router Maximum MTU size is smaller than the one on the SBS server, 
> you may need following steps:
> Modifying the MTU Size: 
> 1)Go to the key: 
> KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
> ces
> 2)Go the key corresponding to the NIC GUID
> 3)Create a Dword parameter 'MTU' with the value small than router size
> 4)Restart the client machine
>  
> References:
> Diagnoses and Treatment of Black Hole Routers
> http://support.microsoft.com/?id=159211
> TCP/IP and NBT Configuration Parameters for Windows XP
> http://support.microsoft.com/?id=314053
> 
> I hope these steps will give you some help. 
> 
> Thanks and have a nice day!
> 
> Best regards,
> 
> Terence Liu(MSFT)
> 
> Microsoft CSS Online Newsgroup Support
> 
> Get Secure! - www.microsoft.com/security
> 
> =====================================================
> This newsgroup only focuses on Exchange technical issues. If you have 
> issues regarding other Microsoft products, you'd better post in the 
> corresponding newsgroups so that they can be resolved in an efficient and 
> timely manner. You can locate the newsgroup here: 
> http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
> 
> When opening a new thread via the web interface, we recommend you check the 
> "Notify me of replies" box to receive e-mail notifications when there are 
> any updates in your thread. When responding to posts via your newsreader, 
> please "Reply to Group" so that others may learn and benefit from your 
> issue.
> 
> Microsoft engineers can only focus on one issue per thread. Although we 
> provide other information for your reference, we recommend you post 
> different incidents in different threads to keep the thread clean. In doing 
> so, it will ensure your issues are resolved in a timely manner. 
> 
> For urgent issues, you may want to contact Microsoft CSS directly. Please 
> check http://support.microsoft.com for regional support phone numbers.
> 
> Any input or comments in this thread are highly appreciated.
> =====================================================
> 
> This posting is provided "AS IS" with no warranties, and confers no rights.
> 
> --------------------
> | Thread-Topic: Message deferrals from EHS
> | thread-index: Ach5juSIzi7dCMESR2SKm3YzoCpozw==
> | X-WBNR-Posting-Host: 207.46.19.168
> | From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
> | Subject: Message deferrals from EHS
> | Date: Wed, 27 Feb 2008 14:20:00 -0800
> | Lines: 39
> | Message-ID: 
> | MIME-Version: 1.0
> | Content-Type: text/plain;
> | 	charset="Utf-8"
> | Content-Transfer-Encoding: 7bit
> | X-Newsreader: Microsoft CDO for Windows 2000
> | Content-Class: urn:content-classes:message
> | Importance: normal
> | Priority: normal
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
> | Newsgroups: microsoft.public.exchange.connectivity
> | Path: TK2MSFTNGHUB02.phx.gbl
> | Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.exchange.connectivity:3595
> | NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
> | X-Tomcat-NG: microsoft.public.exchange.connectivity
> | 
> | We use the Microsoft Exchange Hosted Filtering Service for all of our 
> inbound 
> | and outbound e-mail.  Lately, we have had a large spike in e-mails with 
> large 
> | attachments that are not coming through in a timely fashion.  It seemed 
> to 
> | get worse after we applied SP2 for server 2003, but there were deferrals 
> | before that point, so it is hard to say if that is conclusive.  We use CA 
> | etrust AV connector for Exchange V7.0, which I have disabled (did not 
> seem to 
> | make much difference), then uninstalled (as per a forum post which said 
> that 
> | as AV sinks are tightly integrated with Exchange, disabling alone might 
> not 
> | resolve the problem).  There seemed to be some improvement after 
> uninstalling 
> | the AV connector, but that is hard to say.  I am basing it off the number 
> of 
> | messages in deferral at any given time.
> | 
> | If I run a deferral report in the EHS admin centre, these are the types 
> of 
> | messages I am seeing:
> | 
> | 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed out 
> | while sending message body 
> | 
> |  2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed out 
> | while sending end of data -- message may be sent more than once.
> | 
> | The problem only seems to occur with messages with large attachments 
> (above 
> | 1.5 MB).  EHS tech support has not been much help, as they say the 
> problem is 
> | on our end.
> | 
> | Also, if I look at "current sessions" under the SMTP virtual server, 
> there 
> | are usually several (up to ten at a time) sessions in there from the EHS 
> | servers (SMTP is closed to all other IPs) with connected times sometimes 
> over 
> | 600 seconds (I think EHS times out after approx. 10 minutes).
> | 
> | Researching this problem has not turned up much.  The "path MTU 
> discovery" 
> | issue comes up frequently, but that would be a problem for outbound 
> e-mail, 
> | not inbound.
> | 
> | I am not enough of a network guru to analyze this with packet traces.  
> Any 
> | suggestions?
> | 
> | We are using Exchange 2003 SP2, with an Astaro firewall appliance.  Our 
> | internet connection is a fixed wireless, 1.5 MB symettrical.
> | 
> 
>

Hello Customer,

Thank you for your update.

We enable the message tracing on Exchange to see if the delay email 
receive, and if the delay is caused by Exchange. From your description, the 
delay email cannot be tracked in Exchange, that means the delay is not 
cause by the Exchange mailflow. 

I think this issue is mostly related to the following factors:

1. Public DNS (A and MX record)
2. Your Firewall
3. The EHS
4. The bad Internet connection

Let's analyze this issue. If the delay only happen on big size mail, I 
think this issue will not be the DNS issue. If the big size outbound emails 
do not have delay issue, I think this will not be a Internet connection 
issue. 

Now, mostly this is a EHS issue or your firewall issue. To bypass your 
firewall temporary to narrow down this issue, you need to contact the 
firewall vendor to get help.

I strongly suggest you contact the EHS provide to verify this issue.

Hope the information give you some help.

Thanks and have a nice day!

Best regards,

Terence Liu(MSFT)

Microsoft CSS Online Newsgroup Support

Get Secure! - www.microsoft.com/security

=====================================================
This newsgroup only focuses on SBS technical issues. If you have issues 
regarding other Microsoft products, you'd better post in the corresponding 
newsgroups so that they can be resolved in an efficient and timely manner. 
You can locate the newsgroup here: 
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx

When opening a new thread via the web interface, we recommend you check the 
"Notify me of replies" box to receive e-mail notifications when there are 
any updates in your thread. When responding to posts via your newsreader, 
please "Reply to Group" so that others may learn and benefit from your 
issue.

Microsoft engineers can only focus on one issue per thread. Although we 
provide other information for your reference, we recommend you post 
different incidents in different threads to keep the thread clean. In doing 
so, it will ensure your issues are resolved in a timely manner. 

For urgent issues, you may want to contact Microsoft CSS directly. Please 
check http://support.microsoft.com for regional support phone numbers.

Any input or comments in this thread are highly appreciated.
=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Thread-Topic: Message deferrals from EHS
| thread-index: Ach6XIiyyCufaXu8QZeAwpp0iC/ztg==
| X-WBNR-Posting-Host: 207.46.192.207
| From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
| References:   
<Box5$pfeIHA.1500@TK2MSFTNGHUB02.phx.gbl>
| Subject: RE: Message deferrals from EHS
| Date: Thu, 28 Feb 2008 14:52:02 -0800
| Lines: 274
| Message-ID: 
| MIME-Version: 1.0
| Content-Type: text/plain;
| 	charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
| Newsgroups: microsoft.public.exchange.connectivity
| Path: TK2MSFTNGHUB02.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.exchange.connectivity:3611
| NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
| X-Tomcat-NG: microsoft.public.exchange.connectivity
| 
| Hi Terrence,
| 
| Thanks for all your suggestions.  I enabled the logs for a while this 
| morning, long enough to capture several of the timeout messages.  What 
can I 
| do with them to get them to you?  I cannot attach a file to a post to the 
| forums, and the file is too large to just paste in-line in a post.
| 
| I have checked again with EHS tech support about the number of deferrals 
| that I am seeing, and they have confirmed that it is not normal to see 
that 
| many on an ongoing basis.  Also, some of the deferred messages do 
eventually 
| get through.  I have one with a 6MB attachemtn that I sent to my address 
here 
| from my home address.  It was sent Tuesday at 2:05 pm, and did not arrive 
in 
| my mailbox here until today at 10:57 am.
| 
| A few more questions:
| 
| How can message tracing help me with this problem?  The affected messages 
| are not being delivered in a timely fashion, and I am assuming I can not 
| track a message which has not yet been received.  Sorry for my ignorance 
on 
| this.
| 
| As we are not a large business, I am not sure what I can do to bypass the 
| firewall.  I do not want to open my mail server up to any unecessary 
risks.  
| We only have one firewall and one internet connection for the whole 
company.  
| Any suggestions on methodology to eliminate the firewall as a possibile 
issue?
| 
| I have verified the server MTU is 1472 (your post mentioned SBS - we are 
| running Server 2003 Standard Edition SP2), but as I mentioned in my 
previous 
| post, that would apply to our outbound e-mail, whereas I am trying to 
| troubleshoot inbound mail.  If the MTU is a problem, it would be on the 
EHS 
| side.
| 
| Thanks for the help so far!
| 
| "Terence Liu [MSFT]" wrote:
| 
| > Hello Customer,
| > 
| > Thank you for posting here.
| > 
| > According to your description, I understand that some big income email 
will 
| > delay. If I have misunderstood the problem, please don't hesitate to 
let me 
| > know.
| > 
| > Based on my research, I suggest we try the following steps to narrow 
down 
| > this issue:
| > 
| > 1. Check your Exchange SMTP log to see if the email receive your 
Exchange 
| > server:
| > 
| > Enable SMTP logging and gather SMTP log to troubleshoot the issue:
| >  
| > A. Open Exchange System Manager, expand Servers -> <Server name> -> 
| > Protocols -> SMTP, right-click "Default SMTP Virtual Server" and click 
| > Properties.
| >  
| > B. Under the General tab, check the option "Enable Logging".
| >  
| > C. With "W3C Extended Log File Format", click "Properties".
| >  
| > D. Under "General Properties", make sure "Use local time for file 
naming 
| > and rollover" is CHECKED.
| >  
| > E. Switch to the "Extended Properties", and then select to enable All 
the 
| > logging Options.
| >  
| > F. Click OK to apply the modification.
| >  
| > G. Right-click Default SMTP Virtual Server and click Stop.
| >  
| > H. Right-click Default SMTP Virtual Server and click Start to restart 
the 
| > SMTP server.
| >  
| > I. Reproduce the issue, repeat step G to stop Default SMTP Virtual 
Server, 
| > copy out or zip the SMTP log files in the 
| > "%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart the 
| > "Default SMTP Virtual Server". 
| > 
| > 2. Use the Message Tracking to track the email:
| > 
| > a. Enable Message Tracking on by right-click your Exchange server in 
ESM 
| > and click Properties.
| > 
| > For more information, please check the "Message Tracking" section in 
the 
| > following KB article.
| > 257265 XCON: General Troubleshooting for Exchange 2000 Transport Issues
| > http://support.microsoft.com/kb/257265/en-us
| > 
| > b. Please:
| > 
| > a) Search for the message in Tools \ Message Tracking Centre. (You can 
use 
| > the "Sender" "Recipients" as search criteria.)
| > b) Double click to open it.
| > c) Post the error information here.
| >  
| > 3. Please try to bypass the Astaro firewall and test this issue.
| > 
| > 4. I suggest performing the following steps to determine the MTU 
setting:
| > 
| > On the SBS server:
| > 1). To get the MTU Size maximum, you may need to have the following 
command 
| > on one of internal client connected to SBS server directly. 
| > ping <SBS_IP_address> -f -l <packet_size>
| > and on SBS server, please ping the POP3 mail server with following 
command
| > ping <POP3MailServer_IP_address> -f -l <packet_size>
| > Being:
| > <SBS_IP_address or POP3MailServer_IP_address > - the IP address from 
the 
| > internal network.
| > <packet_size> - the packet size to test the maximum MTU packet size. 
| > You can use some <packet_size> parameters to get the packet ideal size. 
| > This can be identified by the ping results, for example, ping 
192.168.18.8 
| > -f -l 5000 
| > If the ping result is like below: 
| > 
| > Pinging [192.168.18.8] with 5000 bytes of data: 
| > Packet needs to be fragmented but DF set.
| > Packet needs to be fragmented but DF set.
| > Packet needs to be fragmented but DF set.
| > Packet needs to be fragmented but DF set. 
| > Ping statistics for 192.168.18.8:
| > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
| >  
| > You may need to decrease the <packet_size> until encounter a non 
fragmented 
| > packet size the link can answer like below: 
| > 
| > Pinging [192.168.18.8] with 1472 bytes of data: 
| > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128 
| > Ping statistics for 192.168.18.8:
| >  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
| > Approximate round trip times in milli-seconds:
| >     Minimum = 0ms, Maximum = 0ms, Average = 0ms
| >  
| > Or else, in this case, the maximum MTU Size is 1472. It is the default 
| > number for SBS 2k3 server. 
| > 
| > If the router Maximum MTU size is smaller than the one on the SBS 
server, 
| > you may need following steps:
| > Modifying the MTU Size: 
| > 1)Go to the key: 
| > 
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
| > ces
| > 2)Go the key corresponding to the NIC GUID
| > 3)Create a Dword parameter 'MTU' with the value small than router size
| > 4)Restart the client machine
| >  
| > References:
| > Diagnoses and Treatment of Black Hole Routers
| > http://support.microsoft.com/?id=159211
| > TCP/IP and NBT Configuration Parameters for Windows XP
| > http://support.microsoft.com/?id=314053
| > 
| > I hope these steps will give you some help. 
| > 
| > Thanks and have a nice day!
| > 
| > Best regards,
| > 
| > Terence Liu(MSFT)
| > 
| > Microsoft CSS Online Newsgroup Support
| > 
| > Get Secure! - www.microsoft.com/security
| > 
| > =====================================================
| > This newsgroup only focuses on Exchange technical issues. If you have 
| > issues regarding other Microsoft products, you'd better post in the 
| > corresponding newsgroups so that they can be resolved in an efficient 
and 
| > timely manner. You can locate the newsgroup here: 
| > http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
| > 
| > When opening a new thread via the web interface, we recommend you check 
the 
| > "Notify me of replies" box to receive e-mail notifications when there 
are 
| > any updates in your thread. When responding to posts via your 
newsreader, 
| > please "Reply to Group" so that others may learn and benefit from your 
| > issue.
| > 
| > Microsoft engineers can only focus on one issue per thread. Although we 
| > provide other information for your reference, we recommend you post 
| > different incidents in different threads to keep the thread clean. In 
doing 
| > so, it will ensure your issues are resolved in a timely manner. 
| > 
| > For urgent issues, you may want to contact Microsoft CSS directly. 
Please 
| > check http://support.microsoft.com for regional support phone numbers.
| > 
| > Any input or comments in this thread are highly appreciated.
| > =====================================================
| > 
| > This posting is provided "AS IS" with no warranties, and confers no 
rights.
| > 
| > --------------------
| > | Thread-Topic: Message deferrals from EHS
| > | thread-index: Ach5juSIzi7dCMESR2SKm3YzoCpozw==
| > | X-WBNR-Posting-Host: 207.46.19.168
| > | From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
| > | Subject: Message deferrals from EHS
| > | Date: Wed, 27 Feb 2008 14:20:00 -0800
| > | Lines: 39
| > | Message-ID: 
| > | MIME-Version: 1.0
| > | Content-Type: text/plain;
| > | 	charset="Utf-8"
| > | Content-Transfer-Encoding: 7bit
| > | X-Newsreader: Microsoft CDO for Windows 2000
| > | Content-Class: urn:content-classes:message
| > | Importance: normal
| > | Priority: normal
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
| > | Newsgroups: microsoft.public.exchange.connectivity
| > | Path: TK2MSFTNGHUB02.phx.gbl
| > | Xref: TK2MSFTNGHUB02.phx.gbl 
microsoft.public.exchange.connectivity:3595
| > | NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
| > | X-Tomcat-NG: microsoft.public.exchange.connectivity
| > | 
| > | We use the Microsoft Exchange Hosted Filtering Service for all of our 
| > inbound 
| > | and outbound e-mail.  Lately, we have had a large spike in e-mails 
with 
| > large 
| > | attachments that are not coming through in a timely fashion.  It 
seemed 
| > to 
| > | get worse after we applied SP2 for server 2003, but there were 
deferrals 
| > | before that point, so it is hard to say if that is conclusive.  We 
use CA 
| > | etrust AV connector for Exchange V7.0, which I have disabled (did not 
| > seem to 
| > | make much difference), then uninstalled (as per a forum post which 
said 
| > that 
| > | as AV sinks are tightly integrated with Exchange, disabling alone 
might 
| > not 
| > | resolve the problem).  There seemed to be some improvement after 
| > uninstalling 
| > | the AV connector, but that is hard to say.  I am basing it off the 
number 
| > of 
| > | messages in deferral at any given time.
| > | 
| > | If I run a deferral report in the EHS admin centre, these are the 
types 
| > of 
| > | messages I am seeing:
| > | 
| > | 2/27/2008 11:00:00 AM conversation with <external IP>[x.x.x.x] timed 
out 
| > | while sending message body 
| > | 
| > |  2/27/2008 11:07:00 AM conversation with <external IP>[x.x.x.x] timed 
out 
| > | while sending end of data -- message may be sent more than once.
| > | 
| > | The problem only seems to occur with messages with large attachments 
| > (above 
| > | 1.5 MB).  EHS tech support has not been much help, as they say the 
| > problem is 
| > | on our end.
| > | 
| > | Also, if I look at "current sessions" under the SMTP virtual server, 
| > there 
| > | are usually several (up to ten at a time) sessions in there from the 
EHS 
| > | servers (SMTP is closed to all other IPs) with connected times 
sometimes 
| > over 
| > | 600 seconds (I think EHS times out after approx. 10 minutes).
| > | 
| > | Researching this problem has not turned up much.  The "path MTU 
| > discovery" 
| > | issue comes up frequently, but that would be a problem for outbound 
| > e-mail, 
| > | not inbound.
| > | 
| > | I am not enough of a network guru to analyze this with packet traces. 
 
| > Any 
| > | suggestions?
| > | 
| > | We are using Exchange 2003 SP2, with an Astaro firewall appliance.  
Our 
| > | internet connection is a fixed wireless, 1.5 MB symettrical.
| > | 
| > 
| > 
|

Thank you Michael and Terence, for the help.  I started to di around in the 
firewall logs yesterday, and started with the IPS logs on a hunch.  Sure 
enough, I found two Snort rules (10995 and 3655) being triggered.  As we have 
port 25 locked down to the EHS servers only, I disabled these rules, and the 
deferrals stopped almost immediately.  So I have identified the problem, now 
I just have to go back and do clean up, etc.  I am surprised that there is 
not more information on this problem out there, as Snort is quite widely 
used.  There is a bit of info on false positives with SID 10995, and very 
little on SID 3655.  I have also escalated it with EHS tech support - I am 
sure there must be other customers with this issue.

Thanks again for all the help.

"Terence Liu [MSFT]" wrote:

> Hello Customer,
> 
> Thank you for your update.
> 
> We enable the message tracing on Exchange to see if the delay email 
> receive, and if the delay is caused by Exchange. From your description, the 
> delay email cannot be tracked in Exchange, that means the delay is not 
> cause by the Exchange mailflow. 
> 
> I think this issue is mostly related to the following factors:
> 
> 1. Public DNS (A and MX record)
> 2. Your Firewall
> 3. The EHS
> 4. The bad Internet connection
> 
> Let's analyze this issue. If the delay only happen on big size mail, I 
> think this issue will not be the DNS issue. If the big size outbound emails 
> do not have delay issue, I think this will not be a Internet connection 
> issue. 
> 
> Now, mostly this is a EHS issue or your firewall issue. To bypass your 
> firewall temporary to narrow down this issue, you need to contact the 
> firewall vendor to get help.
> 
> I strongly suggest you contact the EHS provide to verify this issue.
> 
> Hope the information give you some help.
> 
> Thanks and have a nice day!
> 
> Best regards,
> 
> Terence Liu(MSFT)
> 
> Microsoft CSS Online Newsgroup Support
> 
> Get Secure! - www.microsoft.com/security
> 
> =====================================================
> This newsgroup only focuses on SBS technical issues. If you have issues 
> regarding other Microsoft products, you'd better post in the corresponding 
> newsgroups so that they can be resolved in an efficient and timely manner. 
> You can locate the newsgroup here: 
> http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
> 
> When opening a new thread via the web interface, we recommend you check the 
> "Notify me of replies" box to receive e-mail notifications when there are 
> any updates in your thread. When responding to posts via your newsreader, 
> please "Reply to Group" so that others may learn and benefit from your 
> issue.
> 
> Microsoft engineers can only focus on one issue per thread. Although we 
> provide other information for your reference, we recommend you post 
> different incidents in different threads to keep the thread clean. In doing 
> so, it will ensure your issues are resolved in a timely manner. 
> 
> For urgent issues, you may want to contact Microsoft CSS directly. Please 
> check http://support.microsoft.com for regional support phone numbers.
> 
> Any input or comments in this thread are highly appreciated.
> =====================================================
> 
> This posting is provided "AS IS" with no warranties, and confers no rights.
> 
> --------------------
> | Thread-Topic: Message deferrals from EHS
> | thread-index: Ach6XIiyyCufaXu8QZeAwpp0iC/ztg==
> | X-WBNR-Posting-Host: 207.46.192.207
> | From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
> | References:   
> <Box5$pfeIHA.1500@TK2MSFTNGHUB02.phx.gbl>
> | Subject: RE: Message deferrals from EHS
> | Date: Thu, 28 Feb 2008 14:52:02 -0800
> | Lines: 274
> | Message-ID: 
> | MIME-Version: 1.0
> | Content-Type: text/plain;
> | 	charset="Utf-8"
> | Content-Transfer-Encoding: 7bit
> | X-Newsreader: Microsoft CDO for Windows 2000
> | Content-Class: urn:content-classes:message
> | Importance: normal
> | Priority: normal
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
> | Newsgroups: microsoft.public.exchange.connectivity
> | Path: TK2MSFTNGHUB02.phx.gbl
> | Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.exchange.connectivity:3611
> | NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
> | X-Tomcat-NG: microsoft.public.exchange.connectivity
> | 
> | Hi Terrence,
> | 
> | Thanks for all your suggestions.  I enabled the logs for a while this 
> | morning, long enough to capture several of the timeout messages.  What 
> can I 
> | do with them to get them to you?  I cannot attach a file to a post to the 
> | forums, and the file is too large to just paste in-line in a post.
> | 
> | I have checked again with EHS tech support about the number of deferrals 
> | that I am seeing, and they have confirmed that it is not normal to see 
> that 
> | many on an ongoing basis.  Also, some of the deferred messages do 
> eventually 
> | get through.  I have one with a 6MB attachemtn that I sent to my address 
> here 
> | from my home address.  It was sent Tuesday at 2:05 pm, and did not arrive 
> in 
> | my mailbox here until today at 10:57 am.
> | 
> | A few more questions:
> | 
> | How can message tracing help me with this problem?  The affected messages 
> | are not being delivered in a timely fashion, and I am assuming I can not 
> | track a message which has not yet been received.  Sorry for my ignorance 
> on 
> | this.
> | 
> | As we are not a large business, I am not sure what I can do to bypass the 
> | firewall.  I do not want to open my mail server up to any unecessary 
> risks.  
> | We only have one firewall and one internet connection for the whole 
> company.  
> | Any suggestions on methodology to eliminate the firewall as a possibile 
> issue?
> | 
> | I have verified the server MTU is 1472 (your post mentioned SBS - we are 
> | running Server 2003 Standard Edition SP2), but as I mentioned in my 
> previous 
> | post, that would apply to our outbound e-mail, whereas I am trying to 
> | troubleshoot inbound mail.  If the MTU is a problem, it would be on the 
> EHS 
> | side.
> | 
> | Thanks for the help so far!
> | 
> | "Terence Liu [MSFT]" wrote:
> | 
> | > Hello Customer,
> | > 
> | > Thank you for posting here.
> | > 
> | > According to your description, I understand that some big income email 
> will 
> | > delay. If I have misunderstood the problem, please don't hesitate to 
> let me 
> | > know.
> | > 
> | > Based on my research, I suggest we try the following steps to narrow 
> down 
> | > this issue:
> | > 
> | > 1. Check your Exchange SMTP log to see if the email receive your 
> Exchange 
> | > server:
> | > 
> | > Enable SMTP logging and gather SMTP log to troubleshoot the issue:
> | >  
> | > A. Open Exchange System Manager, expand Servers -> <Server name> -> 
> | > Protocols -> SMTP, right-click "Default SMTP Virtual Server" and click 
> | > Properties.
> | >  
> | > B. Under the General tab, check the option "Enable Logging".
> | >  
> | > C. With "W3C Extended Log File Format", click "Properties".
> | >  
> | > D. Under "General Properties", make sure "Use local time for file 
> naming 
> | > and rollover" is CHECKED.
> | >  
> | > E. Switch to the "Extended Properties", and then select to enable All 
> the 
> | > logging Options.
> | >  
> | > F. Click OK to apply the modification.
> | >  
> | > G. Right-click Default SMTP Virtual Server and click Stop.
> | >  
> | > H. Right-click Default SMTP Virtual Server and click Start to restart 
> the 
> | > SMTP server.
> | >  
> | > I. Reproduce the issue, repeat step G to stop Default SMTP Virtual 
> Server, 
> | > copy out or zip the SMTP log files in the 
> | > "%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart the 
> | > "Default SMTP Virtual Server". 
> | > 
> | > 2. Use the Message Tracking to track the email:
> | > 
> | > a. Enable Message Tracking on by right-click your Exchange server in 
> ESM 
> | > and click Properties.
> | > 
> | > For more information, please check the "Message Tracking" section in 
> the 
> | > following KB article.
> | > 257265 XCON: General Troubleshooting for Exchange 2000 Transport Issues
> | > http://support.microsoft.com/kb/257265/en-us
> | > 
> | > b. Please:
> | > 
> | > a) Search for the message in Tools \ Message Tracking Centre. (You can 
> use 
> | > the "Sender" "Recipients" as search criteria.)
> | > b) Double click to open it.
> | > c) Post the error information here.
> | >  
> | > 3. Please try to bypass the Astaro firewall and test this issue.
> | > 
> | > 4. I suggest performing the following steps to determine the MTU 
> setting:
> | > 
> | > On the SBS server:
> | > 1). To get the MTU Size maximum, you may need to have the following 
> command 
> | > on one of internal client connected to SBS server directly. 
> | > ping <SBS_IP_address> -f -l <packet_size>
> | > and on SBS server, please ping the POP3 mail server with following 
> command
> | > ping <POP3MailServer_IP_address> -f -l <packet_size>
> | > Being:
> | > <SBS_IP_address or POP3MailServer_IP_address > - the IP address from 
> the 
> | > internal network.
> | > <packet_size> - the packet size to test the maximum MTU packet size. 
> | > You can use some <packet_size> parameters to get the packet ideal size. 
> | > This can be identified by the ping results, for example, ping 
> 192.168.18.8 
> | > -f -l 5000 
> | > If the ping result is like below: 
> | > 
> | > Pinging [192.168.18.8] with 5000 bytes of data: 
> | > Packet needs to be fragmented but DF set.
> | > Packet needs to be fragmented but DF set.
> | > Packet needs to be fragmented but DF set.
> | > Packet needs to be fragmented but DF set. 
> | > Ping statistics for 192.168.18.8:
> | > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
> | >  
> | > You may need to decrease the <packet_size> until encounter a non 
> fragmented 
> | > packet size the link can answer like below: 
> | > 
> | > Pinging [192.168.18.8] with 1472 bytes of data: 
> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128 
> | > Ping statistics for 192.168.18.8:
> | >  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
> | > Approximate round trip times in milli-seconds:
> | >     Minimum = 0ms, Maximum = 0ms, Average = 0ms
> | >  
> | > Or else, in this case, the maximum MTU Size is 1472. It is the default 
> | > number for SBS 2k3 server. 
> | > 
> | > If the router Maximum MTU size is smaller than the one on the SBS 
> server, 
> | > you may need following steps:
> | > Modifying the MTU Size: 
> | > 1)Go to the key: 
> | > 
> KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
> | > ces
> | > 2)Go the key corresponding to the NIC GUID
> | > 3)Create a Dword parameter 'MTU' with the value small than router size
> | > 4)Restart the client machine
> | >  
> | > References:
> | > Diagnoses and Treatment of Black Hole Routers
> | > http://support.microsoft.com/?id=159211
> | > TCP/IP and NBT Configuration Parameters for Windows XP
> | > http://support.microsoft.com/?id=314053
> | > 
> | > I hope these steps will give you some help. 
> | > 
> | > Thanks and have a nice day!
> | > 
> | > Best regards,
> | > 
> | > Terence Liu(MSFT)
> | > 
> | > Microsoft CSS Online Newsgroup Support
> | > 
> | > Get Secure! - www.microsoft.com/security
> | > 
> | > =====================================================
> | > This newsgroup only focuses on Exchange technical issues. If you have 
> | > issues regarding other Microsoft products, you'd better post in the 
> | > corresponding newsgroups so that they can be resolved in an efficient 
> and 
> | > timely manner. You can locate the newsgroup here: 
> | > http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
> | > 
> | > When opening a new thread via the web interface, we recommend you check 
> the 
> | > "Notify me of replies" box to receive e-mail notifications when there 
> are 
> | > any updates in your thread. When responding to posts via your

Glad you found a resolution!

"Glen Martin" <Silmarillion@community.nospam> wrote in message 
news:61BEE66E-36F5-4E8F-BFD6-CDA9DBFB2BF1@microsoft.com...
> Thank you Michael and Terence, for the help.  I started to di around in 
> the
> firewall logs yesterday, and started with the IPS logs on a hunch.  Sure
> enough, I found two Snort rules (10995 and 3655) being triggered.  As we 
> have
> port 25 locked down to the EHS servers only, I disabled these rules, and 
> the
> deferrals stopped almost immediately.  So I have identified the problem, 
> now
> I just have to go back and do clean up, etc.  I am surprised that there is
> not more information on this problem out there, as Snort is quite widely
> used.  There is a bit of info on false positives with SID 10995, and very
> little on SID 3655.  I have also escalated it with EHS tech support - I am
> sure there must be other customers with this issue.
>
> Thanks again for all the help.
>
> "Terence Liu [MSFT]" wrote:
>
>> Hello Customer,
>>
>> Thank you for your update.
>>
>> We enable the message tracing on Exchange to see if the delay email
>> receive, and if the delay is caused by Exchange. From your description, 
>> the
>> delay email cannot be tracked in Exchange, that means the delay is not
>> cause by the Exchange mailflow.
>>
>> I think this issue is mostly related to the following factors:
>>
>> 1. Public DNS (A and MX record)
>> 2. Your Firewall
>> 3. The EHS
>> 4. The bad Internet connection
>>
>> Let's analyze this issue. If the delay only happen on big size mail, I
>> think this issue will not be the DNS issue. If the big size outbound 
>> emails
>> do not have delay issue, I think this will not be a Internet connection
>> issue.
>>
>> Now, mostly this is a EHS issue or your firewall issue. To bypass your
>> firewall temporary to narrow down this issue, you need to contact the
>> firewall vendor to get help.
>>
>> I strongly suggest you contact the EHS provide to verify this issue.
>>
>> Hope the information give you some help.
>>
>> Thanks and have a nice day!
>>
>> Best regards,
>>
>> Terence Liu(MSFT)
>>
>> Microsoft CSS Online Newsgroup Support
>>
>> Get Secure! - www.microsoft.com/security
>>
>> =====================================================
>> This newsgroup only focuses on SBS technical issues. If you have issues
>> regarding other Microsoft products, you'd better post in the 
>> corresponding
>> newsgroups so that they can be resolved in an efficient and timely 
>> manner.
>> You can locate the newsgroup here:
>> http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
>>
>> When opening a new thread via the web interface, we recommend you check 
>> the
>> "Notify me of replies" box to receive e-mail notifications when there are
>> any updates in your thread. When responding to posts via your newsreader,
>> please "Reply to Group" so that others may learn and benefit from your
>> issue.
>>
>> Microsoft engineers can only focus on one issue per thread. Although we
>> provide other information for your reference, we recommend you post
>> different incidents in different threads to keep the thread clean. In 
>> doing
>> so, it will ensure your issues are resolved in a timely manner.
>>
>> For urgent issues, you may want to contact Microsoft CSS directly. Please
>> check http://support.microsoft.com for regional support phone numbers.
>>
>> Any input or comments in this thread are highly appreciated.
>> =====================================================
>>
>> This posting is provided "AS IS" with no warranties, and confers no 
>> rights.
>>
>> --------------------
>> | Thread-Topic: Message deferrals from EHS
>> | thread-index: Ach6XIiyyCufaXu8QZeAwpp0iC/ztg==
>> | X-WBNR-Posting-Host: 207.46.192.207
>> | From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
>> | References:  
>> <Box5$pfeIHA.1500@TK2MSFTNGHUB02.phx.gbl>
>> | Subject: RE: Message deferrals from EHS
>> | Date: Thu, 28 Feb 2008 14:52:02 -0800
>> | Lines: 274
>> | Message-ID: 
>> | MIME-Version: 1.0
>> | Content-Type: text/plain;
>> | charset="Utf-8"
>> | Content-Transfer-Encoding: 7bit
>> | X-Newsreader: Microsoft CDO for Windows 2000
>> | Content-Class: urn:content-classes:message
>> | Importance: normal
>> | Priority: normal
>> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
>> | Newsgroups: microsoft.public.exchange.connectivity
>> | Path: TK2MSFTNGHUB02.phx.gbl
>> | Xref: TK2MSFTNGHUB02.phx.gbl 
>> microsoft.public.exchange.connectivity:3611
>> | NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
>> | X-Tomcat-NG: microsoft.public.exchange.connectivity
>> |
>> | Hi Terrence,
>> |
>> | Thanks for all your suggestions.  I enabled the logs for a while this
>> | morning, long enough to capture several of the timeout messages.  What
>> can I
>> | do with them to get them to you?  I cannot attach a file to a post to 
>> the
>> | forums, and the file is too large to just paste in-line in a post.
>> |
>> | I have checked again with EHS tech support about the number of 
>> deferrals
>> | that I am seeing, and they have confirmed that it is not normal to see
>> that
>> | many on an ongoing basis.  Also, some of the deferred messages do
>> eventually
>> | get through.  I have one with a 6MB attachemtn that I sent to my 
>> address
>> here
>> | from my home address.  It was sent Tuesday at 2:05 pm, and did not 
>> arrive
>> in
>> | my mailbox here until today at 10:57 am.
>> |
>> | A few more questions:
>> |
>> | How can message tracing help me with this problem?  The affected 
>> messages
>> | are not being delivered in a timely fashion, and I am assuming I can 
>> not
>> | track a message which has not yet been received.  Sorry for my 
>> ignorance
>> on
>> | this.
>> |
>> | As we are not a large business, I am not sure what I can do to bypass 
>> the
>> | firewall.  I do not want to open my mail server up to any unecessary
>> risks.
>> | We only have one firewall and one internet connection for the whole
>> company.
>> | Any suggestions on methodology to eliminate the firewall as a possibile
>> issue?
>> |
>> | I have verified the server MTU is 1472 (your post mentioned SBS - we 
>> are
>> | running Server 2003 Standard Edition SP2), but as I mentioned in my
>> previous
>> | post, that would apply to our outbound e-mail, whereas I am trying to
>> | troubleshoot inbound mail.  If the MTU is a problem, it would be on the
>> EHS
>> | side.
>> |
>> | Thanks for the help so far!
>> |
>> | "Terence Liu [MSFT]" wrote:
>> |
>> | > Hello Customer,
>> | >
>> | > Thank you for posting here.
>> | >
>> | > According to your description, I understand that some big income 
>> email
>> will
>> | > delay. If I have misunderstood the problem, please don't hesitate to
>> let me
>> | > know.
>> | >
>> | > Based on my research, I suggest we try the following steps to narrow
>> down
>> | > this issue:
>> | >
>> | > 1. Check your Exchange SMTP log to see if the email receive your
>> Exchange
>> | > server:
>> | >
>> | > Enable SMTP logging and gather SMTP log to troubleshoot the issue:
>> | >
>> | > A. Open Exchange System Manager, expand Servers -> <Server name> ->
>> | > Protocols -> SMTP, right-click "Default SMTP Virtual Server" and 
>> click
>> | > Properties.
>> | >
>> | > B. Under the General tab, check the option "Enable Logging".
>> | >
>> | > C. With "W3C Extended Log File Format", click "Properties".
>> | >
>> | > D. Under "General Properties", make sure "Use local time for file
>> naming
>> | > and rollover" is CHECKED.
>> | >
>> | > E. Switch to the "Extended Properties", and then select to enable All
>> the
>> | > logging Options.
>> | >
>> | > F. Click OK to apply the modification.
>> | >
>> | > G. Right-click Default SMTP Virtual Server and click Stop.
>> | >
>> | > H. Right-click Default SMTP Virtual Server and click Start to restart
>> the
>> | > SMTP server.
>> | >
>> | > I. Reproduce the issue, repeat step G to stop Default SMTP Virtual
>> Server,
>> | > copy out or zip the SMTP log files in the
>> | > "%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart 
>> the
>> | > "Default SMTP Virtual Server".
>> | >
>> | > 2. Use the Message Tracking to track the email:
>> | >
>> | > a. Enable Message Tracking on by right-click your Exchange server in
>> ESM
>> | > and click Properties.
>> | >
>> | > For more information, please check the "Message Tracking" section in
>> the
>> | > following KB article.
>> | > 257265 XCON: General Troubleshooting for Exchange 2000 Transport 
>> Issues
>> | > http://support.microsoft.com/kb/257265/en-us
>> | >
>> | > b. Please:
>> | >
>> | > a) Search for the message in Tools \ Message Tracking Centre. (You 
>> can
>> use
>> | > the "Sender" "Recipients" as search criteria.)
>> | > b) Double click to open it.
>> | > c) Post the error information here.
>> | >
>> | > 3. Please try to bypass the Astaro firewall and test this issue.
>> | >
>> | > 4. I suggest performing the following steps to determine the MTU
>> setting:
>> | >
>> | > On the SBS server:
>> | > 1). To get the MTU Size maximum, you may need to have the following
>> command
>> | > on one of internal client connected to SBS server directly.
>> | > ping <SBS_IP_address> -f -l <packet_size>
>> | > and on SBS server, please ping the POP3 mail server with following
>> command
>> | > ping <POP3MailServer_IP_address> -f -l <packet_size>
>> | > Being:
>> | > <SBS_IP_address or POP3MailServer_IP_address > - the IP address from
>> the
>> | > internal network.
>> | > <packet_size> - the packet size to test the maximum MTU packet size.
>> | > You can use some <packet_size> parameters to get the packet ideal 
>> size.
>> | > This can be identified by the ping results, for example, ping
>> 192.168.18.8
>> | > -f -l 5000
>> | > If the ping result is like below:
>> | >
>> | > Pinging [192.168.18.8] with 5000 bytes of data:
>> | > Packet needs to be fragmented but DF set.
>> | > Packet needs to be fragmented but DF set.
>> | > Packet needs to be fragmented but DF set.
>> | > Packet needs to be fragmented but DF set.
>> | > Ping statistics for 192.168.18.8:
>> | > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>> | >
>> | > You may need to decrease the <packet_size> until encounter a non
>> fragmented
>> | > packet size the link can answer like below:
>> | >
>> | > Pinging [192.168.18.8] with 1472 bytes of data:
>> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
>> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
>> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
>> | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
>> | > Ping statistics for 192.168.18.8:
>> | >  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
>> | > Approximate round trip times in milli-seconds:
>> | >     Minimum = 0ms, Maximum = 0ms, Average = 0ms
>> | >
>> | > Or else, in this case, the maximum MTU Size is 1472. It is the 
>> default
>> | > number for SBS 2k3 server.
>> | >
>> | > If the router Maximum MTU size is smaller than the one on the SBS
>> server,
>> | > you may need following steps:
>> | > Modifying the MTU Size:
>> | > 1)Go to the key:
>> | >
>> KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
>> | > ces
>> | > 2)Go the key corresponding to the NIC GUID
>> | > 3)Create a Dword parameter 'MTU' with the value small than router 
>> size
>> | > 4)Restart the client machine
>> | >
>> | > References:
>> | > Diagnoses and Treatment of Black Hole Routers
>> | > http://support.microsoft.com/?id=159211
>> | > TCP/IP and NBT Configuration Parameters for Windows XP
>> | > http://support.microsoft.com/?id=314053
>> | >
>> | > I hope these steps will give you some help.
>> | >
>> | > Thanks and have a nice day!
>> | >
>> | > Best regards,
>> | >
>> | > Terence Liu(MSFT)
>> | >
>> | > Microsoft CSS Online Newsgroup Support
>> | >
>> | > Get Secure! - www.microsoft.com/security
>> | >
>> | > =====================================================
>> | > This newsgroup only focuses on Exchange technical issues. If you have
>> | > issues regarding other Microsoft products, you'd better post in the
>> | > corresponding newsgroups so that they can be resolved in an efficient
>> and
>> | > timely manner. You can locate the newsgroup here:
>> | > http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
>> | >
>> | > When opening a new thread via the web interface, we recommend you 
>> check
>> the
>> | > "Notify me of replies" box to receive e-mail notifications when there
>> are
>> | > any updates in your thread. When responding to posts via your

Hello Customer,

Thank you very much for sharing your resolution. I appreciate your time on 
this issue.

I'm glad to hear that things are working correctly for you now. Please do 
not hesitate to post in exchange newsgroup if you need any assistance in 
the future. I look forward to working with you again.

Thank you and have a nice day,

Best regards,

Terence Liu(MSFT)

Microsoft CSS Online Newsgroup Support

Get Secure! - www.microsoft.com/security

=====================================================
This newsgroup only focuses on exchange technical issues. If you have 
issues regarding other Microsoft products, you'd better post in the 
corresponding newsgroups so that they can be resolved in an efficient and 
timely manner. You can locate the newsgroup here: 
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx

When opening a new thread via the web interface, we recommend you check the 
"Notify me of replies" box to receive e-mail notifications when there are 
any updates in your thread. When responding to posts via your newsreader, 
please "Reply to Group" so that others may learn and benefit from your 
issue.

Microsoft engineers can only focus on one issue per thread. Although we 
provide other information for your reference, we recommend you post 
different incidents in different threads to keep the thread clean. In doing 
so, it will ensure your issues are resolved in a timely manner. 

For urgent issues, you may want to contact Microsoft CSS directly. Please 
check http://support.microsoft.com for regional support phone numbers.

Any input or comments in this thread are highly appreciated.
=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Thread-Topic: Message deferrals from EHS
| thread-index: Ach67oSd/UhDQgERTwukjGLQjlPwFw==
| X-WBNR-Posting-Host: 207.46.192.207
| From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
| References:   
<Box5$pfeIHA.1500@TK2MSFTNGHUB02.phx.gbl> 
 

| Subject: RE: Message deferrals from EHS
| Date: Fri, 29 Feb 2008 08:17:02 -0800
| Lines: 315
| Message-ID: 
| MIME-Version: 1.0
| Content-Type: text/plain;
| 	charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
| Newsgroups: microsoft.public.exchange.connectivity
| Path: TK2MSFTNGHUB02.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.exchange.connectivity:3616
| NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
| X-Tomcat-NG: microsoft.public.exchange.connectivity
| 
| Thank you Michael and Terence, for the help.  I started to di around in 
the 
| firewall logs yesterday, and started with the IPS logs on a hunch.  Sure 
| enough, I found two Snort rules (10995 and 3655) being triggered.  As we 
have 
| port 25 locked down to the EHS servers only, I disabled these rules, and 
the 
| deferrals stopped almost immediately.  So I have identified the problem, 
now 
| I just have to go back and do clean up, etc.  I am surprised that there 
is 
| not more information on this problem out there, as Snort is quite widely 
| used.  There is a bit of info on false positives with SID 10995, and very 
| little on SID 3655.  I have also escalated it with EHS tech support - I 
am 
| sure there must be other customers with this issue.
| 
| Thanks again for all the help.
| 
| "Terence Liu [MSFT]" wrote:
| 
| > Hello Customer,
| > 
| > Thank you for your update.
| > 
| > We enable the message tracing on Exchange to see if the delay email 
| > receive, and if the delay is caused by Exchange. From your description, 
the 
| > delay email cannot be tracked in Exchange, that means the delay is not 
| > cause by the Exchange mailflow. 
| > 
| > I think this issue is mostly related to the following factors:
| > 
| > 1. Public DNS (A and MX record)
| > 2. Your Firewall
| > 3. The EHS
| > 4. The bad Internet connection
| > 
| > Let's analyze this issue. If the delay only happen on big size mail, I 
| > think this issue will not be the DNS issue. If the big size outbound 
emails 
| > do not have delay issue, I think this will not be a Internet connection 
| > issue. 
| > 
| > Now, mostly this is a EHS issue or your firewall issue. To bypass your 
| > firewall temporary to narrow down this issue, you need to contact the 
| > firewall vendor to get help.
| > 
| > I strongly suggest you contact the EHS provide to verify this issue.
| > 
| > Hope the information give you some help.
| > 
| > Thanks and have a nice day!
| > 
| > Best regards,
| > 
| > Terence Liu(MSFT)
| > 
| > Microsoft CSS Online Newsgroup Support
| > 
| > Get Secure! - www.microsoft.com/security
| > 
| > =====================================================
| > This newsgroup only focuses on SBS technical issues. If you have issues 
| > regarding other Microsoft products, you'd better post in the 
corresponding 
| > newsgroups so that they can be resolved in an efficient and timely 
manner. 
| > You can locate the newsgroup here: 
| > http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
| > 
| > When opening a new thread via the web interface, we recommend you check 
the 
| > "Notify me of replies" box to receive e-mail notifications when there 
are 
| > any updates in your thread. When responding to posts via your 
newsreader, 
| > please "Reply to Group" so that others may learn and benefit from your 
| > issue.
| > 
| > Microsoft engineers can only focus on one issue per thread. Although we 
| > provide other information for your reference, we recommend you post 
| > different incidents in different threads to keep the thread clean. In 
doing 
| > so, it will ensure your issues are resolved in a timely manner. 
| > 
| > For urgent issues, you may want to contact Microsoft CSS directly. 
Please 
| > check http://support.microsoft.com for regional support phone numbers.
| > 
| > Any input or comments in this thread are highly appreciated.
| > =====================================================
| > 
| > This posting is provided "AS IS" with no warranties, and confers no 
rights.
| > 
| > --------------------
| > | Thread-Topic: Message deferrals from EHS
| > | thread-index: Ach6XIiyyCufaXu8QZeAwpp0iC/ztg==
| > | X-WBNR-Posting-Host: 207.46.192.207
| > | From: =?Utf-8?B?R2xlbiBNYXJ0aW4=?= <Silmarillion@community.nospam>
| > | References:   
| > <Box5$pfeIHA.1500@TK2MSFTNGHUB02.phx.gbl>
| > | Subject: RE: Message deferrals from EHS
| > | Date: Thu, 28 Feb 2008 14:52:02 -0800
| > | Lines: 274
| > | Message-ID: 
| > | MIME-Version: 1.0
| > | Content-Type: text/plain;
| > | 	charset="Utf-8"
| > | Content-Transfer-Encoding: 7bit
| > | X-Newsreader: Microsoft CDO for Windows 2000
| > | Content-Class: urn:content-classes:message
| > | Importance: normal
| > | Priority: normal
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
| > | Newsgroups: microsoft.public.exchange.connectivity
| > | Path: TK2MSFTNGHUB02.phx.gbl
| > | Xref: TK2MSFTNGHUB02.phx.gbl 
microsoft.public.exchange.connectivity:3611
| > | NNTP-Posting-Host: tk2msftibfm01.phx.gbl 10.40.244.149
| > | X-Tomcat-NG: microsoft.public.exchange.connectivity
| > | 
| > | Hi Terrence,
| > | 
| > | Thanks for all your suggestions.  I enabled the logs for a while this 
| > | morning, long enough to capture several of the timeout messages.  
What 
| > can I 
| > | do with them to get them to you?  I cannot attach a file to a post to 
the 
| > | forums, and the file is too large to just paste in-line in a post.
| > | 
| > | I have checked again with EHS tech support about the number of 
deferrals 
| > | that I am seeing, and they have confirmed that it is not normal to 
see 
| > that 
| > | many on an ongoing basis.  Also, some of the deferred messages do 
| > eventually 
| > | get through.  I have one with a 6MB attachemtn that I sent to my 
address 
| > here 
| > | from my home address.  It was sent Tuesday at 2:05 pm, and did not 
arrive 
| > in 
| > | my mailbox here until today at 10:57 am.
| > | 
| > | A few more questions:
| > | 
| > | How can message tracing help me with this problem?  The affected 
messages 
| > | are not being delivered in a timely fashion, and I am assuming I can 
not 
| > | track a message which has not yet been received.  Sorry for my 
ignorance 
| > on 
| > | this.
| > | 
| > | As we are not a large business, I am not sure what I can do to bypass 
the 
| > | firewall.  I do not want to open my mail server up to any unecessary 
| > risks.  
| > | We only have one firewall and one internet connection for the whole 
| > company.  
| > | Any suggestions on methodology to eliminate the firewall as a 
possibile 
| > issue?
| > | 
| > | I have verified the server MTU is 1472 (your post mentioned SBS - we 
are 
| > | running Server 2003 Standard Edition SP2), but as I mentioned in my 
| > previous 
| > | post, that would apply to our outbound e-mail, whereas I am trying to 
| > | troubleshoot inbound mail.  If the MTU is a problem, it would be on 
the 
| > EHS 
| > | side.
| > | 
| > | Thanks for the help so far!
| > | 
| > | "Terence Liu [MSFT]" wrote:
| > | 
| > | > Hello Customer,
| > | > 
| > | > Thank you for posting here.
| > | > 
| > | > According to your description, I understand that some big income 
email 
| > will 
| > | > delay. If I have misunderstood the problem, please don't hesitate 
to 
| > let me 
| > | > know.
| > | > 
| > | > Based on my research, I suggest we try the following steps to 
narrow 
| > down 
| > | > this issue:
| > | > 
| > | > 1. Check your Exchange SMTP log to see if the email receive your 
| > Exchange 
| > | > server:
| > | > 
| > | > Enable SMTP logging and gather SMTP log to troubleshoot the issue:
| > | >  
| > | > A. Open Exchange System Manager, expand Servers -> <Server name> -> 
| > | > Protocols -> SMTP, right-click "Default SMTP Virtual Server" and 
click 
| > | > Properties.
| > | >  
| > | > B. Under the General tab, check the option "Enable Logging".
| > | >  
| > | > C. With "W3C Extended Log File Format", click "Properties".
| > | >  
| > | > D. Under "General Properties", make sure "Use local time for file 
| > naming 
| > | > and rollover" is CHECKED.
| > | >  
| > | > E. Switch to the "Extended Properties", and then select to enable 
All 
| > the 
| > | > logging Options.
| > | >  
| > | > F. Click OK to apply the modification.
| > | >  
| > | > G. Right-click Default SMTP Virtual Server and click Stop.
| > | >  
| > | > H. Right-click Default SMTP Virtual Server and click Start to 
restart 
| > the 
| > | > SMTP server.
| > | >  
| > | > I. Reproduce the issue, repeat step G to stop Default SMTP Virtual 
| > Server, 
| > | > copy out or zip the SMTP log files in the 
| > | > "%systemroot%\system32\logfiles\SmtpSvc1" folder, and then restart 
the 
| > | > "Default SMTP Virtual Server". 
| > | > 
| > | > 2. Use the Message Tracking to track the email:
| > | > 
| > | > a. Enable Message Tracking on by right-click your Exchange server 
in 
| > ESM 
| > | > and click Properties.
| > | > 
| > | > For more information, please check the "Message Tracking" section 
in 
| > the 
| > | > following KB article.
| > | > 257265 XCON: General Troubleshooting for Exchange 2000 Transport 
Issues
| > | > http://support.microsoft.com/kb/257265/en-us
| > | > 
| > | > b. Please:
| > | > 
| > | > a) Search for the message in Tools \ Message Tracking Centre. (You 
can 
| > use 
| > | > the "Sender" "Recipients" as search criteria.)
| > | > b) Double click to open it.
| > | > c) Post the error information here.
| > | >  
| > | > 3. Please try to bypass the Astaro firewall and test this issue.
| > | > 
| > | > 4. I suggest performing the following steps to determine the MTU 
| > setting:
| > | > 
| > | > On the SBS server:
| > | > 1). To get the MTU Size maximum, you may need to have the following 
| > command 
| > | > on one of internal client connected to SBS server directly. 
| > | > ping <SBS_IP_address> -f -l <packet_size>
| > | > and on SBS server, please ping the POP3 mail server with following 
| > command
| > | > ping <POP3MailServer_IP_address> -f -l <packet_size>
| > | > Being:
| > | > <SBS_IP_address or POP3MailServer_IP_address > - the IP address 
from 
| > the 
| > | > internal network.
| > | > <packet_size> - the packet size to test the maximum MTU packet 
size. 
| > | > You can use some <packet_size> parameters to get the packet ideal 
size. 
| > | > This can be identified by the ping results, for example, ping 
| > 192.168.18.8 
| > | > -f -l 5000 
| > | > If the ping result is like below: 
| > | > 
| > | > Pinging [192.168.18.8] with 5000 bytes of data: 
| > | > Packet needs to be fragmented but DF set.
| > | > Packet needs to be fragmented but DF set.
| > | > Packet needs to be fragmented but DF set.
| > | > Packet needs to be fragmented but DF set. 
| > | > Ping statistics for 192.168.18.8:
| > | > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
| > | >  
| > | > You may need to decrease the <packet_size> until encounter a non 
| > fragmented 
| > | > packet size the link can answer like below: 
| > | > 
| > | > Pinging [192.168.18.8] with 1472 bytes of data: 
| > | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
| > | > Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128 
| > | > Ping statistics for 192.168.18.8:
| > | >  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
| > | > Approximate round trip times in milli-seconds:
| > | >     Minimum = 0ms, Maximum = 0ms, Average = 0ms
| > | >  
| > | > Or else, in this case, the maximum MTU Size is 1472. It is the 
default 
| > | > number for SBS 2k3 server. 
| > | > 
| > | > If the router Maximum MTU size is smaller than the one on the SBS 
| > server, 
| > | > you may need following steps:
| > | > Modifying the MTU Size: 
| > | > 1)Go to the key: 
| > | > 
| > 
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
| > | > ces
| > | > 2)Go the key corresponding to the NIC GUID
| > | > 3)Create a Dword parameter 'MTU' with the value small than router 
size
| > | > 4)Restart the client machine
| > | >  
| > | > References:
| > | > Diagnoses and Treatment of Black Hole Routers
| > | > http://support.microsoft.com/?id=159211
| > | > TCP/IP and NBT Configuration Parameters for Windows XP
| > | > http://support.microsoft.com/?id=314053
| > | > 
| > | > I hope these steps will give you some help. 
| > | > 
| > | > Thanks and have a nice day!
| > | > 
| > | > Best regards,
| > | > 
| > | > Terence Liu(MSFT)
| > | > 
| > | > Microsoft CSS Online Newsgroup Support
| > | > 
| > | > Get Secure! - www.microsoft.com/security
| > | > 
| > | > =====================================================
| > | > This newsgroup only focuses on Exchange technical issues. If you 
have 
| > | > issues regarding other Microsoft products, you'd better post in the 
| > | > corresponding newsgroups so that they can be resolved in an 
efficient 
| > and 
| > | > timely manner. You can locate the newsgroup here: 
| > | > http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
| > | > 
| > | > When opening a new thread via the web interface, we recommend you 
check 
| > the 
| > | > "Notify me of replies" box to receive e-mail notifications when 
there 
| > are 
| > | > any updates in your thread. When responding to posts via your 
|