Postoffice
is a simple SMTP mail server and client. I
wrote it for pell because spam was getting out of control and
I would rather write my own mail service than continue to hack
up sendmail for antispammery.
Postoffice provides a greylist to slow down the rate of incoming spam, and can be configured to do antivirus checking on incoming mail either via the sendmail milter protocol or a traditional hardcoded AV program.
Postoffice can be configured to deliver mail
to accounts inside
vm-pop3d-style
virtual domains, and it can further be enabled to
support AUTH LOGIN for people inside virtual domains, so they can use
postoffice as a mail forwarder when replying
to mail (I've also written some
virtual domain utility programs
to go along with the virtual domain code in
postoffice and vm-pop3d.)
Postoffice
accepts (and ignores) many of the same command line
options that are passed to sendmail,
and it comes with the usual crop of sendmail compatable
aliases; runq, mailq, newaliases, and sendmail.
Pierre-Philipp Braun at nethence has written documentation on how to run postoffice on a non-ia32 NetBSD box.
AUTH LOGIN was not working, because the Username:
string was being uppercased during message writing and,
in addition, domain 0 handling wasn’t working inside
auth.c. 1.4.9 corrects this defect and makes postoffice
work better with networked mail clients.<limits.h> to the offending modules.AC_SUB, blank expansions were coming out as ^?,
which is not what I had in mind. Macos uses the gnu
sh clone instead of a real Bourne shell, and that
was having echo ${@} expand to ^? inside
the shell? Okay, colo(u)r me confused, but I fixed
it, I think.(there is no 1.4.7; I bobbled the version#s and skipped a number)
1.4.6 adds a new configuration option — trusted=hostname,
which tells postoffice to treat hostname as if
it was localhost. In addition, I've tweaked the mx getter
so that if you set localmx, you need to to explicitly set
the MX for the remote machine before it’s treated as localhost.
On the bugfix front, when I went in and attempted to make
gcc -Wall quieter, I managed to break builds without the
milter code enabled. So 1.4.6 fixes that.
This version sweeps some of the grottier parts of the milter interface
up into tidy stub functions, plus changes the way postoffice
handles RCPT TO: before MAIL FROM:; it used to spit
out a 501 error before it dropped the address, but it now
returns a 250 before it drops the address.
I'm willing to do this because of the milter problem I corrected
in postoffice 1.4.0 — since some common
milters (spamassassin, clamav) drop into an infinite loop when
they get RCPT TO: before MAIL FROM:, that means that
it never happens under the higher-priced brand and so I won’t
have to worry about legitimate mail tripping over this feature.
CC=`gcc -Wall` and get a clean build without
errors. The code changes are gross (and inefficient, and quite
possibly bugridden,) but now stupid gcc will pass them right
on by without complaint.spam=bounce wasn’t setting
spam=bounce; this was reported by Bob Dunlop, who was
evaluating postoffice for inclusion in an
ARM-based system)) and has a fairly extensive code scrub to sweep
out things that the FSF’s so-called “C” compiler complains about.
Some of this was simply housekeeping (I added a configure check for
the volatile keyword, then plastered volatile
prefixes on everything that gcc complained about in functions
containing setjmp/longjmp; on systems that don’t
support volatile it #defines that keyword to an empty comment,)
some involved some minor code rework (forcing an assignment to a
variable that wouldn’t be set if a loop failed; previously I was
failing the condition when loop counter==max,) and some involved
tweaking configure to disable the stupid warning (I combine assignments
and tests by doing if ( var = setter() ), and gcc whines
bitterly about this unless I change my coding style or append
-Wno-parentheses to CFLAGS. I'm not going to change
my coding style after 30 years of programming, so I have changed
CFLAGS instead.)spam=-like configuration options to
manage connections from blacklisted sites similar to how
spam-ridden messages are currently handled. Like spam=,
blacklist= supports bounce, accept, and file options,
which work much like they work with spam=
spam=folder,
with a ~/ prefix meaning a folder in the user’s home
directory, otherwise a folder in the mailspool.Date:, Message-ID:, or From: header. If it
does not, those headers are generated and placed into the
additional headers
section of the control file. The bug is that
postoffice didn’t bother to ever check the
additional headers section for those required headers, and would
thus add a new copy of the originally missing headers every time a
queuerun would happen. If you're attempting to send mail to a site
that refuses to accept it, the additional headers section will grow
without bound.
It’s a dumb coding error, but by the simple expedient of pulling the
header scanner into a separate function I could fix it without causing
too much additional code bloat.junkfolder= feature that I
introduced in 1.4.3; I've renamed the setting to
spam=, which can now take three values:
why is an optional reason that you can give (one line
only) for bouncing the spam-infested mail.**X-Spam:**
header to the message that contains the diagnostic message from the
milter or av program. If the incoming message already contains an
X-Spam header, that header will not be removed.junkfolder= has become. And the behavior
of spam=folder has slightly changed here; local
users will have their spam-infested mail delivered to the
spamfolder, but remote (and virtual domain) users will have
the spam delivered as if the setting was spam=accept.
Spam=folder is now a fancy enhancement to spam=accept
that doesn’t require every user to use procmail to weed
out the X-Spam'med messages. The folder format is slightly
different. There are now two types of valid path:
**~/**path, which writes the spam to the folder path
in the users home directory. path can be anything
(it’s treated like a /path in a .forward file), so the
restrictions on file redirections apply here.suffix, which writes the spam to the folder
username:suffix in the mail spool directory.
If you're using imap, this might be a better solution
than writing the spam to the users home directory,
though the usual caveats about the file growning without
bound still apply.As an extra treat, I've actually documented the spam= option now.
1.4.3 introduces one new feature; if you set the config file
option junkfolder=, unwanted mail will not be bounced but
will instead be put into a junkmail folder named
<user>:<junkfolder>. This is a first release of this
feature, implemented in a hurry because I needed to change my
spamcatching behavior so I could catch spamalike mail coming
in from my relatives.
As an artifact of the hasty release, there is no documentation other than what’s written here. It’s possible that the functionality will alter over the next few weeks, but if you desire adventure this is the software release for you.
vfprintf()s in va_start/va_end, but
spread them around both of them. On the 32 bit Linuxes
I've installed on this doesn’t make a difference, but the
64 bit world is, um, different. Ooops.1.4.1 fixes some of the bugs that were in 1.4.0, adds missing features
(and the missing manual page for usermap(7),) and
has been tweaked so that it builds on another linux
variant (ubuntu on an am86 machine.)
usermap(7) manpage.SATH-ORC was not matching the sath-orc entry in my
~/.alias file. Ooops.)AC_CHECK_RESOLVER (in
configure.sh)
to look for the presence of the Berkeley resolver library.
This code attempts to autodetect the broken
Darwin)
resolver library (Darwin, being essentially a FreeBSD
branch, has library interfaces that mutate just as fast as
gl*bc does. Using BIND_8_COMPAT is only a temporary patch,
and I'll probably have to switch to the djbdns client
library to get a more-stable replacement for res_query(),)
so it may break Darwin anew.The resolver library detection fix and the code cleanup was
because of a bug report from Wink Saville, who
tried to build postoffice on a 64-bit ubuntu
7.04 machine. The resolver library
wasn’t detected because there doesn’t appear to be a res_query()
in glibc 2.8 (it’s a #define for __res_query(). Ugh,)
then, after I tweaked configure.inc so that it would actually
DETECT the resolver, it dumped core because I didn’t include
<time.h;> before using strftime() [sizeof(time_t) !=
sizeof(int) on an am64 machine] so I had to go on a binge of
adding the appropriate #include’s to circumvent any
all-the-world’s-a-VAX‘isms
that were in the code. (There are still quite a few implicit
global functions inside postoffice, but those
are functions that return small scalars (I'm not overly
worried about what happens when a message gets more than 2^31
unique recipients on it; I suspect that by that time the machine
would be so far into swap that the heat death of the Sun would
happen before it finished processing the headers.)
1.4.0 introduces the new feature of usermaps, which are a
way to let users have temporary mail addresses which they can use
when they deal with possible spammers. A usermap is simply a personal
alias file (formatted like the aliases(5) file) which is placed
in a home directory, and which is referred to by a usermap option
in postoffice.cf(5).
The usermap option is formatted as pattern:target{,target};
the pattern is a shell-style wildcard, with the addition of using
the ~ to match any valid user in the domain. A match is either
an alias or the special token ~/filename, which is the address
of a personal alias file. When a usermap is called,
postoffice will try each target, stopping when it
matches one.
There are also a couple of trivial bugfixes in 1.4.0For example, the usermap *–~:~/.alias,bounce will match any mail address of the format something–user. If it matches an address, postoffice will first see if the address is in ~user/.alias, and then if it doesn’t find a match there it will map to the fixed address bounce.
MAIL FROM and
RCPT TO commands and will accept them in any
order as long as both of them have been issued when a DATA
command arrives. But some of the sendmail filters (milters)
I use are not so forgiving, and if they get a RCPT TO
prior to a MAIL FROM, they will freeze and lock the
mail session. This is bad programming, to say the least,
but it’s broken in a sendmail-compatable fashion so it’s
not likely that it will ever change. So I've crippled
postoffice (if built with --with-milter) to whine bitterly
about RCPT TO without a prior MAIL FROM. malloc.h so I can only include it
on machines that actually have it. This is a generalization
of the OS_DARWIN support that Andras Salamon contributed
for 1.3.8c, and should make the code a little bit more
portable to other machines that use C compilers that blindly
follow the whims of the (break-all-of-the-)standards
committees.