ietf-822
[Top] [All Lists]

Re: MIME types for ack[-request]?

1992-03-27 01:13:39
Keith,

2.  I strongly prefer that any ack requests be implemented in the SMTP (or
other) envelope.  Putting this stuff in the header is a opening a BIG can of
worms.  In particular:

This seems to address the MTA-MTA type of ack that Dave referenced.  
Personally, I believe this to be a bad idea.  If we were to assume that all
822 mail is delivered via SMTP and in one hop, this might be useful.  Since
it does not reflect how much of the 822 mail gets delivered, I question how
useful putting this kind of functionality into SMTP is.  The model further
breaks down when looking at the behavour across gateways.

* When messages are auto-forwarded around from place to place, the envelope
addresses change while the header addresses (and especially the contents of
MIME body parts) do not change.  The ack requests then become useless.

I'm not sure how this is a problem for the vast majority of cases.  Sure, 
there will always be some relay sites that screw around with headers and
break things, but it seems that this is becoming less of a problem in recent
years (especially with greater acceptance of domain style addressing).  We 
have been using this type of functionality for many years now, and my 
experience is that this type of problem is *extremely* rare.

* It is necessary to mark such headers somehow once they are processed to
make sure that a message doesn't generate multiple acks as it is "delivered"
to lists and gateways.  This violates a widely-held assumption that message
headers can be ignored by message transport.  Acks-in-headers *requires* any
MTA that supports mailing lists to deal with an ack-request bodypart, either
because it wants to issue the ack when the message is expanded (almost
always the right thing to do). It can't simply forward the ack request to
the list members, because the membership of a list may be confidential.

Most properly functioning internet mailing lists do this today anyway.  It is
necessary among other reasons, to redirect error messages generated by a 
transport back to the list maintainer rather than the originator of the
message.  Yes, to properly handle acks will (optionally) require some 
enhancements to these list exploders, but it does not in any way change
existing practice.

* Finally, if ack-requests are implemented in the headers or in MIME, there
is no assurance that an ack will be generated, since many MTAs and UAs will
continue to ignore MIME.

This is true regardless of whether the ack's require MIME or not as long as
they are represented as 822 extentions of some type.

                          However, if acks are implemented in SMTP, the SMTP
negotiation for the ack can be used to determine whether the receiver SMTP
supports delivery acks.  If not, an "partial" ack can be generated, which is
still more useful than no ack at all.  With ack requests in SMTP, you have a
high probability of getting *some* useful answer to every ack request, that
can be processed mechanically.

And what happens when there are multiple relay sites involved?  What about
if an intermediate hop is via UUCP or some other transport?  How is the
information returned (if any) in these situations useful?

Putting acks in SMTP also allows a mailing list exploder to "probe" a list
to determine whether list recipients are valid.

Hmm..... if I remember the internet lists I maintained while at LLNL, we had
recipients on BITNET, CSNET, and many other networks as well.  Many went
through multiple gateways before arriving at the final destination.  In 
addition, many of the entries were sub-lists with remote expansion points.  
How will this "probe" functionality work for these cases?

Best Regards,

Tim Kehres