Re: [ietf-dkim] where's the code, was draft-ietf-dkim-mailinglists-02 re

> > Give the IETF's traditions, the usual way to show that you care about
> > something is to write the code to do it.
> So if you don't write code for senders you aren't allowed to express an 
> opinion about sender policy?
Anyone can express an opinion about anything, but there's a reason that 
the IETF has a tradition of favoring rough consensus and running code. 
(See RFC 4677, particularly sections 8 and 9.) The draft we're working on 
is a BCP, where C stands for Current.  A BCP describes what people have 
done and found to work, not paper designs.
If a proposal is a good idea, it really shouldn't be hard to persuade 
someone, somewhere, to implement it and try it out.  (That's the E for 
Engineering in IETF.)  For one thing, the net is complex enough that one 
is usually surprised at unexpected side effects and interactions.  For 
another, it puts at least a small minimum bar for people to demonstrate 
that they find something useful.
For all the claims that checking transitive trust is important, I have yet 
to see anyone who actually does it.  This very list puts a signed A-R 
header on messages, I presume because Dave wrote or borrowed the code to 
do so.  Is anyone checking that signed header and use it to manage their 
mail?  As far as I can tell, the answer is no.  (Doubtless I will hear 
very soon if I've overlooked something.)
Mailing lists have been around for decades, and the possibility of people 
forging submissions has been around just as long.  I've seen a variety of 
hacks in the MLM to help identify contributors and control what mail the 
MLM passes along, but I don't ever, in all those decades, recall anything 
to do it at the subscriber end.  If it were a problem, you'd think that 
someone, somewhere, would have tried to solve it before, however 
imperfectly.  Perhaps this is a hitherto unseen problem that needs 
solving, but Occam's razor says that if we consistently don't see 
something, the reason is because it's not there.
Having said all that, it remains perfectly reasonable to write up any of 
these hypothetical propsals as I-Ds and ask the group to publish them as 
Experimental RFCs, to provide a public spec for anyone interested in 
implementing them, something I'd support.  If it turns out people do 
implement them and find them useful, we can revisit them and consider them 
for standards track, as they're doing in EAI.
So start writing those I-Ds.  It's even kind of fun, writing down your 
ideas and trying to make them so clear that even someone like me won't
misunderstand them.

R's,
John

smime.p7s
Description: S/MIME Cryptographic Signature

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