Let’s make it brief. I have a NAS with mail server on it and a VPS, but I cannot send mail directly because the IP of the NAS is defaulty rejected by all, any mail sent will be returned.
But the IP of my VPS is generally accepted. I wish to use my VPS as a relay, while configuring the NAS to send mail through the VPS.
So far, I don’t know if there’s any option other than Microsoft IIS. Is there even an available option for Linux servers? Please let me know if you have any idea, thanks in advance!
Here is Solutions:
We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.
"SMTP relays" are more commonly known as just "SMTP servers", as SMTP-based email has always been store-and-forward in the first place. Even your NAS is already an SMTP relay that accepts messages from mail apps over the ‘SMTP Submit’ port 587 (or 465), then relays it to the recipient’s server over ‘SMTP MX’ (the usual port 25).1
There are quite a few SMTP servers for Linux available, which run a large part of the world’s email infrastructure, and which support relaying as a baseline feature. (Some common examples are Postfix, Exim4, OpenSMTPD, as well as the nearly-historical Sendmail and Qmail. Your NAS likely uses one of those.)
For the VPS, you can go through typical "personal mail server" tutorials, specifically the part that describes how to set up user accounts. As it’s just a relay, you can ignore the parts that talk about Maildirs or POP3/IMAP or SQL, but you do want to set up user authentication for SMTP no matter what; basically the NAS should have its own username and password, and the VPS must only allow "trusted" clients to send messages to arbitrary destinations.
Though if your NAS has a static IP address (and if configuring a password is not an option), all mail servers also support marking certain sender IP addresses as "trusted". Such configuration can also be simpler, though also less secure.
Make sure to test that the VPS requires authentication – "open relays" will get discovered and abused for spam within hours if not minutes of starting them, end up in DNSBLs within days, and possibly be shut down by your hosting company within weeks.
1 Another common example is SMTP relaying between two servers for the same domain, as a way to implement "backup MX" servers – if the highest-priority MX host is unavailable, the secondary MX would accept the message and just put it directly in the outbound queue again (to be delivered to MXs with higher priority than itself). This too is a built-in part of SMTP servers. Though in this case, the mail is inbound so the sender is always "anonymous", and the relay instead only accepts messages for known recipient domains, so it’s a slightly different situation from yours.
Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