🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.mail.headers
Article #208

Re: Return-Receipt-To & forwarding...

#208
From: Erik Naggum
Date: Thu, 31 Dec 1992 00:30
56 lines
3582 bytes
[Neil Rickert]
|
|   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.

Good point.  In the postal services world, you normally don't read
registered mail before you sign and acknowledge that you have received
it, but it would be stupid not to read such mail.  The current "state of
the art" in mail software [1] is perpetrating this exact stupidity by
not presenting the envelope of the message and asking for some kind of
acknowledgement _before_ sending off a receipt.  Of course, this would
require the whole UA-MTA or UA-MS song and dance that X.400 has been
promising to entertain us with for years, since it depends on the UA's
access to the message store (pardon the jargon), and if that is a file
that the user can just go ahead and read with cat, it's meaningless.

Then there's the user side of this issue: if I got mail that required me
to state that I, personally, had received it, implying that I would read
it, I would automatically reject all such mail.  I already refuse to
answer mail addressed to me with bang paths in the To or Cc headers, or
with "uucp" used as a top-level domain, and think that people who use
Return-Receipt-To have already received a reply to their letter so they
don't need one from me, too.

While I'm at it: Has anyone else noticed that whenever there is a Mailer
or X-Mailer header in a message, it doesn't conform to RFC 822 or its
amendments?  It's nice of those who depart from the standards to inform
us that they do, but since IANA doesn't keep a register of alternate
message format standards, isn't this kind of useless?  I try to do some
intelligent search and retrieval on my mail (30+ MB is getting hard to
navigate in), and I have to have special filters for ELM, to try to undo
the damage that it does to headers and references (In-Reply-To has a
nuked date, and contains all sorts of junk), and some WinNET mailer has
an astrological date format that could mean anything.  Good thing I have
those Mailer headers so I can just ignore them, instead of getting lots
of stupid errors, or invent nifty AI routines to understand the headers.

Best regards,
</Erik>

-------
[1] The "current" state of the art in mail software seems to go one
month backwards for each new mailer written by some incompetent DOS
programmer who thinks that the mail format is so simple it can be
effortlessly parsed and implemented.  Why do these people never learn
from experience?  It's as if they have to invent the wheel from scratch
to use it, and never do anything with mail except stare at it.  Will
this change in 1993?  Will the U.S. federal deficit go away in 1993?
Will there be peace on earth in 1993?

--
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
Technical Details
Message-ID: <19921231.001@erik.naggum.no>
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!enag
References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <BzzGC8.4Gr@chinet.chi.il.us> <1992Dec30.192126.7969@mp.cs.niu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!enag
From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Message-ID: <19921231.001@erik.naggum.no>
Date: 31 Dec 92 00:30:01 GMT
References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <BzzGC8.4Gr@chinet.chi.il.us> <1992Dec30.192126.7969@mp.cs.niu.edu>
Reply-To: Erik Naggum <enag@ifi.uio.no>
Lines: 56