[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

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

E-Mail Bounce Backs

Hi.  I am trying to send e-mail through my exchange server & am getting bounce backs with this NDR:
==========================
server.commitcrm.com rejected your message to the following e-mail addresses:

support@commitcrm.com (support@commitcrm.com)


server.commitcrm.com gave this error:
Please turn on SMTP Authentication in your mail client, or login to the IMAP/POP3 server before sending your message. remote.ourdomain.com [74.xxx.xxx.90]:56989 is not permitted to relay through this server without authentication.
============================

MX & other DNS checks out.  We;re not using any POP/IMAP, just SMTP.  Any ideas?

Thanks in advance -- JR
0
JRiley562
Asked:
JRiley562
  • 15
  • 14
  • 5
1 Solution
 
Alan HardistyCommented:
You need to authenticate to your Exchange Server to send emails out, so tweak your CommitCRM settings and that should sort the issue.

You will need to run the Commit CRM Email ServerConfig file to edit the settings (usually X:\CommitCRM\Server\ServerConfig.exe)

On the Outgoing Mail Server Tab, add the relevant credentials and test until it works.

Alan
0
 
Paul MacDonaldDirector, Information SystemsCommented:
Is it safe to say remote.ourdomain.com is your SMTP server?  And it relays through server.commitcrm.com?
0
 
JRiley562Author Commented:
Thanks for the quick reply.  However, I am sending a plain old e-mail to commit requesting integration support.  I'm using my Outlook client & send mail thru my Exchange Server 2010.
0
Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

 
JRiley562Author Commented:
@paulmacd                 remote.ourdomain.com is my SMTP Server.  server.commitcrm.com is supposed to be the destination.  I'm just sending email to support@commitcrm.com.
0
 
Paul MacDonaldDirector, Information SystemsCommented:
That's what I thought.  I wonder if this is your problem at all.  It may be they've misconfigured their SMTP server so it doesn't accept anonymous mail - at least at that address.

If you have a free e-mail account somewhere (gmail, etc) you could try sending the request from there.  Alternately, give them a call and ask them what's up.  This doesn't seem to be working the way one would expect it to, essentially asking your SMTP server to authenticate to their SMTP server so mail can be delivered.
0
 
Alan HardistyCommented:
Sorry - then that's a random error just sending an email to them.

Can you try to resolve server.commitcrm.com on your Exchange Server.  Does it resolve to your Commit CRM server internally?
0
 
Alan HardistyCommented:
Commitcrm use Postini for email filtering, so I think this is being resolved internally to your Commit CRM server and that's why you get the problem.

The error you are getting isn't from a Postini server!
0
 
JRiley562Author Commented:
Thanks for the replies.  If these are just random errors, they seem to be occurring much more frequently.  Is there anything I can do on my end to minimize these NDR's?  This is the third in less than a week to different e-mail destinations.
0
 
Alan HardistyCommented:
Yes - please follow my advice here:

http:#a39238242
0
 
JRiley562Author Commented:
I've attached the latest NDR.
0
 
JRiley562Author Commented:
Yes the server is resolved by my Exchange Server as:

Name:    server.commitcrm.com
Address:  207.58.143.183

And, I am not generating email from my Commit server.  I am on a network client sending an email.
0
 
Alan HardistyCommented:
Okay - I resolve the name to the same IP, but those are not the commitcrm MX record IP Addresses, so it would seem to be a DNS issue your side resolving commitcrm.com to the wrong IP's.

On your Exchange server, please run the following from a command prompt:

nslookup {press enter}
set type=mx {press enter}
commitcrm.com {press enter}

What do you see as the result(s)?
0
 
Paul MacDonaldDirector, Information SystemsCommented:
They may be having DNS issues on their end.  Your e-mail may be going to the wrong server.
0
 
Paul MacDonaldDirector, Information SystemsCommented:
[alanhardisty] drew a similar conclusion I see.  I'd assert the problem was on their end, not yours though.  Especially since he resolves the same, wrong, IP address(es).
0
 
Alan HardistyCommented:
I resolve server.commitcrm.com to the same IP, but there isn't anything in the DNS records pointing mail to server.commitcrm.com, so there isn't any logic as to why that is where the emails are being sent, unless they do have a DNS issue, but I'm not seeing it my end and all my DNS reports come back showing Postini as their inbound mail server(s).

207.58.143.183 is one of their DNS servers and they also have it listed in their SPF record, so potentially it is an outbound mail server for them, but not an inbound one.

Let me try emailing them!
0
 
Alan HardistyCommented:
Works for me!!  Seems to be a problem at your end JRiley562.
0
 
JRiley562Author Commented:
Here their MX record when I nslookup server.commitcrm.com.

commitcrm.com
        primary name server = ns1.commitcrm.com
        responsible mail addr = maayan.commitcrm.com
        serial  = 2009101506
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 86400 (1 day)

MXToolbox gives me this when I MX Check commitcrm.com:

Pref       Hostname       IP Address       TTL       
10       commitcrm.com.s7a1.psmtp.com       64.18.6.10       4 hrs       Blacklist Check      SMTP Test
20       commitcrm.com.s7a2.psmtp.com       64.18.6.11       4 hrs       Blacklist Check      SMTP Test
30       commitcrm.com.s7b1.psmtp.com       64.18.6.13       4 hrs       Blacklist Check      SMTP Test
40       commitcrm.com.s7b2.psmtp.com       64.18.6.14       4 hrs       Blacklist Check      SMTP Test

I just did a dnscmd /ClearCache on my Exchange Server and the my local nslookup now matches MXToolbox results.

It almost seems that I have to clear my dns cache on the server before I send e-mails.  Any thoughts?
0
 
Paul MacDonaldDirector, Information SystemsCommented:
No, I mean the problem appears to be in DNS at commitcrm.com.  Some sort of round robin issue, which would explain why it's intermittent for [JRiley562].
0
 
Alan HardistyCommented:
Are you using DNS Forwarders on your DNS Server?

Have you set up automatic scavenging of stale resource records?

Alan
0
 
Alan HardistyCommented:
@Paul - not convinced it is a problem with Commitcrm's side of the equation at all.
0
 
JRiley562Author Commented:
No, no forwarders.
0
 
JRiley562Author Commented:
Now, to add some confusion, I have 1) local dns server for my exchange server (SBS 2011 - all on same box); and, 2) primary dns records hosted by GoDaddy.  GoDaddy has the MX record for my exchange server.  We don't have general mail failures, just sporadic ones.  Our exchange Server normally hums along very well, except for these intermittent problems.

