ietf-mta-filters
[Top] [All Lists]

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

1998-01-13 11:33:59
--On Tue, Jan 13, 1998 09:22 +0100 "Harald Tveit Alvestrand"
<Harald(_dot_)Alvestrand(_at_)maxware(_dot_)no> wrote: 

[ Thank god for my selective REPLY-TO interface 8-) ]

Some small points of agreement here, I think, to sum up.

Initial reactions:

1) I think a standard filter language is a Good Thing, exactly because
    the Right Place for the filtering is at delivery time, not reading
time,
   and since all the rest of the UI/mailbox interface is standardized
   (IMAP, ACAP), the filtering language needs to be too.
   The alternative is that filters stay in the UI, and people have to wait
   minutes before reading their E-mail, not to mention the need to
   download everything for filtering before classifying most of it as
   "not worth reading now". BAD.

Yes, good summation.


2) I will balk VERY strongly at having the letters MTA anywhere near
   the mailing list name (sorry!), the WG name or the charter text.

I don't think anyone on the list will object. The name MTA-filters was
historical, anyway, and just carried over from an ancient conception because
nobody thought to think up a more accurate name 8-(.


   The reason is that I believe the requirements for filtering at the UA
   and filtering in the message path to be VERY different; the UA must
   make a file/reply/drop/mark/call-attention decision; the MTA must
   make a relay/bounce/black-hole decision.
   These are differing requirements, I think aiming at both is likely to
   produce something that satisfies neither.


I agree that a _complete_ filtering solution has different requirements at
both levels, but I think the fairly restricted scope of the current draft
addresses functions that are, in practice, handled by *both* MUAs and MTAs
right now at the nebulous "delivery" point. While I think a case can be made
that by writing something that applies to both, it's both more accurate,
more restricted, and more achievable to focus on delivery, rather than
making an artificial dichotomy between servers, clients, MTAs, MUAs, etc.

   I suggest calling it Mailbox Server Filtering Language - MSFL?

How about Mailbox Delivery Filtering Language (MDFL) -- and we can re-write
the charter, etc. to explicitly use the term "delivery agent" (in an attempt
to avoid both your quite valid objections to bringing the MTA explicitly
into it, but to simultaneously not make a judgement as to whether it's the
MUA or MTA acting as a delivery agent, since they clearly can both apply...)

BTW, Tim, calling the group Mailbox-Server Filtering Language or whatever
doesn't mean you can't call the specific draft SIEVE 8-). (Anybody have an
idea for words to go into an acronym "COLLANDER"??)

3) I will not object very strongly to an effort AFTER the UAFILTER effort
    to use the if-condition language for UA filtering to see if this can
be
   applied to MTA filtering; as Keith said, it's doubtful that this will
be
   anything but a short-term, somewhat-ineffective measure.

Well, I'd suggest this is one of those areas where implementation experience
is the only way of seeing whether/how much "MDFL" will help. Again,
anti-spam is not the primary intent of this work, it's just it might well
help by making some basics easier.

In any event, if we call this delivery filtering, would that make everybody
happy (or, in the half-empty view of this glass, would that tick anybody
off?)

Keith, does this clarify things a bit and/or restrict scope more to your
liking? 


                             Harald A

who just spent about 3 days to get proper filter configurations into
Eudora, and is dreading the thought of moving mailbox yet again....



excellent timing 8-).

-----------------------------------------------------------------------
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
-----------------------------------------------------------------------




<Prev in Thread] Current Thread [Next in Thread>