Subject: RE: Argh. the spam.. make it stop...

From: Vernon Schryver <[email-masked]>
Date: Tue, 30 Mar 1999 12:49:29 -0700 (MST)

> From: "Larry Masinter" <[email-masked]>

> > What can such a client do with SMTP that cannot also be done with an
> > additional, initial hop through POP, IMAP or some other MTA-MUA protocol?
>
> ESMTP/DSN (RFC 1891).

As we've all known for the at least the last 20 years, during which such
mechanisms have been proposed and several times implemented, few would
knowingly turn on a mechanism that lets general senders know when or
whether they've read a message.  The BSD "Return-Receipt-Request" mechanism
is at the outer edge of what people will tolerate for good, sufficient,
and well known non-technical reasons.  They include the reasons why some
people refuse all U.S.Postal Service "registered" or "certified" mail,
and why many people refuse "registered" or "certified" USPS mail from some
senders.

However, that objection to the idea of DSN asside, I see nothing in RFC
1891 that limits the total number of end-to-end SMTP hops to one.  I would
not expect even the modern IETF to advance an RFC with such an idiotic
limitation.  In other words, adding an additional hop to what is likely
to be a multi-hop SMTP path cannot hurt any application that has any hope
of working.

Vernon Schryver    [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Tue, 30 Mar 1999 12:26:37 -0800 (PST)

On Tue, 30 Mar 1999 12:49 -0700, Vernon Schryver wrote:

> whether they've read a message. 

Agreed.

But DSN doesn't do that.  DSNs only tell senders when a message is
deposited in your mailbox -- not when the message is actually read.

MDN, RFC2298, do tell senders when a message is read, and the
specification also says:

   While Internet standards normally do not specify the behavior of user
   interfaces, it is strongly recommended that the user agent obtain the
   user's consent before sending an MDN.  This consent could be obtained
   for each message through some sort of prompt or dialog box, or
   globally through the user's setting of a preference.  The user might
   also indicate globally that MDNs are never to be sent or that a
   "denied" MDN is always sent in response to a request for an MDN.

which is honored by nearly every implementation.

> The BSD "Return-Receipt-Request" mechanism
> 1891 that limits the total number of end-to-end SMTP hops to one. 

You're correct - it doesn't limit the number of end-to-end SMTP hops.

> I would

Unless that first hop doesn't support DSN.

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Tue, 30 Mar 1999 12:26:37 -0800 (PST)

Agreed.

-Dan Wing

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Mar 1999 22:08:56 -0500

> and well known non-technical reasons.  

DSN is more-or-less equivalent to sendmail's ill-named "Return-Receipt-To" 
mechanism (i.e. DSN is a *delivery* notification, not a read- or receipt-
notification) except that DSN is done *correctly* - in the MTA-MTA 
protocol, NOT the UA-UA protocol.  (the latter is not only a layering 
violation, it has been known to contribute to sorcerer's apprentice syndrome).

If you were thinking of Message Disposition Notifications (MDNs), 
these are implemented by the user agent (not the MTA), so the UA can 
take appropriate measures to prevent abuse (like allowing the
recipient to set MDN policy, and asking the recipient for permission 
before sending the MDN).

> to be a multi-hop SMTP path cannot hurt any application that has any hope

depends on the nature of the hop.  ordinary MTAs get maintained and 
upgraded to support new SMTP options (most vendors support DSN now), 
but this is not necessarily true of MTAs performing as "firewalls" 
and similar boxes.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Mar 1999 22:08:56 -0500

Keith