4

I have this asp.net application that sends out emails. The SMTP server is iis6. The emails are being sent on behalf of our application users and they have different domain names. Most of the email providers, like gmail and yahoo, would accept the emails but some of them not e.g. AOL.

This is the message that users receive from our SMTP server after a few minutes:

Subject: Delivery Status Notification (Failure) This is an automatically generated Delivery Status Notification. Unable to deliver message to the following recipients, due to being unable to connect successfully to the destination mail server.

squillman
  • 37,618
  • 10
  • 90
  • 145

9 Answers9

2

The message you posted is a failure to connect which doesn't necessarily mean they refused your email, it seems more likely a dns issue or some other connection issue. Some things to check/think about are:

Can you check your application server to make sure it is properly resolving the dns and MX records for the domain you are trying to email.

Can you telnet from this server to those domains, if so what response do you get?

Do the domain names you are sending from have spf records and if so, is the ip you are sending from included in the spf record?

Are reverse DNS records setup properly for the IP you are sending from for the domains you are sending as?

Ideally, before anyone can really give you a definitive answer on the problem you need to have a telnet or something and get a server response telling you why you cannot connect in the first place.

Charles
  • 879
  • 5
  • 9
1

One possible option is that these servers are flagging your email as Spam. Even if it is not really spam, many email providers block messages that are not exactly correct, or that are going out to a large number of people.

We ran into this at one point and had to contact a bunch of providers to get white listed. Once we contacted them and explained our email coupon program (opt in, fully compliant with CAN-SPAM) and gave them the details, they added us to white lists.

There are a lot of things that can get you flagged as a spammer. Here are a couple to check:

  1. Number of emails going out.
  2. SMTP headers on the email not matching the domain you're sending from. (Example: using a from address of @microsoft.com when the email is coming from your own domain.) This can happen by accident if you're using a domain like @yourcompanyname.com, but the SMTP server is registered under a different domain or is not registered under your domain.

Here are a few links you may find useful

http://searchwarp.com/swa209211.htm

http://www.wilsonweb.com/05/020529b.htm

http://searchdomino.techtarget.com/news/article/0,289142,sid4_gci1192720,00.html (not really Domino specific, ins spite of the url)

Micky McQuade
  • 195
  • 9
David Stratton
  • 453
  • 2
  • 10
0

Who are you hosting your application with? I've had problems with shared hosts having all sites hosted on their servers blacklisted into the spam hole.

Just because your application isn't sending spam doesn't mean that another app on the shared host isnt. Since it's a shared host, all smtp traffic comes from the same source, which can end up being blocked.

Ryan Michela
  • 1,137
  • 3
  • 16
  • 23
  • I upped this comment as it was -2. Even though the question clearly states that they have their own SMTP server, Ryan's point is valid. Fyi - spamhaus.org will tell you if you're on a blacklist. – Luke Puplett Jun 18 '10 at 14:01
0

The message you posted is a failure to connect which doesn't necessarily mean they refused your email, it seems more likely a dns issue or some other connection issue. Some things to check/think about are:

  1. Can you check your application server to make sure it is properly resolving the dns and MX records for the domain you are trying to email.

  2. Can you telnet from this server to those domains, if so what response do you get?

  3. Do the domain names you are sending from have spf records and if so, is the ip you are sending from included in the spf record?

  4. Are reverse DNS records setup properly for the IP you are sending from for the domains you are sending as?

Ideally, before anyone can really give you a definitive answer on the problem you need to have a telnet or something and get a server response telling you why you cannot connect in the first place.

Charles
  • 879
  • 5
  • 9
0

Where is the NDR coming from, presumably your IIS SMTP server, although I don't work with IIS SMTP very often so I'm not sure if the IIS SMTP server is capable of generating NDR's.

In any event make sure to enable logging in the properties of the IIS SMTP server and then check the logs after you receive an NDR. If there are no entries in the log file that correspond to the email that generated the NDR then I would suspect a problem with the IIS server's dns client being able to resolve the MX record for the recipient's domain. If there are entries in the log file that correspond to the email that generated the NDR, then the SMTP status codes in the log file should clue you in to what's happening.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
0

Make sure you are specifying Sender and Return-Path in the email header. Read this one: Send email on behalf of clients

Community
  • 1
0

You should first check that you can actually connect to the destination SMTP mail server from your internal server. You can do that by telnet <destination server> 25 and see if you get the greeting. Sometimes, some places filter out port 25 connections as a spam prevention policy.

Another potential problem with mail is the reverse dns setting. Sometimes, the destination servers check who you claim to be by checking your source ip against the domain that you claim to represent. You may need to set this up with your DNS provider.

sybreon
  • 7,357
  • 1
  • 19
  • 19
0

Some mailservers will limit your connections until you establish that IP address as a safe sender. This takes several things - you have to adhere to best practives for settings up:

  1. Reverse DNS Entry
  2. SenderID / SPF
  3. Domain Keys

You'll also be better off if you submit the IP(s) to the various whitelist / bulk sender lists, such as AOL and yahoo.

The number of users that report you as spam and the number of bad email addresses you send to will also affect your ability to send.

Habeas and Returnpath can also give you some extra "points" to make your spam score better.

Finally, if you are sending emails from users that aren't on your domain, you're likely to always have some issues. You might try sending from a specific email address, and just changing the from name and "reply-to" address in the email.

ChickenMilkBomb
  • 419
  • 6
  • 14
0

I may be a day late and dollar short but I just recently ran into this and alas, your question came up. My turned out to be bad DNS resolution as a result of MalwareBytes.

I could see the e-mails hanging out in the IIS SMTP queue and eventually it would fail. Here is some things I did and ultimately figured out the cause.

For us, it was specifically to one domain.

I ran packet capturing on our firewall to see if I could see the traffic going out of the e-mail server. It was not so I knew the packets were stopping within the network. I also did not see any blocking messages in the firewall logs specifically blocking the traffic.

Step 1: Go to MXToolbox and plug their domain name in for the MX Lookup Tool. This will give you the correct IP address you'll verify in step 2.

You should also put your public IP address in there and run the blacklist check and SPF check.

Step 2: Run NSLOOKUP from the command prompt on the SMTP server. 

>>nslookup -type=mx domain.com
Server:  domaincontroller1.mydomain.com
Address:  192.168.1.6

Non-authoritative answer:
domain.com   MX preference = 1, mail exchanger = mail.domain.com
mail.domain.com      internet address = 168.144.68.87

This was the issue we had specifically. Our local DNS server was resolving the domain to a 127.x.x.x IP address. That was identified immediately as the problem and we tracked it down to an issue with MalwareBytes not allowing the DNS server to resolve the domain. We had to disable MWB, clear the DNS cache and then query the domain again to get the correct IP. 

Non-authoritative answer:
domain.com MX preference = 10, mail exchanger = mx.domain.com

mx.domain.com      internet address = 127.42.0.2
mx.domain.com      internet address = 127.42.0.4
mx.domain.com      internet address = 127.42.0.5

Step 2: Telnet to the mail exchanger domain on port 25. You should see the following. Try to type EHLO domain.com if it connects and you should see some more things pop up. 

>> telnet mail.domain.com
220 xmail03.domain.com ESMTP  648143d3667b3045487bb901cdbbf649
EHLO domain.com
250-xmail03.domain.com
250-PIPELINING
250-SIZE 100000000
250-DATAZ
250-STARTTLS
250-AUTH LOGIN PLAIN
250 8BITMIME

If it does not connect or just gives a black screen, press ENTER. If it dumps you back out to the command prompt it's not connecting or the server is refusing it.

Travis
  • 870
  • 8
  • 23