"Brett McDowell" <brett(_dot_)mcdowell(_at_)me(_dot_)com> wrote:
On May 25, 2010, at 8:43 PM, Scott Kitterman wrote:
Like I said, "throw away anything that doesn't have our signature" has
some chance of broad adoption. Every extra word you add to the message
makes it less likely that people will do it.
I agree with this. I have yet to see any proposals for additions that didn't
either add enough complexity to act as a barrier to deployment or
alternately make it trivially possible to allow third parties to create
messages that render discardable moot.
I agree that adding anything to "throw away anything that doesn't have our
signature" add complexity to implementation and therefore, by definition, is a
barrier to adoption. That's not what we are debating. What we are debating
is whether such complexity is a necessary evil that we should provide a
specification to support -- as an optional mechanism for stakeholders who want
to opt-in to the authenticated email ecosystem. I *think* the answer is
"yes". But we haven't yet had the meaningful debate that will resolve that
question.
Let's debate whether transient trust through a MLM is actionable. Would a new
header that enabled the MLM to report to the receiver that they indeed
validated the original signature actually make any difference in the
deliverability of that message to the receiver, and if yes, is that actually a
good thing? I say "yes" and "yes". But I expect that if we debate this
specific point one of you might highlight an unintended consequence that would
tip the balance away from pursuing such a model.
Thoughts?
That's not quite the question.
Such transient trust can't be spoofable. It needs to have properties such that
if it asserts "trust me, it was signed by PayPal when I got it, so you can
ignore their discardable flag" it can't be used by arbitrary senders to bypass
PayPal's ADSP.
I don't know of a way to do that which doesn't require a trust relationship
with the mail list provider. If you have such a relationship then it's
relatively trivial to just not bother with ADSP checks for mail from such lists.
I'm left not knowing what advantage there would be from a more complex
standardized approach.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html