Mike,
To his credit, since day one Levine has been militantly against
Policy. What was surreal was that the IETF chairs allowed an
individual who never believed in policy and vocally stated so, to take
over the SSP specification from Eric Allman and Jim Fenton and water
it down to uselessness. This was a classic example of a "Poison Pill".
Nonetheless, the issue was not that POLICY was not desirable by the
resigner market of people here, but the lack of proper engineering
performed for the watered down version and the interoperability
consequences caused by not supporting it even at this watered down
level. The latter being the main mis-engineering calculation.
Overall, the result was an inherent protocol inconsistency with DKIM
resigners. The issues were and still are very clear and the concerns
were documented over and over again. Unfortunately, these concerns
were excommunicated from the WG.
Either a) we update RFC 5617 to make sure resigners support it, b)
add a 3rd party policy to it, or c) we get rid of it.
--
Hector Santos
Michael Thomas wrote:
This is surreal. We have both Crocker and Levine claiming that the *published*
semantics of RFC5617 are either not what it says, or should be ignored because
they don't like it.
Jim is under no obligation to produce evidence for you; evidence which is
-- of course -- conveniently a negative which cannot be proved. The obligation
here is to stop the revisionist history about what rfc5617 actual says.
I realize that this is an open and public forum, but the level of contempt
for this working group's output is astonishing.
Mike
On 10/11/2009 11:54 AM, Dave CROCKER wrote:
Jim Fenton wrote:
I'm (obviously) not as much of a fatalist when it comes using dkim=all. I
believe there are things that one can usefully do, such as to "raise the
bar"
on content filtering, if a message fails a dkim=all ADSP.
Jim,
What you write sounds great. Unfortunately, I have no idea what its
software or
operations impact could or should be.
This isn't about being a fatalist; it is about protocol semantics and whether
non-participating intermediaries experience a failure that is not their
fault.
If we are to assert conclusions of operational effect or non-effect, we need
to
be very careful that it is based on reasonable methodology. That you are not
(yet) experiencing a problem by publishing an =all doesn't mean much if, for
example, virtually no receivers are looking for an ADSP record and/or
virtually
no receivers are making handling decisions based on ADSP records.
Before you report your personal experiences, could you include data about the
receivers, please?
To claim that one signs all mail is to imply that anyone receiving mail
from them should see a valid signature.
Hardly. I thought that it was you that was making the point all this time
that all SSP/ADSP could do is describe the sender's practices, and could not
imply receipt of a valid signature.
Imply is different from dictate.
What is the point of signing? What is the point of publishing an ADSP
record?
If there is no expectation that it will have some effect at the receiver,
then
what really is the point of all this work.
If there is expectation that an ADSP record will have some impact at a
receiver,
then there needs to be some expectation that the impact will be upon messages
that have an ADSP record but do not have a valid DKIM signature of the type
ADSP
promises.
Mail sent through list servers invites the problem of receivers getting
mail that does not have the promised valid signature, since intermediaries
are re-posting the message and are free to make whatever changes they see
fit.
Hence, saying -all for mail that goes through intermediaries which might
affect the signature is inviting receivers to treat the received mail with
hostile prejudice.
Depends on what "hostile prejudice" means. If it means using other filtering
measures more rigorously, I'm fine with that.
Publishing ADSP is a proactive step. Failing an ADSP test is different from
failing to validate a signature. It therefore is reasonable to expect that
the
first failure will have a different effect from the second. In this case,
"different" seems most likely to mean "worse".
d/
_______________________________________________
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