jcc@siemens.UUCP (04/19/85)
<> I am having another problem with sendmail. We have two vaxes here VAXA and VAXB. On VAXB, I have a .forward file in my directory which says jcc@VAXA. Now, I login to VAXA and type "mail jcc@VAXB". I would expect the file to go over to VAXB and then be forwarded back to me on VAXA. However, the file disappears! There is a notice of VAXB receiving the file in the syslog, but it never sends it back to VAXA. Does anyone know why this happens. Note that I can say "mail jcc" on VAXB and it will get delivered to my VAXA account. The load average on both machines is below 3, so I do not think it has to do with the previous sendmail discussion. Any comments would be appreciated. Thanks. Joe Camaratta princeton!siemens!jcc
stanonik@nprdc (04/20/85)
"Smtp connections never include the sender in alias expansions and even drop the sender from the recipient list." So, smtp mail from jcc@vaxa after being aliased to jcc@vaxa on vaxb is quietly dropped by vaxb. Your syslog on vaxb should show a From, but no To entry. We encountered a similar problem when we brought up our second vax. Ron Stanonik stanonik@nprdc Subject: aliases and smtp Index: usr.lib/sendmail/src/srvrsmtp.c 4.2BSD Apparently-To: 4bsd-bugs@BERKELEY Description: Sendmail 'normally' doesn't include the sender in alias expansion; this feature is documented in the manual page. 'Normally' wasn't what I expected, but it was ok. Smtp connections however never include the sender in alias expansions and even drop the sender from the recipient list. The problem seemed to be that smtp recipients weren't treated the same as sendmail arguments; ie, weren't being tagged QPRIMARY. Repeat-By: /usr/lib/sendmail -bs mail from:<root> rcpt to:<root> data test . quit Nothing is delivered to root. Fix: Set the QPRIMARY flag for recipients in the CMDRCPT case in smpt() srvrsmtp.c RCS file: RCS/srvrsmtp.c,v retrieving revision 1.2 diff -c -r1.2 srvrsmtp.c *** /tmp/,RCSt1010446 Tue Nov 6 07:36:18 1984 --- srvrsmtp.c Fri Nov 2 10:36:34 1984 *************** *** 231,236 a = parseaddr(p, (ADDRESS *) NULL, 1); if (a == NULL) break; a = recipient(a, &CurEnv->e_sendqueue); if (Errors != 0) break; --- 231,237 ----- a = parseaddr(p, (ADDRESS *) NULL, 1); if (a == NULL) break; + a->q_flags |= QPRIMARY; a = recipient(a, &CurEnv->e_sendqueue); if (Errors != 0) break;
dave@RIACS.ARPA (Dave Gehrt) (04/20/85)
Or you can invoke the sendmail daemon as: /usr/lib/sendmail -bd -om which will override the mentioned feature and send mail to the name on the from line if it shows up as a recipient after alias expansion. At least on our 4.2 system. dave ----------
jcc@siemens.UUCP (05/01/85)
<> I am having a problem with sendmail creating empty qfAA* files in the spool directory. In the morning there is sometimes 150 such entries! Has anyone experienced this problem (yet)? Also, when I run sendmail by hand (/usr/lib/sendmail -q), not all of the entries in a queue are processed. After sendmail finishes there is a core file in the queue directory but sendmail gives an exit status of 0! This core file is definitely a sendmail image ( I checked it with strings (1) ) and the date suggests that it was caused by the latest invocation of sendmail. It seems that sendmail has problems parsing an address of the form: firstname.lastname@site.ARPA All entries (empty qfAA* files) after this entry are locked, but not processed. Can anyone tell me where the empty files are coming from and why the core image exists? Thank you. Joe Camaratta princeton!siemens!jcc
jcc@siemens.UUCP (05/01/85)
<> One interesting point I noticed about sendmail. I recompiled the source for sendmail in /usr/src/usr.lib/sendmail/src . The size of the executable file is 96256. The size of the /usr/lib/sendmail distributed with 4.2BSD is 81920. Is there a reason for this? Could this be the cause of my problems? Will it ever end? Joe Camaratta princeton!siemens!jcc
avolio@decuac.UUCP (Frederick M. Avolio) (05/03/85)
I suggest running sendmail in test mode. This will probably give
you an indication of what is happening. Your sendmail.cf file is
probably to blame (the size of /usr/lib/sendmail matches mine whic
does not dump core). I have had sendmail dump core (after making some
dumb -- since forgotten -- error(s) in the configuration file).
Sendmail makes lock files, dumps core, and then, from then on, nothing
gets mailed. (Handy, huh?)
Oh yeah, test mode...
/usr/lib/sendmail -bt
some good words...
>
After the > prompt, type in a rule and an address (you are not sending
anything here... sendmail is going to show you how it parses the
address). If you don't get the prompt, you should get an error which
(it is hoped) will indicate what is wrong with your sendmail.cf file.
If you do get the prompt, try some of the suspect addresses (by
looking at the date on core and looking in /usr/spool/mqueue/syslog
you should be able to tell what mail message caused it to die young).
Good luck!
--
Fred Avolio {decvax,seismo}!decuac!avolio 301/731-4100 x4227