Comments on Klensin's concerns about mailserver

>* 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.

Nope, we didn't consider this. I think this is well outside the realm of
the URL scheme since it completely depends on the kind (and quality) of the
mail client that processes the URL. I can see the problem here, which is
that I didn't emphasize "client software" in the I-D, although we talked
about it a great deal in the WG. If there are no objections, I propose the
following change to the I-D:

At the end of the paragraph which currently reads:

Client software would prepare a mail message with the given <subject>
text as the subject header field and the <body> text as the body of the
message. <subject> and <body> may have zero length.

Add the sentence:

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

>* 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.

To me, the "or whatever" is the important part here. I don't see URLs
linked only to the Web. Interpreting the mailserver URL scheme will cause
response that will come back to the user, not necessarily through the
program that the user ran to interpret the URL. This is exactly the same as
with the mailto scheme, and I think it is perfectly OK to have URL schemes
that don't return results in the client that interpreted them. In the
future, Web clients may in fact encompass email, but it doesn't matter for
the purpose of mailserver and mailto that most don't do it today.

>* 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.

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...

>* The WG noted the fact that a number of mail-based servers require
>per-user passwords (or other authentication strings) in order to
>process certain requests, noted that there is no way to accomodate
>user-supplied passwords in this URL syntax, and explicitly concluded
>that those servers would never be the target of URLs.

Well, we talked about this tangentially, and didn't come up with a "never".
However, we didn't come up with any good way to have variable-content URLs,
and I wouldn't want to try to create variables for just the mailserver URL:
we'd have to create them for all URL schemes. Ducking that one, I think
that there are plenty of things the current mailserver syntax will do
without variables.

>* 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.

...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.

>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.

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

>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.

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.

>* 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.

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.

>* 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.

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.

--Paul Hoffman
--Proper Publishing

Received on Monday, 5 June 1995 19:22:38 UTC