ietf-mailsig
[Top] [All Lists]

Re: simplicity, focus and adoption; what problem are we trying to solve?

2004-10-28 08:33:39

On Thu, 2004-10-28 at 07:37 -0700, Dave Crocker wrote:
Jim,

Note the change in Subject line.  I believe we need to focus on some 
very basic issues, in order to decide whether to include heuristic 
hacks that work around *some* mailing list behavior.

I agree with that, except that I'd say "most" rather than "some".

All I have to back that up is a quick count of my own personal
mailboxes. Of the 41-odd active lists I'm bothering to filter into
separate folders, 36 do add a few lines to the mail, while 5 don't.
That's 88%.

This isn't just a user-education issue either. You'll get a lot of
resistance if you tell people to stop adding stuff to the list traffic.
Most lists put a link to the list-info web page from which the user can
unsubscribe. Most users are too stupid to unsubscribe _without_ that
constant reminder, and a direct result of omitting it would be that the
number of "Please help me unsubscribe" messages to the lists would
increase.

I _really_ don't think that telling list admins to 'fix their list' is a
viable option. 


 In the short run, requiring that mailing lists do this in order
 for verification to work is a serious deployment problem.
 It will take some amount of time for mailing lists to begin
 checking signatures and signing; if that's too long people may
 give up on message signatures. 

This is true for any change to an established service.  For that 
matter, it is true for any service at all.

For the current discussion, we need adoption by sending sites and 
receiving sites (and, here, the different between adoption by mtas vs. 
muas is irrelevant).  Mailing Lists are just one more example of 
adoption.  

I don't agree. As I see it, mailing lists are an example of an
uninterested third party sitting in between the sending site and the
receiving site, preventing incremental and unilateral deployment.

I _can't_ start rejecting mail for DK failures today. Not even for
myself, let alone my users.

Treating mailing lists as a special concern introduces significant 
additional complexity to the specification, makes end-to-end 
performance significantly more problematic -- by defining the 
end-points as crossing an intermediate UA -- and is just as likely to 
frustrate user expectations as it is to aid them.

You seem to be saying that dealing with the real world hurts. I don't
really disagree with that.

We should also make some attempt to get message signing to work with 
at least some personal Forwarding or Resending.  

Or maybe we shouldn't.

Maybe survivial of the signature across re-postings is not a goal.

Maybe we should define a simple, clean service, that has a constrained 
goal and constrained specification.  That way it will be easier to 
understand and implement and it will work predictably.  This will make 
adoption and use far easier.

I am trying to imagine designing any other Internet protocol that has 
special features to hack around transient adoption concerns.  

Then let's define something that uses the RFC2821 sender address
instead, and it doesn't need to cope with such details about the real
world.

The argument that we should use the RFC2822 headers because they're more
visible is a red herring. The most prevalent MUA (I'm _assuming_ that's
Outlook?) doesn't show the actually address part anyway, does it? And if
you can make it look at Sender: or Resent-Sender: headers then it's
still trivial to hide it. 

-- 
dwmw2


<Prev in Thread] Current Thread [Next in Thread>