On Thu, 7 Jan 1999, Robert Franklin wrote:
> First up, if I feed in BOB@??? as an address, it won't match
> bob@??? in a DBM file, so I have a rule thus:
>
> *@* ${lc:$local_part}@${lc:$domain}
>
> Is there a better way to do this?
Nope. Though $domain should already be lower cased.
> Second, it says in the docs that Exim lower-cases the key field of a file
> when you use exim_dbmbuild, but NOT the value field (which make sense),
> so this caught me out with:
>
> [synonyms] mince@??? -> R.C.Franklin@???
> [names] R.C.Franklin@??? -> Robert Franklin
>
> (With Eh and w rewrite rules. The key for the second rule was
> lower-cased and so didn't match R.C.Franklin@??? due to case
> sensitivity.)
>
> Is there a reason why Exim shouldn't lower-case the key being looked up
> when doing a DBM lookup (since the keys will always be in lower case,
> anyway)? Or is it a speed thing?
The keys are only lower cased by default. The default is this way
because the most common DBM file is the system alias file. There is a
-nolc flag for exim_dbmbuild which prevents lower casing.
The RFCs about mail state that while domains are case-independent, local
parts are not. This particular rule is, in my opinion, a good candidate
for the rule that causes the most hassle, problems, and confusion.
Sadly, the revised RFCs are not changing it, so after 17 years we are
still stuck with it.
Your rewrite rule above is therefore not correct, because you are
applying it to *all* domains. You should not change the case of local
parts at domains other than those you control.
Exim, by default, lower cases local parts for local domains, that is,
being in a Unix world, it assumes caselessness for local parts. (You can
set locally_caseless = false if you don't like this.) However, it may
not make any such assumption about remote addresses. It is entirely
possible (according to the RFCs) that R.C.Franklin@??? and
r.c.franklin@??? refer to different mailboxes, though
R.C.Franklin@??? has to be the same as the first. IMHO this is
crazy, but what do I know?
Exim certainly has some odd corners as a result of this. I keep meaning
to do a sweep through it and try to come up with some clear rules, but I
haven't got round to it.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
