Problems with SMTP connections dropping

Hi,

We are experiencing problems with SMTP connections between to a specific domain. The MX record for the Y domain points to an SMTP gateway at the X domain. The X domain SMTP gateway is MDaemon Server 10.0.5. The SMTP server for the Y domain is Microsoft Exchange 2007 (SP1 with Rollup 7). The problem is that the Y domain is dropping connections almost exactly 60 seconds after the email is sent. See the enclosed SMTP log from the X domain:

Tue 2009-05-12 15:08:29: Session 376; child 29
Tue 2009-05-12 15:07:28: Parsing message <e:\mdaemon\queues\remote\pd50004600261.msg>
Tue 2009-05-12 15:07:28: *  From: info@zzzzz.zz
Tue 2009-05-12 15:07:28: *  To: name@yyyyyyyy.yy
Tue 2009-05-12 15:07:28: *  Subject: Subject Line
Tue 2009-05-12 15:07:28: *  Size (bytes): 6166
Tue 2009-05-12 15:07:28: *  Message-ID: <22740960.1242140802090.JavaMail.WIN-DOSY30F3GIR$@WIN-DOSY30F3GIR>
Tue 2009-05-12 15:07:28: *  Route slip host: mail.yyyyyyyy.yy
Tue 2009-05-12 15:07:28: *  Route slip port: 25
Tue 2009-05-12 15:07:28: Attempting SMTP connection to [mail.yyyyyyyy.yy]
Tue 2009-05-12 15:07:28: Resolving MX records for [mail.yyyyyyyy.yy] (DNS Server: 172.31.0.102)...
Tue 2009-05-12 15:07:28: *  Name server has no valid records of the requested type for that domain
Tue 2009-05-12 15:07:28: Attempting SMTP connection to [mail.yyyyyyyy.yy:25]
Tue 2009-05-12 15:07:28: Resolving A record for [mail.yyyyyyyy.yy] (DNS Server: 172.31.0.102)...
Tue 2009-05-12 15:07:28: *  D=mail.yyyyyyyy.yy TTL=(40) A=[y.y.y.y]
Tue 2009-05-12 15:07:28: Attempting SMTP connection to [y.y.y.y:25]
Tue 2009-05-12 15:07:28: Waiting for socket connection...
Tue 2009-05-12 15:07:28: *  Connection established (172.31.0.104:3323 -> y.y.y.y:25)
Tue 2009-05-12 15:07:28: Waiting for protocol to start...
Tue 2009-05-12 15:07:28: <-- 220 mail.yyyyyyyy.yy Microsoft ESMTP MAIL Service ready at Tue, 12 May 2009 15:05:45 +0200
Tue 2009-05-12 15:07:28: --> EHLO xxxxxxx.xx
Tue 2009-05-12 15:07:28: <-- 250-mail.yyyyyyyy.yy Hello [x.x.x.x]
Tue 2009-05-12 15:07:28: <-- 250-SIZE 25845760
Tue 2009-05-12 15:07:28: <-- 250-DSN
Tue 2009-05-12 15:07:28: <-- 250-ENHANCEDSTATUSCODES
Tue 2009-05-12 15:07:28: <-- 250-AUTH
Tue 2009-05-12 15:07:28: <-- 250-8BITMIME
Tue 2009-05-12 15:07:28: <-- 250-BINARYMIME
Tue 2009-05-12 15:07:28: <-- 250 CHUNKING
Tue 2009-05-12 15:07:28: --> MAIL From:<info@zzzzz.zz> SIZE=6166
Tue 2009-05-12 15:07:28: <-- 250 2.1.0 Sender OK
Tue 2009-05-12 15:07:28: --> RCPT To:<name@yyyyyyyy.yy>
Tue 2009-05-12 15:07:28: <-- 250 2.1.5 Recipient OK
Tue 2009-05-12 15:07:28: --> DATA
Tue 2009-05-12 15:07:28: <-- 354 Start mail input; end with <CRLF>.<CRLF>
Tue 2009-05-12 15:07:28: Sending <e:\mdaemon\queues\remote\pd50004600261.msg> to [y.y.y.y]
Tue 2009-05-12 15:07:28: Transfer Complete

****** This is where a normal session should end:

Tue 2009-05-12 15:08:29: <-- 250 2.6.0 <OF6F352B6C.54290197-ONC12575B4.0042C6B7-C12575B4.004390D9@zzzzz.zz> Queued mail for delivery
Tue 2009-05-12 15:08:29: --> QUIT
Tue 2009-05-12 15:08:29: <-- 221 2.0.0 Service closing transmission channel
Tue 2009-05-12 15:08:29: SMTP session successful (Bytes in/out: 513/4969365)

****** But this is how the session actually ends:

Tue 2009-05-12 15:08:29: Socket connection closed by the other side (how rude!)
Tue 2009-05-12 15:08:29: This message is 1 minutes old; it has 59 minutes left in this queue
Tue 2009-05-12 15:08:29: SMTP session terminated (Bytes in/out: 333/6267)

As you can see, the Microsoft Exchange Server 2007 SMTP ends the session by closing the connection. I've seen in some logs that it says "Bad sequence of commands" but now I don't see that even anymore. The SMTP log on the Y domain (Exchange) looks like this for the same message:

