Re: lynx-dev Mailing from Lynx with Pine

[Eduardo Chappa]

*** David Woolley (address@hidden) wrote in the Lynx list on Apr...:

:) > Content-Transfer-Encoding: BASE64
:) ...
:) > Content-Description: Patch for external support of mail program
:) > Content-Disposition: ATTACHMENT; FILENAME="mail.patch"
:)
:) This patch looks like a security hole to me.  You seem to be inserting
:) uncontrolled text into a shell command using an interface that has no
:) meta-character protection (you are relying on < going through OK).

Dear David,

  Thank you for looking at the patch. I will fix the uncontrolled sprintf,
no problem. Good point. Does anyone know which are the functions in Lynx
which allow me check for unescaped variables and so on. I would appreciate
input.

   I am not relying on the use of "<", I am giving an example of something
that works in my machine (and in many others), there are some other ways
to make this work with Pine (not as clean as the one proposed, but it can
be done for any system!). I would appreciate if someone told me how to do
the same with mutt and elm. If you see the code, you will notice that the
command to be executed is determined by the user, not by the patch, the
patch just gives the user the parameters to the command to be executed,
(To: field, tentative "Subject:" field and a file name containing the web
page) nothing more. You are free to ignore them if you like (e.g. You can
make the command to be executed a script, which only takes 2 parameters
parameters, or removes the ">" at the beginning of the line and then hands
it to your mailer, etc). Do you see my point?

:) - most Unix email programs given a file on standard input are unable
:) to read the console, so can only send it non-interactively;

Yes, but again, you don't have to accept that parameter, for all you care,
you can define your mailer to be:

/path/to/script %s %s %s

and script be

#/bin/sh
my_mail_program -subject "$2" $1

and do not use $3. So, this is not an issue in itself, it's a help if you
can use, and can be discarded if not needed or is not possible to be used.
That's the way the patch is supposed to help you.

:) - Pine appears to have made an inappropriate choice of MIME encoding for
:) this email; is it really that good a mailer?

The answer to your first question is that is it using mime encoding as
descibed in some RFC whose number escapes to me right now. RFC 15XX?

:)  (Also, I believe References in email should exclude the In-Reply-To
:) article.)

The standard is RFC 2822 (not RFC 822), and by reading it, I get the
impression that it encourages both headers, since they contain information
useful for contructing threads. The references header is not mandated (it
says that it should be used). Finally, don't hold Pine responsible for
that (I mean the Pine Team of couse). I made the modification to the
source myself, so that if another person uses my modification, I will be
able to see threads correctly, which is what I am after. In any case, my
modification still makes Pine RFC compliant. If I recall correctly, Mutt,
for example, uses the reference header, not the in-reply-to header, and
that may be part of the confusion. I may be way off here though, I don't
know for a fact (mutt users cas can tell me though).

  Thanks!

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/






; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden