Dobes Vandermeer <[EMAIL PROTECTED]> writes:

> I want tmda-ofmipd (or any other tool, for that matter) to use the same
> configuration files & whitelist to send mail as I use to receive mail
> (tmda-filter).

It will... if you run it as root so it can setuid to the correct user.

> I'd like to be able to start/stop it using some kind of standard
> tool, and it would even be nice to have it log each message sent in
> maillog.

Some of us use DBJ's daemontools to run it along with numerous other
servers; this has been discussed on list.  Once you have tmda-ofmipd
running as root, it will log to the correct user's LOGFILE_OUTGOING,
if they have that variable set.  Actually, tmda-inject logs the sent
mail, not tmda-ofmipd, but the outcome is the same (per-message log).

> Unfortunately, I ran into a problem that spurred me to upgrade:
> tmda-ofmipd was exploding when I sent mail to people not on my whitelist
> -- it couldn't append to the whitelist file and died ungracefully.  I
> upgraded because I didn't want to bug you about the error unless I had
> the latest version installed (so I dont have the stacktrace anymore).

Once you run it as root and it switches to the authenticated user, it
will have no trouble updating that user's files.

> So far I've found a few gotchas that could certainly be documented or
> fixed:
> 
> 1. The crypt_key must be mode 700 or 600 -- however, when I receive mail
> I do it as myself, but when I send it the tofmipd user is used (so,
> basically I have to run it as myself).  Maybe this should allow other
> modes (e.g. allow tofmipd to read the file?)  This seems to be new since
> my previous version.

Run it as root.

> 2. It seems to require /etc/tofmipd or ~/.tmda/tofmipd; I dont want this
> file.  Also this file wants to be mode 700 or 600 so I can't "share" it
> with tofmipd.   This seems to be new since my previous version.

It used to require one of those files.  Now, if you use either remote
or program authentication, neither of those files is required.

> 3. Even if I was able to "share" my tmda config with ofmipd, it probably
> still wouldn't be able to update my whitelist, because it always creates
> that file with mode 600, which means whoever creates it is the only one
> who can read it -- this is the problem that I started with.

Hmm.  Run it as root?  (is there an echo in here?)

> 4. The auth command option, -A, makes it very difficult to write the
> command line for this correctly.  When you run it in the shell, you can
> say tmda-ofipd -A "/usr/bin/checkpassword-pam -s smtp -- /bin/true",
> however using daemontools you cannot use these double quotes with daemon
> --user, because it puts its own double quotes on (to pass to su -c) and
> doesn't escape mine.

Single quotes could work... i.e.,

  tmda-ofmipd -A '/usr/bin/checkpassword-pam -s smtp -- /bin/true'

> In other tools using checkpassword, the auth command is given the
> entire tail end of the command line for itself and its children so
> you dont have to deal with these quoting quirks.  I think its other
> option to authenticate using your actual smtp server might replace
> that, though.

This is worth considering, although generally those other programs
don't use checkpassword-style programs as an option -- they are a
requirement, whereas with tmda-ofmipd it's an option, so, like any
other option, you can place it anywhere on the command line or nowhere
at all.  Maybe any authentication option should be placed last and
tmda-ofmipd can figure out which is being requested (since all remote
authentication options are URL-like in format).

> 5. Its difficult to get the output -- it seems like initlog logs the
> first few lines but nothing more.

There generally isn't any output from tmda-ofmipd other than those
first few lines.  If you run it with the -d flag it will write
connection information to standard error, which can be passed to
multilog under daemontools, but loggin about the actual messages sent
is done by tmda-inject and takes place in the user's LOGFILE_OUTGOING.

Hope that helps,


Tim

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to