Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard

[Ned Freed <[e-mail]>]

> 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
> <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf