SMTP on another port?

[brianh1970]

Is it possible to change or include another port for SMTP services? I just changed ISPs and they block all outbound traffic on port 25. For now I'll use the ISP's server, but I'd rather have my email go through my domain's server.

[jason]

This a common problem for a lot of people here, and the easiest thing to do is use your ISP's server. It doesn't really matter, though, it won't effect how your mail looks to the reciepient.

The one thing you could try is to set up an SSH tunnel to the SMTP server. I haven't tried it for SMTP, but I've set up tunnels for other services (using Putty), and it has worked well, but it can be a pain in the...

--Jason

[Ron]

I also would like to be able to use the SMTP server on other than port 25.

In addition to some ISPs that block access to port 25 (Earthlink, Juno for instance) AOL does not allow the use of Outlook to access their SMTP services. Therefore, I cannot give a POP account to AOL customers.

What AOL was doing to me was they were SILENTLY INTERCEPTING port 25 email, putting the outgoing email into a log, running a log sniffer and sending the email out from AOL. The funny thing is, they only do this IF you get authenticated from your own SMTP server!!! So they pass through the authentication process, but then snatch the email!

To make matters ever sillier, they would not deliver the email to internal AOL addresses, but they WOULD devliver to external addresses. However, the deliveries took anywhere from 45 minutes to 9 hours.

Go figure.

As far as using your ISP's SMTP server, sure, that works. But the headers will show that the mail was sent from a dialup connection. Doesn't SpamAssassain flag that with some points?

One solution might be the availability of SMTP on other than port 25... is there ANY possibility that another port could be added and redirected to the SMTP services?

Thanks in Advance.

[jason]

You can always use SSH tunneling to access SMTP (or any other service) over a firewalled connection. Most SSH programs, including PuTTY allow SSH Tunnelling (sometimes called Port Forwarding), although it is sometimes kind of clunky to do.

Basically what happens is you tell your SSH program to listen to a port on your computer and then encrypt and send all data sent to that port on to a remote computer. All data is sent to port 22 (SSH) on the remote computer, so if your ISP is blocking port 25 traffic it will still go through.

As I said, using tunneling is often clunky. For instance, with PuTTY you have to have (as far as I've been able to figure out) an open an SSH session in order for the port forwarding to work. I just found a shareware program called Han-soft Internet Secure Tunneling (http://www.han-soft.com/) that allows tunneling in a much cleaner way. It is built on top of PuTTY, much like WinSCP is, and gives you a Wizard-like interface for setting up tunnels. It lives in the system tray and can set up all of your tunnels automatically on startup without user intervention. I've only been playing with it for a few minutes, but so far I like it.

To set up a tunnel (no matter what program you use):
1. You must have SSH access to your server. Contact support if you need it enabled.
2. Pick a local port to use as the listening port (it will be called local port in most SSH programs). If you are going to be tunneling port 25 traffic, you might want to use something like 2525, but the number is arbitrary.
3. Set up your SSH software to establish the tunnel: local port is the one you picked above. Server is your domain name, and remote port is the one you want to connect to on the server (25 for SMTP, for example).
4. Make the SSH connection.
5. Set up your software to connect to 'localhost' on the port you chose in step 2 instead of connecting to the remote server. For example, in your mail app you'd want to use 'localhost' as your SMTP server and '2525' as the port if you've been following these steps.

Once you do this you have the benefit of using services on JPC that are being blocked by your ISP. You also have the added benefit of having everything you send to those services encrypted during transit.

--Jason

[Ron]

Thanks for the reply...looks fscinating to try as soon as I have some spare time...

I haven't had a chance to try this yet, but one question strikes me: If I tell Outlook to use localhost, port 2525, how will it authenticate with Jag's SMTP server? I guess that username and password stay the same.... and I do like the fact that username/password would not be sent in the open.... hmmmmm I'll give it a whirl.

That said, doesn't this seem more difficult to accomplish rather than ask Jag to forward a port, say 2525, to port 25 (If it's possible)?

Doing that wouldn't be any less secure than having 25 open to the public, save for the fact that some ISPs are blocking port 25... would it?

Is there are precedent that they are trying to avoid setting here? Is it extremely difficult to do? It's clearly an issue that keeps going around, I've found many references to it in the forum, and I'm sure a whole boaload of tickets have been opened for it. If in the FAQs they told people to try setting to port, say, 2525, if they are having trouble, it might save some there, wouldn't it?

Just thinking aloud.

[jason]

I don't know if JPC would or could do something like that, but I suspect they probably could. I've never asked to have anything like that done, so I don't know if its something they'd be willing to do.

As for with outlook, when you connect to localhost, the SSH tunnel that is listening on the port you specified does nothing except send the data, bit for bit, back and forth between port 25 on the server and the port you've opened on your machine. When the connection is attempted, the tunnel sends your connection request on to the server and the server responds (basically) by asking for authentication. So you authenticate the same way as connecting through Outlook to the server directly. The only thing that changes is the host and port that you set in OUtlook.

--Jason

[jimg]

Jason,

I've seen mail services (mailshell.com & mailblocks.com) support ports other than 25 for SMTP services (port 2525 & 25025 seems to be common).

While the putty / han-soft / tunneling approach is an option (i've gotten it to work), it is an option only for the primary accountholder user, since SSH functionality is (currently) limited to only that user.

Unless you feel comfortable giving out your primary account username / password to email users, it's really not an option.

I have a support ticket opened asking for either support for more SSH clients under a single account, or the opening of another port for SMTP inbound. I'd suggest that if more people want this, speak up to Jag.

Peace.

[Connie]

I think you are beating your head against a wall so to speak. There have
numerous request that Jag change Port 25 to something else. To date
nothing has been done. I may be wrong but I think these request are
falling of deaf ears.

[JPC-Masood]

Hello everyone,

Sorry for being late to jump in here. Can you guys check smtps port 465, i.e. try the ssl smtp connection. Most modern email client software should be able to support it.

For example in MS Outlook, change the outgoing port number from 25 to 465 and select the checkbox "This server requires an encrypted SSL connection (SSL)"

It may bring the ssl cert warning since it uses generic ssl certificate.

I hope this works for you.

[Galen]

Thank you, Masood! It worked beautifully. That just made my day.

[JonathanB]

Okay, I tried this as well. First I got the ssl certificate warning message. Then I added the cert to my trusted certificates.

So far so good... now when I try to send a message via the smtps port 465, Eudora still responds with the following error message.

SSL negotiation failed. Certificate bad: Destination host name does not match host name in certificate.

Any suggestions? (Please Vin, no comments about Eudora, I already know what your suggestion will be.)

[G.Bloke]

Ignore Vin ... better for the blood pressure.

This behaviour is actually correct, whatever the email client. Change the SMTP/POP server to machine.nocdirect.com (change to whichever server your account is on). This is because the certificate is for machine.nocdirect.com and not your domain. If you had your own cert installed then it should work with your own domain.

[JonathanB]

Originally posted by G.Bloke
Change the SMTP/POP server to machine.nocdirect.com (change to whichever server your account is on).

Of course! I should have thought of that. Thanks G.bloke, it worked like a charm.

Thanks also to Masood, who suggested this in the first place.

I've got two family members on AOL who have email accounts on my domain and this will solve a lot of problems.

[lookout]

Thanks Masood and G.Bloke!

[Connie]

Yes thanks Masood and G.Bloke! This subject has come up
several times over the past couple of years and there has been
a simple solution all the time.

G Bloke. Have another question. We have our own certificate. It
wont work. Using our certificate the unrecognized name comes up as
unknown machine.nocdirect.com.

Not that it's all that important but thought you might have some
ideas about that.