HDTenEightyP/NetNews huggingface dataset:
From: fyta@chulkn.chula.ac.th ("Dr. Yunyong Teng-amnuay")
Subject: pine confusion on UNIX From line
Date: Tue, 29 Dec 1992 15:24:05 +0000 (BKK)
X-Received: by usenet.pa.dec.com; id AA10401; Tue, 29 Dec 92 00:32:34 -0800
X-Received: by inet-gw-1.pa.dec.com; id AA01954; Tue, 29 Dec 92 00:32:24 -0800
X-Received: by chula.ac.th (4.1/SMI-4.1)
	id AA28027; Tue, 29 Dec 92 15:33:04 BKK
X-To: Usenet News Posting <comp.mail.uucp.usenet>,
        Usenet News Posting <comp.mail.sendmail.usenet>
X-Cc: Peraphon Sopatsasatit <sophatsa@enuxhb.eas.asu.edu>,
        admin@chulkn.chula.ac.th
X-Mime-Version: 1.0
X-Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear Netters,

I am using AT&T StarServer E with AT&T UNIX System V Release 4.0 3.0
with Wollongong/StarGroup TCP/IP s/w.

My pine 3.05 confuses the UNIX From line with the "From: " line in normal
mail header.  And so it tries to parse the "seconds" field in the date on
the UNIX From line as a user name.

Either I fixed the pine program which maynot be possible for me or I
change the mail agent parameters somewhere to omit the From line.

Any suggestion?

--Yunyong

Dr. Yunyong Teng-amnuay
Centers of Academic Resources           Voice:  (662) 218 2925
Chulalongkorn University                Fax:    (662) 215 3617
Phyathai Rd., Bangkok 10330, Thailand   Internet: fyta@chulkn.chula.ac.th


Xref: sparky comp.mail.sendmail:3088 comp.unix.aix:12932
From: kleim@bass.bu.edu (Kathryn Kleiman)
Newsgroups: comp.mail.sendmail,comp.unix.aix
Subject: Comsat and aliases
Summary: User not being notified
Keywords: comsat, biff, sendmail
Date: 30 Dec 92 21:50:13 GMT
Followup-To: comp.mail.sendmail
Distribution: na
Organization: Boston University

A user of the system that I am postmaster for has complained to me that he
is not notified when mail comes in addressed to his alias.  Specifically,
when mail comes in addressed to luser@site (the actual name) the user is
biffed, but when mail comes in addressed to userl@site, he is not.  The
entry in the aliases file reads

userl:luser

Please respond to this query to 'cstern@novus.com,' as I am using this account
as a guest.
Newsgroups: comp.mail.sendmail
From: pascoe@rocky.ndhm.gtegsc.com (Dave Pascoe)
Subject: MX record question
Organization: GTE/MSED - Needham Heights, MA
X-Newsreader: TIN [version 1.1 PL7]
Date: Tue, 22 Dec 1992 20:53:01 GMT


This is a generic sendmail question, but Sendmail 5.65c-IDA-1.4.4 is
being used in this case.  host.domainA.com wants to receive Internet
mail from mailrelayB.domainB.com (primary MX) but IP access lists restrict
connectivity such that mailrelayB.domainB.com can only connect to
either relayA.domainA.com or relayC.domainA.com.  Both relayA.domainA.com
and relayC.domainA.com can then connect to host.domainA.com.

Is there any way (besides changing sendmail.cf on
mailrelayB.domainB.com) to force delivery to one of the secondary mail
exchangers?  

These are the current MX records in effect:

host.domainA.com.  3005    MX      5 mailrelayB.domainB.com.
host.domainA.com.  3005    MX      10 relayA.domainA.com.
host.domainA.com.  3005    MX      15 relayC.domainA.com.

Thanks for any help on this....

--
Dave Pascoe
Internet: pascoe@rocky.ndhm.gtegsc.com
GTE/MSED - Needham Heights, MA
(617) 455-5704
Newsgroups: comp.mail.sendmail
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Trouble writing to a file
Organization: Northern Illinois University
Date: Mon, 21 Dec 1992 20:49:12 GMT

