[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Message Disposition Notification:  Second request for implementat
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-10-24 23:12:47
[Download RAW message or body]

On Friday 16 August 2002 14:02, Vaudreuil, Greg M (Greg) wrote:
<snip>
> If you can authoritatively respond on the capabilities of a
> contemporary implementation of this protocol, please reply to the
> questions below.

Sorry for replying so late, KMail just recently acquired compliant MDN 
send support.

> ----------------------------
>
> Please identify the following line-items in such a reply.
>
> 1) Name of software,

KMail

> vendor,

KDE Project, www.kde.org

> and version 

KMail 1.5.0 beta2/Kroupware
(temp. branch to develop a solution for the German government while HEAD 
is in feature freeze; will become KMail 1.6)

> upon which this response is
> based a) Approximately when was this feature introduced into a public
> release?

In a few days, though it's in a public CVS repository for a few weeks 
now.

> 2) MDN Requesting user agent behaviors
>
>   a) Client sends disposition-notification-to header:  (Y/N)

Y (On user request)

>   b) Client sends disposition-notifications-options header (Y/N)

N

>        b1) Client sends request for proprietay options (describe)
>   c) Message disposition header is placed in inner message when used
> with message partial (Y/N/NA) Please indicate N/A if the UA or
> gateway does not generate message partial constructs

N/A

< snip Final MTA behaviors>

> 4) MDN Generating UA
>
>   a) MDN report is generated upon request (Y/N).

Y (User can instruct to always send/ignore/deny or to ask)

> If yes, which fields are populated:
>         Reporting-UA
> 	   original-recipient-field
(if original-recipient is present in original message)
> 	   final-recipient-field
> 	   original-message-id-field
(if present in orig. message)
> 	   disposition-field
> 	   failure-field
(when "failed" is sent)
> 	   error-field
> 	   warning-field
Last two not yet used, but supported for when "error"/"warning" 
disposition-modifiers are present.
(snipped fields are not created)

> b) Which disposition modes are supported / generated:
> 	Manual action
> 	automatic action
>             MDN-sent-manually
> 	MDN-sent-automatically

All of them.

> c) Which disposition types are generated
> 	displayed
> 	deleted

both plus:
- "dispatched" on forward from filter action
- "failed" in case of "required" D.-N.-O. parameter.
- "denied" on user request.
- "processed" and all of the above from a filter action (user choice)

> d) Are any extension fields generated?

N

> 5) MDN Receiving user agent behavior

MDNs received are not treated specially yet.

> 6) Interoperability Experience
>
> Please list those implementations that are known to interoperate with
> this implementation.  Please describe what if any known
> interoperability problems are know with the MDN protocol and this
> implementation.

We respond correctly to Outlook2000-generated requests. ;-)
Seriously: since KMail doesn't parse received MDNs, interop is probably 
not a matter for us yet.

That said, we are not aware of any interop problems in this area.

Marc

-- 
Silent leges inter arma      -- Cicero

[Attachment #3 (application/pgp-signature)]
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]