On Feb 17, 2008, at 9:32 AM, Hector Santos wrote:
Douglas Otis wrote:
I really don't see why it matters from where it sent and how. Do
you have a preferred type of burglar knocking on your door? <g>
Many different doors could be helped by DKIM. While there might be
an expectation that those knocking at the front door will validate
their affiliation, there may be different expectations for those at
the back door. The difference might be as simply as not buying
wares from those at the back door. When someone escorts them to
the front door, they might be asked to validate their affiliation,
although likely unprepared to do so. While moving everyone to a
common doorway may seem ideal, this creates a significant problem
when the front door carries a greater obligation. Different doors
need different policies when there are different levels of trust
based upon the door used. At some distant point in the future,
perhaps all doors will be treated the same, but time has not arrived.
Doug,
That time came long ago.
Remember, this is predominately about anonymous vs non-anonymous
transactions and systems have always treaty anonymous and non-
anonymous transactions differently.
An anonymous back door is the last thing we want, although this
strongly appears what the ASP model is promoting. :-)
DKIM is not about identifying the individual, so in that sense it is
not about anonymity. DKIM establishes an affiliation with a domain.
The identification of individuals depends upon how each domain handles
and marks their messages, where this is fully determined by what
messages the domain signs. *SP policy allows the purported author's
domain to establish domain affiliation requirements.
Do not suggest that *SP includes identification requirements. This
was declared out-of-scope when the WG charter was formed, and remains
a good recommendation. By establishing domain affiliation
requirements, the question of identification depends _completely_ upon
what messages the domain signs.
It is pointless for DKIM policy to impose requirements that a
signature validate a From header identity. RFC 4871 indicates that
signatures are valid when associated with _any_ header and can even
remain ambiguous with respect to who introduced the message.
Identification is clearly a decision of the signing domain that is
made when the signature is applied. It should not be the role of
verifiers to second guess whether the domain made the proper choice.
This choice is fully within the prerogative of the signing domain.
Nonetheless, DKIM will not be implemented across all message protocols
for practical reasons. Until such time, when a domain's policy states
that "all" messages are signed, in all practicality, this currently
means "all" SMTP messages are being signed. Over time, it would be
wrong to assume DKIM policy only pertains to SMTP. However, as far as
protocol gateways into SMTP are concerned, messages should be treated
"as if" the transport were SMTP, which may become problematic in some
cases. So in that sense, there is agreement.
So how can DKIM policy be structured to permit message protocols not
related to SMTP a means to separately announce when DKIM policy can be
applied? One solution suggested by Jim was to introduce a transport
scoping parameter within the policy record. Unlike the service
parameter within the key, policy scoping should also indicate which
protocols are used that do not support DKIM. It would be unreasonable
to assume all protocols will have implemented DKIM when policy is
published. It would be unreasonable for the policy record to change
as DKIM protocol adoption in the wild changes.
It would be safer and less work for policy scoping to list the
domain's supported protocols, and protocols the domain has implemented
DKIM. This listing could allow abuse to be blocked that might be
introduced through protocol gateways. This listing can also prevent
the undesired blocking of messages intended for non-SMTP
infrastructure when it is known the domain has not implemented DKIM
for that protocol. Such policy scoping would permit other message
protocols an ability to introduce DKIM policy independently from that
of SMTP, and to improve protections ASAP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html