James Scott wrote:
Michael Thomas wrote:
I think we'd do better to just not conflate both of these
things. There are signers that are willing to assert "this
passed through me, for whatever that's worth", and "this
passed through me, and I have a relationship with one or more
of the outside addresses visible". The first is, essentially,
a signed received header. The second provides the originating
domain a way to provide some amount of comfort to the
receiver that it's that domain sending the mail rather than
some random forger. They solve two different problems, IMO,
and a domain may well be willing to provide the first, but
not the second.
Is the first scenario one that DKIM is intended to support?
At this point, I'm not entirely sure. I _think_ it's the
intent to support signatures which are not necessarily
associated with anything in the outside headers.
My understanding is that a signing party is vouching for the message. This
means that it is providing an assurance that the message contents, including
originating address fields, are authorised. If the signing party is
unwilling or unable to provide this assurance, then they should not apply a
signature. The receiving party can place a value on this assurance
depending on a variety of factors (relationship to originating address,
reputation, etc).
In general, I think that a signature is better than no
signature at all, even if it doesn't correspond to an outside
header. Perhaps what is needed here is a semantic in the i=
which unambigously says that "it came through me, but I make
no claim about outside headers." It seems that can be fairly
easily accomplished by setting i=(_at_)example(_dot_)com, that is, the
local part is null. This would cause the binding regex match
to fail. Further words might be needed to say that a origination
headers (From, Sender) being matched MUST have a non-null local
part, or it doesn't match.
Mike
_______________________________________________
ietf-dkim mailing list
http://dkim.org