John C Klensin wrote:
If was precisely SPF and Sender-ID, and some similar approaches, to which I
was referring. And I agree with the skepticism and, based on my personal
biases, could have said something a lot stronger that "appear to be": I
was trying to be as neutral
(every now and again, i too experiment with being politic.)
as possible in that comment. One may, of course, be able to substitute
"one hop in trust relationships" for "one hop in transport", but it is not
clear how much that changes things.
Probably requires both constraints, to work, given the physical act of
registering source addresses.
To avoid more of the confusion that comes from not giving examples, while I
believe that DKIM eliminates some of the problems associated with SPF and
Sender-ID, I don't see it as eliminating all, or even most, of them _if it
is used in the
Reasoned discussion about tradeoffs and benefits is always helpful. This space
has not had much of that...
In any event, reasoned proponents of DKIM are clear that it has narrow intent
and narrow benefit. While some of the constraints are already known, I
suspect most reasoned proponents would expect to discover additional ones.
But I don't think I understand how/why you believe it constrains
anything... it was just an observation that those techniques do have
skeptics, that there is some evidence that they don't work
Interesting. You were using "appear to" as a means of raising questions and I
was interpreting it to note the lack of sufficient experience to be able to
say "known to". So we had pretty much opposite views of the term. Sorry for
the misunderstanding.
By way of clarifying the point I was trying to make about path-registration
administrative overhead: It is easy to create the first record. By that
measure, the barrier to adoption for a 'sender' can be extremely low. No new
software and maybe one or a few DNS records. This is goodness.
But it misses the considerable long-term overhead, having to constantly
anticipate changes to the records, including registering all intermediaries,
such as outsourced sending engines and individual forwarders (such as
acm.org.). In other words, the path-registration scheme requires upper-level
application work to be cognizant of email topology and to keep accurate
registration for it.
(The irony of this is that the lower network levels are pressing hard to
*de-couple* identification information from location information, and here we
have an email security scheme trying to marry them more closely.
In other words, too many of the proposals that keep kicking around assume
that there is a live, direct, online, path, using stable and public IP
addresses, between the set of systems under close control of the receiver
and those under close control of the sender and that there are no gateways
involved.
Yup.
Right. Or perhaps consider alternate techniques that do not impose this
limitation?
Sure. You have any suggestions that don't require any of:
* fundamental changes to how the mail system works, especially changes that
would make things more difficult for legitimate users with slow,
intermittent, or very expensive connectivity? * a PKI or equivalent with
fairly strong assumptions about user ability to manage keys? * central
control of the mail system, or control by a relatively small collection of
collectively-selected, or regulator-selected or certified, providers?
* treating a new correspondent address as inherently suspicious even if the
correspondent is well-known and trusted?
Sure.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf