Finding a Secure, Fast, and Stable Email Alternative to ProtonMail for Use with Outlook

[mraleph]

do you have any experience with Axigen? if so, would you recommend Modoboa over it?

As a matter of fact, we considered all non Dockerized solutions, including Axigen for our needs Paradoxically, Mailcow and Mailu have better performance as containerized.

The question is similar - perhaps not quite - to whether Mikrotik CCR2216 or Juniper Networks MX204 should be deployed for BGP routing - we would always select the later, despite the price difference. It's about features. Stub or multi-peer? What is a deployment scenario?

Mail package wise - we selected Modoboa - as they integrated known packages - but have a license for Axigen - they've developed new module for every email server segment - we don't and won't use. Knowledge that operator/administrator has becomes pseudo-obsolete and the package has steep learning curve without any reason.

Answering strictly - I would propose Modoboa over Axigen, considering the @EliasIT use case.

 

[diro]

Answering strictly - I would propose Modoboa over Axigen, considering the @EliasIT use case.

I assume it is complicate for non techy's to setup right?

 

[mraleph]

I assume it is complicate for non techy's to setup right?

I wouldn't say it's complicated - maybe time consuming - including the DNS and domain reputation (SPF, DKIM, DMARC) setup.

With appropriate network policy (filtering traffic) and CDE/FDE, you would have a fully fledged and secure mail server that can exchange mails with any other domain.

 

[wonderfulboy]

you really know stuff @mraleph I enjoy reading your posts.

 

[EliasIT]

I wouldn't say it's complicated - maybe time consuming - including the DNS and domain reputation (SPF, DKIM, DMARC) setup.

With appropriate network policy (filtering traffic) and CDE/FDE, you would have a fully fledged and secure mail server that can exchange mails with any other domain.

But it requires a good amount of experience with sophisticated IT systems and how they function. It's not something an average layperson could figure out, I would imagine.

 

[mraleph]

But it requires a good amount of experience with sophisticated IT systems and how they function. It's not something an average layperson could figure out, I would imagine.

That would resemble a CAD/CAM software installation with plethora of drivers on a Microsoft Windows - follow the instructions principle. So, it fits the layperson perfectly.

Electronic mail server can't be considered sophisticated IT system

 

[EliasIT]

That would resemble a CAD/CAM software installation with plethora of drivers on a Microsoft Windows - follow the instructions principle. So, it fits the layperson perfectly.

Electronic mail server can't be considered sophisticated IT system

When you say that, it’s probably true...

 

[mraleph]

When you say that, it’s probably true...

Well, I may post the sequence and instructions in MGG for setting up personal secure mail server. Will consult with @0xDEADBEEF about that OPSEC guide for regular and high net worth persons we wanted to write.

There are far more serious, complex and sophisticated matters in - what you call IT - but the mail server definitely isn't.

 

[diro]

I believe a lot of what the IT-savvy people post about is completely incomprehensible for us ordinary mortals, and therefore it's difficult to relate to all the terms and concepts.

But I will look forward to read you article in the mentor group

 

[cckuhqilfownnfctux]

For instance, if I subscribe to emails from HSBC, I create an 'unpredictable' alias like [email protected]. Every important account will have a different email address, but I end up seeing it in one inbox anyways. Just need to be careful with the sender address in some cases.

I do the same to prevent SPAM and to track website hacks / database leaks and over the years I've had multiple occasions when I started receiving SPAM to an unique email address, which effectively means that the website I was using that email for got hacked.
and I've had zero occasions when I was able to convince the website owners that they were hacked. "No, our customers database was not leaked, the problem is on your side" - yea, of course a random spammer would all out of sudden send a spam email to "[email protected]" LOL.

 

[cckuhqilfownnfctux]

Well, I may post the sequence and instructions in MGG for setting up personal secure mail server. Will consult with @0xDEADBEEF about that OPSEC guide for regular and high net worth persons we wanted to write.

