RE: More info from bounces

[Andreas Goggerle <an...@pansoft.de>]

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 with job-id and user-id of
the recipient coded into the Reverse-Path (->VERP)

Then I match for mails adressed to this Reverse-Path and hand them
to a BounceHandler-Mailet.
Until now, I do a lot of string-parsing over all multiparts of the
bounce-mail to guess the bounce-reason. With a standard DSN mail
this will be much easier and much more reliable.

> 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

Yes, I think it should be added to LocalDelivery too. Just sticking the
mails to the error pipeline for getting them returned isn't that nice ;)
The idea of a DSNProcessor sounds good, especially if you want to have
the full "SMTP Service Extension for DSNs" (RFC3461) implemented step by
step.
I will implement RFC3464 for error reports, but I'm afraid that I can't do
the rest of RFC3461, at least at the moment.
In this way, we'll get an easy to modify bounce-mailet, that is independent
to the James core, fully customizable and easily extensible.

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?

Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: More info from bounces

[Serge Knystautas <se...@lokitech.com>]

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 the justification for a richer bounce architecture.  Feel free 
to propose.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org