Re: [exim] Daemonless rootless exim for outgoing mail?

Ben Schmidt wrote:
> Hi!
>
> I've never configured or used exim directly, though surely it handles mail of mine
> that passes through some site somewhere!
>
> I am investigating using Exim to assist delivering outgoing mail, though. The mail
> server that is installed on the machine in question has some configuration I'm not
> happy with, but I don't have privileges to change it. I don't want to run a daemon
> or listen for connections at all; I can't need root privileges for installation or
> use. Basically I'd like something that can be called with the sendmail interface,
> that will attempt to deliver the message(s) given to it and then terminate. If it
> fails to deliver the message, I'd need some way of discovering this--perhaps a
> bounce message delivered to an mbox file in my home directory. Or perhaps a
> warning into an mbox file and leave the message queued for manual retry with some
> later command invocation (not automatic, as I don't want to get into daemons or
> cron jobs or such).
>
> A quick glance through the manual gives me hope that this kind of thing is
> possible, but I'm wondering if someone with a bit more knowledge could confirm
> that it is, and give me some hints, or point me to a HOWTO or something? I had a
> bit of a Google, but couldn't turn up anything useful, except that Exim seems to
> be the MTA to offer the most hope for this kind of thing!
>
> I'm also interested in how lightweight this could be made. What components would
> need to be installed, etc.? I need to compile Exim on a different machine and then
> transfer it, possibly along with some libraries, to make it work. It would be
> ideal if it could just be an executable, maybe some libraries, and a config file
> or few, as not much of the MTA's functionality is really needed. Perhaps even
> better if some functionality can be deactivated while compiling.
>
> I'd be interested in whatever wisdom and hints the list has to offer.
>
> Thanks in advance,
>
> Ben.
>

First off, most of us are mailadmins, sysadmins, or both. While polite, your
'needs' indicate that you are about to go head-to-head against [all | part of]
the policy of your host's [sys | mail | both] admin(s). As these are usually
driven by company policy, upstream ToS, and the 'laws of the land', that's
generally seen here as a non-starter.

Better to remain part of the solution than become part of the problem.

Best you should hope for then, is help in clarifying your needs so as to better
explain, then motivate, that/those individual(s) to 'find a away' both you and
they can live with.

Take as given that the 'sendmail' interface you cite has already been redirected
to Exim if that is the MTA of choice, and that any installation of, for example
a perl/PHP/<whatever> smtp tool of your own would soon/immediately be blocked
with firewall rules.

If you cannot convince the admins to supply what you need, then you have two
other non-confrontational options;

1) Pick up the <whatever> as a file in the same way you access the server, i.e.
via ssh's scp or...

2) get it mailed as an unaltered attachment to an off-box address by the
existing MTA, then program an MUA at that site - under *your* control - to
handle it as need be.

There are scads of MUA and MUA-like tools that can do everything an MTA can do
and more, from formatting to addressing to fax <=> email and voice-mail <=>
email to SMS <=> email. These will generelly be tick-the-box, set up a filter,
or and perhaps a bit of script configurable

Building an exim, stripped or otherwise, to run in userland over non-reserved
ports is certainly possible.

But it is a lot more work, and will likely get you at cross purposes with the
admin(s) regardless of how you try to limit it or finesse it.

Their box. Their ass. Their rules.

JM2CW,

Bill