2008-04-25: This is old, but it might be of use to someone.  Please see the parent page ../ for more up-to-date material on web-mail matters.

RedHat 7.1/7.2 > Postman - How-I-did-it

Mid July 2001    Robin Whittle  rw@firstpr.com.au

Last update 15 October 2005  Update history is at the end.

This is a verbose documentation - because I find that a lot of problems are caused by overly-terse doco which already assumes you know things that you don't.  Also, I think more people's problems will be solved if the description is full and search engines find this page better.

It is not a proper How-To - it is How-I-Did-It, simplified.

2005 October 15:

This page was originally written for now obsolete versions of Postman (1.6 and 1.7).  Please see the Version 2.0 section at the end on some extra things I had to do to get Postman 2.0 to compile and run on a RedHat 7.2 machine.   Quite a lot of the main body of this page is probably irrelevant to a version 2.0 installation.  Nonetheless, I think the standard installation documentation still leaves a lot to be desired, so if you read over it - paying attention to the pink boxes in particular - I think you will probably find some useful things.

Back to the web-mail page - with a link to how I installed Postfix, Courier Maildrop and Courier IMAP..
Back to the First Principles page for the world's longest Sliiiiiiiiiinky, corsetry ads, and all sorts of things . . .


Intro

This page describes how I installed software on a Red Hat 7.1 system using Apache.  This is not a How-To or a complete tutorial on setting up mail servers etc. for those who have never done it before, but it is a more complete documentation than is typical of IT stuff.  Part of the reason for that is that I will forget all this quite soon (Unix systems admin is not all I do) and will want these various related things well documented for my own assistance in the future.

Please let me know if you are using Postman, and especially if you make any improvements to it

Please don't me ask for assistance with installing Postman - if it isn't written here, I don't know it!  There is no Postman mailing list, but if a few people start installing it, then it would be good to establish one.

This page describes the following improvements to the Postman source code:



What lies below is what I did in early August 2001, with Postman 1.6.

On 22 August 2001, Agustin wrote to me about version 1.7:

Hello, Robin!

I have had some time to work in Postman software and I have read
at great length your doc.

CHANGES to Postman (to 1.7):
----------------------------

Changes I will put (I think of that week) as Postman 1.7. I am still
testing it.

- Compiled and tested with c-client imap-2001.BETA.SNAP-0108162300

- Changed a little the Postman docs and configuration files to reflect

  your comments in the installation.

- Changed the Postman defaults to your suggestions.

- Changed the login screen to do not cache it. Now, when you
  press the browser Back button, user and password are not there.

- Added your changes to the source to reflect the time of the messages
  and present it sorted by SORTDATE, not SORTARRIVAL, with some changes.

  You have two defines in Config.h to setting it:

 
  //***** MISC ********************************************
  //for display the time '(hh:ss)' for msgs in the message index

  #define DISPLAY_MSG_TIME_IN_INDEX 1

  //for use arrival date or subject date

 
  #define USE_ARRIVAL_DATE 1

 
  The time only will be show in the messages of the current year.

- Some bugs cleared.

- Changed the Language.cc. Some button captions I have no changed
  because I think of these are very longs.

- Change icon back.gif.

- Changed TEXTAREAS to WRAP=HARD.

- Changed the minimum time to refresh to 1 minute.

- Now the mailboxes list is sorted without case sensitivity.

- Reformated the AddressBook screen (and his help screen).

COMMENTS:
---------

- I could add the code to c-client will sort messages by flags. But
  there are one problem. The searched flag is not standard and it is
  handled by me
. ???

- Admin can avoid Postman being used by unauthorised persons with the
  flag in interdaemon.cfg

  ;0 for no, 1 for yes
  allowotherimapservers = 0
 
- In Setember I will create a mailing list to Postman. The postmaster
  is in holidays!
 

Postman

Postman is a C++ Web Mail client, written in 2000, by Jose Agustin Lopez BuenoAgustin.Lopez(at)uv.es of the University of Valencia on Spain's Mediterranean coast.  Postman's Net abode is:
 http://www.uv.es/postman/postman.html
August 2002 update: I see that the latest release has a version number of 1.12, and now supports sorting by thread (the subject line, or perhaps by headers pointing to previously referenced messages) and the ability to access Usenet newsgroups, which is a totally different thing from email.

Features include:
GPL license
IMAP support
Multiple folders support
MIME support (send and receive)
Programmed in C++
Addressbook
Optional cookies
No Java, no JavaScript  (but cookies and Javascript are typically used)
Search mails
Setting of user preferences possible
No reconnections. The connection maintains open.
To these I would add:
>600k of code, programmed by one person.  Salute!

Comments in Spanish but doco in English.

Any mailbox can be used for Sent mail, since if the From address is the same as the user's address, then the "To:" address will be displayed in the From column of the mailbox index, preceded by "To: ".  This is an excellent feature and overcomes the typically limited (usually only one) number of mailboxes in other mail clients which can properly display the destination of sent messages.

The mailbox index page can display any number of messages.  The user controls the number, and typically 10 to 15 is fine for most uses - but Postman can list an entire 9,000 message mailbox (for instance) on a single easily scrollable page.


Here are the doco files:
pmdocs/Postman-1.6-README.txt
pmdocs/Postman-1.6-INSTALL.txt
From the README:

"POSTMAN" is a WebMail client of high performance.

Postman is a client of Mail with interface Web designed and programmed in
the Service of Computer science of the University of Valencia. The program
has been developed in answer to the necessities raised in our University in
the matter of easy, safe, accessible electronic mail and of high performance;
necessities that then did not find solution adapted in the different programs
available in the network. Concretely, the conditions were (in addition to
elementary of facility and the comfort of the interface):

  - Client IMAP, with possibility of using several mailboxes by user.
  - That maintained the connection with server IMAP during the user session.
  - Support, in a same machine of a high number of sessions (several hundreds).
  - "shareware" or "freeware", "open source".

The development of "Postman" took place then having these conditions in
mind, as well as the characteristics, strong points and weaknesses of many other
studied clients "WebMail" with anteriority.

Like result of it, the main characteristics of Postman are at the moment:

  - Open source.
  - All codified in C and C++.
  - Only HTML. No cookies, no Java, no Javascript.
  - Support for IMAP protocol.
  - The connection maintains open.
  - MIME supports (read the "mime-torture-test-mailbox" successfully).
  - Support for send several attachments.
  - There is no transfer of passwords during the session: the password is only
    sent once in the beginning.
  - It can work under safe server (SSL).
  - Support of address book, signature and several mailboxes in the server.
  - All the system works under a same user of UNIX. Not setuids.
  - Support multilanguage (until now translated English, Spanish and Catalan).
  - Complete help for each screen.
  - Aesthetic and ergonomic interface.

And, in addition:

  - Selecting and operating with multiple messages simultaneously.
  - Possibility of use of button BACK of the navigator without loss of
     synchronism with the server.
  - Storage automatic of sent messages and dump of a whole mailbox.
  - Selective resent of attachments in Replies or Forwards.
  - Draft storage between sessions.
  - He is able to show attached HTML with images enclosed "in-line", the URLs
     within the messages are like "links" effective.
  - Automatic commutation of server IMAP based on table user-server.
  - Filters to avoid multiple connections (multiple pulsations of buttons) and
     automatic locking of previous connection in case of reconnection.
  - Optimized occupation and response time of memory.
  - Dynamic identification of which it is the process that takes care of each
     user.
  - Timeout for forgotten sessions.

Functions IMAP and MIME implemented via libreria standard c-client of the
University of Washington (written by Mark Crispin, the author of specification
IMAP). The shipment of attachments is made by means of "Form-based File
specified Upload" in rfc1867.

Postman is made up of two elements: a small called cgi-bin every time by
the WWW server, and "daemon" permanent in charge to send the servers (one by
user session) who take care of the cgi-bin and who maintain the connections
with servers IMAP.
 

Here is my account of installing Postman 1.6 of 4 June 2001 postman16.tar.gz. The installation instructions are in green.

Compile imap c-client from University of Washington.
You do not need make a install of the imap sources!
I have tested with Postman the imap release 4.7 and 2000.

You can get some of then from:
    ftp://ftp.cac.washington.edu/imap/

 or from our ftp server
    ftp://ftp.uv.es/pub/unix/imap-4.7.tar.Z
    ftp://ftp.uv.es/pub/unix/imap-2000a.tar.gz

Put the imap sources at the same level that postman sources. Something like:
    /sources/imap4.7
    /sources/postman

The University of Valencia Postman site currently (18 July 2001) says:
Postman is tested with the next c-client libraries
(please, if it is possible, use the first):
  imap-2001.BETA.SNAP-0105251616
  imap-2000c
  imap-2000a
  imap-2000 RC 3
  imap-4.7
I looked at the UW site for the latest versions:
ftp://ftp.cac.washington.edu/imap/
There is a file there:
imap-2001.BETA.SNAP-0107112053.tar.Z   July 11
I am sus about being too bleeding-edge here.

I decided to get imap-2001.BETA.SNAP-0105251616 from the University of Valencia site.

Inside that, I found a directory /src/c-client/ but it does not have its own makefile.

 
PBUG   <<<  Means what I think is a bug in the Postman documentation or software.

It was not clear to me exactly which part of this source code IMAP is needed by Postman.  What is the "c-client" anyway?

Is this just a way of saying that Postman needs an IMAP server?  Probably not.

http://www.washington.edu/imap/IMAP-FAQs/faqs.xml
and http://www.washington.edu/imap/documentation/drivers.txt.html
leads me to think that it is a library when enables a program to talk to an IMAP server. 
Network protocols supported by c-client drivers are the Internet Mail Access Protocol (all versions: IMAP4rev1, IMAP4, IMAP2bis, and  IMAP2); the Post Office Protocol (version 3); and the Network News Transport Protocol (NNTP) . . . 
This make sense.  But how does the Postman compilation process? 

Later I found out it is specified by editing the Postman's Makefile. 

Later, by looking in the Makfile, I see that Postman uses the c-client.afile, (and a lot of .h files, I guess too), which I guess is linked into the interdaemon binary - Postman's persistent server daemon. 

I create the following directories:
/opt/postmansrc/imap010525/
/opt/postmansrc/postman/
So the c-client code is at:
/opt/postmansrc/imap010525/src/c-client/
Now, reading again:
Compile imap c-client from University of Washington.
You do not need make a install of the imap sources!
I interpret this as meaning that I compile the code in the IMAP tarball, but do not install the resulting executables. (But there seems to be no "install" function in the Makefile.)
 
PBUG 

I think there needs to be some specific instructions on how to compile the UW IMAP stuff and exactly which parts of it are needed by Postman.

Presumably there will be an object file there which will be linked into a Postman executable.

The IMAP installation instructions in docs/BUILD/ tell me to:

make slx
I give this as root.  There was a message about building without SSL support.  There were some warnings regarding "passing arg 3 of scandir from incompatible pointer type.

Now, back to the Postman instructions:

-Create an UNIX user to run the daemons (must be part of the web group).
-Edit and setup the next files: Makefile, Config.h and files/interdaemon.cfg
-Run make
-Run make install
There is no "web" group on my machine, but there is user and group: apache . (As in /etc/passwd and /etc/group .)

Later in the INSTALL doco, it indicates that this user should have a particular home directory and shell.  I am unclear what the significance of the "www" group is.  Is this the group of the web server?  (Later I find that "www" is the typical the group of the web server on HP Unix installations.)

# grep postman /etc/passwd
postman:*:37:102:Postman user:/var/postman:/sbin/sh
# grep postman /etc/group
www::102:www,postman
There is no /sbin/sh on RH7.1, and the default shell is /bin/bash, to which /bin/sh is a symlink.

I created a user postman with:

useradd   -d /var/postman -g apache  -r  postman
"-r" means create a system account, something I spotted in man useradd . This gives a low user ID and does not create a home directory.  In my system the user ID was 100 and the group was 48.

This worked fine, but did not create a directory /var/postman . So I created it, user postman, group apache, permissions 750 as per the example in the INSTALL file.  Maybe it was going to be created in the intall process .

 
PBUG 

Some more guidance about creating this user account would help.

What significance is the "web" group which in the examples is actually "www".  This is probably the same group as the web server, but this should be stated clearly.

How important is my use of "-r" to get a low user ID?
 

In the following, I show the original text in blue and the changes I made in red.

Editing Makefile

REALCGI         = /usr/local/apache/cgi-bin/postman
REALSERVER      = /usr/local/sbin/interdaemon

REALCGI         = /var/www/cgi-bin/postman
REALSERVER      = /usr/local/sbin/interdaemon

Initially I had the above line set to /usr/sbin/interdaemon but it proved not to be wisdom.  Two startup scripts were put in /usr/local/sbin/and they expected the daemon itself to be in that directory too.

WEBGROUP     = www

WEBGROUP     = apache

