Forward emails to remote SMTP server
-
@binary1zero interesting scenario
Not sure I understand benefits of this approach, because if it is "just" a question of addressing storage of old emails, my instinct is to think about solutions like :- MailPiler (custom package available for Cloudron)
- MailSteward (proprietary paid but affordable and solid local archiving solution)
- imapfilter (https://github.com/lefcha/imapfilter) to suck out emails and move them to storage location
- offlineimap (http://www.offlineimap.org/ and https://www.dermitch.de/post/imap-backup-with-offlineimap/)
- various "server-suck-file-save" scripts
Maybe I am missing something in your plan but these could be simpler to implement.
EDIT : could a sieve filter work to forward all incoming email to another server ? Then just delete/purge periodically on initial receiving server after a time period.
@timconsidine said in Forward emails to remote SMTP server:
EDIT : could a sieve filter work to forward all incoming email to another server ? Then just delete/purge periodically on initial receiving server after a time period.
I've looked into this but it doesn't seems to be an option. Sieve filter can only redirect to another "email" rather than a mail server. In this case - both emails would be same as we are just forwarding it to a remote mailbox.
-
Another question is that can I even use Cloudron as a "relay server" from downstream server ? I wasn't able to find any option to whitelist IP or any other way apart from authenticating users at cloudron for outbound emails.
-
Previous discussion on the topic:
-
Previous discussion on the topic:
@infogulch Thank you that was insightful.
Outbound is answered via that post.
For inbound, here's what I'm thinking now :
- Setup private wireguard connection between DO and my home server
- Turn off Inbound email on DO Cloudron.
- Redirect inbound ports like TCP/25 via iptables on DO to home server via wireguard
-
@infogulch Thank you that was insightful.
Outbound is answered via that post.
For inbound, here's what I'm thinking now :
- Setup private wireguard connection between DO and my home server
- Turn off Inbound email on DO Cloudron.
- Redirect inbound ports like TCP/25 via iptables on DO to home server via wireguard
@binary1zero From the constraints you mentioned, I do not understand why you don't simply use the home server as a main email server, but with an external relay for outgoing email (assuming your ISP does not block inbound 25).
From what I know, PTR and stuff is only necessary for outbound relay, as it mostly affects server reputation when other server decide incoming email is spam.
-
@binary1zero From the constraints you mentioned, I do not understand why you don't simply use the home server as a main email server, but with an external relay for outgoing email (assuming your ISP does not block inbound 25).
From what I know, PTR and stuff is only necessary for outbound relay, as it mostly affects server reputation when other server decide incoming email is spam.
@mehdi iirc, one signal used to detect spam is whether the inbound and outbound IPs are the same. Maybe this is not the case, but Google and Microsoft are pretty finicky about email delivery so my instinct is to keep the externally visible configuration 'clean'. That's why I am looking at a design like this.
-
@binary1zero From the constraints you mentioned, I do not understand why you don't simply use the home server as a main email server, but with an external relay for outgoing email (assuming your ISP does not block inbound 25).
From what I know, PTR and stuff is only necessary for outbound relay, as it mostly affects server reputation when other server decide incoming email is spam.
@mehdi said in Forward emails to remote SMTP server:
From what I know, PTR and stuff is only necessary for outbound relay
that's correct. PTR is for the server that does the mail transfer, so it won't be needed if an external relay is used. On Cloudron, the PTR check is skipped when using a relay.
-
@mehdi iirc, one signal used to detect spam is whether the inbound and outbound IPs are the same. Maybe this is not the case, but Google and Microsoft are pretty finicky about email delivery so my instinct is to keep the externally visible configuration 'clean'. That's why I am looking at a design like this.
@infogulch inbound/outbound IP match is not needed. The reputation of outbound IP is very important though.
If @binary1zero is using some business IP from their ISP, one can just host the mail server from home/office instead of all this forwarding.
-
@infogulch inbound/outbound IP match is not needed. The reputation of outbound IP is very important though.
If @binary1zero is using some business IP from their ISP, one can just host the mail server from home/office instead of all this forwarding.
@girish So I tried direct MX to my home and got errors:
[Default] 451-'4.7.1 Greylisting in action, please come back later' (delivery attempts: 5)>'So back to my original problem now - I'm thinking of either putting procmail on Synology and fetch emails or either use iptables/VPN route to send email home.
