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

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.

- 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.

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.

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.

-- 'shell' account holders need not have mail privileges at all. A seperate ID
can be used instead - one that is just one more 'virtual' user [1], and must
connect with an MUA over port 587, authenticate, and follow the rules in place
for that (smtp) session.

-- A Webmail daemon that uses a normal smtp session instead of directly invoking
the local MTA's binary can be used [2], and may or may not be on the same box as
your MTA. That means it can also support single-login for multiple, disparate
accounts - not all of them even your own, if you see fit to offer that option.

I don't know if these alternatives to manually buggering about with headers or
bespoke perl snippets [were ever | are still] 'best current practice' - but they
are available 'right out of the box' and sure make life easier HERE.

HTH,

Bill

[1] Taken perhaps to the extreme, even 'postmaster@' is in our virtual user DB.
Makes our rulesets easier to admin.

[2] Same again for a Mailing List Manager if that helps with easier maintenance
of rules. Pros and cons here.