Log in

No account? Create an account


Firewall fallout / Exchange oddity

« previous entry | next entry »
2nd Sep 2009 | 15:31

This morning my colleagues turned off their Cisco PIX SMTP fuxup mode and most of the failing email finally made it through. But not all. So I broke out tcpdump again.

BTW, a handy way to split a tcpdump output file called dump into separate TCP connections is something like the following. This assumes that one of the endpoints of each connection is always the same port on the same server IP address.

    tcpdump -vvv -r dump |
    sed '/.* clientname[.]\([0-9]*\) .*/!d;s//\1/' |
    sort -u |
    while read p; do tcpdump -r dump -w dump.$p port $p; done

I looked at the connections which ended with a timeout during the data transmission phase. It turned out that just two messages were still having problems. And what strange beasts they were. The following is a paraphrase of the key features of the messages.

MAIL FROM:<mailserver@dept.cam.ac.uk> SIZE=12345
250 OK
RCPT TO:<exchange@dept.cam.ac.uk>
250 Accepted
354 Enter message, ending with "." on a line by itself
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: application/ms-tnef;
Content-Transfer-Encoding: binary
Subject: Service Unavailable
Date: Wed, 2 Sep 2009 12:34:56 +0100
Message-ID: <i6wnzxxs3ctmf9qb@mailserver.dept.cam.ac.uk>
X-MS-TNEF-Correlator: <i6wnzxxs3ctmf9qb@mailserver.dept.cam.ac.uk>
Thread-Topic: Service Unavailable
Thread-Index: GV7mWrV6mdBQLdgGFAfkSCsA
From: "/O=IT Support/OU=Department/cn=Configuration"
      "/cn=Servers/cn=MAILSERVER/cn=Microsoft Public MDB"

... loads of binary TNEF guff with lots of UTF-16 ...

The X.400 address is funny, but what was actually causing the problem was the attempt to send a binary message. Our servers don't support the BINARYMIME extension, so this is verboten. The reason it caused a timeout is that (being binary rather than lines of text) the message didn't end with a CRLF newline sequence, so the DATA dot-CRLF terminator did not appear at the start of a line, so our server thought it was part of the data and continued waiting for more.

Bizarre. Why is the message being sent to my servers when it should have been delivered internally? (Its recipient is a departmental address.) Why isn't Exchange downgrading the binary content as required by the specification? Alternatively, why is it using DATA to send a binary message when you can only do that using the BDAT command?

Very strange.

| Leave a comment | Share

Comments {3}


from: hobnobs
date: 2nd Sep 2009 17:18 (UTC)

Bloody winmail.dat.. hates it we does.

(not related specifically to the technical issue, but as soon as I saw it my fingers curled into fists and my brain went gyaaaah.)

Reply | Thread


from: pjc50
date: 3rd Sep 2009 08:56 (UTC)

This reminds me, I have a mail conundrum du jour:

We use Exchange internally with Exim as a sort of smart firewall and spam filter between it and the internet. There are two sites each with this configuration and a VPN between them over which the exchange systems talk. For various reasons which are mostly not technical, we're considering building a "shadow" email system that takes a copy of all inbound nonspam mail and stores it in UNIXland somewhere where people can get at it when exchange is unavailable.

The things which are nonobvious to me are:
- how to duplicate mail sanely (it seems that an "unseen" router is the way?)
- how to autoexpire mail in the shadow system to prevent it filling up

Reply | Thread

Tony Finch

from: fanf
date: 3rd Sep 2009 10:51 (UTC)

"When" Exchange is unavailable - what confidence you have in Microsoft's technology :-)

Yes, "unseen" is the magic keyword. Its behaviour is a bit strange, so pay attention to the complicated details in the documentation :-)

For auto-expire, you probably want to use something like Maildir since it's easier to delete several small files (e.g. with a bit of shell script) than parse and rewrite a single large one.

Our Cyrus setup has an auto-expire feature for spam folders, but I don't know how general it is. You may prefer to use Dovecot for mailbox access since it's easier to get working.

Reply | Parent | Thread