[comp.sys.apollo] Sendmail Problem

dennis@PEANUTS.NOSC.MIL (Dennis Cottel) (08/17/88)

I'm looking for experience with sendmail running on the Apollos.  I have
talked to Apollo.  After checking for the correct links, permission, etc,
they say they have never seen this behavior.  How about any of you?

We are running SR9.7, TCP3.1beta.  Sendmail is running on a DSP80A
gateway connected to several VAXes running 4.3 BSD.  The network and
the TCP servers seem to be rock solid at this point.

Sendmail is configured to put all mail into the queue, with a separate
daemon process running the queue every 5 minutes.  This was to get
around an apparent bug where incoming (to the Apollo) mail would
sometimes get silently dropped.  Users use /usr/ucb/Mail.

Every so often, maybe a couple times a week, sendmail will not be able
to deliver a message.  If it is able to return an error message, it will
say "554 \dennis... unknown mailer error 1" with the accompanying
message
	mail: cannot append to /usr/spool/mail/dennis
	mail: can't send to dennis
or maybe just "554 \dennis... unknown mailer error 2".

On some of these occasions, the error seemed to occur at about the time
a user was getting out of mail, or using the command "file %" to update
the mail file.  At other times, this wasn't the case.

The only other unusual thing I can think of is that users have a
.forward file in their home directory that both delivers the mail, and
pipes it through a program which uses send_alarm to put up a notice
containing the message's Subject: and From: lines.  My .forward file
looks like:
	\dennis
	"|/user/local/com/mail_alarm dennis"
but note that the errors are (seem to be) associated with the \dennis
part and not the mail_alarm part.

So how come I'm the only one in the world with this problem?!

   Dennis Cottel  Naval Ocean Systems Center, San Diego, CA  92152
   (619) 553-1645     dennis@NOSC.MIL       sdcsvax!noscvax!dennis

rees@MAILGW.CC.UMICH.EDU (Jim Rees) (08/17/88)

    Every so often, maybe a couple times a week, sendmail will not be able
    to deliver a message.  If it is able to return an error message, it will
    say "554 \dennis... unknown mailer error 1" with the accompanying
    message
          mail: cannot append to /usr/spool/mail/dennis
          mail: can't send to dennis
    or maybe just "554 \dennis... unknown mailer error 2".
     
    On some of these occasions, the error seemed to occur at about the time
    a user was getting out of mail, or using the command "file %" to update
    the mail file.  At other times, this wasn't the case.

Just a guess, but if your local user agent (ucb mail) has /usr/spool/mail/dennis
locked for reading, then a delivery agent (/bin/mail) on another node tries
to open the spool file for writing, it won't be able to acquire a write lock
and it may give up.  What it should do is retry in a few seconds, but I
don't know if the domain/ix /bin/mail does this or not.
-------

geof@imagen.UUCP (Geoffrey Cooper) (08/18/88)

In article <8808162127.AA08397@cod.nosc.mil>, dennis@PEANUTS.NOSC.MIL (Dennis Cottel) writes:
> We are running SR9.7, TCP3.1beta.  Sendmail is running on a DSP80A
Us too.

> say "554 \dennis... unknown mailer error 1" with the accompanying
> message
> 	mail: cannot append to /usr/spool/mail/dennis
> 	mail: can't send to dennis
> or maybe just "554 \dennis... unknown mailer error 2".

We've seen this too.  I believe it is indicative of /bin/mail (which is
invoked by sendmail) hitting a locked file.  This is an unknown error
since a Unix program should never hit a locked file, since Unix doesn't
have file locking.

Sometimes the problem is that someone just happens to be reading their
mail just as the sendmail is happening.  This is understandably rare.
Sometimes the problem is some other program (e.g., a mail reader
program) that keeps the mail file open or opens it periodically to
check for mail).

I believe that if a system crashes (or the boot button is pressed!)
while the mail file is open, the mail system can decide that the file
is locked when the locker doesn't believe it is.  Then the mail file
stays locked until....?  I fix that by crp'ing onto the supposed locker
node (obtained using llkob) and running "ulkob -f".

- Geof-- 
UUCP: {decwrl,sun}!imagen!geof ARPA: imagen!geof@decwrl.dec.com

