Re: Comments on draft-freed-sieve-environment-04
Ned Freed <ned.freed@mrochek.com> Fri, 28 March 2008 21:48 UTC
Return-Path: <owner-ietf-mta-filters@mail.imc.org>
X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41ACF3A68F7 for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Fri, 28 Mar 2008 14:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.26
X-Spam-Level:
X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXY11FH5bIgJ for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Fri, 28 Mar 2008 14:48:50 -0700 (PDT)
Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2D6913A6831 for <sieve-archive-Aet6aiqu@ietf.org>; Fri, 28 Mar 2008 14:48:49 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2SLb0O3092900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2008 14:37:00 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2SLb0do092899; Fri, 28 Mar 2008 14:37:00 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2SLawg6092893 for <ietf-mta-filters@imc.org>; Fri, 28 Mar 2008 14:36:59 -0700 (MST) (envelope-from ned.freed@mrochek.com)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSYIEHKZ7K000D9B@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 28 Mar 2008 14:36:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSX8YB275C00007A@mauve.mrochek.com>; Fri, 28 Mar 2008 14:36:52 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-mta-filters@imc.org
Message-id: <01MSYIEFTB7400007A@mauve.mrochek.com>
Date: Fri, 28 Mar 2008 14:16:44 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Comments on draft-freed-sieve-environment-04
In-reply-to: "Your message dated Thu, 27 Mar 2008 00:32:21 +0100" <1206574341.16281.60.camel@oslhomkje>
References: <alpine.BSO.1.00.0803190129540.441@vanye.mho.net> <01MSRCK0MPHS00005Q@mauve.mrochek.com> <1206459316.16281.2.camel@oslhomkje> <01MSU1O7TZT600007A@mauve.mrochek.com> <1206574341.16281.60.camel@oslhomkje>
To: Kjetil Torgrim Homme <kjetilho@ifi.uio.no>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206740214; h=Date: From:Subject:MIME-version:Content-type; b=AZsijpzUWp2025FAAr1aMLN1b MRi7Fl9SXi1lWJtDX55U2PAUOhmT0+i4heCa5G/MkeedlC7ZfKTn2WoR2wdsQ==
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
> On Tue, 2008-03-25 at 09:52 -0700, Ned Freed wrote: > > > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote: > > > > Also a good point. I have added: > > > > > > > > The remote-host environment item defined in this specification is usually > > > > determined by performing a PTR DNS lookup on the client IP address. This > > > > information may come from an untrusted source. For example, the test: > [...] > > > sorry, I don't understand what this means. is the existence of a PTR > > > record sufficient? > > > > Who knows? The mechanism used to obtian the remote-host isn't (and should not > > be) specified. As such, a PTR could be sufficient. Or it may not be - some > > systems do a backwards-forwards check. And there can even be cases when a PTR > > record isn't needed - DNS names aren't the only game in town, you know. > ok. I think it could be made a little clearer, though. how about: > How to determine the remote-host environment item defined in > this specification is left up to the implementation, e.g, if TLS > is in use, the remote system's name can be extracted from the > client certificate if the signer is trusted. Probably more > commonly it will be determined by performing a PTR DNS lookup on > the client IP address. This information may come from an > untrusted source. For example, the test: I really don't want to get into the whole TLS cert thing in this document. > another alternative, with no specific details about alternatives: > An implementation can use any technique to determine the > remote-host environment item defined in this specification, and > the trustworthiness of the result will vary. One common method > will be to perform a PTR DNS lookup on the client IP address. > This information may come from an untrusted source. For > example, the test: This, OTOH, is fine. I'll include it in the next revision. Ned
- Comments on draft-freed-sieve-environment-04 Philip Guenther
- Re: Comments on draft-freed-sieve-environment-04 Ned Freed
- Re: Comments on draft-freed-sieve-environment-04 Philip Guenther
- Re: Comments on draft-freed-sieve-environment-04 Alexey Melnikov
- Re: Comments on draft-freed-sieve-environment-04 Kjetil Torgrim Homme
- Re: Comments on draft-freed-sieve-environment-04 Ned Freed
- Re: Comments on draft-freed-sieve-environment-04 Kjetil Torgrim Homme
- Re: Comments on draft-freed-sieve-environment-04 Ned Freed