Re: [exim] Exim mail issue

On 2008-04-22 at 11:48 +0530, Piyush Sharma wrote:
> Below is the exim configuration file:-

You still don't provide the log lines showing the failed delivery, so we
don't have the diagnostic information to see what has gone wrong.

For instance, it should say what went wrong. It would also tell us how
the mail was received. For instance, if the mail is sent from the
webmail system via SMTP to the hostname, instead of to localhost, then
it would be rejected and we could see this in the logs. (If that is the
problem, you could fix it by changing relay_from_hosts to be:

----------------------------8< cut here >8------------------------------
hostlist relay_from_hosts = @[]
----------------------------8< cut here >8------------------------------
which will let you relay for all mail from the local machine, even if it
wasn't sent to localhost, or if IPv6 is enabled on your system (since
you've blocked that by requiring "127.0.0.1" instead of "localhost").

The logs would also hint to us if there is something weird about the
local_domains setting which you censored.

> qualify_domain = localhost

So if the sender is specified as "fred" and the recipient as
"exim-users@???", then you'll try sending mail from
<fred@localhost> to <exim-users@???> and the exim.org servers will
reject mail claiming to be from @localhost. Use a real value for
qualify_domain.

If you really want unspecified users to be handled locally, no matter
what domain is used, there's qualify_recipient.

> rfc1413_hosts = *
> rfc1413_query_timeout = 30s

What version of Exim are you running? I think the default for that
value dropped to 5s, which would give you fewer delays on incoming mail
from sites with common firewall misconfigurations.

> system_aliases:
> driver = redirect
> allow_fail
> allow_defer
> data = ${lookup{$local_part}lsearch{/etc/aliases}}
> user = harrypotter
> file_transport = address_file
> pipe_transport = address_pipe

You really want all processes run from pipe addresses in /etc/aliases to
be run as user "harrypotter"? And that user exists on your system?

> userforward:
> driver = redirect
> check_local_user

Since you are using virtual-hosting and not relying upon local users,
you probably want to remove this, unless it's intentional that if the
system has an account for "fred" then ~fred/.forward will be used for
handling mail for fred@ whatever domains you host.

> localuser:
> driver = accept
> # check_local_user
> # local_part_suffix = +* : -*
> # local_part_suffix_optional
> transport = local_delivery
> cannot_route_message = Unknown user

This is bad. This will lead, in the current configuration, to you
creating accounts for whatever email address someone sends to on your
system. A typo? New email folder!

If you fix the directory creation to not be automatic in the transport,
then this Router setting will lead to you accepting email and then
bouncing later. You accept email for all left-hand-sides in the local
domains, whether they exist or not! Then, when the transport fails,
you'll give up and generate a bounce. This will lead to you generating
back-scatter and being blacklisted by many sites.

The "check_local_user" was checking the validity of the left-hand-side.
Without it, you need something else to check the validity of the
left-hand-side.

You need to think about what defines a valid address, who or what is
responsible for creating the mail-folder and how to check this in Exim.
For instance, if something outside Exim should create the mail-folder,
then you can do:

require_files = /usr/local/mail/${domain}/${local_part}/Maildir/

on the Router, so only users who have a mail-folder will be valid and
you'll never accept mail to other users at your domains.

Alternatively, if Exim should create the directory automatically, what
_does_ define the valid users? A DB file, a list, something else? You
can look up the user in that on the Router, to verify it.

> local_delivery:
> driver = appendfile
> group = mail
> mode = 0666

Uhm, the Permissions of the Beast? Do you _really_ need permissions
that allow anyone who can get onto the system, as any user, to read or
write any email at all? Okay, so you have directory_mode on the parent
directories, but I'm suspecting that you've been creating directories
and setting the permissions to open them up.

You need to think carefully about what users need to exist, what groups
they should have, "mode", "directory_mode", "user", "group" and
"initgroups" on the transport.

> mode_fail_narrower = false
> envelope_to_add = true
> create_directory = true
> directory = /usr/local/mail/${domain}/${local_part}/Maildir/
> maildir_format

-Phil