Subject: [Asrg] Characterizing message categories

From: "John R Levine" <[email-masked]>
Date: 21 Apr 2006 09:11:58 -0400

It may be useful to categorize messages, which would need taxonomies of
categories.  The appropriate set of categories would probably depend on
what one planned to do with them, e.g., spam filtering vs. end user
filing.

Barry Leiba and Mark Delany expressed interest in this item.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Fri, 21 Apr 2006 11:40:13 -0500

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.

--
David L Nicol
Document what you do, then do what you documented

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Apr 2006 11:02:49 -0700

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: ...
>
> 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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Apr 2006 15:22:22 -0700

DKIM can list headers included within the signature, and  
architecturally this is a more extensible approach.  Adding a new  
header requires modifying the signing process to assure tagged source  
associations relate to this header, and to encompass that header  
within the signature.  A new header is one possibility.

Gleaning additional information from a key selection process should  
create a lower impact on the signing/verifying process.  For example,  
Key/Source association mechanisms may be in place to support the g=  
attributes that define the permitted local-parts, which already  
exists within the keys used by DKIM.  Being able to differentiate  
which tag belongs with a signature is also solved when incorporated  
at the key selector, rather than when using a new header.   
Establishing naming conventions for one of the labels within the key  
selector is a possibility beyond using a new header.

The down-side for using the key selector is a requirement to be  
frugal for key specific trust.  The up-side, from the aspect of  
building a database, is the requirement to be frugal where the key  
and tag can be evaluated together.  Perhaps only transactional and  
administrative tags would merit scrutiny, as such assessments are  
based upon content demanding additional resources.  The goal is to  
ignore a fair amount of the message traffic meriting little  
recognition.  Greater trust is possible when it is selective.

Messages annotation shown the recipient may increase their level of  
trust.  This trust may be desired when instructing recipients to  
click to some location, for example.  While an institution may want  
to assure their customers who know them by their domain name, this  
same domain name may also be used by poorly vetted users as well.   
Perhaps only those messages tagged as being administrative might  
receive elevated trust annotations, which would proactively prevent  
any mischief from those less vetted.  Only by way of these tags would  
a third-party application be able to discern which messages warrant  
elevated trust annotations. (Based upon assurance made by the signing- 
domain, and the reputation of that domain for this subset.)

-Doug