Serge, Soren and Andreas,
Soren just committed the change with Serge's modifications. Did we ever get
the DSNBounce Mailet?
Reviewing the change change, two things occur to me:
1 - there is a "bug" -- actually more of a limitation.
Quoting RFC 3464:
A DSN can be used to notify the sender of a
message of any of several conditions: failed
delivery, delayed delivery, successful delivery,
or the gatewaying of a message into an environment
that may not support DSNs.
The patch handles only bounces and not other types
of Delivery Status Notification types.
2 - It seems to me that the original DSN (as in Delivery Status
Notification) seems more general than "Bounce." I would
change delivery-error to delivery-status. The processor
could be ... <notificationProcessor> ?? Just to prepare
for when we do support more than just error notices.
I have not made any change for either. Would consider changing for #2, and
would not want to touch #1 until post release, although if someone else has
the time, please feel free to look into it.
By the way, due to an error on my part (failing to do a cvs up before a
build), this change did NOT make it into a16. It will be in a17.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 27, 2003 22:21
To: James Developers List
Subject: Re: [PATCH] RemoteDelivery and new DSNBounce Mailet
Andreas,
Two things...
1. You only attached the RemoteDelivery patch, not the DSNBounce mailet.
2. The change to remote delivery... other people have requested handling
how bounces work, so I might suggest we make this more generic.
Basically the code would stay the same, just remove the DSN-specific
naming, e.g., configure a <bounceProcessor> and store the exception as
the delivery-error.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
Andreas Göggerle wrote:
> Hi,
>
> finaly I got time to get things ready.
>
> This Patch to RemoteDelivery introduces a new parameter <dsnProcessor>.
> Here you can specify a processor, where DSN conform Bounces are created.
> If this parameter is missing, mails get bounced the "old way".
>
> Here is a configuration example:
>
> <processor name="transport">
> [...]
> <mailet match="All" class="RemoteDelivery">
> [...]
> <!-- Processor for DSN creation -->
> <dsnProcessor>dsn</dsnProcessor>
> </mailet>
> </processor>
>
> <processor name="dsn">
> <mailet match="All" class="DSNBounce">
> <!-- sender defaults to postmaster -->
> <sender> [EMAIL PROTECTED] </sender>
> <!-- Subject Prefix (default=Re:) -->
> <prefix> ERROR: </prefix>
> <passThrough> false </passThrough>
> </mailet>
> </processor>
>
> The DSNBounce Mailet creates Bounce Mails in the format specified by RFCs
> 3462
> to 3464. There is only one discrepancy: the MIME-type "text/plain" is used
> for
> the status-report part, instead of "message/delivery-status".
> JavaMail doesn't support "message/delivery-status".
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
