Leo, I am a Charter Cable customer and as a result, I have a charter.net
email address. I travel every week, and when I am away from home, Charter’s
email will not let me SEND email when I use Outlook. I can receive email all
day long using Outlook when I’m off the Charter ISP, I just can’t send any
email. Now, using my iPad, it works just fine! But using my laptop? It’s a
no-go! I have questioned Charter about this several times and each time, I get a
“canned” response from them and they want me to jump through hoops. They know doggone good and well that it isn’t going to work, regardless of what I do. I
have a sneaky suspicion that it has something to do with their nasty, ugly,
user-unfriendly web-based email system! I downloaded Thunderbird after reading
your newsletter, but that didn’t work either. Have you got any idea of a setting
or something of that nature that I can adjust/change that might make my Outlook
work with my Charter email address when I am away from my home base?
First, don’t blame Charter.
Well, blame them for not being able to help you perhaps, but don’t blame
them for the situation. It actually has a perfectly logical explanation.
Instead, blame spammers.
I’ll look at the common solution and then explain a little about why this
When your email program sends email, it need to be “authenticated” with your ISP somehow first.
Unfortunately, the specific settings that you need will vary from ISP to ISP, and that means that you’ll need to go to your ISP for the information. Normally, these settings are described in a knowledgebase article or FAQ, because this really is a frequently asked question of any ISP.
There are two common ways that ISPs have you configure your email program for authenticated sending:
Receive before send – When your email program receives or downloads email, it must first login as you to tell the server exactly whose email is being requested. “Receive before send” tells the email program to check for new email before sending. The email server can then say, “Oh, you just checked for email, so it must still be you. I know who you are; go ahead and send.”
Authenticate to send – The connections that your email program uses to send and to receive are two completely separate things. As a result, the server may not be able to associate the receive that your email program just did with the send that it’s about to. “Authenticate to send” causes the email program to sign in first before sending email, just like it does when receiving. That proves that you’re a customer of the ISP, and the mail server then lets you send.
These settings are typically buried in the account configuration in your email program. In Outlook 2010, for example, click File, Account Settings…, click the email account in question, and click Change…. In the resulting dialog, click More Settings… and then the Outgoing Server tab. Other email programs will have this setting in different configuration-related places.
As I said, which of those two options that you need will depend on your ISP, but they are both designed specifically to allow ISP customers to send email using their ISP’s servers from anywhere.
One other possible issue
Why can’t I send mail from my hotel room? talks about this in more detail, but the bottom line is that if your ISP allows you to use a port other than port 25 to send email, use it. You can use it regardless of where you are, whether you’re at home or on the road.
While you’re at it, look for the options to use SSL or TLS to encrypt your outgoing email and use those if you can. When encryption is not used, anyone with access to the network may be able to sniff network traffic and read the email that you’re sending. (You might also consider the equivalent SSL setting for your POP3 settings, used to receive email.)
It’s all about trust … and spam
First, realize that anyone can connect up to your ISP to try to send email.
And, of course, that includes spammers.
When someone tries to send mail to (or through) your ISP, it has three things that it can check:
The send attempt is via an ISP-provided connection. For example, your ISP provides the connection to your home, so they know that it’s you or someone at your home sending email.
The send attempt is trying to send to a customer of the ISP. In that case, the ISP accepts the email regardless of where it comes from so that it can be delivered to that customer.
The send attempt is made by an authenticated ISP customer. As we saw above, authentication allows the ISP to know who’s sending.
The scenario that’s left out is this one:
The send attempt is not via a connection provided by the ISP, not by an authenticated ISP customer, and not destined for a customer of the ISP.
In other words, the email looks like it’s “just passing through”, having nothing at all to do with any ISP’s customer.
Left unchecked, this is one way that spam propagates. There’s no one in that path that the ISP can trust – sender or recipient.
By configuring your email program to authenticate first in some fashion, as described above, the ISP knows that it’s you and thus, they can trust that you’re not a spammer (or they can yank your account if you are).
One last possible glitch
Most email service providers like your ISP support this ability to authenticate in some fashion before sending.
It’s sometimes the case that they might not.
In a case like this, I’d be tempted to find another email provider for everything. More practically, you can send using a different service than the one that you receive on. Gmail is often good for this if you have a Google account. It’s easy in concept (just configure the SMTP settings for the other service), but sometimes there may be ramifications; it’s easy to get the “From:” address wrong on the email that you send and your Sent mail may not be saved as it was when sending through your ISP directly.
Whenever possible, it’s still probably a good idea to send using the services provided with your email account.