HDTenEightyP/NetNews huggingface dataset:
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Date: 3 Jan 1993 02:15:01 GMT
Organization: Oregon State University, College of Oceanography
NNTP-Posting-Host: skyking.oce.orst.edu

In article <davecb.726014848@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>   Mr. Stanley is raving mad (in the sense of angry, 

I am?

>not insane, 

Thanks. Is your psychology or psychiatry degree available for perusal on
the net somewhere, or are you making THAT up, too?

>but also consider fingering him and making up your own mind) 

What could fingering me have to do with how reliable mail isn't? It is,
however, proof that finger is not a reliable method of determining
whether mail has or hasn't arrived and whether someone has or hasn't
read it.

>and is arguing events which may well have taken place somewhere, some time.

Are you accusing me of lieing?

>They are seriously unusual and do not justify the establishment of the
>return receipt mechanism.

Would you please show me where I claimed ANYWHERE that it did?

>  York is the second-largest and second-cheapest university in Canada,
>and one of our three main mailhubs processes between 100 and 200
>thousand messages per month (see below). 

That's nice. Also irrelevant.

[lots of irrelevant x's deleted]

> It is a rare event and a major concern when messages go missing or
>unanswered in a given month: my job depends on the reliable operation
>of SMTP.

Wake up, Dave. SMTP is not reliable. The RFC that defines the protocol
has the goal of making it so, but real world implementations are hardly
reliable. And, here is something that might surprise you, the entire
world does not use SMTP. There are plenty-o-places where mail passes
over non-SMTP links. 

>  If memory serves, we had about three panics (searches for missing
>messages) last year, out of 1.8m+.  That still makes my blood run cold...

That's nice. Too bad that your users aren't educated enough about the
lack of reliability of mail that they would panic when a piece gets
lost. Of course, maybe more than three pieces got lost, and nobody but
those three people (one person three times?) got bent out of shape about
it because they knew how the real world works?
From: avolio@TIS.COM (Frederick M Avolio)
Newsgroups: comp.mail.headers
Subject: Re: Return-Receipt-To & forwarding...
Date: 31 Dec 92 14:41:20 GMT
Reply-To: avolio@TIS.COM
Organization: Trusted Information Systems, Inc.

In article <291@ima.com> kehres@ima.com (Tim Kehres) writes:
>One area that seems to generate a lot of concern is when it comes to UA's 
>taking it upon themselves to generate Return Receipts.  Most people, and
>some standards (like X.400) believe that this is unacceptable.   Whenever
>a return receipt request is detected by a UA, it should first get the approval
>of the user prior to sending out any notification.  As long as the user has
>control of how the UA will deal with return receipt notifications, I don't
>see much of a problem.  If they don't however, for me at least it would 
>represent an unacceptable invasion of privacy, and I would seriously 
>consider the use of another UA for this reason alone.


Among other things needed is a clearer definition or, more exactly, a
model to follow.  Clearly, this is not the model of Certified Mail in
the U.S. Postal System.  Certified Mail gets a return receipt sent to
the sender if the delivery agent delivered the mail.  Also, it gets
signed and stamped in an official, trusted manner.  

1. Certified Mail -- the compliant MTA certifies delivery to the
mailbox.  There may be an option to have this be digitally signed by
the system to have a valid and acceptable time stamp (like a Post
Office rubber date stamp).  This transaction is between the MTA and
the sender and the receiver should not have to okay this.  It is
certifying delivery. ("I did too get the RFP response to you on time.
See?  Here's my certified delivery report with a certifiable digital
signature."  Side note.  Someone who worked for me once scrambled to
get something FAXed to a customer before the 5pm deadline.  Customer
the week later said "We didn't look at it.  It was FAXed to us at
5:45PM -- not before 5pm!"  well...  No one had changed the clocks on
our FAX machines nor had anyone changed the clocks on theirs when
daylight savings time ended.  Easy to verify since they still
hadn't....  Did you change YOUR FAX machines? :-))

2. Read Receipt Requested.  The compliant UA should indicate "A Read
Receipt was requested.  Shall I send one?"  For non-smart UA's, The
header line should indicate to the reader that they are being asked to
confirm their reading it.

F
Newsgroups: comp.mail.headers,comp.mail.misc
From: sdorner@qualcomm.com (Steve Dorner)
Subject: Re: Return-Receipt-To & Mailing lists
Followup-To: comp.mail.headers,comp.mail.misc
Organization: Qualcomm, Inc.
Date: Tue, 29 Dec 1992 13:13:49 GMT

In article <1992Dec29.075730.21796@lynx.dac.northeastern.edu>,
tmetro@lynx.dac.northeastern.edu (Thomas Metro) wrote:
> What should happen when crossing a gateway, and there is no equivalent to
> a "Return-Receipt-To:" or "Read-Receipt-To:" on the other side? Should the
> gateway send an appropriate message?

That depends.  If the gateway *knows* that the mail is never leaving the
receipt-less system, then perhaps it might.

  "Your mail was delivered to Blackholes 'R Us, which does not support
return receipts."

However, if there is a significant chance that the mail will emerge from
the other end (via a .forward kind of mechanism or something), then I would
think not.

Given my 'druthers, I'd leave this behavior unspecified.
--
Steve Dorner, Qualcomm, Inc.
Newsgroups: comp.mail.headers,comp.mail.misc
From: gordon@sneaky.lonestar.org (Gordon Burditt)
Subject: Re: Return-Receipt-To & forwarding...
Organization: Gordon Burditt
Date: Thu, 31 Dec 1992 18:19:41 GMT

>The AT&T packages that are more or less "on-line" and able to send at any
>time generate the receipt when the message is displayed on the screen
>(that is, the user selects "read").  The dial-up versions (access-plus
>and the windows and mac equivalents) generate the receipts as the messages
>are transferred out to the remote machine since they will be off-line
>as they are read.  The wording of the receipt is different to indicate
>the condition.

A friend of mine once wrote a popular (well, at least in the local
UUCP net of our employer) mail user agent which attempted to implement
read-mail-receipts, using Return-Receipt-To:.  

Various refinements occurred.  One social problem which happened 
rapidly was the use of the mailer to send mail from A to B and C with 
return receipts to D, E, F, G, and H, the return receipts being an 
intentional form of harassment.  It initially wasn't obvious to the
victims that A was the one doing the harassing.  A bug that got fixed 
pretty fast was that the "Return-Receipt-To:" header somehow wound up 
in the receipts, causing infinite receipt loops.  Various refinements 
were needed to the algorithm needed to determine "read", and eventually
the receipts started saying "read your message", "saved your message
to a file", "deleted your message without reading it", etc.  Some
people considered this an invasion of privacy (although many of
them didn't mind the original design).  Some of them discovered
how to provoke the mailer into issuing more than one receipt for 
the same piece of mail, and did so, frequently.  Someone who went
on vacation for a week was likely to end up with a megabyte of
receipts in his mailbox, even if he never sent a piece of mail
asking for a receipt.  The use of "more /usr/spool/mail/$USER" as
a mail reader increased greatly.

A big problem showed up when I used the mailer to examine a very large
file of archived mail, and it started sending receipts to all of
the hundreds of year-old-and-older messages.

Please try to design return receipts in a way that can't be used as
a weapon.

					Gordon L. Burditt
					sneaky.lonestar.org!gordon
Xref: sparky comp.mail.headers:373 comp.mail.misc:4091
From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Date: 25 Dec 92 21:58:52 GMT
Reply-To: Erik Naggum <enag@ifi.uio.no>

Return-Receipt-To is a kluge and a hack invented and first used by the
abominable sendmail program for BSD Unix.  It is not standardized,
neither as a header, nor as functionality.  No one has bothered to write
up a specification for it and submitted it as an RFC.  It's generally
considered a Bad Thing because (1) not all mailers implement it, so
absence of a returned receipt means nothing, and mail is not 100%
reliable, anyway, so even if a receipt is generated, it may not get back
to you, especially if headers get rewritten and the address in the
header is useless where generated, (2) it's often used indiscriminately
by those who use it all, causing much wasted bandwidth, and (3) it gives
users the impression that they can get a service that doesn't exist in
the Internet mail system.

'Tis best to ignore it entirely.

An argument could be put forth that it should be deleted, but this
requires some level of recognition of it, which is almost as bad as
responding positively to it.

Let's hope that 1993 will see a replacement for sendmail, and wide
deployment of real MTA software, to support 8-bit data paths, MIME, etc.
I might as well hope for the demise of X.400 while I'm at it.

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
Xref: sparky comp.mail.headers:400 comp.mail.misc:4186
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Date: 1 Jan 93 03:19:37
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
	<davecb.725771350@yorku.ca> <1992Dec31.180958.22688@chance.gts.org>
NNTP-Posting-Host: nutrimat.gnu.ai.mit.edu
In-reply-to: john@chance.gts.org's message of 31 Dec 92 18:09:58 GMT

In article <1992Dec31.180958.22688@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
>| Well, the historical reason this wasn't necessary/desirable/done is
>|called finger.
>
>[...]
>
>|  I regularly finger people, then look to see when my message was sent.
>|Result? I know if it was read.
>
>Actually, finger has the same problem as many existing read receipts,
>and return receipts: incorrect user expectation.
>
>Here Dave, a knowledgeable computer professional, arrives at a result
>that is simply not true, because fingerd does not (and can not) know
>if I have read my mail.

And here's one possible reason why finger may not be reliable: depending on
your backup method, the atime on spool files may be munged, and fingerd
will think the file has been "read".  True it has, but not by a user.  :-)

The latest version of GNU finger lets you customize what long output the
fingerer sees on a per-user basis.  So for me I've programmed it to look at
the mtime on my personal inbox.  As a matter of habit, when I incorporate
new mail and save my inbox I usually read it right then and there.

However, this still isn't a 100% reliable method.  Really, the best way to
find out if someone has read their mail is to ask in the mail message
"please send me a reply when you've seen this" (and if they choose not to
do this that's their business).  All this nonsense about UA automated
read-receipt replies is a waste of time.  People seem to think computers
are capable of solving all sorts of problems that they're not, particularly
when human capriciousness comes into play.
Newsgroups: comp.mail.headers,comp.mail.misc
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Return-Receipt-To & forwarding...
Organization: Northern Illinois University
Date: Sat, 2 Jan 1993 17:14:10 GMT

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
>defines, as I already pointed out, a positive acknowlegement scheme
>FROM THE SENDING HOST TO THE RECIEVING HOST.  If the mail doesn't 
>get there, I know about it because I'm doing end-to-end positive handoffs.

That statement should have been posted to rec.humor, not to a comp group.

You send mail to a user at host B.  Host B doesn't recognize its own
name, and thinks it must relay it.  It accepts the mail for forwarding
to its relay.  At this stage it disconnects, and you have your "positive
handoff" acknowledgement.  Now host B tries to send to its relay.  I
discovers that the relay doesn't exist.  It tries to bounce the message.
The bounce is sent to the relay.  But the relay doesn't exist, so the
bounce also fails.

This type of situation is quite common.  Newly installed machines just
out of the box often behave this way, and inexperienced administrators
may not notice the problem for several months.

Newsgroups: comp.mail.headers,comp.mail.misc
From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: Return-Receipt-To & forwarding...
Organization: ParcPlace Boulder
Date: Fri, 1 Jan 1993 22:47:43 GMT

In article <FRIEDMAN.93Jan1031937@nutrimat.gnu.ai.mit.edu>
friedman@gnu.ai.mit.edu (Noah Friedman) writes: 
>And here's one possible reason why finger may not be reliable: depending on
>your backup method, the atime on spool files may be munged, and fingerd
>will think the file has been "read".  True it has, but not by a user.  :-)

In addition, I use slocal to deliver my mail to an alternate mailbox,
where it may sit for a few seconds, or a few weeks.  There is no way
to automaically tell if I have really seen the message or not.  And
fingerd is certainly not going to have any clue about this at all.

I'd also like to point out that many systems do not have the unread
mail hack to fingerd.

>All this nonsense about UA automated read-receipt replies is a waste
>of time.

Yes.  People are also forgetting that even if they get a read-receipt,
it doesn't mean that I read the message.  For example, if the disk
crashes while I'm reading the message, but after the read-receipt got
sent out, then the user on the other end has now way to know that
fact.  In addition, return-receipt also suffers from the same problem,
but with a much larger window....

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.mail.headers,comp.mail.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Return-Receipt-To & forwarding...
Organization: York University
Date: Thu, 31 Dec 1992 03:09:10 GMT

sdorner@qualcomm.com (Steve Dorner) writes:
|I think it is high time that some form of standard return receipt were
|available in Internet mail.  It's one of the few functional areas where the
|Internet lags behind practically ever proprietary mail system, and X.400 to
|boot.

 Well, the historical reason this wasn't necessary/desirable/done is
called finger.   For those machines which supported the smtp and finger
protocols, one could usually discover if the recipient had undelivered
mail, or whether she had read it.

 Sendmail added return reciepts, but primarily for working through gateways...

  I regularly finger people, then look to see when my message was sent.
Result? I know if it was read.
 I already **know** it was delivered: I didn't get a ``599 mail undeliverable:
recipient had moved to mars'' message.

--dave

-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
Newsgroups: comp.mail.headers,comp.mail.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Return-Receipt-To & forwarding...
Organization: York University
Date: Fri, 1 Jan 1993 21:20:51 GMT

In article <davecb.725910818@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
|>Short answer: 
|>	Go read RFC821/2 (and consider yourself insulted).

stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
|You had better expand on that answer, for neither RFC appears to claim
|anything opposite to what I wrote. And, since both RFC's deal only with
|Internet standards, and since electronic mail can cross network
|boundaries to systems which have no requirement to use SMTP (much less
|obey Internet RFC's), neither can speak definitively on what I wrote.

|>Long answer:

|>	Mail is a reliable, end-to-end service, and must 

|Thanks for the laugh. You may think that mail is reliable, but that
|don't make it so. RFC 822 makes no mention of "reliable", and RFC 821
|mentions it in two instances, one of which specifies the use of a
|"reliable transport" mechanism. 

  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
defines, as I already pointed out, a positive acknowlegement scheme
FROM THE SENDING HOST TO THE RECIEVING HOST.  If the mail doesn't 
get there, I know about it because I'm doing end-to-end positive handoffs.
If I'm talking to a proxy (gateway) site, I get a 250 OK from the proxy,
and at that point it becomes that sites's responsability to do the same
with any further sites it contacts.  If it gets a negative acknowlegement,
it's its responsability to send me mail saying it didn't get through.
And that responsability is passed on to each intermediate site in turn.
Unless you use proprietary PC mailers, your mail uses RFC822 as a
format standard, and SMTP, BSMTP or UUCP as a transport.  SMTP and BSMTP
do exacly the above, and known UUCP mailers do the same.

  And the number of **formally unreliable** mailers can be counted 
on the fingers of a one-fingered man's hand.  Alas, he's growing more
fingers as we speak, due to the existance of erroniously specificed and 
designed PC mail programs.

if skyking.OCE.ORST.EDU is losing mail, you should speak to your
postmaster: you're on the internet too. 


--dave (all the world's not a vax, but
	Usenet, BITnet and the Internet ain't trivial) c-b
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
Newsgroups: comp.mail.headers,comp.mail.misc
From: LLONG@SJUPHIL.SJU.EDU (Your Full Name)
Newsgroups: comp.mail.headers
Subject: what 's RFC 822
Date: 31 Dec 92 20:02:41 GMT
Followup-To: comp.mail.headers
Organization: University of Pennsylvania

I am trying to find some information about mail file format documents.
Such as RFC-822, if you have some ideal about it. Please send me e-mail or
touch me by phone No. 215-387-1613.

The e-mail : llong@sjuphil.sju.edu

Thanks a lot.
Newsgroups: comp.mail.headers,comp.mail.misc
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: Return-Receipt-To & forwarding...
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Sat, 2 Jan 1993 21:25:36 GMT

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, ...

The reality is that it's a miracle that SMTP based mail works _at all_.
The complexity of the problem is astounding, but it does work for a 
large number of all the messages sent.  Peer-to-peer it may give some
degree of certainty, but apart from that it's like Neil Rickart described
in <1993Jan2.171410.30990@mp.cs.niu.edu>.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Xref: sparky comp.mail.headers:386 comp.mail.misc:4153
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Date: 30 Dec 92 19:21:26 GMT
Organization: Northern Illinois University

In article <BzzGC8.4Gr@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>
>The AT&T packages that are more or less "on-line" and able to send at any
>time generate the receipt when the message is displayed on the screen
>(that is, the user selects "read").  The dial-up versions (access-plus
>and the windows and mac equivalents) generate the receipts as the messages
>are transferred out to the remote machine since they will be off-line
>as they are read.  The wording of the receipt is different to indicate
>the condition.

This illustrates why I object to read receipts.  These so-call "read
receipts" actually certify that the mail has not yet been read, but
certain steps have been taken which normally precede the mail reading.

There ain't no such thing as an automatic read receipt, and there won't
be until we solve some problems in AI and in ESP (mindreading, for
example).
Newsgroups: comp.mail.headers,comp.mail.misc
From: barr@pop.psu.edu (David Barr)
Subject: Re: Return-Receipt-To & forwarding...
Organization: Penn State Population Research Institute
Date: Sat, 02 Jan 93 10:21:14 GMT

In article <davecb.725923251@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Your mail may be unreliable, but mine isn't: mine uses SMTP, which
>defines, as I already pointed out, a positive acknowlegement scheme
>FROM THE SENDING HOST TO THE RECIEVING HOST.

Sorry, I have to agree with John Stanley on this one.  In addition
to the scenario John mentioned, consider the following:

"user1@A" sends mail to "user2@B".  Mail for site B is handled by its
MX, C.  Therefore, site C is configured to handle all mail for B in
addition to its own.

1. user1@A's MUA hands off mail to A's MTA.
2. Site A's MTA connects to MTA at site C.
3. Site C receives mail, acknowleges its recept.
4. Site C's MTA connects to MTA at site B.
5. user2 dropped out of school and therefore is no longer a valid
   user at site B.  Site B nak's site C's delivery of mail with
   "user unknown".
6A. Due to a failure in the DNS configuration of site A, when site C
   tries to send a bounce to user1@A, it gets "host unknown" and
   site C promptly drops the bounce to the floor.
or
6B. Due to an improperly configured mailer at site A, the "From"
and/or "Reply-To" addresses are munged and unparseable.  Site C
drops bounce to the floor.
or
6C. Site C's /usr/spool/mqueue fills up and has insuffient disk space
in order to generate a bouce message.

What say you now?  Listen to John, you need to get out more.  SMTP may
be reliable, but SMTP is only a part of the picture, regardless of what
the pretty ASCII picture on page two of RFC821 says.  I suggest you
read the section "Reliable Mail Transmission" in RFC 1123, the
"Requirements for Internet Hosts".  Pay close attention to the words
"SHOULD" and "MUST".

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
#define ENOTTY          25              /* Not a typewriter */
Newsgroups: comp.mail.headers,comp.mail.misc
From:  avsht@sph.spb.su (Alex V. Shturm)
Subject: Return-Receipt-To & forwarding...
Reply-To: avsht@sph.spb.su
Organization: WinNet Mailer Post at Alex's home
Date: Sat, 19 Dec 1992 23:32:24 GMT

Hi netters!

My question is very simple.
Suppose I got a forwarded letter. The original letter
had the header "Return-Receipt-To", so the target system
has already generated and sent notifying mail.
Neverthenless this header came to my system as well.
Should my mailer send one more notifying message to the
author?

Thanks for any help.
References to standards (RFCs?) will be very useful.

Best regards,
/Alex

--
Alexander Shturm  ||  St.-Petersburg  ||  Internet: avsht@sph.spb.su
================  ||   Russia (xSU)   ||  FidoNet:  2:5030/8.18, /43.18
Tel.: +7-(812)-233-9148 (home)   +7-(812)-310-4631 (office)



Newsgroups: comp.mail.headers,comp.mail.misc