[ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations
MH Michael Hammer (5304)
MHammer at ag.com
Tue Aug 24 10:43:19 PDT 2010
And the bell rings for the next round....
> -----Original Message-----
> From: Dave CROCKER [mailto:dhc at dcrocker.net]
> Sent: Tuesday, August 24, 2010 12:32 PM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures -
> On 8/24/2010 9:11 AM, MH Michael Hammer (5304) wrote:
> >>> But again, no verbage that matches your assertion.
> >> I wasn't aware that my statement was offered as a quotation. I
> >> certainly didn't intend it to be.
> > Your statement was taken (at least by me) as an assertion that
> > supporting evidence.
> I thought you were questioning the precise wording.
> As for 'supporting', sorry for assuming that folks on this list were
> sufficiently familiar with the follow-on work done by this group...
> >> Errata, RFC 5672:
> >>> 8. RFC 4871, Section 2.11, Identity Assessor
> >> ...
> >>> A module that consumes DKIM's mandatory payload, which is the
> >>> Signing Domain Identifier (SDID). The module is dedicated to the
> >>> assessment of the delivered identifier.
> > I read it and I reread it and I still nothing that supports your
> > that the main purpose is assessment by reputation filtering engines.
> You don't think that "The module is dedicated to the assessment of the
> identifier." has that meaning? What exactly do you think it /does/
One can assess based on policy rather than reputation. In fact I can
think of several companies that popped up recently in this general space
(email authentication) to do just that.
> >>> If the signature passes, reputation information is used to assess
> >>> signer and that information is passed to the message filtering
> > Still doesn't indicate "primacy", only that reputation can be part
> > process.
> Really? You want this exchange to hinge on my use of an emphasis?
Absolutely. Primary as you used it has a very specific meaning..... or
are we introducing fuzzy logic to the world of standards development and
> As for my use of 'reputation', that's a convenient label that is
> to refer to an assessment phase.
Reputation is one subset of the possible implementations of assessment.
> Perhaps the question should be: If you are that uncomfortable with
> I used, what alternative language would you offer. Having that would
> allow some
> best-fit comparison.
I am quite comfortable with what Wietse wrote. I was going to respond to
his post with a +1 for each of his points.
> >> and<http://dkim.org/specs/rfc5585.html#rfc.section.5.5>
> >>> 5.5. Assessing
> >> ...
> >>> A popular use of reputation information is as input to a Filtering
> >>> Engine that decides whether to deliver -- and possibly whether to
> >>> specially mark -- a message. Filtering Engines have become complex
> >>> sophisticated.
> > "popular" does not equal primary.
> By some popular measures, it does.
Careful for what you ask for. If we are going to reduce this to simply a
> I'll assume that it's too early in the day for you to have started
> drinking, so
> I'll have to admit to confusion about this exchange. If it's just to
> at me, while I readily acknowledge my convenience as a target, that's
> done offline. If it is for a constructive purpose, such as improving
> understanding about DKIM, please suggest superior language.
I am content to leave it as "email authentication, including DKIM is a
useful and good thing. The more that DKIM signing is implemented, the
greater the opportunity for receivers/evaluators to do useful things".
If reputation floats your boat then knock your socks off. I seem to
remember a venerable member of this list floating a proposal that wasn't
supposed to compete with reputation..... AffiL or something or other.
Just to lighten things up, a music commentary on reputation compliments
of Joan Jett - http://www.youtube.com/watch?v=5RAQXg0IdfI
> Although I certainly thought that the citation base I supplied was
> sufficient, you appear to be particularly sensitive to specific
> > And yet again I read and I reread but find nada that says reputation
> > primary. Perhaps if you had said "In my humble opinion reputation is
> > primary...."
> > I remember that we collectively kicked the can down the road by
> > someone did with the value returned in evaluating a message for DKIM
> > of scope.
> First, I believe in self-awareness. For better or worse, at the
> requires my acknowledging that I never view my opinion as humble.
Aw, I stand corrected. Humble or not your opinions are always
interesting and valuable, my prodding today notwithstanding.
> Second, you appear to be seeking to enforce a linguistic etiquette for
> that is exceptional. Possibly a good idea, but certainly not well-
Exceptional? I think not but I'm too busy at the moment to wade through
the archives to provide examples.
> Third, I think that the citation base did amply justify the focus of
> statement. Most especially, the diagrams and accompanying discussion
> cited entirely supported my comment, IMNSHO.
> Fourth, there is a difference between saying that the /details/ are
> and saying that the /construct/ is out of scope. This is tied
> construct of DKIM's delivering a specific payload. The delivery
> processing line, to another module. While DKIM does not get to
> internal details of that module, it has to have some basic sense of
> module is for.
> Otherwise, there's no understanding of the purpose that DKIM is
> to satisfy.
Of course there is. I refer you to the post from Wietse today.
> Oh. Wait. That's exactly the confusion that is so often demonstrated
> this list.
> Such as right now.
I don't think I'm confused. I have roughly a billion signed messages
under my belt and the feedback I'm seeing from various receivers
regarding dispositions indicates that handling based on assertion from a
1st party signer can work very well sans reputation engine. I'm just not
in a position to provide details at this point because while I may have
access to various data streams I do not own those data streams.
> Perhaps we should endeavor to fix that?
Perhaps we should.
> Oh. Wait.
> I thought we did...
More information about the ietf-dkim