Comments inline.

> -----Original Message-----
> From: HLS [mailto:sant9...@gmail.com] On Behalf Of hector
> Sent: Tuesday, June 16, 2009 4:28 PM
> To: MH Michael Hammer (5304)
> Cc: DKIM
> Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures,
was
> l= summary)
> 
> Hi Michael,
> 
> MH Michael Hammer (5304) wrote:
> 
>  > So you are absolutely against 3rd party signatures unless the
>  > 3rd party broke a first party signature?
> 
> I have an long ethical engineering problem with designing and dealing
> with any mail mover software that alters and/or the original intent of
a
> message.  The 1986 US EPCA provisions help model the guidelines for
> hosting systems.  Keep in mind my view point is purely based on
security
> and technical consistency and the expectations of the message
> author/owner.  If the intent of the originating author and copy right
> holder of the message was mail integrity and not necessarily message
> owner authenticity, then I see less of a concern with a 3rd party
(relay
> or hop) changing the intent and final status as long as its persistent
> and consistent.  The chain of trust applies.
> 

How does a 3rd party signing a message change the intent of the author
of a message? One might argue that breaking the original signature does
that. My response would be to then avoid breaking the original
signature.

One of the arguments put forward supporting the DKIM effort was that
unlike SPF it is not hop dependent. 

> But if the intent of the originating author was both mail integrity
and
> authenticity, then I see a really high potential for security and
> technical problems when there is no  "Helper" involve to assist the
3rd
> party and it just blindly alters the mail.
> 

Blindly altering things is generally not a good idea in most
circumstances. I'mnot sure where a "helper" comes into play here.

> Assuming the status quo and direction of DKIM-BASE sans policy,  I see
a
> less security  problem when the original mail  was signed and valid
and
> because of the inherent nature (BCP) of list servers today to alter
the
> messaging layer (presentation),  it  keeps the integrity of the
altered
> message intent intact  by resigning.   I see problems when the 3rd
party
> signs non-signed original mail when policy is still in the mind of
this
> project.  If policy was completely out of the picture, then DKIM
becomes:
> 
>      A system and core protocol allowing a MTA domain (domain) take
> responsibility for the
>      transportation of a message to the next  MTA (Hop) .
> 
> The model is less focus on the Original Domain expectations for the
> authenticity of the transport.  The facebookemail.com post is a prime
> example of the situation with blind list server or middle ware
signings.
> 

Daves server signed the message. As I pointed out in my original post,
this implies some level of responsibility for the message. We still
don't know what that means let alone what we should infer in terms of
reputation (for those who want to go there).

> > My understanding has always been that anyone who handles a message
can
> > sign and thereby take responsibility (whatever that might mean) for
the
> > message they are signing.
> 
> Although this mindset has prevailed, it was not always like that Mike.
> If it was the primary focus (i.e. policy was never a consideration and
> out of the picture), then I believe we would long finished this
project
> .   In the same vain, if people respected the charter out of scope
> guideline for reputation, then possible Policy would of been resolved
> and project over long again. :)
> 

I figure that getting senders signing (or signers signing) and receivers
validating will allow the whole reputation issue to be resolved. The
water is great, jump right in.

> > I have to disagree Hector. For better or for worse, SSP was never
> > an integral part of DKIM. It is layered on top of DKIM.
> 
> It was what sold us to even get involve.  All original marketing and
> presentations had SSP as a integral part of the framework.  It was
part
> of the charter and and DKIM/SSP original specs was ONE document
> (following Yahoo's Domainkeys specifications) before it was split.
> 

I'll admit that SSP has been one of the selling points but as far as I
recollect it has always been represented as something being layered on
top of DKIM and not a core requirement for someone choosing to sign some
(or all) of their messages. Don't get me wrong, I am a strong believer
in the value of SSP/ADSP and believe that once some real implementations
get out in the wild where receivers are validating and respecting ALL or
discardable assertions, life will get interesting.

>  > I'm surprised Hector. It really took you a second to decide it
wasn't
> legitimate?
> 
> Is 1 second good or bad? I did hit 1/2 century mark this year so I am
> bit slower. :-)
> 

But wiser?

> No honestly, I wondered there for a moment if this was a new WG
> participant organizing a wiki/social network DKIM resource.  I just
came
> back from a NYC trip visiting daughter and attending Yankees/Mets
game,
> and all I heard this weekend was FACEBOOK this, FACEBOOK that. :-)
> So I wondered if this was an spambot and if so, why wasn't it trapped
> with the list subscription confirmation process.
> 

My hunch is that it was probably an addressbook harvest type scenario.
Various of these social networks offer (insist?/annoy?) users allow them
to harvest email addresses from the users mail so as to allow others the
delight of interacting through the social network. I'm not picking on
Facebook in this respect as it is a fairly common practice.

Mike

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to