I have been accused of writing code from time to time. SSP is a policy/practice statement. Coding this is a two step process get the value of SSP via a DNS lookup (the easy part) the writers of software will then integrate this result into their current software offering which will have rather wide latitude on what to do with the results, some more effectively than others. We don't want to break current best practices or open new attack vectors unless there is a compelling case to do so. Legacy systems dont/wont care about DKIM/SSP. Certain vendors dont want to have to spend a ton of cash to update their DNS products that have trouble handling new ideas because that is not a profitable company line item. So John's comments are applicable. As well as Hector's "technical" points. thanks, Bill
-----Original Message----- From: [EMAIL PROTECTED] on behalf of Michael Thomas Sent: Fri 1/25/2008 6:55 PM To: John Levine Cc: [email protected] Subject: Re: [ietf-dkim] Re: from'less 2822 messages John Levine wrote: >> Frank, you're (inadvertently?) bringing up exactly the kind of >> corner cases that I was trying to raise so that SSP implementations >> have the same behavior in their presence. It may be that all we >> practically need to do is refer to 2822 and say that if the From: >> field is missing, or if the header field body is missing, or if >> the domain part of the address spec is missing or not a datom(??), >> then the algorithm terminates and returns, oh say, "malformed" or >> something like that. >> > > Well, gee. What if there are two From: lines? Three From: lines? A > From: line with two addresses but no Sender:? A From: line with two > addresses, one of which has no @ sign? A From: line with a couple of > embedded carriage returns? The number of ways one can construct a > string of bytes that is not a 2822 message is limitless, and it's hard > to see any beneft in trying to enumerate them. If it's not a 2822 > message, SSP doesn't apply. > John, do you write code? The current draft is completely silent on this issue. It doesn't even say "SSP doesn't apply". Exception conditions are the classic places that different implementations do different things, including treating them as "suspicious" in the current draft's parlance which is almost certainly completely wrong. Nor do we have to fall prey to the strawman that we'd have to enumerate an infinite list. > But no, [self-important hectoring elided] > > > Mike > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
