Illtud Daniel wrote:
> Highly unexpected today, every user on my system got an email
> when mail was sent to exim addressed to (literally)
> "*@mydomain.com". This was unexpected behaviour, to say the
> least. We use both a traditional aliases file and an LDAP
> lookup to AD, though I don't think that either was used in
> this instance as the headers on the message were:
>
> Envelope-to: *@mydomain.com
> To: *@mydomain.com
>
The best way to determine how it gets accepted is to run a test with debugging
enabled. This should tell you exactly which router accepted the address. I'm not
sure why you think LDAP lookup would not have been used. As far as Exim is
concerned (unless you've configured it otherwise) the '*' is a recipient and it
would try that recipient against all your routers.
'*' is the LDAP wildcard for searches. So it may well be that a search of the
LDAP directory with '*' as the search criteria did match everyone. If you don't
${quote_ldap} the $local_part in the lookup then '*' would have been the search
criteria.
Try running:
exim -v -bv -d+acl *@your.obfuscated.domain
> Any idea how this happened (I presume it doesn't work on all
> exim installations - try it!)?
No, not on mine.
Some output from the above test here:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Considering *@ion.le.ac.uk
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
routing *@ion.le.ac.uk
--------> system_aliases router <--------
local_part=* domain=ion.le.ac.uk
calling system_aliases router
rda_interpret (string): ${lookup{$local_part}lsearch{/etc/aliases}}
search_open: lsearch "/etc/aliases"
search_find: file="/etc/aliases"
key="*" partial=-1 affix=NULL starflags=0
LRU list:
:/etc/aliases
End
internal_search_find: file="/etc/aliases"
type=lsearch key="*"
file lookup required for *
in /etc/aliases
lookup failed
So, lsearch won't match.
A typical LDAP lookup results in:
--------> ldap_aliases router <--------
local_part=* domain=ion.le.ac.uk
calling ldap_aliases router
rda_interpret (string): ${lookup ldap { user=uid=xxx,dc=rsppg pass=xxx
ldaps://ldaphost/dc=rsppg?rfc822mailMember?sub?(&(objectClass=nisMailAlias)(cn=${quote_ldap:$local_part}))}
{$value} fail}
...
database lookup required for user=uid=xxx,dc=rsppg pass=xxx
ldaps://ldaphost/dc=rsppg?rfc822mailMember?
sub?(&(objectClass=nisMailAlias)(cn=%5C2A))
...
LDAP search: no results
lookup failed
ldap_aliases router declined for *@ion.le.ac.uk
So, LDAP searches for ${quote_ldap:$local_part}, which searches for the literal
string %5C2A, and this fails.
> And how can I stop it?
Until you've figured out *why* it happens, that's impossible to say. Well, one
way you could guarantee to stop it is to shut down your server ;-)
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
