Reinhard Haller wrote:
>
> >> message:
> >> Warning: sender mscheld@??? does'nt match reply Mirco Scheld
> >> <mscheld@???>
> >>
> >> configure:
> >> warn condition = ${if eq{$acl_m9}{1}{yes}{no}}
> >> condition = ${if
> >> eq{$sender_address}{${address:$reply_address}}{no}{yes}}
> >
> >Just use the "eqi" rather "eq"....
> >
> >${if eqi{$sender_address}{${address:$reply_address}}{no}{yes}}
>
> Thanks for a possible solution, but this was not my problem.
Actually it is, you are asking Exim to make an equality check against
two values that need to have an equality neutral check done, thus use
eqi.
> Given the mail address:
>
> Reinhard.Haller@???
>
> I've seen the following expansions in the ACL:
>
> $local_part = reinhard.haller
> $domain = interactive-net.de
>
> $sender_address_local_part = Reinhard.Haller
> $sender_address_domain = Interactive-Net.de
>
> ${local_part:$reply_address} = Reinhard.Haller
> ${domain:$reply_address} = Interactive-Net.de
>
> From the debugging output (exim -d+acl) it seems that
>
> recipients = Reinhard.Haller@???
> local_parts = Reinhard.Haller
>
> don't compare against $local_part@$domain.
Actually they do compare, the information is exactly the same, just as
the RFC snippet below says, but what you asked for was an equality check
when the variables are not always 'normalized' before hand, go back to
the documentation and out of all of the variables you specified only one
has this:
"Note: The value of $local_part is normally lower cased. If you want to
process local parts in a case-dependent manner in a router, you can set the
caseful_local_part option (see chapter 15)."
http://www.exim.org/exim-html-4.40/doc/html/spec_11.html#CHAP11
>
> RFC 2821 (2.4) states:
>
> Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and
> extension name keywords) are not case sensitive, with the sole exception
> in this specification of a mailbox local-part (SMTP Extensions may
> explicitly specify case-sensitive elements). That is, a command verb,
> an argument value other than a mailbox local-part, and free form text
> MAY be encoded in upper case, lower case, or any mixture of upper and
> lower case with no impact on its meaning.
> Therefore my question:
>
> Is the behavior of the expansion operators address/domain/local_part
> feature or bug?
Not really a 'feature' per say, but definitely not a bug according to
how those variables are to work according to the documentation. You
could also force them to be cased with the ${lc:<variable> and then
do an equality check.
--
--EAL--
--
