Time to blame the Firewall ….

Now, I knew that Cisco PIX  ‘fixup protocol smtp’ caused Exchange to suffer horribly until it was disabled, but couldn’t find any offical word on the ASA 8.21 doing the same.

We still had the ESMTP filter in place, as part of Cisco’s Modular Policy Framework . I removed the “inspect esmtp” statement from our global_policy map and instantly the problems disappeared.

CiscoAsa(config)#class inspection_default

CiscoAsa(config-pmap-c)# no inspect ESMTP

Hum Ho.

Was mucking around and decided to send some large files (over 10 mb) between email systems, but they didn’t arrive. Hmmm

After checking that all the standard settings for message limits where okay, things still weren’t working.

A bit of Googling stumbled on to this Basically each connector (both send and receive) in Exchange 2007 has a 10mb limit by default.

Get-SendConnector | list and Get-ReceiveConnector | list show this very clearly (ish)

Time to change that!

On the Internal Exhange 2007 box from Powershell:

Set-SendConnector –IDENTITY “Internet” -MaxMessageSize 50MB

SET-ReceiveCONNECTOR –IDENTITY “EX\Default EX” –MaxMessageSize 50MB

Then on the Edge Connector server

Set-SendConnector –IDENTITY “Sending to Internet” -MaxMessageSize 50MB

Set-SendConnector –IDENTITY “Sending to LAN” -MaxMessageSize 50MB

SET-ReceiveCONNECTOR –IDENTITY “External Inbound” –MaxMessageSize 50MB

SET-ReceiveCONNECTOR –IDENTITY “Intenal Outbound” –MaxMessageSize 50MB

Well, that sorted the bugger! I was freely sending up to 50MB files backward and forward.

(-IDENTITY is the name of the exact connector displayed from the Get commands above)

Certain file types, mainly .exe were being deleted and replaced with a simple .txt with the name of the deleted file attached to the original email. So I got evil.exe.txt rather than evil.exe.

I turned to Google for Powershell commands on how to configure the Edge server, since the GUI showed nothing active in the Transport rules tab.

Found this command Get-TransportAgent cmdlet to view the configuration of a transport agent on a computer that has the Edge Transport server role or the Hub Transport server role installed in a Microsoft Exchange Server 2007 organization.
http://technet.microsoft.com/en-us/library/bb123536(EXCHG.80).aspx

[PS] C:\Documents and Settings\Elvis>Get-TransportAgent

Identity Enabled Priority
——– ——- ——–
Connection Filtering Agent True 1
Address Rewriting Inbound Agent True 2
Edge Rule Agent True 3
Content Filter Agent True 4
Sender Id Agent True 5
Sender Filter Agent True 6
Recipient Filter Agent True 7
Protocol Analysis Agent True 8
Attachment Filtering Agent True 9
Address Rewriting Outbound Agent True 10

This lead me to believe my naughty server was blocking by default and this proved me right:
http://technet.microsoft.com/en-us/library/aa997139(EXCHG.80).aspx

By the magic of changing Enable to Disable, I modify the Powershell command and ran it.

Disable-TransportAgent -Identity “Attachment Filtering agent”

[PS] C:\Documents and Settings\Elvis>Get-TransportAgent

Identity Enabled Priority
——– ——- ——–
Connection Filtering Agent True 1
Address Rewriting Inbound Agent True 2
Edge Rule Agent True 3
Content Filter Agent True 4
Sender Id Agent True 5
Sender Filter Agent True 6
Recipient Filter Agent True 7
Protocol Analysis Agent True 8
Attachment Filtering Agent False 9
Address Rewriting Outbound Agent True 10

And as if by magic, my .exe came through to Outlook untouched.

Hopefully, a useful reference if other oddities happen again!

Should reaaaaaallllly think about learning PowerShell sooner rather than later …

I was simply trying to use it as a straight forward standalone relay SMTP server in prep for the whole Exchange 2007 thang. Not connected to Exchange in the slightest way, shape or form. I haven’t had the chance to play with Exchange 2007 and as we all know Ms is a case of next, next, next - finish and it’s up and running, so didn’t bother with RTFM ….

The set up:

Server running Exchange 2007 with SP1, two network cards connected to different network with a DMZ protected by an ISA server.

Two receive connectors:

1 Receiving for From the Internet, using the IP address of the external facing network and receiving mail from the external smart host IP address range

1 Receiving for From the LAN, using the IP address of the internal facing network and receiving mail from the internal ISA IP address range

Removed any ticks for the Authentication tab and made sure the Permission Groups tab were set to Anonymous Users on the receiver connectors’ properties tabs.

Two Send connectors

1 Sending for Outbound to the Internet (Using the * SMTP rule pointing to a smart host)

1 Sending for External Mail to the LAN (With the domains of the Internal LAN added and pointing to a smart host that’s an ISA IP address for the published Exchange server)

Then adding in the authoritative domain on my LAN as Accepted domains.

Everything looked good, so then tried to telnet from the internal network to the mail relay.

220 EdgeServer.DMZ.LOCAL Microsoft ESMTP MAIL Service ready at Sat, 23 Feb 2008 18:59:46 +1100
helo
250 EdgeServer.DMZ.LOCAL Hello [127.0.0.007]
mail from: badbob@chris-mohan.com
250 2.1.0 Sender OK
rcpt to: external@gmail.com
550 5.7.1 Unable to relay

WHAT! Arrgh

After much digging through blogs and other sites – I couldn’t find an answer. So I took it to the Exchange boys, Ben and Bundy, at the office.

After much chewing of the fat, Bundy noted the properties of permission groups of the receive connectors, especially the Exchange server permission in bold:

Anonymous

• Ms-Exch-SMTP-Submit
• Ms-Exch-SMTP-Accept-Any-Sender
• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
• Ms-Exch-Accept-Headers-Routing

ExchangeServers

• Ms-Exch-SMTP-Submit
• Ms-Exch-SMTP-Accept-Any-Sender
• Ms-Exch-SMTP-Accept-Any-Recipient
• Ms-Exch-Accept-Authoritative-Domain-Sender
• Ms-Exch-Bypass-Anti-Spam
• Ms-Exch-SMTP-Accept-Authentication-Flag
• Ms-Exch-Bypass-Message-Size-Limit
• Ms-Exch-Accept-Headers-Routing
• Ms-Exch-Accept-Exch50
• Ms-Exch-Accept-Headers-Organization (Note: this permission is not granted to Externally Secured servers.)
• Ms-Exch-Accept-Headers-Forest (Note: this permission is not granted to Externally Secured servers)

Taken from here

Ben (he of www.benchristian.com fame) then took a further leap.

On the Outbound to the LAN receive connector, ticked the Exchange servers box on Permission Groups tab and Externally Secured box on Authentication tab.

We tried telnet again and the damn thing started relaying! I was most pleased and annoyed at the same time.

Good work lads!