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]