Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signing only mode #12

Open
kinglok opened this issue Jan 7, 2014 · 1 comment
Open

Signing only mode #12

kinglok opened this issue Jan 7, 2014 · 1 comment

Comments

@kinglok
Copy link

kinglok commented Jan 7, 2014

I see gpg-mailgate is a viable and transparent for easy adaptation in using gpg for sending email.

Currently, does it supports choice of signing mode only?

Also, if the user have used gpg client tools to sign / encrypt his emails, will gpg-mailgate double sign / encrypt emails?

@uragit
Copy link
Contributor

uragit commented Jan 9, 2014

(This is not my branch but I figure I'll add a comment anyway because I'm also interested in this topic.)

Interesting question. For signing mode, which is not currently supported, gpg-mailgate would need to know the PRIVATE keys of the mail senders instead of encryption mode where it only needs to know the PUBLIC keys of recipients. This could be workable in the use case where an individual is running gpg-mailgate on a mail server dedicated to their own use but wouldn't really work for any other situation. (In fact, my mail server really is only for my personal email but I'd still rather keep my private key for use by my own account, rather than the mail system.)

In short, I don't see a good case for including a signing-only mode in gpg-mailgate. I'd rather leave this one up to the client-side tools.

(I'm hazy on the details for this part:) As to the second half of the question, unfortunately I don't think this is currently well supported by gpg-mailgate. There's a problem that the client signature will be for the original message and once gpg-mailgate has encrypted it, the client-side tools of the recipient may try applying the signature verification to the encrypted (ie changed from the original) message, causing signature verification to fail. Perhaps a more sophisticated mail client would do the right thing. Some hasty testing on my client (mutt on linux) shows that mutt isn't smart enough to figure it out, and may not even be reading the signature attachment correctly (or gpg-mailgate is processing the signature and body attachments differently than I'm expecting). I'd be curious to know if this works for others' setups.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants