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

[Rob Siemborski]

On Tue, 23 Sep 2003, Pat Lashley wrote:

> (And if the lmtpd authors want to contradict me here; I will claim
> that messages which are not examined by Sieve should not have an
> X-Sieve header added.)

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

> Hmm, I don't have the old messages; but weren't we talking about the
> authors of the LMTP protocol/RFCs at this point; not the authors of
> the Cyrus lmtpd?  The folks who write and review RFCs tend to take
> a more global view than most implementers.

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

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

> It does.  The Return-Path header is not available at this point.
> You are confused by the fact that a predictive copy happens to
> appear in a file created by the same daemon.  But it is, quite
> properly, -not- available to Sieve because the message has not
> yet been designated for final delivery.

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

> Once again.  The fact that that header is predictively inserted into
> the disk file is immaterial.  It is even arguably wrong.  (Although
> that argument is likely to fail in the face of the performance advantage
> of not having to rewrite the file just to add that one header when a
> final delivery is actually made.)

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.

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

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.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper