On 8/4/06, Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
> From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
> So if a mailing list mangles a message then you'd consider
> the message as no longer being policy-compliant? I guess
> that's one reasonable way to look at it, but I don't believe
> its the only reasonable way. I could equally treat this as a
> case where the message appears to conform to the policy, but
> fails signature checking.
A mailing list is not quite the open hole in the specification that many seem
to think.
I think it is a reasonable goal to get to the point where there are only three
likely explanations for a failed message:
1) The message was damaged by a mailing list
2) The message is fake.
3) The administrator for the outgoing mail is a dufus.
4) A real message was 'controlled' by my policy. (ie. I don't want
anyone or rouge MTAs on my network or in my company sending mail
outside the signing process)
Note that I don't even include the mail forwarders like PO box here. If they
don't get their act together they will shut up shop. They are paid to do the
job. The reason mailing lists are unlikely to be a problem is that they are
often volunteer run and the incentive to upgrade is much less.
KISS principle _required_
In any case where mail is being forwarded to me it is without exception because
I have established that forwarding relationship.
This is something I can block very effectively in the client.
So the path processing for cases are very different here.
It is not enough to say 'we created a mess, sorting it out is someone else's
implementation issue'.
> Sounds a bit like an implementation issue.
What is the point of a specification if not to provide the information the
implementations need?
Sort of like me selling you a brand new car - without the keys - or
just as bad - Giving you a bag full of keys and letting you figure out
which one works.
Damon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html