Re: [exim] ACL rewrite

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] ACL rewrite
Searcher wrote:
> Erm
>
> I can't really explain the entire network, coz it would be a security
> breach, but erm
>
> - this exim is just a relay for few domains only
> - purpose of this exim is to have all participating users reply to the
> correct email address and not the sender directly - so the email can be
> processed on our servers (whatever processed means in this case)
>
> Nothing else, no spam checking, no antivirus, forget even the
> subset_list@??? rewrite as it's not relevant since
> it's not a list but *@*.special.domain to $1@$2.
>
> hammer? yes/no? ;)


Yah - I grokked all that .... but still can't figure out why you'd want
to munge the addresses... given that Exim does whatever you tell it to
do with traffic and is not overly picky about HOW you tell it.

IF you are attempting to *conceal* the man-in-the-middle behaviour
you've described, there are better ways to do that. (Though not
necesarily any more - or less - 'legal').

But that's between you, your paymaster, and your local/national government.

Not my call.

Bill




>
>
> -----Original Message-----
> From: exim-users-bounces@??? [mailto:exim-users-bounces@exim.org] On
> Behalf Of W B Hacker
> Sent: Sunday, May 18, 2008 04:27
> To: exim users
> Subject: Re: [exim] ACL rewrite
>
> Searcher wrote:
>> I tried to use your last suggestion but to no avail
>> If I understand it correctly though, it does not rewrite anything but
> sends
>> the email to the *new* recipient?
>
> Yes - your post *seemed* to indicate that you have both the:
>
> <subset_list>@our.domain.special.domain
>
> - active on 'a' server, as well as the:
>
> <entire_list>@our.domain
>
> AND that you are already munging the 'From: / Reply To:' to intercept
> the traffic for 'probationers'.
>
> So why bother with the extra manual rewrite when straightforward
> aliasing can serve?
>
> Given that I can't fathom even *why* you are doing all this, I'll take
> as given that you may not be doing things quite that way.
>
> Just because you have found a hammer doesn't mean you cannot use it for
> a walking-stick instead of driving nails. One can get used to the
> leg-cramps.
>
> ;-)
>
>
>
>> I tried couple (zillion) of other things with my previous settings and
>> suddenly realized that the config file number is actually a sequential
> order
>> how the files are being loaded (dummy) and managed to get it working by a
>> quite simple, eh:
>>> 30_exim4-config_check_rcpt
>> set acl_m7 =
>> ${lookup{$local_part@$domain}lsearch{/etc/exim4/sc_clients}{$value}{}}
>>> 31_exim4-config_rewriting 
>> *@*    $local_part@$acl_m7    Ffrsq

>>
>> Where /etc/exim4/sc_clients uses the alias format
>> recipient@???: new_sender_domain
>>
>
> Over my head. That is all Debian/Exim-specific stuff.
>
> The regular Exim install has only one configure file, and, yes, various
> 'functional' parts of it need to remain in expected order.
>
> Likewise sequence within each part very much matters.
>
>> And this does exactly what I was after: if the recipient is in the alias
>> file it rewrites the sender, if the recipient is not in the list nothing
>> happens.
>>
>> Thank you for all your help Bill
>> But if you still think I'm doing it wrong and have the patience to explain
>> it - I'm all yours
>>
>> Thanks
>> -src-
>>
>>
>
> I haven't a clue if it is right or wrong. I don't see what you believe
> you are gaining.
>
> If the goal is to temporarily monitor new accounts, or to place
> different quotas or other restrictions on them while awaiting approval,
> or throttle based on 'class' (or fees) .. or whatever... I don't see any
> of those goals served by munging addresses.
>
> *Most especially* not the <domain>.<tld> side!
>
> You either have control of account@??? and their settings, or NOT.
>
> Bill
>
>
>
>> -----Original Message-----
>> From: exim-users-bounces@??? [mailto:exim-users-bounces@exim.org] On
>> Behalf Of W B Hacker
>> Sent: Thursday, May 15, 2008 20:45
>> To: exim users
>> Subject: Re: [exim] ACL rewrite
>>
>> Searcher wrote:
>>>> - all recipients to be handled are your clients
>>> Yes they are
>>>> - all affected deliveries are 'local'.
>>> None of the deliveries are local, this is just a forwarder of emails to
> be
>>> modified or to be left untouched - the only purpose of this instance of
>> exim
>>> is to sort emails 2 ways
>> *snip*
>>
>> - Dump all the acl stuff and single-recipient limit stuff.
>>
>> - pick up the 'default' system_aliases router:
>>
>> ====
>>
>> system_aliases:
>>    driver = redirect
>>    allow_fail
>>    allow_defer
>>    data = ${lookup{$local_part}lsearch{/etc/aliases}}
>>    user = mailnull
>>    group = mail
>>    file_transport = address_file
>>    pipe_transport = address_pipe

>>
>> =====
>>
>> rename it from "system_aliases:" to, for example "probationary:"
>>
>> Change the path and filename {/etc/aliases} in
>>
>> " data = ${lookup{$local_part}lsearch{/etc/aliases}}"
>>
>> to some other /path/filename that Exim's 'group' can read, and that your
>> appointed admin (person or script or web interface) can write to.
>>
>> Example ownership: specialadmin:mail
>>
>> Use a script, web interface, SQL DB trigger, or POT editor to put
>> those-who-are-to-be re-written into that new file and take them out later.
>>
>> Use the conventional alias file format:
>>
>> recipient[1]@our.domain.special.domain: recipient[1]@our.domain
>> .
>> .
>> .
>> .
>>
>> recipient[n]@our.domain.special.domain: recipient[n]@our.domain
>>
>> Delete them or comment them out when they are off probation.
>>
>> No need to restart Exim.
>>
>> No need to do a 'newaliases' or such - Exim will read the specified file
>> directly, not a db/cdb of it.
>>
>> Place this ahead of whatever router handles those who are no longer to
>> be re-written - e.g. 'normal' folks.
>>
>> AFAIK, that relieves you of the need to re-write headers manually at all.
>>
>> KISS. You *could* just use the stock router and /etc/aliases file,
>> though on ownership/perms and location grounds alone, I'd suggest not
>> mixing them.
>>
>> HTH,
>>
>> Bill
>>
>>
>>
>
>