----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Thomas A. Fine" <[EMAIL PROTECTED]>
> 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
