Subject: Re: cucipop, unleashed...

From: [email-masked] (D. J. Bernstein)
Date: 13 Sep 1996 04:57:18 GMT

Stephen R. van den Berg <[email-masked]> wrote:
>	+ Is the only popd to perform reliable mailbox locking across
>	  NFS as well

Actually, qmail-pop3d works reliably over NFS. (It's dedicated to
maildir format. maildir is nice for programmers because it doesn't need
any locking beyond the kernel's automatic low-level directory locking.)

qmail-pop3d also uses no temporary files, can serve any size mailbox,
supports APOP and UIDL, imposes no limits on lines or characters, and
has a hook for your favorite authentication scheme. It's much smaller
than cucipop.

It does sound like you have the best available mbox-based POP server.

>	+ It also supports an optional autodelete mechanism, so that any
>	  RETReived message is automatically deleted

Yikes. Does it also automatically tell the users what it's doing? ``I
will irrevocably destroy your mail, before you've seen it, if your
connection drops at the wrong moment.''

---Dan

---

From: [email-masked] (Neil Harkins)
Date: 13 Sep 1996 19:00:58 GMT

Are qmail-pop3d and/or cucipop free? If so, where can one get them?

-Neil
_________________________________________________________________________
Neil Harkins                                            [email-masked]

---

From: [email-masked] (D. J. Bernstein)
Date: 17 Sep 1996 05:59:13 GMT

Stephen R. van den Berg <[email-masked]> wrote:
> the mbox format uses
> a lot less space on typical filesystems (less block slack) and fewer inodes.

Yes, I find an average savings of 12%. Of course, maildir is designed
simply to solve the reliability problems of mbox and mh for incoming
messages; long-term storage should use a completely different format,
with compressed messages and hashed indices.

---Dan

---

From: [email-masked] (Stephen R. van den Berg)
Date: 14 Sep 1996 01:02:51 GMT

>maildir format. maildir is nice for programmers because it doesn't need

I'm actually referring to traditional mbox dotlocking.  For maildir
format, this is, of course, not needed.

>has a hook for your favorite authentication scheme. It's much smaller

Undoubtedly, because it doesn't have to parse the mbox format.
There is an advantage (despite its many shortcomings) to mbox over the
maildir format, BTW, especially to your typical mailserver that has lots
of POP3 readers and not all that many shell users:  the mbox format uses
a lot less space on typical filesystems (less block slack) and fewer inodes.

>connection drops at the wrong moment.''

It takes a reasonable stab at detecting these "wrong" moments and
tries not to delete the message currently being transferred.
But, there is a risk, yes.  In any case, the behaviour is completely
optional and definitely not the default, and of course clearly
marked in the man pages as violating RFC1939.  Nonetheless, it is useful
for some environments, which is why I included it.

As for telling the user..., it indeed displays a message of this kind
as the mail is being retrieved.  The problem is that if the user
is using a typical POP3 client, this message will, of course, not
be displayed to the user.
--
Sincerely,                                                          [email-masked]
           Stephen R. van den Berg (AKA BuGless).

Real programmers don't produce results, they return exit codes.

---

From: [email-masked] (Stephen R. van den Berg)
Date: 12 Sep 1996 12:35:44 GMT

As of now, you can pick up a new POP3-daemon that has been especially
optimised for heavy loads (e.g. your typical ISP setup).

cucipop v1.10

It can currently be picked up as:

ftp://ftp.informatik.rwth-aachen.de/pub/packages/cucipop/cucipop.tar.gz

Feature summary for cucipop:
	+ It's fast (optimised for frequently polling POP3 clients)
	+ It's less filling (i.e. small)
	+ Does not use *any* temporary files (which also means that the
	  startup time is spectacularly short, and there can never be
	  any stale temporary files or doubled mailboxes)
	+ It can therefore serve *any* size mailbox without requiring
	  additional storage beyond what the file already occupies
	+ A fully compliant, all frills attached, RFC1939 implementation of
	  the POP3 protocol
	+ This means that it supports APOP *and* UIDL
	+ It includes the option to sabotage the UIDL command (to defeat
	  undesirable "Leave mail on server" clients)
	+ It also supports an optional autodelete mechanism, so that any
	  RETReived message is automatically deleted
	+ Autoadaptive, simply start it and it will know if it has been
	  started from inetd or as a standalone daemon
	+ Security conscious, i.e. the APOP support, already has hooks
	  for shadowpasswords, and defeats password guessers by an adaptive
	  verification delay
	+ Supports both BSD and SysV (Content-Length) mailbox formats
	+ Is the only popd to perform reliable mailbox locking across
	  NFS as well (it uses the same excellent and proven locking
	  algorithms as does procmail)
	+ Provides flexible logging of statistics and auditing events
	+ Does not impose *any* limits on line lengths, mail length,
	  or the use of any character (any 8-bit character, including '\0' is
	  allowed) in the mail
	+ Secure system mailbox handling
	+ Has hooks to ease moving the mailboxes to any location you'd like
	+ Has hooks for other authentication schemes (e.g. Radius)
	+ Has hooks to virtualise the popserver
	+ It runs on any POSIX and ANSI C compliant system
	+ Is clock skew immune (e.g. in the case of NFS mounted mailboxes)
--
Sincerely,                                                          [email-masked]
           Stephen R. van den Berg (AKA BuGless).

"I have a *cunning* plan!"