Some email not getting through Firebox 700

[tmckeown]

Hi,'
I'm hoping someone may have an answer for me. Watchguard is scratching their heads.

I use filtered-smtp for outgoing and proxy-smtp for the incoming. I have all the switches for esmtp on. We are sending email just fine. Incoming email is fine except for a few people can't send us email. It is always rejected by the Firebox. When I look at the logs on the Firebox, I see quite a few Bad Command...... 10 bad commands...killing link. I don't know if that has anything to do with it or not. The sender who is rejected gets this:
__________________________________
Reporting-MTA: dns;maximus.dmz.cdw.com
Received-From-MTA: dns;maximus.dmz.cdw.com
Arrival-Date: Mon, 3 Mar 2003 08:44:42 -0600

Final-Recipient: rfc822;cjohnson@upstaging.com
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;553 Requested action not taken: mailbox name not allowed or chunk too large
250-BINARYMIME
250-CHUNKING
250 AUTH LOGIN
-0500
________________________________
I did a packet snif at the external port of the firewall, but I don't know what I am looking for. Anyone got any ideas? Thanks for the help.
Tom

 

[ashleym]

Try turning off all of the ESMTP switches and see if it makes a difference. It worked for me.

AM

 

[tmckeown]

How odd? Watchguard told me to turn it all on to cure the problem, and turning it all off cured it. Thanks for the help.
Tom

 

[Ntr0P]

There are still a few unsupported ESMTP commands in WG's software if I am not mistaken (don't recall which ones). Odd indeed that WG would suggest turning on ESMTP as I have always seen them suggest turning it off as ashleym has.

The fact that this only happens to a few of the remote ends that send you mail somewhat supports the idea that it might be an unsupported ESMTP command. If you really like your SMTP proxy (I know I do), you could always add a proxy and a filter and explicitly allow only the known remotes in on the filter and everyone else on the proxy.

 

[tmckeown]

I think I'll leave it with ESMTP off for now, or until someone else starts complaining.
Thanks

 

[stiles123]

It might be at a lower level than that. There are 2 possible problems.

1)You might need to set up a rule for the auth service - the ruleset should match the SMTP services.

2)There is an option under general firewall packet handling to 'autoblock source of packets not handled'. This caused us problems. Turn it off.

 

[tmckeown]

I have found that if ESMTP IS enabled (all checkboxes), some mail does not get through the firewall. It gets the 10 bad commands.. killing link thing. With it disabled, email is getting in without a problem, BUT... our remote users can not authenticate to the server for relaying. Watchguard appears to have some real problems with ESMTP implementation. I can't seem to make anyone happy around here since installing the firewall.

Anyone got any more comments?

 

[Ntr0P]

Sounds like you are running version 5. Upgrade to version 6 (6.1 sp1 is the latest) and the AUTH issue is supposedly resolved. I can't confirm this as we do not use ESMTP.

 

[tmckeown]

Unfortunately, we are using 6.1 with SP1. You would think this stuff would work more reliably. I noticed quite a few posts on Watchguards site with similar problems. None of them were resolved.

 

[tmckeown]

From what I am understanding, if both the sending and receiving servers are Exchange 2K, and ESMTP is enabled in the Firebox, the email will be reject by the Firebox. Apparently, the servers decide to use some ESMTP commands that are not supported by the Firebox. The Firebox strips those commands, then says there are bad commands and finally kills the link with the 10 bad commands log. It doesn't appear that Watchguard knows how to fix this yet. The only workaround is to use the filtered SMTP for BOTH outgoing and incoming. I hope this helps anyone who has been pulling their hair out over this problem.

 

[b4rtm4n]

Ditto most of what tmckeown says.

The problem as I understand it is that Watchguard process fully RFC compliant EMSTP whilst Microsoft make their own ESMPT headers.

Hence the firebox can't process them.

They try but are allways playing catchup to MS.

$cd /pub
$more beer