On Wed, 30 Jan 2008 14:46:56 -0000, Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
On Wed, Jan 30, 2008 at 11:18:08AM -0000, Charles Lindsey wrote:
On Tue, 29 Jan 2008 17:52:57 -0000, Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
<snip>
In any event, "on behalf of" is key wording that permits more
flexibility than you seem to be acknowledging. Note, for example,
that the agent specified in the Sender field is acting "on behalf of"
the author.
Is that agent authorized to work "on behalf of" the author?
That is what the person who actually sent it is claiming.
A well-organized 1st party signer will not sign anything that did not
originate within is domain, and containing a From/Sender within bis
domain.
Ah, I thought were were talking about the case where there isn't a
signature for the domain that is present in the From: header, but just
the Sender: header. Additionally the domains for those two headers
would be different.
Agreed. If the Sender domain was already one of the From domains, there is
no need to consider it further.
But suppose that there were 4 From addresses, from domains which published
no SSP. But for some reason the 4 authors had engaged someone from domain
E to Send it for them. Suppose E publishes a strict SSP. Then they are
going to sign it on the way out, and so it is a 1st party signature.
The verifier sees the valid signature and is puzzled because it does not
relate to any of the Froms; he looks for SSP, and there is none for those
Froms. Is it a 1st or 3rd party signature (for some reason he likes to
know which it is)? Then he looks closer and discovers that it was indeed
Sent from the domain that signed it, which has a strict SSP (plus a good
reputation). So maybe that makes him happier, especially if we provide a
mechanism in SSP for E to say "we sign Sender headers where appropriate".
So for sure we could build that into SSP if we wanted to.
I agree that I can't think of anything the Bad Guys might that do would be
spotted due to an unsigned Sender header, but you never know what Bad Guys
are going to dream up next :-( .
And note that this thread started with Dave asking what a Sender header
actually "meant", presumably with the intent of enquiring what mechanisms
we were providing that might increase confidence in that meaning.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html