In article <FULL_GL.92Dec19060740@dolphin.pts.mot.com> full_gl@pts.mot.com (Glen Fullmer X3296 Pager 7362) writes:
>I put an alias in /etc/aliases like:
>
>	rnews: "/usr/spool/news/incoming/xxx"
>
>and send mail to rnews and it responds with a error message
>that it can not write to a file, permission denied.  I change the
>permissions of the file and all directories above it and still get the
>message.  I even change it to "/tmp/xxx" and I also try a .forward to
>a file with the same results!  Any ideas for a fix?

	rnews: "|cat >> /usr/spool/news/incoming/xxx"

will probably work if run from '.forward', and the file xxx is owned by
the user who is '.forward'ing.  But what you really need is a mail
processing delivery program such as 'deliver' or 'procmail'.

Newsgroups: comp.mail.sendmail
From: pascoe@rocky.ndhm.gtegsc.com (Dave Pascoe)
Subject: Re: MX record question
Organization: GTE/MSED - Needham Heights, MA
X-Newsreader: TIN [version 1.1 PL7]
Date: Tue, 22 Dec 1992 21:14:52 GMT

One more thing:


: These are the current MX records in effect:
: 
: host.domainA.com.  3005    MX      5 mailrelayB.domainB.com.
: host.domainA.com.  3005    MX      10 relayA.domainA.com.
: host.domainA.com.  3005    MX      15 relayC.domainA.com.

relayA.domainA.com and relayC.domainA.com are not SMTP-reachable from the
Internet due to the IP access lists.  This will change in the future
so the fix I'm looking for is only an interim fix.

--
Dave Pascoe
Internet: pascoe@rocky.ndhm.gtegsc.com
GTE/MSED - Needham Heights, MA
(617) 455-5704
From: eric@CS.Berkeley.EDU (Eric Allman)
Newsgroups: comp.mail.sendmail
Subject: ALPHA version of sendmail Release 6 available
Followup-To: comp.mail.sendmail
Date: 22 Dec 1992 00:28:18 GMT
Organization: UC Berkeley Mammoth Project
Distribution: world
Reply-To: eric@CS.Berkeley.EDU
NNTP-Posting-Host: mastodon.cs.berkeley.edu

An ALPHA version of sendmail Release 6 is available for public FTP on
FTP.CS.Berkeley.EDU in ucb/sendmail/sendmail.6.1.tar.Z.  This has many
major changes from versions that you have all seen (including fixing a
number of bugs that may have been vexing you for a long time).

This is *NOT* "Son of Sendmail".  I have in the past resisted attempts
to update this version of sendmail in the hopes that I would get time to
do a proper rewrite.  That doesn't seem very plausible, at least in the
short run.  Maybe someday......

Some of the major changes:

* Eight bit clean.

* Dynamically allocated headers.

* Keyed files.

* Connection caching.

Some of these changes are distinctly non-trivial, and although we have
been running most of them at Berkeley for several months, you should be
cautious.  However, I think you'll find substantial improvements,
particularly for large or complex sites.

This release also contains new configuration files that are somewhat
simpler and cleaner than the old ones.  However, they do assume that
you are running SMTP, at least on a local network, and may be inappropriate
for UUCP-only sites.

eric
From: anselmo@nic.near.net (Ed Anselmo)
Newsgroups: comp.mail.sendmail
Subject: Re: MX record question
Date: 22 Dec 1992 17:44:02 -0500
Organization: NEARnet, Cambridge, MA
	<1992Dec22.211452.4508@europa.asd.contel.com>
NNTP-Posting-Host: nic.near.net
In-reply-to: pascoe@rocky.ndhm.gtegsc.com's message of Tue, 22 Dec 1992 21:14:52 GMT

[ It surely would make things easier if people just used the Real
  Names of Hosts when asking for help.... ]

If you want the mail to end up on host.domainA.com, then you need an
MX-record pointing to host.domainA.com.

So, if I've got this straight, the only machine of the four that is
reachable from the Internet is mailrelayB.domainB.com, right?