is that a PM conversation? please invite me too, I'd like to see that manual and might add something to it.

There are far more serious, complex and sophisticated matters in - what you call IT - but the mail server definitely isn't.

well I would consider email server as a serious and somewhat sophisticated matter too for example even if you hide your website behind Cloudflare or similar provider you could leak your website's real IP address if hosting the email server (software) on the same server (hardware) as your website.

 

[mraleph]

is that a PM conversation? please invite me too, I'd like to see that manual and might add something to it.


well I would consider email server as a serious and somewhat sophisticated matter too for example even if you hide your website behind Cloudflare or similar provider you could leak your website's real IP address if hosting the email server (software) on the same server (hardware) as your website.

For reasons of OCT culture, elevate your status - procure MGG membership - and we may create a group in which others may participate as well. Quite knowledgeable members exist - @aniglo22, @daniels27, @void etc. that greatly contributed to discussions where offshore intersected with OPSEC and digital matters. As for @0xDEADBEEF, I may only say from professional aspect that it would be a rare person that I would ask for any particular matter unbeknownst to me. Where I do business, I seldom to never ask anybody. This also applies to offshore - and in that area, you have another plethora of knowledgeable members beside the ones already mentioned - @jafo, @wellington, @JohnnyDoe, @Marzio etc.

Certain aspects are more common sense then security advisory. One of those is DNS management. In any threat model, it's nominal not to have web and mail servers on the same address nor instance. While you can proxy content and effectively mask the real public IP address by using Cloudflare DNS management, mail traffic can't be proxied that-ways due to inherent DNS logic - a MX record. You may relay it, but, in the end and due to mail architecture, real public IP address will be known.

My statement still stands about the mail server. I'll make a script that any end user may execute and have functioning secure mail server within 30 minutes.

 

[cckuhqilfownnfctux]

ail traffic can't be proxied that-ways due to inherent DNS logic - a MX record. You may relay it, but, in the end and due to mail architecture, real public IP address will be known.

you should proxy the mail traffic on the network layer not on the application layer, i.e. use VPN or a transparent proxy instead of a relay function of the mail server itself.

 

[mraleph]

you should proxy the mail traffic on the network layer not on the application layer, i.e. use VPN or a transparent proxy instead of a relay function of the mail server itself.

When you execute

dig all $domain
dig mx $domain
dig ns $domain

you'll get the real public IPv/IPv6 address.

Let's use proper vocabulary. You may perform L2/L3 tunneling for any traffic, both for mail and web content and set-up DNS parameters accordingly, so that above commands give private feedback.

This aspect may contribute the OCT community also for setting-up not only personal or business mail server but also for hosting web content as well.

 

[cckuhqilfownnfctux]

When you execute

dig all $domain dig mx $domain dig ns $domain
you'll get the real public IPv/IPv6 address.

a public IP address of a proxy server you mean?
a few of my mail servers have only 192.168.1.1-like IP addresses while being connected to the Internet and able to send and receive emails, and their MX records point to the proxy server's IP address not to "192.168.1.1".

Let's use proper vocabulary. You may perform L2/L3 tunneling for any traffic, both for mail and web content and set-up DNS parameters accordingly, so that above commands give private feedback.

you should perform L3/L4 tunnelling for any traffic, both for mail and web content ("L2" was a mistype?)

 

[mraleph]

a public IP address of a proxy server you mean?
a few of my mail servers have only 192.168.1.1-like IP addresses while being connected to the Internet and able to send and receive emails, and their MX records point to the proxy server's IP address not to "192.168.1.1".


you should perform L3/L4 tunnelling for any traffic, both for mail and web content ("L2" was a mistype?)

