Noel J. Bergman wrote:
http://issues.apache.org/jira/browse/JAMES-444
What about have the feature configurable:
onExpires=off // default
onExpires=drop // discard expired mail without notice (my patch)
onExpires=bounce // or other actions??
If we were to introduce this into RemoteDelivery, it would be necessary only
because RemoteDelivery does its own internal queuing.
If you have not seen the discussion on server-dev@ for a new approach to
spooling, you may want to read the thread starting with Message-ID:
<[EMAIL PROTECTED]> in the archives. In brief,
part of that proposal includes moving rescheduling outside of the mailets
and to the processor boundary, allowing us more flexibility on what to
reschedule.
As a nearer-term thing, even in the absence of the additional work required
to change the spool store and wrap processors into transactions, if we can
allow you to have something like:
<processor name="RemoteDelivery">
<schedule>
...
</schedule>
<mailet match="Expired" class="[Null|Bounce|...]"
</mailet>
<mailet class="RemoteDelivery">
</mailet>
</processor>
would that satisfy your requirements?
Yes, great!
You can see my use case under
http://www.xmlblaster.org/xmlBlaster/doc/requirements/protocol.email.html#expires
here it could happen that if there was some network problem some 100000 ping
emails where queuing up in james (but only the most recent ping email is
of relevance)
and when the network recovered all 100000 emails flushed.
I did assume that Expires follows the time format
Expires: Thu, 15 Dec 2005 21:45:01 +0100 (CET)
instead of a more standard (ISO 8601) format:
Expires: 2005-12-15T21:44:56.296Z
correct?
Does it make sense to support both?
best regards
Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
