On 05/26/2010 02:04 PM, Scott Kitterman wrote:
"Brett McDowell"<brett(_dot_)mcdowell(_at_)me(_dot_)com> wrote:
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.
Right, and where I have problems is that I doubt that most admins have any clue
whatsoever
which lists their users subscribe to. Some certainly have policies which may
inform them
(= don't do it), but beyond that this sounds somewhere close to an impossible
task.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html