Thomas kinghorn wrote:
> Good afternoon list.
>
> I am having a problem matching authenticated_id's in an ACL.
>
> I have 2 lists: auth_list_1 & auth_list_2
>
> auth_list_1: contains email addresses (which is used as the
> authenticated_id)
> auth_list_2: contains strings like: smtpauth-username
>
> I have macro's defined for each list
>
> I am trying to ACL authenticated_id's which are being abused
>
> in the ACL's section, I have:
>
> #Deny abused Accounts
> deny
> message = Prohibited Sender
> condition = ${if
> or{{match_address{$authenticated_id}{AUTH_LIST_1}}{eq{$value}{AUTH_LIST_2}}}}
> logwrite = :main: Compromised Account: Authid: $authenticated_id
>
> When I send a test mail using smtp_auth, the mail using the auth_id which is
> an email address, it denies the message correctly.
>
> However, when I try with the auth details smtpauth-username, if fails.
>
> The log shows:
>
> no @ found in the subject of an address list match:
> subject="smtpauth-username" pattern="user@???"
>
> A kick in the right direction would be appreciated.
> I can't seem to find a string expansion which works.
>
> Thanks
>
> Tom
A 'quicky' might be that you need to separate the 'user@???' into
'$local_part' and '$domain' with the '@' either implied or separately furnished,
as ISTR Exim slices the input along those lines unless otherwise directed.
If still no joy, then...
It would help to bump-up the information available so as better to pinpoint what
is happening. Or not.
The best method would be to sort a means to run an authenticaiton session into
Exim's superb 'debug' facility, as it is very comprehensive and can itemize
every step traversed.
Next best would be to ramp up the logging, as follows:
set:
log_selector = +all (temporarily - it can grow a log all-too fast!)
add to each acl you want to track;
logwrite = $<every> $<variable> $<you might want to monitor going *past*>
This will place a log entry EVEN IF the acl is not 'triggered'.
It lets you know what the environment looked like at that point in time, and
absent the next one, that the given acl has been sniffed-at, but was not used.
log_message = $<every> $<variable> $<to monitor if the acl DOES trigger>
Which will only place a log entry IF the acl was 'triggered' (conditonals all met).
If those do not spot the problem so you can sort it yourself, then we would need
to see the actual authenticator code - not just the above 'deny' acl - to go
much further.
Otherwise, one is guessing at what the cited clause is actually being 'fed'. vs
what you expect to be there.
HTH,
Bill
