Re: Return Receipts

Re: Return Receipts

[Lars Magne Ingebrigtsen]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.

Simon Josefsson <jas@extundo.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> James McNaughton <jtm63@enteract.com> writes:
>>
>>> According to http://www.sendmail.org/~ca/email/dsn.html the delivery
>>> status notification is part of the MTA but receipt notification
>>> (e.g. I fetched the message from my mailbox) is the responsibility of
>>> the MUA [Ref. RFC2298 linked on the same sendmail page]. The web page
>>> lists some MUAs which are supposed to do it.
>>
>> "Return-Receipt-To" was (the last time this was discussed)
>> deprecated, so Gnus doesn't support if.  If it has been undeprecated
>> now, then we should take another look at it.
>
> RRT seems to be "nonstandard, but widely used" (RFC 1894), MDN (RFC
> 2298) seems to be to blessed version of it.  DSN (RFC 2852) is a
> SMTP-only thing.  Exmh and Netscape 4.5 supports MDN according to the
> webpage.
>
> Hm.  If MDN is implemented, it would be nice if the UI allowed the
> user to set his preference once and for all -- much like a popup
> buffer with explanatory text that asks "Do you want to return a
> receipt?  Yes/No/Always/Never" that hooks into customize.  Does anyone
> want to implement it?  I think it sounds fun, so I could do it.  DSN
> support could be fun as well.

I think this sounds like a good idea.  I've Cc'd this to the ding
mailing list, so we can see whether anybody there has any comments.
(Follow up to the mailing list only, please.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Return Receipts

[William F. Hammond]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes in gnu.emacs.gnus:

> I think this sounds like a good idea.  I've Cc'd this to the ding
> mailing list, so we can see whether anybody there has any comments.
> (Follow up to the mailing list only, please.)

(Hmmm ... If you had set "Followup-To: ding@gnus.org", would that have
suppressed followup to the newsgroup?)

Doesn't it pose risks if a user inadvertently opens spam?  For example,
does gnus know what w3 might do, much less what nonsense, as bandied
about elsewhere in this discussion, might show up in someone's mailcap?

The least of these might be a spammer who queues the user for more
spam every time a return-receipt comes in.

By the way, in my locale the postal service charges extra money for
return receipts.  There are indeed extra expenses.  It's just not
responsible use of the network.

Alternatively, it's very easy for a user to wire a keystroke to a
boiler-plate acknowledgement by writing a little elisp.  So maybe that
could be provided for users who want to be able to use a keystroke to
honor a return-receipt request.  If so, the request needs to be made
plain to the user, but, pretty please, no prompt, or, at worst, a
user configurable return-receipt-request display-mode like 0=hide,
1=show, 2=prompt.

                                    -- Bill

Re: Return Receipts

[Simon Josefsson]

hammond@csc.albany.edu (William F. Hammond) writes:

> Doesn't it pose risks if a user inadvertently opens spam?

DSN opens up to all kind of privacy threats, so it shouldn't be
enabled by default.  OTOH I think it might be useful in some
situations (especially if you are in a Windows environment where
someone expects you to return a receipt).

> The least of these might be a spammer who queues the user for more
> spam every time a return-receipt comes in.

There are some (limited) discussion about sanity checks that should be
performed in RFC 2289 (section 2.1).

> Alternatively, it's very easy for a user to wire a keystroke to a
> boiler-plate acknowledgement by writing a little elisp.  So maybe that
> could be provided for users who want to be able to use a keystroke to
> honor a return-receipt request.  If so, the request needs to be made
> plain to the user, but, pretty please, no prompt, or, at worst, a
> user configurable return-receipt-request display-mode like 0=hide,
> 1=show, 2=prompt.

Yes, a prompt like this could work.  A prompt is quite obtrusive
though, maybe just a button that says the sender requested a
notification, and you can press the button to send it.

One point of DSN is that the receipt is in machine readable format,
multipart/report, a boiler-plate acknowledgement wouldn't achieve the
same thing.

Re: Return Receipts

[William F. Hammond]

Simon Josefsson <jas@extundo.com> writes:

> hammond@csc.albany.edu (William F. Hammond) writes:
> 
> > Doesn't it pose risks if a user inadvertently opens spam?
> 
> DSN opens up to all kind of privacy threats, so it shouldn't be

DSN here corresponds to http://www.dsn.org/ , correct?

. . .

> >                               If so, the request needs to be made
> > plain to the user, but, pretty please, no prompt, or, at worst, a
> > user configurable return-receipt-request display-mode like 0=hide,
> > 1=show, 2=prompt.
> 
> Yes, a prompt like this could work.  A prompt is quite obtrusive
> though, maybe just a button that says the sender requested a
> notification, and you can press the button to send it.

I agree that an action-required prompt is very obtrusive.

A button would correspond to the value 1 below when emacs is running
with a viable mouse.  A more primitive form of 1 would be provided
for classical interactive terminals.

I intended to suggest a user-configurable variable such as this:

(defvar gnus-return-receipt-request-handling 0
"*Handling for DSN-related return-receipt requests in incoming items.
Meaning:  0 = Ignore all return-receipt requests.
          1 = Provide a styled display of the phrase
              \"Return Receipt Requested\"
              just after the displayed message headers and offer
              the function gnus-send-return-receipt in a non-obtrusive
              way.
          2 = Honor all return receipt requests.)


> One point of DSN is that the receipt is in machine readable format,
> multipart/report, a boiler-plate acknowledgement wouldn't achieve the
> same thing.

Agreed.

                                    -- Bill

Re: Return Receipts

[Simon Josefsson]

hammond@csc.albany.edu (William F. Hammond) writes:

>> > Doesn't it pose risks if a user inadvertently opens spam?
>> 
>> DSN opens up to all kind of privacy threats, so it shouldn't be
>
> DSN here corresponds to http://www.dsn.org/ , correct?


No, Delivery Status Notification -- RFC 2298.

> A button would correspond to the value 1 below when emacs is running
> with a viable mouse.  A more primitive form of 1 would be provided
> for classical interactive terminals.
>
> I intended to suggest a user-configurable variable such as this:

Yes, it should work something like that.  (Altough using values `ask',
`never', `always' such as other parts of Gnus is probably better.)

Re: Return Receipts

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> DSN opens up to all kind of privacy threats, so it shouldn't be
> enabled by default.  OTOH I think it might be useful in some
> situations (especially if you are in a Windows environment where
> someone expects you to return a receipt).

I've given RFC2298 a quick glance, and I thought about it a few
seconds more, and I just don't feel that this is something that users
will want to use.  I certainly wouldn't.  So I'm not going to
implement this, but if you (or someone else :-) wants to implement
this, it'd be fine by me.

(Just to make sure you hadn't already implemented this, I grepped
through the sources for "notification", and I see there's a function
for inserting a Disposition-Notification-To header, but not much
more.  When fetching mail, Gnus should probably be parsing these
receipts, and marking, er, archived messages as having received
notification that they have been received?  Or something?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen