Is there a package that acts as an SMTP relay server to use for sending mail from another machine to the OpenWRT router to then be delivered to a smarthost? Apparently most of these are only for sending localhost mail which is useless for me.
Run postfix on hardware designed for constant disk activity (flash is not) and sufficient RAM. Port-forward smtp and submission to it.
The security risks alone of running a mail server should be reason enough not to run it on your perimeter firewall.
4 Likes
I agree with @jeff, Postfix can be ran as a relay; but I don't suggest on your router. Fruther, if you have a residential-block IP address from your ISP, the mail will likely be rejected by most well known and established email companies. It's also possible your ISP simply blocks it.
You can run Netalyzr to verify your ability to send mail on port 25/tcp.
2 Likes
I can't figure out how to enable SSL auth on postfix which is what I'm using currently not on the router.
I just need something simple to relay IoT and PHP notifications to my host Yandex which has some pretty strict requirements for sent mail compared to Comcast.
Yes my ISP blocks 25 so I'm not concerned about external spam.
No, emails don't get marked as spam as long as you are using your own email domain and configure the DNS records correctly.
Comcast here blocks 25 entirely (src/dst) so sending mail is blocked as well, or probably as the primary intent.
I run a closed “smart hub” on a server at DigitalOcean as a result. I can help you with the Postfix config, but you’ll need to determine if you can connect to port 25, or you won’t be able to send mail to outside destinations directly from your local hosts.
3 Likes
You're not concerned about actually sending email once you setup your server, either.
This is the port used to transmit email. You'll need a new ISP, or an upgrade to a business account.
Also, your reasoning for why email is flagged as spam is quite lacking. Lastly, I never mentioned spam. I said they would reject the emails from residential IPs.
2 Likes
This comes late, but the package https://openwrt.org/packages/pkgdata/emailrelay may do you want.
Here is the manual: http://emailrelay.sourceforge.net/
4 Likes
I think what the original poster wanted is SSH local port forwarding to using SSH encrypt plain text email into SSL email, so that it can be send through whatever email server, as long as it has account on that server.
SSH local port forwarding can be done on regular Linux computer, but not sure if OpenWRT support that?
That might be a job for stunnel. Openwrt has a package for stunnel, but I have never succeeded in configuring it.
You are right. I was able to create a stunnel on regular Linux box. But could not find how to do this on router.
I created a wiki page for the E-Mail Relay:
Please check
I don't suppose you are the package maintainer for EmailRelay?
I have a very small setup at home where I have some email alerting setup for various applications/hardware, I have a SendInBlue account that I just use to forward off as a SmartHost configuration on hMailServer on a Windows VM. Only problem is when this VM is powered down, I get no emails.
So I was looking at what I could do with my OpenWRT setup and came across EmailRelay and I am really impressed. Have configured this as a proxy with the SmartHost configuration using the sample configuration and followed your guide.
The only issue is, email delivery is very hit and miss, and the issue is consistent across my applications/hardware that I have pointed at my router for SMTP. OpenWRT Syslog generally shows:
Fri Dec 8 09:15:31 2023 mail.info [9664]: emailrelay: info: smtp connection from 192.168.0.51:56636
Fri Dec 8 09:15:31 2023 mail.info [9664]: emailrelay: info: smtp connection closed: smtp protocol done: 192.168.0.51:56636
Fri Dec 8 09:15:31 2023 mail.info [9664]: emailrelay: info: smtp connection to 185.107.232.248:587
Fri Dec 8 09:15:32 2023 mail.warn [9664]: emailrelay: warning: client protocol: unexpected response [5.5.4 Missing opening angle bracket]
Fri Dec 8 09:15:32 2023 mail.info [9664]: emailrelay: info: failing file: "emailrelay.9664.1702026931.22.envelope.busy" -> "emailrelay.9664.1702026931.22.envelope.bad"
Fri Dec 8 09:15:32 2023 mail.err [9664]: emailrelay: error: forwarding: smtp error: unexpected response: 5.5.4 Missing opening angle bracket
envelope.bad files look like this:
X-MailRelay-Format: #2821.6
X-MailRelay-Content: 7bit
X-MailRelay-From: xxx@xxx.co.uk
X-MailRelay-ToCount: 1
X-MailRelay-To-Remote: xxx@xxx.co.uk
X-MailRelay-Authentication:
X-MailRelay-Client: 192.168.0.51
X-MailRelay-ClientCertificate:
X-MailRelay-MailFromAuthIn:
X-MailRelay-MailFromAuthOut:
X-MailRelay-ForwardTo:
X-MailRelay-ForwardToAddress:
X-MailRelay-End: 1
X-MailRelay-Reason: smtp error: unexpected response: 5.5.4 Missing opening angle bracket
X-MailRelay-ReasonCode:
I did a bit of digging and looks like a few people have encountered this over the years. Graham Walker mentioned about rebuilding the source with a patch (https://sourceforge.net/p/emailrelay/bugs/_discuss/thread/170eadde/af8a/attachment/patch.p1).
Are you able to help?
Per the Wiki - no. See "Maintainer" at link already posted:
I'm not a maintainer but Federico Di Marco https://github.com/fededim
But he seems not interested in this because my PR is still waiting for his review.
Maybe as workaround you can try to change email from the xxx@xxx.co.uk to Adam <xxx@xxx.co.uk>. Or maybe just <xxx@xxx.co.uk> will work.
The patch that you mentioned is dated from 2021 so it should be already applied.
Interestingly that in the latest version there is some similar issue https://sourceforge.net/p/emailrelay/support-requests/89/ but don't be confused because the OpenWrt feed has an older versions up to v2.4.1
Which version are you using? You can check with opkg info emailrelay
A very long time ago the OP stated:
A different view on the subject:
You don't really need a relay, a mail client will do just fine to send anything you like to a known email address.
On Openwrt I used the msmtp package for quite a while. It has numerous options including the msmtp-mta version that can emulate sendmail.
3 Likes
@stokito, thanks for your helpful response, the version that is installed is: emailrelay_2.4.1-1_mips_24kc.ipk
The impression I got from the original link where the issue had been mentioned was that Graham (I am guessing he is the original developer) basically said the clients in question were not following RFC guidance for SMTP & wasn't massively interested in fixing this.
I will try the workarounds, I did try just the xxx@xxx.co.uk but it didn't work either.
Did you configure your network, server, hostnames, etc. to comply with this?
Most email providers and ISPs will not receive an email from a server that isn't.
Additionally, some ISPs block outbound 25/tcp for customers - unless it's purchased as a business account, etc.
For example (in laymans terms):
The hostname/IP given you perform the following commands usually must match:
nslookup xxx.xxx.xxx.xxx
Where xxx.xxx.xxx.xxx == the IP address
Result: yourmailrealyserver.example.com
nslookup yourmailrealyserver.example.com
Result: xxx.xxx.xxx.xxx
- The former - controlled by your ISP
- The latter - controlled by you
The IP must not be in a known ISP DHCP pool, Public NAT Pool, unassigned, etc.
This is also controlled by your ISP, the account you have, Global SPAM mitigation databases, etc.
See the current Best Practice on the subject: https://datatracker.ietf.org/doc/html/rfc2505 - "RFC 2505: Anti-Spam Recommendations for SMTP MTAs"
From (Best Current Practice No. 30) BCP 30:
A brief summary of this memo is:
o Stop unauthorized mail relaying.
o Spammers then have to operate in the open; deal with them.
o Design a mail system that can handle spam.
If your ISP as implemented this, you cannot send mail without their approval.
Lastly:
See: https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#—_5yz_Permanent_negative_completion
504 5.5.4 Unrecognized authentication type
See: https://datatracker.ietf.org/doc/html/rfc4954
I checked that current best practice for this as well (https://datatracker.ietf.org/doc/html/rfc5248). Table 1 in Section 2.4 of BCP 138 - " A Registry for SMTP Enhanced Mail System Status Codes", matches your error code.
Permanent failure means "do not repeat the same process".
Google lists their 5.5.4 error code under a different Basic Status Code. Interestingly enough, they do have a matching Basic Status code - 504 "Unrecognized Authentication Type."
For 5.5.4, their support recommendation seems to imply that the sender may be an unauthorized relay.
One thing that could cause this is an improperly configured relay missing the necessary BCP 30 configurations, blank configs, etc.
Another simpler question:
In the example FROM email - are you the owner of this domain; or are you configuring your relay to send SMTP to this email provider/ISP?
Everything is configured and in place correctly on my network and records on public DNS in order for me to use an external SMTP provider to relay email from my environment.
I've used HmailServer without fail for years in the same manner, but obviously if the Windows VM running it is offline then I cant relay out.
Which is why I looked at EmailRelay and running it on OpenWRT. We're only talking of really small amounts of emails a day, maybe 5 or 10, nothing intensive at all, no attachments, just text.
Thats interesting regarding the 5.5.4 error though, it does work though but I'd say only 50% of the time. So perhaps authentication isn't working each time and EmailRelay is showing the wrong error text or something.
1 Like
Just an update on this, EmailRelay was just far too temperamental with such mixed results on delivery.
Therefore I installed & configured postfix as a relay & so far this has worked absolutley perfectly.
3 Likes