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

Ben Schmidt wrote:
>> 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.
>
> My needs indicate no such thing, Bill, and I'd appreciate it if you did
> not assume so.
>

Not an 'assumption' - based on what you said - and you've just confirmed it
(below). Though not in a bad way... admins are still admins...

> Basically what is happening is that legitimate mail being sent out is
> being picked up by some mechanisms designed to prevent or at least
> reduce spam and the failure is particularly ungraceful. The whole system
> isn't in place yet (tests have revealed problems) but it happens because
> mail is generated dynamically by scripts and so is injected into the
> system slightly differently to how mailing list mail is, though the
> purpose is similar.
>

Understood.

> I have been in touch with the admins about it. Basically they are unable
> to change configuration simply because they use an out-of-the-box
> solution--I don't know whether the problem is a technical one or just a
> knowledge gap, but anyway, there we have it.

OK - so you are 'at odds', as I surmised - just over their limitations, not (so
far) over policy per se.

That's fine, and you will find willing help.

> But they are happy for me
> to install scripts and binaries to do, well, anything pretty much,
> provided, of course, I do so in a responsible way that doesn't overload
> the server or anything like that. Heck, they'd probably be happy with me
> running a daemon, though I haven't asked, and definitely don't want to.
>

Ok - familiar situation - and that open up some new, yet highly 'responsible'
options.. more later...

>> 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
>
> An MUA is a possibility, though it would still need to run on the
> server, not on another box (mostly due to lack of another box
> :-)--indeed that's the whole point of paying to have this host server).
> Do you have any ideas of ones I should investigate (Linux)?
>

Since you DO have at least a modicum of admin cooperation, I'd suggest another
route.

Give this a think.

There are Mailing List Managers (Ecartis to name one) that are;

A) Specifically designed to be installed and run completely in 'userland'.

B) need 'root' to install (only) one or several forwarding entries in the
/etc/aliases file - and not even that if used for outbound-reporting only.

C) *therafter* can be managed entirely by e-mail, and securely so. OR by editor
applied to user lists and config files if not configured to acpet incoming.

D) In the case of Ecartis, do a 'full court press' smtp session to *wherever*
(domain.tld / IP and port) they are pointed. i.e. do not even *have* to do their
outbound thru the MTA on the same server where they reside (though inbound would
be .. usually).

E) most important.. can do all manner of header *and body* manipulation of the
message, alter from and to address, - even REGEXP filtering -
insert/modify/convert (html to 7-bit) the content. Add or remove headers, block
duplicates, limit size, create digest files. Al /any of these. Or NOT.

That all may sound like gross overkill for your use, but an MLM is just as happy
with a list of ONE recipient (or 'few') as it is with many.

All the tools are there - even to diverting certain message types to where a
private httpd serves them up. Logging, debug, and who gets what sort of error
messages are configurable, Digests can trigger on size, message-count,
time-of-day - etc.

The Ecartis docs are a bit obtuse, but the config is dead-easy anyway. I've
even got Exim routers for virtual domain working with it.

But you don't need off-box incoming - so easier yet.

>> Building an exim, stripped or otherwise, to run in userland over
>> non-reserved ports is certainly possible.
>
> Well, that's good news anyway. It wouldn't need to listen on any ports,
> AFAIK, so port reservations shouldn't come into it. Can it run
> successfully without any daemon, i.e. just run and terminate to deliver
> mail?
>

Sure - but a full-blown MTA is gross overkill - and - more importantly, Exim is
NOT ordinarily in the business of altering message format - especially not
body content - which sounds like something your scripts could use a bit of aid with.

With the digest feature, you might just drop some portion of them into a place
you can web-view them and not need to send them off-box at all.

>> 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.
>
> Yeah, I realise it's more work. But it shouldn't put me at odds with the
> admins (unless I botch it :-)). Indeed, what I'm doing is engineering a
> solution that the admins don't have the time or inclination to do
> themselves.
>

Worth it if there are hundreds of such needs, ELSE a simple smtp binary for
raw/properly formatted traffic, or the MLM if manipulation would help.

There are tons of 'embeddable' or callable smtp critters in perl, python, ruby,
tcl, forth, etc.

As these are also sometimes an admin's worst nightmare, an MLM may be easier /
more welcome for admins and yourself to work with as it leaves proper
'footprints' - nice debug and activity logs and such.

Even more so if you are already running a decent MLM.

> If you or anyone else has further hints, particularly regarding the
> stuff I raised in the original email, I would be very appreciative to
> hear them.
>
> Cheers,
>
> Ben.
>
>

My tool of choice - if you haven't guessed - it a one-user Ecartis. OTOH, I use
it a lot for real lists the past many years as well, so the configs are easy.
Mailman is another failry configurable one - just not my area of expertise.

Happy to help you with that if you want to give it a shot, but on the ecartis
user or devel list would be more appropriate than here.

BUT - parting shot - their Exim configure can *very* easily be made to grant a
pass on whatever fltering is problematic wherein your traffic is coming 'cross
box' and/or from a known IP:port and/or auth method.

If it is on-box 'non-smtp' traffic it is actualy easier to skip the filtering
than to apply it, so a review of their config file would be a cheap first step.

Helping them do that should be the best solution all around, as there is less to
install, less to break, and once sorted - fewer hassles all around, as they'll
have familiarity with your special traffic.

Best,

Bill