On Wed, 15 Aug 2001, Graham Leggett wrote:
> The problem I have with this "this isn't ./configure..." argument is
> that it's usually used when a programmer didn't want to (too lazy to?)
> build in a proper configuration option, relying instead on #defines in
> source files and definitions in Makefiles and saying "it's the user's
> problem".
>
I'm hardly the one to blame for not having a configure script. But,
yes, I threw in most of the ifdefs as an afterthought - I knew I'd want
them, and I wrote the additional features because I have a particular
purpose. The way I look at it, maybe some of the features will get
incorporated into the actual qmail-ldap patch itself, at least there's
some code for these features (I know people have talked about the domain
specific basedns before, I'd have a hard time believing the smtp_auth
restricting to real addresses controlled by the users isn't highly desired
by many as well).
> I am a programmer myself, and am quite happy to go rooting around inside
> source files. But once I've done so I don't like putting those files
> into production without including the patches to the base code where
> this is possible. Usually the person doing the upgrade job six months
> down the line is me - and I know now that I will miss something and end
> up pulling my hair out no matter how good I note what I did down.
The best prevention for this is to test the patch, see what
does/doesn't work for you (and others as well), then convince the
maintainers these features are worth putting in the main patch. Some of
the ifdefs can be gotten rid of once the "right" behaviour is determined.
It doesn't matter to me whether this particular implementation of these
features gets incorporated, but it's usually more helpful for people
wanting features to have at least some code to offer to convince the
maintainers the features are valuable enough to include/work on. [Indeed,
I'm not entirely thrilled with my work, it was the first implementation I
came up with, for deadline-meeting reasons].
> > The next process gets whatever's in mailmessagestore (with
> > some compile time options for (a) ignoring absolute mailmessagestores and
> > (b) having a compiled in default mailmessagestore if that attribute
> > doesn't exist) - if that doesn't exist then it gets an empty string. This
> > may be incorrect behaviour.
>
> Intuitively if a / is placed at the beginning of a path it typically
> means "it's an absolute path, don't fiddle with it". As long as this is
> the default behaviour (and I understand it is) then it's fine.
It's not the default behaviour of my patch as released this time, but
you can easily make it that way for your setup. I didn't go to a lot of
effort to not interfere with the default qmail-ldap defines (as opposed to
the options I use) in this first release of the patch.
As far as the / meaning "... don't fiddle with it", this particular
option reflects my own planned set up where if I see an absolute maildir,
it means the ldap editing app has screwed up or someone's trying to screw
with the system. You're right, this should be restricted by the ldap
editing scripts, but I am sometimes excessively paranoid about such
things (even though stuff like '../../another.domain/user' won't get
detected, so it's pretty poor for any actual security purpose). The
option should probably get excised.
Lynn
