[mail-vet-discuss] Draft as of 9/4/2007
Charles Lindsey
chl at clerew.man.ac.uk
Thu Sep 6 06:33:46 PDT 2007
On Tue, 04 Sep 2007 23:16:57 +0100, Murray S. Kucherawy <msk at sendmail.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.i=sender at example.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.i=@list-expander.example.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.i=@sending.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.i=@sending.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.mail=sender at example.com
> From: sender at example.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.com
> Message-Id: <12345.abc at example.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.from=sender at example.com;
> dkim=pass (good signature) header.i=sender at example.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.mail=sender at example.com;
> spf=fail smtp.mail=sender at example.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.man.ac.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
More information about the mail-vet-discuss
mailing list