--Jérôme Bolliet wrote on 08.01.2003 13:20 +0100: [...]

courierpop3d scans every single line on every login to compute the size with crlf as required/recommended by rfc.

I had a mailbox with ~2500 messages on a crypto-fs which took more than 12 cpu-seconds at each poll on a P200. 100 concurrent users scanning their pop3 continously explain the load of 55, only a faster raid would help somewhat.

qmail-pop3d simply returns the filesize from a stat, the only problem I know was with fetchmail about 2..3 years ago.

If you deliver with courier (or maildrop or deliverquota) the size of the file will be embedded into the filename, and allows very fast operation, even faster than qmail and polling the mailbox with the 2500 messages above takes less than one second.

The patch below is quite simple, and expects to find ',S=nnn' in the filename or will fall back to the traditional method. You also could add a stat there.

+++ imap/pop3dserver.c @@ -113,6 +113,9 @@ DIR *dirp; struct dirent *de; struct msglist *m; +// PATCH: dont scan every file, ignore rfc like qmail-pop3d +char *p; +long s;

if ((dirp=opendir("cur")) == 0) { @@ -140,7 +143,13 @@ m->next=msglist_l; msglist_l=m; msglist_cnt++; - calcsize(m); + + // PATCH: dont scan every file, ignore rfc like qmail-pop3d + // de->d_name =~ 1018021353.83146_0.host.dom,S=9249:2,S + if( (p=strstr(de->d_name,",S=")) && (s=atol(p+3))>0 ) + m->size = (off_t)s; + else // fallback to slow rfc-conformant scan + calcsize(m); } closedir(dirp); }