Re: zmailer

[Alexis Yushin <alexis@NL.net>]

Oooof, slow morning,

	Does Columbus beer (9.5% alc) get to Finland somehow?

Once Matti Aarnio wrote:
>	I have a priorization at checking on things:
>	- is it potential security leak ?
>	- does it cause core-drops ?
>	- is it slow ?
>	- is it too ugly to watch ?
>	- all other stimuli I get
>	Order of the last three may vary.

        Yes, but I think the highest priority still should be
core dumps/misbehaviour because on in a large scale environments
like what ZMailer is supposed to be used in the worst thing is
when the thing breaks down at nigh or trash some mail. You may
be hacked once or not and they may succeed or not but if it
misbehaves you are definitely in trouble. Can make a company out
of business as well, half a day of no mail is enough for it in
fact.

	On other hand about revision system you should think of
two things: a) whether you want to be the only one who is able
to do zmailer development b) this will really help tidying things
and relieve you from keeping all the pieces in mind.

	Thats why perhaps it would be better to start with
revision control and somewhat more clear source tree (just remove
that obsolette, move things that are actually external packages
like libident, libresolv into separate directory so you can easily
keep them up to date with current versions of those libraries et
cetera)

>	Oh, it is easy :)   Once you have done it for years, you
>	wonder, why to bother with revision control systems..
>	After all, there are even bigger software projects running
>	without one.

	I can imagine! If you never have used it that coul be
somewhat of inconvinience in the beginning, but believe me it
worths the effort. I am willing to help you with that if you
want.

>> pieces of code if Matti is willing to divide it between them. If we
>> put a little more structure into the sources and make configurations
>> files neat I believe everyone can benefit from it. Does it make any
>> sense?
>
>	Yes, I would start with tidying of the router configuration
>	files, though.  (And the general source be in second place.)
>
>	Particular example of nice looking bit is your  map.cf, but
>	how do you use it ?  And what should I do when the resulting
>	db is not generated the way your default does things ?

	How could that be? If it is incore you have to awk it
if it is btree you have to makendbm it. This is true, you have
to add more types into case statement there. And perhaps 'default'
type that would check for all of the available databases types
in order to find one. But that gives you generic interface with
generic error handling for the rest of configuration. Just one
thing perhaps to put MAKEMAP= and AWK= into zmailer.cf

	How you can use it? You can replace all the occurences of
``if if if if then relation -t'' with it. Like:

     map btree fqdnaliases $MAILVAR/db/fqdnaliases -limt

instead of

     relation -limt btree -f $MAILVAR/db/fqdnaliases.db fqdnaliases

but that would take care of errors and defining fake lookup
function, rebultind the database  and keeping it up to date.

	Or, another example:

     map incore thishost $MAILVAR/db/localname "-l -d pathalias -s 0" || \
	thishost(name) {
	    .....

instead of

# We do local delivery, more or less, of mail arriving for these hostnames
if [ -f $MAILVAR/db/localnames ]; then
    if [ -f $MAILVAR/db/localnames.zmsh ]; then
        if [ $MAILVAR/db/localnames -nt $MAILVAR/db/localnames.zmsh ]; then
            local cmd
            cmd="$MAILBIN/make-incore.sh"
            "$cmd" thishost $MAILVAR/db/localnames $MAILVAR/db/localnames.zmsh
        fi
        . "$MAILVAR/db/localnames.zmsh"
    else
        relation -lt ordered -f $MAILVAR/db/localnames -d pathalias thishost
    fi
else
        # The default set of hostnames is:
        #       $rawhostname - system hostname, from /bin/hostname (or whatever)
        #       $hostname - the canonicalized version of $rawhostname
        #       $rawhostname.X, where X is a member of the set of organizational
        #       domains in $orgdomains.
        # We use a function and an incore relation, because this
        # file is loaded before the siteinfo stuff.
        relation -lt incore -b thishostdb
        thishost(name) {
...

	Another thing about configuration that it has a lot of
very nice functionality which noone ever uses in fact. Like all
those different ways of reading hostnames, localnames, ean delivery
bitnet delivery and so on and so on just hardcoded there not in
the most brief way actually. ZMailer kind of enables you to do
these things, its pretty exciting when you can run an external
command or a shell command at any point of handling email, but
still you have to be very careful and definite about the way you
do things and what is considered expensive and what is not. I
see it is shell scripts, so you dont have to make as brilliant
code as you would try in C, but still while we can do it simple
why wasting resource which are although available not required
for simple operations.

	And I vote for renaming standard.cf to basic.cf and
putting consist stuff there as well and perhaps something
else that nooone would ever want to change. This is another
thing separation policy - how separate things should be, should
it be quite a lot of little files or a couple of big ones. Seems
to be unimportant but when you have clear understanding on what
is good name/file size/coding way it helps you a lot to keep things
neat.

>	(I don't have 'makemap' program, ZMailer has 'makendbm', [which
>	 does need rename, and 'makemap' is quite good; but (ex-)sendmail
>	 users will have a hard time with different parameters..] )

	In fact I use makendbm in map.cf now too. But cause of
the nice name we can just rename it and add those options for
compatibility with makemap. It is not so different in fact.

Usage: makemap [-N] [-d] [-f] [-o] [-r] [-v] type mapname

	You see? Almost the same. No options conflicts and
if you dont give makendbm the third argument it should read
its stdin for the source file.

>	Huh?   (I do see uses for it, but still I wonder, if it
>		would help me..)

	Handy if you want to lookup something really old.
Perhaps a good think could be CVS (add on for RCS system
but handles directories, collective development and more more
fun stuff. I used RCS quite a lot but now I find CVS easier
to use even for small projects)

	Oh, that's a long email! Have fun and try to find
some of that columbus beer but dont drink it on wednesdays
evenings (or what it was yesterday? :-) Regards,
							alexis
-- 
	How can a flower so beautiful, be so laiden down with dew