With respect to scavenging, I'm turning it on now.  Keep it the recommended 7 days?
0
 
Alan HardistyCommented:
You can scavenge a little quicker if you like - 2 days should be good.

I have always found that adding DNS forwarders resolves a lot of issues with SBS 2011 and I would recommend that you add them too.

Either add your ISP's or 8.8.8.8 and 8.8.4.4 (Googles) and that should help.

Alan
0
 
JRiley562Author Commented:
Alan,  Apologies for my denseness here.  My ISP is Roadrunner.com.  Do you mean GoDaddy?  I've thought about just using Google's but wasn't sure the impact.
0
 
JRiley562Author Commented:
I added the Google forwarders.  I did a dnscmd /clearcache on the server.  I did an ipconfig /flushdns on my client.  Tried to e-mail support@commitcrm.com and received the same 550 NDR.

server.commitcrm.com gave this error:
Please turn on SMTP Authentication in your mail client, or login to the IMAP/POP3 server before sending your message. remote.ourdomain.com [74.xxx.xxx.90]:12109 is not permitted to relay through this server without authentication.

Is there any SMTP-to-SMTP server authentication going on?  I don't have, and really don't want , TLS turned on.  My Exchange Server has a self-signed certificate.  Any other discrete data needed here?
0
 
Alan HardistyCommented:
Doesn't really matter whose forwarders you add - as long as they resolve and help to resolve DNS queries happily.  I did mean Google's.

Did you run "ipconfig /flushdns" on your Exchange Server?

Give it 24-48 hours and try it again by which time it might realise where it needs to send emails, or create a new SEND connector specifically adding one of the IP's of the commitcrm MX records and then that should get around the problem.
0
 
JRiley562Author Commented:
I /flushdns'd on the server.  I created the send connector for "commitcrm.com" as it asked for the address space.  I sent an email.  And the result is ... Wow, no NDR.

Looks like it was sent & not stuck in my queue.  So I guess this means that when we get "550" messages, I need to temporarily create a send connector for that address space.  I'm hoping this doesn't happen too often.
0
 
JRiley562Author Commented:
Thank you to Alan.  Was a very good step by step distillation of the problem that led to a quick resolution.  Very happy, indeed!
0
 
Alan HardistyCommented:
DNS forwarders should resolve the majority of those sort of problems.

The Commitcrm.com one does seem to be a somewhat special case and I have no idea where the server.commitcrm.com address came from unless it is a very old, stale record hanging about.

Alan
0
 
JRiley562Author Commented:
Alan,

Here is a new twist.  I can't send e-mail to a different domain now.  Here is the NDR.  Do you want a new forum question for this?

Diagnostic information for administrators:

Generating server: BENCHMARKSERVER.recipientdomain.local

user@domain.net
wh03.domain.com #553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) ##

Original message headers:

Received: from BENCHMARKSERVER.recipientdomain.local
 ([fe80::f9bd:7930:9953:9efd]) by BENCHMARKSERVER.recipientdomain.local
 ([fe80::f9bd:7930:9953:9efd%10]) with mapi id 14.02.0342.003; Tue, 11 Jun
 2013 14:04:19 -0400
From: Service <recipient@recipientdomain.com>
To: Ryan Moisio <user@domain.net>
Subject: Another test (my apologies)
Thread-Topic: Another test (my apologies)
Thread-Index: Ac5mzgf94eEodWbwQfOKLNpIi3ezXg==
Date: Tue, 11 Jun 2013 18:04:17 +0000
Message-ID: <FBAC85E327A04B488C72CFE317D36B5602DC8308@BENCHMARKSERVER.recipientdomain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.0.51]
Content-Type: multipart/related;
      boundary="_004_FBAC85E327A04B488C72CFE317D36B5602DC8308BENCHMARKSERVER_";
      type="multipart/alternative"
MIME-Version: 1.0


Thanks --

John Riley
0
 
Alan HardistyCommented:
No need for a new Q - it's a pretty simple answer!

Are you using a Smarthost for sending most mail out?

If yes, then you need to authenticate first.

If no - then they are rejecting you for some reason.
0
 
Alan HardistyCommented:
Have a read of my article and check out your domain to make sure you tick all the boxes:

http://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html

Alan
0
 
JRiley562Author Commented:
Yep.  You're absolutely right about the e-mail addresses.  Sorry.

No smarthost.  I will check your article & thanks again so much for your help!!

John
0
 
Alan HardistyCommented:
My pleasure - shout if you have any further questions.

No worries about the email addresses - just glad I could nip them in the bud quickly.  EE gets indexed by Google before you can say "Oh crap!", so the quicker they go, the better for all concerned.  Just be careful not to post email addresses / domains in general as the Mods get numerous requests to have them removed from questions after the event, sometimes years after!
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 15
  • 14
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now