2009-05-12T13:06:54.575Z,EXCHANGESERVER\Default,08CBA1139A506B17,0,192.168.254.12:25,x.x.x.x:52371,+,,
2009-05-12T13:06:54.575Z,EXCHANGESERVER\Default,08CBA1139A506B17,1,192.168.254.12:25,x.x.x.x:52371,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2009-05-12T13:06:54.575Z,EXCHANGESERVER\Default,08CBA1139A506B17,2,192.168.254.12:25,x.x.x.x:52371,>,"220 mail.yyyyyyyy.yy Microsoft ESMTP MAIL Service ready at Tue, 12 May 2009 15:06:53 +0200",
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,3,192.168.254.12:25,x.x.x.x:52371,<,EHLO xxxxxxx.xx,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,4,192.168.254.12:25,x.x.x.x:52371,>,250-mail.yyyyyyyy.yy Hello [x.x.x.x],
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,5,192.168.254.12:25,x.x.x.x:52371,>,250-SIZE 25845760,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,6,192.168.254.12:25,x.x.x.x:52371,>,250-PIPELINING,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,7,192.168.254.12:25,x.x.x.x:52371,>,250-DSN,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,8,192.168.254.12:25,x.x.x.x:52371,>,250-ENHANCEDSTATUSCODES,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,9,192.168.254.12:25,x.x.x.x:52371,>,250-STARTTLS,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,10,192.168.254.12:25,x.x.x.x:52371,>,250-AUTH,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,11,192.168.254.12:25,x.x.x.x:52371,>,250-8BITMIME,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,12,192.168.254.12:25,x.x.x.x:52371,>,250-BINARYMIME,
2009-05-12T13:06:54.637Z,EXCHANGESERVER\Default,08CBA1139A506B17,13,192.168.254.12:25,x.x.x.x:52371,>,250 CHUNKING,
2009-05-12T13:06:54.669Z,EXCHANGESERVER\Default,08CBA1139A506B17,14,192.168.254.12:25,x.x.x.x:52371,<,MAIL From:<info@zzzzz.zz> SIZE=6166,
2009-05-12T13:06:54.669Z,EXCHANGESERVER\Default,08CBA1139A506B17,15,192.168.254.12:25,x.x.x.x:52371,*,08CBA1139A506B17;2009-05-12T13:06:54.575Z;1,receiving message
2009-05-12T13:06:54.669Z,EXCHANGESERVER\Default,08CBA1139A506B17,16,192.168.254.12:25,x.x.x.x:52371,>,250 2.1.0 Sender OK,
2009-05-12T13:06:54.700Z,EXCHANGESERVER\Default,08CBA1139A506B17,17,192.168.254.12:25,x.x.x.x:52371,<,RCPT To:<name@yyyyyyyy.yy>,
2009-05-12T13:06:54.700Z,EXCHANGESERVER\Default,08CBA1139A506B17,18,192.168.254.12:25,x.x.x.x:52371,>,250 2.1.5 Recipient OK,
2009-05-12T13:06:54.731Z,EXCHANGESERVER\Default,08CBA1139A506B17,19,192.168.254.12:25,x.x.x.x:52371,<,DATA,
2009-05-12T13:06:54.731Z,EXCHANGESERVER\Default,08CBA1139A506B17,20,192.168.254.12:25,x.x.x.x:52371,>,354 Start mail input; end with <CRLF>.<CRLF>,
2009-05-12T13:07:56.969Z,EXCHANGESERVER\Default,08CBA1139A506B17,21,192.168.254.12:25,x.x.x.x:52371,-,,Remote

As far as I can read these logs, the SMTP serve at the Y domain (Exchange) awaits the <CRLF>.<CRLF> but seems like it for some reason never gets it. After one minute, according to both SMTP logs then session is ended. Has anyone experienced anything like this? Does anyone interpret the logs differently than me?

All mail going to the Y domain gets the same treatment by the Y SMTP, when sent from the X domain. When I try from the server that runs the X domain SMTP server by using telnet to port 25 at the Y domain, it lets me send email without any trouble.

Regards,

Tomas Andersson
LVL 1
YMNORRAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
YMNORRConnect With a Mentor Author Commented:
Just to add to the confusion. I re-enabled ESMTP for the MDaemon server because other SMTP clients (MS Outlook) started having problems sending emails. Now both the regular SMTP clients and email to the Y domain works like a charm. Maybe it's time to start doing something else, like driving a garbage truck instead? ;-)
0
 
moorhouselondonCommented:
It's not an issue with the size of the message being sent is it?  

If I'm reading the log correctly the size of the message being sent is certainly within Exchange's max advertised acceptable capacity (25845760), but is slightly over the size that was advertised by mdaemon (6166) prior to sending.  6267 bytes were in fact sent.  Has Exchange got the hump about those extra bytes?
0
 
