Re: lynx-dev internal links

[Nelson Henry Eric]

> Well said.  Lynx should protect the administrator's interests for
> captive accounts; for shell accounts, either the necessary protection
> is configured in sendmail or Lynx can do nothing -- I can send
> anything I want simply by piping into sendmail.  Fix the
> weaknesses for captive use; ignore them for shell.
> 
> BTW, is Henry willing at least to disclose whether the weakness
> found exists for captive accounts?  I couldn't discover it by

I understand what people are saying here.  Somewhere I must have
chosen the wrong wording or something.  I'll apologize again, thank
Michael very much for waking me up, and try again to explain.

The only point I'm trying to make is that that "Lynx can do nothing"
is true now, but it doesn't have to be that way.  Lynx can quite easily
be made to reject improper input that will allow the fabrication of
bogus headers.  I know that I can "send anything I want simply by piping
into sendmail".  The problem is that Lynx facilitates that for anyone,
including a user in a captive account.

It is very convenient for Lynx to have internal mail.  The P)rint
option, "Mail the file", for example, is really great for captive
account users who often have no other way to get copies of Web
documents.  Also, with internal mail available, FORMs can be set up
with the POST action to increase the available services to such
account holders without putting a lot of work on the administrator.
I really would like to keep internal mail services, but I cannot
take on the extra work of monitoring sendmail logs and comparing them
with the tcp entries should some jerk get on.

Lynx faithfully (actually while we're on the subject I'll speak more
on this below) forms  "From:" and "X-Mailer: Lynx, Version..." headers,
among others.  These will be sent along with any bogus headers that
might be sent.  Not only will the site be known, but also it is obvious
that Lynx is the mailer.  Thus, my complaint is not just for captive
account users, but that pranksters could give Lynx a bad name.  (One bad
scenario would be starting a flame war and sneaking in a Reply-To: header.)

Maybe it sounded as if I wanted Lynx to act the policeman.  That's not
really the case.  I just want Lynx to do exactly what it does, no more,
no less.  I want Lynx to retain its limited mailer capabilities; that's
why I brought up this topic in the first place.  If someone needs a full-
capability mailer, with Bcc:, Content-Type:, or whatever, then that is
when they should be calling an external application.  To give Lynx the
capability to form any header, to be a mailer in its own right, just is
not reasonable.  Lynx is a WWW browser.  There have been a number of posts
recently saying this.

*IF* it were up to me, (It is NOT, and I KNOW that.) I would rewrite the
problem function in HTParse.c to only expand escaped reserved characters
(";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ",") and no others.
My (quite possibly faulty) logic is that there should be no reason for
escaping other than to literally represent a reserved character.  Anyway,
FWIW, that is how I did my personal, unpublished hack to stop the problem.

Now, back to the From: header.  I would like to propose that Lynx no
longer support the From: header, or at least turn it off by default.  I
believe the comment in userdefs.h (UNIX):
      * The default should be to uncomment this line but there probably are too
      * many mail agents out there that won't do the right thing if there is no
      * From: line.
      */
     /* #define NO_ANONYMOUS_EMAIL TRUE */
is out of date.  Mail agents which cannot determine the correct From:
header must be in the minority in this day and age.  I don't think Lynx
needs to cover up for lazy sysadmins.

This really will be my final statement on the topic.  I have neither the time
nor the patience to continue.

__Henry