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