On Jan 19, 2008 4:15 PM, Douglas Otis <[EMAIL PROTECTED]> wrote: > > On Jan 18, 2008, at 11:53 PM, Frank Ellermann wrote: > > > Douglas Otis wrote: > > > >> There is a domain within the signature that should be used to > >> assess compliance. What prevents a valid signature of the From > >> domain from allowing a message to comply with "all" or "strict"? > > > > The most interesting case for SSP is "no signature". > > SSP should create compliance requirements for messages based upon From > header's domain(s). A "strict" or "all" compliance requirement > should be met with a signature that could be valid for the From email- > address's domain. The signature should not need to be "on-behalf-of" > the From email-address (as determined by the signatures i= parameter). > > IMHO there should be an exception for restricted keys, where these > signatures must be on-behalf-of the From email-address to fulfill a > compliance requirement of "all" or "strict". > > > For my unconvincing "toss a coin" list (Message-ID or first author > > or Reply-To) it's of course possible to add "use any signature for a > > domain in From addresses" to figure out a relevant domain for SSP. > > It should not matter which header a domain's signature is on-behalf- > of. DKIM is not about establishing an author's identity. The trust > being established is with the signing domain. The signing domain has > the option of using ambiguous signature (no i= or no local-part and > multiple email-addresses of their domain). IMHO, the signing domain > should be able to even use an opaque identity that does not associate > with any header. An opaque id could prove useful to protect someone's > privacy. A domain should be able to indicate they sign "all" without > conveying anything more than that it was signed by their domain. > > > But that only works if there is a corresponding DKIM signature, when > > it's not really necessary to test SSP. > > Just having a DKIM signature is not enough. Domains protected by DKIM > and an SSP assertion of "all" or "strict" must include a signature > from a domain that would be valid for the From email-address domain in > question. The DKIM WG seems unnecessarily focused on the on-behalf-of > feature of the DKIM signature. This feature _might_ enable an MUA to > highlight which identity the signature was on-behalf-of. There may be > cases where it is not possible for MUAs to establish which identity > the signature was on-behalf-of. In that case, just the signature > domain could be highlighted. Due to the possible on-behalf-of > uncertainty, DKIM signature notifications must be able to convey just > the domain of the signature. > > Although compliance for "all" or "strict" could be defined to require > an unambiguous on-behalf-of, such a requirement will make unambiguous > on-behalf-of less certain. The signing domain might then "falsify" > the on-behalf-of to meet an unambiguous on-behalf-of. Security > concerns are better met by not placing constraints on the types of > signatures used. There are also the issue of body length, and subject > lines where security might be impacted. The verifier/MUA can use the > information and display whatever they consider appropriate. One could > argue that excluding the subject line and including body length should > not be used as well. There is no reason to use SSP as a means to > constrain these parameters. > > > Or do I miss something obvious in your proposal ? We could pick > > John's proposal where Arvel's idea doesn't work, just look at all > > domains in From addresses, for legit mail it's rare. That needs > > some "SSP processing limits" for malicious mails (not as badly as > > for SPF). > > EAI might wish to allow two From email-addresses to permit alternative > formats. SSP could assert that messages containing more than two From > email-addresses are not complaint with "all" or "strict". This would > limit the number of policy search operations to two per message. > Except in cases of restricted keys, SSP compliance should not depend > upon which header the address is on-behalf-of. Ensuring an > unambiguous signature is within the control by the signing domain and > is independent of SSP compliance. MUAs are free to display > ambiguously signed, body length, and excluded subject line messages in > any manner they consider appropriate. There is no reason for the DKIM > WG to dictate how the on-behalf-of feature of the signature must be > used before a domain can assert their signing practices or policies. > Let the market decide. > > -Doug > >
I liken this ~entire~ argument to something as asinine as not selling right-handed golf clubs because there are a lot of left handed people out there. Fringe cases should be considered only as to whether or not we should add an asterisk to the suggested usage page. Regards, Damon S _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
