Re: [Evolution-hackers] Beginnings of Message Disposition Notification Support

[Not Zed <notzed ximian com>]

On Mon, 2004-09-20 at 13:33 +0100, James Ascroft-Leigh wrote:
> Hi,
>
> Firstly, congratulations on your latest wonderful release.
Thanks.
> I'm new to this list but I was reading a rather heated thread on the
> users list regarding "return receipts" and thought that I might have a
> shot at implementing support for this.
I kept thinking 'we've had a patch for this recently', and finally found it. 

http://lists.ximian.com/archives/public/evolution-patches/2004-August/006684.html

So cactus as cc'd on the bug had just about worked it out.  Unfortunately he didn't put the patch on the bug.  He mentioned something about going away/being busy, so he probably hasn't seen the followup yet.  All of the discussion has been on the patches list.

His patch is pretty complete, including processing receipt of the request, and user-interface stuff.

It would nice to be able to do it as an 'eplugin', but i don't think that can be achieved for various reasons.

> So far I have trivially added support for requesting the Message
> Disposition Notification's in the first place.  This takes the form of
> an "MDN Request" toggle option on the "Security" menu of the composition
> window.  When true at build_message time the extra header "Disposition-
> Notification-To:" is set to the same value as the "From:" header.
>
> When loading a draft message (e_msg_composer_new_with_message) the
> simple presence of this header triggers the setting of the mdn_request
> field of the new composer object back to true.
>
> I have not exhaustively tested this but a Mozilla Thunderbird understood
> what I was asking for and sent me a MDN back.  This is only a first
> attempt and I expect to find many issues I have overlooked but I thought
> you might like some input at this stage.  Feel free to correct me on any
> point and suggest alternative strings and/or UI structure.
>
> Regarding the more difficult generation of the MDNs, when a request
> comes in I was thinking of tending away from the user interfaces I have
> seen for this before.  Instead I was thinking of putting a tool bar
> button that shows a dialogue with tabs for the possible disposition
> types "displayed", "dispatched", "processed", "deleted", "denied" and
> "failed" (probably with the exception of "failed", though).
>
> Each tab would have a description the type for the user to choose.  The
> default tab would be whatever Lookout uses when it asks to send a read
> receipt (probably "displayed") and each would have a send button.  Bear
> in mind here that I have not read the IMAP-specific RFC yet.
I'm not sure what cactus's patch does, I think it just shows the mail itself.

So there may still be possible work to do to cross-reference the mail and the receipt, although i'm not really sure where that would fit in the scheme of things.
> I, personally, would hope to just never push that tool bar button but if
> you have to for whatever reason it is there for you to do so.
>
> Comments, suggestions, bugs and flames all welcome,
>
> James Ascroft-Leigh

--

Michael Zucchi <notzed ximian com> "born to die, live to work, it's all downhill from here" Novell's Evolution and Free Software Developer