Yeah... That IS a head-scratcher!
Here is an excerpt from a successful delivery on our server where the mail
message is found:
(adjusted for clarity =)
Jun 28 10:28:56 gg courieresmtpd: started
Jun 28 10:28:57 gg courierd: newmsg
id=001AC091.42C15EA9.000053ED,
dns; myisp.net (mail.somewhereelse.net
Jun 28 10:28:57 gg courierd: started
id=001AC091.42C15EA9.000053ED,
from=<[EMAIL PROTECTED]>,
module=local,
[EMAIL PROTECTED]/mailspool/localdomain.com/me!!,
addr=<[EMAIL PROTECTED]>
Jun 28 10:28:57 gg courierd: Waiting.
shutdown time=none,
wakeup time=Tue Jun 28 12:05:07 2005,
queuedelivering=3,
inprogress=1
Jun 28 10:28:57 gg courierlocal:
id=001AC091.42C15EA9.000053ED,
from=<[EMAIL PROTECTED]>,
addr=<[EMAIL PROTECTED]>,
size=1575,
success: Message delivered. <-THIS MEANS IT WAS DELIVERED!
Jun 28 10:28:57 gg courierd: completed,
id=001AC091.42C15EA9.000053ED
Jun 28 10:28:57 gg courierd: Waiting.
shutdown time=Tue Jun 28 10:33:57 2005,
wakeup time=Tue Jun 28 10:33:57 2005,
queuedelivering=2,
inprogress=0
So I see your problem. Because even though your log excerpt shows that it
was 'Message delivered', yet it is no where to be found... That is quite a
problem!
Cause "from=<[EMAIL PROTECTED]>,addr=<[EMAIL PROTECTED]>,
size=15767,success: Message delivered." in your logs show it was
delivered... SOMEWHERE... Hehe.
Do you have a .courier-default file in the "/home/earle" directory, that is
EMPTY, but the filesize is greater than 0 bytes? Courier has a sort of ...
"feature" that if you have an empty .courier-default file, but its larger
than 0 bytes, it will 'deliver' the mail, but into the bit bucket. Check
that file.
> On Jun 27, 2005, at 3:25 PM, Randall Shaw <[EMAIL PROTECTED]>
> wrote:
>> Greg Earle scribbled something like:
>>
>>> I got authdaemon started manually (will check for an init script now,
>>> thanks), but have a new problem - mail comes in, "submit" gets called,
>>> everything looks OK, "courieresmtpd" logs a message:
>>>
>>> Jun 27 13:34:01 isolar courieresmtpd: [ID 702911 mail.info] started,
>>> ip=[::ffff:24.130.129.94]
>>>
>>> An "250 Ok. 42C062BB.0001FC6" gets written to the "trigger" socket,
>>> and at some point "submit" writes a "QUIT" back to "courieresmtpd".
>>> But that's it - "courierd" never seems to be contacted (which always
>>> seems to be the next step after "courieresmtpd" gets the initial
>>> incoming connection), and the mail disappears into the bit bucket.
>>>
>>> Scratching my head over this one ...
>>
>> Hmmmm... By chance, when you upgraded, did you copy your old config
>> files in
>> over the new ones installed? Or did you do a patch from old version
>> to new
>> version, and go and adjust all your configurations in the new files?
>
> I install all the new files, then diff the old/new trees and when I see
> file
> differences, I merge the old changes into the new base files after
> looking
> at each change to see if it's applicable.
>
> In the case of files that didn't exist in the new version I generally
> just
> copy those in from the old version - I suppose this is where there's a
> chance to screw things up but I've done several Courier upgrades in the
> past and this is the first time I can recall that things have basically
> just fallen over ...
>
>> I had upgraded from .39 up to .50, and had to basically 'start over'
>> with
>> config, because copying them in would have caused quite a stir. The
>> 'big
>> change' of courier-authlib being split off into its own daemon, makes
>> the
>> config files a slight bit different in how they perceive user
>> accounts...
>> Which in turn determines if mail gets delivered, or mail can be
>> accessed, or
>> if users can send out mail via authenticated smtp.
>>
>> Your problem could lie anywhere in that mess =)
>
> Once I had the new authdaemon running (manually), I am able to log in
> with
> Apple's Mail.app, so at least user authentication for "imapd-ssl" logins
> is working.
>
>> The behavior I notice with the new Courier is:
>>
>> Mail comes in from the world, esmtpd fires up, looks up the user, if
>> they
>> exist, it files the message if they are not over quota. If they don't
>> exist,
>> it rejects the mail. Courierd is never in the mix when a mail comes in
>> for
>> delivery, nor does courierd get involved when a user sends email out.
>> As
>> esmtpd handles both of those.
>
> I based my comments on seeing "courierd" log messages shortly after the
> initial esmtpd connection log (lines folded for clarity):
>
> Jun 28 09:59:53 isolar courieresmtpd: [ID 702911 mail.info]
> started,ip=[::ffff:24.130.129.94]
> Jun 28 09:59:54 isolar courierd: [ID 702911 mail.info]
> newmsg,id=0002B832.42C18209.00002571: dns; isolar.DynDNS.ORG
> (c-24-130-129-94.hsd1.ca.comcast.net [::ffff:24.130.129.94])
> Jun 28 09:59:54 isolar courierd: [ID 702911 mail.info] Waiting.
> shutdown time=none, wakeup time=none, queuedelivering=1, inprogress=1
> Jun 28 09:59:54 isolar courierd: [ID 702911 mail.info]
> started,id=0002B832.42C18209.00002571,
> from=<[EMAIL PROTECTED]>,module=local,
> host=earle!!20!20!/home/earle!!,addr=<earle>
> Jun 28 09:59:54 isolar courierlocal: [ID 702911 mail.info]
> id=0002B832.42C18209.00002571,
> from=<[EMAIL PROTECTED]>,addr=<[EMAIL PROTECTED]>,
> size=15767,success: Message delivered.
>
> With Courier 0.50.0 in place, I see the initial "courieresmtpd" started
> message as shown above, but the following "courierd" mail.info newmsg
> message never shows up. And the mail message is not delivered, it just
> disappears. That's the head-scratcher at this point ...
>
> - Greg
-Randall Shaw
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
