2002-11-05 08:58:52
Earl Hood wrote:
Some initial comments about the script (which you are free to ignore :-):

Thanks for your comments!

I'm smart enough not to ignore them, Earl. I haven't very much Perl
experience, and compared to you I'm definitely a beginner...  The
modified script is available at

Some of your suggested changes I have not (yet) made, though. These are
some comments/questions with respect to them:

* The initial BEGIN block is probably not needed.  Fatal messages
  should be sent a log file to avoid any potential sensitive
  information showing up in someone's browser.  Error messages the user
  see should not be some Perl error message, IMHO.

Please note that the script is intended to be password protected in some
way, and the "user" can be assumed to have at least FTP access. (I made
a change, so that the 'fatalsToBrowser' routine is not imported when
running the refresh() routine, which anybody can do.)

I have tried to make the installation easy, and error messages in the
browser is undoubtedly convenient when you are installing a CGI script.
I could of course import the 'carpout' routine instead of
'fatalsToBrowser', or do something similar, but I don't understand the
reason for your concern.

What have I missed?

* The following statements appear to open up a vulnerability:

if (!$ENV{'HTTP_USER_AGENT'} or $ENV{'HTTP_USER_AGENT'} =~ /^libwww-perl/) {
      exit (autoupdate());          # if not invoked from a browser

  What prevents anyone from causing the autoupdate() routine to be

Not much. Other than you need to know that the script is there...

But what can happen? If $pop3 is enabled, invoking autoupdate() only
results in an archive update, i.e. if there are any new messages.
Otherwise an arbitrary message may be added, but that's about it.

  It appears no password is checked before this statement is invoked.

True. I didn't use password protection here, since I wanted to make a
simple pipe from for instance a .forward file possible.

  This appears to allow someone to do a DoS against the the popserver

Not sure what you mean by that.

You may think I'm naive, but to some extent I simply rely on
hackers/crackers/whatever having more exciting things to do than causing
some minor inconvenience for somebody who maintains a mailing list
archive. ;-)

* The updatembox() could be written to prevent a large amount of
  memory getting used.  At a mimimum, store the passed in message data
  into a single scalar
  Note, an array containing each line of a message takes up more
  memory than a single scalar containing the entire message text.

So far I understand, and now STDIN is stored in a scalar. But I haven't
used the code you suggested in this respect, since I'm not comfortable
with references in Perl, and I avoid using code I don't understand.

If you can explain what the point would be, I'd be happy to do some
reading. :)

* In the shell() routine, you may want to use ... I'm
  not sure if anyone has bothered to make a module out of it.

Did that. I found Text::Shellwords in CPAN, but it seems totally
redundant to me, since only includes one subroutine. On
the other hand, it was Lincoln Stein who wrote it, so I guess there is a sensible reason for its existence...

I do not have a problem with including it in the contrib/ directory of the distribution. Of course, keep a version available from your website so you can update independently from MHonArc releases. I can list a URL in the contrib/ README to tell people were the latest version is available.

That's what I had in mind, and it makes me proud that you want to include it. I'll be happy to keep a version available at my site.

You may also want to mention a supplementary script I'm using for forwarding messages to a copy of at SourceForge:

(SF doesn't provide email service, and the ability to 'talk' to other servers via e.g. Net::POP3 has been disabled.)

/ Gunnar

To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the

<Prev in Thread] Current Thread [Next in Thread>