-
Notifications
You must be signed in to change notification settings - Fork 57
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
dkim: Provide a low-level Verify function for more control #10
Comments
foxcpp
added a commit
to foxcpp/maddy
that referenced
this issue
Sep 18, 2019
See emersion/go-msgauth#10 for improvements that *should be* made to this initial implementation.
type VerifierOptions struct {
// if nil - net.LookupTXT is used, AD flag is used to indicate DNSSEC status which is then included into Verification struct.
LookupTXT func(domain string) (ad bool, txt []string, err error)
} |
emersion
pushed a commit
that referenced
this issue
Apr 29, 2020
Closing, not worth the effort. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Use-case
I'm thinking of ways to make maddys DKIM support work well and it needs quite a lot of control over verification process for that. Here is my experience report so far:
Non-cancelable network I/O done by dkim.Verify makes latter less useful. Also, it is done not using
custom DNS resolver implementation provided by maddy.
Currently I have to serialize header to bytes.Buffer and then pass it to dkim.Verify.
Allowing to pass already parsed header would be nice.
It is not that important, as I can keep non-parsed header blob around and pass it to dkim.Verify, thus eliminating one part of the problem and hoping other is not that significant.
Proposed solution(s)
Expose internal structures and separate operations such as: Parse DKIM key record, parse DKIM signature header, verify the signature using provided header subset and body reader.
With that I would simply pass DKIM-Signature fields to dkim.ParseField, then fetch keys using replaceable DNS resolver with context.Context support, let dkim.ParseKey parse them and then finally pass everything to the dkim.VerifySig to do the actual verification.
Even more: I can take the subset of fields required for signature and pass it to dkim.VerifySig instead of resorting to serialize-then-parse hack. That could be complicated though, so I guess being able to simply pass go-message/textproto.Header is better..
This way I even will be able to distinguish different failure types and act accordingly (e.g. increase the "quarantine score" for messages with broken signatures, immediately quarantine messages with a signature without a corresponding key in DNS, but only if this is not caused by a temporary resolution error).
... or ...
Tell me what you think. I am willing to help with the implementation of whatever solution you think is better.
The text was updated successfully, but these errors were encountered: