Subject: Re: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH

From: Dave Cridland <[email-masked]>
Date: Thu, 01 Dec 2005 09:13:47 +0000

On Thu Dec  1 01:16:14 2005, Mark Crispin wrote:
> On Wed, 30 Nov 2005, Dave Cridland wrote:
>> 1) I ran into an almost immediate problem with URLAUTH in that the 
>> server didn't recognise the hostname in the URL as being its own. 
>> I used 'mail' rather than the server's canonical hostname.
> 
> For better or worse, I think that a server needs to recognize its 
> name(s) and not assume a canonicalization.  Canonicalization 
> implies chasing CNAME and possibly a PTR lookup.
> 
> 
Effectively, you're saying that a server should take the hostname as 
provided by the client, perform a getaddrinfo() on it, and see 
whether any of the entries matches the getsockname() of the 
connection?

>> It occurs to me that if GENURLAUTH accepted a relative URL (either 
>> to the server URL, or to the currently selected mailbox as with 
>> CATENATE), this problem would vanish. The server is always in a 
>> better position than the client to construct the URL to the server.
> 
> I question whether this is really so, given virtual hosts and other 
> such complications.
> 
> 
I'll certainly concede that this might not be as easy as I thought - 
I've not personally tried implementing something like this.

>> 2) There's no way to know whether a submission server you're 
>> talking to:
>> a) Is authorized by the IMAP server to access "submit+" URLAUTH 
>> URLs.
>> b) Will understand and use "anonymous" URLAUTH URLs, or simply 
>> anonymous URLs.
> 
> I always thought that this was something that this would be 
> knowledge that is configured into the client, either by the human 
> user or by some system configuration tool.
> 
> 
Yes, it has to be. For a Lemonade-environment client - that is, one 
that simply requires Lemonade servers - that's not a problem, since 
the client can assume that whatever submission server it has not only 
supports URLAUTH, but has a "submit+" level trust relationship with 
the IMAP server. In principle, a Lemonade client has no need to 
examine capabilities of servers at all.

For a generic client, I'm a little concerned that a typical user 
would start to encounter problems comprehending what the client is 
asking them about. It's difficult to know how to phrase it in such a 
way that both, for instance, you and my mother would understand what 
question was being asked.

>> 4) I found it unclear whether URLFETCH should accept relative URLs 
>> or not. I have no opinion on whether it should or not, either, 
>> given that the only purposes I can think of would be stateless 
>> access to message bodies, and I'm not sure that's within the 
>> spirit of things.
> 
> I thought that in LEMONADE we require absolute.
> 
> 
For Lemonade, URLFETCH is, essentially, an implementation detail, and 
would only be used by the submission server, with URLAUTH URLs. So 
from a Lemonade standpoint, there is no issue.

> Stateless access to message bodies is certainly a possibility, 
> considered from the inception of URLAUTH.  I'm not sure if I 
> consider it to be "good" or "bad" (I tend towards the latter) but 
> it certainly was considered.
> 
> :-)
> 
> 
I've actually yet to find a practical use for it, although annoying 
purists almost counts. :-)

Realistically, the only circumstances I can think of where you'd want 
to access message bodies in multiple mailboxes would be in message 
assembly, where we'd use CATENATE/BURL/GENURLAUTH commands instead.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Dec 2005 22:08:17 -0800 (PST)

On Thu, 1 Dec 2005, Dave Cridland wrote:
>>> 1) I ran into an almost immediate problem with URLAUTH in that the server 
>>> didn't recognise the hostname in the URL as being its own. I used 'mail' 
>>> rather than the server's canonical hostname.
>> For better or worse, I think that a server needs to recognize its name(s) 
>> and not assume a canonicalization.  Canonicalization implies chasing CNAME 
>> and possibly a PTR lookup.
> Effectively, you're saying that a server should take the hostname as provided 
> by the client, perform a getaddrinfo() on it, and see whether any of the 
> entries matches the getsockname() of the connection?

I'm saying that neither client nor server should canonicalize a name that 
is used in a security context.  This means that the server needs to know, 
its name(s), and probably should not trust the DNS in this regard.

In the case of URLAUTH, I'm not certain that it should be validating any 
associated IP addresses against the getsockname() of the connection (what 
about proxies?).

> For a generic client, I'm a little concerned that a typical user would start 
> to encounter problems comprehending what the client is asking them about. 
> It's difficult to know how to phrase it in such a way that both, for 
> instance, you and my mother would understand what question was being asked.

I suspect that it'll be the same as always; you configure your IMAP server 
and your submission server at the direction of your ISP.

