Re: [exim] How to enforce valid From: header on local mail?

m. allan noah wrote:
> On Thu, Apr 22, 2010 at 10:47 AM, W B Hacker <wbh@???> wrote:
>> m. allan noah wrote:
>>> Hello- have a question about header rewriting in Exim, which I have
>>> spent a couple days trying to solve.
>>>
>>> I need to make sure that all locally generated email (from
>>> /usr/sbin/sendmail or from localhost via smtp) has a proper From:
>>> header. Basically trying to prevent outgoing spoofs from our
>>> (relatively untrusted) users. I would prefer to use perl, since some
>>> of the checks for validity (aliases, etc) are kinda complicated.
>>>
>>> So, I have tried adding headers_rewrite to a transport, or setting up
>>> a rule in the global rewrite section of exim.conf. Something like:
>>>
>>> *@* ${perl{foo}{$1}{$2}{$sender_host_address}} f
>>>
>>> Where my function foo() returns a 'corrected' address for local hosts.
>>> I think I can cover all the corner cases to make that work reasonably.
>>> Unfortunately, it does not seem to work if there is no From header in
>>> the mail.
>>>
>>> So, my question is this: How can I detect that no From header has been
>>> sent, and add one? Or, is it possible to have a perl function receive
>>> all the headers at once, and make this determination?
>>>
>>> Thanks for any help you can provide.
>>>
>>> allan
>> - Exim has several built-in settings that deal with enforcement specific to
>> 'local' sources of traffic. You can select what best fits your need, and ISTR
>> there are header-specific tools among those options.
>
> Thanks for the pointer. Section 44.11 of the current manual indicates
> that local program invocations (submission mode) will have From:
> header added if missing. Section 44.1 shows how to cause exim to treat
> local smtp connections as if they were submission mode. I am not sure
> how that will work, since smtp process is not running as the sender,
> but I will test it.
>
>> - Keep in mind that traffic presented by direct invocation of the binary does
>> not entail an smtp session with an external subitter, ergo does not ordinarily
>> traverse the 'standard' acl_smtp_xxx acl clauses *at all*. Have a look at
>> 'acl_not_smtp' instead if you need to craft rules for such.
>
> Thanks for that info. So far I have been using global rewrite rules,
> not ACLs, so they apply to all mail.
>
>> After perusing these several other tools, you will probably find a more durable
>> solution - one that does not require you to create any perl code or even have to
>> manually deal with headers.
>
> Perhaps, though our concept of 'valid user' is a little hairy, and
> I've been accused of thinking in perl, so i think it will be both
> required and durable :)
>
>> Finally - not specific to Exim, but to ANY MTA or even bare-bones smtp binary
>> and 'on box' or web-interface users:
>>
>> It sidesteps a whole universe of potential problems and is not overly dificult
>> to not even *allow* 'local' (shell account) users or daemons to make direct use
>> of the MTA by means of invoking [ the | a ] smtp binary.
>
> I agree in principle, but have thousands of users with existing cgi
> scripts and such that call out to the on-disk binary. Extremely
> difficult to change at this point.
>
> Thanks for the input. I will continue to poke at it.
>
> allan

Allan,

'An ounce of prevention...'

In that situation, it might be easiest to rename or 'front' the binary and
instead route the cgi scripts that seek the expected executable through a
pre-filter script of that name (written in perl, perhaps?).

Should be near-as-dammit invisible to the caller, but give you as much - or as
little - flexibility as you need to intercept the [few | many] problematic ones
w/o having to bend much in the 'standard' Exim environment.

Not to forget that keeping such beasts from running their OWN smtp critters is
also possible - block outbound to any remote port 25 in your firewall rulesets
for all *except* the Exim-runner.

HTH,

Bill