Lindsay Haisley writes:

On Mon, 2007-09-10 at 20:18 -0500, Lindsay Haisley wrote:
On Sat, 2007-09-08 at 17:38 -0400, Sam Varshavchik wrote:
> Your logs showed that courierlocal received and delivered the message:
> > Sep 8 12:02:19 shakti courierlocal: > id=000000000014255A.0000000046E2D55D.000076C7,from=<[EMAIL PROTECTED]> > ,addr=<@fmp.com>,size=703,success: Message delivered. > > This is irrefutable. > > Sep 8 12:02:19 shakti courierd: > started,id=000000000014255A.0000000046E2D55D.000076C7,from=<[EMAIL PROTECTED] > tus.org>,module=local,[EMAIL PROTECTED]/home/vmail/domains/fmp.com/al > ias!!,addr=<[EMAIL PROTECTED]> > > This is courierd telling courierlocal to deliver this message to > /home/vmail/domains/fmp.com/alias > > You have a .courier-default file in there. Prepend something before the > final delivery instruction in there, something like: > > | cat >/tmp/lastmessage.txt

Done, and we find that this delivery instruction is ignored altogether
when sending an email to "@fmp.com".  There is no /tmp/lastmessage.txt
file!  I tried appending "2>&1" and still nothing.  Sending a message to
a properly formed, non-existent mailbox, however, invokes this, as
expected and as it should, and the contents of said msg end up
in /tmp/lastmessage.txt.

There was no .courier-default file for the alias account, but several
other .courier-* files (household and business group addresses) so I
created one and moved the other redirects elsewhere, all
except .courier-default, and the result was the same.  Nada!

Just for the record, here's the section of the mail log associated with
this latest test:

Sep 10 20:08:21 shakti courierd: 
newmsg,id=0000000000142409.0000000046E5EA7C.000042BE: dns; bubba.cactus.org 
(bubba.cactus.org [::ffff:192.207.27.54])
Sep 10 20:08:21 shakti courierd: 
started,id=0000000000142409.0000000046E5EA7C.000042BE,from=<[EMAIL 
PROTECTED]>,module=local,[EMAIL 
PROTECTED]/home/vmail/domains/fmp.com/alias!!,addr=<[EMAIL PROTECTED]>
Sep 10 20:08:21 shakti courierd: Waiting.  shutdown time=none, wakeup time=Mon 
Sep 10 20:08:29 2007, queuedelivering=232, inprogress=7
Sep 10 20:08:21 shakti courierlocal: 
id=0000000000142409.0000000046E5EA7C.000042BE,from=<[EMAIL 
PROTECTED]>,addr=<@fmp.com>,size=696,success: Message delivered.
Sep 10 20:08:22 shakti courierd: 
completed,id=0000000000142409.0000000046E5EA7C.000042BE

I'm stumped. Can't really figure out what's going on just by looking at this from the outside.

The only suggestion I have is the brute force approach.

1) Make sure to do this when things are otherwise quiet, and nothing else is going on. For the duration of the test you can temporary stop incoming mail delivery with "esmtpd stop", then restart it afterwards with "esmtpd start". This won't take more than a minute or two, and won't have any measurable impact. Afterwords, a poke on port 25 will verify that incoming SMTP is back up and running.

2) Find courierlocal's pid, run "strace -o /tmp/strace.log -f -s 256 -p <PID>".

3) Send the problematic message. Even though you might have incoming SMTP turned off, "sendmail -bs" from the shell will let you do it the old-fashioned way.

4) Kill strace, then back to business at normal.

Hopefully, the contents of strace.log will help me figure what courierlocal is doing, before I skip town next week for some well-deserved R&R. Depending on the results, it may or may not be necessary to do this again with a larger -s option, but I hope not.

Attachment: pgppBuwJwhwuF.pgp
Description: PGP signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to