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

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

problem sending email to one external domain

We have a problem sending email to one of our vendors.  Everything was working fine until about 3 days ago when all mail going to domain2.com failed.

User1 on 3/22/2011 1:31 PM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<mail.domain1.com #5.7.1 smtp;550 5.7.1 Unable to relay for User1@domain2.com>

In message tracking, it gets as far as starting outbound transfer of message then generates the NDR.

I have ran smtp diag from the Exchange server and using my address with User1, it completes successfully; both mail from and rcpt are ok..  I have checked several spam sites and our public address is not found in any blacklist database.

I just sent a test email to that user to generate an NDR and had diagnostic logging enabled for Exchange Transport.  The only thing I found in the application log that stands out is where the NDR occurred.  It shows that error (unable to relay) on rcpt command, but what I don't get is the remote host IP address is not what resolves to either of their mx records.  The smtp diag test resolved the mx records correctly, but Exchange shows something different.  I'm at wits end on this one.
0
Seth Simmons
Asked:
Seth Simmons
  • 6
  • 6
  • 2
  • +3
1 Solution
 
Viral RathodConsultantCommented:
0
 
Viral RathodConsultantCommented:
Also it is possible that external domain have blocked your domain or IP Address

To cross check the issue
Telnet to externaldomain.com from your domain server
Send the test E-mail using Telnet command
After sending the mail you will get the exact error

Hope this helps.
0
 
Alan HardistyCommented:
What version of Exchange do you have?

Have you got a specific SMTP Connector / SEND Connector configured for this domain and you are using an old IP as the smarthost address?

Do you have the old server IP address for the remote domain in your hosts / lmhosts.sam file in c:\windows\system32\drivers\etc ?

Have you got a DNS entry for their domain added using the wrong IP address?

Alan
0
Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

 
AmitIT ArchitectCommented:
Below are the resons:

1) This is a permissions problem.  It seems due to some reason the sender is not allowed to email this account or an anonymous user is trying to send mail to a distribution list.

2) Check SMTP Virtual Server Access Tab and see if you have allowed this machine to relay.

3) User may have a manually created email address that does not match with your system policy. Ask user to use Check name button
0
 
jtwcsCommented:
Have a look at this article, http://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html

It may be something as simple as clearing your domain name or IP from a spam list.
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:
viralrathod:
Exchange 2003.  As mentioned, ran the smtp diag test from the Exchange server and was successful.  I did do a telnet session to that address (which I found to be their Exchange server) and the test failed with the same error when I did rcpt to; came back with the same relay error.

alanhardisty:
No send/smtp connector; no manual dns/hosts/lmhosts entries; no smarthost

amitkulshrestha:
It's multiple email accounts from all users at domain1.com.  I tried same user from my gmail account and works fine.  They are user accounts, not distribution lists.  We are the sender, not the recipient.

jtwcs:
I already mentioned I have checked a number of sites and returned no results for our external address on spam blacklist.
0
 
Alan HardistyCommented:
Sounds rude not to ask you to look at my article appropriately titled:

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

This will get you to check if your server is RFC compliant or not and once it is and you still have issues - then the issue is beyond your control 99% of the time.
0
 
maxxmyerCommented:
Sound like it is not you, it is them.....
@alanhardisty  good article.
0
 
Alan HardistyCommented:
Thanks - If you like it - feel free to vote for it ; )
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:
yes, that is a good article and I have already considered these factors

i have been leaning more toward an issue on their end (trying to get answers as to what changed earlier this week) but still waiting on them

i still don't understand the address difference here.  as i mentioned, when i do the smtp diag test, it passes.  The error in the transport shows a different IP address than what the mx record has so that's the part I can't make sense of.  When I do the telnet test to that address (which is in the same domain), I can reproduce the problem.  It's the fact that Exchange isn't communicating with one of the 2 servers listed for mx records.

For example, if domain2 had mx records as 10.1.1.1 and 10.1.1.2 if i do telnet test or smtp diag test, it passes with mail from and rcpt to.  Exchange transport shows it fails when connecting to 192.168.1.1 and so does the telnet test; though 192.168.1.1 responds as microsoft smtp 7.5 with a server on their domain name.  I just can't figure out how Exchange is getting 192.168.1.1 when it's not an mx record (not the real addresses of course; just example to show the difference on how it's resolving.)  I did flush dns cache on exchange server and stills same behavior.
0
 
Alan HardistyCommented:
If you want to be sure - drop me a test email to alan @ it-eye.co.uk - I can then see what you send out as, check you are RFC compliant and then hopefully leave you happy that it's not your problem : )
0
 
AmitIT ArchitectCommented:
Alan,

Check this link, it might help. You can paste the header information and see where it is failing.

http://www.levinecentral.com/mail_parse/default.aspx
0
 
Alan HardistyCommented:
Okay - test message received.

Here are my findings:

Your sending IP is 208.xxx.xxx.80 - Reverse DNS on this IP Address is vpn3.domain.com and vpn3.domain.com resolves to IP 208.xxx.xxx.80 - So far, so good.

The problem is that your FQDN is buf-ex02.domain.com and that doesn't resolve to anything in DNS.  If you change your FQDN on the SMTP Virtual Server> Delivery Tab> Advanced Button to vpn3.domain.com - the other domain may be happier to receive your mail.

Alan
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:
the vpn records point to our firewall for user access; wonder if it makes more sense to just have the buf-ex02 (internal name) as the .80 address and the vpn as alias records to that
0
 
Alan HardistyCommented:
That would work - or create another name in DNS pointing to the .80 IP address, change the server name and Reverse DNS to match.
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:

Problem resolved...

Restarted SMTP virtual server and it suddenly started sending mail using the correct MX records for that domain.  Confirmed with them that no MX records changed so I'm at a total loss as to why SMTP service was not using the correct address to communicate with the last 3 days.
0
 
Seth SimmonsSr. Systems AdministratorAuthor Commented:
figured it out on my own
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.

  • 6
  • 6
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now