ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] "I sign everything" is not a useful policy

2006-08-06 14:47:36


Mark Delany wrote:
If I choose to deliver unsigned mail that purports to be from a domain that 
says
it signs everything, but I mark it up with flashing lights that say 
"spoofed" do
...
Well sure, but how about treating it the same as an IP checksum
failure?

You may divert it to some port for analysis - especially in the early
days - but what sort of stack delivers a known damaged packet to the
end point when the transmitter/protocol says to discard known damaged
packets?

Mark,

I am a great fan of looking to the experience of the lower layers, when trying
to develop mechanisms for applications, especially email.  So your suggestion is
an important one to consider.

I think the problem is that email's variations in the handling of its "packets"
make its environment too vastly different from the much simpler world of IP.

(I'll skip over my recollection that there have been activities that do partial
delivery on damaged IP datagrams. The standard says what you cite and it is a
more useful place to start, I think.)

What you espouse is probably where we all want this to get to.

The question is whether we can get there with a directive, at this point, in an
adjunct protocol that operates in the realm of a contingent, remote,
partially-adopted mechanism that changes the fundamentals of Internet mail
delivery?

And, of course, the way I've phrased it, here, makes clear my own view of the
answer.

In other words, having a sender give contingent -- in the sense that some
senders will give it and others won't -- directions about delivery is a very new
realm, not just for email but for Internet protocols in general.

Rather than cross over the line into that bit of architecturally experimental
specification, why is is not sufficient to leave things with the simpler --
albeit more passive -- stance that a sender talks about themselves but refrains
from telling the evaluator what to do with the information?  Yes, that is at
odds with a classic model of protocol specification, but we are juggling among
constraints, here.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>