Sendmail seems lost some mails, pls help!
Kevin Yang
around 1,200 users within our company using the email system.
These days, I encounter a problem is that some users asking why they
did not receive important mails within our company. For example, A
send to B and cc to C and D, only when D or C reply to all then B
knows that he lost the original mail from A. I checked the email
addresses all are correct and the mail routing is ok, too.
One of the case that I checked the /var/adm/syslog/mail.log and found
the information as below:
Feb 19 10:36:40 ms sendmail[977]: KAA00971:
to=<f...@ms.usi.com.tw>,<cwan@m
s.usi.com.tw>,<cl...@ms.usi.com.tw>,<hy...@ms.usi.com.tw>,<ts...@ms.usi.com.t
w>, ctladdr=<pa...@ms.usi.com.tw> (630/104), delay=00:00:01,
xdelay=00:00:00,
mailer=local, stat=Sent
In this case, Paul send to Fa, Cwan, Clma and cc to Hyle, Tsie, the
result is only last two (Hylee, Ts_hsieh) receive the email.
Only occasionally will happen this kind of cases, when we test it
using the same condition, it always deliver emails successfully.
I wonder if there are some problems to write emails to the
/var/mail/users-mbox or is there any problem in my sendmail.cf file to
limit system process and result in drop some packets when the system
is pretty busy.
Any comments are welcomed.
TIA
Per Hedeland
kev...@ms.usi.com.tw (Kevin Yang) writes:
>One of the case that I checked the /var/adm/syslog/mail.log and found
>the information as below:
>Feb 19 10:36:40 ms sendmail[977]: KAA00971:
>to=<f...@ms.usi.com.tw>,<cwan@m
>s.usi.com.tw>,<cl...@ms.usi.com.tw>,<hy...@ms.usi.com.tw>,<ts...@ms.usi.com.t
>w>, ctladdr=<pa...@ms.usi.com.tw> (630/104), delay=00:00:01,
>xdelay=00:00:00,
> mailer=local, stat=Sent
That line shows that sendmail delivered the message to the local mailer
(the program specified in the Mlocal entry in sendmail.cf), which
accepted it without giving any errors, which means that things are out
of sendmail's hands.
>In this case, Paul send to Fa, Cwan, Clma and cc to Hyle, Tsie, the
>result is only last two (Hylee, Ts_hsieh) receive the email.
Per above you then need to investigate the program that you use for
local delivery, to find out why it didn't deliver to the other
recipients - it's not a sendmail problem. Though of course one
possibility is that your Mlocal entry doesn't match the requirements of
that program - but I can't see how that could produce the specific
result you describe.
--Per Hedeland
p...@bluetail.com
Kevin Yang
> In article <b0144051.02030...@posting.google.com>
> kev...@ms.usi.com.tw (Kevin Yang) writes:
> >One of the case that I checked the /var/adm/syslog/mail.log and found
> >the information as below:
> >Feb 19 10:36:40 ms sendmail[977]: KAA00971:
> >to=<f...@ms.usi.com.tw>,<cwan@m
> >s.usi.com.tw>,<cl...@ms.usi.com.tw>,<hy...@ms.usi.com.tw>,<ts...@ms.usi.com.t
> >w>, ctladdr=<pa...@ms.usi.com.tw> (630/104), delay=00:00:01,
> >xdelay=00:00:00,
> > mailer=local, stat=Sent
>
> That line shows that sendmail delivered the message to the local mailer
> (the program specified in the Mlocal entry in sendmail.cf), which
> accepted it without giving any errors, which means that things are out
> of sendmail's hands.
Our Mlocal entry is:
Mlocal, P=/usr/bin/rmail, F=lsDFMAw5:/|@qm9, S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=rmail -d $u
and we did not made any modification on it since the system built up.
>
> >In this case, Paul send to Fa, Cwan, Clma and cc to Hyle, Tsie, the
> >result is only last two (Hylee, Ts_hsieh) receive the email.
>
> Per above you then need to investigate the program that you use for
> local delivery, to find out why it didn't deliver to the other
> recipients - it's not a sendmail problem. Though of course one
> possibility is that your Mlocal entry doesn't match the requirements of
> that program - but I can't see how that could produce the specific
> result you describe.
In the last one month, all the cases(5 cases) that I met were the 'to'
recipients did not receive it, but 'cc' recipients did. It's strange that
the rest hundreds of thousands emails were delivered normally.
The users within my company all use Microsoft Outlook Express to retrieve
emails from this mail server.
Per Hedeland
kev...@ms.usi.com.tw (Kevin Yang) writes:
>p...@bluetail.com (Per Hedeland) wrote in message
>news:<a66052$12n8$2...@hedeland.org>...
>> In article <b0144051.02030...@posting.google.com>
>> kev...@ms.usi.com.tw (Kevin Yang) writes:
>> >One of the case that I checked the /var/adm/syslog/mail.log and found
>> >the information as below:
>> >Feb 19 10:36:40 ms sendmail[977]: KAA00971:
>> >to=<f...@ms.usi.com.tw>,<cwan@m
>> >s.usi.com.tw>,<cl...@ms.usi.com.tw>,<hy...@ms.usi.com.tw>,<ts...@ms.usi.com.t
>> >w>, ctladdr=<pa...@ms.usi.com.tw> (630/104), delay=00:00:01,
>> >xdelay=00:00:00,
>> > mailer=local, stat=Sent
>>
>> That line shows that sendmail delivered the message to the local mailer
>> (the program specified in the Mlocal entry in sendmail.cf), which
>> accepted it without giving any errors, which means that things are out
>> of sendmail's hands.
>
>Our Mlocal entry is:
>Mlocal, P=/usr/bin/rmail, F=lsDFMAw5:/|@qm9, S=10/30, R=20/40,
> T=DNS/RFC822/X-Unix,
> A=rmail -d $u
>and we did not made any modification on it since the system built up.
Nevertheless, that is where the problem must be - unless HP made some
strange modifications to sendmail and broke it in such a way that it
lies about what it did. You could try removing the 'm' from the F= field
- this will make sendmail invoke 'rmail' separately for each recipient,
rather than passing it all the recipients in one invocation. If you use
a .mc file to build sendmail.cf (which you should), you can do this by
using
define(`LOCAL_MAILER_FLAGS', `9')
(the default for HP-UX 10.x is `m9').
>In the last one month, all the cases(5 cases) that I met were the 'to'
>recipients did not receive it, but 'cc' recipients did. It's strange that
>the rest hundreds of thousands emails were delivered normally.
>The users within my company all use Microsoft Outlook Express to retrieve
>emails from this mail server.
To or Cc makes no difference to sendmail, delivery isn't based on
headers but on the envelope (RCPT To: in SMTP).
--Per Hedeland
p...@bluetail.com
Kevin Yang
> >
> >Our Mlocal entry is:
> >Mlocal, P=/usr/bin/rmail, F=lsDFMAw5:/|@qm9, S=10/30, R=20/40,
> > T=DNS/RFC822/X-Unix,
> > A=rmail -d $u
> >and we did not made any modification on it since the system built up.
>
> Nevertheless, that is where the problem must be - unless HP made some
> strange modifications to sendmail and broke it in such a way that it
> lies about what it did. You could try removing the 'm' from the F= field
> - this will make sendmail invoke 'rmail' separately for each recipient,
> rather than passing it all the recipients in one invocation. If you use
> a .mc file to build sendmail.cf (which you should), you can do this by
> using
>
> define(`LOCAL_MAILER_FLAGS', `9')
>
> (the default for HP-UX 10.x is `m9').
>
Thanks, I will try to remove the 'm' from F field, but I am confused about
'9'. It seems that '9' comes with 'm' in the HP-UX 10.x, but in the general
UNIX sendmail, the '9' flag is used for the purpose of 'convert into 8-bit'.
Should I remove 'm9' or just only 'm' in my sendmail.cf file ?
>
> --Per Hedeland
> p...@bluetail.com
Per Hedeland
kev...@ms.usi.com.tw (Kevin Yang) writes:
>p...@bluetail.com (Per Hedeland) wrote in message
>news:<a68qn5$27mp$3...@hedeland.org>...
>>
>>
>> (the default for HP-UX 10.x is `m9').
>
>Thanks, I will try to remove the 'm' from F field, but I am confused about
>'9'. It seems that '9' comes with 'm' in the HP-UX 10.x, but in the general
>UNIX sendmail, the '9' flag is used for the purpose of 'convert into 8-bit'.
Why the "but"? The '9' flag is set on the local mailer regardless of
OSTYPE (there might be some exceptions, but I don't think so) - gets rid
of that pesky quoted-unreadable encoding on text/plain mail at least. In
any case it's highly unlikely to have anything to do with the problem
you're seeing.
>Should I remove 'm9' or just only 'm' in my sendmail.cf file ?
Don't do anything in your .cf file, use the m4 directive above in your
.mc file instead (it will - obviously - remove 'm' but not '9').
--Per Hedeland
p...@bluetail.com