qmail Digest 2 Apr 1999 11:00:01 -0000 Issue 598
Topics (messages 23860 through 23878):
Mail server load testing
23860 by: Anand Buddhdev <[EMAIL PROTECTED]>
23862 by: "Fred Lindberg" <[EMAIL PROTECTED]>
23873 by: "Dave Teske" <[EMAIL PROTECTED]>
Melissa Virus
23861 by: "Paul J. Schinder" <[EMAIL PROTECTED]>
23865 by: Peter Haworth <[EMAIL PROTECTED]>
Problem with CGI
23863 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
23864 by: [EMAIL PROTECTED] ()
23866 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
23869 by: Markus Stumpf <[EMAIL PROTECTED]>
23870 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
qmail and relaying to an aliased address...
23867 by: "Stephenson Grant (SMI)" <[EMAIL PROTECTED]>
Does Qmail have support for Dynamic IP Spam Sources List
23868 by: [EMAIL PROTECTED] ()
maildir and "You have new mail"
23871 by: Miquel van Smoorenburg <[EMAIL PROTECTED]>
23872 by: Mark Delany <[EMAIL PROTECTED]>
23874 by: Miquel van Smoorenburg <[EMAIL PROTECTED]>
23875 by: "Lenny Mastrototaro" <[EMAIL PROTECTED]>
23876 by: Bruce Guenter <[EMAIL PROTECTED]>
23877 by: Jay Soffian <[EMAIL PROTECTED]>
23878 by: Bruce Guenter <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Thu, Apr 01, 1999 at 01:26:19AM -0500, Dave Teske wrote:
The Postfix distribution includes such tools. Go to:
http://www.postfix.org
> Does anyone know of any apps that can do load testing on mail servers. I've
> seen a bunch that do web server load testing but none for mail servers. I've
> got our server on a tiny (486 w/P90 upgrade chip & 24mb ram)box and I'd like
> to see how much load it'll handle before I go scrounging for a replacement.
--
System Administrator
See complete headers for address, homepage and phone numbers
On Thu, 1 Apr 1999 01:26:19 -0500, Dave Teske wrote:
>Does anyone know of any apps that can do load testing on mail servers. I've
>seen a bunch that do web server load testing but none for mail servers. I've
>got our server on a tiny (486 w/P90 upgrade chip & 24mb ram)box and I'd like
>to see how much load it'll handle before I go scrounging for a replacement.
qmail is an excellent tool for this. Just set up another computer with
qmail and a concurrencyremote as high or higher than the max number of
connections you can accept on the test machine. Set up an ezmlm list on
the test machine. Subscribe a lot of users test-123@testhost, over a
range of "123". Set up a user "test" on testhost. Create
~test/.qmail-default with a single "#" in it.
Send a message to the list on the other computer. It will send as many
messages as there are subscribers to the test machine. It does less
disk work that the test machine since it sends the same message to all
subscribers. The test machine receives the messages, queues them, then
delivers them discovering that the "#" which means that the delivery
succeeds without writing anywhere.
Thus, you test the [local] network, qmail-smtpd, queue and queuing,
that you have memory for the set number of incoming connections, etc.
For outbound mail, you can reverse the function of the two boxes.
Do yourself a favor and set it up with tcpserver and daemontools
(cyclog) directly. Otherwise, syslog may become limiting and you are
slow on incoming connections and have less control over the number.
Also, carefully read tcpserver docs on -H -l, etc.
What isn't tested: outside net, named (run a caching one locally).
Still, it tells you a lot, especially to what to limit the nuber of
incoming connections (tcpserver -c) and outgoing
(concurrencyremote/local) so that you don't run out of memory at
maximum load.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Thanks thats exactly what I wanted. I got the smtp sending tester working
(of course I didn't like the results...) Would you happen to know of any
docs for the 2 apps. I gathered what I needed for the cmdline help but addtl
info would be great.
Thanks again
--Dave
>
>The Postfix distribution includes such tools. Go to:
>
>http://www.postfix.org
>
>> Does anyone know of any apps that can do load testing on mail servers.
I've
>> seen a bunch that do web server load testing but none for mail servers.
I've
>> got our server on a tiny (486 w/P90 upgrade chip & 24mb ram)box and I'd
like
>> to see how much load it'll handle before I go scrounging for a
replacement.
>
>--
>System Administrator
>See complete headers for address, homepage and phone numbers
At 9:14 AM +0000 4/1/99, Petr Novotny wrote:
} > My car is "user-friendly" and easy to use, so are you saying that if
} > I go out and drive at 100mph and crash that it's Ford's fault for
} > not limiting the maximum speed of my car?
}
} Dismissed - invalid analogy. You need a licence to drive a car. You
} probably did some tests to prove you know what you're doing. If there
} were no licence for driving a car, Ford would make a car that would
} limit your maximum speed.
And there would be information available on the web on how to disable the
governor. Mechanics would offer to do it, even if it was illegal, for a
price.
Since I lead a Microsoft free life, Melissa hasn't affected me except by
all the mail that has shown up here and on BUGTRAQ about it. I didn't even
get a single copy of the Melissa spew sent to me yet.
The Microsoft users here say that the mechanism that Melissa uses is
disabled by default. And yet the news outlets, even the clueful ones, are
all braying that Melissa is the "fastest spreading virus ever". That
indicates to me that lots of people (and at Microsoft and Intel, reported
to be heavily hit!) are turning whatever protections there are off. Or is
it that the protections are on only in NT and not in the 95/98?
(And what this has to do with qmail is beyond me.)
}
} Next!
} --
} Petr Novotny, ANTEK CS
} [EMAIL PROTECTED]
} http://www.antek.cz
} -- Don't you know there ain't no devil there's just God when he's drunk.
} [Tom Waits]
---
Paul J. Schinder
NASA Goddard Space Flight Center
Code 693, Greenbelt, MD 20771
[EMAIL PROTECTED]
Russ Allbery wrote:
> Bruno Wolff <[EMAIL PROTECTED]> writes:
>
> > This isn't the same thing. They don't run commands imbedded in the the
> > documents.
>
> emacs does.
Doesn't vi also treat the first 5 lines of a file as special under certain
circumstances? Unfortunately, I can't seem to find this in the manpage on
Solaris 2.6, so I may be misremembering.
--
Peter Haworth [EMAIL PROTECTED]
"The Perl Way.. code yourself into a corner, and then come up with an
outragous hack to allow people to do something important at a later date."
-- John Redford
> : > : Return-Path: <[EMAIL PROTECTED]>
> : > : Received: (qmail 17136 invoked by uid 33); 1 Apr 1999 02:43:28 -0000
> : > : Date: 1 Apr 1999 02:43:28 -0000
> : > : Message-ID: <[EMAIL PROTECTED]>
> : > : To: [EMAIL PROTECTED]
> : > : Subject: Linux Applications
> : > : FROM: [EMAIL PROTECTED]
One of my users is running some CGI scripts, but the return-path that is
being sent is my email address instead of his. Does anyone know why this
could be happening? He says he doesn't have a return-path programmed into
his cgi's. uid 33 is www-data (the account that apache is running under).
--Adam
Adam D. McKenna ([EMAIL PROTECTED]) wrote:
: > : > : Return-Path: <[EMAIL PROTECTED]>
: > : > : Received: (qmail 17136 invoked by uid 33); 1 Apr 1999 02:43:28 -0000
: > : > : Date: 1 Apr 1999 02:43:28 -0000
: > : > : Message-ID: <[EMAIL PROTECTED]>
: > : > : To: [EMAIL PROTECTED]
: > : > : Subject: Linux Applications
: > : > : FROM: [EMAIL PROTECTED]
: One of my users is running some CGI scripts, but the return-path that is
: being sent is my email address instead of his. Does anyone know why this
: could be happening? He says he doesn't have a return-path programmed into
: his cgi's. uid 33 is www-data (the account that apache is running under).
: --Adam
What environment does apache have? If you started it on a login, it
may have your LOGNAME, which qmail-inject will happily use for a
return path.
-harold
From: <[EMAIL PROTECTED]>
: What environment does apache have? If you started it on a login, it
: may have your LOGNAME, which qmail-inject will happily use for a
: return path.
:
: -harold
SERVER_SOFTWARE = Apache/1.3.3 (Unix) PHP/3.0.5
GATEWAY_INTERFACE = CGI/1.1
DOCUMENT_ROOT = /www/flounder
REMOTE_ADDR = 169.132.9.210
SERVER_PROTOCOL = HTTP/1.0
SERVER_SIGNATURE =
REQUEST_METHOD = GET
REMOTE_HOST = xenon.telecom.idt.net
QUERY_STRING =
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 5.0; Windows NT)
PATH =
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
HTTP_ACCEPT = */*
HTTP_CONNECTION = keep-alive
REMOTE_PORT = 4699
HTTP_ACCEPT_LANGUAGE = en-us
HTTP_CACHE_CONTROL = max-age=259200
SCRIPT_NAME = /cgi-bin/printenv
HTTP_ACCEPT_ENCODING = gzip, deflate
SCRIPT_FILENAME = /usr/lib/cgi-bin/printenv
HTTP_PRAGMA = no-cache
SERVER_NAME = www.flounder.net
REQUEST_URI = /cgi-bin/printenv
HTTP_X_FORWARDED_FOR = 169.132.9.229
SERVER_PORT = 80
HTTP_HOST = ariel.flounder.net
HTTP_VIA = 1.0 xenon.telecom.idt.net:8000 (Squid/2.1.PATCH2)
SERVER_ADMIN = [EMAIL PROTECTED]
[EMAIL PROTECTED] is defined as ServerAdmin in httpd.conf, But
linuxapps.com has ServerAdmin defined separately in its VirtualHost entry,
as [EMAIL PROTECTED], so if it's using ServerAdmin to get the
return-path, then it should be using that one.
Anyway, I just changed the default ServerAdmin to [EMAIL PROTECTED], so
if I start getting bounces/etc to that email address I'll know why it's
happening.
--Adam
On Thu, Apr 01, 1999 at 12:54:12PM -0500, Adam D. McKenna wrote:
> Anyway, I just changed the default ServerAdmin to [EMAIL PROTECTED], so
> if I start getting bounces/etc to that email address I'll know why it's
> happening.
I am rather sure this will NOT help.
Try something like that in your apache.conf:
SetEnv QMAILUSER webmaster
SetEnv QMAILDEFAULTHOST www
SetEnv QMAILDEFAULTDOMAIN example.com
This will set an appropriate environmet for qmail-inject.
Happy Easter and a lot of coloured eggs to y'all!
Markus Stumpf
--
SpaceNet GmbH | http://www.Space.Net/ | In a world without
Research & Development | mailto:[EMAIL PROTECTED] | walls and fences,
Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | who needs
D-80807 Muenchen | Fax: +49 (89) 32356-299 | Windows and Gates?
From: Markus Stumpf <[EMAIL PROTECTED]>
: On Thu, Apr 01, 1999 at 12:54:12PM -0500, Adam D. McKenna wrote:
: > Anyway, I just changed the default ServerAdmin to
[EMAIL PROTECTED], so
: > if I start getting bounces/etc to that email address I'll know why it's
: > happening.
:
: I am rather sure this will NOT help.
: Try something like that in your apache.conf:
:
: SetEnv QMAILUSER webmaster
: SetEnv QMAILDEFAULTHOST www
: SetEnv QMAILDEFAULTDOMAIN example.com
Right, but where would qmail get *my* email address, unless it was told
explicity somewhere that mine was the correct one to use? The only place
that my email address (and not webmaster, etc) was present in httpd.conf is
for ServerAdmin.
--Adam
yes it is /usr/bin/procmail
> ok I mean sending an email through smtp-pop client it can send anything to
> anyone.. but I get the below message when I try to send to an aliased
> address.. (works fine say though pine)
>
> Mar 30 18:33:57 lan qmail-smtpd: 922847637.576748 14661: DENYMAIL:
> Filter.TO:_451_-exec_procmail_failed_-_try_again_later. relay
> client.stephenson.cc [192.168.1.3] FROM <[EMAIL PROTECTED]>
Pine does not use SMTP.
Check if your procmail is installed as /usr/bin/procmail.
--
Sam
Russell Nelson ([EMAIL PROTECTED]) wrote:
: Yusuf Goolamabbas writes:
: > Hi, The following web site
: >
: > http://www.imrss.org/dssl/
: >
: > seems to have a mechanism to prevent spammers from sending directly
: > from dial-up lines. The site has no docs on how to get qmail
: > integrated with it, Anybody have any idea
: Ought to work just fine using rblsmtpd. Look on koobera (as usual).
This might answer.
/*
Filter connections from dial-up hosts, based on patterns.txt
which is a list of regular expressions of dial-up ip hostnames
obtainable from www.imrss.org/dssl/
To build this, you must have already built djb's cdb package.
Compile with something like:
cc dssl-filter.c -o dssl-filter -I<path> -L<path> -lcdb
where <path> is the path to the cdb source directory.
To use this, first build the cdb version of the patterns.txt file:
{ while read dom hos; do
echo "+${#dom},${#hos}:${dom}->${hos}"
done; echo; } <patterns.txt |cdbmake cdbfile cdbtmp
(assuming a fairly modern sh-type shell.)
Make sure patterns.txt does not contain blank lines.
To run this, insert into standard djb exec chain:
tcpserver 0 smtp dssl-filter cdbfile qmail-smtpd
The filter requires TCPREMOTEHOST to be set if it is to do any
filtering, so don't use option -H to tcpserver.
No warranty, no restrictions, YMMV.
-harold
*/
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <regex.h>
#include <uint32.h>
#include <cdb.h>
#define FLAGS (REG_EXTENDED|REG_ICASE|REG_NOSUB)
int cdbfd;
char *
lookup(char * key, int len)
{
uint32 dlen;
static char buf[256];
if( 1 != cdb_seek(cdbfd, key, len, &dlen) )return(0);
if( dlen > 255 )return(0);
if( dlen != read(cdbfd, buf, dlen) )return(0);
buf[dlen] = '\0';
return(buf);
}
int
main(int argc, char ** argv)
{
char * remotehost;
char * dom;
char * hos;
regex_t regex;
int len;
if( argc < 3 )_exit(1);
if( ! (remotehost = getenv("TCPREMOTEHOST")) )goto done;
if( -1 == (cdbfd = open(argv[1], O_RDONLY)) )goto done;
for(dom = remotehost; *dom; dom++);
for(len = 0, dom--; dom > remotehost; dom--, len++)
if( '.' == *dom )
if( (hos = lookup(dom + 1, len)) ){
*dom = '\0';
if( 0 == regcomp(®ex, hos, FLAGS) )
if( 0 == regexec(®ex, remotehost, 0, 0, 0) )
exit(3);
*dom = '.';
}
done:
execvp(argv[2], argv + 2);
_exit(128);
}
I have just converted all of our 8000+ users to maildir format. We
don't use qmail but we do use maildir folders using our own MDA.
The mail is delivered in /var/spool/mail/username/
Anyway, shell users now don't have the nice "you have mail" or
"you have new mail" message anymore. So I started checking out the
source code of several shells and mail checkers to see how this
is handled.
It turns out that while in mbox format (see also the mbox(5) manpage
that comes with qmail) it only takes one stat() to find out if new mail
arrived, you need to scan the entire new/ and cur/ directories for
maildir format. With a lot of users who potentially have hundreds
of messages in their spool, this can be quite time- and disk intensive.
Now, with a bit of thinking I found out that this isn't nessecary at
all. The modification time on the tmp/ directory indicates when a new
message was last delivered, since that always goes through tmp/.
The access time on the new/ directory (set by readdir()) indicates when
a mail program last checked the maildir mbox. So, a complete scan
of new/ and cur/ stat()ing all files isn't nessecary at all.
However, since quite a few existing programs take the scanning approach,
they change the access-time on the new/ directory making the above described
approach invalid.
Would it be possible to define the method I decribed above as "the"
method to check for new mail (for shells, status bars etc) and to also
define that programs that actually scan cur/ and new/ should use utime()
to reset the access time on those directories after the scan?
With "the" method I mean the maildir manpage of qmail and djb's webpage
about maildir ..
[If so I could contact the authors of maildir-aware applications to
make sure they use that method]
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
At 11:16 PM Thursday 4/1/99, Miquel van Smoorenburg wrote:
>I have just converted all of our 8000+ users to maildir format. We
>don't use qmail but we do use maildir folders using our own MDA.
>The mail is delivered in /var/spool/mail/username/
>Now, with a bit of thinking I found out that this isn't nessecary at
>all. The modification time on the tmp/ directory indicates when a new
>message was last delivered, since that always goes through tmp/.
>The access time on the new/ directory (set by readdir()) indicates when
>a mail program last checked the maildir mbox. So, a complete scan
>of new/ and cur/ stat()ing all files isn't nessecary at all.
>
>However, since quite a few existing programs take the scanning approach,
>they change the access-time on the new/ directory making the above described
>approach invalid.
But mtime and atime are different right?
>Would it be possible to define the method I decribed above as "the"
>method to check for new mail (for shells, status bars etc) and to also
>define that programs that actually scan cur/ and new/ should use utime()
>to reset the access time on those directories after the scan?
Probably better not to have scanners invoking additional I/O if they can
avoid it (and they may not have +w access).
Making it "the" method would be interesting. If you are using your own MDA,
then it's pretty hard to argue why you don't just touch a .new file or some
such. And of course for those people who need it with mail-local, a
| touch .new
in a .qmail works just fine.
Not saying that you haven't a good idea, just that there are ways of
achieving this already for those people who need it and (speculation) with
declining direct shell access vs POP/IMAP. adding this requirement certainly
doesn't fall into the category of everyone needing it.
>[If so I could contact the authors of maildir-aware applications to
> make sure they use that method]
Good idea.
Regards.
According to Mark Delany:
> At 11:16 PM Thursday 4/1/99, Miquel van Smoorenburg wrote:
> >The modification time on the tmp/ directory indicates when a new
> >message was last delivered, since that always goes through tmp/.
> >The access time on the new/ directory (set by readdir()) indicates when
> >a mail program last checked the maildir mbox.
> >
> >However, since quite a few existing programs take the scanning approach,
> >they change the access-time on the new/ directory making the above described
> >approach invalid.
>
> But mtime and atime are different right?
Yes, but mail-last-checked is indictated by the atime on the new/ directory,
not the mtime. Mtime is changed at mail delivery (move into new/) or when
mail is moved from new/ to cur/ . The atime is changed only when an application
does a readdir() aka a scan on the directory. That's what a MUA does.
> >Would it be possible to define the method I decribed above as "the"
> >method to check for new mail (for shells, status bars etc) and to also
> >define that programs that actually scan cur/ and new/ should use utime()
> >to reset the access time on those directories after the scan?
>
> Probably better not to have scanners invoking additional I/O if they can
> avoid it (and they may not have +w access).
Well aditional I/O .. if you're doing opendir() readdir() stat() stat()
stat() stat() ....... closedir() anyway, one extra utime() won't hurt.
And a maildir is usually drwx------ anyway, so any program scanning
a maildir supposedly has write access anyway.
> Making it "the" method would be interesting. If you are using your own MDA,
> then it's pretty hard to argue why you don't just touch a .new file or some
> such.
Well it's not too hard to find out when new mail arrived - that's easy,
the mtime on tmp/ reveals that pretty well.
The thing is how do I find out if the mail has been checked / read!
I don't want to modify all possible MUAs. In fact, the MUAs already all
scan new/ for a fact. So taking the atime of new/ is the natural way.
I just want to make sure no additional programs ruin the atime of new/
> And of course for those people who need it with mail-local, a
> | touch .new
> in a .qmail works just fine.
Yes but not for the MUA (Mail User Agent). I want to find out when mail
was last checked, not when it was last delivered.
> Not saying that you haven't a good idea, just that there are ways of
> achieving this already for those people who need it and (speculation) with
> declining direct shell access vs POP/IMAP. adding this requirement certainly
> doesn't fall into the category of everyone needing it.
My aim is to integrate Maildir into standard programs. I've written an
MDA, a POP3 daemon and a smrsh application that can support mbox and
maildir simultaneously so migration of mbox to maildir is painless.
I'm also working with the procmail maildir-patch maintainer to get
proper maildir support into that, and I'm involved in other things like
the Debian/Linux project. I want maildir to become a real standard
on multiple platforms.
> >[If so I could contact the authors of maildir-aware applications to
> > make sure they use that method]
>
> Good idea.
But first I need an answer on the new/atime thing - from djb, I guess
as he would be the final authority on this.
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
On Apr 2, 1:10am, Miquel van Smoorenburg wrote:
> Subject: Re: maildir and "You have new mail"
> According to Mark Delany:
> > At 11:16 PM Thursday 4/1/99, Miquel van Smoorenburg wrote:
> > >Would it be possible to define the method I decribed above as "the"
> > >method to check for new mail (for shells, status bars etc) and to also
> > >define that programs that actually scan cur/ and new/ should use utime()
> > >to reset the access time on those directories after the scan?
[...]
> The thing is how do I find out if the mail has been checked / read!
> I don't want to modify all possible MUAs. In fact, the MUAs already all
> scan new/ for a fact. So taking the atime of new/ is the natural way.
> I just want to make sure no additional programs ruin the atime of new/
how are you going to stop a user from `innocently' updating the
atime of new/ with the following command?
ls ~/Maildir/new
if one is taking the time to build a tool, they should follow
a standard protocol, but I don't think a robust protocol should
depend on a parameter as volatile as a directory's atime.
> My aim is to integrate Maildir into standard programs.
A very worthy goal.
> But first I need an answer on the new/atime thing - from djb, I guess
> as he would be the final authority on this.
DJB, please don't weaken the maildir protocol to the point where
I can't `safely' use ls(1).
Regards,
Lenny
> Mike.
> --
> Indifference will certainly be the downfall of mankind, but who cares?
>-- End of excerpt from Miquel van Smoorenburg
--
Leonard Mastrototaro Systems Administrator Click3X New York
[EMAIL PROTECTED] 212-627-1900 http://www.click3x.com
"Yeah well ... The Dude abides." -- http://www.lebowski.com
On Thu, Apr 01, 1999 at 07:19:42PM -0500, Lenny Mastrototaro wrote:
> > The thing is how do I find out if the mail has been checked / read!
> > I don't want to modify all possible MUAs. In fact, the MUAs already all
> > scan new/ for a fact. So taking the atime of new/ is the natural way.
> > I just want to make sure no additional programs ruin the atime of new/
>
> how are you going to stop a user from `innocently' updating the
> atime of new/ with the following command?
>
> ls ~/Maildir/new
I think your thinking on this is a little exaggerated. Doing the above
listing is analogous to scanning (with "frm" or other appropriate tool)
a mbox file for all messages that do not have a "Status:" header field.
Obviously, doing such a scan would update the atime of the mbox file, as
does your listing.
I think the idea of checking the atime of new/ is a good idea and seems
like the perfect analog of checking the atime of the mbox file.
--
Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED]
Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
"Miquel" == Miquel van Smoorenburg <[EMAIL PROTECTED]> writes:
Miquel> It turns out that while in mbox format (see also the
Miquel> mbox(5) manpage that comes with qmail) it only takes one
Miquel> stat() to find out if new mail arrived, you need to scan
Miquel> the entire new/ and cur/ directories for maildir
Miquel> format. With a lot of users who potentially have hundreds
Miquel> of messages in their spool, this can be quite time- and
Miquel> disk intensive.
Miquel> Now, with a bit of thinking I found out that this isn't
Miquel> nessecary at all. The modification time on the tmp/
Miquel> directory indicates when a new message was last delivered,
Miquel> since that always goes through tmp/. The access time on
Miquel> the new/ directory (set by readdir()) indicates when a
Miquel> mail program last checked the maildir mbox. So, a complete
Miquel> scan of new/ and cur/ stat()ing all files isn't nessecary
Miquel> at all.
Doesn't the presence of any messages in the new dir indicate "You
have new mail." and the presence of any messages in the cur dir
indicate "You have mail." So you need to do an opendir and a readdir,
but you can stop at the first directory entry that looks like a valid
message. Hopefully I'm not being to naive. I'm hoping that the OS does
_not_ in fact read in the entire directory and then libc just returns
one entry at a time. If this is the case, then while you are saving
some CPU by not iterating though all of the directory entries, the
disk access is still the same, which is likely the expensive part.
j.
--
Jay Soffian <[EMAIL PROTECTED]> UNIX Systems Administrator
404.572.1941 Cox Interactive Media
On Thu, Apr 01, 1999 at 11:31:59PM -0500, Jay Soffian wrote:
> Doesn't the presence of any messages in the new dir indicate "You
> have new mail." and the presence of any messages in the cur dir
> indicate "You have mail."
Yes, if you use those words, but the prompt is really saying that "You
have new unread mail." which is different.
> So you need to do an opendir and a readdir,
> but you can stop at the first directory entry that looks like a valid
> message. Hopefully I'm not being to naive. I'm hoping that the OS does
> _not_ in fact read in the entire directory and then libc just returns
> one entry at a time. If this is the case, then while you are saving
> some CPU by not iterating though all of the directory entries, the
> disk access is still the same, which is likely the expensive part.
On Linux, readdir is implemented with getdents, which returns multiple
entries at once. However, it does not likely return more than one
block's worth of entries, in which case there is no extra I/O being done
anyways. IOW, yes the OS reads more than one but it doesn't really make
a difference.
--
Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED]
Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
