Emails being lost

[James Shamas]

Okay.. Lots of good suggestions from everyone.

>  Could this be due to a Sieve filter that you're not aware of?  Look 
> in your imap log for entries like this:

Nah, no sieve filter... I checked.

> You may want to verify what address you are replying to.  I've seen 
> replies get lost or sent to a different account due to users not 
> setting their identity up correctly (either in IMP or a mail client)

I checked, same email address for both...

> This is going to seem really basic, but check the logs closely. Are 
> the messages getting delivered from your machine to the server? Are 
> the messages making it through the AV software? Are the messages 
> getting into the spool? What sort of Message-ID is in the message?  Is

> it a duplicate so that the deliver duplicate suppression drops it?

I upped the log level in sendmail and have attached my logs.  Message #1
(A Reply) did not make it to the client.  Message #2 (An email I
initiated) did.  They look the same to me, except for the msgid on the
first one... In fact, that one does not look quite right to me.  Could
it be a clue?:

Apr 22 17:17:02 s1 sendmail[26666]: restarting /usr/sbin/sendmail due to
signal 
Apr 22 17:17:02 s1 sendmail[26695]: starting daemon (8.12.5):
SMTP+queueing at 00:30:00 
Apr 22 17:17:02 s1 sendmail[26695]: started as: /usr/sbin/sendmail -bd
-q30m
--- MESSAGE 1 ---
Apr 22 17:17:55 s1 sendmail[26707]: NOQUEUE: connect from
blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:01 s1 drweb-smf: [h3MLHtwe026707]: message from <js****
@optima-inc.us> is aborted 
Apr 22 17:18:01 s1 sendmail[26707]: h3MLHtwe026707:
to=<ks*****@***-inc.us>, delay=00:00:06, pri=0, stat=RSET 
Apr 22 17:18:01 s1 sendmail[26707]: h3MLHtwe026707: from=<js****
@optima-inc.us>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA,
relay=blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:06 s1 sendmail[26707]: h3MLHtwg026707: from=<js****
@optima-inc.us>, size=6890, class=0, nrcpts=1,
msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAOBUi7NvqcUS51/bloo
ti98KAAAAQAAAAuxGD5DzkJUqMzcohpms6, proto=ESMTP, daemon=MTA,
relay=blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:08 s1 drweb-smf: dwlib: scan: message sent by <js****
@optima-inc.us> is passed 
Apr 22 17:18:08 s1 drweb-smf: [h3MLHtwg026707]: processing message from
<js**** @optima-inc.us> completed (exit code 3) 
Apr 22 17:18:08 s1 sendmail[26711]: h3MLHtwg026707:
to=<ks*****@***-inc.us>, delay=00:00:02, xdelay=00:00:00, mailer=cyrus,
pri=30768, relay=localhost, dsn=2.0.0, stat=Sent 
Apr 22 17:18:08 s1 sendmail[26711]: h3MLHtwg026707: done;
delay=00:00:02, ntries=1
--- MESSAGE 2 ----
Apr 22 17:18:39 s1 sendmail[26714]: NOQUEUE: connect from
blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:44 s1 drweb-smf: [h3MLIdwe026714]: message from <js****
@optima-inc.us> is aborted 
Apr 22 17:18:44 s1 sendmail[26714]: h3MLIdwe026714:
to=<ks*****@***-inc.us>, delay=00:00:05, pri=0, stat=RSET 
Apr 22 17:18:44 s1 sendmail[26714]: h3MLIdwe026714: from=<js****
@optima-inc.us>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA,
relay=blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:48 s1 sendmail[26714]: h3MLIdwg026714: from=<js****
@optima-inc.us>, size=2463, class=0, nrcpts=1,
msgid=<000601c30914$c1876e20$8400a8c0 at OPTIMA.HQ>, proto=ESMTP,
daemon=MTA, relay=blackhole.optima-inc.us [12.111.39.146] 
Apr 22 17:18:49 s1 drweb-smf: dwlib: scan: message sent by <js****
@optima-inc.us> is passed 
Apr 22 17:18:49 s1 drweb-smf: [h3MLIdwg026714]: processing message from
<js**** @optima-inc.us> completed (exit code 3) 
Apr 22 17:18:49 s1 sendmail[26719]: h3MLIdwg026714:
to=<ks*****@***-inc.us>, delay=00:00:01, xdelay=00:00:00, mailer=cyrus,
pri=30542, relay=localhost, dsn=2.0.0, stat=Sent 
Apr 22 17:18:50 s1 sendmail[26719]: h3MLIdwg026714: done;
delay=00:00:02, ntries=1


Could that msid be causing the problem?  How is this generated?  Where
might the message be getting lost?

- James

> 
> If you have a message that you know is failing, you should be able to 
> trace it every step of the way to see what part is not properly 
> handling the message.
> 
> -_Gene
>