Subject: [ietf-dkim] Issue: Section 3.9 - Add AUID and ODID

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 19:52:28 -0400

>> Murray wrote:
>> You want AUID and RFC5322.From added to the Output Requirements 
>> section explicitly.  

BTW, while RFC5322.From will satisfy requirements, I am proposing a 
new ODID identity (RFC5322.From.domain) since that is whats already 
extracted by APIs in order to do the current ADSP support.

I proposes the following:

3.x  Originating Domain Identity (ODID)

    The ODID is the domain part of the From: address.  This identity
    MAY be considered as an output communicated to an advanced
    Identity Assessor module.

       INFORMATIVE IMPLEMENTATION NOTE:

       The ODID and SDID are inputs for the optional
       Checking Signing Practices component as described
       in the DKIM Service Architecture [RFC5585]

3.9.  Output Requirements

    For each signature that verifies successfully or produces a TEMPFAIL
    result, the output of a DKIM verifier module MUST include the set of:

    o  The domain name, taken from the "d=" signature tag; and

    o  The result of the verification attempt for that signature.

|  Optional output are:
|
|  o  The Agent or User Identity (AUID) taken from "i=", if any.
|
|  o  The Originating Domain Identity (ODID). Verifier output
|     MAY consider ODID when no signatures or invalid signatures
|     are found.

    The output MAY include other signature properties or result meta-
    data, including PERMFAILed or otherwise ignored signatures, for use
    by modules that consume those results.

    See Section 6.1 for discussion of signature validation result codes.

You might be able to figure out better text.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 05 May 2011 12:01:23 +0200

>      See Section 6.1 for discussion of signature validation result codes.

are you aware of the fact that 5322.From can consist of a mailbox-list 
as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From 
contains multiple 'mailboxes' (terminology of RFC5322)?.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 13:09:19 -0400

> contains multiple 'mailboxes' (terminology of RFC5322)?.

While technically possible, it is rare (more on this below).

It was worked out over the years to be either the first address or
each one is to be considered.

SSP described it as a potential DNS overhead and this is where the
first one was considered technically correct and for its rarity
factor.  Also limits can be placed.  I believe the consensus (as
reflected in ADSP) was to leave it technically open leaving it up to
the implementation

ADSP [RFC5617] has the following:

3.  Operation Overview

    ...... If a message has
    multiple Author Addresses, the ADSP lookups SHOULD be performed
    independently on each address.  This document does not address the
    process a host might use to combine the lookup results.

But keep in mind of the importance of End to End technical "vetting"
process beginning predominately at the Originating point.  I have
design, nor seen an MUA in my 29 years of mail system commercial
product development, which allows for multi-address From INPUT. That
is for good reason - mail hosting 99.99% of the time force only one
 From tied to the user account  And the exception is normally a system
that allow for manual From change such as in an anonymous mail system
- but its still only one.  One that allows for uncontrolled
multi-address From Input is already a BAD SYSTEM.

So the ODID payoff is just to consider the first address. I'm open
though to pass the RFC5322.From value and the only reason I didn't
suggest that is because it passes additional technical "subjective"
semantics such as user part considerations and all we wanted here as a
ADSP functionality.

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 12:52:52 -0400

SSP described it as a potential DNS overhead its and this is where the 
first one was considered technically correct and for its rarity 
factor.  Also limits can be placed.  I believe the consensus (as 
reflected in ADSP) was to leave it technically open leaving it up to 
the implementation

3.  Operation Overview

    ...... If a message has

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 14:46:34 -0400

> contains multiple 'mailboxes' (terminology of RFC5322)?.

A follow up,  in section 2.3, it has among Identity examples:

    - author
    - author's organization

If we wanted to be 100% Ideally RFC5322 correct, it should be

    - author or authors
    - an author's organization

Although it would be "technically" correct, I don't think it would be 
practically realistic to view or operate it in that way.  That is why 
the focus is really on a single author and its organization.

The one point I want to make, related to what another person 
considered the "unvetted" concept behind the originating author, in 
the history of BBS and mail hosting software, the user account is 
unique. Depending on the brand, the communicated "From" is generally 
offered based on the type of mail conference provided (or where he is 
posting mail).  Overall, the user namespace can contain identities 
such as:

    real name
    login identity
    alias name
    email address

For example if the mail type is related to:

   Networking   <- Mail.from = user.name|user.alias|user.alias
                   RFC5322.From = user.email
   Local        <- Mail.from = user.name|user.alias|user.alias

