Many ISP's is block port 25, how do I choose an alternative port?
Solution 1:
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.
Outbound 25
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.)
Inbound 25
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.
Solution 2:
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.