----- Original Message ----- From: "Paul Hoffman" <[EMAIL PROTECTED]>
> At 2:37 PM -0400 4/19/06, Hector Santos wrote: > > >> Verifiers SHOULD support checking of x= values. > > > >I think this must be a MUST. In my view, this is risking malpractice and > >product liability problems if a domain has exclusively expressed an > >expiration and it is not honored by the verifier. > > Armchair lawyering should be out of scope for this discussion. Armchair? Please Paul. I have dealt with legal product liabilities every day for the past 25_ years in corporate and private enterprises. No responsible manager should be ignorant of it. Lawyers don't think things up. You do. Sorry Paul. I understand the cliche and I try to avoid such debates myself. But when needed, you just need to bring it out before it hurts people. It is a new era when we are placing a new responsibility of domains signers who seek extra protection and immediate detectable segregation from the bad. I can understand these product liabilities issues and now does John Levine. From his trip report: http://www.circleid.com/posts/california_frets_about_goodmail_email/ .... In the questions that followed we learned several interesting things. One is that AOL and Goodmail both agree that they are responsible for the mail they stamp, to the extent that if a phish or virus sneaks through with a stamp, they're on the hook for damages. This is something new in the world of e-mail. .... > Everyone should, of course, implement from the spec in any way they > want to with respect to their perceptions of the law. But that's an > implementation choice, not a spec choice. Agree, but the specs should provide guidance. I was responding to Steve to correct my statement and agree with your post too. The wording should probable be: Verifiers MAY support checking of x= values. If verifiers supports checking the expiration x= tag, they MUST honor the signature expiration. This is the safer approach. I personally don't like it when your spend alot of effort on a new protocol and you have relaxed provisions at receivers that basically nullifies its objectives, but I agree that you don't always want to create situations that promotes liability issues too. >> If there are any harm or >> damages some some entity (user or domain), this is subject for action >> (asking for trouble.) > > Similarly, threats of legal action, even by third parties, should > also be out of scope. Were you attributing my statement above to a threat? Hahaha, out of the world. It was a point. Ask john. He is well verse on the subject now. > >I don't think I am off base with this opinion, > > I do, given the long list of IETF specifications that allow the > recipient to decide what they do or don't want to do based on local > policy, and the amazing lack of "malpractice and product liability > problems" that have come up. Absolutely, uncategortically incorrect. If you need help 1) Start with US EPCA 1986 provisions. 2) See the TOC that were established because of it, 3) See all the lawsuits that were based on it, 4) See Canadian Malpractice Bills for ISP currently in play. 5) See Verizon's recent settlement that was 100% reliable to your misconception above and lack of understanding of #1. Many I can go on and on, I don't wish to get into this because it is obvious you are not well verse on product liability concerns. It is this attitude that continues to make people believe they really can do what they want with accepted mail. It is fallacy and if you don't believe that is the case, talk to a high tech lawyer that is familiar with the laws. Or better, setup an Commercial EMAIL server, get commercial customers and go ahead and use this "Oh Well, I can do what I want with your email" mode of operation. If a customer was harm, lost of business or whatever because of your malpractice, you are liable - PERIOD. Your TOC means nothing when you ACCEPT mail and don't deliver it without notification. That is what happen to Verizon just last month with their Class Action Lawsuit settlement but its long been precedence. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
