Barry,
I think this might be a matter of definition for "validity." I was
not speaking of truthfulness, authentication or authorization. I am
stating that a valid DKIM signature is making a series of validity
statements or correctness assertions for the various parts it binds to
the signature. This really has nothing to do with whether the validity
statements are actually truthful and/or authorized to be used.
See inline:
Barry Leiba wrote:
>> No matter how many times it is stated and repeated, it will never be
>> true. If one wants this to be true, then remove the required binding
>> the Author Address, A.K.A 5322.From.
>
> No, not at all. While I think it was probably a mistake to make the
> signing of ANY header fields "MUST" (we should have just put "From" in
> with the other "SHOULD" fields), the fact that "From" MUST be signed
> says, in itself, nothing about the *validity* of the address (nor the
> display name) in that field. That's up to the signer.
And it can also be up to author domain to decide what a) signer domain
it will and b) what fields are hashed to create the DKIM signature and
implicit statements of validity for the parts the author decides to bind.
> It's all a question of what the signer is willing to sign.
And that could also be the author deciding who is the signer and what
parts are signed.
Part of the on-going "usual misunderstanding" contention is the
on-going attempts to separate the author from the picture when in
fact, the author may very well be:
1) the signer itself,
2) use a different signing domain owned by the author, and//or
3) authorized outsourced 3rd party signer.
I believe you are focused on the DKIM product implementation where the
"3rd Party" is the decider of what parts it binds to the signature.
I believe this market has been covered and IMO, 4871bis remolding
reflects what changes are necessary to cover this market.
However, the next frontier to increase DKIM adoption is to get private
domains to adopt DKIM and in this case, they will desire more control
over what is bound to the signature and what signer domain is used to
"represent them" for some out of scope reputation engines.
> I have two
> submission domains that I use. One, gmail.com, which does DKIM
> signing, will only allow me to use a "From" address after it has sent
> a test message to that address and seen that I can access the test
> message. So it's made *some* level of confirmation that I owned the
> address at the time I set it up. But there's no confirmation that I
> still own the address, and there's certainly no assessment of the
> display name that I associate with it. Gmail will sign mail that I
> send with my old IBM addresses in the "From", though I have not worked
> for IBM for over a year and a half, and no longer have any
> authorization from IBM to use those addresses.
>
> Is that "valid"?
I would suggest it is not valid from a "authorization" standpoint.
Nonetheless, from the purity of a DKIM signature, your old IBM address
would still be a statement of validity - to be authenticated at some
later date (future DKIM results analyzer layer) perhaps.
Small point of clarification. As far as I recall (last month), the
GMAIL 2nd account setup is:
- STARTTLS Test
- User ID/Password AUTH test
- Gmail does not DKIM sign these Smart Host setup path
So yes, it is possible to use a valid but "not authorized" 2nd account
setup. But your setup is still a "statement of validity."
I don't recall it testing the 2nd account as a MAIL FROM or RCPT TO.
Maybe it did, but note this is a feature for outbound mail, not
inbound. See note below regarding MAIL FROM checking.
> The other submission domain I sometimes use, which does not currently
> DKIM-sign, will let me put anything at all that I like in the "From"
> field, including, say, "presid...@whitehouse.gov". It doesn't check,
> and it doesn't care, as long as I'm connected to their network when I
> send the message.
Right, for most SMTP systems, the public port fundamental rule is:
- Anonymous (no authentication/authorization), allow mail for
local users only, i.e. no open relay
- Authenticated/Authorized, allow mail for local or remote.
So as long as you are Authenticated/Authorized, it will allow the
transaction to be accepted and for some, if not most, it will skip all
the "checks." For us, we skip the 821 level checks and leave the 822
checks to the operators.
For the private port (587), the submit protocol requires
authentication (login) and it also provides additional enforcement
rights to validate most or all parts of the transactions.
One pitfall we found regarding authenticated sessions is that it might
skip checking the MAIL FROM. The problem here is a non-delivery
bounce to no where. So for our system, an authenticated user MAIL
FROM is always checked against the local user database to make sure a
bounce is deliverable.
> They could start signing with DKIM tomorrow. If
> they did, would you then say that the "From" address in those messages
> is "valid"? I wouldn't. You might say, "Well, they shouldn't oughta
> do that." Maybe wise people would advise them not to. But maybe
> they're not wise. DKIM doesn't weigh in on that.
I will state that the DKIM process is making a series of statements of
validity for all the parts (which includes the 5322.From) it hashes
and binds to create and add a "purportedly" valid DKIM signature.
When the DKIM verifier reproduces a valid signature from the bound
parts, this is implicitly making a series of validity statements for
these parts, including 5322.From.
It is only a higher layer, i.e., POLICY and/or the out of scope
reputation engines which take two different DKIM validated input feeds:
POLICY_RESULT = POLICY(Author-Domain)
REPUTATION_RESULT = REPUTATION(Signer-Domain)
that can do any "truth" or DKIM validity confidence related concept.
> The fact is that probably 99% of their users just use the proper
> domain in their "From" fields, and it doesn't matter. The fact, for
> John Levine's domains, is that he knows and trusts his users, so he
> lets them do what he wants. Now, if his signing domain started
> developing a bad reputation because some of his users were sending
> mail as "whitehouse.gov" or whatever, he might change his policy. As
> might my service provider, if they started signing and saw their
> domain's reputation go south.
I was not speaking of the invalid or unexpected or authorized usage. I
am saying that what DKIM binds and signs are all parts of its validity
claims.
> But that's all outside the scope of DKIM. DKIM only provides
> assurance of the *signing* domain, and that the message has arrived
> substantially unchanged from when it was signed (modulo h= and c=).
And IMO, these are statements of validity, and it doesn't imply they
are actually true.
The point is that even if you wish to just use one side of the
(market) coin where the signer is independent of the authors with a
blind unrestricted signing practice, and your intent is to use the
signing domain for some high layer evaluation, the validity of its
bound parts MAY BE part or in whole of the "total assurance" the DKIM
valid message wishes to provide, not just that of the signer
information, but that of the authors as well.
What is not being taking into account is that the author is still a
fundamental essential part of the message and it is these DKIM
adopters who will decide not only what fields are hashed and bound to
the signature, but also what domain will be used for the signer (d=).
My nit is one of a technical sales pov.
One group is only focusing on a signer domain to satisfy
some out of scope design goals and continues to water down
the validity of the From that is required to be hashed bound
to a VALID DKIM signature.
Another group, and I believe one that most people will "better"
understand is that DKIM will help protect the validity of the
author address.
To help increase DKIM adoption, IMO we should not water down the
inherent DKIM statement of validity for the hash bound 5322.From which
is another way of saying that there is a market of originating domains
that decide what is signed and what signer domain will be used to
represent them in some future out of scope reputation or currently
possible VBR feeds.
--
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
