Solved

Problems with SMTP connections dropping

Posted on 2009-05-12
17
4,168 Views
Last Modified: 2013-11-30
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
0
Comment
Question by:YMNORR
  • 10
  • 6
17 Comments
 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
>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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 31

Expert Comment

by:moorhouselondon
Comment Utility
>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
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 15

Expert Comment

by:abhaigh
Comment Utility
Id contact the admins for the problematic site - that looks like greylisting to me
0
 
LVL 1

Author Comment

by:YMNORR
Comment Utility
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
 
LVL 1

Accepted Solution

by:
YMNORR earned 0 total points
Comment Utility
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

Featured Post

Free book by J.Peter Bruzzese, Microsoft MVP

Are you using Office 365? Trying to set up email signatures but you’re struggling with transport rules and connectors? Let renowned Microsoft MVP J.Peter Bruzzese show you how in this exclusive e-book on Office 365 email signatures. Better yet, it’s free!

Join & Write a Comment

Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…
Marketers need statistics and metrics like everybody else needs oxygen. In this article we explain how to enable marketing campaign statistics for Microsoft Exchange mail.
In this video we show how to create an Address List in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Organization >> Ad…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now