Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2652
  • Last Modified:

SMTPdiag error

Hello,

Mail sent from a partner's Exchange 2003 to our Exchange 2003 does not pass HELO.
(see the SMTPdiag screen capture from the other server)
Telnet from the other server sends a message successfully.

It's a single instance, mail from other domains is OK.
We have 2 MX records pointing to public IP's from our 2 link providers that are NAT to the Exchange internal address.
There is a link load balancer that handles the 2 ISP's.
I've made a change (after that screen capture) so that both MX records point to the first ISP address but mail still didn't go through.
Any ideas? SMTPdiag error SMTPdiag error
0
Optec
Asked:
Optec
  • 17
  • 16
  • +1
1 Solution
 
George SasIT EngineerCommented:
I think this is a firewall issue and not an exchange or smtp issue.

Can you telnet test both servers from a computer located on your LAN ? Does this work ?
Telnet test mail from the partner network works ?
0
 
OptecAuthor Commented:
Telnet from the remote Exchange server to ours works OK.
The other way was not tested because email is delivered.
0
 
George SasIT EngineerCommented:
I'm a bit confused now.
You say , mail can not be delivered from remote network but telnet test works ?
When I say telnet test mail , I mean you have to test and send an e-mail trough telnet :
http://support.microsoft.com/kb/153119

Does this work ?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
OptecAuthor Commented:
Yes telnet session from the other server successfully sent an email which I received.
However sending email from outlook through that server is not successful.
0
 
George SasIT EngineerCommented:
Common issue can be :
Your SMTP server name or address as specified has an error.
or
Your SMTP port is blocked.


Its the FQDN set up correctly on the remote smtp connector ?
Does the remote location use a smart host ?
Do you have a correct reverse DNS set up ?

Check your DNS and MX records :
http://www.dnsstuff.com/
http://www.mxtoolbox.com/

0
 
George SasIT EngineerCommented:
K , then that it's the FQDN on the sender exchange. It does not present itself as it should.
0
 
OptecAuthor Commented:
What needs to change at the sender Exchange?
0
 
George SasIT EngineerCommented:
And , when you are using Telnet you are connecting directly to the remote host , but when you use Outlook , your exchange might use a smart host.
Check your SMTP protocol properties and fix the FQDN and see the smarthost.
You might wanna make a new SMTP connector that will deliver mails to your domain DIRECTLY to your exchange server instead of going trough the DNS and smarthost.
0
 
OptecAuthor Commented:
I'll ask the other Exchange admin to check the SMTP properties as you suggested
0
 
OptecAuthor Commented:
Where in the SMTP connector is the FQDN referenced?
0
 
George SasIT EngineerCommented:
Open the ESM , go to your server and check SMTP under protocols.
Properties and under the "Delivery tab" check "Advanced"
0
 
WaseemsCommented:
this looks like DNS problem from the other server try using
nslookup
set type=MX
youdomain.com
do you get the correct MX ip and information, I guess not
may be the other domain create a zone for your domain in dns which they should not do, if so just delete it and this should solve the problem
tell me what information nslookup command gave?
0
 
OptecAuthor Commented:
Here is the nslookup from the remote server
It looks correct
SP32-20100903-132821.jpg
0
 
George SasIT EngineerCommented:
Ok , but still I am sure your remote partner uses an incorrect FQDN or it's using a smarthost.
0
 
OptecAuthor Commented:
The FQDN value is mail.valueplace.com
Their email goes out through their Barracuda spam filter
0
 
George SasIT EngineerCommented:
Does your exchange check for SPF records ?
0
 
George SasIT EngineerCommented:
K just to make a summary:
a.You try to send mail from valueplace.com to optecdisplays.com
b.The SMTP diag was done from the REMOTE location.
c. When you try the telnet test from REMOTE location (valueplace.com) the mail goes trough correctly.

Did the remote location tried to make an SMTP connector to send mail DIRECTLY to your MX records instead of going trough Barracuda ?
0
 
OptecAuthor Commented:
My Exchane (Optec) has ORF anti spam software in which I enabled SPF, however, messages are stopped before reaching that stage.
The summary is correct.
Remote Exchange has not tried SMTP connector, I can ask for it next week.
Here is a log sent to me from Valueplace:



Delivery has failed to these recipients or distribution lists:
 
oded@optecdisplays.com
An error occurred while trying to deliver this message to the recipient's e-mail address. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message, or provide the following diagnostic text to your system administrator.
 
 
 
 
 
 
 
Diagnostic information for administrators:
 
Generating server: smtp.valueplace.com
 
oded@optecdisplays.com
#< #4.0.0 X-Spam-&-Virus-Firewall; conversation with mail.optecdisplays.com[67.91.72.36] timed out while sending HELO> #SMTP#
 
Original message headers:
 
X-ASG-Debug-ID: 1283360827-2b8400300000-lrRreK
X-Barracuda-URL: http://10.80.80.241:8000/cgi-bin/mark.cgi
Received: from mail.valueplace.com (localhost [127.0.0.1])      by
 smtp.valueplace.com (Spam & Virus Firewall) with ESMTP id A7D732B8DC1   for
 <oded@optecdisplays.com>; Wed,  1 Sep 2010 12:07:08 -0500 (CDT)
