DKIM support (signing & verfication) about maddy HOT 13 CLOSED

We can potentially use io.MultiWriter and io.Pipe for this (e.g. https://stackoverflow.com/questions/24677285/how-to-have-multiple-consumer-from-one-io-reader).

from maddy.

1. There will be nosig_action and brokensig_actions to override behavior on failures. Both will default to "ignore" since this is the way DKIM is meant to work by default.

2. DMARC policy of the sender domain overrides the local policy for failure handling.

3. Authentication-Result header field is always added. Its MUA responsibility to warn the user about invalid/missing DKIM signature.

from maddy.

emersion/go-msgauth#10

from maddy.

Verification:

1. Signatures with "body limit" tag are considered invalid by default.
2. DKIM relies DNSSEC to authenticate keys, resolution on emersion/go-msgauth#10 is needed so we can use DNSSEC-aware resolver with go-msgauth.

Signing:

1. Header fields should be "oversigned" by default to prevent all modifications.
2. Header fields to sign: everything visible for the user (Subject, To, CC, From, Date), everything that affects body handling (Content-Type, Content-Transfer-Encoding, possibly more), everything that affects user interactions (Reply-To).

Src: https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html

from maddy.

Signing is implemented in beef9e2.

from maddy.

Defaults

Verification is enabled by default for all incoming messages.
Signing is enabled by default for all outgoing messages. Keys are generated automatically and the public key is generated. DNS zone record for the public key is written to log.

New modules

dkim_verify module implements the Filter interface and does verification of message signatures.
dkim_sign module implements the Filter interface too but signs messages.

dkim_sign configuration

pub_key, priv_key directives with a path to keys, defaults to $MADDYSTATE/dkim_public_<config_block_name> and $MADDYSTATE/dkim_private_<config_block_name>.

If both files don't exist - keys are generated (algorithm to use by default? RSA-2048?) and saved (format to use for keys? probably we want to interoperate with OpenDKIM). If only one of the files exists - we refuse to start, this is a configuration error. If both files exist - we use keys from them.

We also probably want to add params to tweak key generation (algo? params?).

dkim_verify configuration

dkim_verify { invalid accept }

Insert Authentication-Result header and accept the message even if it contains invalid DKIM signature(s).

dkim_verify { invalid reject }

Reject messages with invalid DKIM signature(s). Default?

dkim_verify { required }

Reject messages without a DKIM signature.

dkim_verify { no-bounce }

Don't send bounce messages if DKIM verification fails for any reason.

from maddy.

Updated my post, there are some questions in bold, but in overall that's how I would design/implement it.

from maddy.

DNS zone record for the public key is written to log.

We should probably write it in a file. But that can be done as a second step.

RSA-2048?

Probably. It would be neat to use ECC, but I don't know how well this is supported.

format to use for keys?

PEM

Reject messages with invalid DKIM signature(s). Default?

Other e-mail servers quarantine. In my experience DKIM signatures still break a lot so we probably shouldn't be too harsh, at least at first.

(The DMARC policy of the sender can request to quarantine/bounce/… messages)

Don't send bounce messages if DKIM verification fails for any reason.

So the message is just lost in limbo? Or just reports are not sent?

from maddy.

DKIM also has things like selector and other parameters, we probably want to make them configurable

from maddy.

Probably. It would be neat to use ECC, but I don't know how well this is supported.

AFAIK, ECC is not supported by OpenDKIM (the most widespread implementation?) so we are out of luck here.

Other e-mail servers quarantine. In my experience DKIM signatures still break a lot so we probably shouldn't be too harsh, at least at first.

(The DMARC policy of the sender can request to quarantine/bounce/… messages)

Okay, so then the following set of values for the invalid option would make more sense: ignore/quarantine/reject. DMARC policy of the sender overrides the value set in the config.

ignore - accept, but still add Authentication-Results header

quarantine - accept, but set a marker in delivery context for broken signatures, so, IMAP storage will place the message into Spam mailbox, for example.

reject - refuse to accept the message.
Note: In the current design we don't send the bounce messages themselves and instead just don't accept messages that don't pass something. I wonder if this is a valid approach, but this is out-of-scope of this issue anyway.

from maddy.

go-msgauth/dkim buffers the whole message in memory if multiple signatures are present.
Per #76, we really want to avoid creating additional copies of message in memory.

from maddy.

We really should do the verification in parallel instead of buffering. Requires feeding data from a single io.Reader to multiple consumers in separate goroutines.

from maddy.

I will take a look.

from maddy.