paul@DELRIO.CC.UMICH.EDU ('da Kingfish) (08/20/88)

unknown mailer error #N problems are when /bin/mail can't open
/usr/spool/mail/luser.  N is the # of mailboxes it couldn't open.

The smtp error 550/no such user is when /etc/passwd and/or
/usr/lib/aliases are not available to sendmail when it is running
sendmail -bd and doing smtp or delivering from the queue.

I am just finishing a set of mail related changes for Apollos.

They include:

/bin/mail only tries one person per invocation.  if it fails, it exits
with EX_TEMPFAIL.  Even "local" delivery can be a remote delivery with
a distributed file system.  /bin/mail is now "never fails" instead of
"always works".

mh's inc, /bin/mail, and /usr/ucb/Mail all use the same locking style.
Any other program that modifies /usr/spool/mail/box uses the same style
by using ios_$ versions of open, fopen, and flock that I wrote.  (By
saying -lopen at compile time.)  Error texts are more explanatory.

They are "well-behaved".

sendmail will 451 instead of 550 when aliases/passwd are not
available.  It uses "new" dbm instead of dbm and the new dbm uses the
locking routines described above, so it doesn't matter where the
process is running relative to where the alias/passwd files are.  You
can run sendmail -bi (newaliases) from any node.

mailq prints out the apollo error text as well as the perror text for
failed messages still in the queue.  /bin/mail failures are logged so
you can stcode the result.  uids are used for message ids.

syslog uses no AF_UNIX at all, for various reasons, and I use the 4.3
style syslog routines.

These compile and run under 9.7 and 10.  For SR10, I delete the
distributed /usr/new and put in my own.

Many of these changes are generally useful, and not just for Apollos.

After a month of testing with real people's mail in September (I run
these changes on a small ring with only staff usage now) I'll do my
best to make all this available, via whatever means seem practicable
and doable.  I've been running this code for a while, and am polishing
it up, checking #ifdefs and Makefiles now, etc. to make it releasable.

The base versions for this are bind 4.8, sendmail 5.59, mh 6.5, and the
4.3 bsd vax release.

I have been collaborating with Mark Giuffrida from the engineering
college here, where several 100 Apollos are running.  Kind folks from
Apollo have given me the right pieces of information and helped track
down problems.

We've started on an NCS-based version of a lot of this too.

Take it from me:  file systems bad; objects, managers, and servers
good.

--paul

zjls13@cad10.trc.amoco.com (Sills) (09/28/90)

Class define:
   CD trc.amoco.com hou.amoco.com nap.amoco.com

Rewriting rule in S0:
   R$*<@$=D>$*               $#ether $@$2 $:$1<@$2>$3

Address:
   user@nap.amoco.com
                      
Problem:
   The address fails rule on the Apollo but hits on the Sun.

Timestamp of sendmail:
   Ver Name              Time Stamp                     File Name
   --------------------------------------------------------------
   c 1 version           1989/09/28  9:15:56 CDT (Thu)  /bsd4.3/usr/lib/sendmail

Is there is bug in sendmail (or a patch I don't know about).


Thanks for the help!!!


Jim Sills
   jsills@trc.amoco.com    918-660-3158

paul@CAEN.ENGIN.UMICH.EDU (paul killey) (10/09/90)

	Class define:
	   CD trc.amoco.com hou.amoco.com nap.amoco.com

	Rewriting rule in S0:
	   R$*<@$=D>$*               $#ether $@$2 $:$1<@$2>$3

	Address:
	   user@nap.amoco.com
	                      
	Problem:
	   The address fails rule on the Apollo but hits on the Sun.

	Timestamp of sendmail:
	   Ver Name              Time Stamp                     File Name
	   --------------------------------------------------------------
	   c 1 version           1989/09/28  9:15:56 CDT (Thu) 
/bsd4.3/usr/lib/sendmail

	Is there is bug in sendmail (or a patch I don't know about).


	Thanks for the help!!!


	Jim Sills
	   jsills@trc.amoco.com    918-660-3158


Sun probably has some of the "IDA sendmail enhancements".  Without them
(i.e., your case) sendmail is only trying to match one token, and you
have more than one ("nap", ".", "amoco", ".", and "com").

IDA will match on these multi-token classes.  In your case, it would
match nap, then nap., then nap.amoco, then nap.amoco., etc.

You could instead do something like this:

CD trc hou nap

and

R$*<@$=Z.amoco.com>$*           $#ether $@$2.amoco.com $:$1<@$2.amoco.com>$3

or whatever.

To sum up, this is an instance of comparing IDA sendmail with the stock
version.

out117w@monu6.cc.monash.edu.au (y ng) (12/05/90)

Incorrect FROM address are generated by  sendmail when mailing to host not in the same sub-domain as
shown in the following transcript. The correct FROM address should be yman@fees.vut.edu.au.
We still can send and receive mail. The only problem is that
the recipent of our mail can not use the reply command. 

$ mail -v out117w@monu6.cc.monash.edu.au
.......
out117w@monu6.cc.monash.edu.au... Connecting to monu6.cc.monash.edu.au (tcpld)...
monu6.cc.monash.edu.au Sendmail 5.61/1.34 ready at Wed, 5 Dec 90 12:47:53 +1100
>>> HELO fees.vut.edu.au
monu6.cc.monash.edu.au Hello fees.vut.edu.au ([140.159.1.161]), pleased to meet you
>>> MAIL From:<yman@fees>
<yman@fees>... Sender ok
>>> RCPT To:<out117w@monu6.cc.monash.edu.au>
....

The recipent sees the following

Message  1:
From yman@fees Wed Dec  5 12:48:01 1990
Received: from [140.159.1.161] by monu6.cc.monash.edu.au (5.61/1.34)
        id AA22153; Wed, 5 Dec 90 12:47:54 +1100
Received: by fees.vut.edu.au (5.65+/1.34)
        id AA00628; Wed, 5 Dec 90 11:50:23 +1000
Date: Wed, 5 Dec 90 11:50:23 +1000
From: yman@fees (yauman NG)
Message-Id: <9012050150.AA00628@fees.vut.edu.au>
To: out117w@monu6.cc.monash.edu.au
.....

Any hint and fix to this problem will be gratefully accepted. Many thanks

P.S. We are running SR10.2 with BSD4.3 as the default environment. Sendmail version 5.65+/1.34 and 
named.

Yau Man NG		
Dept of Elect Eng,  FIT
Victoria University of Technology  
Melbourne,  Australia

yman@fees.vut.edu.au

bergum@CIM-TUNE.HONEYWELL.COM (Dave Bergum) (12/07/90)

You will have to change your /usr/lib/sendmail.cf to include a
rewriting rule that adds your domain to your sender address.  One place
you can do this is in the sender rule for the smtp mailer.  Sendmail.cf
is a hairy thing and much more than can be described in a short
message.  I can show you what I have as an example and you can look at
yours and see if you can see a similar thing to modify.  In mine, smtp
mail invokation is specified by the rule:

Msmtp,  P=[IPC], F=LmsDFMPuX, S=11, R=21, A=IPC $h, E=\r\n

You might se a rule like Mtcp or something like that.  The S=11, part
of the specification says that rule 11 is used to rewrite the sender
address.  I have a rule that looks like:

S11
# Convert sender field (From) to acceptable user@host syntax.  No
# explicit routing allowed.

R$*<@$+>                $@$1<@$2>                       If host specif, OK
R$*<$*>$*               $1$2$3                          defocus
R$*:$*@$*               $2@$3                           and strip route ifany
R$+@$+                  $@$1<@$2>
##R$+<@$=A>             $@$1<@$E.$F>
R$+                     $@$1<@$P.$E.$F>                 tack on our hostname

The last rule rewrites my address by adding my localhost and domain as
the sedning host.  The macros are defined as follows: P - primary
hostname, E - level two domain name, F - root domain name.  With my
sendmail all addresses are reformated for processing so the the host is
in "<>" and the final rewriting rule removes the "<>" focus.  Your
sendmail may be different.  But generally, what you need to do is add a
rule in one of the sender rewriting rules to fully qualify your host
name.  You might see something like:

  R$+			$1@$w

In many cases $w is your simple host or node name.  If you just
redefine w to your domain name, that will fix the problem.  At the top
of your sendmail put:

  Dwhost.domain.name

If you can't figure it out, I can send you my sendmail.cf or you can
mail me yours and I'll take a look at it.

      A
-----/|\---------------------------------------+
-   / | \   Bergum@CIM-VAX.Honeywell.COM       |
-  /__|__\  Dave Bergum [MN26-3190]            |
- j---'---/  2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~  (612)870-5839                     |
-----------------------------------------------+

wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (12/07/90)

In article <9012062003.AA03840@tune.honeywell.com> bergum@CIM-TUNE.HONEYWELL.COM (Dave Bergum) writes:
>
>If you can't figure it out, I can send you my sendmail.cf or you can
>mail me yours and I'll take a look at it.

We've got a fairly simple sendmail.cf (Somebody else made it) It is documented
and requires only the insertion of some trivial information.
Things like organisation for the domain, hostnames which are considered equal
etc.

I've put it in our anon-ftp in /pub/apollo/sendmail.cf.Z 
( address: ftp.eb.ele.tue.nl [131.155.40.1] )

Maybe it's of use, 	Willem Jan

Eindhoven University of Technology   DomainName:  wjw@eb.ele.tue.nl    
Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET
P.O. 513                             Tel: +31-40-473401
5600 MB Eindhoven                    The Netherlands