More comments on the mailserver URL scheme

I pass along here comments about my comments on the mailserver URL scheme.
Larry Masinter brings up some good points here, and I'd love to hear more
discussion on these before we go back to John Klensin.

Again, the following material is from Larry Masinter, not me.

--Paul Hoffman

================================================================
John asked if

>* The WG explicitly considered the implications of using MAILSERVER
>without defining a canonical return address format and decided that
>nothing else was needed. We are already having problems with
>non-repliable mail from MAILTO URLs when people try to respond to
>them; MAILSERVER essentially requires a response. At a minimum, did
>the WG explicitly decide that its advice to implementors need not
>contain advice about getting the reply address right.

and you suggested adding:

> The client software is responsible for adding all other appropriate mail
> headers, including a correct return address for the user, before sending
> the message.

I think it is reasonable to make the wording even stronger. For
example, user agents might actually check the configured user ID using
SMTP VRFY before sending local mail. (While it's unreasonable to
verify recipient addresses, verifying the source address should work
even for host behind a firewall.)
================================================================
When John said:

>* The WG explicitly considered the problems of messages coming back
>to a mailbox without the ability to relink them into the Web (or
>wherever) and decided this problem wasn't worth solving.

I think what he was referring to was the fact that in external-body
mail messages, there is a 'content-id' tag that links the reference to
any recieved mail. The current 'mailserver' URL has no way to
establish that link.

This is certainly worth considering in more detail.
================================================================
When John said:

>* The WG explicitly considered the relationship between maximum
>practical URL lengths and the sometimes-extensive information
>required by some mail servers and decided that mail servers requiring
>extensive information weren't worth worrying about.

and you replied:

>We didn't consider this, but I think it's a non-issue. I have never seen a
>mail server command that required more than 100 characters, and the vast
>majority require no more than 70, even for subscribing to mailing lists.
>I've seen longer http URLs...

perhaps others have had experience with other kinds of mail servers. I
think it might be prudent for the URI working group to establish a
'maximum reasonable length for URLs' (say 512 characters) and note
that programs and agents that attempt to deal with URLs need to be
aware of the length and not exceed it. ('Those things that require
longer strings cannot be pointed to by URLs'). This is an issue in
general for URLs but is reasonably brought to mind by the mailserver
issue.
================================================================
John said:

>* The WG noted the fact that we are seeing an increasing number of
>mail-based servers on the Internet that accept only digitally-signed
>messages to process certain actions (and will certainly see more in
>the future) and decided that, when it was necessary to deal with
>those servers, a new URL type would be invented.

and you replied:

>...or that such mail servers won't be able to have their messages formed as
>URLs at all. This is more than a "replace xxx with your email address"
>variable: it is a full-blown "determine a signature for this message"
>variable, well beyond the scope of this WG.

I don't think this is 'well beyond the scope', and in fact it was a
topic during the mailserver discussions. I think it is reasonable to
add something to the mailserver draft that explains how the mailserver
URLs are limited in not providing for substitution of variables. I
think it is worth considering whether the 'mailserver:' URL should
indicate whether or not the recipient requires or permits digitally
signed messages.
================================================================
John said:

>Editorial comment: There are many forms of RFC 822 addresses. A
>piece of undefined syntax called "encoded822addr" is not a sufficient
>definition of what is permitted or required.

and you replied:

> This comes from the mailto: spec in RFC 1738; anyone want to comment on
> that?

I'll comment that any piece of BNF imported from another draft needs
at least to be annotated as to its source.
================================================================
John says:

>Security comment: displaying a message about to be sent to the user
>is likely to be burdensome for many clients, makes common cases
>appear to be more complex than they are, and, with most users, will
>add confusion but not security.

and you replied:

> I *strongly* disagree here. In every Windows/Mac/X Web client that handles
> "mailto" that I've seen, the message about to be sent comes up as one
> simple dialog box. The message can be sent with a single click on the "OK"
> or "Send" button. In Lynx, it is more difficult, but not so much as to be
> "burdensome" since the user would have to type in the (possibly cryptic)
> subject and/or message in their text-based mailer anyways. I do not think
> that this will cause confusion, except possibly in Lynx. I do *not* want to
> see messages sent off without the user viewing them for the reasons we
> discussed before; I believe there was general agreement on that topic.

I think you missed the point of John's comment. It isn't so much that
the user shouldn't be warned or asked, but rather that an overly
complex or cryptic warning or user query often results in reduced
security; the security consideration here is that the user warning
should clearly state what is going on; e.g., not just 'OK to send?'.
================================================================
John said:

>* Please assure me that the WG considered such alternatives as
>*requiring* particular source-labelling on messages being sent out
>from mailserver URLs that would appropriately disclaim the issues
>noted in the "examples of problems" section.

and you replied:

>I not sure what is meant by "source-labelling" here, but I think he means
>message content that says "this was sent by a URL-reading client". I don't
>think that's appropriate here since many mail response systems would choke
>on such a message, and nasty folks would just leave the source label off
>anyways.

but such an annotation is perfectly reasonable in a 'Comments' field.

Comments: This message was sent automatically in response to a
'mailserver:' request from web page http://www.bad.guys.org/joke-mail

================================================================
John asked:

>* Why is the syntax of a MAILSERV URL
> mailserv:host-domain/...
>rather than
> mailserv://host-domain/... ?
>
>The latter would seem more consistent with RFC 1738.

and you replied:

> We did discuss this, and chose not to go with the common syntax for the
> same reason "mailto" didn't. The common syntax allows optional user names,
> passwords and (shudder) port numbers, all of which aren't necessary and
> could be confusing. Also, by now users are familiar with maito URLs, and
> mailserver URLs will look quite similar to them, as well they should.

I think there were a few other reasons as well. I'm less certain on
this point, but perhaps the mailserver: proposal could mention the
reasons.

Received on Thursday, 22 June 1995 14:41:44 UTC