Re: More comments on the mailserver URL scheme

Although it is sounding a bit like a dialog instead of group voice, I'd
like to respond to Larry's comments. For those of you with good visual
parsers, my earlier comments appear below with">>", and Larry's have ">".

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

I agree that stronger wording in the draft would be good here, although
there is no way we can enforce it. Further, I'd like to note that this
would also apply to the existing "mailto:" URL, and we should keep this in
mind when RFC 1738 comes up for review.

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

We could bring this up in the draft as an issue and suggest to mail clients
that also resolve mailserver URLs that they keep track of this. I'm not a
MIME guru, so I'd appreciate seeing suggested wording on this from someone
else.

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

Indeed. However, I'd rather not talk about the maximum length for the first
time in this draft. If RFC 1738 is revised, this would certainly be
appropriate there. We could put a mention in this draft that mailserver
URLs over 512 characters are not advised and leave it at that.

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

...and was determined to be well beyond the scope during that discussion.

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

>I think it is worth considering whether the 'mailserver:' URL should
>indicate whether or not the recipient requires or permits digitally
>signed messages.

I'm not sure how this could happen without variables, but I'm open to
creative suggestion.

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

Agreed. The same sentence can remind the reader that the format of the
mailserver URL is derived from the format of mailto.

>>. . .security comment

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

The draft now says:

"Thus, a mail client should never send a message based on a mailserver
URL without first showing the user the full message that will be sent
(including all headers, including the subject specified in the URL),
fully decoded, and asking the user for approval to send the message."

We could beef this up by adding "The mail client should also make it clear
that the user is about to send a mail message, since the user may not be
aware that this is the result of a mailserver URL".

Of course, this should be added to "mailto" as well. Maybe that'll stop all
the null messages I've been getting from Netscape users clicking on mailto
URLs at my Web site. :-)

>... source labelling

>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

I think that is a fine suggestion.

>> mailserv:host-domain/...
>>rather than
>> mailserv://host-domain/... ?

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

I looked through all the messages I saved on mailserve, and couldn't find
any more reasons. However, I think it's a good idea to add these briefly to
draft.

--Paul Hoffman
--Proper Publishing

Received on Friday, 23 June 1995 15:06:49 UTC