Discussion:
[courier-users] various bugs
Alan Curry
2001-08-07 09:02:27 UTC
Permalink
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 /^
Sam Varshavchik
2001-08-07 11:38:43 UTC
Permalink
Post by Alan Curry
2. People who go running around with umask 022 all the time are the ones with
a problem.
What specific problem would that be?
Post by Alan Curry
I always keep a secure umask 077 and I'm offended by the
suggestion that this is somehow a bad choice.
Because it is, when you're about to install some stuff.
Post by Alan Curry
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
So, people who do not fully understand mail headers will find the mail
headers confusing. Yup.
Tell that to the sendmail folks.
Post by Alan Curry
violation of _something_ (besides just common sense that it should be
Well, when you find something that it violates, be sure to let us know.
Post by Alan Curry
inclined to treat it as I would any other blatant forgery - report it as
abuse to the ISP or just blacklist the server...
It takes all kinds.
Post by Alan Curry
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.
Solution: install Courier correctly.
Post by Alan Curry
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
Feel free to submit patches.
Post by Alan Curry
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!)
Yes: that's always a problem - incorrectly set permissions mean that you
have problems reading the file.
Post by Alan Curry
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.
Did anyone ever tell you that you have an attitude problem?
Post by Alan Curry
courier writes invalid mbox files! The mbox format requires a blank line
between messages. A /^
v***@tana.it
2001-08-07 14:24:01 UTC
Permalink
Post by Sam Varshavchik
[...]
2. People who go running around with umask 022 all the time...
Some people always log in as root: they obviously don't like
umask 022. For building Courier they must add "su" and "umask"
to their scripts. (People use scripts for their configure options
anyway, don't they?)
Post by Sam Varshavchik
ipv6-style addresses into the Received headers...
So, people who do not fully understand mail headers will find the mail
headers confusing. Yup.
I thought it was a mean for advertising ipv6 worldwide :)
Post by Sam Varshavchik
Solution: install Courier correctly.
That's not easy. In fact it's rated "medium" in
http://www.geocities.com/mailsoftware42/
Post by Sam Varshavchik
Yes: that's always a problem - incorrectly set permissions
mean that you have problems reading the file.
That's a good point. Even scripts like makehosteddomains need
that permissions be corrected after running them. Courier has
an open permissions model (which is why the lack of properly
formatted error messages is felt so hardly.) Hence, it doesn't
do any chown/chgrp/chmod.

System administrators obviously want to set their own rules
for grouping users and the like. For real users, with telnet
access, Courier doesn't break the existing security model,
still letting users run their own scripts.

For virtual users one has to work out a suitable set of uids and
gids. A rather obvious choice is courierusers:courierusers, which
may or may not coincide with courier:courier (or whatever was
given to configure). With MySQL one has the choice of assigning
a different uid:gid to each virtual user.

Carefully planning permissions will be a relief when virtual
users will be able to run their own scripts. Currently, webmail
doesn't allow to edit .courier files and I guess a somewhat
deeper understanding of security implications is needed
before that happens.
Post by Sam Varshavchik
I never understood why qmail didn't automatically create
./Maildir/ if it wasn't already there.
Well, try a bit harder to understand then, ok?
Admittedly, reporting that Maildir doesn't exist would be cleaner.
But then, if that happened in real life, one would be happier to
recover the mail message from a however formatted legacy mbox file.
Again, the problem gets solved by proper scripts that invoke
maildirmake and adjust permissions behind it. Since maildirmake
doesn't know how to adjust permissions, it wouldn't make sense
to invoke it automatically on the first message. (I'm not sure
this is the only reason, nor that it applies to Qmail as well.)


I hope this helps. However, as I'm quite new to Courier myself,
the above guesses may be either corrected by more experienced
people or validated by silent=assent.

