Charles Lindsey wrote:
In general +1 to all that, though I am not as passionate as Michael, and
can accept that hopelessly broken signatures _might_ occasionally be
removed.
But by and large, I do not want to prevent Forensics.
Whats odd about all this is that it perpetuates the key differences in
understanding the purpose of DKIM. If its for a domain to assert a
responsibility for the message, then based on these discussions it is
only up to a point or the next hop where that responsibility is
downgraded or rescinded. As the next hop, be it a relay or list server,
could take over the responsibility, the chain of trust is presumed
here. Hop to Hop, Point to Point, relay to relay, finally the the MDA
and the user. This is an fundamental idea that allowed internet email
and the delivery system to work, but there was never a presumption that
middle ware will be altering the originality of the mail. Passthru
mail was fundamentally sacred and this was covered by US laws to be
frank. It's been challenged over the years, but there is still a taboo
to mess around with it. List Servers were the exception for the most
part and that was covering tagging the subject, adding footers or some
HTML framing, etc, all making it much harder for new mail integrity
technology.
But overall, I hope everyone agrees that a message MUST begin its
adventure through its "mail-verse" travels with sound integrity. i.e. it
can not begin broken. The first hop must take action and minimize
initial failures propagating through the net especially where there is
auto-correction involved. So if the chain of trust is going to be
presumed to be reliable concept, then the question I have is what
happens at the first moment it is broken? Are we too expect the List
Server to drop incoming invalid DKIM messages to auto correct it and
redistribute? If there is going to be an stripping and replacement
concept, should only strip successful signatures, not failures?
I never liked any software or idea that screwed around with headers. It
was always problematic one way or another, if not for you, maybe for
others, the downlinks. I don't see how DKIM can control perfection here.
So in that vain, I'm with Michael 100%, it brings nothing but trouble
and I consider it more harmful, then not to be screwing around headers
you didn't create or own.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html