undeliverable emails (Full Version)

All Forums >> [Microsoft Exchange 2003] >> Server Security



Message


Pearlyshells -> undeliverable emails (13.Oct.2010 3:37:25 PM)

one of our employee's is receiving this undeliverable message back:

(Undelivered): 571 incorrect IP - psmtp

How do we resolve it. The message originator is:

X-SFDC-Interface: internal
Received: from [10.x.x.x] ([10.x.x.x:57122] helo=na7-app2-11-sjl.ops.sfdc.net)
by mx3-sjl.mta.salesforce.com
----------------------------

The application vendor supporting the email client that our employee is using sent us this information but I'm leery about implementing it. What is "IP Lock"?

Error 571 incorrect IP - psmtp on Salesforce.com emailsShare
Twitter Gmail Blogger Buzz Orkut Google Reader Bookmarks More
Comment Print Issue: Messages from Salesforce.com to your domain bounce.

Symptoms: The bounce message for the undelivered emails is "571 incorrect IP - psmtp."

Resolution: An IP Lock configuration has been set up to tie the domain in the sender address of an email with the IP range of the mail servers authorized to send emails from that domain, and the list of allowed IP address ranges does not include the Salesforce.com mail servers sending these messages.

To resolve this issue, add the IP addresses of the Salesforce.com servers to the IP Lock list. According to Salesforce.com support, the IP address spaces are as follows:

204.14.232.0/25
204.14.233.0/25
204.14.234.0/25
204.14.235.0/25

The batch commands to add these ranges to your IP Lock configuration are:

addallowedip ,:204.14.232.0/25
addallowedip ,:204.14.233.0/25
addallowedip ,:204.14.234.0/25
addallowedip ,:204.14.235.0/25




uemurad -> RE: undeliverable emails (17.Oct.2010 12:45:12 PM)

psmtp indicates the message is being delivered to Postini (now part of Google).  That means either you are sending your outbound mail through their service or because the recipient system is sending all of their inbound mail through their service.

If it's your outbound mail, you need to verify the smarthost address to which you are sending.

If it's the recipient's inbound mail, you first need to verify your outbound DNS is getting current MX information for their domain, then you need to work with the recipient domain to verify end-to-end connectivity.




Pearlyshells -> RE: undeliverable emails (19.Oct.2010 11:09:22 AM)

Very much appreciate the help. I found out that the problem is with the recipient inbound mail only. Our emails to him are going thru fine. So, now I need to check for MX record for the recipient domain in our DNS? As I was discussing this with my coworkers, I also discovered that we have 2 external name servers along with our local DNS servers. I presume the MX records should exist in our local DNS servers, right?

When I check our primary DNS server, I don't see the domain Salesforce.com as an MX record. Do I need to include it and assign the IP addresses the vendor specified? Is that what needs to happen?




uemurad -> RE: undeliverable emails (19.Oct.2010 11:47:22 AM)

Typically you use the public DNS servers to ensure you are getting updates if the recipient makes a change.

On your Exchange server, use NSLookup to query for the MX record using the command:
nslookup -q=mx salesforce.com

That will tell you if you are able to resolve at all currently. If you are, confirm you are seeing the public information with the following sequence:

nslookup
server 4.2.2.2
set type=mx
salesforce.com

What you are looking for is that the two checks above return the same information (the IP address 4.2.2.2 is one of the DNS root servers).




Pearlyshells -> RE: undeliverable emails (19.Oct.2010 12:16:29 PM)

interesting. when I did the Nslookup on salesforce.com I was able to resolve that there are 4 instances and they are resolving to what appears to be external ip addresses (so, they don't show as 12.x.x.x...). then, when I did the nslookup to validate the same IP addresses as per the second set of instructions, I get the same IP addresses. I was expecting the IP addresses to be the 204.x.x.x series of addresses. Instead, I am seeing 64.x.x.x IP's.




Page: [1]