Received: from mail.valueplace.com ([10.80.80.246]) by smtp.valueplace.com with ESMTP id jFWV5M86RoeKDTWB for <oded@optecdisplays.com>; Wed, 01 Sep 2010 12:07:08 -0500 (CDT)
X-Barracuda-Envelope-From: helpdesk@valueplace.com
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-ASG-Orig-Subj: test
Subject: test
Date: Wed, 1 Sep 2010 12:07:07 -0500
Message-ID: <BB0DC9E55623D04EBB18B993DA75B1A603164303@exchange1.Consolidated-Holdings.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: test
Thread-Index: ActJ+BtscuBoj/bAQT6ihSRBsN6isA==
From: Help Desk <helpdesk@valueplace.com>
To: <oded@optecdisplays.com>
X-Barracuda-Connect: UNKNOWN[10.80.80.246]
X-Barracuda-Start-Time: 1283360828
X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at valueplace.com



0
 
George SasIT EngineerCommented:
It's your e-mail delivered directly to your exchange ?
Does the ORF check for reverse DNS ?
0
 
George SasIT EngineerCommented:
Do you require authentication upon receiving e-mail ?
I noticed the SMTP test sends "ehlo" ... have you (remote host)  tried the telnet test with EHLO instead of HELO ?
0
 
OptecAuthor Commented:
Yes my email is delivered directly to the Optec Exchange server.
Yes ORF checks reverse DNS.
Both Valueplace name and ip are whitelisted in ORF.
The telnet messages showed in ORF logs as whitelisted.
Haven't tried EHLO telnet.
Are you asking about AD authentication upon receipt?  I don't think so, where do I verify?
0
 
George SasIT EngineerCommented:
I am asking about the SMTP authentication.
I have asked about the reverse DNS because maybe your ORF tries to resolve the DNS of smtp.valueplace.com and check it against the IP address of the barracuda box that delivers you the mail and if that does not match it will drop the connection.
Has the barracuda same IP as the smtp.valueplace.com ?
0
 
OptecAuthor Commented:
Update

My Exchange (Optec) does not use SMTP Authentication.

The Barracuda and smtp.valueplace.com have the same public ip of 68.143.33.62.

Looks like remote Exchange has DNS issue, it resolved mail.optecdisplays.com to 74.208.5.3 and 74.208.5.21 which are the Name Servers instead of 67.91.72.36.

0
 
George SasIT EngineerCommented:
K , can they fix that ? If they fix it then your problem is fixed also ... not YOUR problem anyway :)
0
 
OptecAuthor Commented:
Remote Exchange fixed the nslookup error and issued the following:

telnet 67.91.72.36 25
EHLO valueplace.com

At this point the connection timed out and it showed the “Connection to host lost” message from telnet.

Then

telnet 67.91.72.36 25
HELO valueplace.com
The SMTP gateway immediately replied with a 250 mail.optendisplays.com Hello [68.143.33.58]

Then completed the command sequence and the message was sent.


0
 
George SasIT EngineerCommented:
Good :) so the problem is still on the other side or maybe your spam filter does not like the EHLO.
0
 
OptecAuthor Commented:
Any other ideas to fix the issue?
0
 
George SasIT EngineerCommented:
I don't know the ORF anti spam , but I would suggest you to contact their rupport department and ask them if this is a known bug
0
 
OptecAuthor Commented:
I have emailed ORF and they said that the fact that the log viewer did not have any sender entries for the domain indicates these emails never reached ORF (timed out at the HELO stage before it had a chance to test them), so it is definitely not ORF blocking them.
0
 
sunnyc7Commented:
hi optec
Can you go to DC of both domains (yours and the other exchange server)

from DC
do this
start > run > dnsmgmt.msc

check if there is any MX record entry in DC forward look-up zone.
Or if there is an entry for your partner exchange in yours.

Please post screenshots of internal DNS at both locations
0
 
George SasIT EngineerCommented:
Optec: "Yes ORF checks reverse DNS." - Can you temporary disable this and see if it works ?
0
 
OptecAuthor Commented:
Both ends don't have any mx record in the forward look-up zone.
A test email didn't arrive after disabling reverse DNS checks in ORF.
0
 
OptecAuthor Commented:
We found that our Palo Alto Networks 500 Firewall classified SMTP traffic from ValuePlace as Unknown-TCP and therefor dropped the session.
It is still under investigation at PAN, my guess is that this traffic deviated a bit from the protocol standards as it was a singular event.
Meanwhile another rule was added to allow this traffic.
0
 
George SasIT EngineerCommented:
Tbh , I gave up :( I'm not a network guy so I didn't thought at the firewall as it was allowing telnet ... we live and learn.
0
 
OptecAuthor Commented:
I also didn't think to check the firewall logs because of telnet success.
Thank you for all your help.
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 17
  • 16
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now