File: HACKING.DKIM

package info (click to toggle)
libmail-dkim-perl 0.19-3
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 308 kB
  • ctags: 180
  • sloc: perl: 2,370; makefile: 45
file content (93 lines) | stat: -rw-r--r-- 3,462 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
Here is a list of components of Mail::DKIM, and the parts of the DKIM spec.
they implement:

http://mipassoc.org/dkim/specs/draft-allman-dkim-base-01.txt

  Canonicalization/DkimCommon.pm -- 5.4
  Canonicalization/simple.pm     -- 3.4.1 and 3.4.3
  Canonicalization/relaxed.pm    -- 3.4.2 and 3.4.4


http://mipassoc.org/mass/specs/draft-allman-dkim-base-00-10dc.html

  Algorithm/rsa_sha1.pm      -- 3.3.1
  Canonicalization/nowsp.pm  -- 3.4.2
  Signature.pm               -- 3.5
  Signer.pm                  -- 5
  Verifier.pm                -- 6

--

New version - update version numbers in these files:
  lib/Mail/DKIM.pm
  lib/Mail/DKIM/Verifier.pm
  lib/Mail/DKIM/Signer.pm
  README

--

New algorithm:
  create new algorithm class by copying and editing
    lib/Mail/DKIM/Algorithm/rsa_sha1.pm
  edit lib/Mail/DKIM/Common.pm:
    get_algorithm_class() - add a check for your new algorithm and return
      the name of your new algorithm class
    add a "use" line at the top of this file so that your algorithm class
      gets imported

--

How the Verifier Works:

First, the message headers are fed into the verifier object, where they
are stored into a buffer until all headers have been seen.

  message +----------+
  ------> | Verifier |
          +----------+

When the blank line separating the header from the body has been seen,
the verifier looks at the headers, and picks out the DKIM signature it
is going to verify. The signature specifies which algorithm and
canonicalization method the verifier should use. The verifier creates
an algorithm object. It also creates two canonicalizer objects and two
digest objects, one each for the header, and one each for the body.

Now the verifier feeds the message headers from its buffer into the
newly constructed algorithm object, which in turn feeds the headers into
the header canonicalizer, which canonicalizes the headers and feeds the
result into a Digest object, which will compute the SHA-1 or SHA-256
digest.

  +----------+         +-----------+     +---------+   can.  +--------+
  | Verifier | headers | Algorithm |     | Canoni- | headers | Header |
  |          | ------> |           | --> | calizer | ------> | Digest |
  +----------+         +-----------+     +---------+         +--------+

Now the verifier accepts the rest of the message (i.e. the body). The
body is not buffered in memory; it gets piped through the algorithm,
the body canonicalizer, and into the body digest.

  message +----------+   +-----------+   +---------+ can. +--------+
  body    | Verifier |   | Algorithm |   | Canoni- | body |  Body  |
  ------> |          | > |           | > | calizer | ---> | Digest |
          +----------+   +-----------+   +---------+      +--------+

Now the whole message has been read.

The DKIM signature, minus the contents of the b= tag, is fed into the
header canonicalizer, which gets fed into the header digest.

            modified DKIM +---------+  can.  +--------+
              signature   | Canoni- | header | Header |
            ------------> | calizer | -----> | Digest |
                          +---------+        +--------+

The header digest is computed, and the algorithm verifies it against
the value of the b= tag in the signature. If it fails to match, the
signature has "failed".

Next, the body digest is computed, and compared with that in the
signature. If it fails to match, the signature has "failed".

Otherwise, the signature has "passed".