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.
When I pointed out that the "first from" rule enabled a trivial end
run around SSP, by using a real first address and a forged second
address that is likely to be visible in MUAs, I naively assumed that
it would be obvious to everyone that any rule other than checking all
the addresses would have the same hole, hence the fix is to check all
the From: addresses, and then move on to something else.
But no, we got endless nattering instead. This is not a subtle point,
and I share Steve Atkins' concern that a group of people who don't
understand the way that e-mail works can't design a working protocol.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html