Re: default MTA for sarge
On Wed, Jul 16, 2003 at 11:29:01PM +1000, Martijn van Oosterhout wrote:
> On Wed, Jul 16, 2003 at 10:41:05PM +1000, Craig Sanders wrote:
> > On Wed, Jul 16, 2003 at 09:20:16PM +1000, Martijn van Oosterhout wrote:
> >
> > > I see sendmail configuration files that are ten lines long and I can't
> > > wrap my brain around them. OTOH, when I look at an Exim configuration I
> > > can see the steps. After global parameters, looks if the domain is in
> > > local_domains, if so see list A else list B. Each list is traversed in
> > > order until one matches and a delivery happens. Postfix seems the other
> > > way round; there is a setup somewhere that you tweak using options in
> > > your configuration.
> >
> > postfix does things in the EXACT order you specify. first match wins.
> > always.
> >
> > funnily enough, this is something really basic about postfix but lots of
> > people miss it. it comes up on the list quite often, usually in questions
> > about anti-spam rulesets.
> >
> > it is useful, e.g., when you want to have multiple aliases files or
> > local/virtual recipient tables.
>
> Yes, that's very good, but I'm not interested in the restrictions. My problem
> is the issue of transports. See, that basic config was only short because
> they left out at least the master.cf and god knows what else.
i guess that's because most people don't need to touch master.cf. postfix
users tend to take default settings as a given and ignore them...mostly because
that's the habit on the postfix-users list.
> See what I want is sort of: if user in list A, deliver as normal, else if
> list B, deliver but always as user mail (these accounts have no real user
> accounts), else if in list C deliver via this program. If file X exists then
> user is on vacation and give vacation message (remember, these users don't
> have home directories either).
user A: no special config required
user B: cut and paste a copy of the local transport in master.cf, change it so
it has "user=mail". call it, say, "vlocal". add a transport table entry like
so:
userB@example.com vlocal
alternatively, use the existing "virtual" transport.
user C: could be done as an alias, or with another transport (hard to tell from
the description you gave).
vacation for normal users can be handled with vacation(1). for virtual users,
you'd have to hack up a copy that looked for the .vacation files (or whatever)
some other than the non-existent $HOME or roll-your-own (perhaps as simple as
using the relocated map).
actually, now that i think of it, you can specify the directories that postfix
looks in for .forward files. see local(8) for details. btw, that's a very
important point: unlike most MTAs, postfix comes with excellent man pages for
everything.
anyway, the default is:
forward_path = $home/.forward${recipient_delimiter}${extension},$home/.forward
change it to:
forward_path = $home/.forward${recipient_delimiter}${extension},$home/.forward,/etc/postfix/forward/{$user}
and then you can use standard tools like vacation(1) in
/etc/postfix/forward/USERNAME files, something like so:
\USERNAME, "|/usr/bin/vacation -f /path/to/vacation.db -m /path/to/vaction.msg USERNAME"
all untested, of course, just created off the top of my head by reading the
docs, but it should work with very little tweaking. the only other thing i can
think of is that you need to make sure that the .forward files are readable and
accessible by whatever UID your virtual transport runs as, ditto the vacation
message file. the vacation.db file has to be readable and writable.
in all, i doubt if it would take more than a few hours to configure postfix to
do exactly what you need....and that's starting from scratch, including time to
read docs and google for info.
> My favourite feature is builtin message filtering, allowing me to do all
> sorts of neat tricks. The vast majority of viruses coming through are picked
> up with simple pattern matching of the MIME headers without resorting to
> external programs.
ditto postfix.
i have a simple PRCE header_checks rule that rejects windows executable attachments:
/^Content-(Disposition|Type):\s+.*(file)?name="?.*\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dll|exe|hlp|hta|in[fs]|isp|jse?|lnk|md[be]|ms[cipt]|ocx|pcd|pif|reg|sc[rt]|sh[bs]|url|vb[esx]?|vxd|ws[cfh])\b"?\s*$/ REJECT executable file type rejected, please compress with zip and resen
> > Ralf Hildebrandt has some excellent docs and howtos and sample configurations
> > (incl. a tar.gz of his /etc/postfix directory which also contains a useful
> > Makefile to automate everything...i should send him a copy of my Makefile in
> > case there's anything he can use in it). anyway, his site is at:
> >
> > http://sbserv.stahl.bau.tu-bs.de/~hildeb/postfix/
>
> Yep, I see it and I downloaded his example postfix directory. I'm not seeing
> any semi-complicated virtual-hosting setup
virtual hosting isn't complicated in postfix. it's a no-brainer to get working.
it is also very well documented. see, for example the various HOWTOs under
the POP/IMAP section of http://www.postfix.org/docs.html - and, of course,
/usr/share/doc/postfix/VIRTUAL_README.gz on your nearest debian postfix box.
> with vacation and bsmtp support.
for comments on vacation, see above.
i've never done bsmtp on postfix (i prefer uucp) but it doesn't appear to be
difficult. a bsmtp transport entry (that uses the bsmtp package) is in the
master.cf included with the debian postfix packages. see pipe(8) for more
details on pipe-based transports such as bsmtp.
> Like I said, it's probably possible but all these small files give me the
> creeps.
what small files? you mean map files? you can't mean anything else because
postfix only has two configuration files - main.cf (general configuration) and
master.cf (controls available transports, what daemons are run, how many, what
args, etc). most people never need to touch or even look at master.cf.
map files are data, not configuration. where else are you going to store data
(as opposed to configuration)? in the config file itself[1]? that's as silly as
expecting that /etc/passwd should be #included into the config file - it's just
data too.
[1] in postfix, you CAN actually store most values inside main.cf itself if you
want to. for single-valued options, it's even convenient. for lookup tables
or multi-value options it's far more convenient to store them in a separate map
file[2]. make it a hash/dbm/btree map file and you don't even need to reload
postfix when the you update the .db, postfix will notice the update
automatically.
[2] map "file" is a bit of a misnomer, as a map can be a file (plain text,
indexed db, pcre or posix regexp), postgres or mysql connection, ldap, unix
domain socket, or a tcp map (i.e. remote query to any host:port).
map types supported by the debian package are:
$ postconf -m
static
nis
dbm
regexp
environ
proxy
btree
unix
hash
tcp
sdbm
pcre
ldap
the postfix-pgsql and postfix-mysql packages add the appropriate SQL map types.
i don't use either, i prefer to dump Pg databases to text files and turn them
into hash maps. much faster, and the mail server still keeps on working even
if the Pg server isn't available.
craig
Reply to: