Frank Ellermann wrote:
Jim Fenton wrote:
a message contrary to the published SSP, and it did its job.
I count this is a success.
"Working as designed" is a compelling argument. Let's use
Arvel's "Sender" proposal instead of renaming SSP to "FASP".
Please keep the revised "author" terminology, Arvel's idea
is for cases where "Sender" picks one of the author domains.
Off hand +1.
For cases where there exist multiple From: domains, using the Sender:
domain (assuming they could only be ONE domain for Sender:) as a
"helper" for the SSP domain discovery sounds feasible.
But it must be under the following conditions:
REQ-1: From: and Sender: are part of the DKIM binding process.
REQ-2: Sender domain IS within the list of From: domain(s).
What if these conditions are not met?
REQ-1:
First, From: is required to be part of the binding process. Sender: does
not to be bound by the signature. But when multiple From: domains are
used, then the SENDER: MUST be bound by the signature.
But the real issue is why there are NO real signatures. As it always
been, the issue of failed vs no real signature rears its ugly head.
In either case, the NO signature state SHOULD enforce requirement #2.
REQ-2:
The valid scenario for the SSP discovery is:
From: A, B, C
Sender: A|B|C <--- has one of these.
But when we have this:
From: A, B, C
Sender: D
Then there are a few design approaches:
1) Use the first From: domain -> A
2) Use the Sender: domain -> D
Obviously, there is only one TRUE server, regardless when there are
co-authors. So it probably makes sense to use Sender: IFF there are
non-matching co-authors.
--
Sincerely
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