Please don't CC me on list messages. I'm subscribed to the list, and it's a
little annoying.
On Tue, 4 Nov 1997, Tomas Fasth wrote:
Tim Showalter wrote:
Nailing it down limits the applicability of the draft. What does it change?
Hmm, would rather say that it makes the applicability clearer for
the implementors. But it depends on how specialized or generic you
want Sieve to be. I think Sieve is enough special to deserve an
explaination in what circumstances it is intended to be used.
I really don't agree with this. Systems that say, "Don't use this unless
you're in this position" don't get used. It seems silly.
The major places where this could be used would be an IMAP server, a POP
client, or a Unix system using whatever local mail facilities are availible
(something more sophisticated than, say, Berkley mailspools).
Rationale: I don't understand the difference between MTA and MUA filtering.
I admit, it _is_ confusing.
I'd argue that it doesn't exist. I see no difference between pre-delivery
filtering and post-delivery filtering because I can't see the perceptible,
on-the-wire difference between a filter running at SMTP level as a part of
the SMTP agent and a filter running on the end of a pipe from sendmail. One
is SMTP, the other just happens to convey the same information and take an
RFC822 format message.
Sieve is designed to filter a message at time of "final delivery", a
deliberately open-ended term concocted to make it clear that it's supposed
to happen just before the message hits the message store, and only happen
once. I think this is enough.
An interesting question: are POP clients supposed to be able to
generate DSN's? That might put some arguments on it's head. :-)
Why shouldn't they? They have all the envelope information they need.
If a message can't be given to the user but was delivered to the mail store,
the POP client is probably the only program that knows why.
So don't do that. (This would be a major configuration error.)
Ah, but then, wouldn't it be a good thing to make a clarification
on when a set of rules is considered a major configuration error
and when not?
No, I don't. Prohibitions against configuring your mailer to do something
dumb are not typically part of protocol documentation.
What bothers me is that this spec is about to become a base for
several different implementations. I would recommend to design
Sieve in such a way that it will not become broken when shifting
from one implementation to another.
Sieve scripts should be portable, and I know of no case where this isn't
true (other than the lack of non-INBOX-like mailboxes if a Sieve script is
run on a POP server).
In this particular case, I asked for a clarification in what
contexts Sieve is to be designed for. If the context is not
clear, we might end up with a language causing more trouble
than joy.
Please provide an example. Bounce isn't it; it's not hard to generate a DSN
given an RFC822 message, which you have anyway.
Sieve was designed to be run on the server when the message is delivered as
part of the MTA. My definition of MTA is broader than yours; I think the
MTA writes to the mail store, you think the mail store takes the message
from the MTA.
That said, I do not believe that "bounce" represents an ambiguity in Sieve's
role. MTA, MUA, and other X.400-derived terms are useful for labeling parts
of an Internet mail system, but are not authoritive, or even rigerously
defined, or in the case of many specifications, defined (or used) at all.
Bounce can be implemented easily by any program that can connect to an SMTP
server given an RFC822 message, to the best of my knowledge.
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu