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