Andreas Goggerle wrote:
My first approach was to implement it into the existing bounce methods.
But having a mailet responsible for creating DSNs also seems to be a good
idea.
Personally I would prefer this new bounce-architecture.
So what does the community say? Which way should I go?
I can see th
Hi Noel,
> 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?
We extended James with a service called fetchdb that reads a
mailjob-database and produces mails
.
--- 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 mes
age-
> 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 me
Attached is a VERP class which basically has a simple embedded matcher
framework. The provided implementation uses regex parsing.
The code comes with a driver containing VERP examples in ASF-style, original
djb style (http://cr.yp.to/proto/verp.txt), and Jason's iNovem-style.
Mark might consider
t; Subject: Re: More info from bounces
>
>
> Noel J. Bergman wrote:
> >>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
>
I think it would be a cold day in hell if Lotus or MS give you good quality
error codes...
-- Jason
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]
> Sent: 31 July 2003 14:26
> To: James Developers List
> Subject: Re: More info from bounces
>
>
&
Noel J. Bergman wrote:
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, a
Noel J. Bergman wrote:
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
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.apac
I vaguely remember discussing this, but don't remember if anything
conclusive was reached. I'm trying to hack together a VERP system (send
emails with unique return-path so I can see which messages were
undeliverable), and the challenge I have is the exact error message is
buried deep in the m
11 matches
Mail list logo
