From owner-freebsd-questi...@freebsd.org Thu Apr 12 15:09:43 2012
Date: Thu, 12 Apr 2012 13:01:10 -0700
From: Ron <rg.li...@rzweb.com>
To: <freebsd-questions@freebsd.org>
Subject: Postfix + Courier IMAP local email problems
I'm having a couple of issues with postfix and courier-imap on my
new
machine and I'm trying to figure out what is different from my old
machine. I've checked every config file I think of and they both
seem
to be set up the same.
Here are the two issues:
If I send email from a local user (while SSH'd in using the command
line mail) to another local user (mail t...@mysite.com) on the same
machine, but using the full email address, I get the following error
and
the email bounced back:
553 5.3.5 mail.mysite.com. config error: mail loops back to me (MX
problem?)
554 5.3.5 Local configuration error
this is a 'well known' problem.
The only thing I can think of is that mysite.com and mail.mysite.com
(the mx record) do not point to the same server (which they did on
my
old machine).
it's not that sample. <grin>
I have also tried everything I can think of in how
users
are listed in postfix's virtual file and in /etc/aliases and server
entries in main.cf.
The problem is that the 'local' machine DOES NOT KNOW that it is
supposed
to accept mail for the domain specified in the email addressz.
The server looks at the address, determines that it is *NOT* local,
by whatever means 'postfix' uses to make that determination (it's the
'w' class in Sendmail), and goes off to query DNS for the MX for the
'remote' machine to send mail to. DNS returns "this" (the one asking
for
the 'remote' machine name) machine as the destination to deliver to.
the local server =knows= that is incorrect, because it is not the
delivery
point for that domain. hence the error message, and 'return to
sender'
as undeliverable.
This _is_ a configuration error in (probably) the local mailserver,
or in
the way the local hostname/domainname are set up..
The second issue is if (again, SSH'd in an using mail) I send email
to
a local user without the @mysite.com (mail todd) then the email
isn't
available via IMAP externally. I can read it using the command line
mail, but not externally via IMAP. These two mailboxs are
completely
separate and have two different lists of waiting email.
This is an 'inconsistency' in the way 'locally' generated mail is
being
handled, and the way externally generated mail is being handled.
*PROBABLY* because -one- mail server program is being started at boot
time, and a _different_ program is being invoked when somebody sends
locally from the command-line.
Chasing this down can be a b*tch. "Everything and it's cousins" has
the
executable name 'sendmail' hard-coded into it for sending outgoing
mail.
Sometimes the original 'sendmail' is replaced by a different
executable
'of the same name', that is really 'postfix', 'exim', 'qmail', or the
dreaded 'something else'. Sometimes 'sendmail' is a "switching"
program
that determings -- by some arbitrary means (typically a configurtion
file,
stored 'somewhere')-- _which_ of many alternatives to call.
Now _if_ the mailer started at boot time is *explicitly* named as
something
_other_ than "sendmail", and is -not- what you get when you invoke
the name
'sendmail', you have "obvious" potential for dissimilar behavior.
this
is _probably_ what is going on in your case. "Local" command-line
mail
is being delivered to an 'mbox' type mailbox, while 'remote' mail is
being delivered to 'something different' -- I think recent versios of
IMAP use a database-type struture rather than a simple 'mbox'.
Everything works fine if I send email from a remote client
(Thunderbird, Mail.app) and read the email with a remote client via
IMAP. It's just the local email sending that seems to be broken.
I'd
like to get one of these two problems fixed so root can email me
daily
log files, which it can't do right now or I can't read via IMAP
because
they are't going to the right mailbox.
Is there some simple I'm just messing up?
"Yes." <grin>
The difficulty comes in identifying _which_ "simple thing" it is that
is
messed up.
