You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2004/03/26 06:20:09 UTC
RE: [PATCH] RemoteDelivery and new DSNBounce Mailet
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:sergek@lokitech.com]
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. sergek@lokitech.com
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> JamesMailserver@domain.tld </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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery and new DSNBounce Mailet
Posted by Soren Hilmer <so...@tietoenator.com>.
Ignore the last mail!!
For some reason my mail-client decided to resurrect some old mails and put
them in the outboks ;-(
--Søren
On Friday 26 March 2004 11:29, Soren Hilmer wrote:
> Hi Noel,
>
> Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons
> why I have not committed it.
>
> i) It does not compile under 1.3 because:
> a) Uses Java's regular expressions (have fixed that)
> b) Uses InetAddress.getCanonicalHostName (I am still deciding on how
> this is best handled, either close your eyes and use getHostName, or extend
> and use our DNSServer).
>
> ii) It uses text/plain instead of message/delivery-status as Content-type
> for the dsn message. This should be easy to resolve, given Steve Brewin's
> code.
>
>
> I then decided that splitting the commit up, so the bounceprocessing
> feature was separately comitted to RemoteDelivery made sense, at least that
> way developers have the hook they need to do custom bounceprocessing.
>
>
> --Søren
>
> On Friday 26 March 2004 06:20, Noel J. Bergman wrote:
> > 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:sergek@lokitech.com]
> > 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. sergek@lokitech.com
> >
> > 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> JamesMailserver@domain.tld </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: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery and new DSNBounce Mailet
Posted by "Noel J. Bergman" <no...@devtech.com>.
Søren,
Thanks for the update. :-)
> Yes, we did get the DSNBounce mailet from Andreas
Great. I had looked in my archives, but I couldn't find it.
> i) It does not compile under 1.3 because:
> a) Uses Java's regular expressions (have fixed that)
> b) Uses InetAddress.getCanonicalHostName (I am still
> deciding on how this is best handled, either close
> your eyes and use getHostName, or extend and use
> our DNSServer).
For now, I would use:
getMailetContext().getAttribute(Constants.HELLO_NAME)
and we'll address it further later. So that takes care of JDK 1.3 issues.
:-)
> ii) It uses text/plain instead of message/delivery-status as
> Content-type for the dsn message. This should be easy to
> resolve, given Steve Brewin's code.
Cool. Then let's do it. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery and new DSNBounce Mailet
Posted by Soren Hilmer <so...@tietoenator.com>.
Hi Noel,
Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons why
I have not committed it.
i) It does not compile under 1.3 because:
a) Uses Java's regular expressions (have fixed that)
b) Uses InetAddress.getCanonicalHostName (I am still deciding on how this
is best handled, either close your eyes and use getHostName, or extend and
use our DNSServer).
ii) It uses text/plain instead of message/delivery-status as Content-type for
the dsn message. This should be easy to resolve, given Steve Brewin's code.
I then decided that splitting the commit up, so the bounceprocessing feature
was separately comitted to RemoteDelivery made sense, at least that way
developers have the hook they need to do custom bounceprocessing.
--Søren
On Friday 26 March 2004 06:20, Noel J. Bergman wrote:
> 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:sergek@lokitech.com]
> 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. sergek@lokitech.com
>
> 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> JamesMailserver@domain.tld </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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org