On Apr 21, 2006, at 9:40 AM, David Nicol wrote:
The consensus of the tagging committee was that categories should
be left unspecified as part of the technical specification of a
tagging infrasturcture, with a tag registry maintained externally,
and a standard for experimental tags within the standard tagging
system. So when you are experimenting with a new classification
Foo, your tag would look like
Is-X-Foo: ...
instead of
X-Is-Foo: ...
and after the Foo classification is properly registered, software
would upgrade to
Is-Foo: ...
The points of contention in the tagging committee were over
agreement on one technique for discouraging forgery.
I refer the reader to my earlier draft of a tagging protocol
including a practical forgery discouragement method sent to this
mailing list. Given a sudden shower of tuits I may reformat it in
RFC form but no such event is expected in the next couple months.
I think interests related to DKIM may pertain more to a sender
tagging scheme, with an additional desire related to trust
annotations provided recipients. This can overlap with that of a
receiver tagging scheme however.
Within a given domain, not all messages may be as trustworthy,
although DKIM verifies the signing domain. Rather than establishing
a plethora of sub-domains to establish separate levels of trust (and
that ironically may play into the hands of phishers which DKIM
intends to thwart), a tag contained within the key and encompassed by
the signature, or perhaps a convention for naming the key selector
could convey these different levels of trust.
Use of the key selector offers a greater level of security with
little disruption, as this information is already signed. The s=
selector is part of the DKIM signature and is protected by the
signature.
A convention might be possible where either the right-most or left-
most label of the s= selector could begin with an '_t-' where the
information following this could be used to distinguish separate
categories of email with different levels of trust. Perhaps
"s=jan-06._t-trn" would indicate transactional mail from that domain.
The size of the tags should be kept small, as this consumes DNS
response payloads. Perhaps the convention could limit these tags to
3 characters for a 9 byte increase in DNS payload.
For example:
_t-trn Transactional
_t-adm Administrative
_t-sol Solicitation
_t-mat Mature content
_t-usr Domain User
_t-gst Domain Guest
_t-mdn Mailer-Daemon
_t-sys System
_t-unk Unknown status
A message annotation may decide to include a subset of these
categories, where trust reputations of each could be treated within
subsets separately.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg