--On Tue, Jan 13, 1998 22:49 +0100 "Tomas Fasth"
<tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
wrote:
Would it be possible to draw a charter for this "delivery filtering"
working group which include goals addressing the issues I brought up?
It seem to me like a good idea to keep such issues together in the same
working group and try to provide an overall interoperable delivery
filtering standard.
OK, so I don't get to punt 8-).
I have a strong intuition that broadening the scope in this way would lead
to a firey death when we ask Harald and Keith to approve the charter.
I totally agree that these need addressing, I'm just not as sure it's an
achievable goal, and neither am I convinced that starting with a very basic
set of filter language primitives isn't the correct first step even if we'd
like to get to these things eventually.
Specifics:
How should a MUA be able to transfer filtering rules to the MTA (or more
precisely; to the delivery agent) so that arbitrary brands of MUA and
MTA can interoperate?
Two answers here:
(1) it doesn't matter, if you use an intermediary, like ACAP. In a separate
thread with the ACAP group, I'm proposing an experimental SIEVE rules
dataset so we can get a reality check on implementation of filters via an
intermediary.
This is not science fiction, btw; the IMSP experiment included option names
for common mail server/MUA attributes that could be used at delivery time
for a few operations.
(Anybody who's been following cal/sched, insert your experiences here with
the new protocol issue...)
(2) since the filtering rules are just data, this can be deferred (if my
first answer isn't satisfactory) until after the filtering language itself
is completed. There's nothing inherent in construction of the language that
would preclude a particular approach to transport later.
And, how can this be done in a way preventing evil attacks to succeed?
We perhaps need to add some more language to the current draft for security
considerations that addresses the basic issue, but I honestly don't see this
as particularly different from the simple case of having access to the
.forward file or a server-based vacation program. I can only attack where I
can convince some agent in the process to believe rules I have permission to
write.
(Case in point, by the way, I got into a little mini flame-like exchange
with somebody I "sent mail" to yesterday, and continued to "send mail" to.
It turns out a colleague incorrectly set his .forward notice to point at
this guy's account, and I was the first unfortunate SOB who sent him mail
from outside the company in question, a point this person didn't get since
he had absolutely nothing to do with setting the .forward file. Let's say
you've been fired. Before you leave, you set your .forward to go to
boss(_at_)yourformeremployer(_dot_)com(_dot_) You go home, get a hotmail
account, and
immediately start cranking out mail to your old address. Substantially the
same as just attacking the Boss' mailbox directly.)
How can the MTA be able to communicate filtering status and reports to a
MUA in an interoperable way between arbitrary brands?
Definitely way out of scope. Desirable to talk about, but there's early and
somewhat unsatisfactory work on the instrumentation front (APPLMIB, yes?)
that will either be applicable or it won't. Transfer and handling of log
information isn't unique to this problem domain, ergo we should ignore the
issue. (My 2 c, of course, only.)
And actually, this really seems like either just an implementation issue or
something for the generalized application instrumentation/logging standards
work elsewhere.
And, what can we do to eliminate unpredictable results from running the
filter rules?
There are two general answers to this:
1) make the rules themselves as safe as possible. By restricting looping and
similar constructs, sieve is 'safe', although discussion of the
extensibility mechanism is probably well-advised to get into this in more
detail.
2) you can't prevent people from writing incorrect rules. This happens *all*
the time with filters. It's a problem with FLAMES, it's a problem with
Procmail, it's a problem with Eudora. And one of the problems with doing
validation for any rules-based filter in any sphere is it's quite difficult
to comprehensively test outliers -- i.e. you can do all the syntax checking
you want, but there's no algorithm on the planet to check if the rule
semantically matches the intended effect.
we have to
address the interoperability issue as percieved from site deployment
point of view. Or do you suggest that we are going to say, "Hey, it's up
to you to find the pieces that fit together"? Seem not to adhere to the
general spirit of IETF, IMHO.
Not really. Lyndon's analogy about RFC822 messages was a good one. You
specify structure and format for one part of the architecture, independent
of transport. Look at MIME. Same deal. You can address a building block
piece without necessarily providing a holistic answer to all problems in the
sphere.
I suggest we either discuss
the possibility to define a simple TCP based protocol to be used to
exchange information related to MTA filtering.
Yuck. I really don't see the need for it. There are a ton of ways of getting
this sort of thing over the wire, and I'd have to hear a pretty convincing
argument that a separate protocol is required for exchanging this kind of
information. ACAP is ideal, http will likely be used regardless, the mail
transport pipe itself can be used (much like it is for virtually all
listserv-style processing, for instance.)
Or, discuss the
possibility to define one or more MIME based formats suitable to
exchange information related to MTA filtering using the mail transport
itself as communication media between the MTA and the MUA.
A MIME definition is probably a good idea as part of the base spec on
general principle.
= mw
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------