Re: [exim] use of add_header - not an *exact* drop-in replac…

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] use of add_header - not an *exact* drop-in replacement formessage?
Eli wrote:

> W B Hacker wrote:
>
>>Thank you Eli!
>>
>>Just saved me a ton of grief.... (1700 line configure file... *many*
>>legacy
>>'message = ..' used where add_header could/should be..
>
>
> No prob!
>
> Though, I have now stumbled upon a possible drawback in the way add_header
> works. I decided that since I was rewriting some of my ACL lines to work
> (and make more sense in the flow of reading), that I'd rewrite the rest of
> them too... until I stumbled upon this one:
>
> deny message         = You must be authenticated to send from 
> <${sender_address}>
>      set acl_m10     = ${sender_address_domain}
>      sender_domains  = +domain_virtual : +domain_aliases
>      set acl_m10     =
>      !authenticated  = *

>
> I looked at it for a second and realized why I was setting acl_m10 twice,
> and specifically in the order everything appears:
>
> domainlist  domain_virtual      = ${lookup mysql {SELECT `host` FROM 
> `domain` WHERE `host` = '${quote_mysql:${if def:acl_m10 
> {$acl_m10}{$domain}}}' LIMIT 1}}
> domainlist  domain_aliases      = ${lookup mysql {SELECT `alias` FROM 
> `domain_aliases` WHERE `alias` = '${quote_mysql:${if def:acl_m10 
> {$acl_m10}{$domain}}}'
>  LIMIT 1}}


I see where you are going with 'domainlist', but find it simpler to put the
complexity into the DB and write shorter SQL calls...

i.e. an SQL '.....where $acl_m10' (full stop) tests it for null/not null,
avoiding need for an 'if def:' in Exim / pcre, AND ALSO eliminate the need for
double-handling acl_M10 in the first instance.

OTOH, our DB, authentication setup and routers are such that we don't need that
clause at all. 'helo_data', for example, can be a field in the same db record as
each user.

>
> A pretty little hack, quite possibly "stolen" from someone else on the list
> to help me overcome $domain issues. Of course, if I try to move the message
> line around I suppose I could end up with:
>
> deny !authenticated  = *
>      set acl_m10     = ${sender_address_domain}
>      sender_domains  = +domain_virtual : +domain_aliases
>      set acl_m10     =
>      message         = You must be authenticated to send from 
> <${sender_address}>

>
> Or if I didn't have the authenticated restriction, I suppose I could even
> start it off on the "set acl_m10 = ..." line, but perhaps there might be an
> ACL that someone has where it's just not possible to rewrite it in such a
> way that would work with the way add_header functions?
>
> I dunno - my personal opinion is that I'd prefer to have add_header function
> *just* like message did *IF* the point to using add_header is to ultimately
> abolish the use of "warn message = ...". However, if the actual intended
> use of add_header is to allow the unconditional addition of a header to a
> message, then perhaps calling "warn message = ..." depreciated behaviour
> should be revoked, and both methods kept for the future.
>
> Comments?
>
>

I expect 'message' to survive, but don't mind that it is no longer intended to
apply to a 'warn'.

Technically, a 'warn' has no part in communicating directly with a client -
only with variables, logs, headers, etc. 'inernals' if you will.

As I think of 'deny', 'drop', 'discard' as 'reject-class verbs', I think of
'warn' as an 'accountant class' verb. IOW, a scorekeeper or umpire, not a player.

YMMV,

Bill