Message-Id: <email@example.com> Date: Fri, 27 Jan 1995 09:20:26 -0700 To: firstname.lastname@example.org From: email@example.com (Paul Hoffman) Subject: 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 all. >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.