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
