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