SMTP Header obscured?

[mrbusy]

Hi,

I have an E2K3 box running at a remote location. When I RDP to the box and telnet to port 25 (telnet localhost 25) I get a good SMTP header and quick response. When I try the same thing from the Internet I get:

220 *********************************************************0****0****0 *********************200**0*****0***0*00
helo domain.com
250 mail.domain.com Hello [XX.XX.XX.XX]
quit
221 2.0.0 mail.domain.com Service closing transmission channel

Connection to host lost.
Z:\>

I suspect the Internet gateway device (to which I do not have access) is some kind of Cisco device set to disguise the header with garbage.

Anyone seen this before or have an alternative reason?

 

[paella33]

I have seen that done by an internet gateway device too.

 

[58sniper]

That's likely fixup being enabled on port 25 on a firewall device (such as Cisco).

Pat Richard
Microsoft Exchange MVP

 

[Zelandakh]

That is very common on the Pix products as exposed Exchange servers can be targetted. Obscure the server and you don't know if it is Exchange or not.

 

[58sniper]

But keep in mind that fixup does limit the commands that can be sent through to the server as well. I don't recommend using it.

Pat Richard
Microsoft Exchange MVP

 

[Zelandakh]

Remote location" - is it a branch office? If so, have email delivered to main site then restrict the tunnel from site to site so the branch office can only receive port 25 traffic from corp. Then you can remove the fixup.

I had the fixup for years Pat and it was ok for me.

 

[mrbusy]

Thanks for the answers. Very useful.

The server is running at a branch office and I don't have very much control over the way things are configured.

One further question. When I telnet to the mail server via the internet (rather than from the RDP session to the server itself) I occasionally get timeouts when I try to quit the session or end the body / data section of the test messages. I had attributed this to the slow connection we have at the branch office, but could this be a result of the PIX blocking some content / commands?

 

[Zelandakh]

If it is occasional then I'd say it is latency rather than a command.

 

[58sniper]

I had the fixup for years Pat and it was ok for me.

Somewhere around here, I have a list of parameters that don't work with fixup enabled. I'll see if I can dig it up.

Pat Richard
Microsoft Exchange MVP

 

[grantjb]

I have the exact thing for our mail servers, and it is fixup enabled on our PIX firewalls.

Grant

 

[mrbusy]

I'm not sure I see this adding a huge amount of value to our security. If a vulnerability is found in any of the major SMTP engines then surely the people trying to take advantage of it will be aware of this fixup? What's to stop them ignoring the obscured header and trying the vulnerability anyway?

This seems a little obsolete to me?

 

[paella33]

fixup does more than obscruing the header. It will disable some extended SMTP commands also.

 

[Zelandakh]

If you find a vulnerability in the postfix engine, you can't hit a Windows SMTP box or an Exchange server and get the same results.

 

[ntinlin]

We had big problems with fixup when we were doing a direct VPN link from our company to another for migration purposes.

SMTP connections to the servers at the other company just wouldn't hold. Could start connection but then they'd drop.

Turned out one of our network guys had turned off fixup originally but hadn't commented it in the log so some other bright spark turned it back on. And guy 1 refused to believe the problem was at our end because he KNEW had done the pre-work and wouldn't go back and check it.

Neill

 

[xmsre]

Looks like a PIX with Mailguard enabled.

http://support.microsoft.com/kb/295725/en-us