Hi,
Much appreciate your effort. I add the line as suggested and the return
value is /sbin/nologin.
This is the same as the shell for user 'mail' so I changed the passwd
file to use /bin/bash and also to /usr/sbin/smrsh, kill all the sendmail
processors and restart the sendmail, it still return the same result. So
it does not like procmail pick up the shell from passwd file?
I check the sendmail.cf and submit.cf file, it is hard to understand
what all these varables do but I can not locate the string nologin in
these files. The closest thing is /usr/sbin/smrsh.
My organization is ITNC.COM, a HK company who has a closely related
company PENIT.COM in China; two companies share a server hosted in China
Telecom. I understand that the old server 211.154.135.158 (NS1) is to be
phased out and a much more powerful dual-processor 211.154.135.160 (NS3)
will do the three services we need.
I asked the administrator about the time and he think it is one-hour
difference (NS3) due to the summer time or soemthing close to it. We use
the date command to put it right for now and will try to find an
automated way. Apprecite your pointing out the carelessness of the
system administration.
How do I check whether we have NFS installed? The PS command does not
show anything so I assumed that we do not have a NFS installed.
I re-test the little shell script I wrote with the inclusion of /bin/sh
to test the sed and the assigning variable. It does not make any
difference. So the question of why assign to a variable behaves differen
tly from writing to a file remains a puzzel. It looks like the TR
command put the \n that behave differently when it is assign to a
varialbe to write to a file/screen.
Rgds,
Kwang-Fuh Lee.
At 00:44 2007-01-08 +0800, DR. Lee - NS3 wrote:
That sound worrying - a bogus shell?
No, a shell setting on a host that basically displays a message such as
"this account not permitted to log in" and terminates. Look at the
message
you're getting in the pipeline assignment, and it should be clear that
is
is rather likely. Stuff works when you're shelled in and invoking
procmail
from your shell, but when the mail comes in on SOME OTHER BOX (or
perhaps
even a virtualized server on the same system), the password file there
contains stub users - info for home dirs and the like, but no useable
shells, because those users aren't intended to log in on that system.
I have done what you suggested by putting the SHELL=/bin/sh command and
it seems work nicely.
Now, move the SHELL=/bin/sh below your LOGFILE line, and between them,
add:
LOG="Shell is ${SHELL}
"
(yes, with the newline before the closing quote).
This will tell you what shell is running on whatever machine is
_actually_
handling your email.
The question is what exactly this 'bogus shell" - a virus or what? Our
server is installed by a company which supposed to be "expert". It only
does web service, dns and e-mail and we do not have NFS.
Do you know what NFS is?
"The host actually handling mail doesn't have a legitimate login shell
for you to use." The server is for our use only and we have the full
control; therefore it is hard for me to think why unless this is also
related to the issue of the bogus shell?
By "you" I mean "you, the user who procmail is running on behalf of at
delivery time", not "you, the company which rents the entire system"
One user might have csh, and another bourne, yet another may have no
valid
shell at all - meaning they can't log in.
itnc.com A 211.154.135.158
www.itnc.com A 211.154.135.160
itnc.com MX 30 mail.itnc.com (211.154.135.158)
MX 10 mail3.itnc.com (211.154.135.160)
A given system can have more than one IP, but all outward indications
here
are that your domain has at least two servers associated with it.
Connecting to SMTP service on each of the two IP addresses results in
different greetings:
220 ns1.penit.com ESMTP Sendmail 8.12.10/8.12.10; Mon, 8 Jan 2007
02:01:01
+0800
220 localhost.localdomain ESMTP Sendmail 8.13.1/8.13.1; Mon, 8 Jan 2007
00:40:26 +0800
They're not even running the same version of the MTA, AND their time
settings are BOTH way the fsck off - I connected at 1730 GMT. at +8
(which
both hosts claim), the timestamps should have been 01:30 and change -
the
first host is 30 minutes advanced, and the second is 50 minutes
retarded.
Correct time is important, and it's easy to maintain - see "ntp". It
sucks
when you have to correlate events (think SECURITY) on two hosts that
don't
share the same time, and neither of which correleate to REAL time
either...
As your "expert" hosting people if they run NTP. Also, why the second
host
there doesn't have a valid hostname.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer:
<http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the
list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail