And the bell rings for the next round....
-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Tuesday, August 24, 2010 12:32 PM
To: MH Michael Hammer (5304)
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures -
mua
considerations
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
begged
for
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
responsible
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
assertion
that the main purpose is assessment by reputation filtering engines.
Wow.
You don't think that "The module is dedicated to the assessment of the
delivered
identifier." has that meaning? What exactly do you think it /does/
mean?
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
the
signer and that information is passed to the message filtering
system.
Still doesn't indicate "primacy", only that reputation can be part
of
the
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
implementation?
As for my use of 'reputation', that's a convenient label that is
popularly
used
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
the
language
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
and
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
popularity contest.....
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
take
shots
at me, while I readily acknowledge my convenience as a target, that's
better
done offline. If it is for a constructive purpose, such as improving
group
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
more
than
sufficient, you appear to be particularly sensitive to specific
vocabulary.
And yet again I read and I reread but find nada that says reputation
is
primary. Perhaps if you had said "In my humble opinion reputation is
the
primary...."
I remember that we collectively kicked the can down the road by
saying
what
someone did with the value returned in evaluating a message for DKIM
was
out
of scope.
First, I believe in self-awareness. For better or worse, at the
least,
this
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
the
list
that is exceptional. Possibly a good idea, but certainly not well-
established.
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
my
statement. Most especially, the diagrams and accompanying discussion
that
I
cited entirely supported my comment, IMNSHO.
Fourth, there is a difference between saying that the /details/ are
out of
scope
and saying that the /construct/ is out of scope. This is tied
directly to
the
construct of DKIM's delivering a specific payload. The delivery
crosses a
processing line, to another module. While DKIM does not get to
specify
the
internal details of that module, it has to have some basic sense of
what
the
module is for.
Otherwise, there's no understanding of the purpose that DKIM is
intended
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
on
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...
Guess not.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html