cyrus-imapd 2.1.15, sieve, lmtpd, and return-path header

[Chris Stromsoe]

On Mon, 22 Sep 2003, Pat Lashley wrote:
> --On Monday, September 22, 2003 19:02:11 -0700 Chris Stromsoe <cbs at cts.ucla.edu> wrote:
> > On Mon, 22 Sep 2003, Pat Lashley wrote:
> >
> >> Can't you get what you want using the "envelope" extension?
> >
> > Probably.  "But..." the rules are being generated by smartsieve.
> > Relying on smartsieve to know that return-path is special (compared to
> > any other random header) and that it should use envelope seems a
> > little goofy.  I can also see some utility in having the return-path
> > and other generated headers in the header cache.
>
> I would think that the right solution would be to make smartsieve know
> about the envelope extension and have it explicitly offer comparisons
> against envelope sender and envelope recipient rather than the
> Return-Path and possible Envelope-To headers.

Why?  Return-Path is clearly a header.  What's special about it as opposed
to Subject or Date or From or anything else?

> > Anyway, the attached (compiled but untested) patch splits fill_cache()
> > into a second piece (insert_cache_element()), and uses the new
> > function to insert the return-path into the header cache.
>
> So you wind up with sieve scripts that won't work as expected on other
> conformant sieve implementations.

Right now I've got sieve scripts that don't work as expected.  When you
pull a message out of the store, it clearly has a Return-Path _header_.
The expectation is that sieve will be able to match on any header in the
message.  But, right now, it can't, because the generated headers are only
written to disk and never inserted into the header cache.

I'm not sure why the script won't work with any other conformant sieve
implementation.  This has nothing to do with sieve... it has to do with
lmtpd writing one thing to disk and keeping a separate thing in ram.


-Chris