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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]