And host.domainA.com *isn't* reachable from mailrelayB.domainB.com,
but only reachable via relayA and and relayC?

Then this should work:

host.domainA.com.  3005    MX       5 host.domainA.com
host.domainA.com.  3005    MX      10 relayA.domainA.com.
host.domainA.com.  3005    MX      15 relayC.domainA.com.
host.domainA.com.  3005    MX      25 mailrelayB.domainB.com.
Newsgroups: comp.mail.sendmail
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: Trouble writing to a file
Organization: Bruce Lilly
Date: Mon, 21 Dec 92 16:24:54 GMT
Reply-To: lilb@sony.compuserve.com (Bruce Lilly)

In article <1992Dec21.155057.1303@blilly.UUCP> lilb@sony.compuserve.com (Bruce Lilly) wrote:
>
>Note that although the combination of sgid bit set and group execute bit not
>set indicates that mandatory file locking should be used (on System V and
>its derivatives), no file locks are set by the code, so it is possible for
>two or more processes to write to the file at the same time, resulting in
>gibberish.

The following patches, based on UIUC/IDA 5.65c, take care of locking the
file being mailed to.  Your line numbers, as well as your mileage, may
vary.

*** deliver.c	Mon Dec 21 11:17:26 1992
--- deliver.c	Mon Dec 21 11:17:32 1992
***************
*** 1560,1565
  		if (f == NULL)
  			exit(EX_CANTCREAT);
  
  		putfromline(f, ProgMailer);
  		(*CurEnv->e_puthdr)(f, ProgMailer, CurEnv);
  		putline("", f, ProgMailer);

--- 1560,1576 -----
  		if (f == NULL)
  			exit(EX_CANTCREAT);
  
+ 		/* lock the file to prevent multiple processes's output from colliding */
+ 		/* this works fine for System V derived systems, since mandatory file locking
+ 			is enforced by the kernel, given the file modes
+ 		*/
+ 		/* for systems w/o mandatory file locking, it will still prevent cooperating
+ 			processes (probably only other sendmail processes) from trying to
+ 			write simultaneously
+ 		*/
+ 		/* complaints about BSD's lack of mandatory locking to Leffler, McKusick et. al. */
+ 		(void) flock(fileno(f), LOCK_EX); /* block if locked */
+ 
  		putfromline(f, ProgMailer);
  		(*CurEnv->e_puthdr)(f, ProgMailer, CurEnv);
  		putline("", f, ProgMailer);
***************
*** 1565,1570
  		putline("", f, ProgMailer);
  		(*CurEnv->e_putbody)(f, ProgMailer, CurEnv);
  		putline("", f, ProgMailer);
  		(void) fclose(f);
  		(void) fflush(stdout);
  

--- 1576,1582 -----
  		putline("", f, ProgMailer);
  		(*CurEnv->e_putbody)(f, ProgMailer, CurEnv);
  		putline("", f, ProgMailer);
+ 		/* closing the file drops the lock */
  		(void) fclose(f);
  		(void) fflush(stdout);
  
-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce
From: Thomas.Tornblom@nexus.comm.se (Thomas Tornblom)
Newsgroups: comp.mail.sendmail
Subject: Re: BUG in 5.65c8/IDA-1.4.4 Sendmail
Date: 22 Dec 92 11:48:49 GMT
Organization: Communicator Nexus AB