>> Stateless access to message bodies is certainly a possibility, considered 
>> from the inception of URLAUTH.  I'm not sure if I consider it to be "good" 
>> or "bad" (I tend towards the latter) but it certainly was considered.
> I've actually yet to find a practical use for it, although annoying purists 
> almost counts. :-)

I suspect (fear) that some webmail programs would get the idea that it 
will be more "efficient" to use URLFETCH rather than SELECT/FETCH/etc.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Chris Newman <[email-masked]>
Date: Thu, 01 Dec 2005 22:57:36 -0800

Dave Cridland wrote on 11/30/05 23:21 +0000:
> 3) I found it unclear what response BURL generates when used with CHUNKING.
> It seems natural that, given that RFC3030 clearly shows a 250 response for
> non-LAST chunks with BDAT, that BURL should also, but in section 6, a "354"
> response code is listed. I have chosen to expect, and emit, 250 response
> codes, in line with BDAT.

This is a bug in the BURL spec.  It should be "250 2.5.0" (with the same status 
text and discussion) rather than "354".  Will fix during RFC editor process and 
sort down one slot for correct ordering.  This also involves removing the "Most 
of" modifier in the final sentence of the first paragraph of section 6.

                - Chris

---

From: Dave Cridland <[email-masked]>
Date: Fri, 02 Dec 2005 14:23:36 +0000

On Fri Dec  2 06:08:17 2005, Mark Crispin wrote:
>>>> 1) I ran into an almost immediate problem with URLAUTH in that 
>>>> the server didn't recognise the hostname in the URL as being its 
>>>> own. I used 'mail' rather than the server's canonical hostname.
>> Effectively, you're saying that a server should take the hostname 
>> as provided by the client, perform a getaddrinfo() on it, and see 
> I'm saying that neither client nor server should canonicalize a 
> name that is used in a security context.  This means that the 
> server needs to know, its name(s), and probably should not trust 
> the DNS in this regard.
> 
> In the case of URLAUTH, I'm not certain that it should be 
> validating any associated IP addresses against the getsockname() of 
> the connection (what about proxies?).
> 
> 
Right, so effectively, any hostname configured in the client must be 
the (or a) canonical, known name of the server. TLS encourages this 
too, of course.

>> asking them about. It's difficult to know how to phrase it in such 
>> a way that both, for instance, you and my mother would understand 
>> what question was being asked.
> 
> I suspect that it'll be the same as always; you configure your IMAP 
> server and your submission server at the direction of your ISP.
> 
> 
That's not actually what happens now, in a lot of cases. What happens 
now is that the user receives some cryptic instructions, and pays a 
consultant (like, say, me) to configure things for them, generally as 
part of the "get my computer on the web" request. Or asks a friend 
who knows these things.

 From a business standpoint, therefore, I should really be 
encouraging as many cryptic options as I possibly can, seeing as this 
represents a not insignificant portion of my company's income.

But from a technical perspective, however, I'm trying to reduce all 
these options to a minimum. Ideally, I'd like an EHLO keyword, in 
this case, which indicated those IMAP servers for which the 
submission server had access. I say again, this isn't needed for a 
pure Lemonade environment.

>> I've actually yet to find a practical use for it, although 
>> annoying purists almost counts. :-)
> 
> I suspect (fear) that some webmail programs would get the idea that 
> it will be more "efficient" to use URLFETCH rather than 
> SELECT/FETCH/etc.

It'd be more efficient for a webmail client, but only under some 
circumstances (such as when the object referenced by the URL were 7 
or 8 bit, and there was no need to rebuild the summary display). A 
webmail which handled that distinction is likely to be designed well 
enough to avoid the need entirely.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Dec 2005 09:49:48 -0800 (PST)

On Fri, 2 Dec 2005, Dave Cridland wrote:
> Right, so effectively, any hostname configured in the client must be the (or 
> a) canonical, known name of the server. TLS encourages this too, of course.

Don't use the word "canonical".  It implies a "canonicalization" step to 
transform a name into the canonical name.  DNS spoofing makes doing so 
dangerous.

Rather, say that "any hostname used by the the client must be a name that 
the server recognizes as being its (the server's) name.  TLS requires this 
too, of course."

>> I suspect (fear) that some webmail programs would get the idea that it will 
>> be more "efficient" to use URLFETCH rather than SELECT/FETCH/etc.
> circumstances (such as when the object referenced by the URL were 7 or 8 bit, 
> and there was no need to rebuild the summary display).

Wrong definition of "efficient".  The definition is "efficient" as in 
"lazy programmer doesn't want to bother to think about how to do it 
right."

-- Mark --

http://panda.com/mrc