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

>>>>> "John" == John C Klensin <john@jck.com> writes:

    John> Sam, A few comments about differences in philosophy rather
    John> than specific details of this proposal.  Once one gets past
    John> that difference in philosophy, it is not clear to me how
    John> much of your comments are major but...

    John> --On Tuesday, 18 March, 2008 04:51 -0400 Sam Hartman
    John> <hartmans-ietf@mit.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.

    John> The bottom line about Sieve is about providing a standard
    John> way to let mail-receiving and mail-reading client machines
    John> communicate with mail server systems about filtering and
    John> classification of mail.  Both the client and server systems
    John> in the Sieve case occur after what the mail transport
    John> standards refer to as "final delivery".  For practical
    John> reasons, there has been general consensus in the email
    John> protocol community for many years that filtering and
    John> classification are better done on always-on/
    John> always-connected/ always-active servers than on mail
    John> receiving/reading machines... if only because of perceived
    John> performance issues with the latter.  Part of the elegance of
    John> Sieve is that it tries to be flexible on that subject: if an
    John> operation cannot be specified to and performed on the
    John> server, then it can be acted on by the client, using the
    John> same vocabulary for describing what is to be done.  But the
    John> main goal, IMO, is to permit client control of server-side
    John> filtering operations with a standard vocabulary.

John, It sounds like you believe I have a problem with standardizing a
mechanism to look at the remote IP or host of the person submitting
the message at hand.  That's not the case; I simply don't think that
the environment extension is where we should expose that in sieve.

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf