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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Michael Thomas
Sent: Fri 1/25/2008 6:55 PM
To: John Levine
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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