In article <1h5s28INN9ia@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:


   There's a rather deadly bug in the sendmail which says "5.65c8/IDA-1.4.4"
   when I SMTP to it. I don't know if that bug has been reported, and frankly
   I don't care, not runing sendmail myself.

   % telnet amiga.physik.unizh.ch 25
   220 amiga.physik.unizh.ch 5.65c8/IDA-1.4.4 Sendmail [...]
   HELO smurf.sub.org
   250 Hello smurf.sub.org, pleased to meet you
   MAIL From:<anybody-at-all>
   250 postmaster... Sender ok
   RCPT To:<another-anybody>
   250 <another-anybody>... Recipient ok
   DATA
   354 Enter mail, end with "." on a line by itself
   X-Charset: Dead

   .
   554 getchout: open of charset output translation file //usr/local/lib/mail/char/DEAD
   quit
   221 amiga.physik.unizh.ch closing connection

   Very neat. An undocumented and optional header causes my mail to fail.
   NOT GOOD:

   Now, we replace the word "Dead" with the empty string. Guess what? The mailer
   hangs.

   Very nice. Very nice indeed.

   !!! Test your software before letting it loose on the Internet !!!


   Disclaimer1: This may be a local hack by amiga.physik.unizh.ch.
		If so, sorry to annoy the rest of the world with this.
   Disclaimer2: I'm sorry if this looks like a flame. It's not. Not really,
		anyway. Well, let's assume it isn't.  ;-)


So if you don't care, why bother? And why are you using "undocumented"
headers if you don't know how to use them? What is the proper
behaviour if you use an optional header in a manner not intended?

I myself find these additions very useful (thanks Keld) as they allow
me to use ISO-8859-1 (or about any other character set) and still
conform to RFC-822 (7 bit SMTP).

One could perhaps expect sendmail to accept and deliver the mail
without character set translations of no translation set is found.

Thomas
--
Real life:      Thomas Tvrnblom           Email:  Thomas.Tornblom@Nexus.Comm.SE
Snail mail:     Communicator Nexus AB     Phone:  +46 18 171814
                Box 857                   Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.mail.sendmail
Subject: Re: BUG in 5.65c8/IDA-1.4.4 Sendmail
Date: 22 Dec 1992 23:55:36 +0100
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In comp.mail.sendmail, article <THOMAS.TORNBLOM.92Dec22124849@beck.nexus.comm.se>,
  Thomas.Tornblom@nexus.comm.se (Thomas Tornblom) writes:
> 
> So if you don't care, why bother? And why are you using "undocumented"
> headers if you don't know how to use them? What is the proper
> behaviour if you use an optional header in a manner not intended?
> 
In case it wasn't obvious -- I didn't originate that mail. 

> One could perhaps expect sendmail to accept and deliver the mail
> without character set translations of no translation set is found.
> 
I don't really care about sendmail or what it does or does do to mail;
after all, I don't use it.
I do care, however, about problems that clog my mail queues. If the problem
happens to originate with sendmail, I post to comp.mail.sendmail if there's
evicende that the problem is not local to one site. Any problems with that?

This X-Charset problem is bad because the header isn't standardized.
Thus, the mail conforms to RFC-822. Thus, sendmail is required to do
something reasonable with it. Hanging SMTP connections are generally
_not_ considered reasonable.  :-/   IMHO, neither is the 554 rejection
I get when X-Charset doesn't contain a recognized translation. The sender
can't know which charsets may or may not be installed at the receiver.

-- 
La vache qui rit est jolie.
 
(Laughing cows are pretty.)
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
From: rmh0363@zeus.tamu.edu
Newsgroups: comp.mail.sendmail
Subject: Could Someone Help?
Date: 22 Dec 1992 14:22 CST
Organization: Texas A&M University, Academic Computing Services
Distribution: world
NNTP-Posting-Host: zeus.tamu.edu
News-Software: VAX/VMS VNEWS 1.41    

I'm a computer technician for a technology licensing office, and my employer 
wants to do something, that I'm not sure how to do. So if someone could help
or give me some ideas I'd really appreciate it.  His clients want to E-mail
requests for documents and have the requests serviced by a computer and sent
back via E-mail.  I know that it's possible, but I'm not sure of the 
requirements for doing this.  What are the procedures and software required?
Please mail me any help you could to:

rmh0363@zeus.tamu.edu

Thanks
From: kehres@ima.com (Tim Kehres)
Newsgroups: comp.mail.sendmail
Subject: Re: Return-Receipt-To & forwarding...
Date: 31 Dec 92 00:45:06 GMT
Organization: International Messaging Associates, Menlo Park, California

