HDTenEightyP/NetNews huggingface dataset:
From: barr@pop.psu.edu (David Barr)
Subject: Re: IDA and NO_WILDCARD_MX
Organization: Penn State Population Research Institute
Date: Tue, 13 Oct 92 13:29:33 GMT

In article <bw1ell.4of@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>another way you use to canonicalize single-token MX-only subdomains?  Or
>are you all just in the habit of typing fully qualified names even in your
>local domains?

I make no special tricks or hacks to allow people to use unqualified
addresses.  If someone sends mail from here to "bob@math", (expecting
it to be delivered to "math.psu.edu")  IMHO it _should_ always bounce.
(unless you have a locally connected machine that has no FQDN address
Even then in the latter case I prefer the ".UUCP" hack) This reminds me
of a problem at one of this campus's primary mail hubs.  They run
ZMailer, which has the broken behavior of doing recursive DNS queries.
I tried to send mail to "user@omega.UUCP".  Unfortunately, they have a
local machine called "omega", and it promptly tried delievering it
there.  :-(   Even worse, a friend of mine tried sending mail to
"user@willard.UUCP"  ZMailer did one step worse and tried to send mail
to one of our campus routers "willard.psu.edu".  *sigh* (This is
supposedly fixed in a later version)

To boil it down, I try to get my users into the habit of always using
fully qualified addresses.  Those few extra characters save me lots of
headaches, and the users a lot less bounced mail.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
Newsgroups: comp.mail.sendmail
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Skipped/Deferred in mailq
Organization: Northern Illinois University
Distribution: na
Date: Wed, 7 Oct 1992 14:54:59 GMT

In article <1992Oct7.061127.12066@proponent.com> monty%roscom@think.com (Monty Solomon) writes:
>Various entries displayed by mailq on one of our systems contained the
>following:
>
>                          Deferred: Host paradise is down
>                           Skipped: Host paradise is down
>
>What is the difference between Deferred and Skipped?

This is somewhat of a guess, since my sendmail does not use these two
different messages.

During a queue run, if sendmail times out trying to connect, it marks
the mail as deferred.  But it also caches the host name it is connecting
to.  If there are other messages for the same host in the same queue
run, sendmail does not even try - it assumes that the same problem will
recur.  On my system, both are marked as "Deferred", but "Skipped" is
perhaps a more informative term for the second case.

>Will all of the mail indicated by these entries be delivered when host paradise  
>comes back up?

Yes, that is what should happen.
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.mail.sendmail
Subject: Re: how to define specific return address?
Date: 14 Oct 92 23:48:15 GMT
Article-I.D.: mp.1992Oct14.234815.19850
Organization: Northern Illinois University

In article <3123@news.cerf.net> jerry@gristle.com writes:
>
>I have a NeXT that sends mail  via uucp and has a registered domain
>name unit.edu. Currently the From: gives the uucp return address:
>unit!user@ucsd.edu I'd like to change this to user@unit.edu
>
>Dq is like this:
>Dq$g$?x ($x)$.
>Header is defined thus:
>H?F?From: $q
>
>If I replace $g with unit.edu I get: 
> From: unit.edu%somereturnpath
>
>If I replace $g with $x@unit.edu I get:
> From: fullname@unit.edu
>		which is close to what I want.
>		Is there a variable for username?

These changes are asking for trouble.  You might try changing $g to $f
(which is a relatively harmless change).  But your problem is most likely
in the rewrite rules for your outbound mailer.  Look at the "S="
operand for the UUCP mailer, and investigate that rewrite ruleset.
There is probably a rule something like

	R$+	$w!$1

If so, try replacing it with

	R$+	unit.edu!$1
Newsgroups: comp.mail.sendmail
From: tmetro@lynx.dac.northeastern.edu (Thomas Metro)
Subject: Missing From: Header
Organization: Northeastern University
Date: Mon, 12 Oct 1992 10:08:25 GMT

We have recently switched from MMDF to sendmail.
I've noticed that I'm getting local mail with headers like this:
> From a-local-user Sun Oct 11 21:18:11 1992
> Subject: Re: Your account
> To: tmetro@lynx.dac.northeastern.edu
> Date: Sun, 11 Oct 92 21:18:08 EDT
> In-Reply-To: <no.id>; from "Tom Metro" at Oct 11, 92 6:33 pm
> X-Mailer: ELM [version 2.3 PL11]
Notice that there is no From: line.
The only indication of who sent the message is in the From_ line.
This format throws off the PC MUA I'm using (CMM). 
As can be seen by the headers, the message was generated by ELM.

I'd like to know if this is normal behavior for either sendmail or ELM
(in which case the PC software should be modified) or is the local system
messed up? Perhaps something absent from our Ultrix sendmail.cf?

 -Tom

tmetro@ds5000.dac.northeastern.edu

Newsgroups: comp.mail.sendmail
From: andy@homebase.vistachrome.com (Andy Finkenstadt)
Subject: Sender and Recipient rewrite rule #'s?
Reply-To: andy@homebase.vistachrome.com
Organization: Vista-Chrome Incorporated
Date: Thu, 15 Oct 1992 14:02:37 GMT

An easy question but I can't find the info online any more
by any reasonable 'grep'...

Ruleset 0 is applied to the envelope address (which can come
from the headers of the letter with the -t(?) option to sendmail).
From the mailer definition for 'uucp' it is numbers 13 and 23.
However, something ELSE invokes those, no?

My problem:  my sendmail.cf is rewriting From: and Reply-To:
headers which were already in fully qualified domain name form,
and I'd really prefer it not.

Thanks in advance.
-Andy


My site setup:

  An internal ethernet using SMTP over TCP/IP
  All hosts known on the ethernet are in /etc/hosts
  One of our UUCP neighbors (uunet) accepts multiple recipients on rmail
  All outside connectivity is through uucp

I think I have these as the applicable lines from my sendmail.cf:


# The official local domain that this host lives in.
# The full host name becomes $w.$D, which is the "Dw" hostname followed
# by the "DD" domain name.
DDvistachrome.com

# my official hostname
#	DO NOT COMMENT THIS OUT!
Dj$w

# uucp hostnames
DU$w
CU$=w rde homebase

#########################
#   Format of headers   #
#########################

H?P?Return-Path: <$g>
HReceived: $?sfrom $s $.by $j ($v/$Z)
	id $i; $b
H?D?Resent-Date: $a
H?D?Date: $a
H?F?Resent-From: $q
H?F?From: $q
H?x?Full-Name: $x
HSubject:
# HPosted-Date: $a
# H?l?Received-Date: $b
H?M?Resent-Message-Id: <$t.$i@$j>
H?M?Message-Id: <$t.$i@$j>

############################################################
############################################################
#####
#####		UUCP Mailer specification
#####
############################################################
############################################################


Muunetm,	P=/usr/bin/uux, F=DFMhum, S=13, R=23, M=900000,
	A=uux - -r -gC $h!rmail ($u)

Muucp,	P=/usr/bin/uux, F=DFMhu, S=13, R=23, M=500000,
	A=uux - -r -gC $h!rmail ($u)

#Muucp,	P=/bin/smail, F=sDFMhum, S=13, R=23, M=100000,
#	A=smail -vH$j $h!$u

S13
R$+			$:$>5$1				convert to old style
R$*<@$=w>$*		$1<@$w>$2			resolve abbreviations
R$*<@$->$*		$1<@$2.$D>$3			resolve abbreviations
R$+<@$+>		$2!$1				uucpize (no @'s in addr)
R$w!$+			$1				strip local name
R$+			$:$U!$1				stick on our host name
R$=U!$-%$-		$:$1!$2@$3.$D			ucbvax!user@host.domain

S23
R$+			$:$>5$1				convert to old style
R$*<@$=w>$*		$1<@$w>$2			resolve abbreviations
R$*<@$->$*		$1<@$2.$D>$3			resolve abbreviations
R$+<@$w>		$U!$1				a!b@here -> here!a!b
R$=U!$+			$2				here!a!b -> a!b
# sanity ... should not happen.
R$=U.$D!$+		$2				strip local name.domain

-- 
Andrew Finkenstadt       | Vista-Chrome, Inc.   |     NIC Handle: AF136
GEnie Unix Sysop/Manager | The Printing House   |    ...!uunet!rde!andy 
+1 904 222 2639 home     | 1600 Capital Cir SW  |   andy@GEnie.geis.com
+1 904 575 0189 work     | Tallahassee FL 32310 |  andy@vistachrome.com
 <> Send mail to ora-request@vistachrome.com to join Unix, CASE, and
 <> Desktop Oracle discussions.
From: chris@loki.amd.com (Chris Martin)
Newsgroups: comp.mail.sendmail
Subject: Invoking differnet local mailers based on a (CNAME) domain part?
Date: 7 Oct 92 15:34:43 GMT
Article-I.D.: amd.1992Oct7.153443.21874
Organization: Advanced Micro Devices, Santa Clara, CA

Hello,

I would like to bind CNAME records to mail-based services but I'm
running into a tricky architectural problem:

I have an email-to-fax gateway that allows internal users to send mail
to fax machines using "number@fax.amd.com" syntax.  I like this approach 
much more than mailing to an alias that invokes a fax gateway.  This
method allows completely unstructured input in a more user-friendly way.

[Note to the curious:  this gateway uses RFC822 trace information added
 by our external relay to reject external FAX requests.]

I have set up fax.amd.com as a CNAME to tetsuo.amd.com.  On tetsuo,
there is a hook in sendmail (5.65c+IDA1.4.1 w/custom cf) to direct mail
to a gateway if the domain part if fax[.amd.com].

The problem is that most sendmails (including my internal and external
relays) will resolve fax[.amd.com] back to tetsuo.amd.com.  If mail 
passes through one of these sendmails, the domain part can no longer 
be used to determine local versus fax delivery.
[Could always use @fax:user@fax but that is not at all pretty.]

An alternate route might be to determine fax delivery if the (local)
address looks like a phone number.  One would define a class of digits
and test for them.  The problem is that digits are (rightfully so!) not
considered token delimiters (see Do) so the entire number will likely
be tokenized into a single token.  Obviously, defining a class of all
possible phone numbers is not reasonable.  Likewise, it seems that 
redefining Do to use digits as token boundries would be a bad idea.
What would be great is a way to say (token composed of chars within
class X).  I don't think this is possible, correct?

Certainly, other postmasters have run into this situation before.
If there is interst, I will summarize back to this group.

		--Chris
--

Chris Martin                                      chris.martin@amd.com
Advanced Micro Devices; Sunnyvale, Ca.; U.S.A.    408/987-9047
Newsgroups: comp.mail.sendmail
From: rich@tsmnet3.uucp (Richard Martin)
Subject: sendmail problem
Organization: E-Systems, Melpar Division
Date: Wed, 14 Oct 1992 19:32:04 GMT
Followup-To: rich%melpar@uunet.uu.net
Summary: SCO sendmail trouble
Keywords: sco sendmail unix uucp

I would like some opinions on how we should set-up our mail gateway machine.

We have a tcp/ip network with with quite a few SCO UNIX 3.2.2 boxes running
sendmail. We have a connection to uunet through one of the SCO machines 
and need to configure the mail gateway machine to talk uucp (!)
for mail to uunet and tcp (@) for mail to all of the machines in our
network.  It all works except that the address are getting corrupted
when jumping from tcp to uucp and back. 

I would appreciate any suggestions or comments...

Thanks..

Rich Martin
E-Systems, Melpar Division
Falls Church, VA
...uunet!melpar!rich
rich%melpar@uunet.uu.net


Newsgroups: comp.mail.sendmail
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: UUCP addresses rewritten?
Keywords: UUCP
Organization: Bruce Lilly
Date: Thu, 8 Oct 92 22:40:47 GMT

In article <1992Oct7.125234.16369@netcom.com> kimc@netcom.com (Kim Culhan) wrote:
>   ----- Transcript of session follows -----
>bad system name: w3vh
^^^^^^^^^^^^^^^^^^^^^^
>uux failed ( 68 )
 ^^^^^^^^^^
[...]
>Any ideas?

It looks like uux is complaining that it doesn't know how to send
(directly) to a UUCP site named "w3vh". Probably that site is
not directly connected to yours.

If that's the case, you'll need to have sendmail rewrite the
envelope address passed to uux so that it is a bang path which
starts with a neighboring uucp site. An alternative is to
rewrite the address as "user%w3vh.UUCP@some_gateway" where
"some_gateway" is a willing Internet-to-UUCP gateway, and then
forward the message via SMTP to that gateway (assuming you have
a network connection, and also assuming that "w3vh" is a
registered UUCP site).
-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce
Newsgroups: comp.mail.sendmail
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Missing From: Header
Organization: Northern Illinois University
Date: Mon, 12 Oct 1992 11:24:52 GMT

In article <1992Oct12.100825.1201@lynx.dac.northeastern.edu> tmetro@lynx.dac.northeastern.edu (Thomas Metro) writes:
>I've noticed that I'm getting local mail with headers like this:
>> From a-local-user Sun Oct 11 21:18:11 1992
>> Subject: Re: Your account
>> To: tmetro@lynx.dac.northeastern.edu
>> Date: Sun, 11 Oct 92 21:18:08 EDT
>> In-Reply-To: <no.id>; from "Tom Metro" at Oct 11, 92 6:33 pm
>> X-Mailer: ELM [version 2.3 PL11]
>Notice that there is no From: line.

Notice that there is no "Received:" line either.  I recommend you check
your 'sendmail.cf'.  There is probably a line "H?x?Received:..." where
"x" is some letter.  I recommend you delete the three characteres "?x?"
(with whatever character replaces "x" in the actual case).

>I'd like to know if this is normal behavior for either sendmail or ELM

Most likely your problem is caused by a bug in your delivery agent
/bin/mail, which is deleting the "From:" header.  Making the changes I
recommended above will put a "Received:" header above the "From:", so
that the bug will not be triggered.

Newsgroups: comp.mail.sendmail
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: testing of cf files
Organization: Bruce Lilly
Date: Sun, 11 Oct 92 15:50:04 GMT

In article <718657020@duke.cs.duke.edu> sls@duke.cs.duke.edu (Shelley L. Shostak) wrote:
>
>I am trying to use sendmail -bt (version 5.65) to "test" a cf file, but I
>cannot quite get the information I seek.  This is very simple.  I would like
>to see what and how it generates header lines.

Add debugging flag(s) -dn.m -- see the documentation for
IDA/UIUC sendmail, which (regarding the debugging flags) should
be about 95% accurate, even if you're not using IDA sendmail.
Alternatively, read the sendmail chapter in the book by Nemeth,
Snyder, and Seebass.

>  I don't really care about
>the recipient stuff, but I am concerned with sender info, the From: and
>Return-Path: fields.

In that case, probably the easiest thing to do is to send
yourself a message, and look at the sender fields.

>  For instance, if the "C" flag is defined for a
>mailer, you are SOL, because ruleset 3 strips off the domain and you cannot
>get it back on before the S/R rulesets or fudging the cf file to append one
>in all cases.

Ruleset 3 only does those things which are programmed into the
ruleset; if it's stripping off a domain, that's because your
configuration file is set up to do so.

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce
From: joltes@husc10.harvard.edu (Richard Joltes)
Newsgroups: comp.mail.multi-media
Subject: MIME-compatible mailers for Macintosh?
Date: 8 Oct 92 17:26:40 GMT
Article-I.D.: husc3.1992Oct8.132641.16173
Distribution: na
Organization: Harvard University Science Center

I'm hunting for a MIME-compliant mail client, preferably using IMAP (POP is the
second choice) for access to a UNIX server.  Does anyone know of one that's
either in development or already available?  Public domain or commercial are
both okay, but the former is obviously preferable.

Thanks,

--------------------------------------------------------------------------------
Dick Joltes						joltes@husc.harvard.edu
Hardware & Networking Manager, Computer Services 	joltes@husc.bitnet 
Harvard University Science Center

"Mind you, not as bad as the night Archie Pettigrew ate some
sheep's testicles for a bet...God, that bloody sheep kicked him..."
Newsgroups: comp.mail.multi-media
From: "David Herron" <david@twg.com>
Subject: Re: Mass market MIME based e-mail question
Sensitivity: Personal
Encoding:  43 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Wed, 14 Oct 1992 20:54:09 GMT

In article <1992Oct13.113431.7685@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>MIME is just a content encoding. The mail packages you mention are all 
>transport mechanisms as well. So you would have to run MIME over something,
>like POP2/POP3/IMAP2/IMAP3/..., and these protocols are not stable enough
>to be attractive to many commercial vendors, I suspect. 

Nope.. wrong.. these protocols are too stable enough ;-).  Though your
inclusion of IMAP v3 into that list isn't correct since the RFC which
is labeled IMAP v3 is not part of the Official IMAP development stream.

And as the fellow from CMU said, they're not working on replacing it
but on developing a protocol which handles mail management things
which the IMAP authors feel do not belong in IMAP.

Our MTA supports both POP3 and IMAP2, but we prefer IMAP2.  It allows
for delivery of messages while the folder is open, allows for
multiple folders on the servers, and allows us to store status
strings in the messages so we can track which have been read/answered/etc.

>Of course, each of these protocols is IP-based, which
>has its own problems in the PC/Mac environment,

Oh?  Just buy a TCP/IP implementation for your system.  There seems
to be dozens of companies with 'em ... ;-)

ptrubey@netcom.com (Phil Trubey) writes:
>What is P7?

P7 is part of the X.400 protocol suite.  It is sort of equivalent
to POP in capability.  It is mostly a maildrop, but does have some
intelligence in the entity which handles the maildrop as delivery
notification messages are to be generated there.  It doesn't allow
for more than one folder or any other sort of message grouping
in the P7 server.

I don't understand why a P7 server using MIME is a cool/nifty idea ...
MIME is a cool/nifty idea by itself regardless of which mailbox access
protocol you use.  But the X.400 world already has its own multi-body-part
standard so why would they want to use MIME?

And .. talking about reliable servers .. Why would a P7 server be
more/less reliable than, say, an IMAP server?


<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
Newsgroups: comp.mail.multi-media
From: martin@alba.UDAC.UU.SE (Martin Wendel)
Subject: MIME (RFC1341) Charset question
Keywords: MIME Charset
Organization: UDAC, Uppsala, Sweden
Date: Thu, 8 Oct 1992 13:28:24 GMT

RFC1341 specifies that legal values of charset are those registered
with IANA as MIME character set values. It is also required that
they are reviewed and approved by the IAB. Initially, RFC1341 
allowes use of US-ASCII and ISO8859-[1-9]. Surely the 8859 charsets 
are rich enough for them to be used by many languages, although not by 
all.

I see a problem, though, when a message is originally created with
characters that doesn't fit into one of the 8859 charsets but could 
be squeezed into two or more. Is it the intent that such a message 
should be of content type multipart/mixed? 

Then, what about characters not in any one of the 8859's?

Finally, why not use mnemonics? That would eliminate the need for
the quoted-printable content-transfer-encoding.

BTW what charsets aside from US-ASCII and ISO8859-[1-9] have been
accepted as standard MIME charsets?
--
______________________________________________________________ 
E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC
       Domainmaster@UU.SE                     Martin Wendel
       Postmaster@UU.SE                       Box 174
Tel:  018 - 18 77 80                          S-751 04 Uppsala
Int: +46 18 18 77 80                          SWEDEN
Fax: +46 18 51 66 00
______________________________________________________________
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.multi-media
Subject: Re: Mass market MIME based e-mail question
Date: 13 Oct 92 11:34:31 GMT
Organization: U of Cambridge, England

