Re: mailserver URL

>>If we want to have a mailserver URL, the format should be
>>
>>    mailserver:address[/<subject>[/<body>]]
>>
> 
> Hmmm.  This doesn't seem quite right to me.  You are requiring that a
> Subject: field be included if there is a body.  Many mail servers ignore
> the Subject: altogether.  I was thinking more along the lines of using a
> //, i.e. a blank line, to signify the start of the body.

Yep, I intended that subject and body would be zero or more chars, e.g.

    subject = *xchar
    body    = *xchar

such that

    mailserver:address
    mailserver:address/
    mailserver:address//

would all be no subject/no body, and

    mailserver:address/subject
    mailserver:address/subject/

would be subject but no body, and

    mailserver:address//body

would be body but no subject,

    mailserver:address/subject/body

would be both.

>>In addition, both subject and body should be restricted to disallow
>>the hex codes for CR and LF (%0D and %0A).
> 
> Right, that we are letting the / serve as the end of line.  Does make for a
> special case in the URL parsing, which I was hoping we could avoid, but
> it's not a terribly difficult one.

That's not really a special case -- those characters should be avoided
for any protocol that decodes the URL before using it (i.e. gopher, finger,
etc.).

>>  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. In particular, some mail agents allow special characters
>>to act as shell-escapes (to allow execution of commands within the mail
>>environment) and these need to be avoided by the user agent before
>>attempting to use the URL.
>>
> So, do we know what these shell escapes are?  I'm assuming you are refering
> to something that causes a problem on the server side.  If so, I'm not sure
> how we can come up with a list of prohibited characters.  Or perhaps I'm
> just not comprehending the risk here, in which case could you elaborate?

It is a problem on the client side if the client uses some external
application (such as /bin/mail) to handle the message.  Most posting agents
avoid this problem by using more secure mail handlers like mhmail or
just using sendmail directly.  This is the same hazard as exists for
CGI mailer scripts, but would likely be part of the client setup in this
case.

......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Wednesday, 25 January 1995 21:16:50 UTC