
Why is no one signing their emails? - Karrot_Kream
https://arp242.net/weblog/signing-emails.html
======
andrewstuart
It's surprising to me that anyone could think that email signing was even
vaguely in the ballpark of being comprehensible to the ordinary person.

~~~
mikekchar
Conceptually it's not hard at all. "When you send an email there is no proof
that it came from you. It is easy to fake emails. When you press this button,
it will 'digitally sign' the email. Now people can tell that it comes from
you."

It's the key exchange that's difficult. However, as the blog rightly points
out, having _companies_ sign their emails would be a _massive_ step in the
right direction. Every ordinary person uses an email service. If that email
service handled the key exchange for those companies the it would be truly
wonderful. It doesn't even need to be that difficult given that these
companies almost certainly have certificates for their websites.

Then all the service provider has to do is put this nice message when
delivering the email: "This email was not signed by the company that it claims
to be sent from. Beware." Not in any way difficult for an ordinary person to
understand.

~~~
andrewstuart
This is a deeply ironic reply - is it intended to be? There's almost no words
there that would gel into comprehension in any way for average Joe and Jill.

I don't want this to come across the wrong way - but are you a Linux
engineer/admin? I think when someone has deeply understood deeply technical
things for a very long time, they lose touch with just how arcane their
knowledge is and how much of a real expert they are - skyscrapers above the
ordinary level of knowledge. This state leads them to think that what is
obvious to them can't be hard for others to understand.

~~~
dTal
You must have a very low opinion of average Joe/Jill, to not expect them to
understand "When you send an email there is no proof that it came from you."

I really don't see what's so hard about the first paragraph, which is the only
one intended to be understood by a layperson. Even though the concept of
"signing" has a long-established and well-known non-digital meaning, which
nearly everyone will understand, the paragraph still goes out of its way to
define it. Seems pretty idiot proof to me.

~~~
sethammons
I knew a smart guy that believed someone could physically watch him through
his monitor.

~~~
jl6
Given laptop webcam placement these days, this is kinda true...

~~~
NikkiA
I was looking at (budget) desktop monitors the other day, and noticed a
disturbing number of them included a built-in webcam.

------
seanwilson
I think if Gmail decided to implement email signing today as a prominent
feature where they show a big warning for all non-signed emails the user
demand for it would happen pretty quick e.g.

    
    
        WARNING: You cannot trust this email was sent from who it
        says it's from, the email have been modified in transit,
        and the email may have been read by hackers in transit
    

Similar to how Chrome started showing non-HTTPS sites as "Not secure".

~~~
organsnyder
They already show this information, but it's not prominent (I had to view the
sender details to see it).

[https://support.google.com/mail/answer/6330403](https://support.google.com/mail/answer/6330403)

~~~
mankyd
Encryption and signing are different things here. Encryption in this case
means that the contents of the email are encrypted between Google's servers
and the recipient's servers. i.e. preventing snooping.

Signing verifies that the contents of the email itself have been authenticated
by the author. I.e. prevent spoofing.

~~~
organsnyder
Their documentation doesn't mention signing specifically, but wouldn't S/MIME
include signing?

~~~
mankyd
Signing on behalf of the server, maybe, but gmail in no way
supports/encourages having the actual author sign their messages, to my
knowledge.

------
mikekchar
All I can say is OMG yes. I've been meaning to write the exact same blog post.
How is it we're at 2019 and email clients don't demand some kind of signature?
How is it that you can spoof email... simply by entering the fields however
you want to? It's insane.

I agree that the key exchange is difficult, but seriously I'll even take a CA
if it means that I can reasonably tell that email that appears to come from my
bank probably comes from my bank. Even better if a technical user can manage
the keys themselves, but at least lets do the bare minimum!

~~~
Arnt
PGP isn't demanded, but a different kind of signature is increasingly
demanded: DKIM. Only a minority uses it to reject mail on its own (although I
guess that minority is bigger than the number of PGP users), it's widely used
as part of a scoring system.

------
z3t4
There's nothing stopping spammers from signing their spam. The pain point with
signing and encryption is key rotation.

One problem is that both scammers and banks themselves use domains like
paypal.accepournewtos.com or paypal.usersurvey.com and
paypal@ourmailservice.randomdomain.com

~~~
Carpetsmoker
> There's nothing stopping spammers from signing their spam. The pain point
> with signing and encryption is key rotation.

Yes, but those signatures can't be verified.

I understand this is tricky problem; how do we prevent people from simply
clicking "accept this unknown key"? I'm not sure; but not _every_ user is a
blubbering idiot, and "unknown signature" strikes me as a lot better UX than
"carefully look for spelling errors or misleading domain names".

~~~
chx
[https://twitter.com/miradoreltd/status/843877685675868160](https://twitter.com/miradoreltd/status/843877685675868160)
adopted from
[http://blog.johnath.com/images/snotweasel.png](http://blog.johnath.com/images/snotweasel.png)

[Transcription: Windows XP error dialog with the yellow triangle - title
"Something happened and you need to click OK to get on with things." details:
"Certificate mismatch security identification administration communication
intercept liliputian snotweasel foxtrot omegaforce." then you have a button
saying Technical Crap and three radio buttons 1) More technical crap 2)
Hoyvin-Glayvin 3) Launch photon torpedoes and then OK and Cancel buttons.]

~~~
riffraff
I will argue that something like the chrome untrusted certificate warning will
scare away most of the users.

[https://i.stack.imgur.com/r0iOf.png](https://i.stack.imgur.com/r0iOf.png)

~~~
tialaramex
Nope. Back in the old days Microsoft actually did tests on this in Internet
Explorer, with users real banking credentials not fake ones, so that the user
would properly value giving credentials away.

The only thing that actually works is brick wall UX. If you don't give the
user the option to ignore the problem, they are forced to give up, which was
the only safe option for them. If there's a way to continue, despite it being
unsafe, users will do that.

Humans have a psychological defect in which they become rigorously focused on
achieving a specific objective, and screen out indications that this is a bad
idea. This is why those signs saying "Danger! Low bridge" aren't as effective
as you'd expect. The human driving the over-height vehicle is focused on
getting to the other side of the bridge, your warning signs aren't helping
them do that, so they ignore them.

This is why a modern Firefox has brick wall UX for some HTTPS problems and
would like to do it for more such problems. Only brick wall UX keeps people
safe.

This is also why "bad idea" and similar Chrome overrides for their brick wall
have to be changed periodically, these start a "power user" feature for people
who actually do what they're doing, but quickly they spread and are used by
people just trying to get things done, without grasping that now they're
completely insecure.

~~~
Noumenon72
That brick wall UX keeps me from using Firefox on my work intranet, since we
have a self-signed certificate it doesn't like. I kind of wish the other
browsers did the same, so they would actually fix it instead of everyone
having to click the insecure warning to continue five times a day.

------
paxys
Sure an email from Paypal.com can be signed or encrypted, but so can an
identical one from Paypa1.com. How are users more protected in this case? In
fact a big "sender verified" message in the email client for the latter email
will cause a lot more phishing.

~~~
c256
Web browsers already implement a ‘near miss that’s probably intentionally
confusing” check on domains, and the code is readily extracted and shared (I
know about it because someone extracted it and added it to Emacs a couple
years ago).

This seems like one of those cases where more large infrastructure people need
to say “don’t let the perfect be the enemy of the good”.

~~~
joombaga
> Web browsers already implement a ‘near miss that’s probably intentionally
> confusing” check on domains,

What do they do with the information?

~~~
c256
For Emacs (and its web browsers, email clients, etc) this comes up in a
concept of “confusables” strings that could easily be mistaken for other
strings, usually as a result of Unicode tricks (multiple similar code points
from different scripts, or composed versus combined characters, or sometimes
ugly tricks with LtR/RtL markers. The code added to emacs was. A library that
could be used to detect these probably-misleading tricks, but they didn’t
implement a policy for them. The uses I saw of the library fell into the sort
of “Danger, Will Robinson! This looks like it might be malicious” type
warnings that can be found in most browsers these days.

------
jcrites
Email is already generally signed and verified when sent and received by
competent email providers.

DKIM and DMAC are the technologies that do this. DKIM employs asymmetric
cryptography to sign all outbound emails from a domain name using a key for
which the public part is published in the domain’s DNS. Receiving mail servers
validate signatures automatically, looking up each domain’s public key from
DNS.

DMARC allows senders to advertise the fact that all email they send will be
authenticated, such as with DKIM or SPF, so that receivers may drop anything
else (kind of like HSTS for websites). Messages that lack a DKIM signature,
from sending domains that require it, will simply be dropped.

Quality email providers, including most webmail providers, offer these
capabilities built in. These technologies are table stakes for email, like
HTTPS is for websites. Take a look at received email in your mailbox for
DKIM/DMARC status headers and you might find that many messages are protected
by these technologies.

However, even strong authentication of email addresses is not enough to
prevent abuse. Attackers can send email from addresses that are similar (but
not identical) to the person they want to impersonate (typo-similar domains).
An attacker can fully set up the domain and employ DKIM+DMARC. Just like with
TLS, possessing a key is not by itself an indicator of trustworthiness.
Signing our email won’t stop people from being tricked by impersonators
unfortunately.

It’s similar to the phone system: if someone calls you and claims to be an
employee of your bank, how do you know if it’s really them? The best answer is
often to independently navigate to the bank’s website, look up their contact
info, and then use it to reach them. The same is the for email addresses: you
can’t assume that an address belongs to someone - you have to verify it
somehow (using an existed trusted channel). Then DKIM+DMARC can help by making
it impossible for anyone to forge messages from that address.

A starting point for a better solution to the identity discovery problem could
be a better address book experience, calling to the user’s attention the first
time they’re communicating with a new person, especially at a new or different
organization. Defending against phishing is more of a user experience design
problem than a crypto engineering problem in my opinion.

~~~
upofadown
DKIM and DMARC only verify the domain of the mail server ... which is
something we care about only because the email clients can't do something
better. A signed email identifies an individual sender. Pretty much apples and
oranges.

~~~
jhasse
Sure, but the SMTP server won't sign the email if it was sent with the wrong
login. So unless I don't trust the whole domain (in which case even PGP could
result in a false sense of security), this pretty much verifies the sender.
Only thing I need to do is to check if it's correct.

------
floatingatoll
Because no mail client implements a sane process for acquiring and operating
S/MIME certificates using an S/MIME-issuing CA within the mail client’s UX,
much less doing so automatically for all configured email addresses using
“confirmation link” emails occasionally.

------
fooblat
I used to work for a big tech company and the vast majority of people there
signed all email by default and encrypted them when the content was sensitive.
Part of onboarding was a training session on how all this works.

Now I work for a non-tech startup and there are exactly two of us who sign our
email. Happens to be another engineer I need to occasionally exchange
encrypted messages with.

As a positive, at least no one seems confused by my signed messages.

------
wtmt
> For signing there’s more margin; it’s okay if half the people never verify
> your signatures.

The problem that people may not verify signatures is one, but what's far worse
is that bad email clients won't show the email content for emails signed with
S/MIME certificates that have later expired. I was in an organization where
S/MIME certificates were always issued with a validity of one year, and I used
to sign all my mails. After a year, a colleague told me (and showed me) that
my previous mails in Outlook couldn't be read any longer. Turns out that
Outlook has a convoluted process to say "Yes, I know that the certificate used
to sign this mail has now expired, but it was valid at the time of signing and
I just want you to let me use it for older emails or just show me the email
content with some warning". I had to go through a series of steps to make sure
Outlook trusted those certificates for all mails.

Email clients need to improve a lot more on usability if people are to use
signatures and also manage multiple (expired) certificates.

------
mothsonasloth
The average Joey Bloggs is just coming to terms with fake news and how to make
their social media pages more private.

PGP is not user friendly though and will never reach wide adoption until it's
made easier or someone develops a service for it.

~~~
Carpetsmoker
PGP doesn't need to be user-friendly just to verify signatures. It's like
verifying your Linux distro's package system: all of them sign their packages
(usually with PGP) and they get verified on installation, but as an end-user I
never see it.

And yes, PGP is hard, but only if I want to add signatures to my emails, or
use it for encryption. But that's a different use case than what I wrote about
here. I think this is exactly the sort of confusion I intended with:

> Confusion between every-day “random person A emails random person B”-usage
> versus “large company with millions of users sends thousands of emails
> daily”-usage.

~~~
BeetleB
>But that's a different use case than what I wrote about here.

I find it amusing that the problem in the HN threads isn't that they know too
little, it's that they know too _much_. They've seen arguments against PGP for
years, and are having trouble processing the post in any way that is different
from the "usual" PGP use cases they've seen. I'm seeing comments arguing that
the user can't understand concepts of web of trust, or will get fooled by
Paypals.com's signature, etc.

------
peteretep
> Would probably have avoided Podesta and the entire Democratic Party a lot of
> trouble

Unconvinced. The Podesta phishing email has:

> _From:_ Google <no-reply@accounts.googlemail.com> > _Date:_ March 19, 2016
> at 4:34:30 AM EDT > _To:_ john.podesta@gmail.com > _Subject:_ _Sоmeоne has
> your passwоrd_

From a Google domain, to a Google domain. Google uses DKIM, so the sender,
message-id, etc, WAS ALREADY SIGNED, and apparently got through anyway.

Which part of this would further signing have helped?

------
jarjoura
It’s easy. The mail teams at Apple, Google and Microsoft are running in
maintenance mode and honestly there’s no money in it for them to invest in it.

~~~
runn1ng
GMail _just_ had a major redesign.

~~~
heavenlyblue
The literally only changed the CSS of the pages. Not even pagination logic was
changed - what am I missing?

------
simias
I always sign my email with PGP/MIME, although I do wonder if any of the
recipients ever bothered to validate the signature. I mostly do it out of
habit at this point. I use my GnuPG smartcard to authenticate through SSH and
encrypt files so I might as well tell mutt to sign my email.

These days I suspect that the average user simply trusts their provider's
antispam to discard bogus emails (and as TFA points out, DKIM does effectively
provide a signature, although obviously it's not the same trust model).

I haven't given up on PGP, if anything I use it more than ever, but in this
age of webmails and the general trend towards the centralization of the web I
think the author is preaching in the desert.

~~~
amelius
How do you distribute the public key?

~~~
simias
Through the usual keyserver network, keybase and my own web server.

------
hamilyon2
Author does not mention dkim in article which makes me think he might not
"read all the relevant RFCs" as he claims. Majority of important emails _are_
signed and are not easy to spoof

~~~
Carpetsmoker
I have updated the article to mention it:

> DKIM is useful, but limited. All it does is verify that an email which
> claims to be from paypal.com is really from paypal.com. What it lacks is the
> ability to show warnings such as "this email wasn't signed, do you want to
> trust it?" and "this signature isn't recognized, yikes!"

Perhaps such warnings could be accomplished with DKIM somehow (I'd have to
study it to see), and if it can: great! But in its current state it's doing
something different than what I'm proposing (which is why I omitted it
originally).

~~~
jhasse
Well that UX somehow exists: If DKIM fails, the changes are high the email
will be classified as spam or possible phishing.

------
BlackLotus89
At my current job it is "mandatory" to sign your mails with mime. We got the
infrastructure in place. I have seen 3 signed mails up until now. A colleague
of mine got the reply to one of his signed messages "can't read because it's
encrypted".

I would really love signed mails thought...

------
kccqzy
I was a period I actually sign every email I send. I stopped when I keep
getting replies about there's this mysterious p7s attachment people can't
open. And some people say their virus scanner thinks it's malware.

------
emilsedgh
I sign my emails with PGP all the time.

One of the problems I noticed is that the signature ends up as an attachment
and that confuses the hell out of many people.

 _Did you send me an attachment? What was that file I couldn 't open it!_

~~~
Carpetsmoker
Once (or rather, _if_ ) PGP gains some traction this problem will disappear;
email clients will improve the UX to show a specialised "PGP signed" box and
hide the attachment.

~~~
dredmorbius
It's been 23 years since MIME Security with Pretty Good Privacy (PGP) was
proposed.

[http://www.faqs.org/rfcs/rfc2015.html](http://www.faqs.org/rfcs/rfc2015.html)

I'm starting to think that someone really doesn't want this to happen.

------
cascom
The only organizations that i see consistently signing their emails are the
large commodity traders [1], not sure what drives it (third world country
operations, secrecy, etc.)

[1][https://en.wikipedia.org/wiki/List_of_commodity_traders#Mode...](https://en.wikipedia.org/wiki/List_of_commodity_traders#Modern_companies\[3\])

------
SamWhited
I gave up on using PGP for personal communications ages ago (even ones where
signing would actually be nice and not just a waste of time), but I still
appreciate services that do this. For example, my repository hosting
(sourcehut, [https://git.sr.ht](https://git.sr.ht)) and related services sign
emails. I could know nothing about their key, key management, levels of trust,
etc. just that I hit trust the first time (I'm perfectly okay with a TOFU
model here) and now I throw away any emails that don't have a green tick next
to them in the "Signature" field.

Email software could make this dead simple without requiring that the user
know anything about the web of trust, regardless of how complicated PGP is
under the hood. For most users, even webmail users, this would be good enough.

~~~
rakoo
That is exactly what autocrypt
([https://autocrypt.org/](https://autocrypt.org/)) aims to do: define a
protocol to effortlessly encrypt back and forth with no input from the user

------
alexis_fr
Also, by guaranteeing we’re the source, it only makes us more liable for what
is written. If I say something that reads like a commitment, or get upset, or
tell a mistake, there’s always a chance of benefiting from a loophole during
trial; if it was digitally signed, no escape.

The best interest of companies and individuals is that others send them signed
mail, and that they send non-signed mail... I think that doesn’t help at all.

It’s different from signing a website, because one is way more self-conscious
when putting informations on a website.

~~~
pferde
Sorry, but that's nonsense. The Received headers in an e-mail can already
guarantee that your company is the source.

------
z3t4
E-mail is transitioning to web based central/closed services. For example in
Sweden - government do not send e-mail, instead they use a private proprietary
service that require an Android or iPhone for second factor access, as an
alternative to snail mail.

So if you want to keep messaging decentralized, open and standardized, instead
of just complaining, we need to try out things like e-mail signing. In order
to improve we need to _feel_ the pain points and engineer them away.

------
pw6hv
I was so surprised when I received a signed email by Postfinance, my bank here
in Switzerland.

I really think it would be very beneficial if all major providers would start
to use that. At first not many people would check the signature, but if then
this takes momentum probably all major email provider will start to show an
icon telling that the email is signed and verified. Just like Gmail shows when
an email was received through a secure channel (TLS).

------
gudok
Maybe it is because major email services already do good enough job of
filtering spam/phishing emails?

And yes, we already have DKIM.

~~~
Carpetsmoker
(I am the author of this article, looks like someone posted it here before I
got the chance)

If they were, phishing would be a thing of the past; but it's not. In addition
it's a lot harder to filter out targeted spear phishing with spam filters.

Spam filtering is certainly useful – as are other measures such as the
malicious website list that most browsers have – but it seems to me that
adding _extra_ guarantees such as signing would be a good thing?

DKIM is useful, but also limited. It just detects forgeries of From address
and such. Ideally email signing should be like https: if it's not https then
you shouldn't trust it. DKIM can perhaps fill this role; but the current
implementations don't; they just add some score to the spam-check.

~~~
evgen
You are begging the question by assuming that a signature on an email message
proves anything useful to the recipient when the facts on the ground show this
not to be the case.

It is not harder to conduct phishing with email signatures, and the fact that
such phishing campaigns have no problem putting TLS certs on their phishing
sites is a simple existence proof of this fact.

Email signatures does not impact spam in any significant manner beyond
existing measures to prevent domain name forgery in the header. Spam email
signed by joe@cheap-ray-bans.com does not stop being spam because it is signed
and the signature provides no useful signal to spam filtering tools.

The difference between an email signature and a TLS cert on a web site is that
in the latter case the user is making an effort to connect to a specific site
and the certificate ensures that they are in fact connecting to paypaaaaal.com
even if other means were used to misdirect them to this site. With email there
are two problems to be addressed, transport privacy/security (a sender
problem) and unsolicited email (a recipient problem) and signatures are only
useful in ensuring integrity of the former and do nothing for the latter.

------
Zanni
Okay, this may be off-topic, but I think the specific problem mentioned in the
article would be much more easily solved by Queensland University of
Technology providing context for the gift--which is already expected email
etiquette. No need for a massive overhaul to email infrastructure. ("Off-
topic" because the anecdote is a pretext for discussing signing email.)

I once had a similar experience in real-life. I received a check via express
mail with no accompanying letter or explanation, which seemed like it _had_ to
be bogus. Mindful of cashier check scams, I took it to my bank to see if it
was safe to cash, and they erred on the side of caution and said, "no." But it
was $600, so I cashed it anyway. And then about a month later, remembered I
had closed out a poker account for that same amount.

I'm all for security, but can we start with common courtesy?

------
pmontra
The post is about signing, but the same applies to encryption:

> "This is not comprehensible to the ordinary person."

Too many moving parts, but there could be a solution. Unfortunately it's not
going to happen.

The solution is that the few big webmail providers start setting up end to end
encryption using any open standard. It must be the same zero configuration
stuff that worked for WhatsApp which every grandpa and grandma use. If they
start doing it for messages sent between their addresses, the world will
follow.

Unfortunately this means that it must be done in the browser and the webmail
provider can't see anything of the content. I don't think Google wants to see
this happen even if they own the most used browser.

------
upofadown
A lot of the things people suggest as replacements for SMTP could be done with
SMTP if email signing became standard. You could have closed message groups
where you only have emails from people you have corresponded with before. So
you could have a family INBOX, a company INBOX and a friends INBOX. Getting
added to a particular INBOX would involve some communication out of band. This
could be done in a very intuitive way. People would have no problem
understanding the concept of a private INBOX.

It would totally allow man in the middle attacks but spammers/scammers
generally can not do such attacks and would not have any financial incentive
anyway.

------
spicytunacone
I'm guilty of not signing my emails despite associating some accounts with my
key. A fear I have is signing but the receiver, even someone in the general
tech field, not understanding the surrounding text/attachments and dismissing
my mail. I wonder if that's part of why these large orgs don't sign.

I do agree with other comments that if big clients like Gmail abstracted PGP
signing nicely for their users, it would put more pressure for organizations
to publish public keys and sign lest the people they try to reach complain
that Gmail gives them a nice big warning each time they try to open one of
their emails.

------
aidenn0
It always surprised me that, back in the heydey of spam, few (if any) mailing
lists required signatures for e-mails sent.

Most of them were subscriber-only lists, and many were targeted at a highly
technical audience, new subscribers were rare, and spam was not particularly
targeted.

I'm not sure how many person-hours per week was spent by moderators hand-
filtering spam, and it definitely increased the delay for posts to appear.

It doesn't make as much sense today with DKIM and friends, automated spam
filtering, plus the general volume of spam is lower, but seemed like such a
big win back then.

------
joshfraser
My company has been a frequent target of phishing attacks. Setting up the
strictest possible SPF, DKIM and DMARC records and then reminding everyone to
always verify the domain matches goes a really long way to keeping people
safe. It might not be as perfect as end-to-end PGP, but it's available today &
supported in almost all of the major email clients. If you haven't set up
DMARC yet, it's a good place to start as it stops scammers from being able to
spoof emails and make them look like they came from your domain.

~~~
pard68
We, organization I work for, gave up on managing our own email. We pay
Microsoft to do it. Their automated phishing detection is phenomenal. Maybe
two or three emails slip through a quarter, down from dozens a month.

We had so many because our user base gets an email address which expands the
email base from employees to employees + customers, so 10k to 150k+ and once
someone fell for the scam it would get resent from their address which looks
much more convincing.

------
MagicPropmaker
At first thought, you'd think: All that would be needed to make this happen
would be for gmail, outlook mail, and Apple's clients to support signed and/or
encrypted mail and display a logo if the digital signature matches, say, a
signature in your contacts.

But spammers would probably just throw a "signed" or "verified" logo or text
at the bottom of the mail and fool or confuse most people into trusting an
email they shouldn't trust.

------
Tepix
We need free S/MIME certificates with decent validity periods (remember, you
have to keep around all certificates you've ever used!).

Webmail (which a lot of people use) is also not ideal for dealing with
certicates. You more or less have to trust the mail provider with your private
keys. There are just countless attack vectors.

Finally, it's quite technical to get a certificate, copy it to all your
devices that have an email client and configure them.

~~~
Carpetsmoker
I am not intimately familiar with the finances of PayPal, Google, Facebook, or
Amazon.com, but I suspect they may be able to afford an S/MIME certificate.
Perhaps even two or three!

> Webmail (which a lot of people use) is also not ideal for dealing with
> certicates. You more or less have to trust the mail provider with your
> private keys. There are just countless attack vectors.

You are _already_ trusting the email provider with _everything_. What's so bad
with trusting them to verify a signature, too?

We're not communicating state secrets over encrypted email here; we're just
verifying the signature on "PayPal sent you a message, click here to view
it"-kind of emails.

~~~
rebuilder
But the signature doesn't tell you the sender is the org they claim to be,
because how would the verification system know who the sender says they are?

------
mcculley
I have been using S/MIME for over a decade. I used PGP a long time ago, but it
was way too much to expect others to use. Now that S/MIME is built into major
MUAs, it makes more sense.

But one problem I have run into recently is that some correspondents complain
that the attached smime.p7s file causes their system to mark my messages as
spam. It has made me reconsider using it.

------
writepub
One reason is a trusted PKI. Even if an email is signed, how does one verify
the ownership of the key? I hope certificate authorities aren't the answer
here, we've all seen how that worked for the web.

This is where a PKI on a blockchain makes sense.

Product Pitch: Signed emails, with inbuilt verification of key ownership,
backed by a PKI on the blockchain

~~~
dcbadacd
Estonia provides everyone a smartcard with a per-person certificates on it,
those could absolutely be used to exchange encrypted e-mails in general, but
the reason they aren't is because e-mail clients do not support it, there
isn't a single e-mail client that comes even remotely close to that
functionality. People resort to encrypted containers ASICE and attach those.

------
no_gravity
One reason is that SPF already accomplishes good enough sender identification
without any hassle on the user side.

When you get an email from joe@example.com and example.com is trustworthy and
uses SPF, then you know that the sender in fact was joe@example.com

It's easy enough to set up SPF for any domain.

Gmail, Yahoo, Outlook etc all use it.

~~~
Carpetsmoker
SPF can be a massive hassle since it's based on which server is sending
emails, rather than which organisation is sending emails. Change some server
and your SPF breaks. In a large organisations there can be a bunch of
different ways of sending emails (main app uses SendGrid, marketing team uses
SureyMonkey, some 3rdparty tool uses something else, etc.) In practice, I see
administrators get SPF wrong all the time, which is why it's rare to see a
hard-reject policy.

In addition, the limitations of DKIM also apply to SPF:

> DKIM is useful, but limited. All it does is verify that an email which
> claims to be from paypal.com is really from paypal.com. What it lacks is the
> ability to show warnings such as “this email wasn’t signed, do you want to
> trust it?” and “this signature isn’t recognized, yikes!”

~~~
jhasse
> What it lacks is the ability to show warnings such as “this email wasn’t
> signed, do you want to trust it?” and “this signature isn’t recognized,
> yikes!”

Such a warning already exists: [https://lifehacker.com/stop-looking-like-a-
phisher-in-gmail-...](https://lifehacker.com/stop-looking-like-a-phisher-in-
gmail-5875549)

------
TomK32
I do PGP sign my emails but not the mails that my little web app sends out. I
should try that and see how users do react.

How's the state at the receiving side? I mean what percentage of users would
be displayed a message about the PGP signature being valid despite them
neither using nor knowing about PGP?

~~~
Carpetsmoker
I don't think there are many clients which support PGP out-of-the-box. The
state of S/MIME is better though; I believe many desktop email clients already
support it by default.

Still, more work needs to be done. It's a bit of a catch-22: no one is signing
their emails because client support isn't that good, and client support isn't
improving because no one is signing emails.

------
LoSboccacc
Because it adds nothing. Unless both part exchange their keys securely and
both parties store the keys securely you are just delegating identification to
a different infrastructure with no indication of it being more secure but with
an added false sense of security with is even more dangerous.

~~~
ricardobeat
Yet this is exactly how SSL security is implemented.

Speaking of that, couldn’t companies use their existing domain certificate to
sign emails?

~~~
jcranmer
No. You need a CA certificate that is authorized to sign email certificates to
sign the email certificate that signs emails. The domain certificate is merely
authorized for the SSL connection itself, and the CA that signs it likely
doesn't have trust bits for email either.

------
elcomet
Maybe one reason is because it is a hassle to check the signature of someone
you didn't have already in your contact list ?

How do you know it's not a fake signature ? Certainly you have to look at
their website and find the key. But what if this person doesn't have a website
?

~~~
Carpetsmoker
for S/MIME you don't need this; it's just a CA chain like HTTPS (for better or
worse).

For PGP I mentioned some possible options:

> PGP could also be used; we can bypass much of the key exchange dilemma by
> just shipping email clients with keys for large organisations (PayPal,
> Google, etc.); like browsers do with some certificates. Or publish the keys
> on a DNS record. Even just publishing them on your website (or, if you’re a
> bank, in local branches etc.) so people can manually add them to their
> keyrings is a lot better than not signing anything at all!

------
mrgreenfur
In lieu of signing, shouldn't links in emails be disabled wholesale at the
enterprise/organization level? If we can't prove who it comes from, then you
shouldn't click on it, end of story.

------
thunn
I know this is just a spam email, but Queensland University of Technology
(QUT) is different from University of Queensland.

I hope you can adjust the names in your post! I have some University pride
even if it is just spam

~~~
iamben
It wasn't spam... That was the point of the article?

------
runn1ng
Isn't this solved by DKIM, which at least GMail sort-of supports?

~~~
cbg0
That only establishes that an e-mail sent from john@example.com was authorized
for sending by example.com.

~~~
jhasse
And if example.com is a decent email provider, this also proves that it was
sent by john, because otherwise the SMTP server wouldn't sign the outgoing
email with a wrong login.

------
e1ghtSpace
Weird, the email says Queensland University of Technology but the author talks
about The University of Queensland. Two different universities but they are
close (physically) to each other.

------
dcbadacd
I wish Microsoft released the patents protecting SPFv2, it could help against
quite a lot of spam but it can't be implemented by GPLv3 software, it's a
pity.

------
edoo
I always thought the best webmail would be one that uses PGP in purely browser
side javascript with an open source 3rd party library, or you can disable that
and do it manually if you are still worried. The fact gmail never integrated
PGP shows what a fraud google is.

------
Labo333
I think
[https://en.m.wikipedia.org/wiki/DMARC](https://en.m.wikipedia.org/wiki/DMARC)
is meant for that. Of course it relies on trusted DNS.

------
dchest
[https://xkcd.com/1181/](https://xkcd.com/1181/)

------
nicky0
FWIW Facebook will not only sign but encrypt its emails sent to you using your
PGP key.

------
e1ghtSpace
Lol, Queensland University of Technology and The University of Queensland are
two different universities.

