Subject: RE: [ietf-dkim] Proposal for specifying syntax and semanticsformultiple signatures

From: <[email-masked]>
Date: Mon, 3 Apr 2006 09:51:28 -0400

We are a rather smallish ISP that handles about 40 mil mail messages a
day. I am talking about signing and verifying. DNS rollout should be a
matter of updating the proper record with a policy statement (whatever
that turns out to be) and a public key. 

This is similar (except for the DNS part) to changing an AV engine, it
does not require a redesign of the entire current mail methodology, that
piece sits behind my edge devices and see's whatever messages that pass
muster from the front end and processes them. Is it an insignificant
amount of work? Not particularly.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Saturday, April 01, 2006 9:51 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Proposal for specifying syntax and
semanticsformultiple signatures

On Sat, Apr 01, 2006 at 05:16:17PM -0500, [email-masked] allegedly
wrote:
> Many folks use edge devices that look/act like an mta but is
antispam/av oriented. Dropping a dkim plugin should be no more dificult
that deploying a new av engine.

Are you talking about signing or verifying or both? Have you actually
done this or are you speculating about the ease? Are you considering
key management and DNS rollout in your claim about "no more
difficulty" or are you ignoring that aspect? Have you considered any
need to authenticate submitters or is that irrelevant?

If folk here are thinking that DKIM is a mere matter of adding a
plugin to existing infrastructure they are sadly mistaken. And to
justify protocol designs on that assumption are also mis-guided and
narrow-minded.

The people I've been been working with have actually been deploying
this stuff on a large scale with a large number of participants for a
number of years. They have *all* had to deploy new s/w and new
processes to participate. No exceptions.

That this group contains a number of folks who are capable of running
their tiny infrastructure as a DKIM experiment does not constitute the
Internet reality. As a group we should be very wary of their
disproportionate influence simply because such folk are present and
vocal on this list.

The almost religious approach to "must be milter compatible" is a case
in point. Such constraints are largely irrelevant to the major senders
and the major receivers I've been dealing with - yet already such
constraints seem to pervade the discussion here simply because three
or four vocal participants happen to use a milter as a convenient
implementation frame-work.

Mark.

> thanx,
> bll
> 
> 
> -----Original Message-----
> From: [email-masked] on behalf of Michael Thomas
> Sent: Fri 3/31/2006 6:32 PM
> To: Mark Delany
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Proposal for specifying syntax and semantics
formultiple signatures
>  
> Mark Delany wrote:
> 
> >On Fri, Mar 31, 2006 at 02:25:49PM -0800, [email-masked]
allegedly wrote:
> >
> >  
> >
> >>And let's please not forget that even if this got fixed tomorrow the
amount of
> >>time it takes to significantly deploy new MTA versions is very long
- far
> >>longer than we can afford to wait.
> >>    
> >>
> >
> >I'm confused. We expect wide-spread use of this protocol without
> >deploying new MTAs? That's quite the feat.
> >  
> >
> With milter, you don't have to upgrade your sendmail version. For us,
> we'd probably have to go through a lot more contortions to get our
> infosec folks to buy into a new sendmail version for our production
> environment. Not undoable, but definitely harder.
> 
> My understanding is that other MTA's have similar plugin kinds of
> capabilities too.
> 
>        Mike
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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