----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Thomas A. Fine" <fine(_at_)head(_dot_)cfa(_dot_)harvard(_dot_)edu>
Hi Thomas,
This isn't really directed at you, but I've wondered each time
someone has said something like:
Thomas A. Fine wrote:
"I sign all email, and do NOT permit email through any body or
signature altering gateways"
I've no idea how a sending domain could enforce the "do NOT permit"
there. Neither in practice, nor in principle. Does anyone? (This may
just be my own ignorance of course, I don't claim to be a mail
expert.)
If its unenforceable, then I don't see why anyone would bother making
the statement.
It is programmable Stephen. If it feasible? That depends.
It could be a few things:
- Probably less reliably, it can use the Received headers to
trace the hops.
- A MDA which is actually a relay or router or forwarder is
DKIM compliant and it might have a different set of routing
rules.
- The Verifiers along the chain see a restrictive SSP policy
and keeps with the traditional "Thou should not tamper"
passthru philosophical.
And probably some other possibilities, but I think the most feasible are the
latter two.
The way I see it, the domain that is really intent in using DKIM to the
"notion" that it will help protect its message transactions and the final
end user will have a higher confidence in its originality, these people are
direct their mail to systems known to have a safe and/or DKIM compliant
path.
And I don't mind looking at our ROUTER software to see we can make DKIM work
better with protocol consistency in mind.
PS: SPF ran into the same problem with its FORWARDING ISSUE and the group
still has the thorn on its side about WHO is responsible for the damages,
the MDA who was really a RELAY? or the SPF domain for its desire to get
maximum benefit using restrictive (-ALL, ~ALL) policies. I predict the same
will happen with DKIM as well. When damages happen, they will wonder who is
really at fault. DKIM domains with restrictive policies at the software for
not having the standardize mandate to properly program it. To me, its the
same issue, but with DKIM it is less of an issue because DKIM does solve the
forwarding problem, but it doesn't address when there is additional
tampering and/or uncontrolled resigning that might break the integrity of
the message.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html