At 15:16 04-09-2007, Murray S. Kucherawy wrote:
In Section 2.3, I suggest using engineering.example.net instead of
engineering.example.edu (RFC 2606).
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 |
+------------+---------+--------+----------------------------------+
| domainkeys | RFC4870 | header | From or Sender |
+------------+---------+--------+----------------------------------+
I'm not sure whether domainkeys should be included in there as it has
Historic status.
Appendix B. Legacy MUAs
Implementors of this proposal should be aware that many MUAs are
unlikely to be retrofit to support the new header field and its
semantics. In the interests of convenience and quicker adaptation, a
delivery MTA might want to consider adding things that are processed
by existing MUAs in addition to the Authentication-Results header
field. One suggestion is to include a Priority: header field, on
messages that don't already have such a header field, containing a
value that reflects the strength of the authentication that was
accomplished, e.g. "low" for weak or no authentication, "normal" or
"high" for good or strong authentication.
I understand the rationale behind this paragraph. It attempts to
solve the Legacy MUA issue. However, the proposal redefines a header
already defined in the Mail Headers registry for a particular purpose.
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])
I suggest changing the 192.0.128.1 to 192.0.2.1 (RFC 3330).
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])
I suggest 192.0.2.200 here.
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Tue, 04 Sep 2007 20:49:22 -0700
DKIM-Signature: a=rsa-sha1; s=gatsby; d=example.com;
c=simple; q=dns;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
To be in line with the DKIM RFC:
Tue, 04 Sep 2007 20:49:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=gatsby;
t=1188964191; x=1189050591; bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70
Cuhw29g=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References:
Mime-Version:Content-Type;b=3ZAJzvgX4CaV7T4BLzKIwz66QyFF+/fKdq4GNM8Rwd
Ub/2pcQ4GL0nAOCOSxFvCpnPdFW37B/aiv4wXLDRMJeiehratWdrbV3z70WQBKo1/dY5XI
XQ3veVVJDRzkNSfQ9h2ILd34R/+8kMp403d1DHt5A6iDdjH1a13AoUnjEpA=
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html