Why not take an AIN approach? An SSP query to determine how to route the
message, with additional signatures, without and directly?
Thanks,
Bill
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Sunday, August 06, 2006 5:38 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html