Re: the curse of the S(imple) protocols, was: Re: e2e

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Sunday, 19 August, 2007 11:48 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:

> 
> 
> John C Klensin wrote:
>> 
>> --On Friday, 17 August, 2007 16:18 -0700 SM <sm@xxxxxxxxxxxx>
>> wrote:
>>> There are ways to validate the sender the first time you
>>> establish a contact.  Once that is done, you can use it to
>>> validate future communication you receive from that
>>> correspondent.
> ...
>> Hop-by-hop transport-based solutions appear to be easier to
>> deploy --although there are some concerns about transitivity
>> of trust relationships and the ability of large mail
>> providers to force the smaller ones out, among other things--
>> and they
> 
> Given the poor history of actual deployment and use of
> authentication -- that IS what is being discussed, right? --
> for email, I'm not sure where the "appear to be easier to
> deploy" comes from, unless it is the narrow consideration of
> the two popular path-based schemes, SPF and Sender-ID.  If so,
> the large-scale efficacy of them is either unclear or
> problematic, depending upon which skeptic is talking. My point
> is that "appear to be" requires constraining the consideration
> too much.

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
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.
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
same way_ (if it is used purely as a reputation service for
elevating the level of attention/ MUA priority given to some
messages, as you have suggested, I don't see it as even part of
this discussion).

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
as well (at least in simple form) as their most passionate
advocates would claim, and so on.

>> generally work much better when there is a direct connection
>> between the originating MSA and the final deliver MTA than
>> when relays are involved.   But they also tend to restrict
>> services somewhat.  
> 
> In other words, hop-by-hop is easier, when there is only one
> hop?

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.  I note that
the absence of such control does not imply open relays or their
ilk although it does imply that, in some cases, not every system
in the path is guaranteed to be following exactly the same
rules. 

I was trying to suggest --obviously in too subtle a way-- that
the supposedly easy-to-deploy transport-based systems often
don't work well if there is more than one hop.  If that is
equivalent to what you say above, then so be it: the apparent
silliness of that statement may be just the point.

>>    Maybe we have to give that up --and
>> give in to the desire of those who run the large email
>> services to advertise themselves and lock users in -- but,
>> from my point of view, the techniques better have very high
>> leverage on spam and criminal enterprises in order to justify
>> that.  Otherwise,
> 
> 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?

--john





_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]