-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles Lindsey
Sent: Thursday, January 31, 2008 9:16 AM
To: DKIM
Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to
posting by firstAuthor breaks email semantics
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.
By what mechanism do you know that the 4 authors (from addresses)
engaged someone from domain E? We currently have no way of knowing that
across domains other than the fact that the person from domain E claims
it.
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".
What about the cases where domain E has no reputation?
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.
Unless there is a mechanism for showing that Sender (from a domain other
than that of From) has been authorized to send on behalf of From then it
can only be considered an arbitrary assertion (that may or may not be
true) by sender. Upon reviewing RFC822 it is interesting to note in
section 4.4.2 2 use cases are indicated:
1) It is intended for use when the sender is not the author of the
message, or
2) to indicate who among a group of authors actually sent the message.
There is nothing that states that sender is authorized by the purported
authors unless it is case #2 where sender is one of the authors of the
message. Even case #2 provides no way of determining
authorization....only "indication" which is at best a weak thing to hang
ones hat on.
When we look at the examples given in A.2. ORIGINATOR ITEMS, we see
that none of the examples include an example where the sender is from a
different FQDN than the author.
If we look to RFC2822 for guidance we don't get much more help at all.
Although the example given in A.1.1. shows Sender and uses FQDN, both
From and Sender are within the same domain.
The only thing that can be gleaned from reviewing the RFCs is that if
there is a Sender field then that is the claim of origination. There is
no claim of authorization that is recognized within the RFCs that can be
meaningfully applied when the domain of Sender is not the same as the
domain of From. The RFCs do not preclude us from comparing From and
Sender fields to determine authorization. They simply don't discuss it.
That being the case, in the context of SSP, what makes sense? Which
"voice" do we consider? Where competing claims might be made are
reputation systems the only way to decide? Should the direct assertion
of the owner of a domain be considered authoritative for that domain?
In past discourse with Dave I have used the terms "spoofed" and forged"
to describe mail where an originator of email puts an email address in
the From field that is not within their domain. Dave was not happy with
applying those terms because of connotations that may not be applicable.
Dave suggested using the term "independent" to describe this situation.
My response was to suggest the following:
First Person: User of email address is sending through mail server of
domain of the email address.
Second Person: User of email address is sending through a mail server
not of the domain of the email address but is the specific initiator of
the email message. An example of this might be a person walking up to a
public internet kiosk and sending mail using their own email address but
the server of the kiosk provider.
Third Person: Third party (domain) is sending an email that uses the
email address of the user of the email address but the sent email was
not directly initiated and injected by the "user".
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html