[Top] [All Lists]

RE: Separate incoming mail into 4 categories - log file??

2007-01-07 20:15:56

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 and 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 (NS1) is to be
phased out and a much more powerful dual-processor (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.

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
you're getting in the pipeline assignment, and it should be clear that
is rather likely.  Stuff works when you're shelled in and invoking
from your shell, but when the mail comes in on SOME OTHER BOX (or
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,

LOG="Shell is ${SHELL}

(yes, with the newline before the closing quote).

This will tell you what shell is running on whatever machine is
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
shell at all - meaning they can't log in.        A    A        MX      30        (
                 MX      10       (

A given system can have more than one IP, but all outward indications
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 ESMTP Sendmail 8.12.10/8.12.10; Mon, 8 Jan 2007

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
both hosts claim), the timestamps should have been 01:30 and change -
first host is 30 minutes advanced, and the second is 50 minutes

Correct time is important, and it's easy to maintain - see "ntp".  It
when you have to correlate events (think SECURITY) on two hosts that
share the same time, and neither of which correleate to REAL time

As your "expert" hosting people if they run NTP.  Also, why the second
there doesn't have a valid hostname.

  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer:
  Please DO NOT carbon me on list replies.  I'll get my copy from the

procmail mailing list   Procmail homepage:

procmail mailing list   Procmail homepage:

<Prev in Thread] Current Thread [Next in Thread>