I am building an application that will be acting as a combined MUA/MTA on different networks. However, many of the networks are with ISP's that block port 25 for SMTP. Therefore I would also like to open up a secondary port so that some of the installs can communicate on that if port 25 is closed.
How do I choose a second port? I know some people use port 26 or port 2525. What is the correct way to choose a port that won't interfere with existing software?
Your question is not 100% clear to me. Are you looking to have incoming port 25 connections, or are you connecting 25 outbound? I will split the answer into two to cover both bases.
If by "installs communicate on port 25", you mean that the software installation tries to contact other servers using port 25, that is a bad idea. Do not ship software that calls out on port 25.
The only outbound port your software can rely on for "phoning home" or contacting other servers is port 80. And not only the port, but the protocol has to be HTTP. Some firewalls allow port 80, but they also inspect the protocol and block it if it is not HTTP. You can also rely on 443, HTTPS. Still, I would provide an alternative installation/registration workflow which works if there is no port 80 connection.
ISP's block outgoing 25 because it's used by spammers to directly contact mail servers from subscriber lines and deliver spam.
That being said, of course you can ship software that sends mail, and that uses port 25. However, that mail should go to an SMTP server which is configured by the user. (Quite often, a relay provided by their ISP, which may require authentication.)
An application that is going to act as a mail server for a domain will generally not be deployable by users who cannot have incoming port 25 open.
Those people will need a workaround, ranging from changing their subscription, changing to another ISP, or using some machine in some other network as a port-forwarding proxy which forwards port 25 connections to the real server, using some port that is open.
The choice of alternate port is best left as a configuration to be determined by the users.
There is no universal port number that is guaranteed to be open, regardless of ISP.
But the bigger problem is that all the mail software out there will expect to connect to port 25. The mail exchange (MX) DNS record does not include a port number; it resolves to a host.
The MX host is expected to listen on port 25.
If you're just sending email on behalf of an end-user, who originates the email within your application, use authenticated SMTP to port 587.
You can send mail to some servers via the SMTPS port 465, if the remote MTA is SSL/TLS-enabled and listening on that port, but don't count on it.
Otherwise, advise the user that they need a business-class ISP.
Today I released a feature on ForwardEmail.net to allow custom port forwarding for emails. This solution may work for you. We've documented it along with a guide/how-to at our page on Port 25 blocked by ISP workaround.
If you're unfamiliar with ForwardEmail.net:
ForwardEmail is a free, secure, and open-source email forwarding service, which allows the use of custom domains and disposable addresses. It also has a strict zero tolerance policy for storing logs of any kind (see the Zero Tolerance Privacy Policy for more information).
You can pick any port you want, as long as you're building a closed private e-mail system and the MTA's all know to use that port to communicate with each other, as long as you stay consistent. If you need this system to communicate to the outside world though, at least one of your MTA's will have to use destination port 25 to relay, or use a trusted relay to get out to the rest of the world.
As long as you pick something in the high port range, and it's something you can remember, this is fine.
For incoming 25, you can use one the many smtp rerouting services, provided because many ISPs block port 25. See this post: http://thenubbyadmin.com/2010/06/14/list-of-inbound-smtp-redirection-services-some-for-free/.
My plug for DNSMadeEasy: Comcast blocked port 25 on me unannounced, killing my mail server. After reviewing the rerouting options, I chose DNS Made Easy. (EasyDNS in Canada, DNSExit raised prices, DYN ridiculously expensive). DNS Made Easy had me back up in under 10 minutes, and that’s with manual MX Record entries. They also responded very promptly to a silly question I had because I was rushed and didn’t hit the little blue “i” info button. They have a essentially infinite 1 GB buffer and my mail server is a lot more robust to downtime now that I'm using this rerouting service.
For outgoing port 25, you'll need to specify a smtp gateway anyway, especially if the IP is listed in spamhaus's PBL list -- even if your mail makes it out, it will almost certainly be blacklisted by most remote mail servers.
I agree with Michael Hampton but since your comments talk about the MTA as well:
-Make your MUA program allow for configuration by the end client/user to put in whatever their correct outbound MTA is with their ISP.
Then the MUA will send email out their residential ISP since it will allow it coming from its own network.
EDIT: course you said your app is a combined MUA/MTA. That won't work for MTA functionality unless you then had the "thousands" of deployed apps then send all the email to another centralized MTA (via whatever port) and then that MTA relays email outbound to wherever over port 25.
