Sam,
A few comments about differences in philosophy rather than
specific details of this proposal. Once one gets past that
difference in philosophy, it is not clear to me how much of your
comments are major but...
--On Tuesday, 18 March, 2008 04:51 -0400 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> wrote:
...
In particular I believe that the remote-host and remote-ip
variables are inappropriate and should not be standardized.
I believe an applicability statement should be added to the
extension making it clear that this extension is only for
interpreter state and that another extension should be
designed for examining information about the message.
...
Section 4.3.3 claims that experimental RFCs are an appropriate
mechanism to register non-standards-track variables intended
for wide use. That seems wrong. I recommend revisiting the
registration policy.
The bottom line about Sieve is about providing a standard way to
let mail-receiving and mail-reading client machines communicate
with mail server systems about filtering and classification of
mail. Both the client and server systems in the Sieve case
occur after what the mail transport standards refer to as "final
delivery".
This actually isn't true. Some Sieve implementations, including ours, operate
before final delivery. (Usually just before.) Others operate just after. And in
the imap-sieve case there is now a situation where Sieve can be executate LONG
after final delivery.
Indeed, there's at least one Sieve extension - ereject - that requires
operation at or before final delivery in order to funciton (it calls for a 5yz
SMTP response - no way can that happen after final delivery).
For practical reasons, there has been general
consensus in the email protocol community for many years that
filtering and classification are better done on always-on/
always-connected/ always-active servers than on mail
receiving/reading machines... if only because of perceived
performance issues with the latter.
Performance issues are part of it, but there's also the temporal context to
consider. Some filtering operations are highly time dependent - indeed, there's
a Sieve extension (date) specifically do deal with such things.
Part of the elegance of
Sieve is that it tries to be flexible on that subject: if an
operation cannot be specified to and performed on the server,
then it can be acted on by the client, using the same vocabulary
for describing what is to be done. But the main goal, IMO, is
to permit client control of server-side filtering operations
with a standard vocabulary.
Exactly.
The operations and vocabulary that are being specified for Sieve
aren't doing anything new or anything we can prohibit by not
publishing pieces of the specification language or by making
registration difficult.
This is the key point. You can rail all you want about how the client IP
address or host name oren't legitimate things to base your filtering on, but
that isn't going to change the fact that people do this sort of filtering all
the time. Heck, there are entire services built around this model, and I could
see wanting to take the remote IP address an feed it into the external list
extension in order to access information from such a service.
If we keep functionality out of Sieve,
we don't prevent that functionality from being used. We just
impede filtering being offered as a service by multiple-user
email providers, keep those of us who have been doing
server-side filtering and classification for years from doing so
unless we run our own servers and can run scripts and custom
filters there, and push everyone else into client-side filtering
that slows down the perceived performance of mail reading.
Very nicely put. I completely agree.
Now, use of Sieve is unwise, and perhaps dangerous, if there is
not a fairly strong trust relationship between the client and
server and if the client doesn't have a good model of server
capabilities. I would wish it were otherwise, but that
relationship reflects reality. I personally believe those
issues are adequately covered in the base Sieve materials, but
perhaps you disagree and should be looking for more explanation
there (or elsewhere).
I believe there are a number of things we got wrong that unessarily hinder
script portability and reliability, but the good news is almost all of them can
be address through extensions of one sort or another. Access to the sort of
informaton environment provides addresses one of these concerns. (Another
example: Currently scripts have a choice of requiring an extension or doing
without it - there's no way to use an extension if and only if it is available.
This one is addressed by the ihave extension defined in another one of my
drafts.)
Ned
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf