Andreas,
We would certainly like to see your code, and I would very much like to see
RFC 3464 implemented.
There are two sides of bounce management. James generating notices, e.g.
RFC 3464 DSNs; and James understanding bounces, e.g. ,DSN, VERP, etc. What
aspect(s) have you implemented?
Perhaps we should define a <DSNProcessor> element for RemoteDelivery. If
that has a value, RemoteDelivery would send messages with attached
attributes to that processor instead of doing an internal bounce. A <DSN>
element can control whether ALL messages are sent to the DNSProcessor,
PERMANENT failure, TEMPORARY failure, etc. The current implementation would
be equivalent to <DSN>PERMANENT</DSN>. Eventually we could deprecate the
bounce code, and make <DSNProcessor> a mandatory configuration element, with
<DSN> defaulting to PERMANENT.
Likewise, we could add them as optional elements to LocalDelivery, so that
positive DSNs can be sent.
--- Noel
-----Original Message-----
From: Andreas Goggerle [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 12:34
To: 'James Developers List'
Subject: RE: More info from bounces
Hi,
I just implemented a simple bounce management within James. The code parses
the James message Serge mentioned and detects soft and hard bounces. I agree
that this is not a nice way, so I would like to fix the bug 18309 Noel
mentioned. I will implement RFC 3464
(http://www.faqs.org/rfcs/rfc3464.html), which replaces RFC 1894.
I am no committer or contributer for James so far. Do you think there will
be a way to get my code placed in James?
Andreas
PANSOFT GmbH
Tullastr. 28
D-76131 Karlsruhe
Germany
Web: http://www.pansoft.de
Mail: mailto:[EMAIL PROTECTED]
> -----Original Message-----
> Von: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 31. Juli 2003 04:57
> An: James Developers List
> Betreff: RE: More info from bounces
>
>
> Serge,
>
> > the challenge I have is the exact error message is
> > buried deep in the message.
>
> > what about doing something like stick the error response
> > as a header in the bounce message?
>
> Obviously, we have no control over the content of another
> server's bounce
> messages, but see
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18309,
> which proposes that James implement RFC 1894
> (http://www.ietf.org/rfc/rfc1894.txt).
>
> > The motivation for this is to recognize soft bounces
> (mailbox full, mail
> > servers down) from hard bounces
>
> Servers should probably not be sending a bounce, or at least
> a non-RFC 1894
> bounce, for a soft error. VERP seems to be somewhat
> predicated upon bounces
> being permanent, at least for that message. To work around
> the fact that
> the errors may relate to a transient mailbox error, it seems that VERP
> mailers will be tolerant of a configured number of bounces,
> and will then
> send an "warning message" to inform the user. If the warning
> bounces, the
> user is disconnected from the list. That seems to describe
> the behavior
> I've seen from ezmlm, but Brian (or perhaps some of our
> members) would know
> better.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
