Personally I rename them to something meaningful and they get merged if there are no other references. PayPal is especially bad for completely meaningless rubbish in the payee field and they tend to be ad-hoc purchases so I don’t fiddle with them much. The category is the most relevant bit for me.
email is one of the only services i just gave up on (after rolling my own exchange for over a decade). its too annoyingly complex, tedious to do correctly for just yourself. its not worth it.
Self hosting email on non-mission critical domain for learning purposes might be okay if your intention is to get into the industry. Self hosting email for others on more production like setting you’re going to find yourself in a world of pain.
All it takes is one missed email (be it not making into their intended recipient’s inbox, or them not receiving an important notice in their inbox) and you’re never going to hear the end of it.
You’d also be liable for content your users send out from your servers — and I don’t mean the spam type, though if you get your IP blacklisted, your provider may want to have a word with you.
I’d strongly advise against going down this path, but if you do, be sure to have ways to legally shield yourself from any sort of potential liabilities.
I do not understand why everyone calling hosting email difficult? IT is like 5 RFC you need to read and implement. Sofware wise you will need mail agent, something for DKIM ( if it not build in in agent), “local delivery agent” ( probably presenting it as IMAP) + mail reader of your choice. Nothing too complex
It’s not complicated until your reputation drops for a multitude of reasons, many not even directly your fault.
Neighboring bad acting IPs, too many automated emails sent out while you were testing, compromised account, or pretty much any number of things means everyone on your domain is hosed. And email is critical.
The complex part isn’t the hosting part. Its the security part, the reputation management part, the uptime part, the troubleshooting delivery part and basically every other aspect other than running postfix+dovecot
Hosting your own email is a bad idea. Hosting OTHER PEOPLE’S email is a REALLY BAD idea. Self-hosting mail on a vanity domain is a good exercise to learn how SMTP, DNS, IMAP and other protocols interact.
If you don’t like Google, Apple, or Microsoft then sign them up with Proton or another hosted provider. You don’t want to be the reason someone lost income because they missed out on a critical email from a client or their job application was blocked because it was sent from a host with poor reputation.
You can selfhost the email server wherever you want. But you’ve to use some external system to deliver the email or you’ll end up in spam because your residential IP is most likely dynamic and already flagged by most email providers.
One way to do it is to get a VPS somewhere and setup Wireguard on it. Then configure your local system to bind to the Wireguard interface and IP so all email send and received using the tunnel. Dovecot doesn’t care what interface it is running on, Postfix has specific options that you can change in master.cf to accommodate the fact that it will be binding to the VPN IP and the real IP is the VPS public IP.
Create a outgoing transport for the email that uses the WG tunnel and is aware of the VPS public IP:
<span style="color:#323232;">out-wg unix - - n - - smtp
</span><span style="color:#323232;"> -o proxy_interfaces=188.xxx.xxx.xxx # the real public IP of the VPS
</span><span style="color:#323232;"> -o smtp_bind_address=10.0.0.2 # the IP that your local server has on the WG interface
</span><span style="color:#323232;"> -o inet_interfaces=10.0.0.2 # same as above
</span><span style="color:#323232;"> -o myhostname=server.example.org # should match the PTR / reverse DNS entry on the VPS IP
</span><span style="color:#323232;"> -o smtp_helo_name=server.example.org # should match the PTR / reverse DNS entry on the VPS IP
</span><span style="color:#323232;"> -o syslog_name=smtp-wg
</span>
Set your VPS firewall to NAT/forward incoming traffic on port 25, 587, 465 and 993 to the local server (wireguard client 10.0.0.2);
Change main.cf to use the transport by adding: default_transport = out-wg.
That’s everything you need to get it going. Use www.mail-tester.com to debug if DKIM and everything else is properly setup at the end.
Usually aluminium or glass. There’s a metallic coating applied to the outside surfaces that stores the data. That layer is very thin though, so most of the material is the substrate.
I think mail forwarders are still a good way to go. It’s hard to predict how Internet providers will react to email running in their networks.
These days I have an ec2 at AWS for my mail server and use SES for outbound mail. I’m thinking of moving “receiving” back into my network with a simple chat forwarding service but keep SES for outbound. They handle all the SPF and DKIM things and ensure their networks aren’t on blacklists.
It’s spam they’re concerned about. Spam email is kinda “big business” and one way they thrive is by using bots to just scan for poorly-configured or vulnerable systems to hack and install an app that will let them send email from your system. By compromising hundreds or thousands of individual machines it makes it hard for mail providers to block them individually. It also uses a ton of bandwidth on internet service providers networks.
So some time ago service providers started to simply block port 25 (used to send email) on their networks except to certain services. I think they’ve backed off a bit now but inbound port 25 can often be blocked still. It may even be against their TOS in some cases.
It does have quite a bit of overhead, meaning it’s not the fastest out there, but as long as it’s fast enough to serve the media you need, that shouldn’t matter.
Also, you need to either mount it manually on the command line whenever you need it or be comfortable with leaving your SSH private key in your media server unencrypted. Since you are already concerned with needing to encrypt file share access even in the local network, the latter might not be a good option to you.
The good part about it is, as long as you can ssh from your media server to your NAS, this should just work with no additional setup needed.
I’m not expert but for the sake of getting some discussion going:
Don’t open ports on your router to expose services to the open internet.
Use a vpn when torrenting and make sure your torrent client is set to only use the vpn’s network adapter. This way, if your vpn drops out the torrent client can’t reach the internet.
I keep everything local and use Tailscale to access things while I’m away from home.
There’s some really fun chemistry in the rare-earth magnets - I used to buy them in bulk to enlarge my own IT-workshop collection, which was mostly broken down for Nd salts. Also, the magnets from iMac screens were also plentiful when HDD magnets got small (and then went extinct).
selfhosted
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.