But it really depends on the host, for example you mail see in the UI 
(User Interface) when starting a new message that supports anonymity:

   From: <default name>   (o) Use default
                          (_) Use Alias
                          (_) Use Anonymous (if enabled)

Using anonymous is really rare and the history of using began with 
servicing the "Daddy Market" (Porn or Adult Mail) market.  What was 
important is that it wasn't tied to the user account like alias would 
be. Not the say it wasn't locally logged and traceable, that depended 
on how much the mail host wanted to provide user anonymity.

Of course, the "spam" problem started when we began networking mail 
hosting systems. So along with the good aspects, came the potentially 
bad.

But excluding the bad for a moment, it become of a "disjoint" problem 
- in other words, the social "personal community" which was 
predominately local, now was distributed.  In simple terms,  "Joe" was 
known in system ABC, but when networking started, "Joe" was not known 
in system XYZ.  We increasingly use an "email id" to login as well, 
but its all tied to "vetted" set of user identities.  Technically, the 
 From wasn't required to be identity for responses, as long as there 
was a Networking Address.  However, very importantly, it is the From 
that end users generally see.

So from a networking standpoint, there is technical explanation why 
the From can be viewed as "unvetted."

But that is where DKIM comes in:

DKIM still applies because the primary technical transport design 
presumption is end to end mail integrity and authenticity.  The point 
is; regardless of that the original "value" of the from, it is 
expected NOT to be altered.

ADSP is just about whether DKIM applies or not, but whether failure to 
authenticate is an important author's organization policy. Its not 
about the From can be unvetted even though the idea of "vetting" can 
be also be part of making sure the original message integrity is 
intact using DKIM.  It also comes a policy presumption that the 
Original From was "vetted" at the originating domain organization.

Whether you can TRUST the message *context* and/or who wrote it is the 
2nd party of the DKIM equation.

That is why we still need some sort of 3rd party trusted vouching 
feature as the final DKIM evaluation for the user sake.

For the mail host, the "TOS" (Term of Service) would essentially be:

      We will DKIM authenticate the message and we will also
      look at certain trusted signers to give you "TRUST" indicator.
      You may not know who or be associated with the author
      or even who is the trusted signer is, but if you TRUST
      US, then the message is not considered BAD.

Whether that "POLICY" or "MINDSET" holds, it is something the senders, 
especially Spammers, Marketers what the receiver to convey to users if 
DKIM is the technology or basis to do this.

So its all really up to the receiver market and my posting of late is 
100% a engineering reflection that focusing on a single TRUST factor 
only is seriously insufficient for receivers to consider solely.

The problem with the DMA vendors is that they believe that all mail 
should be accepted and like the user decide.  They really don't think 
about the security issues and thats why they always get bit and users 
get bit in the butt.  David Lewis, Chief Marketing Officer at Message 
Systems recognized this when he said in his blog:

   This is all about data security — something us marketers
   avoid thinking about, but now must because it has direct
   brand ramifications.

   (http://www.messagesystems.com/wordpress/?p=65)

His "Mission Statement" for marketers was to understand that RECEIVERS 
are a critical part of this trust and security framework when he outlined:

   The framework I see for addressing this challenge is threefold:

    1. Rally the industry and articulate data security/best
       practice guidelines

    2. Encourage companies to apply those guidelines within
       their own environments

    3. Provide a collaboration forum for companies to
       discuss common threats and share best security practices

   (http://www.messagesystems.com/wordpress/?p=69)

In short, trying to tell me (an implementator and receiver) that I 
should only

    a) Invest in time/resources for a complex DKIM integration,
    b) add computational cost, for an
    c) already highly exploited unknown spammer world,
    d) looking for the golden needle in the DKIM Hay Stack for valid mail,
    e) to check for a very small table of trust vendors for
    g) accepting and passing to users.

only perpetuates the overall "Trust" problem that David Lewis "Mission 
Statement" is describing.

We know one thing, whether it is RFC5322.From or ODID passed, it is an 
OUTPUT that MUST be part of the DKIM Service Architecture for receiver.

Ignore that fundamental idea is in my review protocol engineering neglect.

If there are other factors, that is also fine to know and 3.9 reflect 
that universally obvious view.   But I am talking about the specific 
things we know about that can be extracted from all the work that was 
done for DKIM, without any subjective thought, just purely on whats 
written, AUID and ODID (or RFC5322.From) should be part of receivers 
considerations as well as the SDID.