8

I run my own mail server and would like to use different addresses on the same domain. If I were to sign mails from those addresses, I'd have to generate new PGP keys for each and every one of them. This could become unmanageable very quickly.

As I understand it, DKIM signatures prevent the mail from being tampered with by other parties. Would it be possible / make sense to leverage DKIM for mail signing and just encrypt mail, skipping PGP signing? If it's possible, what assumptions would one have to make to reach comparable security? Would a DNSSEC secured domain be enough?

Improve this question

2 Answers 2

Reset to default
9

First, DKIM only gives you the assurance that:

a DNS administrator was involved in the process of signing this message.

That DKIM signature is intended for a reputation to be built with a "selector". A selector (signing key) is issued:

  • per user
  • per groups of users
  • per domain.

The granularity of that signing is undefined in the RFC and up to the DNS admin.

If you're OK with that flexible, possible anyone-can-sign assurance, then you are OK, but I'm not sure what that will give you.

Next, DKIM has three modes:

  • Full
  • Headers only
  • Partial signing (with the -L (length) parameter.)

The latter two means the encrypted content can be replaced in its entirety with another payload.

Unless you have a very strict implementation of DKIM, it's not a substitute for authenticating an end user (unless all you care about is the DNS name)

I spent time on the RFC working group but left in the late draft stage, so I'm 99% sure that this stuff is still true.

Improve this answer
0
4

PGP offers end-to-end encryption, your e-mail client signs the message, and the receiver's e-mail client verifies it. With DKIM, your mail server signs the message. The difference is that the message could be altered in transit while your client submits the message to the server. You can remove that risk by submitting the message using SMTPS or SMTP with STARTTLS. However, the receiver doesn't get the assurance that the message arrived directly from you, unaltered, because it's not end-to-end encryption.

Furthermore, with DKIM, it is the receiving server (MTA) who would verify the signature, not the receiving client (MUA). All that the client typically sees is an added header claiming that the receiving server was satisfied with the signature. An added header is not exactly a guarantee of authenticity.

In short, DKIM is designed as a means to verify that the message passed through a legitimate server. It's mainly a countermeasure for spam. It does not guarantee that the message originated from you.

Improve this answer
2
  • Thank you for the nice answer. So it's technically possible, but only if the sender trusts their server and assumes communications with that server to be secure. The whole idea is unfeasible because receivers usually have no (easy) way to check DKIM signatures and would hence have to place the same trust on their server as they'd place on their client machine. Did I get that right?
    – tarleb
    Oct 20, 2015 at 21:23
  • 1
    That is part of the problem. The receiver needs to trust the receiving server, assume that the message was not altered during submission, that the submission server authenticated the sender, that DNS is properly set up, etc. End-to-end encryption/signing is just so much more authoritative.
    – 200_success
    Oct 20, 2015 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .