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