Tag Archives: SMTP Tips

SMTP Authentication–I Can Only Send Email to My Domain

image

One of the most common problems experienced by users of hosted email services is that they find they can only send email messages to their own domain.

For Example, if you have two hosted email addresses:

  1. ted@mybusiness.com
  2. john@mybusiness.com

You find that you can successfully send an email message from one user to another, but when you try to send to any other domain:

  1. anything@hotmail.com

You find that the email messages do not send.

Solution

You need to enable “Authentication” in your configured email account settings. There are many client email programs, probably the most common is Outlook.

When you configure an new POP3 email account you normally end up with something that looks like this:

image

If you click on More Settings / Outgoing Server

image

and just tick the option to use the same settings as the incoming mail server.

image

This is all that is needed to enable outbound SMTP authentication.

Background

SMTP Servers (or email servers) are setup to need stop people using them for sending email messages. As strange as that sounds, if they were not setup this way, then anyone could SPAM the world using that email server.

To prevent users from abusing an Open Relay Mail Server, the administrators say that anyone wanting to send email messages from that server to any other server, will need a users name and pass. Almost always this is the same user and pass as the one needed to download your mail from that server.

This this need for user and pass is referred to as “Authentication” and is necessary on almost all servers, other than internet service providers who give you an internet connection. In that instance they authenticate you from your internet connection.

Why Can You Send to Your Own Domain?

Because Email Servers by nature will received email messages to addresses they host. This is part of the process necessary for email messages to be sent and received.

Removing IP from AOL email Black List postmaster

I’m finding the AOL process really really annoying. We have been trying to clear up blacklist and reputation problems with a new IP range that was previously abused.

AOL have some tools that pretend to help. What you need to know is this.

1. Ensure your mail server IP has a RDNS – so when you do an NS lookup on the IP address it will show a name, like smtp.interactivewebs.com

2. Setup an email account like abuse@ or postmaster@  that domain. Make sure you get that mail.

3. Ensure that you verify with AOL that you are the admin for that RDNS lookup name. That is by submitting a ticket called Feedback Loop here: http://postmaster.aol.com/SupportRequest.FBL.php

4. Wait till they verify your Feedback Loop. AKA. that you are getting mail on that domain.

6. Use this link: http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3aaol.com
to work out the IP of an AOL mail server.

7. Work out what code error is given when you try to connect from your mail server using Telnet. Follow these instructions. http://support.microsoft.com/kb/153119 but use the IP address and port 25 of the AOL mail server from step 6 above.

8. Look at the error result and compare it to this page: http://postmaster.aol.com/Postmaster.Errors.php

9. Follow the support request process from that page, to submit a ticket to have them fix things up.

Easy as that.!


Imagine if we had to do that crap for every email domain in the world. This was a recent blog from AOL about their update:

http://postmaster-blog.aol.com/2011/05/05/general-update/

We are in the process of automating email problem report resolution. This is a mid-term project, and is being implemented in stages on a queue-by-queue basis. (Ex: Each unique error code type represents a different queue, as do feedback loop and whitelist requests. http://postmaster.aol.com/Postmaster.Errors.php )
The last couple of months were spent migrating our sundry ticketing systems onto one common platform — essentially readying a back-end for the front-end logic flow that you will interface with. We are excited to finally be addressing the part of this project that will offer, in most cases, immediate resolution to your issues.
We are starting with router-level queues, the first of which will be RTR:BB errors. I will post on our progress as we push the code into production, along with what ticket submitters should expect with the automated process specific to the queue addressed. If you are seeing problems with the queues in transition, please comment on that particular blog post, and we’ll take a look.
Meanwhile, our Postmaster staff will continue handling every ticket we receive.
Thanks for your patience and support during this transition!

 


This was my comment.

1. Good that you are improving things. Sucks that your process is so stupid in the first place. An example of how frigging annoying I am finding things.
We at: http://www.interactivewebs.com have been forced by a chapter 11 of an upstream provider to move all our servers to a new IP range.
First thing we did was to setup RDNS and check mail reputation (on all the major Black Lists, and senderbase.org). What we found was that the IP range has been abused. So we set about cleaning that up.
Naturally we checked AOL, and found that the IP was "undisclosed" reputation. Helpful Right… NOT!
But it does not show AOL was listing it.
So we move and fire up services. THEN and only then do we find out that AOL does have the address on a BL and mail cannot be delivered.
How about tools that work, and a process that works to allow proper checking/de-listing.
The ironic part of dealing with your 1990 process, is that it really does not work as well as other systems. AOL users get more spam than many other reputable spam systems. There is even free spam software services that do better.
So why stick with such a lame process, when the end result is HEAPS of false positives?