procmail
[Top] [All Lists]

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

2007-01-07 20:15:56
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

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