james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Goggerle <andreas.goegge...@pansoft.de>
Subject RE: More info from bounces
Date Tue, 02 Sep 2003 10:13:15 GMT
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
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
Personally I would prefer this new bounce-architecture.
So what does the community say? Which way should I go?


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

View raw message