Ciao
Ale
Sam Varshavchik
2001-08-07 22:03:40 UTC
Permalink
Post by v***@tana.it
Alan Curry writes: [...]
2. People who go running around with umask 022 all the time...
Some people always log in as root: they obviously don't like
umask 022. For building Courier they must add "su" and "umask"
to their scripts. (People use scripts for their configure options
anyway, don't they?)
Yes. And, it's a one-time deal. Actually, people should use pre-compiled
packages where possible.
Post by v***@tana.it
Solution: install Courier correctly.
That's not easy. In fact it's rated "medium" in
http://www.geocities.com/mailsoftware42/
I never said that it's supposed to be easy. See the big warning in the
beginning of the INSTALL file?
Post by v***@tana.it
Yes: that's always a problem - incorrectly set permissions
mean that you have problems reading the file.
That's a good point. Even scripts like makehosteddomains need
that permissions be corrected after running them. Courier has
[***@ny courier]$ cat makehosteddomains
...
umask 022
--
Sam
Lars Christensen
2001-08-07 17:08:47 UTC
Permalink
Post by Alan Curry
I just finished my first test run of courier, and here are some of the things
I found wrong with it.
This is where you make the first mistake. If you want to make suggestions, don't start by pissing the author off...
Post by Alan Curry
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.
Yup, I got that too, then I decided to actually READ the install instructions. If you had done that too, you could have saved yourself from typing most of the mail.

I found Courier when it was 0.30.0 and since I am not too experienced in installing and configuring any kind of software on Linux, I turned to the docs that are in the package. They may not be written in the style of Shakespeare, but they do contain all the information that is needed to make Courier work. Today I run a server with a mix of real and virtual users spread over multiple domains. I even customized the error messages returned with 8-bit errors, because I see som any of them.
It really isn't that hard to make it work if you READ the documentation.

I know this is off topic, but I felt I had to let it out...

Great work Sam!
Post by Alan Curry
[Snip IPv6 ...]
Regards
Lars Christensen
Aly S.P Dharshi
2001-08-07 18:48:08 UTC
Permalink
Hello All,
Post by Alan Curry
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.
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.
I think some of these things are mentioned in the postings over
and over and over. You should have referred to the INSTALL and README +
archives for known issues that people have had while compiling and
installing the software.
Post by Alan Curry
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.
Sam's choice. He must have a reason
Post by Alan Curry
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!)
I am sure there is an option to turn it off. The purpose of
configure it to determine the state of you system and O/S features and
install those features into the software. You need to use the
--with-options and --without-options.

As someone said this you donot start off by pissing off the
author, you may want to suggest calmly what you feel is wrong and suggest
what can be done to improve it. If you are not happy with this software
don't use it. But I hate when people abuse the author because they haven't
perused the archives for solutions or read the required docs. Lose the
attitude.

Cheers,

Aly.

---------------------
Aly S.P Dharshi
Student @ University of Lethbridge and
System Administrator ORS Servers
E-mail: ***@uleth.ca
v***@tana.it
2001-08-08 01:47:49 UTC
Permalink
If one doesnt' override the default (by writing "dsnfrom"), then
dns messages cannot be fetched by fetchmail. It gets "517 Syntax
error." Since it cannot fetch the message, fetchmail will report
such error in turn. It gives MAIL FROM:<FETCHMAIL-***@localhost>
Guess what answer it gets?

It is the rfc822check in courier/module.esmtp/esmtp.c which
enforces the "seendot" logic, independently of BOFHCHECKDNS.
Does it cause many bounces?

Ciao
Ale
Sam Varshavchik
2001-08-08 02:05:47 UTC
Permalink
Post by v***@tana.it
If one doesnt' override the default (by writing "dsnfrom"), then
dns messages cannot be fetched by fetchmail. It gets "517 Syntax
error."
Only if you have fetchmail attempt to reinject mail via smtp, which is a
completely broken approach. The problem is that you need to provide the
message envelope return address for the message. However, the message
envelope return address MAY be discarded after delivering message to the
mailbox, so fetchmail attempts to guess what it is by reading the mail
headers.

And fetchmail gets it wrong. Although the message envelope return address
MAY be discarded, Courier will usually save the message envelope return
address in the Return-Path: header:

Return-Path: <>
Received: from localhost (localhost [127.0.0.1])
(ftp://ftp.isi.edu/in-notes/rfc1894.txt)
by ny.email-scan.com with dsn; Tue, 07 Aug 2001 22:01:31 -0400
From: "Courier mail server at ny.email-scan.com" <@>

Fetchmail should use the Return-Path: header to reconstruct the original
message envelope return path, not From:.
Post by v***@tana.it
Since it cannot fetch the message, fetchmail will report
Guess what answer it gets?
An error. As well as it should, because @localhost is meaningless in the
great world of the Internet, with fully-qualified domain names.
--
Sam
Loading...