Ticket #7 (assigned enhancement)

Opened 1 year ago

Last modified 2 weeks ago

Add support for S/MIME signed and encrypted messages.

Reported by: anonymous Owned by: amcgregor
Priority: low Milestone:
Component: extension-interface Version:
Keywords: Cc:

Change History

Changed 1 year ago by amcgregor

  • status changed from new to assigned
  • type changed from defect to enhancement
  • component changed from unassigned to message-class
  • milestone set to 2.1

Changed 1 year ago by felix.schwarz

I made a patch which adds the possibility to pass mails as plain strings to turbomail.enqueue. With that I can sign the mail outside of TurboMail and just send it through TurboMail.

Changed 1 year ago by fs

With the patch in #16 it is possible to create an S/MIME signed message in your application and pass it as string to TurboMail which is at least a workaround.

Changed 1 year ago by amcgregor

  • priority changed from normal to low
  • component changed from message-class to extension-interface
  • milestone changed from 2.1 to 3.0

Planned module for TurboMail-3.0, to be made available as a separate package, TurboMail-Security.

Changed 1 year ago by amcgregor

I figure the extension will work like this:

  1. The extension starts and overloads the turbomail.manager.deliver and turbomail.Message.__init__ methods.
  2. To the Message class it adds boolean signed and encrypted properties via the __init__ decorator.
  3. The deliver decorator, if encrypting, analyses the message recipients against some store of certificates.
    1. For each recipient with a certificate it creates a new, unique copy of the message and passes it to the original deliver method.
    2. Finally, it passes along a copy of the message with encrypted recipients removed.
    3. The original message is thrown away (never passed to the original deliver method.

Changed 1 year ago by amcgregor

The on-disk path to x.509 certificates will be stored in the configuration as keystore:

mail.smime.on = True
mail.smime.keystore = '/var/path/to/keys/'

Keys are chosen by a crafted filename based on the e-mail address of the sender or recipient, as appropriate. (Signing requires the sender's private key, encrypting requires each recipient's public key.)

Changed 1 year ago by amcgregor

(A GPG extension would be functionally identical to the S/MIME one, just using a GPG store rather than an x.509 one.)

Changed 1 year ago by amcgregor

S/MIME signatures are working as of r52. It's a bit of a hack (assuming the hashing method, etc.) and has some odd requirements for the x.509 certificate and key, but otherwise, it works.

Signature verification verified OK in Apple Mail 3.0. I'll leave encryption off 'till tomorrow, as I can't for the life of me figure out how to get a x.509 certificate out of Keychain Access.

Changed 2 weeks ago by amcgregor

  • milestone deleted
Note: See TracTickets for help on using tickets.