Oops Re: [tpop3d-discuss] Looking for resources

[Chris Travers]

Hi Chris;

From: "Chris Lightfoot" <chris@ex-parrot.com>

> yes... In POP3 there's a distinction between sending the
> headers of the message and the (first N lines of) the
> message itself. I'm guessing you're supporting more
> sophisticated applications (IMAP server?) with your
> schema, so you'll probably be parsing the message out in
> the database. You may have to stick it back together
> again....

THis can all be done with views and is entirely beyond the details of
implementation, but I am planning on having the headers and body in separate
database fields.  The headers can then be dynamically parsed by an IMAP
server, and the only headers that need to be stored separately in the
database are those headers which actually make a difference to the
applications that sit on it (particularly, REFERENCES and IN REPLY TO
headers).
>
> > Finally 1 more question:
> >
> > If I am authenticating using PostgreSQL and retrieving my messages from
the
> > database, I shouldn't need any special privaleges.  Is there any
> > documentation regarding running this via chroot and or under a more
> > restricted UID?  I am thinking that the process changes its UID and/or
GID
> > after forking, so this may not be possible.
>
> A few users have done this with private patches, and
> incorporating these is on the to-do list, but I haven't
> got round to it yet, unfortunately.
>
Chrooting could easily be done with a wrapper script.  The UID/GID issues
would be different.  Thinking of having the program SUID as a user with
limited rights (named tftpd).  This would make authenticating the app
against the PostgreSQL database more flexible because one could use Ident
authentication.

Kerberos V support would be something else that could open up new
possibilities but that is beyond the scope of my work ;-)

> Of course, you'll need to apply care with the database
> connections when you fork....

Despite the added latency, I had planned to use one persistant connection
for authentication assuming that it will be lost after the fork, and
creating a session connection for each concurrent user.  This could get
messy under high load, but connection pooling would be worse.

For example, if I am "locking" by using transaction blocks (which gives the
appearence of an exclusive lock despite the fact that one is not actually
aquired), and I am pooling connections then I have a major problem because
each client will block every other client(!).

If I create a new connection for each authenticated user and inherit this to
the child process, things get considerably worse...  If I log in, retrieve
my email, and am deleting it when a network error occurs which causes the
connection to be lost, there is a possiblity of deadlocks when I reconnect.
This way, the connection exists entirely within the child and does NOT pose
this problem (deadlocks are still possible of 2 users try to delete the same
messages in the mailbox due to the transactional isolation, but that is a
different problem, and one not necessarily ).

The approach I am looking at will allow group email boxes as well as
individuals.  The only difference is that deletions are ignored by
non-admins for group mailboxes (that is the database's job).

Best Wishes,
Chris Travers.