You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/07/22 20:11:30 UTC

RE: Handling the Expired: Header

Marcel,

> > 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:
<NB...@devtech.com> 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?

	--- Noel


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

Re: Handling the Expired: Header

Posted by Marcel Ruff <mr...@marcelruff.info>.
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:
> <NB...@devtech.com> 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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org