View Full Version : Problems sending to some recipients using CDO?
05-26-2007, 05:08 AM
I am using XP's SMTP service to send emails via ASP and CDO. I am able to send to one of my email accounts, but cannot send to another. The email server I cannot send to is a public server, at a well-known ISP. Memory is foggy, but I think I remember something about that server not allowing relayed messages? I'm not sure.
Anyway, I was hoping others who have ad this type of trouble could shed some light? Thanks.
05-29-2007, 06:58 PM
I think i remember reading something about that, but i can't find where anymore. It said something about configuring the smtp server differently to allow relaying to that server (yeah okay so im repeating your thing). Or it could just be that your "from" is not a known address (something to do with the server DNS) to that well known isp and it just rejects it totally. If I can refind that page where i read about it i'll link you to it.
05-30-2007, 10:48 AM
Could the ISP be doing a reverse DNS lookup on the email? Is this page any help?
AOL, Hotmail, Yahoo, and some other ISPs perform a HELO lookup when receiving messages. If the lookup is not successful, they simply reject to deliver the message to the recipient without sending any error message. There are three possible ways to solve this problem.
1. You can select the "Resolved Internet IP" option in the HELO handshaking settings in the Settings/Advanced screen. The program will perform a DNS query to find out which address points to your IP. This option sometimes does not return the correct values if you are behind a router. If that is the case, you can use the http://network-tools.com/ service to check your IP address and look for "Host name" which should then be copied into the "Use this Identification" box in HELO handshaking settings.
2. Try to change the server identity in the HELO handshaking settings in the Settings/Advanced screen to the "mail.domain.com" format. For example, if your ISP provides e-mail address such as email@example.com, set the HELO handshaking identification to mail.domain.com. Try also with only 'domain.com' format.
3. If you have a domain name that points to your computer's IP address, then enter that domain name in the HELO handshaking settings in PostCast Server. You can use the no-ip.com service to host a domain name on your computer.
05-30-2007, 03:11 PM
If you are sending this from a standard XP box, then it's probably much more sinister than just RevDNS and ISP blocking.
Depending on your ISP, they may be blocking outbound port 25. This is the standard SMTP port (you can change this in IIS). Most companies nowadays use 587 for outbound client mail to their mail servers, and even then they don't always relay.
Not all mail services use RevDNS, as it is an expensive operation. If they can't check your RevDNS, it usually just gets sent to your Junk Mail. Each ISP is a little different, some delete, some bounce, some Junk Mail, etc.
Even more sinister, it is a sure bet that companies are using blacklists, especially if you are on an ISP's DCHP. Comcast, especially. Comcast is known for its lack of enforcing SMTP rules and spam filtering, so almost all of its DHCP address blocks are on blacklists. You can use Spudhead's examples above, but it won't help any if your IP is on a blacklist, whether you put it there or not. Trying to remove a DHCP address from a blacklist is like pulling teeth with a mousefart and a fishing line -- it's a long, painful, and unproductive process. Besides, IF you get the IP removed and someone else is spamming in the same address space -- guess what?? You are back on the list.
Ways to fix this --
1) Request a static IP from your ISP. These typically are not on blacklists and you can easily get them removed if they are.
2) Set up a true mail server, not just your own workstation. If you set up a mail server, then all of the configuration options above with HELO and EHLO will be set for you.
3) Don't use CDO. There are a lot of 3rd party FREE mail systems out there. They will allow you to setup and configure their options much better than XP's IIS SMTP service. Try Win2k3 has IIS 6, in which the SMTP service has more configurable options than XP's IIS 5.1, and it's a lot more secure.
05-30-2007, 08:25 PM
More likely the target SMTP server does not allow emails sent from ANY dynamic IP (rather than just those known to spam in the past). For example AOL, walla.co.il and bellsouth all block emails sent from a dynamic IP address in an attempt to reduce spam.
This only applies if your CDO is sending from your SMTP server, if you log in and send from your ISP's SMTP server (SMTP is pretty much based around the idea that everyone sends from their ISP's SMTP server, which is just rubbish) or a public SMTP server to which you have access, this wouldn't be the problem (but you said you were sending from your box, so it probably is).
Your ISP is not blocking port 25, or you wouldnt be able to send to anyone.
Using an alternative to CDO would make no difference, it is still originating from an SMTP agent in the dynamic IP range. Changing your SMTP settings would also not make a difference for the same reason.
Your best bet is to use your ISP's SMTP server (if you still have your account details) or a mail server on an alternate address (for example gmail if you have a gmail account, though i think gmail now filters messages with non gmail from addresses going through their servers, there are a lot of other ones that don't)
05-31-2007, 02:16 AM
I appreciate all of your responses. They all give me insight.
Ghell is correct that it is obvious that port 25 is not blocked, as I am receiving mail on one remote network account.
The machine I have been referring to is my home box, which I am using to build a web application. Once finished, I will be moving the app to my production web server at the office, which is static. Hopefully these problems will no exist there.
05-31-2007, 07:06 PM
It would be best to test using an existing server (if your production server already has SMTP set up, it may be possible to get it to use it now) before you deploy the application.