--On Mon, Jan 12, 1998 16:51 -0500 "Keith Moore"
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
I'm very dubious about the desirability of standardizing an
MTA-level mail filtering language.
in addition, the notion of a "general" filtering language,
as opposed to one specifically designed for email, sounds
like a rathole to me.
Maybe some language problems here on my part, specifically the intent of
"generalized". We don't mean the swiss-army-knife generalized; emphasis on
the use of the word to mean "simplified enough that it makes sense in
several related contexts".
I shall attempt to clarify and make a little more explicit what's going on.
There's a two-year history dating back to the January '96 IMAP meeting, and
the working SIEVE draft probably bears some examination to illuminate the
proposed WG's goals.
The proposed filtering language is only 'generalized' for use by delivery
agents tied to the MTA. I don't think we've ever been discussing anything
much more ambitious than that. It's desirable (saying this as a current
client guy) that this be 'fungible' between client and server sides, but not
a fundamental requirement.
I can remember conversations about this as long ago as 1994 in the IMAP4
revisions penumbra. The specific impetus to go the current design route
originally came out of the early IMAP discussions as a particularly bad hole
in the architecture. Specifically, we had the first such meeting at the
first formal IMAP meeting in Seattle, and Terry Gray at that time proposed
dealing with it as a general issue rather than one tied specifically to
IMAP. It was identified specifically from the podium at the 2nd IMAP meeting
as among the most important architectural issues, and about 250 industry
people around the room nodded their heads. We've since continued to have
pretty broad participation, and we'd've proposed the WG a long time ago save
for the fact that many of the originators of the discussion have had other
windmills to joust at in the interim 8-). In fact, I was prodded to do this
after the dozenth time I'd answered the question at the DC IETF 'what's up
with SIEVE? We need this yesterday...'
I also count up 300 some posts from 50 or so domains on the list and related
discussions over the past 18 months. I believe this in and of itself
justifies consideration of pursuing this formally via the IETF. There's
clearly a large segment of the usual suspects who've considered this a
worthwhile area to spend time on.
Fo further clarify...the specific action issues that are a big problem here
are: vacation, auto-reply, auto-discard, and auto-file to multiple INBOX
locations (including resubmission, aka forward) according to logic. These
are traditionally MTA-delivery side things, are implemented in an incredible
variety of ways, and are completely obscure in a client/server architecture
-- ' things you or your server admin have to login and futz with to do', as
these were generally described at one of the meetings. I'd argue the basic
set of activities screams for a standardized approach. From the client side
of things, it's virtually impossible to talk about replacing proprietary
functionality with the internet architecture without a standards approach.
The last, the auto-file issue, is one that's become recently quite important
to certain IMAP implementations. I thing we're generally agreed that
requiring delivery behavior via the access protocol is a bad thing and kind
of limited, and at the same time it's out of scope for the 821/822 revisions
and discussions. The others are all time-tested issues with just gobs of
current non-interop problems. Just do a search in the discussion groups for
getting filter agent X to work with SMTP agent Y and IMAP server Z -- and
this is a knowledgeable crowd, to boot.
The scope is purposefully quite limited here. Concentrating on a relatively
simple standard syntax is just about as minimal as you can get here. It's
location-neutral -- i.e. appropriate for stores ranging from local disks and
.rc files to more nuanced approaches like ACAP -- protocol-free, to avoid
adding more on-the-wire requirements -- and "generalized" only in the sense
that it's simple enough that both client and server implementers can build
on it.
I'm very aware of the rathole potentials here, ranging from current
commercial vendors getting enmired in retroactive compatibility issues (ala
Cal/Sched) to a misinterpretation of the problem area as merely anti-spam
(when this is only a small tool for that very large general area). Awareness
of potential ratholes is specifically why the scope of the language was
limited, it was designed to be a 'primitives' subset, and it's not a
Turing-complete language with all the "real" language and parsing issues
involved. It's a way of specifying a limited set of logical operations that
are common to MTA delivery.
Believe me, I have no love of having to face these potential ratholes. But
having been down the server side and client side both over the past few
years, a simple lingua franca would be enormously helpful. Many people are
going to implement their own chimerical versions regardless; it's a question
of whether the IETF will take a leadership stance, or we're going to have
permanent non-interoperability for some key functions that are missing from
the architecture.
with few exceptions, the mail transport system should not be
doing mail filtering. the mail transport's job is to deliver
mail, not to make filtering decisions on behalf of the user.
if recipients want to filter their own mail, that's their
business, but then it's a UA-level thing.
I disagree. Filtering is something that *is* done at the delivery end of the
transport cycle. A "UA" relies on delivery and transport agents to make a
number of decisions. If it was merely a UA activity, we wouldn't have
vacation, procmail, .forward, IMAP BB+ -style delivery, auto-bouncing, or
any current filtering activities done completely without the participation
of a UA.
I personally hear from customers with increasing frequency about the need to
move and share filter-style activities. UAs obviously play a key role for
the individual user, but UA, location-, and even site-independence to be
able to move these guys about are really useful. As IMAP is to mail access,
maybe one could think of the MTA-filter proposal is to 'filter access',
minus the protocol overhead requirements.
Others, please chime in. Keith needs to be convinced... 8-)
- Matt
-----------------------------------------------------------------------
Matthew Wall mailto:wall(_at_)cyrusoft(_dot_)com
Cyrusoft International, Inc. http://www.cyrusoft.com
Voice: 412 605 0499 Fax: 412 605 0705
-----------------------------------------------------------------------
Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------