🚀 go-pugleaf

In article <BzxoGE.FIB@iron.hq.aflc.af.mil> hanrahan@iron.hq.aflc.af.mil (Kevin Hanrahan) writes:
> 
> 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.

I could not agree more.  Over the past few years, I have attempted within
the IETF to generate some interest in this, and have been unable to make
any progress.  My position is that there really needs to be two separate
mechanisms in place - one for UA return receipts, and a delivery 
acknowledgement mechanism that the final delivery agent can use to notify
the originator that the message has been delivered.  In addition, the 
mechanisms need to operate across gateways, hence cannot be tied to any
particular transport mechanism.

> >My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
> >successful delivery, since it has some utility and is also not going to go
> >away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
> >would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
> >ONLY the MUA) when the message is actually read.
> >--
> >Steve Dorner, Qualcomm, Inc.
> 
>    I would tend to agree with your leaning, but several SMTP compatible
> mail packages already implement "Return-Receipt-To:" as a read
> receipt (Control Data's ASCENT*Mail is one of these and is widely
> used in the U.S. Air Force).  I had the pleasure of hacking "elm"
> to recognize and implement this header for an Air Force customer
> who demanded this capability and desired compatibility with
> existing systems.

I would have to disagree with the use of Return-Receipt-To.  As the person
that wrote the code for the return receipt functionality in the LLNL EM
code (which ASCENT*Mail is derived from), I am somewhat familiar with what
went into the decision to use Return-Receipt-To.  :-)  We had a strong desire 
on the part of the Air Force to be able to determine when a message arrived
at it's destination.  Upon further discussions with the client, we found
that what was really desired was an ability for the sender to know when
the message was sucessfully delivered to the recipient - in other words
a devliery report, *not* a return receipt.  Unfortunately, we were unable
to generate our own header fields, so we had the option of using X- fields
for new functionality or overloading Return-Receipt-To.  We chose to do the
latter, and provide both functions as the result of a single request.

To make this work properly, two things were also done - we first supplied
our own version of sendmail, with the return receipt code torn out.  In 
addition, we had our own local mail delivery program, which was responsible
for the generation of delivery notifications reports.   The later was a major
win, since very few people seem to be able to tell the difference between
a sendmail delivery report (what it improperly calls a return receipt), and
an error message.  The new delivery agent, which really is the only agent
capable of determining the status of final delivery anyway, produced a 
clean, and simple delivery report.

In looking back on what was done, it probably would have been better to 
just define two new X- fields for return receipt and delivery acknowledgement
use.  Sendmail is badly broken when it comes to this stuff,  and it is
impractical to think that we will be able to get good fixes out to many of
the existing locations.  For that reason, if Return-Receipt-To was chosen
as the basis for either function, it would only add more confusion to end
users.

>   My recommendation on this subject however, would not be to
> try to formalize the "Return-Receipt-To:" header (or create
> a Read-Receipt-Header), but instead to attempt to take advantages
> of MIME, which is now gaining rapid popularity.

Either way, a new header type needs to be defined.  I don't really see
any good reason why return receipt/delivery notification functionality
needs to be tied to MIME.  How am I going to tell users that they can
only request one of these functions if the other side is running MIME
compliant UAs and delivery agents?  What do we really gain here?  We 
certainly lose the ability to use these services in environments and/or
messages that are 822 compliant but not MIME compliant, which still make
up the majority of messages in the Internet.  If we are to impliment 
smarter delivery agents, it also unnecessarily complicates that code if
they have to deal with anything more than the 822 header.

Best Regards,

Tim Kehres