graeme, thank you for replying, as it gives me further insight
into tracking down exactly what the hell is going on.
i will endeavour to track down the scope of this problem a bit
further, because i have just tried this:
HELO localhost
MAIL FROM:<>
RCPT TO:llllllllllllltotallyfakeaddress@localhost
and _that_ was accepted (!)
it's the fact that the mail gets accepted - without even being
checked against the cyrus mailbox, and THEN it gets attempted
to be delivered by LMTP, that bothers me. is that... just...
too much to ask?
the key here is that if you attempt to send MAIL FROM: <some real
address@some real domain> RCPT TO:
lllllllllllllltotallyfakeaddress@localhost **THEN*** everything
works as expected.
now, whilst i don't pretend to fully understand the entire
way that exim works, nor pretend to know my way around configuring
it, but that just strikes me as... baroque.
here's a key question: _how_ do i specify an 'empty user' in the
configuration files, such that i can _stop_ mail coming
from a 'blank' user' like this?
and what the hell is exactly going on inside exim4, and its
configuration files, that causes all of the checks that i can
possibly think of adding, so far, to be completely bypassed and
irrelevant?
i'm going to try some further checks, e.g sending to some of my
'virtual' domains amongst other things, and i'll let you know
the outcome.
irrespective of _whoever_ is "responsible" for particular
configurations, this issue _needs_ to be got to the bottom of,
by the best experts around, and that means people like you, graeme,
are easily the best candidates for that.
if, in your opinion, the people who do cyrus _are_ the best
candidates, then yes, i will pursue it with them.
but, being absolutely honest, the cyrus team are _cyrus_ experts,
not exim4 config experts.
and this issue smells veeerrry slightly, to me, like a bug or
limitation in exim4 itself, with a limitation in the config file
format (of not being able to specify empty users, for sure).
unless that _is_ possible, of course, and i just haven't found it,
in which case, it's a bug in the exim4 documentation (nothing
to do with cyrus or debian).
so whilst there is overlap between the areas of expertise, please
help by advising me and helping me to solve this example config
that _happens_ to come from a slightly-modified-debian default
install and _happens_ to involve cyrus, but is _actually_ to do
with correctly configuring exim4.
and the reason _why_ you (plural - that is, the exim4 developers)
should consider helping me is not because i will be the only person
to benefit but because i am the only person who has the expertise
and willingness to track it down, and also because _every_
debian/exim4/cyrus2 administrator will benefit from the problem
being fixed and resolved.
i shouldn't _really_ have to point this out. but given that the
issue hasn't been fully researched to confirm that it's not a bug
in exim4, and you are already trying to refer me to the cyrus
team who aren't experts in exim4 configuration, i _do_ have to point
it out.
sorry about that.
anyway.
regarding the hack-suggestion, to use a flat file, it is a good
starting point as a temporary hack.
it's possible to obtain a list of mailboxes using cyrdadm
'listmailboxes' command.
i believe that it requires cyrus administrative privileges to perform
the cyradm listmailboxes command, but there might be another way to
do it (read-only access or something, i dunno).
the key issue for me isn't so much that the destination user mailbox
doesn't exist: the key is, i believe, that the mailbox user doesn't
even get _checked_ when some idiot tries to send mail from a blank
recipient (part of the issue is that i don't really understand why
that's happening).
_and_ the mail gets accepted into the queue - and that's the worst
bit about it. it definitely shouldn't be accepted, and i can't find
out how to stop it.
now, that might be easy to fix with the right configuration changes -
but i haven't found out how.
and that's what i believe that i specifically need your help with.
_how_ do i do 'blank user, containing no characters whatsoever,
please bugger off' in exim configspeak?
i can do _any number_ of 'usernamedthis@domain' go away in exim
configspeak.
blank user? not a hope in hell.
l.
> On 01/02/2007 02:12, Luke Kenneth Casson Leighton wrote:
> > many things that i should say before describing the issue i've
> > discovered: not least is that i am not subscribed to this list so
> > please cc me on any correspondance (without worrying about me getting it
> > twice cos i won't ha ha)
>
> I was tempted to just reply to the list, but then you wouldn't get the
> reply (ha ha). That's really not a good way to introduce yourself to a
> mailing list, is it?
>
> Anyway:
>
> > secondly is that whilst this deals with the configuration that is
> > supplied by debian, what i don't wanna hear is replies along the lines
> > of 'well that's a debian config, so get lost and go talk to the debian
> > people who created that config'. the reason is because i do not believe
> > this to be _specific_ to the debian config setup, but to be with the
> > local_user section _itself_.
>
> Incorrect. It's entirely down to the advice supplied by the Debian Cyrus
> packages when interfacing with the Debian Exim4 package. Neither (I
> expect, not being a Debian expert but having some small knowledge of the
> Exim4 package) are likely to be "vanilla" systems and both will (as
> Exim4 does) have their own Debian-isms.
>
> I'd love to tell you to get lost, but as one of the list admins that
> would be rude. So I'll just say that this really, *really* isn't a
> problem with the source-supplied Exim configuration. This *is* a Debian
> specific issue when using Exim4 with Cyrus. I'll point out a little more
> below.
>
> > additionally, i'd like people here to dream up a solution, which i can
> > _then_ go to the debian maintainers and say 'oh lookee here, there's
> > a bug report, and a solution, and the solution wasn't created by me,
> > so damn well go fix it' (or something a bit more polite but with the
> > same general intent, anyway).
>
> You need to go to the Cyrus maintainers, ideally. Or add in a method in
> that router which is capable of checking the user, as described below.
>
> > now, the really really _really_ bad thing is that this is a default
> > exim4 config issue (for the past three years) and the removal of
> > check_local_user is advice listed in the cyrus21 and cyrus22 Debian
> > Exim HOWTOs. so it's kinda important that it gets fixed.
>
> None of which relate to Exim in its' default, source-supplied state.
> This config:
>
> > the issue is caused by removing check_local_user from this:
> >
> > ### router/900_exim4-config_local_user
> > #################################
> >
> > # This router matches local user mailboxes. If the router fails,
> > # the error message is "Unknown user".
> >
> > local_user:
> > debug_print = "R: local_user for $local_part@$domain"
> > driver = accept
> > domains = +local_domains
> > #check_local_user
> > local_parts = ! root
> > transport = LOCAL_DELIVERY
> > cannot_route_message = Unknown user
>
> router/900_exim4-config_local_user is from the Debian split
> configuration. The default, source-supplied config contains a completely
> different local_user router which *does* include the check_local_user
> option.
>
> Removing that option makes the router accept any recipient except root
> in any domain the local_domains list.
>
> What you need is to replace check_local_user with a relevant local_parts
> expansion instead, or a condition (exercise for anyone who's remotely
> interested). If you had a file with all the Cyrus users in it, you could
> have the following in your local_user router:
>
> local_parts = lsearch;/etc/cyrus/listofusers
>
> Hopefully that's enough for you to be getting on with. You'll find lots
> of other information by linking from http://www.exim.org/ or with the
> README.debian file that came with your various packages.
>
> Now do we tell you to get lost? ;-)
>
> Graeme
>
