"John" == John C Klensin <john(_at_)jck(_dot_)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(_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.
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf