chris@bnrunix.UUCP (Chris Fulmer) (10/04/90)
Hi there. This has probably been asked before, but.... We are having a problem with external people replying to mail sent from our host across our uu link. I think that what happens is that the replyed to mail gets copied to our local host, via uucico and gets picked up by smail. smail connects to the smtp port on the local machine, strips the local name off of the incoming message, and trys to do a HELO with that name. Now, the problem is that if the name is the same as what sendmail thinks the local name is, sendmail gives back an error, something like "name configuration error." The current work-around is to tell everybody to strip the domain name off any mail that they want to reply to. Then, when the HELO happens, the two strings don't match, and sendmail lets the connection go through. Now, my question is: How do I fix this? The obvious hack is to change the sendmail configuration file so that when only the local hostname is added onto the from: field, instead of the local hostname and the domain. Is this easily done? I looked in the sendmail.cf file, and the from line referenes the $q macro, which (I guess) is defined internal to sendmail. Any help on this would be appreciated. Thanks. ---------- ----------- Chris Fulmer Bell-Northern Research ...!uunet.uu.net!rti!bnrunix!chris P.O. Box 13478 "AAAHHHHH" RTP, NC 27709-3478
rickert@mp.cs.niu.edu (Neil Rickert) (10/04/90)
In article <485@bnrunix.UUCP> chris@bnrunix.UUCP (Chris Fulmer) writes: >Hi there. > >This has probably been asked before, but.... > >We are having a problem with external people replying to mail sent from our >host across our uu link. > >I think that what happens is that the replyed to mail gets copied to our >local host, via uucico and gets picked up by smail. smail connects to the smtp >port on the local machine, strips the local name off of the incoming message, >and trys to do a HELO with that name. Now, the problem is that if the name >(...) If smail is really doing this, then it is badly designed. The name used in the HELO message is supposed to be the host name. It should have absolutely nothing to do with the addresses in the mail. It ought to be a fixed value, either hard coded into smail, or in a configuration file. The name 'sendmail' uses for this purpose is $j, usually defined in the 'Dj' line of 'sendmail.cf'. It is supposed to be the fully qualified domain name of the host. To avoid having problems, smail should use a different name. Possible choices - 'localhost' is good, especially if it is doing the SMTP transfer over the loopback net. In checking out MH I have found no problems with its client mode SMTP. If the output it lists is complete with the 'snoop' option, then MH is not even using the HELO command, which if it works would certainly be one way of avoiding the problem. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
gary@nucs.cs.nu.oz (Gary Carroll) (12/14/90)
Hello,
I hope you can help us with this problem:
Sendmail is leaving processes such as the ones below after sending mail.
The syslog file says that the status of the mail is sent and we can confirm
that the mail has arrived. These processes stay indefinitely chewing up
CPU time like crazy. We'd like to get rid of this problem! Any suggestions
or hints where to look would be more than welcome.
We are using v5.65 of sendmail on a Sun 3/60.
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND
root 1465 24.3 0.1 176 16 p1 R 14:06 22:39 -AA01463 arp.anu.edu.au:
root 1420 23.9 0.1 176 16 p1 R 13:58 26:02 -AA01418 arp.anu.edu.au:
root 1362 22.3 0.1 176 16 p6 R 13:43 40:03 -AA01356 arp.anu.edu.au:
Thanks in anticipation,
Gary.
---------------------------------------------------------------------------
Gary W. Carroll. Department of Electrical Engineering and Computer Science,
University of Newcastle,
Newcastle, 2308, Australia. .-_|\
Telephone : (049) 685 225 / \
\.--._/
Internet : gary@nucs.newcastle.edu.au v
---------------------------------------------------------------------------paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (12/14/90)
gary@nucs.cs.nu.oz (Gary Carroll) writes: >Hello, > >I hope you can help us with this problem: > >Sendmail is leaving processes such as the ones below after sending mail. >The syslog file says that the status of the mail is sent and we can confirm >that the mail has arrived. These processes stay indefinitely chewing up >CPU time like crazy. We'd like to get rid of this problem! Any suggestions >or hints where to look would be more than welcome. > >We are using v5.65 of sendmail on a Sun 3/60. > >USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND >root 1465 24.3 0.1 176 16 p1 R 14:06 22:39 -AA01463 arp.anu.edu.au: >root 1420 23.9 0.1 176 16 p1 R 13:58 26:02 -AA01418 arp.anu.edu.au: >root 1362 22.3 0.1 176 16 p6 R 13:43 40:03 -AA01356 arp.anu.edu.au: Examine the spool directory for old tfAA* files. Chances are that you'll find three with the same uid in the filename as the spinning processes. Sendmail is spinning in the top of queueup() in a do loop that tries to exclusively open the control file: do { strcpy(tf, queuename(e, 't')); fd = open(tf, O_CREAT|O_WRONLY|O_EXCL, FileMode); if (fd < 0) { if ( errno != EEXIST) { syserr("queueup: cannot create temp file %s", tf); return NULL; } } else { if (flock(fd, LOCK_EX|LOCK_NB) < 0) { if (errno != EWOULDBLOCK && errno != EAGAIN) syserr("cannot flock(%s)", tf); close(fd); fd = -1; sleep(1); } } } while (fd < 0); If the file exists, sendmail assumes some other sendmail has it and will let go of it Real Soon. If it belongs to a dead process, sendmail spins forever. My fix was to remove any pending tf* files at boot time. In addition I added a else clause with a syserr and sleep after the test for EEXIST. Why the tf* files are accumulating should be investigated as well. /pbp -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910