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

[Pat Lashley]

--On Tuesday, September 23, 2003 23:11:25 -0400 Rob Siemborski 
<rjs3 at andrew.cmu.edu> wrote:

> All messages that hit a sieve-compiled LMTPd are "processed by sieve" even
> if that processing is just "hey, look, there isn't a sieve script for this
> user... moving on..."

Which is what I suspected; and part of the basis for my opinions
about what headers should be available to it.


> Heh. They're one and the same actually.  RFC2033 was written by John
> Myers, one of the first developers on the Cyrus Project.

I suspected there was at least some overlap...

> There are a number of similar RFCs that were developed at around the same
> time that were definitely severely impacted by the needs of Project Cyrus.
>
> And, while RFCs are generally written to create interoperable standards,
> the fact is, most of the time they're written by implementors of those
> same standards -- the people who have the most experience getting that
> interoperability to work right.  Indeed, often if an RFC is published and
> there isn't at least one full implementation of it already, glaring bugs
> are found after publication.  (The IMAP BINARY extention has this problem,
> for example).

Absolutely true.  But once a draft RFC is published a bunch of other
people, with no vested interest in the prototype implementation, have
a go at it.  Which tends to cause a general cleanup and generalization
of the spec.  (Except in the rarish case where the original authors
were able to divorce themselves from their implementation enough to
make the original draft clean and general...)

This is part of the purpose of the RFC process.  Propose something.
Generate a proof-of-concept.  Let a bunch of other smart folks with
experience in the general area look it over and knock all of the
rough edges off of it.


> Forgetting about Return-path for the moment.  At the minimum the X-Sieve
> header should be available (and probably the received header, since the
> message was received before it was processed by sieve).

I thought you said above that sieve runs before the 200 result.  So
arguably, the message hasn't been -completely- recieved by lmtp until
sieve is finished.

As to whether the X-Sieve header goes in at the beginning or the end
of sieve processing; I could see arguments either way.  (And arguments
for providing some other mechanism for a sieve script to find out what
version of which sieve interpreter is processing it.)


> Yeah, if we were to correct the fact that we forward messages with the
> Return-path, we'd correct it by skipping the first line of the file when
> we were writing it back to the MTA, not by writing the initial file
> without the Return-path header.

Exactly.  Having it in the file is a predictive optimization based
on the most likely outcome of the sieve processing.


>> Procmail is basicly a hack to provide much greater capability to the
>> unix .forward files.  Which were themselves basicly a hack.  The MTA
>> treats it as a final delivery, whether it actually is or not.  But
>> procmail is not well integrated into the mail system; and is most
>> emphaticly -not- a good model for a stand-alone sieve filter.
>
> Why not?  If I had a sieve implementation that was stand-alone and I
> wanted it to work as a local delivery agent, I think it would make sense
> for it to work exactly as procmail does.

Because it doesn't properly handle the envelope?  Because pipes could
be used instead of writing temporary files; with all of the race-
condition potential security holes that come with using temp files?
(No, I can't think of anything particularly dangerous that could be
done by maliciously tampering with the temp file.  But that doesn't
mean that nobody can.  And I suspect the potential would depend greatly
on the specific stand-alone sieve implementation.)

> And procmail is allowed to fail and exit with EX_TEMPFAIL (or other exit
> codes) to signal various failure conditions to the MTA.  Any reasonable
> MTA shouldn't assume the message is delivered until that delivery agent
> exits with an OK status code.

That much is reasonable.  The mail filtering program certainly needs
some way to return various error conditions (and a positive success
condition.)  But using exit codes implies the need to fork a new copy
for each message processed; which eliminates the potential for a 'sieved'.
(Not that I'm not particularly advocating a sieved for a stand-alone
sieve implementation; I just don't see any particular reason to eliminate
the possibility or make it needlessly comples.)

There are certainly -worse- models than procmail; but that doesn't
make procmail a particularly good model.  And certainly the argument
"but procmail does it like this" doesn't hold much water.



-Pat