Rolf E. Sonneveld wrote:
On 5/5/11 1:52 AM, Hector Santos wrote:
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]
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)?.
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.
--
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