Re: sieve draft

Bart Schaefer wrote:

> } My point is that if we use this description as a model, message
> } delivery is just about to find the correct maildrop. That makes
> } the task of the MTA much less complicated.
>
> The name of this mailing list *is* ietf-mta-filters.  Have we all decided
> that we're not talking about MTA-level filtering any more?
Good point. I have been questioning the overall concept of
MTA-level filtering. Which might not be a very good idea on a
list dedicated to the task of doing exactly that. If I have been
out of line here I appologize for that.

Still, I thought it to have been unclear when this MTA-level
filtering was about to take place. Reading one of my earlier
postings in this thread, I recognize my own confusion, mixing it
up with MUA-level filtering. My eager to argue, and therefore
showering this list with several postings on the same subject,
comes partly from my assumption that Sieve was going to be used
in the context of UA-level filtering.

But I seem to have been partly wrong. The Sieve draft states:
"
   Implementations of the language are expected to take place at time of
   final delivery, when the message is finally moved to the user-
   accessible mailbox.  In systems where the MTA does final delivery,
   such as and traditional UNIX mail, is reasonable to sort when the MTA
   deposits mail into the user's mailbox.  If the MTA does not do final
   delivery, or lacks the power to sort into separate mailboxes, as is
   the case under POP3, the MUA must do filtering into local-disk
   folders.
"

It seem to me that the text about an MTA doing a final delivery
is misleading. It might be the case that a monolithically designed
program is performing several tasks, among them SMTP handshake,
message routing, and local delivery. But this is not the same as
saying that the MTA is doing this and that.
In the case of sendmail, the final delivery is actually done by a
separate program (mail, rmail, mail.local). I would not include
that program in the domain of an MTA. 
On Unix systems it's sometimes not very easy to recognize the
borders between different components within the mail subsystem.
Still, I would like categorize the mail.local, pop and imap
programs as part of the message store, not the message transport
agent.

You might think I am one of those idealistic OSI guys, but I
ensure you, I'm not. I just like to have some order in the
terminology we are using here.

And in the end, what all my rioting in this thread have been
leading up to is my assertion that Sieve is actually executing
in the context of the message store, beyond the point where a
message have been delivered by the MTA but before the point were
it has been filed. Therefore a message cannot be bounced, only
handled by performing a drop, reply or store.

Even if you allow to execute Sieve in a context where it is
possible to reject a delivery, you still have a problem when the
same set of rules are about to run on the MUA-level.
It is not mandatory to keep the address to the SMTP originator
beyond the point of delivery, so it might not be available when
you are about to initiate a bounce.
Therefore, in the case of mailing list exploders, you may not
know by what address the message was delivered to you, which
makes a bounce pointless, because you may not have access to
the return-path nor the recipient address (which may be needed
to fix the cause of rejection).

If something good have come out of this thread, it might be the
distiction between SMTP-level filtering, MTA-level filtering and
MUA-level filtering.
The SMTP-level for processing filtering rules prior message
transfer. The MTA-level for processing after message transfer
but before local delivery (or possibly further relaying). The
MUA-level for post-delivery processing.

Was Sieve really intended to do SMTP-level filtering as well?
Or was this only a wild idea raised in the heat of the debate?

-- 
Hälsningar/Regards

Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden