Suggestions for a more privacy conscious email provider

Mailman List Mirror (Read Only)
21

In my naive opinion, there are some subtle differences with where "the linux box you can ssh into" resides.

Namely, when I ran my server at home, it took a search warrant to legally enter my house to access the server, which I would be immediately made aware of. I can't say the same with the same degree of certainty for a server located in a co-location facility.

I'm obviously ignoring someone compromising the system across the network. Though even then, I can disconnect the server from the outside world and still access it from my home.

22

I'll just remind everybody that if this is a serious component of your threat
model, you probably need to have gotten in touch with some serious
professionals to help set everything up, because it's going to have more little
gotchas than we can cover here on NANOG. For starters, did you build
your system in a way that avoids cold-boot attacks against the crypto
keys that manage access to your hard drive?

(Those 6 of you who *are* serious professionals at this can ignore that advice :slight_smile:

23

I'll just remind everybody that if this is a serious component of your threat
model, you probably need to have gotten in touch with some serious
professionals to help set everything up, because it's going to have more little
gotchas than we can cover here on NANOG.

Yup.

For starters, did you build
your system in a way that avoids cold-boot attacks against the crypto
keys that manage access to your hard drive?

Probably not.

(Those 6 of you who *are* serious professionals at this can ignore that advice :slight_smile:

Do I count? I only accused the Director of the NSA of High Treason in my letter to the editors of the Communications of the ACM (see <http://www.shub-internet.org/brad/cacm92nov.html&gt;\).

So, yeah -- having the hardware here in my house so that it is more secure against unreasonable search and seizure -- that is very much in my threat model.

24

If you're really worried about this, separate your mail storage from the mail transport. Run an inbound and outbound smarthost on your $5 VPS to queue up mail and deliver it back to your house where your long term mail is stored. This gives you the benefit of the static IP at the VPS along with the security and cheap storage of having the mail storage in house.

If you're worried about the short amount of time that messages are queued up on your VPS before making it to your house then you really shouldn't be communicating over email.

25

The concept is sound, but attempting to use your $5 VPS as your outbound mail relay is only going to end in pain and tears -- your VPS cannot have or build a good enough reputation to get reliable delivery to the big mail providers. You need to use an outbound mail relay that already has a good reputation, and that works hard to continue to maintain that reputation.

As for handling your inbound mail, use something like imapsync and then effectively treat your IMAP provider as a POP3 provider instead, and download/delete the messages from their system as soon as they have been copied to your local system.

The bad guys could tap into the stream of mail that flows through that system, but they wouldn't be able to get into your archive of old mail without breaking into the box sitting in your house.

26

Treason fail. What declared enemy of the US did the Director provide aid and
comfort to? (Hint: a declaration of war seems to be considered important -
during the Korean conflict a number of soldiers didn't get prosecuted for
treason at least partly because we hadn't actually declared war on North Korea.
Similarly, the Rosenbergs got the chair for espionage but not treason, because
we didn't declare war on the USSR either during the Cold War). Actually, we
haven't declared war on anybody since WWII...)

27

I'm not personally really worried about this. - I was just calling out that it is a difference. For others that do care. :wink:

If you're really worried about this, separate your mail storage from the mail transport. Run an inbound and outbound smarthost on your $5 VPS to queue up mail and deliver it back to your house where your long term mail is stored. This gives you the benefit of the static IP at the VPS along with the security and cheap storage of having the mail storage in house.

I agree that the VPS Smart Host is a good solution. However that puts you in a position that you are now administering multiple mail servers.

I'd suggest that people new to mail servers stick with a single $5 ~ $10 / month VPS that does all of the roles. - Then graduate to the multiple server solution.

If you're worried about the short amount of time that messages are queued up on your VPS before making it to your house then you really shouldn't be communicating over email.

I think it depends what part of the communications you're worried about. S/MIME and PGP tend to cover a lot of the (non-metadata) concern.

28

Technically, I accused him of causing Very Grave Harm to National Security Interests, which is treated at the same severity as High Treason.

Or at least, that was the way I read the "Orange Book" TCSEC at the time, because I deliberately took the wording straight from that book.

29

The concept is sound, but attempting to use your $5 VPS as your outbound mail relay is only going to end in pain and tears -- your VPS cannot have or build a good enough reputation to get reliable delivery to the big mail providers. You need to use an outbound mail relay that already has a good reputation, and that works hard to continue to maintain that reputation.

My experience shows otherwise.

I've been using a VPS as my primary mail server for > 2 years and have only been black listed once. Even that was a 12 hour automated listing because I sent one message to an address I had not used in 7 years, which had since been converted into a spam trap.

I've also known others that use VPSs for this exact thing with considerable success.

As for handling your inbound mail, use something like imapsync and then effectively treat your IMAP provider as a POP3 provider instead, and download/delete the messages from their system as soon as they have been copied to your local system.

Why? Having a different provider handle inbound will require them supporting your domain(s). Why not handle inbound email directly?

The bad guys could tap into the stream of mail that flows through that system, but they wouldn't be able to get into your archive of old mail without breaking into the box sitting in your house.

S/MIME / PGP }:slight_smile:

30

There are all kinds of factual issues with the arguments in the referenced document.

1. During Desert Storm I personally sent hundreds of STU-IIIs to the sandbox. They didn't go in diplomatic pouches, they went as Air Force cargo like everything else. The State Department did not have to "smuggle" anything. They use diplomatic pouch as a way to prevent the receiving country from inspecting the shipments. This is common for all cryptographic devices, classified or not. Also commonly used for Playboy magazines and bottles of scotch going into Saudi Arabia.

2. Treason is not applicable here because there must be a declared war. Treason requires interaction with a declared enemy during a time of war. I know that term gets thrown around haphazardly lately but it is a very specific legal term.

3. Asking a government agency act as the KDF is so demonstrably brain damaged we don't even need to go into the problems with that. They have shown that:

  a. They are not interested in keeping your data secure, in fact they would like to keep as much of it in their databases as possible.

  b. Most of the organizations you listed have been breached multiple times and receive failing grades under their own IT standards for security.

  c. International organizations are even worse. So, if my keys are stored by the IEEE does that mean that only countries that are part of the United Nations can get access to my data. I feel much better now :slight_smile:

4. Sending a device or technology out of the US does not equal an export under ITAR. In your example, if a device is going to be used by US Government employees or military personnel and kept under their control, it is not an export. As a matter of fact a US company can use export restricted software and hardware in foreign countries in most cases if it is under to control of US Nationals. i.e. US company can use high encryption licenses for Cisco devices inside of China branch offices to secure their VPN connections. My company has this in writing, we did all of the appropriate export paperwork and then was told it was unnecessary since the software remains under the control of US nationals (of course they know that all the foreign intel agencies already have it so they are not worried about James Bond sneaking in the middle of the night to reverse engineer it).

5. The DirNSA has a vested interest in the collection of intelligence and the security of US GOVERNMENT systems as his primary responsibilities. Securing US private entities is way down his list of priorities and if in conflict with his primary missions will take a back seat. Not treason my friend just focus on his mission.

Steven Naslund
Chicago IL

31

I run my own mailserver...

​

32

This is incorrect reasoning. Because they're the biggest cloud provider
in the world, they should send the least amount of junk: the larger
an operation is, the easier abuse detection/prevention gets. [1]

They have -- for all practical purposes -- unlimited computing resources,
unlimited personnel resources, and unlimited financial resources.
Shouldn't they be leading? Shouldn't they be more professional, more
competent, more diligent than all of us? Shouldn't they be the exemplar
for How To Do It Right?

---rsk

[1] I don't expect them, or anyone else, to catch everything all the
time. There are always unpleasant surprises. But there is absolutely
no excuse for systemic, chronic abuse, for failure to accept abuse
reports, for failure to respond to them quickly, for failure to
act on them promptly, for failure to prevent repeat incidents,
or for failure to apologize.

33

Yes. And it will need to be located in an allocation that's known
to be static, i.e., a single static address in the midst of a large
block of dynamic addresses == trouble. It'll also need to be on
a provider that that has scrupulously dealt with abuse issues; those
that don't may have large swaths of address space that's already
blacklisted. One way to determine this is to ask them what address
they will assign *before* you sign up, then check that address
against various blacklists.

You'll also need matching A and PTR records: if the mail server
is mail-abc.example.com, then the PTR needs to match. It's also
highly advisable to make it HELO as that same canonical name.

I also suggest running an instance of a nameserver on the same box.
Mail servers make a lot of DNS queries, so having one right there --
with a cache that will eventually be populated according to local
usage patterns -- is useful. Just make sure it's not an open
resolver, i.e., make sure it only answers queries on 127.0.0.1

A Raspberry Pi can handle this. Doubly so if you customize its defenses
specifically to your needs. The more abuse you reject outright via
the onboard firewall and via MTA configuration, the less will make it
through to more computationally expensive steps. Note that you'll
need enough storage if you really do plan to use it for the LKML;
I've seen roughly 50M in traffic on it since 11/28 and there are
times when it spikes (in terms of the number of messages and their
aggregate volume) quite a bit.

---rsk

34

Not from I’ve seen, most get big fast, and than security follows secondary. Name your ISP, your Cloud, and your Virtual Environment.
Comcast and AOL used to be hell for spam, then they started blocking SMTP, or in AOL’s case sort of went out of business till the VZ buyout. From what I’ve noticed, OVH is sort of the same, got big quick and was one of the biggest spammers around, they have finally gotten their act together IMHO. Linode from what I remember hasn’t been that bad, a couple of hacked servers of course, but par for the course and kept things manageable and responsive to my requests. Main point I think is mailops comes with a learning curve, and it happens...

35

In article <e726b3a2-4dbf-9db6-a695-95b483001036@spamtrap.tnetconsulting.net> you write:

36

I do the same thing, with pretty much the same experience. One initial
blacklist hiccup that was easily resolved.

I ran my mail server at home for a while, but after a few storm-related
outages I switched to a cheap VPS doing store-and-foward.

You can also shop around to get some storage (20-50GB) that you can use
for remote backups of critical files (encrypted, of course).

I find Low End Box <https://lowendbox.com/> is a good resource for
finding VPS providers. You will have to pay attention if you want IPv6
support, as it's far from universal.

37

Last week we found out that Helpscout sends email from AWS servers.

Thank you, Helpscout, for forcing me to lift the AWS blocks on my incoming MTAs, that were cutting down my incoming spam scanning load by a factor of two. At least.

Note that I work for an email hosting company, which makes this infinitely more annoying. A factor of two, in this case, is a non-trivial number.

--lyndon

38

I believe my comment "it took a search warrant" was taken slightly out of context. Nothing like that ever happened.

I was meaning to imply that I believe it would be more difficult to access the server at my house than at a co-lo / hosting facility.

I'm speaking in the hypothetical with zero experience.

39

In article <0f7a39b9-efee-54d6-d449-081c7825cdec@spamtrap.tnetconsulting.net> you write:

I was meaning to imply that I believe it would be more difficult to
access the server at my house than at a co-lo / hosting facility.

Depends on the hosting facility. My server is in a locked room that
used to contain printing presses, so it's pretty sturdy. I expect the
hosting provider would be sceptical if someone showed up with a
subpoena.

For that matter, due to the somewhat informal way the IPs are managed
(I'm borrowing a block from a local ISP who doesn't currently need
it), it's rather hard to figure out where the server is. See if you
can tell me where the host mail.iecc.com is physically located.

R's,
John

40

There are all kinds of factual issues with the arguments in the referenced document.

1. During Desert Storm I personally sent hundreds of STU-IIIs to the sandbox. They didn't go in diplomatic pouches, they went as Air Force cargo like everything else.

Maybe not all of them went the way I described, but there were public stories at the time regarding ones that had been sent in diplomatic pouches, and which was confirmed by the government. I wasn't concerned about the STU-IIIs that got sent the "normal" way, and therefore I did not mention them.

What really concerned me at the time was that it was totally okay to send them in a wide variety of ways before they were keyed, but they had to be sent via diplomatic pouches once they had been keyed, in order to get around our own export controls regarding munitions.

Today, I know a bit more about what "keying" means than I did then, but not much more. I guess if you're using shared secrets everywhere, it becomes really important to protect those shared secrets against everyone, including other members of our own government.

2. Treason is not applicable here because there must be a declared war. Treason requires interaction with a declared enemy during a time of war. I know that term gets thrown around haphazardly lately but it is a very specific legal term.

Okay, so treason was the wrong term. I grant you that. In fact, I granted that in my previous message.

Let's get over that word.

3. Asking a government agency act as the KDF is so demonstrably brain damaged we don't even need to go into the problems with that. They have shown that:

At the time, I think it was reasonable to at least mention using a government agency as a Key Escrow agent, if only to point out one possible solution.

Key Escrow has had a lot more research since 1992, and we've learned a lot of lessons since then.

4. Sending a device or technology out of the US does not equal an export under ITAR. In your example, if a device is going to be used by US Government employees or military personnel and kept under their control, it is not an export. As a matter of fact a US company can use export restricted software and hardware in foreign countries in most cases if it is under to control of US Nationals. i.e. US company can use high encryption licenses for Cisco devices inside of China branch offices to secure their VPN connections. My company has this in writing, we did all of the appropriate export paperwork and then was told it was unnecessary since the software remains under the control of US nationals (of course they know that all the foreign intel agencies already have it so they are not worried about James Bond sneaking in the middle of the night to reverse engineer it).

The rules regarding the exportation of strong crypto have changed since 1992. Although it now looks like maybe they're soon going to be going back the other direction.

However, for the moment, it is still a non-sequitur to apply the rules of exportation under modern law to something that was written in 1992.

5. The DirNSA has a vested interest in the collection of intelligence and the security of US GOVERNMENT systems as his primary responsibilities. Securing US private entities is way down his list of priorities and if in conflict with his primary missions will take a back seat. Not treason my friend just focus on his mission.

I believed at the time that he was causing Very Grave Harm to National Security Interests, through their actions to try to force the standardization on poor encryption algorithms and prohibit the use of strong crypto.

As far as that statement goes, I believe that it is as true and applicable today as it was in 1992.