🚀 go-pugleaf

In article <30d09640.4515768@news.demon.co.uk> [Thu, 14 Dec 1995 
21:35:05 GMT], Mike Mann says...
>
>This may be a reference to the fact that WinDis appends incoming mail
>to the file ....\ka9q\spool\mail\<user>.txt *unless* its POP3 server
>is switched on, in which case incoming mail is stored in files of the
>form ....\ka9q\spool\mail\<user>\nnnnnnnn.pop.
>
>There must be a good design reason for this although it escapes me.
>Unfortunately, this practice means that WinDis is unsuitable for use
>as a POP3 server on a system which hosts multiple users, some of whom
>wish to use POP3 mailers and others wish to use KA9Q-compatible
>mailers such as NewsWin or FiMail.     It is for precisely this reason
>that I have to use TPOP3 as a local POP3 server instead of WinDis
>which I would much prefer to use, if only it allowed an option on the
>storage of incoming mail.

Firstly, I think it needs to be said that Windis is not really intended 
to be the sort of server you describe. There are other things that make 
it unsuitable for true multi-user use (eg. you can't set individual 
users POP3 passwords). It is supposed to be adequate in the work-group 
context where some user or role separation is required for convenience 
but where formal and secure privacy is not essential. It clearly isn't 
sufficient for a service provider for example nor I would suggest for a 
company of any size.

Having said that, I can't see that the 'problem' has anything to do 
with where/how the POP3 server stores its files.The design reason for 
doing it the way we did, is that it is MUCH easier (and therefore less 
risking of mail-loss) not to have to contend with concurrent access 
issues on a single mailbox file both from within Windis (by multiple 
mail streams) and outside (by innumerable possible mailreaders). The 
whole point of POP3 is that you get at the data through a 
communications protocol NOT file access so it should be irrelevant 
where the data are stored.

What you really seem to be saying is that you would like to be able to 
select the mailbox 'type' on a user-by-user basis. [Not a provided 
option, sorry :-)].

What you can do (with the latest version) is provide a "template" for 
the mail storage directories so that the mailbox name component no 
longer has to be at the end of the path. This means you can more easily 
protect the mail files using the OS file security (if you have any!). 
It ought to be relatively simple to write a script (perl or rexx or 
something) to concatenate the *.POP files onto the end of a single 
<mailbox>.TXT and add the standard separator since they are all plain 
text. Whether or not that might help you would depend on exactly what 
you perceive the problem to be. Look out for mail-readers which don't 
notice changes in "open" mailboxes though!!

Sadly, the decision has been made that Windis itself will not be 
developed further. It now does what it was intended to do (and some 
more!). In any case, there comes a point when a product is stretched so 
far beyond its original design intent that it would be no longer the 
same product. To try to make Windis a full-featured, multi-user server 
would be a major undertaking of no benefit to most of its 'target 
audience'. Besides there are now quite a few mail-server products 
available now (at least for NT which is the only version of Windows 
worthy of such a task IMHO).
 
Cross-posted and follow-ups set to d.i.s.w since this has now strayed 
from the topic of development.

-- 
-----------------------------------------------------------------------
Colin Spensley    <colin@alecto.demon.co.uk>
<http://ourworld.compuserve.com/homepages/alecto>
-----------------------------------------------------------------------