[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic