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

[Pat Lashley]

--On Monday, September 22, 2003 19:32:07 -0700 Chris Stromsoe 
<cbs at cts.ucla.edu> wrote:

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

It's not a standard header, as such.  Subject, Date, From, and most other
headers are written by the originating MUA; and remain intact throughout
the life of the message.  Primary exceptions are Message-Id; which should
be added by an MTA if it isn't already there; and Recieved: which is is
added by each MTA that processes the message.  Return-Path doesn't exist
at all until final delivery, at which point, I believe it is optional.

And, as I recall, the Envelope-To: header is completely non-standard;
though widely used; and when used, it is in a manner similar to Return-
Path:  (I.e., Any existing one is removed and a new one is added only
at the point of final delivery.)


>> 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_.

What is your MTA?  Have you checked to see whether that header is optional?
(Or does LMTPd create it?)  Perhaps you -shouldn't- see the Return-Path
header when you pull a message from the store.

> 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.

What, if anything, does the Sieve RFC have to say about Return-Path?
I suspect that if it were allowed by the standard, then there would
have been no need for an "envelope" extension.  (Does the envelope
RFC/draft say why it is necessary?)

Smartsieve should either be smart enough to automatically translate
the condition; or smart enough to warn the user that it won't work
as expected.

> 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.

Because other sieve implementations are likely to be in an environment
where that header does not yet exist to be tested.

Your solution has the advantage of being simple and fairly easy to
implement.  That doesn't make it the right one.


The envelope extension exists to provide the functionality you need.



-Pat