Alan Curry
2001-08-07 09:02:27 UTC
I just finished my first test run of courier, and here are some of the things
I found wrong with it.
First, I got this message:
ERROR: your umask MUST be 022. Your install is HOSED.
You need to do rm -rf /usr/lib/courier (as well as any other non-default
directories you're using), change your umask to 022, then
rerun make install.
which is stupid for several reasons:
1. It scrolled by as part of the mountain of output generated by make
install, so I didn't notice it until I'd already spent a lot of time manually
chmod'ing things.
2. People who go running around with umask 022 all the time are the ones with
a problem. I always keep a secure umask 077 and I'm offended by the
suggestion that this is somehow a bad choice.
3. You have to chown all the installed files to the right user anyway... why
not just add a chmod for the ones that need to be readable by someone other
than the owner and root?
Even though ipv6 doesn't come anywhere near my test machine (it's not even
compiled into the kernel), courier found the header files, so it configured
itself --with-ipv6. This isn't necessarily bad, but it puts ipv6-style
addresses into the Received headers, even for mail that is received over
ipv4. This can only serve to make them more confusing to people who may have
trouble understanding a Received header to being with, and may not have any
idea what ipv6 is. Why not keep the headers in simple dotted-quad format,
without the ffff::, for messages that haven't actually touched ipv6? (and log
files too!)
The default From: line in bounces is completely bogus: <@>. That has to be a
violation of _something_ (besides just common sense that it should be
deliverable, and tradition that it should be MAILER-***@fqdn). If some
outside host sent me a bounce (or any other message) with From: <@> I'd be
inclined to treat it as I would any other blatant forgery - report it as
abuse to the ISP or just blacklist the server...
Since I'm not a umask 022 idiot, my first attempt to run courier resulted in
a lot of permission errors... and I discovered that it does not deal with
them well. For example, if courierlocal has trouble delivering a message
because it can't exec courierdeliver, it logs strerror(errno). With no
context. So all you see in the log is "courierlocal: Permission denied". Not
very helpful. I can't fix the permission problem unless the error message
gives some clue to what the hell it was trying to do when it got the EACCES.
It should look something like
courierlocal: exec(courierdeliver): Permission denied
Another bad case is if etc/locals is not readable. get_control_locals() in
courier/libs/islocal.c calls readfile(), which simply returns 0 if fopen()
fails for any reason. So a permission problem is silently ignored and courier
pretends the file didn't exist. (I guess you thought every time fopen()
fails, that means ENOENT? Wrong! Always check errno!)
Here's another permissions thing: courier/doc contains a bunch of html files
which for some reason are executable. The doc directory is the first thing I
went for after untarring, and files with needless x bits make me think
perhaps this thing was put together by the kind of luser who goes around
chmod'ing everything in sight to 777 because it seems to work and he can't be
bothered to learn what the permissions mean.
courier writes invalid mbox files! The mbox format requires a blank line
between messages. A /^
I found wrong with it.
First, I got this message:
ERROR: your umask MUST be 022. Your install is HOSED.
You need to do rm -rf /usr/lib/courier (as well as any other non-default
directories you're using), change your umask to 022, then
rerun make install.
which is stupid for several reasons:
1. It scrolled by as part of the mountain of output generated by make
install, so I didn't notice it until I'd already spent a lot of time manually
chmod'ing things.
2. People who go running around with umask 022 all the time are the ones with
a problem. I always keep a secure umask 077 and I'm offended by the
suggestion that this is somehow a bad choice.
3. You have to chown all the installed files to the right user anyway... why
not just add a chmod for the ones that need to be readable by someone other
than the owner and root?
Even though ipv6 doesn't come anywhere near my test machine (it's not even
compiled into the kernel), courier found the header files, so it configured
itself --with-ipv6. This isn't necessarily bad, but it puts ipv6-style
addresses into the Received headers, even for mail that is received over
ipv4. This can only serve to make them more confusing to people who may have
trouble understanding a Received header to being with, and may not have any
idea what ipv6 is. Why not keep the headers in simple dotted-quad format,
without the ffff::, for messages that haven't actually touched ipv6? (and log
files too!)
The default From: line in bounces is completely bogus: <@>. That has to be a
violation of _something_ (besides just common sense that it should be
deliverable, and tradition that it should be MAILER-***@fqdn). If some
outside host sent me a bounce (or any other message) with From: <@> I'd be
inclined to treat it as I would any other blatant forgery - report it as
abuse to the ISP or just blacklist the server...
Since I'm not a umask 022 idiot, my first attempt to run courier resulted in
a lot of permission errors... and I discovered that it does not deal with
them well. For example, if courierlocal has trouble delivering a message
because it can't exec courierdeliver, it logs strerror(errno). With no
context. So all you see in the log is "courierlocal: Permission denied". Not
very helpful. I can't fix the permission problem unless the error message
gives some clue to what the hell it was trying to do when it got the EACCES.
It should look something like
courierlocal: exec(courierdeliver): Permission denied
Another bad case is if etc/locals is not readable. get_control_locals() in
courier/libs/islocal.c calls readfile(), which simply returns 0 if fopen()
fails for any reason. So a permission problem is silently ignored and courier
pretends the file didn't exist. (I guess you thought every time fopen()
fails, that means ENOENT? Wrong! Always check errno!)
Here's another permissions thing: courier/doc contains a bunch of html files
which for some reason are executable. The doc directory is the first thing I
went for after untarring, and files with needless x bits make me think
perhaps this thing was put together by the kind of luser who goes around
chmod'ing everything in sight to 777 because it seems to work and he can't be
bothered to learn what the permissions mean.
courier writes invalid mbox files! The mbox format requires a blank line
between messages. A /^