In article <1992Oct13.054709.22181@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>Am I missing something here?  Why is it that I seem to be the only person
>who thinks that MIME based e-mail packages can take on the very profitable,
>yet proprietary mass market e-mail packages like Microsoft Mail (aka Network
>Courier), Lotus cc:Mail, Da Vinci E-Mail, etc?

MIME is just a content encoding. The mail packages you mention are all 
transport mechanisms as well. So you would have to run MIME over something,
like POP2/POP3/IMAP2/IMAP3/..., and these protocols are not stable enough
to be attractive to many commercial vendors, I suspect. IMAP2bis is pretty
new and even now they seem to be talking about replacing it with something
from Carnegie-Mellon. Of course, each of these protocols is IP-based, which
has its own problems in the PC/Mac environment, such as requirements for
packet/NDIS/ODI drivers (and IP/IPX multiplexers if necessary, etc. etc.),
and RARP/BOOTP servers etc. And isn't MacTCP a commercial product?

What might be interesting is a PC-based MUA talking P7 and using MIME as
a content-encoding.
Newsgroups: comp.mail.multi-media
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Subject: Re: Rearranging lists & newsgroups
Organization: U of Cambridge, England
Distribution: inet
Date: Fri, 9 Oct 1992 19:16:47 GMT


I think both MIME, and MIME futures, are suitable for comp.mail.multimedia.
After all, the really tricky problems that affect MIME, i.e. that are going
to lead to long discussions (e.g. the debate about PostScript), have
implications for all multimedia mail, indeed document interchange generally.

It would be nice if some indication of how the MIME futures debate is
progressing could be posted to the public group. I don't have time to get
_involved_, but I do want to _know_ about it. It sounds selfish - but
multimedia mail is only 1% of my job! Perhaps a monthly digest?
From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein)
Newsgroups: comp.mail.multi-media
Subject: Re: MIME (RFC1341) Charset question
Date: 9 Oct 92 13:47:22 GMT
Distribution: inet
Organization: The Internet

Excerpts from mail: 8-Oct-92 Re: MIME (RFC1341) Charset .. Jon
Postel@ISI.EDU (98)


> I'd like to see a move to unify MIME charactersets with those listed in
> RFC-1345.

Well, I'm not sure what you mean by "unify".  MIME has been strongly
biased towards keeping the number of charsets as low as possible, while
RFC 1345 provides a fairly exhaustive survey of what character sets are
in use.  I think it would be a mistake if MIME provided a blanket "seal
of approval" for ALL of those character sets -- the fewer redundant
character sets, the better, in my opinion.  However, if all you're
saying is that the character sets that DO overlap should be called by
the same name in the two documents, I certainly have no problem with
that!  -- Nathaniel