this post was submitted on 04 Aug 2024
36 points (100.0% liked)

Technology

37708 readers
494 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
 

I need to change ISPs and need to find a new email provider. This time I want to move to my own domain which I purchased through Namecheap and I do not want to use another ISP's email system nor do I want to use Google, or Microsoft since I am Linux (and Android too) based. I would like this to be US based or at least have a strong US presence so obvious choices like Proton Mail, Mailfence, and Mailbox.org are out. I would prefer it interoperate well with FOSS software too, I use Thunderbird and K-9 Mail for example. Also so want them to be trustworthy, have good security, and have good OpSec with respect to their their servers and service.

After looking I find three I am considering and they are quite different:

  • Fastmail. Long history. No PGP support but they do have their own domains one can use also.
  • Namecheap Private Email. Uses Ox App Suite, may support PGP, and quite new. I think you have to have your own domain (not sure).
  • Forward Email (forwardemail.net). A forwarder with IMAP support. You supply the webmail if you want webmail, but otherwise it should work fine with IMAP and normal clients.

So questions:

  • Any thoughts and experience, pros and cons with the above 3.
  • Other better ideas.

So thoughts? Thanks.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 3 months ago (3 children)

Two tips having worked in the corporate world (strict controls):

  • Create a basic non-spam web page for it that has something that doesn't look like SEO garbage or whatever. Nothing more than "hey this is a personal domain of the flatbield family" is fine, maybe a link to something (links enhance rep - put a picture of your dog up or link to a wikipedia article or something) and let it rest for at least 30 days. The 3rd party filtering services used by corporate players severely limit, block or distrust a domain newer than 30 days (or longer, depending). Set up a SSL cert on it for another +1 to it's rep value, HTTPS is looked at by these services and ensure the CA record is in your DNS for that SSL issuer.

  • Ensure you use the Providers' setup for DKIM, SPF and so forth (many like Fastmail have a DNS-check wizard to get you all set up) as many modern providers will instantly downvote you if anything is missing or wrong with these controls (I've heard GMail and O365 particularly). In 2024 these are a must-have, not a nice-to-have, for getting your email received by anyone and everyone.

If you chose a domain at a TLD which has/had been used by the bad buys (dot-xyz, info, zip, etc.) you may wish to reconsider - there are TLDs which are wholescale blocked or downvoted in rep based on this (by the same services used above). Ensure someone working at a bank (strict egress controls for their employees) can visit your domain as a good litmus test as to it's validity for use in email reputation.

A company such as Fastmail spends a lot of time ensuring their IP address space for sending and receiving mail is clean - getting spammers off their service, getting IP rep cleaned off blacklists and so forth. So your task is to focus on the same thing for your domain - if someone had previously owned the name they could have gotten it on blacklists long ago, a handy way to check old history is looking it up at web.archive.org for captured snapshots (and I've walked away from domain names because of this once I discovered previous content I didn't like).

[–] [email protected] 1 points 3 months ago (2 children)

Thanks. Great ideas. Had not considered the web issue. I actually have a VPS for other things at Linode. I could just add my new ".net" domain to that and setup something. Let rest is fine. We are transitioning over the next 6 months and hope to not change for a long time after that. So we have time to get this correct.

I also have mail setup in my VPS for other reasons so I do understand mail basics. Including SPF etc. Never really had any delivery issues but I do not use it generally. I think my old domain which I have had for 5 years has a fine reputation. Good point about the one I just purchased. Just do not want to move my general mail there or commit to setting it up and worse maintaining the multiple VPS systems needed to really do mail correctly. That is, I would want to have at least two incoming SMTP servers in two different data centers then maybe separate IMAP server too that they route to. Then there is the webmail client and locking it all down. Cost and worse yet effort and time mount up and it's not a one time deal. Not something my wife could do and not me 20 years from now.

[–] [email protected] 1 points 3 months ago (1 children)

To your multiple IMAP concept, I have been using isync / mbsync (name change, package isync in Debian) for years running via cron script to pull email from one domain at one provider and push it to a subfolder of another domain at another provider. You have to be aware of one specific gotcha but it's otherwise been working all by itself forever without issues. Take note of the PipeLineDepth 1 for IMAP service providers which throttle your speed, I have to use it on the destination side provider config.

[–] [email protected] 1 points 3 months ago

Thanks. Interesting.

Just FYI, I was talking multiple SMTP servers not IMAP servers. If I did it, I would have 2 public facing SMTP servers which would then route to an internal SMTP server probably with a single IMAP server. The routing would probably be over a private link not a public one and the final server would present only IMAP publically. Really reduces attack surface.