ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Attempted text for x=

2006-04-19 13:27:47

----- Original Message -----
From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>


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