(Apache doco indicates that on HP machines the web server's group may be www.  With RH7.1, it is apache.)
 
 

WEBHTDOCSDIR = /usr/local/apache/htdocs

WEBHTDOCSDIR = /var/www/html

This is the root directory for where Apache serves its files from!  A directory postman will be created there.  This was one thing I did not understand the first time I tried.  See also the POSTMANDIRitem in Config.sys, which is typically the above setting, with "/postman" added.
 

C-CLIENTDIR  = ../imap-2001.BETA.SNAP-0105251616/c-client

C-CLIENTDIR  = ../imap010522/c-client
 

SRC          = /usr/local/FUENTES/POSTMAN/postman

SRC          = /opt/postmansrc/postman
 

CGIUSER      = root
CGIGROUP     = root  <<< Should be www to match examples in INSTALL.
SRCSERVER    = $(SRC)/interdaemon
SERVERUSER   = root
SERVERGROUP  = root   <<< Should be staff to match examples in INSTALL.

CGIUSER      = root
CGIGROUP     = apache
SRCSERVER    = $(SRC)/interdaemon
SERVERUSER   = root
SERVERGROUP  = apache
 
 
PBUG 

More explanation of all these Makefile variables is needed!

The CGIUSER and CGIGROUP are for the executable programpostmanwhich goes in the cgi-bin directory.    Presumably this group should be "www" to match the example of the resulting files in the INSTALL file.

The SERVERUSER and SERVERGROUP are for the interdeamonexecutable which runs in the background, and is started by the interdaemon. Presumably this group should be "staff" to match the example of the resulting file in the INSTALL file.

I found that make install did set the group of interdaemon correctly (to "apache") while it was in the source tree, but that when it was copied to its final location in /usr/local/sbin which is user root and group root that its group was turned back into root again.  This is presumably due to it being copied by a root command, to a directory owned by root.  It does not seem to matter to me, but this should be noted in the documentation what its owner and group need to be.  Since  interdaemon  (or rather its start-up script /usr/sbin/inderdaemon.ini ) will need to be started at boot-up time by a root process, perhaps there is no need forinterdaemonto be in some other group.

Editing Config.h

Quite a bit of the following information was determined once I got Postman running.  It is not necessarily obvious to anyone installing the system for the first time.  I think all these configuration items need to be fully documented.
 

#define POSTMANDIR "/usr/local/apache/htdocs/postman"

Be sure to change this!  If you don't, you will besorry.  I was!  I spent hours trying to figure out some problems listedbelow.

Be sure to change it to the directory where you will put your postman directory so the web server can see it.  This contains icons, login pages and help pages.  (Actually, the icon location is specified separately, with reference to the web server's document root.)
For me, POSTMANDIR, should be:

#define POSTMANDIR "/var/www/html/postman"

If you don't do this, then the URL:
cgi-bin/postman?lang=eng
and also the Confirm button when logging out, will cause a browser error because Postman gives it a file with 0 bytes.

Furthermore, you will wonder why the login files such as  /var/www/html/postman/postman_eng.html don't do what you (falsely) expect.  These files are not supposed to be used directly, but for Postman to process and serve up as login pages, with a few changes.  For instance the part where it says:

name=imapserver value="#"
will have the # turned into the name of  the server computer Postman is running on. (Unless you specify a complete server name in place of the "#".)
//1 Allow several connections from the same user using that program, 0 only one
#define ALLOW_SEVERAL_CONNS 0

#define ALLOW_SEVERAL_CONNS 1

I changed this to 1, so I could run several sessions of Postman running on the one account if I wanted.  I tested it a little.  It does seem to support multiple sessions - including two sessions from the one browser machine with two separate web browsers, such as MSIE and Netscape and another session from another browser computer.   You can't have two sessions with the one browser on the one computer - even if one is HTTP and the other HTTPS.    No matter how many sessions you have from multiple browsers and computers, for the one user, there is only one place where the Compose text can be saved (in that user's entry in Postman's /var/postman/users/ directory.  However, the individual Compose windows can send their messages perfectly independently.
 

The 20 minute timeout item is:

#define DEFTIMEOUT 1200

There are many other settings, such as for colours and whether or not to calculate the mailbox size.
 

#define REPLY_BEGIN_LINE "> "

Hoorah for this being right!  There are so many email systems which do something else - HotMail, when I last looked, had ">" but not "> ".

I think the default 30 high 70 wide message compose window should be 72 wide, and not so high, because on 800x600 screens, with cluttered browser menus (The Windows Start bar on, all toolbars, big buttons at the top) there is not much window space available and one or both scroll buttons could be outside the window.
 

#define DEFOPT_SAVEMSGSENTMAIL         false

#define DEFOPT_SAVEMSGSENTMAIL        true

I set this to true because I think people generally want to save what they send.

#define DEFOPT_WIDTHWRITEAREA          70
#define DEFOPT_HEIGHTWRITEAREA         30

#define DEFOPT_WIDTHWRITEAREA         72
#define DEFOPT_HEIGHTWRITEAREA        20
 

I made it 24 x 72 - but I recommend experimenting with it on a large installation where this affects many people.  If they all have 1024 x 768 screens, with their browsers running full screen, then 30 or so lines might be more appropriate.

#define DEFOPT_TRUNCATELENGTHREADINGMSG 80

#define DEFOPT_TRUNCATELENGTHREADINGMSG 90

Make it not wrap long lines of text so aggressively.  This may affect how some messages print out, so perhaps this should be looked at more closely.  These are user settable options, but it is good to provide sensible default values.
 

There are some other things to check here, such as the default sent-mail folder.  Unless you alter this Config.h file, Postman uses "sent-mail" as does IMP and SqWebMail.
 

#define MAXTEXTSIZEATTACHFORDISPLAY    10000

This presumably limits the size of HTML, text or maybe graphic attachments which will be automatically displayed.

There are font specifications - for font face and size.

#define MIN_TIME_TO_REFRESH 2

#define MIN_TIME_TO_REFRESH 1

I changed this to 1 minute.  Note that with the standard setting, I think the user should be told there is a minimum limit.  Otherwise they set it to 1 minute, safe the options and assume that this is set.  But in fact, it is set to 2.  I altered the text in the Config page to reflect the default 2 minute minimum setting - so if you use my Language.cc file, make sure what it says there for L_REFRESHTIME is correct.  See below.

//****************  DISPLAY EN INDEX
#define LONGDISPLAYSUBJECT 35
#define LONGDISPLAYFROM    20

#define LONGDISPLAYSUBJECT 45
#define LONGDISPLAYFROM   25
 

These affect how long the "From:" and "Subject:" displays are in the mailbox index.  These values ( 35 and 20) seem to be good for a 640 wide screen.  I guessed some larger values (45 and 25) for giving more characters, but still being usable on an 800 wide screen.  I would make them wider still if I knew everyone was using 1024 wide screens.  These are not precise values, since the width on screen also depends on the characters.  For instance "iii" is not as wide as "WWW".  It seems that the minimum width of the mailbox index table is controlled, in part, by the longest "From:" line and the longest "Subject:" line.   The idea is to make it so that in general, unless people send messages titled: "WWWWWWWWWWWWWWWWWWWWWW", that the table will always display properly inside the user's available browser window width.  The user can select the number of messages to display per mailbox index page.
 
 

Editing files/interdaemon.cfg

This has settings such as the maximum number of connections - 300 by default!  It turns out that this file will be copied to /usr/local/etc/interdaemon.cfg where it can be edited to control things at runtime.  So it may not be important what this file is during compilation.

;default domain to suffix the ip name when its do not have points
;   example: something like "myserver" will be changed to "myserver.uv.es"
defaultipdomain       = .uv.es

defaultipdomain       = .firstpr.com.au
 
 
PBUG

Would a better explanation be:

Suffix to add to user name when sending email.  So userxyzwill send mail with the Sender: address xyz@uv.es .
Or maybe I have misunderstood it.   Maybe it is what gets added to a single word in place of the "#" for the IMAP server item in the login form.

Actually, I have no idea what this does.

;0 for no, 1 for yes
allowotherimapservers =0
 
 
PBUG

What does the above option do?

I guess it controls whether Postman will be able to access IMAP servers on machines other than the one it is running on.

This relates to the later section of files/interdaemon.cfg .  I don't understand it at all - so a fuller description is needed. 
 


 

;in seconds
timeout               = 1200
 

This is how many seconds - 20 minutes in this case - Postman's timeout is.  The user must do some activity within this time otherwise the session will no longer be active and they will have to log in again.  Part of this is a Javascript timer in the Compose window which pops up five minutes before the timeout is due.
 

def_user_not_in_db    = post.uv.es

def_user_not_in_db    = firstpr.com.au
 
PBUG 

What does this option do? 

Does it get added to their user name and "@" to form what Postman understands as their full email address?   I don't think it does - I don't know what it does.

;true for best security!
use_cookies           = 1
;no important
use_javascript        = 1
 
PBUG 

Again, explanation of these options would be valuable.
 

There is a series of sections at the end of interdaemon.cfg which are, for example:

[post.uv.es]
imapserver     = post.uv.es
imapport       = 143
smtpserver     = post.uv.es
maildomain     = uv.es
mailboxprefix  =
remotepath     = ~/mail/

In my case, I wanted the machine "zair.firstpr.com.au" to run Postman, and to also be the IMAP sever, and the SMTP server.  However I did not want mail sent from a user blah to be sent with the From: line (Actually it is part of the SMTP envelope - set by the SMTP handshake, see SendMSG.cc line 236.) of blah@zair.firstpr.com.aubut with it set to blah@firstpr.com.au .  The way to set this is with the "maildomain" varialble.  Here are the settings which worked for me, with my Courier IMAP server.  I had only one such section - I got rid of the other sections which related to uv.es servers.

[zair.firstpr.com.au]
imapserver     = zair.firstpr.com.au
imapport       = 143
smtpserver     = zair.firstpr.com.au
maildomain     = firstpr.com.au
mailboxprefix  = INBOX.
remotepath     =

I am not sure what the "remotepath" variable is, but I guess it is to do with telling the IMAP server where to find each user's mailboxes.  In the case of Courier IMAP, this is already defined as being the directory "Maildir" in the user's directory - and this is both the Inbox and the place where other mailboxes and folders of mailboxes reside.
 

Compilation

I gave the command:
make
It didn't get very far!  The compiler complained about a parse error on lines 752 and 753 of /c-client/mail.h which is a symlink to/src/c-client/mail.h  .

This is thoroughly sus!  Here is the error report followed by the sus code in red.  The variables

In file included from c-client.h:49,
                 from IMAP.h:16,
                 from IMAP.cc:5:
../imap010522/c-client/mail.h:752: parse error before `or'
../imap010522/c-client/mail.h:753: parse error before `not'
 

SEARCHPGM {   /* search program */
  SEARCHSET *msgno;  /* message numbers */
  SEARCHSET *uid;  /* unique identifiers */
  SEARCHOR *or;   /* or'ed in programs */
  SEARCHPGMLIST *not;  /* and'ed not program */
  SEARCHHEADER *header;  /* list of headers */
  STRINGLIST *bcc;  /* bcc recipients */

So the UW-IMAP code uses keywords like "or" and "not" as variable names!

I changed them to "orrwfixed" and "notrwfixed".  Sheesh!

Now I guess have to find all references to them . . . which the compiler can help me with!  But there are no apparent problems . . .

This code already worked with the IMAP compilation, it is just being included here in the Postman compilation, so perhaps in the IMAP compilation the compiler flags coped with these really sus variable names.  Presumably, these variable names are not used in the Postman compilation, since I got no errors when I did "make" again.

 
PBUG 

This compilation problem needs to be documented, or perhaps there are some extra compiler flags which could be set to make the Postman compilation ignore these stupid variable names. 

The only way I could get it to work was to compile the UW IMAP stuff and then change one of its files before compiling Postman.

Then I tried "make install".

The final step of this is to give the following command:

/usr/local/sbin/interdaemon.ini start
This runs a command line (here split into four lines) as user postman :
( su postman -c
"PATH=. HOME=/var/postman /usr/bin/nohup
interdaemon /usr/local/etc/interdaemon.cfg
>/tmp/interdaemon.out 2>&1 &" ) && echo "interdaemon"
but I got an error:
bash: /root/.bashrc: Permission denied
followed by the "interdaemon" echo.

I fixed the error by setting the world execute permission of directory /root. This doesn't sound very wise from a security point of view, so I think there is something which should be fixed here.  I am not quite sure why the system is trying to access root's .bashrc, but I guess it is because I am root giving this command.

Once this was fixed, I still couldn't see any interdaemon program running with:  ps -fax

Trying to debug this startup script, I changed to user postman and went to /usr/local/sbin/. There I gave the command:

PATH=. HOME=/var/postman /usr/bin/nohup interdaemon /usr/local/etc/interdaemon.cfg &
I got rid of this bit:
>/tmp/interdaemon.out 2>&1
which took the stdout and stderror of the command line and wrote them to/tmp/interdaemon.out .

I used "info nohup" to learn about it because "man nohup" wasn't much good.

The main command line causes nohup to run the rest of the line "with no interrupt signals, so it keeps running in the background after you log out".  But a trailing "&" is still needed to put the command into the background.  nohup takes the standard output and standard error of the program - interdaemon in this case - and writes it to a file nohup.out . See info nohup for some more things on this output file . . . but I can't find where it is written.  It would be good to find where the stdout of interdaemon is written, to help me debug with printf() statements.

The contents of this output file, /var/postman/nohup.out for my command in blue, or /tmp/interdaemon.out for the interdaemon.ini script, is consistently:

/usr/bin/nohup: exec: nice: not found
Now, methinks . . . maybe that "PATH=." was a little restrictive???? nohupwould call nice as part of the way it runs the command, but with a path of just the current directory . . .   Maybe other versions of nohup don't work like this.

So I modified /usr/local/sbin/interdaemon.ini to change the PATH command to

PATH=$PATH:.
Then, the command would reliably start and stop interdaemon.
 
 
PBUG 

The /usr/local/sbin/interdaemon.ini start command does not seem to work.  Firstly, it is accessing /root/.bashrc which is not normally accessible to user postman since /root/ is not world executable.

Secondly, the "PATH:." part of the main command line stopsnophupfrom running, because it cannot find nice.  My fix above seems to work.  Are there any problems with this having PATH set to a large number of directories, rather than just the current one?

Also, the stop command does not report whether the interdaemon was stopped.  If it was stopped, then there is no text output. If the interdaemon was not running when this script was called to stop it, then the script produces a usage message  from kill because kill is called without any parameters.

I think there should be a restart function too.

Ideally, the installation process would add things into the System V Init system in /etc/rc.d/init.d.

However the startup is done, the documentation needs to point to this script as the way of doing it, and how this might need to be called from/etc/rc.d/rc.localor whatever.

Then, as per the INSTALL instructions, I tried the URL:

http://myserver.xyz/cgi-bin/postman?lang=eng
and I got a login page.  (Note, at first it didn't, because I had not set the POSTMANDIR value in Config.c correctly.  See above for the symptoms, including 0 bytes returning from the above URL.)
 

In the Problems section of INSTALL, is:

-Postman configuration is not yet automatized. The most problems
 are for wrong file permission or owners.
-You must have one Apache conf entry like that in /usr/local/apache/conf/httpd.conf

     DocumentRoot "/usr/local/apache/htdocs"
     ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
     <Directory "/usr/local/apache/cgi-bin">
         AllowOverride None
         Options None
         Order allow,deny
         Allow from all
     </Directory>

My scriptalias section of /etc/httpd/conf/httpd.conf is:
DocumentRoot "/var/www/html"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>
PBUG 

The Apache doco insists that Options must be set to ExecCGI but I found that cgi programs still worked if it was set to None.

Since the Apache doco says it should be ExecCGI, this part of the INSTALL file should be changed or annotated. 


 
 

Some notes on the login page files

It was not at all obvious to me how the login pages worked.  Perhaps it would have been if I had configured the POSTMANDIR  value properly.

After I couldn't get any sense from the program accessed directly as a cgi-bin executable with "?lang=eng" as its parameters, I assumed that the files in /var/www/html/postman/ of the form postman_xxx.html were supposed to be used as login pages.

But they are not meant for this.  They are meant to be read by the postman program and processed with the addition of some announcement text to create a login page sent to the user's browser.  So when you use:

http://myserver.xyz/cgi-bin/postman?lang=eng
then you get back a processed version of the postman_xxx.htmlfile.  (At least the way I had Postman configured - and I don't understand all the configuration options for multiple IMAP servers.)

The standard file  http://myserver.xyz/postman/postman_eng.html will be reproduced fine by Postman in response to the above URL, but unless you edit the file (best do it in a text editor, not an HTML editor) one of its hidden form fields (sent to the postman program when you click the "Login" button) asks it to log in to an IMAP server "#".  Then you will get a message like:

Error: That IMAP server is not allowed!

or perhaps

Error: No such host as #.aaa.bbb.ccc

You will see in in /var/logs/messages that Postman is accessing the "pam_unix" command.

In /var/logs/mailog, the interdaemon process reports the user and that it can't find an IMAP server.

IMAP server '#' is not allowed. User 'blah'. Exiting


So be sure to edit the /var/www/html/postman/postman_xxx.html files to specify the IMAP server you want to use!

It is possible to create a totally different login page, which you can put anywhere (I only tried it on the same server) to send the required things for Postman to log you in.  These include the following Name/Value pairs, which you can see in the correctly processed login page which Postman creates.

The form's output is defined by <FORM ACTION="/cgi-bin/postman" METHOD="POST"> but "GET" will also work.  See discussion below on GET vs. POST.
 
 
Name Type of field Value Notes
cmd Hidden login Tells Postman we want to log in. 
lang Hidden eng Or "spa" or "val".
user User enters in text box  
 
pw User enters in text box  
 
imapserver Hidden xyz.abc.def Depending on how it is configured, Postman will try to log in to this IMAP server with the above user and password. 
Login Hidden Login This is generated by the login button - but Postman probably doesn't need it.

In the standard postman_eng.html file, there is some commented out stuff which can replace the hidden value for imapserver with a user editable text entry box.  There is a default value too.  I suggest a longer text box than 10 characters!

  <!--
  <b><font color="#3333CC" size=4>S</font>erver:</b><BR>
  <INPUT TYPE=text size=10 name=imapserver value="postal.uv.es"><br>
  --->

There is also a "Help" button which causes Postman to generate a help screen.

There is also an announcement and a reproduction of a text file, depending on the language, the appropriate one of the /usr/local/etc/postman.motd.xxx files.  (MOTD means Message Of The Day - an arcane Unix service which I know nothing about, but which I suspect is a functional equivalent of fortune cookies.)  The part of the file which Postman recognises is:

</TABLE>
</CENTER>

^ INC /usr/local/etc/postman.motd.eng

</BODY>
</HTML>


It is possible to create a completely "custom" different login page.  Provided it sends the details back to the /cgi-bin/postman program on the server, then it will be an effective login page.  However, if the login fails, then the user will need to use the Back button to go back to the "custom" login page.

What Postman normally does, when a login fails, when a user logs out, or if it is called with no parameters at all:

http://myserver.xyz/cgi-bin/postman
is serve up a login page, based on one of the postman/postman_xxx.html files.  It will use the eng page if there are no parameters, or the appropriate language's page based on its last command.

To to make a totally seamless set of customised login pages in all three (or whatever) languages, one should edit the files:

/var/www/html/postman/postman_eng.html
/var/www/html/postman/postman_spa.html
/var/www/html/postman/postman_val.html
appropriately, at least to include the IMAP server you want to connect to.

It would also suffice in a solely English-language situation to customise just the first one, and take out the links within it to pages of other languages.

Here is my customised page, which includes a bunch of introductory help material to get people up to speed and to point out some unusual aspects of Postman, such as the way its Compose page cannot save to a "Drafts" mailbox.

pmdocs/postman_eng.html
You may want to have another page somewhere to point to the urls:
http://myserver.xyz/cgi-bin/postman?lang=eng
and
https://myserver.xyz/cgi-bin/postman?lang=eng
so users can easily choose between normal and SSL secure sessions.
 

Note, I do not understand the various configuration file options for multiple IMAP servers.

The following assumes that Postman is configured to be able to access the IMAP servers on machines other than itself.  Generally, this needs to be restricted, otherwise anyone could access any server anywhere via this Postman installation.  (I assume this is what the configuration file achieves.)
 

Forms: POST, GET and URLs

Here, for my own reference at least, are some key aspects of forms and cgi-bin programs.

The formal definition of the Common Gateway Interface is at:

http://hoohoo.ncsa.uiuc.edu/cgi/
The Apache doco is at:
http://httpd.apache.org/docs/howto/cgi.html.en#whatsgoingonbehindthescenes
From:
http://hoohoo.ncsa.uiuc.edu/cgi/forms.html
I see:
The GET method (Note, this is the same as using a URL to encode all the parameters.)
If your form has METHOD="GET" in its FORM tag, your CGI program will receive the encoded form input in the environment variable QUERY_STRING.

 
The POST method
If your form has METHOD="POST" in its FORM tag, your CGI program will receive the encoded form input on stdin. The server will NOT send you an EOF on the end of the data, instead you should use the environment variable CONTENT_LENGTH to determine how much data you should read from stdin.

 
In the GET method, the browser combines all the parameters the form returns into a URL, and requests that URL.   So this involves no special communication.  It is a handy way of debugging a form (though perhaps not the most professional) - modify the METHOD to "GET" and fill in the form.  Then the URL can be inspected in the server logs.  It also shows up on the screen of the browser (assuming the browser isn't instructed to load some other page).

So it is possible to edit a Postman login form to make it work via GET.  Then fill it in, and see the URL it generates.

Using The URL includes the password and all - so this is insecure.  (However, it means that a login to Postman, or many other systems, can be achieved with a simple bookmark or hyperlink!)

Such URLs might appear in the logs of caching proxy servers . . .   So I am not suggesting that forms usually be in "GET" mode.  (It is worth knowing this stuff though - I wanted links which would fire up a bank currency converter, and I just encoded the parameters in the URL, so the bank's converter which normally servers responses from a POST data returned from pages at the bank's site works fine and dandy, serving a page in response to what it sees as GET form data, but which is actually a link on my website, with the currency and value built into it. See the Devil Fish page on this site.)
 


Initial exploration and comments - with reference to SqWebMail and IMP

Also some changes to Postman's source code

 
This is not a complete review of Postman, or a proper comparison with other webmail systems.  My primary comparison is with IMP 2.2.0 pre13 (I did not have a later version running when I did this exploration) and with SqWebMail 2.1.1.

Interspersed with these observations are some bug reports and fixes, including significant changes to some of the source code files.

First some general Postman / IMP / SqWebMail observations:

IMP is slow by comparison to SqWebMail and Postman.  IMP is quasi-interpreted PHP and the others are compiled executables from C and C++.

IMP and SqWebMail are widely used and have active mailing lists.  Postman is the work of one person, from what I know, and it has so far (July 2001) only been used at the University of Valencia.   I think that a wider user base and an active mailing list will enable Postman to be refined and extended.  Also, I think that the scrutiny of many people will be required to find and resolve the security problems which are in Postman.  For instance, as I noted below, the way the that the user name and password can still be seen in the browser with the use of the Back button.  (I am testing this on a Win2k Netscape 4.77 browser.)

SqWebMail does not connect to the mailserver via IMAP - it accesses mailboxes (which must be in Maildir format) on its own machine, or on nearby machines via NFS.  If those mailboxes are accessed by an IMAP server, then the server must be Courier IMAP.    SqWebMail does not do IMAP things to the mailboxes.  It does not have "Expunge" or show the T flags which show a message is tagged for deletion.  But this simplifies deletion from (I imagine) many user's point of view.  It also enables SqWebMail to so some things not practical via IMAP.

For instance, when you log in to SqWebMail, it counts all the messages in all your mailboxes and shows a list of all mailboxes of folders containing mailboxes, with their total number of messages!   Neither IMP nor Postman can do this.  They both select a single mailbox to access via some kind of list.

SqWebMail cannot sort the messages - they are always in the order they arrive in the mailbox, or is it date order?  IMP and Postman can sort in both directions on Date, From and Subject and Size.  (Note, Postman 1.6's Date sorting arrangement is actually by the "From " date at the start of each message in a Mbox mailbox, or the file date of each message in a Maildir mailbox.  See below for my changes to fix this to work on the real date in the headers of the message.)

Postman can also sort by "number" which I guess is the order they appear in the IMAP mailbox (actually, the "From " and file date mentioned in the previous paragraph), which in the case of the Inbox would be related to the time they were delivered - or the time they were copied from another mailbox, depending on how the IMAP server works.  This could be handy, I guess.  Netscape has a "Sort by order received" option.

Both IMP and Postman, to my knowledge, should only be used for a single mailbox at a time - but SqWebMail seems to work fine with multiple browser windows looking at multiple mailboxes.

With IMP, don't touch that "Back" button Daddyo!  Postman and SqWebMail seem to be happier with using Back and Forward - but beware the temptation to open multiple mailboxes with Postman - my impression is that it does not work.  Pressing a button on one mailbox can cause the actions to take place on the mailbox most recently accessed in another window, with the results appearing in the current window.  So Postman does not seem capable of thinking about more than one mailbox at a time.  Use two separate browsers for two separate sessions to achieve this.

The only way to properly evaluate these systems, especially IMP and Postman, which I think are both advanced, promising systems, is to run them yourself - so please do not make important decisions based on my observations.
 

I have not investigated how user preferences function in Postman, but I notice that there are addressbook, options, signature and other things in a directory of the form:

/var/postman/users/aaa.bbb.ccc/bl/blah/
for a user logging into blah, with the IMAP server set (as described above, in the HTML of the login page) to aaa.bbb.ccc .

SqWebMail can do something which neither Postman or IMP attempts: changing the user's password.  It works fine with my PAM and shadow password system.
 
 

This is a bit of a grab bag of comments, primarily for Agustin to consider.  Some problems may be bugs, some may be things I have done wrong, some may be things I don't understand - and so may be problems with the documentation.
 


The order of the IMAP folders in Postman's pull down menu is not alphabetical at all.  Nor is it in the unsorted Unix file system order . .   SqWebMail orders them alphabetically ignoring case, which is the correct behaviour, I think.  IMP sorts on ASCII - so upper case comes before lower case.  This is likely to be pesky for most users.

I notice that when I use Postman to access an account with a UW IMAP server, that it sees every file and directory in the user directory as a mailbox - at least with the way I have things set up.  It is not clear how this can be resolved by configuring Postman on an account by account basis - or in the UW IMAP server, which as far I know, has no configuration options.   This doesn't bother me, since I will soon be using it only for Courier IMAP, with which it works fine.


Security of password

My initial observation was:

Even if I am logged out, someone else could come along to the computer by using the Back button to get back to the login screen, which still has my user name and password.  Somehow, SqWebMail and IMP prevent these from reappearing.
Here is a deeper analysis.  Both SqWebMail and IMP seem to replace the login screen with a fresh one whenever the user clicks the "Login" button.  This has the effect of getting rid of the user name and password the browser may have retained in its "history cache" or whatever.  That solves the problem.

However Postman does not do any such thing.  On a successful login, it serves up a page at a new URL, but the browser still has the login page in its history cache.  So even after the session is logged out, or while it is running, it is possible to use the browser's Back button to return to the login page.

With Netscape, the username and password are still there.

With MSIE 5.0, the username is there, but the browser has deleted the password.  (This is what Netscape should be doing, I think, since the type of text entry box is "password".)

Since users will typically not close browser windows, then this represents a completely unacceptable security problem for Postman, as far as I can see.  Maybe there is a Javascript way of coding around this - but I don't know Javascript.  Nor can we assume the browser has Javascript enabled.

I have not fully investigated this, or determined exactly how SqWebMail or IMP get rid of the username and password - but I think this problem should be resolved before Postman is used for any large installation.


Even if the email arrives today, there is no time for when it arrives.  IMP displays the date for other days, and the time for messages which arrived today with a time.  See my fix for this in ProcesaDate.cc .


On one occasion at least, I couldn't get Postman's "Refresh" link to work on the INBOX.  I sent new messages to it, and it cannot see them.  (IMP is fine.)  Logging in again I saw the new messages. That was to a remote machine. Later, logged into the local machine, the refresh worked.  Also, the Open mailbox command, when applied to the Inbox when you are already looking at the Inbox, does more than the Refresh link.  For instance, it shows any tagged for deletion flags put on messages by programs other than Postman.

(Imp has some Javascript magic which somehow alerts the user soon after an email arrives.  But there's no obvious way to refresh the INBOX IMP - you have to click the Inbox thing on the left to see the new messages.)
 


Refreshing a non Inbox mailbox

Lets say something other than this web mail program changes the contents of a mailbox.  Perhaps it was another mail program or client (such as Netscape) or perhaps it was a freshly arrived email being filtered on the server and so being added to a mailbox.  How do the various programs cope?  None of them automatically check - since this would involve usually pointless communications with the IMAP server.

Here is what I found:

Netscape

The "Update message count" option doesn't seem to do anything.  If I close the window (or select another mailbox in it) and re-open the mailbox again, the new messages are listed - with any "tagged for deletion" messages listed with a red cross.  This is functionally good, but a bit of a pest to have to reload mailbox.  Sometimes, reading a message will update the mailbox display.  Netscape has its own cache of "Tagged for Deletion" flags, so it may continue to display messages as being tagged for deletion (if they were "Deleted" in Netscape) after some other IMAP client (for instance Postman) has reset those flags.
IMP
There is no "Refresh" command in IMP, but I was astounded that using the browser Refresh function recreated the mailbox listing in a completely updated way.  With IMP it is generally bad to use any browser buttons, like forwards and backwards, so this really surprised me.  It works, but is not something which is obvious to the average user.  I am not convinced that IMP reports the "tagged for deletion" status of messages if another program has tagged them.  Furthermore, tagging with IMP does not seem to set the flags in the server, and a reload seems to make IMP forget which were supposedly tagged for deletion.  (My IMP installation is working with Mbox mailboxes on a UW IMAP server, not MailDirs, so it is hard for me to see how they are tagged.  I only have Netscape to look at those mailboxes, and I am not convinced that Netscape is physically tagging the files on the server . . how do the "Tagged for deletion" and other IMAP flags work in an Mbox anyway?
SqWebMail
SqWebMail has no refresh function.  I found that using the browser's refresh button ended the session!  However, reading an email from the mailbox and then returning to the mailbox results in an updated message list.  (If the message you click on has been deleted, you get just a blank screen.)  Likewise, going back to the the Mailbox main index and then selecting the mailbox again will display the latest contents of the mailbox.
Postman
Postman has an explicit "Refresh" link at the bottom of each mailbox page - but only if this page contains the last message in the mailbox.  If not, it has a "Next page" link.

Postman's refreshing does not reflect whether the messages have been tagged for deletion by another program.  (Netscape does really set the tag in the server when you "delete" an email.  But be wary over a slow link - let the transaction complete before doing anything else, otherwise the tag is not really set.)  Even if Postman doesn't show any messages tagged for deletion, the Expunge function still works and the tagged files are deleted.  Postman's tagging of messages on the server is immediate.
 


By some unknown process, I had a 0 byte message in the Inbox of my Maildir based IMAP server.  Postman could not connect to that account, and would not even produce an error report - there was just a generic Apache server failure report.)


Problem with the dates of messages


Postman 1.6 has a problem with the display of message dates in the mailbox index - at least with my installation accessing a Courier IMAP server which uses Maildir mailboxes.  (Probably this is true of Mbox mailbox based IMAP servers too  The "From " line - not "From: " at the start of each Mbox message is the functional equivalent of the message's file date in a Maildir mailbox.)  See the parent directory for a link to my notes on Courier IMAP and the excellent Maildir mailbox format.

With a Maildir format, each email is in a separate file. Normally, when an email arrives, the file is created and so the date of the file is the time of reception.  However, this may have nothing to do with the time the email was sent, or really received - for instance and perhaps, if the email has been copied from another mailbox.  My situation is one of converting several hundred megs of several years email in a hundred or more directories from the linear file Mbox format to Maildir mailboxes. Therefore, most of my emails have file dates of around now - nothing to do with their real date.   Postman, when accessing Courier IMAP (and probably any other Maildir based IMAP server) reports in the Mailbox index the file date - which is not related at all to the actual date of the email.

This might be a good way of date ordering emails without having to look at their real dates and calculate their actual times after accounting for timezone variations, but it makes a real mess of my older emails!

When the email is viewed, the correct date is shown - the date in the headers.  The problem I am focusing on here is the matter of the dates shown in the mailbox index.

An email's date and time is very important, and I think it is vital that Postman show the proper date and time in the mailbox index.

Also, that date is purely the date - nothing about the time.  Times are important, so this is an area in which I think Postman can and should be greatly improved.  See below for my fix to ProcesaDate.cc.

Looking at the IMAP standard:

http://www.isi.edu/in-notes/rfc2060.txt
It seems that Postman is looking at the "INTERNALDATE" - which is the file date.

The following is my exploration of the source code in search of a fix and quite a number of improvements.


The code which prepares the date for the mailbox index has nothing to do with the way the message's date is displayed when reading the message.  The mailbox index date stuff is around line line 715 of IMAP.cc in IMAP::getHeaderList() .  My comments are in green.
//3. DATE
                           // Call a function from the UW IMAP c-client code, line
                           // 2305 of mail.c.  The date string is returned in
                           // tmp.
mail_date (tmp, cache);

                           // ProcesaDate() is at line 1376 of Utils.cc.  After 15
                           // minutes scrutinising the code (why don't people have
                           // more comments???) I think it takes an input such as
                           //
                           //      " 8-Sep-2000 08:51:13 +0100"
                           //
                           // and returns:
                           //
                           //      " 8-Sep-2000"
                           // or   " 8-Sep" if this is the current year.

inter = ProcesaDate (tmp);
SL->Add (inter);
delete [] inter;

Now, looking into the UW IMAP source code at /src/c-client/mail.c  I find that mail_date() creates a date string such as the one shown above from numeric values in an "elt" structure (or object . . .) here called "cache" it is passed a pointer to.  This is of type MESSAGECACHEwhich is defined in mail.h .  The time-relevant parts of this are:
                      /* internal date */
unsigned int day : 5;         /* day of month (1-31) */
unsigned int month : 4;       /* month of year (1-12) */
unsigned int year : 7;        /* year since BASEYEAR (expires in 127 yrs) */
unsigned int hours: 5;        /* hours (0-23) */
unsigned int minutes: 6;      /* minutes (0-59) */
unsigned int seconds: 6;      /* seconds (0-59) */
unsigned int zoccident : 1;   /* non-zero if west of UTC */
unsigned int zhours : 4;      /* hours from UTC (0-12) */
unsigned int zminutes: 6;     /* minutes (0-59) */
But what kind of date is in these when Postman calls mail_date()?   Clearly, in my experience, it is getting the file date of each message file in the Maildir mailbox.  I guess the equivalent in an IMAP server which uses Mbox format mailboxes is the "From " date on the line which starts each message.

Looking earlier into IMAP::getHeaderList() it is clear that this "cache"   elt structure is formed by a call to a function which (I assume) gets the data straight from the IMAP server.

cache = mail_elt (imapstream, themsgnum);
mail_elt() is also defined in mail.c.   I can see no fancy options for telling the IMAP server what to put in this message cache.

Clearly, we need to get the headers of each email and get the date from the headers.

There is a function mail_cdate() in mail.c too, but it does some different kind of date format with the same "elt" information.  But the next function looks promising :

mail_parse_date(MESSAGECACHE *elt, char *s)
This takes a string pointed to by s and crunches it into date and time in an elt (= MESSAGECACHE) structure.

Here is my plan:

  1. Use mail_parse_date() pointing at the date in the message's header to write into another MESSAGECACHE structure.
  2. Then use mail_date() to crunch that information into a date, as before.
  3. Modify the ProcesaDate() function to provide a time as well.  (This is the only call to ProcesaDate() so changes to it should be fine.)

  4.  
Step 1 looks the trickiest - I need to get the header from the IMAP server and find the date line . . .

A function on line 509 of IMAP.cc looks promising:

char *IMAP::getDate (xulong nummsg)
This fetches the header and returns a pointer to just after the "Date: " text. Normally this is fine, because the date string starts on the character after the space after the colon.  This is as specified in the current April 2001 spec for email messages:
http://www.imc.org/rfc2822
Any normal email will be like this, but I found a Microsoft Security email which had 8 extra spaces before the date started, so I may need to cope with this.

*IMAP::getDate() is used at various points in InterDaemon.cc for the current message, when being displayed or replied to etc.  However, I don't fully understand how this function works.  Line 519 somehow sets two elements of the object on which this method is called, which must specify which part of the header to download.  That makes sense, rather than downloading the entire header over the network.

The date which is pointed to is of the form:

Mon, 9 Jul 2001 16:23:01 +1000
This is exactly the format expected by the c-client mail.c function mail_parse_date().  But it can only skip the day of the week ("Mon") if it starts on byte 0 of the input string.   So I do need to gobble any spaces which may be there due to Microsoft or anyone-else's incompetence.

Here is the new code:
                               // Get a pointer to the date section of the
                               // message's headers. getDate() is a method
                               // of class IMAP, and we are currently in
                               // another method of class IMAP, so we can
                               // use it directly, on the current IMAP object.
                               //
                               // Feed this to mail_parse_date which will
                               // parse the date and feed write the values
                               // into the "elt" variables in "cache".
                               //
                               // getDate() points to the character after:
                               // "Date: ".  Any normal RFC2822 compliant
                               // message will start with the date on that
                               // byte, but I have found some Microsoft
                               // security bulletin emails which have 8
                               // extra spaces.  Since mail_parse_date()
                               // can only gobble the day of the week if
                               // it starts at byte 0 of the string, then
                               // we need to skip past any spaces we
                               // find to start with.

datebuff = (getDate(themsgnum));
                               // Debug: the offending MS Date:
                               // datebuff = "        Thu, 5 Jul 2001 18:08:16 -0700";

while (datebuff[0] == ' ') datebuff++;

mail_parse_date (cache, datebuff);

                               // Now create a date string from these values.
mail_date (tmp, cache);

                               // Process it to remove bits we don't want,
inter = ProcesaDate (tmp);
 

There are two more things I want to do.

First, doctor the ProcesaDate() function for the following changes:

  1. Make it add two non-breaking-spaces to compensate for there being only a single digit day of month. (It normally adds only one space, which is not very wide.)
  2. Display the time in minutes and seconds.
  3. Add four spaces so there is a bit of clear space to the left of the From column.
I have done this. See my Utils.cc in the source-code links below.

Note that these times are not corrected for either the local timezone or the timezone in the message.

To do this would require having a local timezone setting - and a summertime correction.  Also, the user may be nowhere near the Postman server, so they really need to be able to set a timezone to their own locality, not where the Postman server is.   To achieve this will require a complete rewrite of this date/time stuff, since the time and timezone corrections can overflow into days, months and years.  It all needs to be done on the numeric data in the "cache" variable in the above code.

Secondly change the sorting system for what the user sees as "Date".

In the version of Postman I am working with (1.6) when the user sorts on "Date", the code tells the IMAP subsystem (in the c-client code which is part of interdamenon and/or the code in the IMAP server) to sort on "ARRIVALDATE".  Commented out and next to it is "DATE".  Here is the relevant line, and how I changed them.  This is line 796 ofInterDaemon.cc.

     if      (strcasecmp (parm1, "number")  == 0) {sorttype = NO_SORT;}
     else if (strcasecmp (parm1, "date")    == 0) {sorttype = SORTARRIVAL; /*SORTDATE*/}
     else if (strcasecmp (parm1, "from")    == 0) {sorttype = SORTFROM;}
     else if (strcasecmp (parm1, "subject") == 0) {sorttype = SORTSUBJECT;}
     else if (strcasecmp (parm1, "size")    == 0) {sorttype = SORTSIZE;}
     else                                         {sorttype = NO_SORT;}
 

I modified this line  to:

else if (strcasecmp (parm1, "date")    == 0) {sorttype = SORTDATE;}


This now makes Postman sort properly on the real date/time of the message (from the message headers), including with all the timezone corrections.  It completely ignores the file date of the message file in the Maildir mailbox.

But . . . . when I first log in, the mailbox is not sorted on date!   I want to make it be sorted on date whenever I first open a mailbox.  This means the following commands and perhaps others (as per the form elements sent from the browser, which translate into a big case statement in InterDaemon.cc) need to be modified so that the mailbox is initially sorted on date:

The mb_sort commands are quite different.  So I think I want to make the mb_change sort the mailbox first, by SORTDATE.  This turned out to be a bad approach.  Actually sorting the mailbox reverses the direction of the sort or each time the sort operation is performed.

The solution is to alter the constructor for class IMAP (in the early lines of IMAP.cc) so that the standard sorttype is SORTDATE.

This means that every newly opened mailbox is sorted by real date and the user sees the index page with the last message.
 




Like IMP, when the INBOX contains, for instance, 11 messages, and the screen only displays 10, then the user will get a screen with only one message.  At that point, at least some users will panic and think all the other emails have gone!  It might be good if the standard arrangement was to show a screenful showing the most 10 recently received messages.  But perhaps this would cause other problems.


It is not quite obvious how you copy or move messages.  The trick is to select them (the top button selects or unselects them all) and they use the narrow pull-down list which is by default "Open mailbox" to do this to the messages to the mailbox selected from the next pull down list.


IMP has a user mechanism for selecting which of all mailboxes it will present to the user.   Postman always presents all mailboxes, as does SqWebMail.



 

Language file changes


Agustin, it would be good to change the Javascript warning message in the compose window from:

"WARNING: They lack five minutes to disconnect the session. Use the 'Save' button or you could lost the writing."

to something like:

"WARNING: Your Postman session will end in 5 minutes unless you send the message or click the 'Save' button to save your text and continue editing."

(This is in Language.cc and all these messages are easily changed prior to compilation.  The text is compiled into interdaemon.)

I have created a modified Language.cc which fixes this and a few other messages.  The changes are flagged with /* RW */  This includes changing the search term for the "From" field to "From" instead of "De".

I have also changed the text of the "Add addresses" button in the Addressbook to "Add selected addresses to message".  See belowfor discussion of why.

I changed the Options text:

Time (in min.) to autorefresh the index page (0 for no refresh):
to be more informative about the 2 minute minimum time:
Time in minutes to auto-refresh the Inbox (0 for no refresh, 2 minutes minimum):


In the Message Compose window, I have changed the button:

Clean all
to
Clear addresses & text
I made a few other changes to Language.cc, such as "OK" instead of "Ok", and "NOT important" rather than "NO important.".

Following on from the above point about saving from the Compose window:

I understand that a subsequent session will have the compose window start with the last uncompleted message (or at least whatever was saved to the Postman server).  This is an *excellent* approach.  The Save function of IMP (at least the 2.2.0-pre-13 version I am using) closes the composition window when you press the Save Draft button, which is not what most people expect or want.  You have to know to open the Drafts mailbox, open the draft, and then Resume it, to continue editing.

Postman doesn't have "Drafts" mailbox, or a way of saving messages in various states of completion.  It saves the message in a file in the /var/postman/users/server.domain.com/bl/blah/.savedmsg  file.  So the saved message has nothing to do with IMAP mailboxes.  (Being the Devil's advocate, I think this means that if a user connected to one IMAP server via two separate Postman servers, then they would have two separate sets of user preferences and two separate possible saved messages.  But this is an unlikely situation.)

So there is no way of saving multiple drafts - except by sending the unfinished email to yourself, so it appears in the Inbox.

Having a draft message in your Inbox isn't very convenient, since there is no way of editing a message as new (as Netscape does).  This would be a really handy function, to be able to take a message as it is, particularly one from the sent-mail mailbox, and pop it into the Compose window, with all its text, addresses and (perhaps) attachments ready to send or edit and send.

I think this lack of IMAP-server based drafts is potentially serious a reason against using Postman.  Firstly it is different from what most sophisticated mail users are accustomed to.  Secondly, it is not as flexible as saving multiple versions of a draft.
 


A bug in the Addressbook system

When composing a new message (or replying or forwarding), from the Compose window, I press the Addressbook button and I see the Addressbook. Assuming that I have already put some names and addresses into it, then I see one or more lines of people I may want to add to the To: Cc: or Bcc: of the current message.

The problem is that at first, there is no "New Entry" (or for that matter "Dump") icon on the top row.  Using the Help does not help, because the only way out of the Help screen (which I think is very well written) is to use the browser's Back button.

(By the way, Agustin, I thought the example of your name in the Help screen was marvellous, because it describes you as "Es el programador."  I immediately thought of you as programmer / matador - splendidly attired, with a cheering crowd, battling bugs rather than bulls!)

The "New Entry" and "Dump" icons do appear if the Addressbook is opened from the mailbox index page.  Also, they appear when accessed from the Compose window when either:

  1. The "Add addresses" button is pressed, or
  2. One of the sort links is pressed to order the addressbook by various fields.
So when someone first use the system, it is not at all clear how anything can be added to the Addressbook.  Pressing "Add Address" does nothing much - it generates an error message, but at least it also makes the "New Entry" link appear.

Here are some suggestions:

  1. Make the "New Entry" link a button, rather than something on the top line.
  2. Rename the "Add Address" button to something like "Add selected addresses to message".  (I have done this in Language.cc.)
  3. Make it a bit easier to spot where to press to edit each entry - maybe have an icon which is bigger and more clearly for editing.  Alternatively, and probably better, have a link which has a Language.cc defined word for "Edit" in it..
  4. Change the "Back" icon to something like: "Back to compose message window".  (Make a similar change to the Attachments window.)


Bug Fix: The absence of "New Entry" and "Dump" in the Address Book window when started from the Compose Window.

Scrutinising the commands sent by various buttons, and a big case statement in Interdaemon.cc, I conclude that:

CMD_AB_FROM_CM is the function which does not produce the "New Entry" and "Dump" icons.
The following functions do produce them:
CMD_AB_SHOWALL  (From the main mailbox index, and when returning from address entry edit etc)
CMD_AB_SORT           (From Address Book - sorting.)
and some others.
Looking at the code, CMD_AB_FROM_CM and CMD_AB_SORTare handled by the a common piece of code, with a few differences: Interdaemon.cc line 1297.    I can't see anything obvious which controls which icons appear at the top line. This is done by method PrintAddBook_Show in line 2145 of HTML.cc, which calls method BotoneraComun in line 1018 of HTML.cc.

This is where the problem lies.  In line 1059, there is an OR of tests for four commands, including CMD_AB_SHOWALLand CMD_AB_SORT but these do not includeCMD_AB_FROM_CM.

Here is the new form of that line and the following one which fixes the problem:

      //BUTTON NEW ENTRY IN ADDRESSBOOK
      if ((cmdactual == CMD_AB_SHOWALL)     || (cmdactual == CMD_AB_SORT) || (cmdactual == CMD_AB_FROM_CM) ||
          (cmdactual == CMD_AB_DELEENTRIES) || (cmdactual == CMD_AB_ADDFIELDS))

Problem solved!


Bug Fix: Server error and end of session from Cancel button in Add new item to Addressbook

From the Address Book (no matter how entered), using the New Entry icon to add a new line to the address book, and then pressing Cancel causes a server error and the end of the session!  This is irrespective of entering text into the fields.

The command to the server by that button is "ab_deleentries" which looks wrong.   This is the command used for the "Delete" button in the screen for editing an address book line.  However, there is no pre-existing address book line to delete when adding a new entry.  So I suspect the command returned by this button needs to be changed.  The commands are parsed in a big case statement in Interdaemon.cc.

The code for creating both the Edit and Add New windows for the Addressbook is method  HTML::PrintAddBook_EditEntry in HTML.cc.  A conditional at line 2289 makes the button.  In both cases the command is "ab_deleentries".

There seems to be no separate command for cancelling.  "ab_deleentries" is handled by code starting at line 1344 of Interdaemon.cc.

Clearly, this needs to cope with so-called deleting a line which does not yet exist.  But rather than do this, I decide to change the command of the Cancel button to be "ab_showall" so it simply returns to the main Addressbook screen.

Fixed!!

However with this change alone, the red text "Editing entry" remains on the screen . . .

I won't pursue this, but it should be fixed at some stage.
 


The back.gif icon was a 24 x 24 pixel icon, whereas the others were 32 x 32. So the text below it did not line up properly.  I made it bigger in Photoshop.  The new one is here: 


In the Attachments page (from the Compose page), it would be good to see the size of the files.

(By the way, when the attachments are being prepared, they are saved in the user's directory in /var/postman/. )


There is a green warning text near the top of the Compose message window.  It only appears at first, not after saving.  Is it supposed to be there always?


Text wrapping in the Compose Message window


On Netscape, the compose window does not wrap text.  This forces the user to enter their own ends of lines, and so manually change everything when they alter the text.

Netscape is just doing what it is told:

<TEXTAREA NAME="texttosend" ROWS="30" COLS="70">
But MSIE 5.0 does something it is not asked to and wraps the text.  Curse Automatic Bill and his mates!  MSIE doing things it shouldn't do leads to covering up bugs in websites and code!

I modified HTML.cc around line 610 to add:

WRAP="PHYSICAL"
to this tag, so it becomes:
<TEXTAREA NAME="texttosend" ROWS="30" COLS="70" WRAP="PHYSICAL">
This caused Netscape to wrap the text on screen (but there is problem with the font not being fixed width - see fix below) but with both Netscape and MSIE, the message sent by Postman was unchanged - there was no wrapping whatsoever.  This is puzzling because the function of WRAP="PHYSICAL"is clearly defined and apparently uncontentious.  For instance:
http://html.mcwebber.net/customize.html#textarea
Setting wrap=off means no wrapping will occur - text is sent exactly as typed.
Setting wrap=virtual means the display wraps but the text is sent as typed.
Setting wrap=physical means the display wraps and text is sent with line breaks at all wrap points.
I can't easily see what the browser is sending back.  So what is happening?

Is the browser not doing what I expect?  Or is Postman compensating for some wrapping, and if so where and how.

Proper wrapping of text, but not breaking of URLs etc. which exceed the wrap length, is vital to email use.  I have written a few things to the Mozilla editor list about how text editors for email should work, but officially they are committed to making the default be HTML email!

WRAP="PHYSICAL" should do what I want.  Do I have to use WRAP="VIRTUAL" and then have code in Postman to wrap the text there?

How does IMP do it?  Imp wraps its text on screen to 80 characters or so and saving the draft or sending the mail reflects that wrapping.   It does chop words (like a long URL) to the wrap limit.   The browser window IMP's compose window appears in has no file menu.  I found the page source by using the fab Z-TreeWin program to sort all the files on my C: drive by time, and the most recently file was Netscape's cache of the compose window!

They use wrap="hard"!!  I had never heard of this.  A web search reveals:

At: http://list.opera.com/pipermail/opera-users/2001-May/004170.html "wrap="hard" is a non-standard thing invented by Netscape and then used by MSIE (?), but not implemented by Opera, because it is standards compliant.  ("I also *think* that support for the various values of WRAP have varied in the two browsers.")

This raises the question of how this all works with Netscape, MSIE, Mozilla (NS 6.x)and Opera.

OK - here is something more informative:

http://www.idocs.com/tags/forms/_TEXTAREA_WRAP.html
"Soft" means "virtual" in the purple text above.
"Hard" means "physical" in the purple text above.

Both wrap the text visually, but the hard option sends the text back to the server with breaks where the text was wrapped.  This page also gets down to some dirty Browser Wars scuttlebutt:

You may from time to time see other variations on WRAP, such as VIRTUAL or PHYSICAL. Netscape introduced these attributes a few years ago as proposed extensions to HTML 3.0, then abandoned them. Officially, the HTML 4.0 specs don't list WRAP, but Netscape and MSIE list WRAP = HARD | SOFT | OFF in their guides. It's best to stick these three values.
The curiously unreadable page:
http://www.htmlref.com/reference/AppA/textarea.htm
tells a similar story, but that IE should also respect "Virtual" and "Physical".

I alter line 609 of HTML.cc to make the tag:

<TEXTAREA NAME="texttosend" ROWS="30" COLS="70" WRAP="HARD">
It works with MSIE 5.0 and with Netscape, but I still have to solve Netscape using a non-fixed-width font.  Netscape breaks according to how many characters it can fit across the space, while MSIE does it strictly by the 70 column limit.
 

Fixing the non-fixed-width font problem with Netscape.

Experiments with editing a saved file of the Compose screen lead me to the conclusion that it was no good putting the whole textarea thing between <TT> and </TT> tags.  All that is needed is a </FONT> tag before the textarea tag begins.

I notice there is a </FONT> tag after the textarea part of the page.

So I alter HTML.cc to make the tag:

</FONT><TEXTAREA NAME="texttosend" ROWS="30" COLS="70" WRAP="HARD">
Fixed!!

The new line 609 of HTML.cc is:

WRITE ("</FONT><TEXTAREA NAME=\"%s\" ROWS=\"%d\" COLS=\"%d\" WRAP=\"HARD\">\n", name, rows, cols);
This change affects the other textarea in Postman too - the editing of the signature.  This works fine in Netscape now - with fixed width font and wrap.

There remains an unneeded </FONT> tag following the textarea part of the page.  I haven't bothered to look where in the code this is done, but it should be removed.
 

The problem remains of Postman chopping URLs which are longer than 70 characters (or whatever the limit).  This can only be solved, I think, by using WRAP="SOFT" and then doing the wrapping within Postman's interdeamon.  Then we can look out for long URLs and not break them.


With large mailboxes, it is important to be able to jump somewhere into the middle of it.  IMP has a facility for typing in a number of the page to go to, and it shows how many pages there are, with the current page number shown there.  Postman doesn't have any such facility - it has Previous and Next and First and Last.  The encoding of the URLs seems to contain this information, but several numbers change for each new index page, so it is not easy to manually edit them.


The "To:" address for mail sent by the user

There is an undocumented feature in the Inbox - or for that matter any mailbox.  If the email was actually sent by the user (or some criteria related to this) then in the "From: " column, the user's address does NOT appear.  Instead a truncated form of the "To: line appears, such as:

To: abc@123.345
when there is some kind of truncation of the actual address - as per the#define LONGDISPLAYFROM limit in Config.h.

This is a feature, probably intended so that any mailbox, including whichever one is selected to receive a copy of the sent mails.  The benefit is that any mailbox can display mail sent by the user, with the "From" column showing the "To:" address rather than the sender.  For this to be activated, the "From:" address needs to be the current user name plus "@123.456.com" where "123.456.com" is (I think) specified in the def_user_not_in_db parameter of /usr/local/etc/interdaemon.cfg.

This means that any mailbox can function as a repository for sent mail.  Try doing that with Netscape!   For most users, Netscape appears to have only one folder which can hold sent mail and display the "To:" address instead of the "From:" address.  The result for most users is that their Sent mail folder (whichever they nominated, local mailboxes or via IMAP) grows and grows because if the messages are copied anywhere else, then you can't see who you sent them to!  Here are limited workarounds for this in Netscape in Edit > Preferences > Mail & Newsgroups > Copies and Folders:

  1. Use the Usenet sent option to make another mailbox show the "To:" line. (This assumes you don't use Usenet, which is not necessarily the case.) I use this to point to a mailbox "0-Usenet-Sent-really-previous-years-email-sent" where I keep older sent mail.)
  2. Similarly, sacrifice the "Templates" function and use this to point to another mailbox.
Postman needs no such fudges!

It is my impression that SqWebMail has a similar problem to Netscape, but worse: only one mailbox is useful for displaying the "To:" line of sent messages.,  The "Sent" mailbox is the only one which displays the "To:" line - and that this is not configurable by the user.

Likewise, I think that IMP only has one such mailbox, again not user-configurable: "sent-mail".
 


I think that the Help screens should have an explicit icon, saying that pressing this will return the user to a particular screen (from wherever this particular Help screen originated).  Maybe this is tricky, since the browser's Back button may be the best way of returning, (either because there is no need to send anything from the server, or because the help screen doesn't know the session ID . . . though the Help screen could be dynamically generated with that information in the link or button.

Likewise perhaps all the windows might have an explicit link or button saying what it will go back to - the Addressbook, Preferences , Expunge, etc.  But it is not essential.  An advantage might be that it encourages the user not to use or rely on the browser buttons - if this is a desirable goal.


Postman has a user preference for how often to refresh the INBOX.  The minimum setting is 2 minutes.  As noted above I have altered the text to tell the user of this 2 minute minimum.

IMP doesn't have a way of automatically refreshing the mailbox, but it does have a way of the server communicating regularly with the client to put up a rather pesky Javascript alert box every time a new mail arrives.  The only way of stopping this appearing regularly seems to be to read the email - and to do that you have to go to the Inbox.  There is no refresh button for the Inbox or any other mailbox.  The user must click the INBOX icon or select INBOX from the pulldown list on the left.  This this regular alert box could be inconvenient if you are writing a new message.  The timing of the new mail alert is set in the server configuration.


My initial test sending and receiving MIME attachments worked fine.   Postman didn't recognise a base 64 attachment - but I don't think anyone should be sending things except as MIME these days.   IMP can have an integrated Word file viewer, which is pretty snappy for a web mail program.  This could be particularly handy in an educational or business setting.


Remember not to try to operate two mailboxes at once!  You can be looking at the Inbox (call this window 1) and then right click the Mailboxes icon, and from there select a mailbox ZZZ in what I will call window 2.  Now switch to window 1 and press refresh - you get messages from mailbox ZZZ.

IMP can't look at more than one mailbox at once, unless, you have separate sessions with separate browsers.

With Postman, it seems fine to right click the message lines in a mailbox and so open separate messages in separate windows.  IMP can do this too - each message is in a window without IMP's frame, which could be confusing if you relied on it to go to other mailboxes, log out etc.  With IMP, if you change the main window to another mailbox, then go to a message from the first mailbox, then you can use a button there to return to that first mailbox, and it appears on in that window without a frame.  But it doesn't do you much good, since if you click on a message, that screen becomes the same mailbox in the the main frame.

So neither IMP or Postman can handle two mailboxes at the same time.  But they can handle multiple messages open at once, from different mailboxes.  Postman looks like it can have two message composition windows, but the server only thinks there is one, so trying to use the address book and then go back to the composition window will lead to failure for one of them.  Still, I have been able to have two windows open at once, and send both messages.

By right clicking links, SqWebMail can do multiple mailboxes fine, as well as multiple message composition windows.  There seems to be no limit or complications.
 


The header of each mailbox page shows the number of messages in it (as does IMP) but it also shows the total size of the mailbox in bytes.


Postman worked fine via SSL - I just used https://myserver.xyz/cgi-bin/postman?lang=eng
This is without me even thinking about the standard Red Hat SSL installation.  Since I haven't paid money for a server certificate from Veri$ign etc. browsers prompt the user to accept the certificate as being valid.


There is an intriguing way of downloading the mailbox which is being currently viewed - this is via the Mailbox link which leads to a page for this, and for creating, renaming and deleting mailboxes.  The entire contents are sent to the browser in what looks like Mbox format.  However, if any lines in the body of the message start with "From" (whatever the case) then these are not escaped as they should be for an Mbox format mailbox.   In Mbox format, any body line which starts with "From" has to have a ">" added before it.  Its a pest, and probably screws up a few things (like PGP signatures . . . ) but that's the way it has to be.  There's no way of stripping this off, since there is no way of knowing that the message was a "From" in the first place.  If this was not the case, then the following scheme would be reliable:

 
If you save mailbox dump in your local mail system, such as for Netscape under Windows, for user abcd:
C:\Program Files\Netscape\Users\abcd\Mail\
then the next time you run Netscape (you have to close the entire program, and restart it - not just Messenger) then the mailbox will be accessible under local mail.  I tried this with a 15 megabyte mailbox and it worked like a charm!   But this would be error prone without adding an extra function for escaping "From" lines in the body.   If I was going to do this, then I would add a separate button to do it, or rather a link, so that shift-clicking on the link would create a file with no ".html" extension, and which could be saved to a local mailbox location.  However, this feature is probably rather tricky for ordinary users.
This is a n excellent feature!  IMP can't do it at all.

Neither IMP, Postman nor SqWebMail can copy whole mailboxes.  They can all rename mailboxes - and SqWebMail is hip to folders of mailboxes.  The only way of copying a whole mailbox worth of emails would be to select them a window at a time and copy them.  But since Postman can easily be configured to have a very long index page for mailboxes, it is possible to make the length longer than the mailbox, and so select all messages with one click of the top button, and copy the lot.  The page would take a while to download over a slow modem, but.

Postman will quite happily display huge numbers of messages in its mailbox index.  I tried it with a 15 megabyte, 9,000 message mailbox.  I set the mailbox index to display 10,000 messages, and after some chewing, Postman displayed the lot all on one long easily scrollable web page!  You definitely need a LAN connection to the Postman server to do this.
 


Postman can change the tags of messages (Deleted message, Answered message, New (unseen) message, Important message) when reading the message.
 


Postman has a SEARCH function!  IMP (2.2 at least) can't do that.  It seems only to search on the first word in the search string - it ignores "and" and any subsequent terms.  Messages which match are tagged with a yellow and green cross - and the number of matching messages is displayed.

There is no way of sorting on flags.  If there was, then it would be possible to collect all those messages which match the search string at one end of the mailbox.  So it could take a while in a long mailbox to find all the matched messages.  This is a real problem if you have 5000 messages in a mailbox!  I think some way is needed of hiding those which do not match.  (But see above about displaying the entire mailbox on one long page and scrolling through it.)
 


I did have one fault with Postman - a newly arrived message which appeared with no subject and a blank sender line.  The message was OK when I clicked on it - it was just the index page which was wrong.


A Postman installation being used by unauthorised persons?

If Postman is configured to access IMAP servers other than the machine it is running on, and if the Postman program was usable by anyone, regardless of location, then I think it would be possible for anyone to fire up a session to the IMAP server of their choice, by creating their own form or perhaps URL encoding the relevant form data, since Postman can be told by the form which IMAP server to connect to.   Perhaps there is a way of restricting this - I don't understand all Postman's configuration options.  But there needs to be - otherwise anyone from anywhere can use the Postman server to access any IMAP account in the world.

It is easy to create a login page with the IMAP server as a user alterable item.

Making a login page without this doesn't stop someone else from creating their own form and making it go to the Postman program on your server.


General security issues

Security is a very deep subject.  It could take a lot of scrutiny to find whatever problems Postman may involve.

For instance, a message to the IMP mailing list on 22 July 2001 http://marc.theaimsgroup.com/?l=imp&m=99575417320757&w=2 Brent Norquist mentioned a newly discovered (and fixed) problem with a malicious email including text which IMP might pass to the browser so that the browser interprets it as Javascript.

By using tricky encodings of "javascript:" an attacker can cause
malicious JavaScript code to execute in the browser of a user reading
email sent by attacker.  (IMP 2.2.x already filters many such patterns;
several new ones that were slipping past the filters are now blocked.)
I haven't looked into it, but there are many potentially subtle security threats and it will take a lot of scrutiny and probably some refinements before Postman can be thought of as reasonably secure.   I have no idea what the problems might be, but I think it is safe to say there will be a few.

Perhaps Postman should go to the sort of trouble which I think IMP goes to to stop the browser (and perhaps a proxy server) caching pages.


I think Postman is most promising!  I would imagine it is more CPU-efficient than IMP, because PHP must be rather inefficient compared to compiled binaries.   My IMP installation is on a Pentium 100 MHz and the Postman installation is on a K6 200 Mhz, so it is hard to compare fairly, but Postman is certainly very fast (fractions of a second via the LAN) , while IMP can take a second or two to do almost anything.

IMP supports 23 languages . . there seem to be a *lot* of users and quite a few people contributing to it.



 

My altered source code files

 pmdocs/IMAP.cc
 pmdocs/InterDaemon.cc
 pmdocs/Language.cc
 pmdocs/Utils.cc
 

Version 2.0 notes

Here are some notes on getting 2.0 going.  This is probably not all you will need to get it running on whatever machine you are using, with whatever compiler and library gotchas you encounter.  This is from some emails I wrote to the Postman discussion list.


There are two "#include db1/db.h: in:

Authentication.h
runtinas_db.h

but I have no such directory. I do have:

/usr/include/db3...

not

/usr/include/db1...

Changing the two includes to point to "db3/db" leads to a big
compilation problem, the same as mentioned on the Postman list on 9 May
2004 by "aktor". The error messages which result are:
cc -Wall -Wpointer-arith -Wstrict-prototypes -O2 -DLINUX   -c
rutinas_db.c -o rutinas_db.o
rutinas_db.c: In function `sm_getpwnam':
rutinas_db.c:22: warning: assignment makes pointer from integer without
a cast
rutinas_db.c:30: warning: passing arg 2 of pointer to function from
incompatible pointer type
rutinas_db.c:30: too few arguments to function
rutinas_db.c:94: too few arguments to function
rutinas_db.c: In function `exist_user':
rutinas_db.c:168: warning: assignment makes pointer from integer without
a cast
rutinas_db.c:174: warning: passing arg 2 of pointer to function from
incompatible pointer type
rutinas_db.c:174: too few arguments to function
rutinas_db.c: In function `db_get_data_from_user':
rutinas_db.c:202: warning: assignment makes pointer from integer without
a cast
rutinas_db.c:209: warning: passing arg 2 of pointer to function from
incompatible pointer type
rutinas_db.c:209: too few arguments to function
rutinas_db.c:244: too few arguments to function
make: *** [rutinas_db.o] Error 1

There are a bunch of problems in "rutinas_db.c", in
function "sm_getpwnam", and the way it calls a function "dbopen" which
evidently does not exist in DB3.

Here is what I had to do to make it compile.  Some of these changes
relate to my system in general, and some to the problem encountered by
aktor.  That problem is that the Postman code assumes a DB1 Berkeley
Database, while my system has DB3 installed.

The Postman code expects there to be a library to link to called:

  db1

and I have to make it

  db

So in the Makefile:
# LIB    = -lcrypt -ldb1
LIB      = -lcrypt -ldb

Version 2.0 assumes that there is a header file:

/usr/include/db/db.h

but I have only:

/usr/include/db3/db.h
/usr/include/db3/db_185.h

I need to change several files (listed below) to include:

db3/db_185.h

Makefile
--------

REALCGI = /var/www/cgi-bin/$(APPNAME)

WEBGROUP = apache

WEBHTDOCSDIR = /var/www/html

CCLIENTDIR = ../imap-2001a/c-client
(I downloaded this imap-2001a library from the Postman website
and compiled it, but did not install any of the programs.
Postman needs to link to an object file there "c-client.a". )

CXX = gcc

LIB = -lcrypt -ldb
(Not -ldb1)
CGIGROUP = apache
SERVERGROUP = apache

/files/interdaemon.cfg, Config.h
--------------------------------

Just changes which are normally required - not to do with this
compilation problem.

I did have a problem with the make install not placing interdaemon.cfg
at its final destination:

/usr/local/etc/interdaemon.cfg


 probably due to there being an older file there from the earlier version.


Authentication.h, ClientDB.h and rutinas_db.h
---------------------------------------------

Replace:

#include <db1/db.h>

with:

#include <db3/db_185.h>


With various other things as listed in the main body of this page, I was able
to log into my IMAP account, at least to some extent, with the new Postman.

Postman produces a message:


"Mail (You have 3 messages not read)"

with the right number of messages, so the cgi-bin program was clearly
talking to the interdaemon and the interdaemon is clearly logging in to
my IMAP server successfully. When I clicked this message's link, or
when I clicked any one of the other links on the page, I got:

Error: Service not allowed!


The first problem was that the /files/interdaemon.cfg file was not
copied to its proper location:

/usr/local/etc/interdaemon.cfg

and my old one, (from an earlier version of Postman) was still there.

Another change was to config.h, to specify the location of sort correctly:

// #define cmdSORT "/usr/bin/sort"
#define cmdSORT "/bin/sort"

There is a lot of room for error in this part of config.h - be sure to
check the locations of:

sort
ps
grep
wc

Another change, which probably is that for my Courier IMAPD server, I
changed its config file (/usr/lib/courier-imap/etc/imapd) item:

MAXPERIP=4

to

MAXPERIP=20

I doubt that this affects Postman, but it helped me use Mozilla
intensively. This controls how many concurrent IMAP sessions Courier
IMAPD will accept from the one IP address. Whatever IMAP server you are
using on a large web-mail system, you will need it to handle a lot more
than 4 concurrent sessions from the server which is running Postman! I
am only using this as a personal server.



Update history