Outbound emails with attachments stuck in Exchange 2003
Hi all.
After a few days head-scratching, I’ve finally been able to isolate and replicate the issue I’m having on an Exchange 2003 server (part of SBS 2003 stnd).
Any email with any attachment (zip, pdf, jpg, etc) will not get sent to any domain. If a plain text email or a standard html email gets sent to the same domain, it will be sent, and a delivery report generated for user etc.
At first i thought it was a DNS issue, but have ruled this out, as we've run testexchangeconnectivity, exchBPA plus manually reset DNS forward zones using Open DNS rather than the ISP's dns.
The exchange is set to route email via DNS, not a smarthost.
I have ruled out AV interference, we've clean installed AVG 2011, and the exchange scanning module has NOT been installed.
We also run an auto signature software, exclaimer, but this has been ruled out, as i disabled it for an hour during the day, and still got the same results; emails with no attachments sent ok, emails with attachments stuck in retry.
I have followed an article which suggestions a corrupt exch DB. Having run eseutil and verified clean shutdowns, no other errors, i have also run an isinteg which shows no errors, and an offline defrag. All mounted again, but still same stuck emails with attachments.
I am aware of a registry entry which affects the av scanning of exchange, but haven’t been able to find a reliable source of the key to edit.
The settings in Exchange do allow attachments, and the size limit is set as 'any' size in Global \ Message Delivery and is not restricted in the smtp connector. Limit message size is not set in default virtual smtp, and the users allowed email size is using system default.
Any help would be welcome now, as i've gone through most of the obvious (i think) problems. There were a few updates applied on 31st Oct, one of which was for Exchange (KB907747) this was for IMF.
After a few days head-scratching, I’ve finally been able to isolate and replicate the issue I’m having on an Exchange 2003 server (part of SBS 2003 stnd).
Any email with any attachment (zip, pdf, jpg, etc) will not get sent to any domain. If a plain text email or a standard html email gets sent to the same domain, it will be sent, and a delivery report generated for user etc.
At first i thought it was a DNS issue, but have ruled this out, as we've run testexchangeconnectivity, exchBPA plus manually reset DNS forward zones using Open DNS rather than the ISP's dns.
The exchange is set to route email via DNS, not a smarthost.
I have ruled out AV interference, we've clean installed AVG 2011, and the exchange scanning module has NOT been installed.
We also run an auto signature software, exclaimer, but this has been ruled out, as i disabled it for an hour during the day, and still got the same results; emails with no attachments sent ok, emails with attachments stuck in retry.
I have followed an article which suggestions a corrupt exch DB. Having run eseutil and verified clean shutdowns, no other errors, i have also run an isinteg which shows no errors, and an offline defrag. All mounted again, but still same stuck emails with attachments.
I am aware of a registry entry which affects the av scanning of exchange, but haven’t been able to find a reliable source of the key to edit.
The settings in Exchange do allow attachments, and the size limit is set as 'any' size in Global \ Message Delivery and is not restricted in the smtp connector. Limit message size is not set in default virtual smtp, and the users allowed email size is using system default.
Any help would be welcome now, as i've gone through most of the obvious (i think) problems. There were a few updates applied on 31st Oct, one of which was for Exchange (KB907747) this was for IMF.
FDiskWizard
My first reaction was Anti-virus, etc.... What about file-level scanning? have you excluded the Exchange app/data folders per Microsoft recommendations?
ASKER
yes, as per kb823166.
Do you have any Intrusion prevention system in place?
I would enable SMTP logging in IIS to see if it shows where it is breaking.
And enable message tracking on the server properties in ESM.
Track those emails and see what the routing shows. We had an IPS sqaushing some PDF emails across our connector to Canada a while back.
So, does it happen internally, or just outbound? If just outbound I would really start looking at Firewall and IPS if you have one. Something is squashing those attachments most likely.
What if you rename an .XLS to .TXT and send?
I would enable SMTP logging in IIS to see if it shows where it is breaking.
And enable message tracking on the server properties in ESM.
Track those emails and see what the routing shows. We had an IPS sqaushing some PDF emails across our connector to Canada a while back.
So, does it happen internally, or just outbound? If just outbound I would really start looking at Firewall and IPS if you have one. Something is squashing those attachments most likely.
What if you rename an .XLS to .TXT and send?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Sorry for delay in this thread, have been working with MS Critical support to resolve it.
Long story short, after testing and troubleshooting, Exchange, AV, Auto Signature software, DNS, and all the other things that i tested in the first place, it turns out the problems was a faulty WAN port on the router.
Having used NetMonitor after isolating the network and sending emails and capturing packets, we discovered the router was not allowing larger emails to be split into smaller packets for transport. After some config of exisiting router with regards to MTU etc, we changed the Router, all good again :o)
Long story short, after testing and troubleshooting, Exchange, AV, Auto Signature software, DNS, and all the other things that i tested in the first place, it turns out the problems was a faulty WAN port on the router.
Having used NetMonitor after isolating the network and sending emails and capturing packets, we discovered the router was not allowing larger emails to be split into smaller packets for transport. After some config of exisiting router with regards to MTU etc, we changed the Router, all good again :o)