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

[Pat Lashley]

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

> On Mon, 22 Sep 2003, Pat Lashley wrote:
>
>> Return-Path doesn't exist at all until final delivery, at which point, I
>> believe it is optional.
>
> from RFC2821 (which, I realize, is smtp and not lmtp)
>
>    When the delivery SMTP server makes the "final delivery" of a
>    message, it inserts a return-path line at the beginning of the mail
>    data.  This use of return-path is required; mail systems MUST support
>    it.  The return-path line preserves the information in the
>    path from the MAIL command.

Ok, I was wrong on that.  It is still required.


> I'm not familiar with Envelope-To and have no idea what uses it or might
> use it.  I don't really care about (and am not complaining about) any
> specific headers.

Envelope-To does exactly what you would expect from the name.  It
records the recipient address from the envelope.  It is completely
non-standard; but quite common as there is no other method of saving
that information with the message in a manner visible to the end
user.

(Return-Path would probably be named Envelope-Sender if it hadn't
originally had a slightly different function back in the days of
usenet bang-routed addresses.)

I keep mentioning Envelope-To because 30+ years of Software Engineering
experience tells me that if you handle Return-Path, people will also
want Envelope-To.


> My problem is this:
>
>   - a message is passed to lmtpd via lmtp
>   - lmtpd writes the mail headers to disk and caches the headers in ram
>   - lmtpd generates and writes a Return-Path header to disk but does not
>     cache it in ram
>   - lmtpd generates and writes other headers to disk but does not cache
>     them in ram either
>   - sieve operates by checking against the headers in the cache
>   - sieve can't check all of the headers, because not all of them are in
>     the cache
>
> That, imho, is not correct behavior.

What headers, aside from Return-Path, are not cached in RAM?



> I don't what the Sieve RFC says about return-path.  I'm pretty sure that
> it isn't germane to this topic.

Then why was it necessary to create an "envelope" extension to sieve?


> smartsieve can't be smart enough to automatically translate the condition.
> It seems like you're suggesting that smartsieve (and any other program
> that generates sieve rules) should be following behind lmtpd, trying to
> guess at what special header might map to which special sieve function.

Nonsense.  I'm only suggesting that it be smart enough to actually
follow the RFCs and drafts; and to know about a few of the extensions
like envelope.



>> > 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.
>
> I'm not sure what you mean here.  Or maybe I am not being clear.  To
> restate myself:  this issue has _nothing to do with sieve_.  I am not
> trying to patch sieve and I don't want to be.  The patch changes the
> behavior of lmtpd so that the on-disk and in-memory represention of the
> headers is the same.  (Rather, the patch is a start; since it doesn't yet
> include the last-hop Received header they don't completely match.)

You're trying to change LMTP to provide a header that WILL NOT EXIST
in other sieve environments.  It will not be at all obvious to the
naive user that that header was inserted at the last minute rather
than following the message from its inception.


>> The envelope extension exists to provide the functionality you need.
>
> The envelope extension does not provide the functionality that I need.
> Open any message that is stored in cyrus and was delivered via lmtp.
> Look at the headers.  The first header that you will see looks something
> like:
>
>   Return-Path: <cbs at cts.ucla.edu>
>
> I need to be able to filter on that header.

You are confusing functionality with implementation.  A common mistake.




-Pat