Discussing these matters and other ones at OCT requires a bit of an abstraction, parallel and contextual reasoning, don't you agree? But, yes, the gateway address was assumed.
Without discussing the OSI model, perhaps, an introduction and guide should be also written for the whole OCT community regarding how to properly set-up private web-server with available tunneling technologies. That is, to offer to this community a way to legitimately mask their location, without any leaks. Would be quite useful for our fellow OCT members, right?
Elevate your status to MGG, post in MGG and contribute as well. I'm confident that others will follow suit and share their knowledge.
Mail server address wise - it wouldn't be proper to have localhost or private addresses as the origin, notwithstanding the domain reputation parameters. It's prudent to use real and public IPv4/IPv6 ones.

 

[cckuhqilfownnfctux]

Elevate your status to MGG, post in MGG and contribute as well.

I don't get it, you want me to pay money to be able to share my knowledge? if I would ever write such manual I will share it for free, in the public part of the forum.

Mail server address wise - it wouldn't be proper to have localhost or private addresses as the origin, notwithstanding the domain reputation parameters. It's prudent to use real and public IPv4/IPv6 ones.

the origin seen by the Internet is the proxy server, not the 192.168.1.1 from my example, i.e. the "Received:" header of outgoing emails has a valid external IP address like 12.34.56.78 pointing to the MX record of the domain, so "dig MX mydomain.com" will return "12.34.56.78" not "192.168.1.1".
but that IP 12.34.56.78 does not have a mail server (software) installed, it is just a proxy for the real server located somewhere else. the "real" server does not have any external IPs, so not only outgoing emails do not leak the real server address, but also if some hackers will achieve code execution on the server and will run "ifconfig" they will see only 192.168.1.1 not its real IP (and if they run "curl whatismyipaddress.com" or similar they will see the VPN server's IP address, again not the real location)
and in case that public MX record 12.34.56.78 will get down because of a DDoS attack or whatever else the real mail server will not be affected, I will be able to route the traffic through a different proxy.

 

[mraleph]

I don't get it, you want me to pay money to be able to share my knowledge? if I would ever write such manual I will share it for free, in the public part of the forum.


the origin seen by the Internet is the proxy server, not the 192.168.1.1 from my example, i.e. the "Received:" header of outgoing emails has a valid external IP address like 12.34.56.78 pointing to the MX record of the domain, so "dig MX mydomain.com" will return "12.34.56.78" not "192.168.1.1".
but that IP 12.34.56.78 does not have a mail server (software) installed, it is just a proxy for the real server located somewhere else. the "real" server does not have any external IPs, so not only outgoing emails do not leak the real server address, but also if some hackers will achieve code execution on the server and will run "ifconfig" they will see only 192.168.1.1 not its real IP (and if they run "curl whatismyipaddress.com" or similar they will see the VPN server's IP address, again not the real location)
and in case that public MX record 12.34.56.78 will get down because of a DDoS attack or whatever else the real mail server will not be affected, I will be able to route the traffic through a different proxy.

This forum has tiered membership and for a good reason. Nothing I proposed to you is out of the OCT rules and culture, particularly related to mentor group gold members. When I wrote post in MGG I meant post in Mentor Group Gold forums - a non transparent ones. But, it's your decision after all. Search the forum for what comes with membership.
Anyway, it's interesting discussing with you and I'm glad that you can contribute. Good thing I'm an atheist because it's Shabbat today.

 

[lory]

With my very limited knowledge of all this, especially about securing an email account, I can conclude from this thread that it's impossible to fully secure an email account. One way or another, it can be hacked, and someone can access the emails and what’s written in them.

 

[cckuhqilfownnfctux]

With my very limited knowledge of all this, especially about securing an email account, I can conclude from this thread that it's impossible to fully secure an email account. One way or another, it can be hacked, and someone can access the emails and what’s written in them.

with my extensive knowledge on this subject I can assure you that it is in fact very difficult to secure an email account, and that's exactly why PGP was invented.
learn how to encrypt emails using PGP and educate your colleagues, and make sure to encrypt the messages inside a mail client software installed locally on your computer, not inside a browser (i.e. do not trust Protonmail's "automatic PGP encryption")