On Mon, 12 Jan 1998 18:45:51 -0500 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
If the filtering language is to be transmitted over the 'net between
a user and his mail service, then it's part of an on-the-wire protocol.
the filtering language might be thought of as a separate piece, but it's
going to need some sort of transfer protocol with authentication to be
useful in this scenario.
Well, RFC822 doesn't mandate RFC821. 822 is a very useful piece of
work by itself; it doesn't require an on-the-wire protocol definition.
(And I'm glad for that, having used 822 over more than one non-821
transport-type beasty.)
Mail filtering is certainly useful. My concerns are about whether
standarization of a mail filtering language is an appropriate activity
for IETF (given its tranditional scope and limited resources) and if so,
how to legitimize mail filtering without adversely impacting the mail
transport system.
I will admit it's a bit non-traditional in the IETF context. However,
this initiative is being driven by many (most?) of the major players in
the (IETF standards based) e-mail arena. We all agree that the only way
to deliver functionality to our combined user community is by having a
single, standard, light-weight filtering specification. That we also
all agree that the IETF is the place to create this standard is a
statement that the IETF directorate should pay attention to. (Many of
the people who have been quietly pushing this initiative aren't
newcomers to the IETF process.) If it's a *big* problem we could submit
an informational RFC, but this is getting mired in politics and I'm not
wanting to go there.
[BTW, I'm using the "royal all" above. I'm sure not 100% of the
SIEVE participants agree, but I haven't heard any of them speak up
against this. ]
I'm not sure what you mean by "legitimize" above. The whole thing has
been driven by customer demand. They *want* this, and they want it
yesterday. There's no selling of the concept required. Now that ACAP is
published I'm fielding two to ten requests a week from people asking
when we will have ACAP plus some sort of filtering language up and
running. I'm sure other vendors can speak up as to numbers.
The bottom line here is that the user community wants it, and the
vendor community agrees that an RFC is the only way to go. With that
sort of support the IETF could be catching a lot of bad press from all
directions if they adopt a stick-in-the-mud attitude on this.
Users will need a method to specify filtering to their ISPs. If this
method is not defined as part of the standard, different clients and
different ISPs will support different ways of specifying the filter,
and those users will have interoperability problems.
I wonder if ISPs would really be willing to support ACAP as their
storage medium of choice for mail filtering.
I can think of three or four large installations that would buy it
*today* if we could deliver it (ACAP+SIEVE+IMAP4 server). The
requirements are:
* SIEVE ruleset manipulation support in the client, including
fetch and store on an ACAP server,
* An IMAP4 server that has the ability to filter a users
incoming mail based on the SIEVE rules in that users
ACAP data set, and
* An assurance that the ISP (and their customers) can switch
components in and out (i.e. swap in a different vendor's
IMAP4 server) without the rest of it breaking.
Now, if an RFC isn't the appropriate vehicle, can you suggest an
alternative that would let us achieve the same thing (an open standard)
in a similar timeframe? One thing that really concerns me is that if we
*don't* get something out in a reasonable timeframe then vendors will
simply define their own proprietary schemes. That's nothing but a lose
for the everyone.
--lyndon