I have a small app on my centos6.6 server i am running that allows the user to send an email on a custom port and I am allowing any port to be used. Is there any security risk for allowing this app to use any outgoing port on my serve to do an smtp transaction?
SnapOverflow
Yes, there is. Depending on how much control you're giving the user over the content, it could range from "user can do mischief" to "you're a total open relay".
As an example more at the "mischief" end of the spectrum, Redis has a fairly "permissive" command parser. It will ignore any commands it doesn't recognise, and then wait for a command it does. That means that if the user sends an e-mail containing the string "flushall" at the beginning of a line, and sends that e-mail to an open Redis server on the Internet (yes, people leave their Redis servers open to the Internet, however silly that may sound) all of the data in that Redis server will be deleted.
Of course, the miscreant doesn't have to use your service to do that -- they can send the commands directly -- but by relaying through your service, it's a nice way to mask the true source of their shenanigans. The problem can get much uglier if your machine has network access to anything not on the public Internet -- say, internal servers behind a firewall, or over a VPN (including roadwarrior VPNs from your laptop). In that case, with a bit of guesswork, they can possibly do recon or an actual attack against your private infrastructure.
The more control over the e-mail you provide, the more likely this is. So, if you allow users to set headers, or even worse, control the SMTP conversation itself, the chances of someone working out a way of using your service to do Bad Things goes waaaaaaaay up.
My apologies, but I think @wombies answer is wrong.
The more logical answer (to what was probably meant) is this -
You can allow SMTP communication on (almost) any port - the security does not come from the port, rather it comes from the access controls in the mail server to ensure only authenticated users can log in (be it by username/password or IP address)
The standard ports are generally associated with specific roles though - 25 is generally mail server to mail server (but you can often send as an end user through it) 26 is an unofficial alternative to port 25 because some ISP's block sending mail through port 25 587 is the "correct" port for sending email as an end user - its normally encrypted using SSL. 465 is typically used for sending "TLS" encrypted email.
I've never heard of 2525, but its probably equivalent to 26, with the added advantage of the port number being > 1024, so it has less privileges under Linux.
You should steer away from commonly known ports - for example 80, 3128, 8080, 443, - these are often behind proxies so will not speak the mail protocol and be blocked - and this is a good reason to stick with port 587 - which is considered standard.
The correct answer is probably answering the question the sender did intend to ask, which is "Its OK to send from any port above 1024 TCP, as this emulates standard behaviour - provided the destination port is correct [ ie port 25 if destined for the wider Internet ]. That said, unless you are writing your own stack or mail server, this is unlikely to be relevant.