[Top] [All Lists]

Re: MTA Filters BOF request, LA IETF; Proposed Charter

1998-01-12 17:35:05

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.