In article <1992Dec25.161948.9506@blilly.UUCP> lilb@sony.compuserve.com (bruce Lilly) writes:
:
> >Should my mailer send one more notifying message to the
> >author?
> 
> I believe that it should not do so (I was once bombarded by return receipts
> after sending a bug report to one of FSF's bug-reporting addresses, which
> expanded to a mailing list).

This is one reason why return receipt and delivery notification requests
should be standarized.  If standardized, then the distribution list software
could be modified to look for these requests, and perform the required 
function.  For most lists, I would suspect that no action would be taken
for a return receipt request, other than its removal from the header.  A 
delivery notification request however would generate a reply back to the 
originator indicating final delivery to the list, and then remove the request
from the header.  There are some list maintainers however that may wish to 
pass these requests through the list, and that should be allowed, if that is 
what the owner of the list desires.

Best Regards,

Tim Kehres
Newsgroups: comp.mail.sendmail
From: vlcek@mtl.mit.edu (Jim Vlcek)
Subject: Re: Is it possible to alias a hostname?
Summary: I think I've got it
Organization: EPI / Chorus Corporation
Date: Sat, 2 Jan 1993 11:39:41 GMT

I'd needed a way to redirect mail that was addressed to PCs which
(rather misguidedly) used SMTP to forward outgoing messages, but
couldn't accept incoming mail.  Greg Woods of NCAR was quite helpful,
and now I think I've got a solution:

Basically, a Unix mailhost running sendmail must intercept the
mail messages targeted to a PC and redirect them instead to the
POP server.  This must be done by implementing new rules into the
sendmail.cf file.

First, I defined a new class (named "C") of "mail clients"; these
are the PCs which might originate (but cannot receive) SMTP mail.
This is accomplished with the following line in /etc/sendmail.cf:

  FC/etc/mailclients

The actual names of the PCs are placed in the file /etc/mailclients
(one name per line, hostname ONLY (not fully qualified host w/
domain))
rather than specifying them in the sendmail.cf file itself; this makes
maintenance much easier as well as keeping the whole process more
streamlined.

Next, the rewrite rules for the mailclients must be included in
sendmail.cf.  This is accomplished by the following two rules:

  R$*<@$=C>$*           $1<@LOCAL>$3            <@pc> -> <@LOCAL>
  R$*<@$=C.$=m>$*       $1<@LOCAL>$4            <@pc.dom> -> <@LOCAL>

This maps addresses of the form <user@pcname> or
<user@pcname.subdomain.domain> into <user@LOCAL>, which is what my
Sun's sendmail wants to see (I'm not certain, but others may be
different).  Note that $=C matches any hostname in the class "C",
and $=m matches any name in the class of valid domain names for this
site.

Now, the question is, where should these rules be placed (ie, in which
ruleset)?  Ruleset three is used to map addresses into an internal
canonical form, so these rules should be placed somewhere such that
they are invoked directly or indirectly by ruleset three.

In the Sun sendmail.cf, ruleset six ("special local conversions") is
invoked directly by ruleset three.  It previously consisted of but one
rule:

  R$*<@$*$=m>$*         $1<@$2LOCAL>$4          convert local domain

which simply mapped <user@localhost.subdomain.domain> into
<user@localhost.LOCAL>.  This seemed like the obvious place to put the
two new rules, so I placed them there.  Oh, I put them before the
existing rule so that they wouldn't have to deal with rewritten
addresses like <user@pcname.LOCAL>.

Other systems would probably have to modify the rule definitions
and their location somewhat, I would imagine.

SInce we're a small shop, I've just got aliases set up for all users
on the uucp host (my SUn) that provides the link to uunet.  In other
environments, it might be more advantageous to set up MX records for
the PCs in the mail link's DNS, directing all the mail for the PCs to
the POP host.  Then, the hacks that I've described above should be
done on the POP host rather than the mail gateway.

Thanks again, Greg.

Jim Vlcek
vlcek@epimbe.com
Newsgroups: comp.mail.sendmail
From: markmc@halcyon.com (Mark McWiggins)
Subject: Re: Fun with sendmail & friends
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Fri, 1 Jan 1993 02:08:29 GMT

*blush* I found the problem with sendmail hanging ... in changing from
raw sendmail.cf to Ease-ish, I must have inadvertently done something
that caused a loop in rulesets and/or macro definitions. 

I found the hanging loop with -d35.25, then  went back to the  original
sendmail.cf file, converted to Ease, converted back, and ran -- with no
hang.

I think I should be able to get things going from here, so thanks
anyhow! *blush*

-- 
Mark McWiggins        Hermes & Associates		+1 206 632 1905 (voice)
markmc@halcyon.com    Box 31356, Seattle WA 98103-1356  +1 206 632 1738 (fax)
Newsgroups: comp.mail.sendmail
From: mrl@uai.com (Mark R. Ludwig)
Subject: Care and feeding of sendmail's mail queue directory
Organization: /etc/news/organization
Date: 30 Dec 92 08:10:36

Okay, I'm not _that_ experienced with sendmail, but I've never had
this happen before:

mark's favorite wierd prompt> ls -l /usr/spool/mqueue
total 159
-rw-------  1 root        56992 Dec  9 15:11 dfAA20922
-rw-------  1 root        39632 Dec  9 15:11 dfAA20926
-rw-------  1 root        25310 Dec  9 15:11 dfAA20929
-rw-------  1 root        39632 Dec  9 15:11 dfAA20930
mark's favorite wierd prompt> 

The ``mailq'' command didn't acknowledge their existence.  I manually
removed them, and then started wondering why I had to do that.
Perhaps I should have a cron job?  

For version information, I'll relay what connecting to our daemon yields:

220 uai.com 5.65c/IDA-1.4.4 Sendmail is ready at Wed, 30 Dec 1992 08:07:30 -0800

Thanks in advance for any tips, pointers, etc.$$
From: avolio@TIS.COM (Frederick M Avolio)
Newsgroups: comp.mail.sendmail
Subject: Re: Care and feeding of sendmail's mail queue directory
Date: 30 Dec 92 18:18:02 GMT
Reply-To: avolio@TIS.COM
Organization: Trusted Information Systems, Inc.

1. The didn't appear in mailq output because there are no associated
q-files for the data files..

2. Yes one might want to write something to sort through these things
on occasion. 

These files were left when some catastrophe struck: system shutdown,
network disconnect, file system full, etc.

F
Newsgroups: comp.mail.sendmail
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Is it possible to alias a hostname?
Organization: Northern Illinois University
Date: Sat, 2 Jan 1993 16:46:11 GMT

In article <1993Jan2.113941.23309@athena.mit.edu> vlcek@mtl.mit.edu (Jim Vlcek) writes:
>I'd needed a way to redirect mail that was addressed to PCs which
>....

>  R$*<@$=C>$*           $1<@LOCAL>$3            <@pc> -> <@LOCAL>
>  R$*<@$=C.$=m>$*       $1<@LOCAL>$4            <@pc.dom> -> <@LOCAL>
>..

>Now, the question is, where should these rules be placed (ie, in which
>ruleset)?  Ruleset three is used to map addresses into an internal

They probably should go in ruleset 0, toward the beginning of the
ruleset.  But you may need to change the second rule, or add a
new rule

R$*<@$=C.LOCAL>$*	$1<@LOCAL>$3

Putting it in ruleset 3 only affects the actual delivery, and does
not change the address on the headers.

Actually, if you put those hosts in class 'w' instead of class 'C'
you probably won't need any new rules at all.
From: eric@CS.Berkeley.EDU (Eric Allman)
Newsgroups: comp.mail.sendmail
Subject: updated sendmail (6.4) alpha distribution
Date: 2 Jan 1993 22:29:25 GMT
Organization: UC Berkeley Mammoth Project
Distribution: world
Reply-To: eric@CS.Berkeley.EDU
NNTP-Posting-Host: mastodon.cs.berkeley.edu

There is an updated version of sendmail available on FTP.CS.Berkeley.EDU
in ucb/sendmail/sendmail.6.4.tar.Z.  This is still an alpha release.  It
fixes about a dozen bugs, most of which turn out to have existed for some
time, but which got misfiled at our end.

eric