Re: Comments on draft-freed-sieve-environment-04
Ned Freed <ned.freed@mrochek.com> Sun, 23 March 2008 21:18 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 E787A3A6BE7 for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Sun, 23 Mar 2008 14:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.565
X-Spam-Level:
X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=0.097, 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 prAc8stt1VfB for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Sun, 23 Mar 2008 14:18:36 -0700 (PDT)
Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 5A0203A6C13 for <sieve-archive-Aet6aiqu@ietf.org>; Sun, 23 Mar 2008 14:18:35 -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 m2NL6enr058002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Mar 2008 14:06:40 -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 m2NL6eid058001; Sun, 23 Mar 2008 14:06:40 -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 m2NL6dkb057987 for <ietf-mta-filters@imc.org>; Sun, 23 Mar 2008 14:06:39 -0700 (MST) (envelope-from ned.freed@mrochek.com)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; format="flowed"
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSRHURJX4G003LFF@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 23 Mar 2008 14:06:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSRA67GIRK00005Q@mauve.mrochek.com>; Sun, 23 Mar 2008 11:34:01 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-mta-filters@imc.org
Message-id: <01MSRCK0MPHS00005Q@mauve.mrochek.com>
Date: Sun, 23 Mar 2008 10:50:10 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Comments on draft-freed-sieve-environment-04
In-reply-to: "Your message dated Wed, 19 Mar 2008 02:01:52 -0600" <alpine.BSO.1.00.0803190129540.441@vanye.mho.net>
References: <alpine.BSO.1.00.0803190129540.441@vanye.mho.net>
To: Philip Guenther <guenther@sendmail.com>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206306376; h=Date: From:Subject:MIME-version:Content-type; b=KIwB0UdCPSn/fVDSZQWVqYeqJ 3MSx/k8BeLeYBBk+KYEAprHbzLBOfayahcLvZkGYMb+w/c2GAzk6sG7u4BLKw==
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>
> If the SMTP session was over IPv6, what should the "remote-ip" environment > item be set to? I would think that in this case it would obviously be the IPv6 address. However, I take your point that the format of such addresses needs to be specified - the underlying standards for address formats having failed to specify this with sufficient clarity or generality, it is now up to every application protocol where such addresses appear to deal with it separately. Sigh. Not the way it should be, but how it is. Perhaps there should be a prefix on the value that > indicates the address family, or it should be formatted like the 'host' > part of URI? > Note that the obvious test of > environment :matches "remote-ip" "*.*.*.*" > will match an IPv6 address literal if the implementation uses the > x:x:x:x:x:x:d.d.d.d > form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4". > (Yes, this thought was triggered by the "IPv6-only" experiment during the > IETF technical plenary.) Well, I certainly hope that for any given address there's exactly one way it will end up being represented. If that's not the case then there's a major problem that goes far beyond this specific issue. There's also the issue of how any future sort of address should be handled. Since RFC 2821 has already had to deal with this I think the best way to handle it is by referring to the formats defined there. I currently have: "remote-ip" => IP address of remote SMTP/LMTP/Submission client, if applicable and available. IPv4, IPv6, and other types of addresses are respectively represented in the formats defined by the IPv4-address-literal, IPv6-address-literal, and General-address-literal productions defined in [RFC 2821] section 4.1.3. > There probably should be a security consideration that explains that the > value of the "remote-host" item may be controlled by an untrusted source. > For example, the test > environment :matches "remote-host" "*.mydomain.com" > is *not* a good way to test whether the message came from 'outside' unless > the implementation there's some sort of IP->host->IP consistency check > made. 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: if environment :matches "remote-host" "*.mydomain.com" { ... } is not a good way to test whether the message came from 'outside' becaus anyone who can create a PTR record can create one that refers to whatever domain they choose. > (The sendmail MTA faced the above issues some time ago for the pre-defined > variables it provides to its rulesets. To quote the sendmail operations > guide, it defined variables as follows: > ${client_addr} > The IP address of the SMTP client. IPv6 > addresses are tagged with "IPv6:" before the > address. Defined in the SMTP server only. > ${client_name} > The host name of the SMTP client. This may be > the client's bracketed IP address in the form [ > nnn.nnn.nnn.nnn ] for IPv4 and [ > IPv6:nnnn:...:nnnn ] for IPv6 if the client's IP > address is not resolvable, or if it is resolvable > but the IP address of the resolved hostname > doesn't match the original IP address. Defined > in the SMTP server only. See also > ${client_resolve}. I think a simpler way to handle this is to say that the name will be blank if it cannot be resolved into a host name. How about: "remote-host" => Host name of remote SMTP/LMTP/Submission client, if applicable and available. The empty string will be returned if for some reason this information cannot be obtained for the current client. > ${client_ptr} > The result of the PTR lookup for the client IP > address. Note: this is the same as > ${client_name} if and only if ${client_resolve} > is OK. Defined in the SMTP server only. > ${client_resolve} > Holds the result of the resolve call for > ${client_name}. Possible values are: > OK resolved successfully > FAIL permanent lookup failure > FORGED forward lookup doesn't match reverse lookup > TEMP temporary lookup failure > Defined in the SMTP server only. sendmail > performs a hostname lookup on the IP address of > the connecting client. Next the IP addresses of > that hostname are looked up. If the client IP > address does not appear in that list, then the > hostname is maybe forged. This is reflected as > the value FORGED for ${client_resolve} and it > also shows up in $_ as "(may be forged)". > While client_ptr and client_resolve are probably overkill for the sieve > environment extension, the tagging in client_addr and precise definition > of when client_name contains a name and not an address literal seem like > practical guidance in this area.) I agree - see above for my proposed solution for this issue. 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