Forums & Blog

Hi all,

I've got one user from one domain whom is experiencing a new trend of rejected emails.  There are really three types:

1.  No MX record- I think this is a problem with the DNS.  The rejection notification will say something like: 

Failed recipient recipientname@domainname.com

Reason:  Failed four attempts to connect to the recipients mail server.  No MX records were found for the 'domainname.com' domain.Failed four attempts to connect to the recipients mail server.

Attempted to send the message to the following ip's:

###.###.###.###

2.  Relaying denied - I'm not sure why this happens.  A rejection will say:

Failed recipient recipientname@domainname.com

Reason:  Remote host said: 550 5.7.1 recipientname@domainname.com...

Relaying denied.  IP name possibly forged [MY MAIL SERVER'S IP ADDRESS]

 

3.  Contact - seems to be perhaps a routing problem w/ ISP?  This is identical to #1, but without the failed MX mention.

Failed recipient recipientname@domainname.com

Reason:  Failed four attempts to connect to the recipients mail server.

Attempted to send the message to the following ip's:

###.###.###.###

Any thoughts?  I should say that I'm running SmarterMail 3.3.2543.

Any help is greatly appreciated...

The first issue pertains to the fact that SmarterMail is unable to resolve any MX records for the recipients domain. This could pertain to a DNS resolution issue, or the fact that they don't have an MX record.

The second issue is one you will need to contact the receiving domain for. They seem to not allowing the message to be relayed based off of your IP address.

 The last issue pertains to the fact that SmarterMail is unable to connect to the designated IP address.

 Hope this helps.

Thanks for the help, ST-BDavis.

The first issue certainly looks like a DNS issue.  I turned on detailed logging to get a capture of what's happening.  I also did some DNS testing.  From the box running SmarterMail, I am able to use nslookup is able to resolve the MX record correctly.  However, I can see from the bounced message and from the delivery log that SmarterMail attempted to deliver to another IP address belonging to that domain, but not that of the MX record.  Seems certain to be a DNS issue.  However, I'm troubled by this entry in the delivery log.

15:02:28 [34682] Delivery started for user@domain.com at 3:02:28 PM
15:02:43 [34682] Sending remote mail for user@domain.com
15:03:00 [34682] Connecting to 208.6.38.2
15:03:42 [34682] Binding to local ip '216.128.23.117' failed.  Switched binding to primary local ip.
15:03:42 [34682] Connection to 208.6.38.2 failed

The troubling line is the fourth one, which I've put in bold.  What do you make of this?  This box has four IP addresses.

Thanks in advance!

I would suggest checking General Settings and making sure the DNS text boxes have the correct IPs (or leave them blank and SmarterMail will auto detect)

The bold line is just an error message that is too broad. It shows up when you can't connect to another mail server. SmarterMail isn't sure whether thats because it couldn't use the IP set in protocol settings or if the connection simply couldn't be established, so it tries again from the primary IP address. All in all, it's a symptom rather than the cause. Once you sort out the DNS issues, it should go away.

The DNS text boxes are blank, so it's using the DNS addresses on the local machine.

Thanks for your input, James.  It definitely seems to be caused by DNS issues, so I'll check with my ISP.

UPDATE:  I let the logs collect a couple of days worth of data so that I could approach the ISP with some hard evidence to help them troubleshoot.  The problem resolved itself during that timespan.

Coincidentally, not long after this our ISP announced that they were making DNS changes.  The changes weren't to affect the DNS servers I was using, but it seems highly suspect that DNS changes/testing in general were occurring at the ISP level.  I suspect the DNS servers my box points to had DNS changes upstream.

Regardless, the problem is resolved.  In summary, the SmarterMail app performed as it should and the problem appeared to be external.  Thanks to all who posted comments and assisted in this.