Re: DKIM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Not clear. As currently envisioned, DKIM doesn't address phishing because it basically says "I saw this message" rather than "I wrote this message".


I don't see a problem with that, XML signature does not have any
signature semantics at all.

Different application, different use cases.

Signature semantics are a function of the PKI, not the application.

No. If the protocol doesn't say what is meant by signing a message, or even restrict the circumstances in which a message can be signed, then very little can be assumed about a signature even if it appears to be valid. PKI can have an effect on semantics, but the semantics don't have to be determined entirely by the PKI.

I see the big problem with blacklists as being their total refusal to
accept accountability to email senders.

That's partially because either they have no way to be sure of what they're asserting, or they have to constrain themselves to making assertions which might be verifiable but aren't good indicators of anything. If we want reputation servers to work better, we have to provide them with data that are both useful and verifiable.

Its all about accountability.

I don't see how we can have accountability of reputation servers without giving them reliable data which can be audited. We could penalize them for providing false negative indications but that alone would make them ineffective against all but the worst offenders. Everyone would get away with spamming a little bit, and everyone's mailbox would still be flooded - just with more sources of spam than we have now, and with spam that's harder to filter out with heuristics than at present.

I think that the problem is the common one of thinking that the way to
get a group to act quickly is to specify the smallest possible charter,
even if this means that the job is only half finished.

...and even if that means the problem is not understood.

I think it would be much better to accept that email authentication is
going to be a longer job.

Instead of proposing a twelve month charter with minimal deliverables I
think that the group should have a longer charter, two or three years
would be more realistic.

Long charters don't seem to work well. I'd prefer a charter with the first deliverable is that the group should produce a detailed description of what it takes to solve the problem and a convincing explanation of why it will work. At the rate IETF moves, that will take at least a year. Once that milestone is completed the group could have its charter extended to do the protocol work. But the protocol work is the easy part.


What I don't think is acceptable is a group saying that they are not
going to address a part of a problem because 'we do not understand it'

I agree, but it's even worse for a group to try to address a problem that it doesn't understand, or for a group to make a part of the problem that it doesn't understand a necessary component of a solution.

Keith

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]