markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) (05/16/89)
>We are a large Apollo site (about 700 nodes) running 9.7.1 >(soon to be 10.1) Domain/IX. We use primarily Unix Sys V >since we are now part of an ATT JV. ... >adding to the mailbox (all 700 nodes are linked to one /usr/mail dir). This is really not a good idea. Very few mail programs check to make sure that their 'write()'s succeed. If the network gets flakey, or something else goes wrong you could easily lose your entire mailbox. In addition you have the cost of 700 users beating on a single directory every few minutes checking to see if there is new mail. I must disagree with this statement. I am responsible for the mail environment here at the University of Michigan CAEN. We have 500 Apollos and they all link to one spool directory. We modified SENDMAIL extensively to work in a distributed enviornment. One of the changes is to accomodate Apollos file locking. If the mailbox cannot be opened for write, it simply leaves the message queued (it will not bounce) and tries again later. With syslog output going to the main node, you can watch the entire mail environment as it happens by "tail -f" that log file (we call it Mail-TV or MTV for short). A smart administrator can catch problems long in advance of them becoming a problem by watching the log output. To give another small example, the message-id incorportes the nodeid in it so that we can tell exactly which node generated the message. We now traffic about 1500 msgs/day (1/3 of them nonlocal) and have very few problems. Also, we find the cost of checking for new mail is not even noticeable. The sendmail Apollo ships is a straight port from BSD and it isn't specifically modified to handle the situations that arise in a distributed environment. Until X.400 takes over, vendors need to be concerned with current mailers like SENDMAIL and tune them to a network environment. Mark Giuffrida University of Michigan (CAEN) markg@caen.engin.umich.edu
krowitz@RICHTER.MIT.EDU (David Krowitz) (05/16/89)
Mark, Is it possible for other Apollo user's to get a copy of your modified sendmail? My network has only 20 nodes (running SR9.7 and SR10.1), but we occasionally get in a situation where so many nodes are trying to acess the /usr/spool/mqueue directory that the directory itself becomes locked up -- which then causes the sendmail daemons to go wild with repeated trys to access the directory. The poor node on which the directory resides may receive in excess of 700 network I/O's per second when this happens! -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
dennis@peanuts.nosc.mil (Dennis Cottel) (05/17/89)
In article <4341a7bf1.0017b5e@caen.engin.umich.edu> markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: > ... We modified SENDMAIL extensively to work in a distributed > environment. One of the changes is to accomodate Apollo's file > locking. If the mailbox cannot be opened for write, it simply leaves > the message queued (it will not bounce) and tries again later. ... > The sendmail Apollo ships is a straight port from BSD and it isn't > specifically modified to handle the situations that arise in a > distributed environment. Hooray! This locking problem has been a plague since we started using Berkeley Mail and sendmail seriously a year ago. We only handle 100-200 deliveries a day, but our users have to be trained to execute 'mailq' before executing or exiting Mail. Ugly! How can I get your modified version, Mark? Is it specific to SR9.x or SR10.x? --Dennis Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis
markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) (05/17/89)
Is it possible for other Apollo user's to get a copy of your modified sendmail? My network has only 20 nodes (running SR9.7 and SR10.1), but we occasionally get in a situation where so many nodes are trying to acess the /usr/spool/mqueue directory that the directory itself becomes locked up -- which then causes the sendmail daemons to go wild with repeated trys to access the directory. The poor node on which the directory resides may receive in excess of 700 network I/O's per second when this happens! Our mail shark Paul Killey is willing to put together a ftpable release of our sendmail in his spare time. Since he is doing it in his spare time, it may take a while to complete. One of us will announce it when it is available. Mark Giuffrida University of Michigan markg@caen.engin.umich.edu
dieter@oahu.cs.ucla.edu (Dieter Rothmeier) (06/02/89)
I am trying to get mail to work on our little 3 node
Apollo network. We are running Domain/IX 9.7 4.2 BSD.
At this point, no machine can send mail to any other
machine. When I try to send mail to user@othernode using the
verbose option, it displays
... Connecting to .ether..
user@othernode... Host unknown.
I am using /usr/ucb/mail.
Telnet,ftp and rlogin work fine between all the nodes.
Any help would be appreciated,
Dieter Rothmeierkrowitz@RICHTER.MIT.EDU (David Krowitz) (06/02/89)
The sendmail.cf file is, as you said, formidable.
There are very few people who can understand the cryptic
format of the file. Most of us (myself included) use
an existing file we borrowed from someone else and then
modified for our particular site.
1) make certain that the file /usr/lib/sendmail.fc (".fc", not
".cf") has been deleted. This is the "frozen" mail configuration
file. If it exists, the mailer will use it instead of the
/usr/lib/sendmail.cf file.
2) edit the /usr/lib/sendmail.cf file and put in your site specific
info at the top. I will send you a copy of my file in a seperate
message. I borrowed this file from someone else, who got it from
yet another person. The sendmail file I have looks in /etc/hosts
for the host name and tries to send the message directly. If it
can't find the hostname there, it relays the message to another
machine (which *must* be in /etc/hosts) who has a more complete
host table. The name of the forwarding machine is defined near
the top of the file. There is also a seperate definition for a
UUCP mail forwarding host, if you need one. The only problem I
have found with this sendmail.cf file is that it does not
recognize names of the form "host.subdomain.domain" even though
they are in the /etc/hosts file and it forwards the message to
the forwarding machine rather than sending it directly (eg. my
/etc/hosts files contains both "richter" and "richter.mit.edu",
but the sendmail.cf file I'm sending you will only recognize
"richter" as a machine that it can send mail to directly. It
will send mail for "richter.mit.edu" to the forwarding machine
-- which fortunately, will send the mail to the correct host).
I am looking for the fix to this problem. In the meantime, I
hope this file will work for you.
3) You can create a new "frozen" configuration file by using the
command /usr/lib/sendmail -bz to read the ".cf" file and create
a new ".fc" file. The mailer is supposed to run faster using
the ".fc" file, but you have to remember to re-freeze the
configuration file after every time you edit the ".cf" file.
-- David Krowitz
krowitz@richter.mit.edu (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)vskahan@lgnp1.LS.COM (Vince Skahan) (06/05/89)
In article <8906021616.AA02345@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >The sendmail.cf file is, as you said, formidable. >There are very few people who can understand the cryptic >format of the file. Most of us (myself included) use >an existing file we borrowed from someone else and then >modified for our particular site. > Same goes with us. I took a look at the (in my opinion quite weak) examples in arpaproto.cf and uucpproto.cf, put the two together and got something that was relatively stupid for both UUCP and TCP. sendmail.cf writing is a royal pain and is very, very tricky and is something you cannot just pick up and do in 15 minutes unless you're starting with a pretty close-to-the target version that you need to edit slightly. If you have an ultrix system, the sendmail.cf you get by default is REALLY good in comparison to any default ones I've ever seen. It's pretty close to plug-and-play. It has a real nice feature where you can define lots of gateways for UUCP, and especially (for me) decnet where all mail to a particular fake domain gets forwarded via TCP to the remote gateway host which sends it along. In other words, if you want to mail to a remote Decnet-only Vax from an Apollo that talks only TCP, you mail to remotevax::user (like in VMS) and it is rewritten into user%remotevax.dnet@decnetgatewayvax When it gets to the "decnetgatewayvax", the mail gets sent to remotevax::user like you really wanted to. I run the ultrix one on all systems and have added the SR10 mailers for DPSS<--->unix mail with no problems. The only thing I can't make it do is handle the case of mailing from DPSS to a *remote* unix mail site (which I think is lack of a feature...it works just fine between *local* DPSS and unix mail). -- Vince Skahan - please reply to skahan@boeing.com or bcsaic!psev!bcs212 Note: any comments expressed above are mine and have no relation to Boeing or the real nice folks who let me read news on their system...
steve@simon.UUCP (Steven E. Piette) (06/08/89)
In article <24432@shemp.cs.ucla.edu>, dieter@oahu.cs.ucla.edu (Dieter Rothmeier) writes: > > I am trying to get mail to work on our little 3 node > Apollo network. We are running Domain/IX 9.7 4.2 BSD. > At this point, no machine can send mail to any other > machine. When I try to send mail to user@othernode using the > verbose option, it displays > ... Connecting to .ether.. > user@othernode... Host unknown. > > I am using /usr/ucb/mail. > Telnet,ftp and rlogin work fine between all the nodes. > Any help would be appreciated, > Dieter Rothmeier It sounds like your not running sendmail as a daemon on any of the other systems. You can check this by executing netstat -a on the other systems and looking for *.smtp open on a port. If you don't see any then edit you rc files to add /usr/lib/sendmail -bd -q1h. (you may just need to uncomment the specific line in /etc/rc or /etc/rc.local). First you might like to try using ps ax to see if sendmail is running (I must be getting old, suggesting looking at netstat's output before thinking of ps (:-)) It's also possible that your /usr/lib/sendmail.cf file needs tweeking. If you plan on using both SMTP and UUCP to move mail you will need to change it from the default provided by Apollo. (their used to be a uucpproto.cf file you could use as a starting point.) I hope this helps... -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 -------------------------------------------------------------------------------
weber_w@apollo.COM (Walt Weber) (06/08/89)
In article <8906021616.AA02345@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes about sendmail.cf: > . . . . . . . . . . . . . . . . . . . . . . The only problem I > have found with this sendmail.cf file is that it does not > recognize names of the form "host.subdomain.domain" even though > they are in the /etc/hosts file and it forwards the message to > the forwarding machine rather than sending it directly (eg. my > /etc/hosts files contains both "richter" and "richter.mit.edu", > but the sendmail.cf file I'm sending you will only recognize > "richter" as a machine that it can send mail to directly. It > will send mail for "richter.mit.edu" to the forwarding machine > -- which fortunately, will send the mail to the correct host). > > I am looking for the fix to this problem. In the meantime, I > hope this file will work for you. It may help you to know that under sr10, a number of different sendmail config's were released in the "domain_examples" tree. (Then again, it might NOT help you :-). Please understand that these are released AS IS, with no support available to answer questions on "why was it done like this...". These are unsupported -- but we did want to make them available to you, since they came from the bsd tapes. ...walt... -- Walt Weber Apollo Computer (508) 256-6600 x8315 People's Republic of Massachusetts -The views expressed herein are personal, and not binding on ANYONE-
steve@simon.UUCP (Steven E. Piette) (06/08/89)
In article <8906021616.AA02345@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: > (stuff deleted) > 1) make certain that the file /usr/lib/sendmail.fc (".fc", not > ".cf") has been deleted. This is the "frozen" mail configuration > file. If it exists, the mailer will use it instead of the > /usr/lib/sendmail.cf file. > (stuff deleted) > 3) You can create a new "frozen" configuration file by using the > command /usr/lib/sendmail -bz to read the ".cf" file and create > a new ".fc" file. The mailer is supposed to run faster using > the ".fc" file, but you have to remember to re-freeze the > configuration file after every time you edit the ".cf" file. > > -- David Krowitz > krowitz@richter.mit.edu (18.83.0.109) David, If this is still in reference to mail problems under SR9.7.x then frozen configuration files were not supported. You can sendmail -bz to your heart's content but nothing will happen. I don't remember if 10.0 cleaned this up. Also if this is the correct thread (9.7 mail problems) the /etc/host file had to be correct for rlogin and ftp to work by giving a host name (they lookup the name in the host file to get a internet number, but you knew that). Back when I used to work at Apollo, I hacked up a couple of functional sendmail files for both mixed SMTP/UUCP and for SMAIL support. Unfortunatly I can't seem to find them around here anymore. (anyone want to restore some old wbak tapes?) Oh well back other hacking. -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 -------------------------------------------------------------------------------
lau@kings.wharton.upenn.edu (Yan K. Lau) (06/08/89)
In article <43b2954e.10b48@apollo.COM> weber_w@apollo.COM (Walt Weber) writes: >It may help you to know that under sr10, a number of different >sendmail config's were released in the "domain_examples" tree. >(Then again, it might NOT help you :-). Please understand that these >are released AS IS, with no support available to answer questions on >"why was it done like this...". These are unsupported -- but we did >want to make them available to you, since they came from the bsd tapes. This wasn't very helpful to us. Apollo was definitely true to its word that they are unsupported :-) & :-(. One would think that they would at least provide one usable on the Internet. The boilerplate version for the Arpanet (remember that?) did not work as is. I was able to get a working version from a neighboring site (thanks again!). I am very grateful and didn't look further into it. How anyone can figure this stuff out even with the documentation is beyond me. Yan. ============================================================================== Yan K. Lau + the last message of a newgroup will be: )~ + a) longer than one screen & ~/~ lau@scrolls.wharton.upenn.edu + b) something you're not interested in. /\_ + your decision, 'n' key or space bar? ==============================================================================
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/09/89)
If the sendmail daemon is not running on the destination machine, the message you get is the following (use "mail -v" to see this): $ mail -v krowitz@hess Subject: test abc *** EOF *** Cc: krowitz@hess... Connecting to hess.tcp... krowitz@hess... Deferred: Connection refused by hess If the destination machine is not up, or is not running the tcp/ip daemon (/etc/tcpd), the message you get is: $ mail -v krowitz@hess Subject: test 123 *** EOF *** Cc: krowitz@hess... Connecting to hess.tcp... krowitz@hess... Deferred: Connection timed out during user open with hess In general, tcp/ip based software will give you a "timed out" message if the node is down, the tcp server is dead, or if an intervening gateway is not routing the messages correctly. The the server for the particular program you are using is not running on the destination machine, then you get a "connection refused" message. If your host tables don't have the machine, or if the program you are using has a configuration file which is not set up correctly, then you will get the "host not found/known" message. Note that if your /etc/hosts table contains an IP number which is incorrect, then you will also get a "connection timed out" error due to the fact that the TCP/IP packets will have been misrouted. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
weiner@novavax.UUCP (Bob Weiner) (06/10/89)
In article <1570@lgnp1.LS.COM> vskahan@lgnp1.LS.COM (Vince Skahan) writes: In article <8906021616.AA02345@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >The sendmail.cf file is, as you said, formidable. >There are very few people who can understand the cryptic >format of the file. Most of us (myself included) use >an existing file we borrowed from someone else and then >modified for our particular site. > Same goes with us. I took a look at the (in my opinion quite weak) examples in arpaproto.cf and uucpproto.cf, put the two together and got something that was relatively stupid for both UUCP and TCP. We have a similar need, for both SMTP and UUCP mail routing. Apollo says they do not provide anything that does both. The DPSS to UNIX mail translation rules are also overly simplistic. Those wanting (needing) to play with the sendmail config files might consider getting the 'ease' software that I believe comes from Emory University and should be in the comp.sources.unix archives. It lets you write sendmail config files in a much more structured and readable syntax; ease translates this into a sendmail.cf file. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087