On Tue, 04 Sep 2007 23:16:57 +0100, Murray S. Kucherawy <msk(_at_)sendmail(_dot_)com>
wrote:
draft-kucherawy-sender-auth-header-06
2.1. General Description
The decommented value of the header field consists of an
^^^^^^^^^^^
documented
authentication identifier, some whitespace, a "property=value"
^^^^^^^^^^^^^^^
is that whitespace oblgatory? because the ABNF suggests otherwise.
2.2. Formal Definition
Formally, the header field is specified as follows:
header = "Authentication-Results:" [CFWS] authres-id
*([CFWS] ";" methodspec propspec )
authres-id = dot-atom-text
; see below for a description of this element;
; "dot-atom-text" is defined in section 3.2.4 of [MAIL]
methodspec = [CFWS] method [CFWS] "=" [CFWS] result [CFWS]
; indicates which authentication method was evaluated
propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" value
; an indication of which property of the message
; was evaluated by the authentication scheme being
; applied to yield the reported result
Should we allow for the possibility of more than one <propspec>?
For example:
dkim=pass header(_dot_)i=sender(_at_)example(_dot_)com
header.t=1189079141
3.1. Header Position and Interpretation
Furthermore, an MUA SHOULD NOT interpret this header field unless the
hostname it bears appears to be one within its own trust domain as
configured by the user.
AND FURTHER ON:
4.1. Removing The Header
As specified in Section 3, instances of this header field added by
outside MTAs that appear to come from inside an MTA's trust boundary
must be removed. In the case of messages signed using [DKIM] or
other message signing methods that sign headers, this may invalidate
one or more signature on the message if they included the header
field to be removed at the time of signing. This behaviour is
desirable since there's no value in validating the signature on a
message with forged headers. However, signing agents MAY elect to
omit these header fields from signing to avoid this situation.
I don't think that is right.
A message may pass through half a dozen agents that
redirect/forward/resend/mail-list-expand it, picking up assorted
signatures and Authentication-Results on the way, and maybe causing
earlier signatures to fail so that later agents can no longer verify them.
Moreover, in a sufficiently complicated situation (mailing lists
subscribed to other mailing lists, for example), it may well pass through
the same trust boundary twice.
The way to make sense of this is for agents that change things so that
signatures fail to add an Authentication-Results to show that the message
was OK when received by them, and then to add a new signature which
covers, in its h= tag, the Authentication-Results it has just added. So
you get something like:
Authentication-Results: example.com
dkim=pass (good signature)
header(_dot_)i=(_at_)list-expander(_dot_)example(_dot_)com
Received: .........
Received: .........
Received: .........
Dkim-Signature: ...... d=example.com; i=list-expander.example.com;
h=...:Authentication-Results:...; ...
Authentication-Results: example.com
dkim=pass (good signature) header(_dot_)i=(_at_)sending(_dot_)domain
Received: by list-expander.example.com ...........
Received: .........
Received: .........
Received: .........
Dkim-Signature: ........... d=sending.domain ..........
Just to be awkward, I have made the two Authentications to within the same
trust boundary, but it need not be so. The various Received:s could have
been added anywhere.
So clearly an MUA should look at the top Authentication-Results: first,
and then at the lower ones, believing them or not as he sees fit. But in
this case, it is clear that the lower Authentication-Results: is as valid
as the first, and example.com should clearly leave it in place (contrary
to what you have written in 4.1). Example.com may also have tried (and
failed, because the list-expander had broken it) to verify the lower
signature), and might even have recorded that as a dkim=fail.
But, in the usual case where the two authentications were done in
different trust zones, we could usefully have some additional feature so
that (supposing the earlier authentication had been done by
list-expander.example.NET) example.com you have added something to say
that it believed the first Authentication. So perhaps example.com could
have added something like:
Authentication-Results: example.com
indirect=pass (verified earlier)
header.auth=example.NET header(_dot_)i=(_at_)sending(_dot_)domain
6.2. Method Registry
As stated above, names of message authentication methods supported by
this specification must be registered with IANA, with the exception
of experimental names as described above.
Each method must register a name, the specification that defines it,
one or more "ptype" values appropriate for use with that method, and
which "property" value(s) should be reported by that method.
The initial set of entries in this registry is as follows:
+------------+---------+--------+----------------------------------+
| Method | defined | ptype | property |
+------------+---------+--------+----------------------------------+
| auth | RFC2554 | smtp | auth |
+------------+---------+--------+----------------------------------+
| dkim | RFC4871 | header | value of signature "i" tag |
+------------+---------+--------+----------------------------------+
I think we need to allow for the possibility of tags other than 'i' (or in
addition to 'i' as suggested earlier).
| domainkeys | RFC4870 | header | From or Sender |
+------------+---------+--------+----------------------------------+
| senderid | RFC4406 | header | name of header field used by PRA |
| | | smtp | from (envelope sender) |
+------------+---------+--------+----------------------------------+
| spf | RFC4408 | smtp | from |
+------------+---------+--------+----------------------------------+
C.3. Service provided, authentication done
A message that was delivered by an MTA that conforms to this standard
and applied some message authentication:
Authentication-Results: mail-router.example.com;
spf=pass smtp(_dot_)mail=sender(_at_)example(_dot_)com
From: sender(_at_)example(_dot_)net
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.128.1])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver(_at_)example(_dot_)com
Message-Id: <12345(_dot_)abc(_at_)example(_dot_)net>
Subject: here's a sample
Hello! Goodbye!
Example 3: Header reporting results
Those headers seem to be in a funny order. Why is that From: in the midst
of the Trace headers?
C.5. Service provided, several authentications done, different MTAs
A message that was relayed inbound by two different MTAs that conform
to this specification and applied multiple message authentication
checks:
Authentication-Results: auth-checker.example.com;
sender-id=fail
header(_dot_)from=sender(_at_)example(_dot_)com;
dkim=pass (good signature)
header(_dot_)i=sender(_at_)example(_dot_)com
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by auth-checker.example.com (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
Authentication-Results: mail-router.example.com;
auth=pass (cram-md5)
smtp(_dot_)mail=sender(_at_)example(_dot_)com;
spf=fail smtp(_dot_)mail=sender(_at_)example(_dot_)com
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.128.1])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
DKIM-Signature: a=rsa-sha1; s=gatsby; d=example.com;
c=simple; q=dns;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
That signature needs to show a plausible "h=" tag.
And finally, we need a really complicated example to show
Authentication-Results: headers that have themselves been signed by later
DKIM-Signatures, as I have outlined above.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html