Re: external lists and spam protection
Ned Freed <ned.freed@mrochek.com> Mon, 08 October 2007 18:33 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l98IXiJ9070018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2007 11:33:44 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l98IXiXD070017; Mon, 8 Oct 2007 11:33:44 -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.13.5/8.13.5) with ESMTP id l98IXhra070010 for <ietf-mta-filters@imc.org>; Mon, 8 Oct 2007 11:33:43 -0700 (MST) (envelope-from ned.freed@mrochek.com)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MMA1UXJBCW00B7L2@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 8 Oct 2007 11:33:41 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MM9YAF7MA800BDC1@mauve.mrochek.com>; Mon, 08 Oct 2007 11:33:39 -0700 (PDT)
Cc: IETF Sieve WG <ietf-mta-filters@imc.org>
Message-id: <01MMA1UWH57E00BDC1@mauve.mrochek.com>
Date: Mon, 08 Oct 2007 09:51:20 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: external lists and spam protection
In-reply-to: "Your message dated Tue, 02 Oct 2007 00:09:55 +0200" <20071002000955.6x2veqixkcswwooo@mail.aegee.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="UTF-8"; DelSp="Yes"; format="flowed"
References: <20071002000955.6x2veqixkcswwooo@mail.aegee.org>
To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1191868421; h=Date: From:Subject:MIME-version:Content-type; b=AB9i9ns8nw63bNBPMzTXB6Xwz umkbn3OaAQaPx49/xcAt/PUyOit16C7iscowUdx55deP/spixk1rEDmSZ5jyQ==
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>
I'm glad you brought this up - I've been meaning to comment on this draft. > In the draft-melnikov-sieve-external-lists-01 I would like very > much to have two more tests: > Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] [:list] > <envelope-part: string-list> > <key-list: string-list> > where ADDRESS-PART can be :hostname and :hostip, near the usual :from > and :to. The :hostname and :hostip are substituted with the hostname > of the last host that sent the mail, and hostip is the IP of that > host. The idea is, that the script can check if the mail comes from an > unwanted host and reject it. The real application is, that the script > can check in an DNS blacklist, if the IP of the sending host is > present there and refuse the mail in this case. I think it will be > useful, once sieve scripts are executed during the smtp connection is > not closed - then every user could specify which DNS blacklists does > s/he want to make use of. I see what you're after here but to my mind this is a separate extension. Also, it doesn't really fit under envelope - getting at the remote host and IP seems to be a much better fit for the environment extension. Please see draft-freed-sieve-environment-01.txt when it comes out (should be any time now) and take a look at the remote-host and remote-ip environment items. > At the same time the :hostname and :hostip have no usage without > the external lists, therefore I suggest they are included here. I disagree. While they may be most useful when used with an external list, it's not at all unreasonable to have a script that checks this information for other reasons. > Question: what to do if an implementation has no access to the > information, or if a message is somehow not sent over smtp? The environment extension deals with this issue by having the test fail unconditionally. This makes it easy to test to see if an item is supported: if environment :matches "foo" "*" { code for when item foo is available } else { code for when it isn't } Note that unlike comparators there is presently no way to specify a specific environment item in a require clause or ihave test. I'm disinclined to provide one since whether or not some enviroment items are applicable depends more on, well, the current enviroment the script is executing in and not on the Sieve implementation. > Question: Does somebody have an idea, if spammers use one and the > same EHLO text to send mails, regardless of the sending host? In this > way envelope :helo would be useful as well. The HELO/EHLO parameter value is pretty much the definition of a boundary case. Since it is presented before the transaction starts you could say it really isn't part of the envelope. OTOH, it is almost always thought of as being part of it. My personal preference is to make getting the EHLO value an environment item as well, but that's mostly because it avoid the need to write up yet another envelope extension. But I could be convinced this isn't the way to go, which is why I haven't added it to the environment draft yet. Now, getting back to :list, I think this is a tremendously useful extension but it needs a little work. My first issue with it is that :list is currently defined as a new tagged argument orthogonal to any existing arguments. THis seems wrong - I think :list should instead be defined as a new MATCH-TYPE. I say this because it sems to me that :list only makes sense as a :is match - I want to be able to define lists using, say a dynamic LDAP URL where the list name simply gets shoved in to the URL somewhere. I for one don't see any way to support :contains for list names and :matches and :regex are truly scary. My second issue is that the lists it accesses are inherently single-column. I'd like to see the ability to look something up on a list and then get some property information back about the list entry that matched. I'd also like to have a way to get back information on what actually matched - remember that many of our tests check multiple things even if a list of things to check isn't specified. One way to do this that doesn't require any draft changes is to fold the property check into the list name. Suppose you have an external list of addresses "foo" that associates a status of "red", "green" or "yellow" with each address. This could be dealt with by defining "virtual" lists "foo-red", "foo-green" and "foo-yellow". But this rapidly gets unwieldy and also can result in scripts checking the same list more than once - not good if the list check is expensive, which it definitely can be. I believe the better way to do it is to have the test either have a way of specifying required propery values, have a way to return property values, and preferably both. (Note that the thing that matched can be thought of as a property.) The obvious change is to change this so that :list takes the list name or names as an argument and have the key-list match against a single returned property. But this really grots up the more common single-column case and doesn't solve the problem of getting the thing that matched back so I think it is a nonstarter. Another approach is to define a second tagged argument, say :property, that takes as its argument the value that the matching list's "property" has to have. Or you can have :propert take two arguments specifying the property name and value respectively if you want to support multiple properties. (I note in passing that it is trivial to map either form into an LDAP filter.) But while this is cleaner it still may result in scripts performing multiple queries against the same list - not good. And it doesn't provide a way to get back the item that matched - also not good. Variables provide the obvious way to get information back from :list. Suppose :list, like :match, were to set the ${0}, ${1} ... ${N} variables? ${0} would be given the value of the item that matched, ${1} would be the first associated property, ${2} would be its value, ${3} would be the second property name, and so on. So now you could write something like: require ["extlists", "variables", "reject"]; if address :domain :list "from" "known-domains" { set "domain" "${0}"; set "status "${2}"; if string "${status}" "bogus" { reject "From ${domain} is considered bogus"; } elsif string "${status}" "good" { keep; } } I prefer this last approach. The one drawback I see is that this does require variables support, but I reallly don't think that's overly onerous. > By the way, where is the changelog of draft-ietf-sieve-notify-xmpp-05 ? Sorry, can't help you with that. Ned
- external lists and spam protection Dilyan Palauzov
- Re: external lists and spam protection Ned Freed