Re: mailserver URL

>Arbitrary header fields introduce an unacceptable security hazard.

Um, we went through this, and I don't think anyone expressed agreement with
you on the mailing list. Header fields are just header fields: they only
become hazards when the message is actually sent. People on the list showed
examples of other valid URLs that have the exact same hazards in them.

If you propose to modify RFC1738 so that no URL can possibly send a message
to an SMTP port that contains any header field other than "Subject", I
would certainly change mailserver draft to have that same limitation.
Otherwise, mailserver is no less safe than the URLs that are already out
there. Similarly, if you modify RFC822 so that nothing other than "Subject"
headers are allowed for security reasons, I'd certainly change the
mailserver draft.

It seems unnecessary to have a URL that is more restricted than the
transport protocol it is helping users access. We're trying to write specs
that are scalable.

>In addition, both subject and body should be restricted to disallow
>the hex codes for CR and LF (%0D and %0A).

Why? There are no security concerns for CRLFs in header fields as long as
the user can see the message in the mail-sending client before it is sent.
And I don't see how restricting them from the body will help security at

>Also, the security section
>should contain a warning to user agent developers to be aware of the
>security limitations of an external mail agent if one is used to handle
>the message.

This is a valid security concern, but it is outside of the scope of a URL
that is not extending the underlying RFC822 protocol.

Since this is clearly a major concern for you, I suggest you write
security-related RFC that addresses these issues in their full scope,
namely anything that can talk to the SMTP port in an automated fashion.
That includes most mail clients (few tell you all the headers they are
including), any URL that can send a message to an alternative port (http,
gopher, and so on), and mailserver.

>If people feel this is too restrictive, than I suggest that the name be
>changed to "mailmesg".  That is what has been defined by the current draft.

That is fine with me. We could certainly make it two URLs (mailmsg as what
I have, mailserver as what you propose). It seems unnecessary, but we seem
to be aiming towards more than one URL for WAISish requests and such. Heck,
you could even have your name on another Draft, Roy! :-)

How does the rest of the list feel about two URLs instead of one?

>I would allow a restricted mailserver URL to be implemented on our
>systems -- its usefulness would justify the risk.  However, I would
>never allow a "mailmesg" (or its equivalent) to be implemented -- the risk
>is simply too great to allow arbitrary messaging within a URL.

Um, how would you prevent a URL from being "implemented"? If you have
complete control over every possible URL-interpreting client at your site,
and every one of those clients allowed you to allow or block particular
URLs, that might be possible: this seems a tad unlikely.

Please don't interpret this as meaning I don't care about security: I
really do. But I don't believe that restricting features from a URL (as
compared to restricting them from a transport mechanism) will achieve
anything real in making the Internet more secure. Just the opposite: it
will add a false sense of security for one URL when the other URLs pose the
same problems and don't even come with warning labels about showing users
the effects of resolving them.

Received on Friday, 27 January 1995 12:19:41 UTC