YMNORRAuthor Commented:
No idea where those extra bytes come from. Must be some header information that's been added or something. I don't think that is the issue though, that should give me a more clear error message I think. Just for the heck of it, I tried by using telnet, information in the MAIL FROM command that the size was 314 bytes but I sent just a subject line. It went through with no problems after I sent <CRLF>.<CRLF>
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
YMNORRAuthor Commented:
Could it be that the Exchange server is having problems intrpreting the <CRLF>.<CRLF> that should be inside the .msg file that MDaemon tries to send? How would I go about to find that out? Hm... I'll see if I can find the .msg file in MDaemon somewhere.
0
 
moorhouselondonCommented:
>that should give me a more clear error message I think
Microsoft?  Clear error message?  :-))

It's fine for the Size parameter to show a figure that is bigger than the message, but not the other way round.

The reasoning behind my first comment is that Exchange is looking for the end of message identifier within the size given to it.  It looks possible that the end of message identifier was not seen within this span and Exchange decided to give up on the session.  
0
 
YMNORRAuthor Commented:
Hm... I see that MDaemon is doing someting I'm not in control of. The .msg file does not contain <CRLF>.<CRLF> at the end of the file. It must be sent after, but it's not logged by MDaemon. I checked another Exchange server where it actually works to send to, but the log doesn't show the <CRLF>.<CRLF> command.
0
 
YMNORRAuthor Commented:
Oh well, I admit I was a bit hasty on the comment about Microsoft being clear ;-) but they do tend to follow the SMTP standard :-)
0
 
moorhouselondonCommented:
Can you try knocking off any size restrictions temporarily in Exchange?  Mdaemon may not then advertise the size of its' message, and Exchange will then wait for proper termination.  
0
 
YMNORRAuthor Commented:
I tried by setting it like this:

set-receiveconnector "Default" -SizeEnabled Disabled

Then the Exchange server doesn't advertise the SIZE in the banner anymore, and MDaemone doesn't send the size with MAIL FROM either. The bad part is that it had no effect what so ever. It still drops the connections aftter the 60 second timeout.
0
 
moorhouselondonCommented:
I assume that you've checked Reverse DNS, etc. on the mdaemon domain.  I know you are anonymising things, but if zzzzz.zz does not match when a reverse lookup is done on it by Exchange, this could be where the problem lies.  Talking of zzzzz, I'm off to bed now...
0
 
YMNORRAuthor Commented:
Well, it doesn't receive email from any domain, so I doubt that it could be RDNS related. Is RDNS lookups enabled by default on Exchange 2007? In that case, how do I disable it? But it really sounds strange if the RDNS lookup would occur after they have introduced eachother, and the email has actually been sent but not properly terminated by the sending side as it seems here.
0
 
moorhouselondonCommented:
Sending and Receiving of emails are very different.  Sending of emails is now about proving to the recipient, or rather, the recipient's mail server that you are who you are, and not someone who has taken over your mail server - turning it into an open relay - and is bombarding the world with spam.

Put your sending IP in here to check correct setup of rdns:-

http://postmaster.aol.com/cgi-bin/dns_tool.pl

Ideally, run the dnsreport found here which gives a more comprehensive check:-

www.dnsstuff.com
0
 
YMNORRAuthor Commented:
Well, I do know how RDNS works. I just don't think that would be the issue in this case. The Y domain does not have a RDNS entry at their ISP though.
0
 
moorhouselondonCommented:
>Well, I do know how RDNS works.  
Please accept my apologies, but a lot of questions on EE don't get properly solved because not all of the obvious boxes are ticked before heading off at a tangent.

Y is not doing the sending so I don't think that is an issue.  I think you're implying that X does have RDNS setup correctly?  (Can you confirm so that we can "tick the box"?)

Is
zzzzz.zz
equal to
xxxxxxx.xx
?

If not, then this may look like an Open Relay to the recipient.  (Consider zzzzz.zz to be verifyyourpasswordbyclickingtheattachedlink@ebay.com for example lol).
0
 
YMNORRAuthor Commented:
X has RDNS correctly setup. Y does not. Z is not equal to Z, it is simply the original sending domain. X is just a forwarding SMTP gateway for Y. Complex enough? ;-)

Anyway, I managed to solve the problem. According to the MDaemon support, nothing is wrong on their side. I'm pretty sure that Microsoft would say the same thing if I would have called them. I started looking into the ESMTP things and I saw that when sending directly from a W domain (running out of letter now...lol) that also runs Exchange 2007 to the Y domain, the email gets sent with no problem. It ended with BDAT though, which is weird since Microsoft is not supposed to support that verb. Anyway, I disabled the use of EHLO instead of the traditional HELO on the MDaemon server, and all the emails went through fine. It's reported as a bug with Alt-N but I doubt that they will look into it. What I could have done to help them would have been to run a sniffer on the receiving and sending sides, since the SMTP logs don't reveal all information apprently. For example, when the MDaemon log says "Transfer complete", that is supposed to mean that <CRLF>.<CRLF> has been sent. I don't trust that though, I would like to see it with my own eyes in the log.
0
 
abhaighCommented:
Id contact the admins for the problematic site - that looks like greylisting to me
0
 
YMNORRAuthor Commented:
If only it would be that easy. As I have explained before, the problem is sending to any domain. I'm the admin for both Y and X domain in question.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.