From asrg-bounces@irtf.org Fri Jan 2 07:52:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43223A68B5; Fri, 2 Jan 2009 07:52:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8543A68B5 for ; Fri, 2 Jan 2009 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yhVrxrcTl3Xf for ; Fri, 2 Jan 2009 07:52:10 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 7ADFE3A6873 for ; Fri, 2 Jan 2009 07:52:10 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n02FpsXi028756 for ; Fri, 2 Jan 2009 10:51:55 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n02FhmN5019630 for ; Fri, 2 Jan 2009 10:43:48 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n02Fpmex029445 for ; Fri, 2 Jan 2009 10:51:48 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n02Fplmg029444 for asrg@irtf.org; Fri, 2 Jan 2009 10:51:47 -0500 Date: Fri, 2 Jan 2009 10:51:47 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090102155147.GA28581@gsp.org> References: <20081203143108.GA4549@gsp.org> <20081204115037.GA22266@gsp.org> <20081204152859.A5D3D24238@panix5.panix.com> <493802E7.8080306@nortel.com> <20081214202430.GF9303@gsp.org> <49458900.8010602@nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49458900.8010602@nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] A paper/project worth considering (found it!) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sun, Dec 14, 2008 at 05:30:24PM -0500, Chris Lewis wrote: > I don't understand this. I tried to explain this phenomena before. > Didn't you take statistics somewhere? Given that most of my graduate work was in statistical pattern recognition, I think that's safe to presume. ;-) > Let's say for sake of argument, AOL's users have a 5% error rate. 5% of > what they report via TIS isn't spam. That means, on average, 95 out of > 100 reports are accurate and it is spam. > > You have a FBL. But you don't send any spam, right? You only get your > share of the error rate, and none of the accurate ones - because you > don't send any spam. > > So, from your perspective, the TIS button is 100% wrong. For _you_ it > is. But it's NOT reflective of TIS hits against a network that sends spam. Of course not: you're correct. But it is reasonable to presume that a user population which has generated a 100% error rate on the FP side has also generated a substantial error rate on the FN side. (That is, there's no reason to think they're any more accurate one direction or the other.) > Are you contending that Comcast's or Yahoo's FBLs are yielding correct > TIS hits? Or do you have FBLs with them at all? Some of the operations I manage/consult to do. I haven't completed analysis of all those yet, so I'm quasi-reserving judgment. But so far, out of the data I *have* analyzed: 100% FPs. It'll be months before I'm done, I expect, because that's what it took to go through the AOL results with a mix of automated/manual processes, and to cross-check against logs, and so on. > What the TIS button does is help highlight situations where the > anti-spam filters aren't working. Perhaps. But I think all such instances need to be passed by a clueful, experienced human for manual review. That is, I think aggregating the data and presenting to a person with a note that says "there may be a problem here" is reaonable, but automated action based on end-user reports alone is a bad idea. I also think a much better approach -- which allows a higher degree of automation because it removes users from the equation -- is to run a large number of local and remote spamtraps. After all, if spammer X targets A local "real" users, then it seems reasonable to guess that X will also target B local spamtraps and perhaps C remote spamtraps. Correlation of data between all these makes it possible to identify at least some spammers before users ever get a chance to use the TIS button. (Yes, this is a methodology I use, and I use it based on connecting IP address alone -- that is, I ignore everything else. Any IP address connecting to a sufficient number of sufficiently-diverse MXs and attempting delivery to a sufficient number of spamtraps is up to no good and is treated as such.) ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 2 08:40:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61B528C0F5; Fri, 2 Jan 2009 08:40:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0045428C0EA for ; Fri, 2 Jan 2009 08:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.81 X-Spam-Level: X-Spam-Status: No, score=-14.81 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 ktNLxY7a8tPC for ; Fri, 2 Jan 2009 08:40:28 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id BF36E28C0E3 for ; Fri, 2 Jan 2009 08:40:27 -0800 (PST) Received: (qmail 62363 invoked from network); 2 Jan 2009 16:40:14 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Jan 2009 16:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=KJJf0LB2hkrxL67v2AT25GyuXsfA5x9t7Hz6ZrwQqxg=; b=bYlAbh2sA2+O6tvE+bE5v4YQeMNK/lQolCmhg3vvj+CydPOnCBp2ZCqc397eDOTyIypuLnT21FPcsDRDn0aSlcV0lit6ocT46mlY7oRpnb5rnndeYbH9Uqh9pTSaCx6EV24qKizUj2AcNYsSXjlJS5lGYzq3OOETFb/Xw/KPp+Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; bh=KJJf0LB2hkrxL67v2AT25GyuXsfA5x9t7Hz6ZrwQqxg=; b=mBgBGAC+eF+Mb/FQl98thXzkI8gdfFm6Zo6l7nWxjWFek0/k3EsSL6lGSRABHheqD58+yQfEe/RPjgumh37xVKpABLiRacEfLY2X5+Wlh3gSJd7qsnjjI1Ay8Fktgpn4HzuH0E2oiW3fAoj6QAHzXhwkryu95PxmRqqNQS84/iY= Date: 2 Jan 2009 16:40:13 -0000 Message-ID: <20090102164013.47121.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090102155147.GA28581@gsp.org> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] A paper/project worth considering (found it!) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> So, from your perspective, the TIS button is 100% wrong. For _you_ it >> is. But it's NOT reflective of TIS hits against a network that sends spam. > >Of course not: you're correct. But it is reasonable to presume that a >user population which has generated a 100% error rate on the FP side has >also generated a substantial error rate on the FN side. (That is, there's >no reason to think they're any more accurate one direction or the other.) Depends on your model of the sending population. It appears that you're in roughly the same situation I am, well-behaved individual users, perhaps some COI lists. With a population like that, the scenarios for valid complaints are pretty marginal, maybe a 'bot that takes its relay config from the local MUA, maybe a few list members who treat the spam button as unsubscribe. You're not going to get a lot of FNs if there's no spam to report. What that tells me is that the main use to us is that if there were a sudden burst of complaints, it would be a hint that something broke. You can't generalize from that to a sending stream which has enough complaint-worthy mail to generate a non-zero number of real complaints. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 2 08:40:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABD528C183; Fri, 2 Jan 2009 08:40:32 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C03028C17E for ; Fri, 2 Jan 2009 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 yIz13S7vOsTY for ; Fri, 2 Jan 2009 08:40:29 -0800 (PST) Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by core3.amsl.com (Postfix) with ESMTP id 404D128C0E3 for ; Fri, 2 Jan 2009 08:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1591; t=1230914417; x=1231778417; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20A=20paper/project=20worth=20co nsidering=20(found=20it!) |Sender:=20 |To:=20Anti-Spam=20Research=20Group=20-=20IRTF=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Lrb1gXOFsnpSuGl1gp4FLcW00YInDB0GoLVpIVfRHM8=; b=K0syl6KIXPuQH+AKoc+0yjOFRXPYl9EsmSxKyc66VJEeE04Yybhwtvc5eu 6AkBdpf0acfrDMUnGs9my0uDtaxfiUY5iLNgusIQewVgSrZaIluS32AzSKQx aul4Su1zhJRo/f9/8xACotcm5TGRrCUD8lIzkwh3cFGQPNS9W1nvc=; Received: from crabapple.local (63-170-118-237.dsl.volcano.net [63.170.118.237]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id n02GeFP4012915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jan 2009 08:40:16 -0800 Message-ID: <495E437A.4010707@mtcc.com> Date: Fri, 02 Jan 2009 08:40:26 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20081203143108.GA4549@gsp.org> <20081204115037.GA22266@gsp.org> <20081204152859.A5D3D24238@panix5.panix.com> <493802E7.8080306@nortel.com> <20081214202430.GF9303@gsp.org> <49458900.8010602@nortel.com> <20090102155147.GA28581@gsp.org> In-Reply-To: <20090102155147.GA28581@gsp.org> Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com Subject: Re: [Asrg] A paper/project worth considering (found it!) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > Perhaps. But I think all such instances need to be passed by a clueful, > experienced human for manual review. That is, I think aggregating the > data and presenting to a person with a note that says "there may be > a problem here" is reaonable, but automated action based on end-user > reports alone is a bad idea. > That makes lots of presumption about what the "automated action" encompasses. For me alone, hitting the TIS button is always 100% correct (modulo the occasional clumsy fingers). Therefore "automatically" putting the mail into the junk folder is 100% correct. For a larger population, your FP rate will clearly go up. Whether the FP rate is acceptable depends a whole lot on the population in question. One thing to consider here is that the population does not need to be monolithic on the order of a vast service provider's population. It can be subdivided into much smaller populations that are context relevant for *me*. That is, people who classify things like I do are likely to have a small FP rate from *my* point of view. If I get enough of those similar-classifiers, and especially with some diversity, their FP and FN rates are likely to be very good. Think of this as "people who hate junk like I hate junk hate this mail". I really wish people would stop with this absolutist nonsense that there is single definition of junk that if only we bred more spam-Mentats the world would be saved. People differ, as do their tastes, and dissing them because of that entirely misses the point. Mike _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 2 09:04:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421F83A695E; Fri, 2 Jan 2009 09:04:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2043A695E for ; Fri, 2 Jan 2009 09:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.036 X-Spam-Level: X-Spam-Status: No, score=-9.036 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 jSJ2LXTFUUqD for ; Fri, 2 Jan 2009 09:04:35 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 1C6393A6825 for ; Fri, 2 Jan 2009 09:04:34 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA25507; Fri, 2 Jan 2009 12:04:21 -0500 (EST) From: der Mouse Message-Id: <200901021704.MAA25507@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 2 Jan 2009 11:49:01 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090102155147.GA28581@gsp.org> References: <20081203143108.GA4549@gsp.org> <20081204115037.GA22266@gsp.org> <20081204152859.A5D3D24238@panix5.panix.com> <493802E7.8080306@nortel.com> <20081214202430.GF9303@gsp.org> <49458900.8010602@nortel.com> <20090102155147.GA28581@gsp.org> Subject: Re: [Asrg] A paper/project worth considering (found it!) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > But it is reasonable to presume that a user population which has > generated a 100% error rate on the FP side has also generated a > substantial error rate on the FN side. (That is, there's no reason > to think they're any more accurate one direction or the other.) Actually, I disagree. If you send no spam, every report you receive will be a FP; that is, you are guaranteed to see a 100% FP rate regardless of how accurate your recipient population is. (Well, unless they're 100% accurate, in which case you'll see no reports at all and your FP rate is undefined.) All your user accuracy will affect is the quantity of those reports. The only data you have on which to base even a wild guess at the FN rate for those users is the rate at which you receive FP reports as a fraction of the rate at which you send mail. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 4 06:50:55 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBCB3A6862; Sun, 4 Jan 2009 06:50:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8993A6862 for ; Sun, 4 Jan 2009 06:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[AWL=-2.021, BAYES_20=-0.74, MANGLED_LIPS=2.3, RCVD_IN_DNSWL_MED=-4] 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 n-+lQeRmurw0 for ; Sun, 4 Jan 2009 06:50:53 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 8ABDC3A6452 for ; Sun, 4 Jan 2009 06:50:53 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n04Eodks026484 for ; Sun, 4 Jan 2009 09:50:40 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n04EgRlr013538 for ; Sun, 4 Jan 2009 09:42:27 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n04EoXsl021108 for ; Sun, 4 Jan 2009 09:50:33 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n04EoXSN021107 for asrg@irtf.org; Sun, 4 Jan 2009 09:50:33 -0500 Date: Sun, 4 Jan 2009 09:50:33 -0500 From: Rich Kulawiec To: asrg@irtf.org Message-ID: <20090104145033.GA19110@gsp.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Asrg] Fwd: [matthias@LEISI.NET: MISC: How many legitimate SMTP senders?] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I found this a fascinating (and potentially important) question, and am doing some research to explore it further. I'm going to call it the Leisi Conjecture as a shorthand, and suggest that if it is correct within an order of magnitude, then this suggests that various approaches involving enumeration may be tractable. I'm writing up one now and will send it along once it's three-quarters-baked (as opposed to half-baked). ---Rsk ----- Forwarded message from Matthias Leisi ----- > Date: Sun, 4 Jan 2009 14:22:03 +0100 > From: Matthias Leisi > Subject: MISC: How many legitimate SMTP senders? > To: SPAM-L@PEACH.EASE.LSOFT.COM > > [I originally posted this to news.admin.net-abuse.blocklisting which > resulted in only a few feedback by email.] > > dnswl.org is currently approaching 50'000 individual IP/CIDR entries. > For a more realistic estimate about the number of legitimate SMTP > senders, we need to make a couple of adjustments: > > * subtract some legacy ranges in our DB which need to be phased out > * add the import queue of "IP addresses to potentially include" [1] > > Considering this, we arrive at a number of roughly 100'000 legitimate > SMTP senders (individual IP addresses) on todays' Internet, legitimate > being loosely defined as "speaks proper SMTP and has substantially more > ham than spam". > > Does this guesstimate match with yours? What is a meaningful error range > - ? 20%? Is it overall plausible? What would you base your estimate on? > > -- Matthias > > [1] IPs which have been seen used as SMTP senders, not listed on a > selection of blacklists, and has valid PTR ----- End forwarded message ----- _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 5 07:22:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A67F3A6864; Mon, 5 Jan 2009 07:22:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57593A6864 for ; Mon, 5 Jan 2009 07:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 eCOu8vZnITmE for ; Mon, 5 Jan 2009 07:22:16 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 572483A682C for ; Mon, 5 Jan 2009 07:22:16 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54034) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KD084Z-000BUG-2E for asrg@irtf.org; Mon, 05 Jan 2009 15:24:35 +0000 Date: Mon, 05 Jan 2009 15:22:02 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20081122134321.GA17923@gsp.org> References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> Originator-Info: login-token=Mulberry:01/M+MN2Uw+pw9POCZaPVvRP+qYketkV/1cTo=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 22 November 2008 08:43:21 -0500 Rich Kulawiec wrote: > On Thu, Nov 20, 2008 at 02:33:51PM +0000, Ian Eiloart wrote: >> The only thing that matters is that you can reach the system >> administrator for the domain that sent the email. Then you can assign >> reputation to the domain, and even to the email address used. > > But you can do that today -- well, by IP address, at least, which is > (as we've seen from the use of DNSBLs) nearly always good enough to > make accept/deny decisions WRT email. But that's not good enough. In fact it's crap. If I want to whitelist an organisation, I can't do it because there's no principled way in which I can know what IP address they're using to send email. I need to be able to whitelist the domain. As long as there's nothing to stop people spoofing the domain, the > > And *please* let's not try to assign reputations to individual email > addresses, as the scalability problems involved in N users with M email > addresses trying to track reputations of N users with M addresses, > given that N is on the order of 10e9, are awful. You don't have to have centralised reputation management for that. I can manage my own address based reputation database, once I know that email from a given address really is coming from the owner. > >> happens from there on is down to local policy - it'll depend on whether >> the domain belongs to an ISP, a university, an individual, or whatever. >> But, you'll be able to hold the domain admin responsible for the email. > > I see what you're saying but we can do this *today* by IP address (and > thus by extension) by network. In fact: we ARE doing it, and have been > for a long time. It works quite well, without the need to invent and > deploy any new technology. Well, it kind of works, but really really poorly. I've had business requests to whitelist certain domains and always resisted them because whitelisting a domain would simply open a hole in my anti-spamming measures. > Given that it's trivially easy to change domains (spammers go through > them by the thousands, and ICANN seems quite intent on making this even > easier and cheaper for them) That's irrelevant to whitelisting. And, reputation is earned so new domains have to work to build reputation. > but much more difficult to forge IP addresses > and change networks, it seems much better for anti-spam purposes to > focus on addresses and networks, and not on domains. > > But there's a more fundamental problem at work here. > > We have to take into account the presence of a few hundred million > 0wned systems -- whose new owners have the ability to immediately take > possession of any authentication credentials used on them, should > it please them to do so. > > So although we frequently refer to spam as "the problem", it's not > the problem -- it's merely a symptom of the problem. So, actually we've got two problems, given that SMTP has no mechanism for assigning accountability. Sure, endpoint security needs addressing, but part of the solution could be to reduce the attraction of 0wning systems by preventing those systems from spoofing sender addresses. > The problem is > a serious and fundamental lack of security on a very large number of > network endpoints. That problem remains unaddressed except in token > fashion, which is why it continues to get worse with no sign > of any turnaround in the forseeable future. (And multiple signs that > it could get much worse, i.e., the inclusion of DRM in popular OS > releases, meaning they're pre-compromised at the factory, so to speak.) > > Sure, we could argue "go ahead and do it anyway", but I think that's > not a good idea. The enemy reads these lists and the RFCs and the code, > too, and has long since demonstrated the capacity to wait until > something's deployed, then begin to exploit it. This is, by the way, one > of my deep concerns with anti-forgery technologies: it's my opinion that > widespread deployment of one will be followed shortly thereafter with > widespread exploitation: see "few hundred million 0wned systems" above, > and note that the absence of any reason to think that corporate or ISP or > government or university or any other networks are free of these. I'm > worried that if we begin deploying technology that trains users to > believe that email is REALLY from who/where it claims to be from, that > they will eventually accept that training...at which point forgeries > become much more dangerous than they are now, when we're training users > never to believe that anything is from who/where it claims to be. That's bogus. They already do believe that, in my experience. > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > https://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 8 12:10:42 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E943A692D; Thu, 8 Jan 2009 12:10:42 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF823A68F7 for ; Thu, 8 Jan 2009 12:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3CKXuUIw7+Pu for ; Thu, 8 Jan 2009 12:10:39 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 606EE3A6887 for ; Thu, 8 Jan 2009 12:10:39 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 188A6A94444 for ; Thu, 8 Jan 2009 20:10:24 +0000 (UTC) Message-Id: <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 8 Jan 2009 12:10:23 -0800 References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 5, 2009, at 7:22 AM, Ian Eiloart wrote: > --On 22 November 2008 08:43:21 -0500 Rich Kulawiec > wrote: > >> On Thu, Nov 20, 2008 at 02:33:51PM +0000, Ian Eiloart wrote: >>> The only thing that matters is that you can reach the system >>> administrator for the domain that sent the email. Then you can >>> assign reputation to the domain, and even to the email address used. >> >> But you can do that today -- well, by IP address, at least, which >> is (as we've seen from the use of DNSBLs) nearly always good enough >> to make accept/deny decisions WRT email. > > But that's not good enough. In fact it's crap. If I want to > whitelist an organisation, I can't do it because there's no > principled way in which I can know what IP address they're using to > send email. I need to be able to whitelist the domain. As long as > there's nothing to stop people spoofing the domain, There are methods that can be used to limit risks related to whitelisting domains. Often these involve capturing prior conversations and noting where the message originated. The locations might then be expanded to CIDRs, routes, or acquired address lists. >> And *please* let's not try to assign reputations to individual >> email addresses, as the scalability problems involved in N users >> with M email addresses trying to track reputations of N users with >> M addresses, given that N is on the order of 10e9, are awful. While that might appear to represent an unreasonable number, dealing with IPv6 might quickly exceed any reasonable magnitude when one attempts to resolve to individual IP addresses. DKIM on the other hand limits M to the number of DKIM signing domains with a reasonable reputation, where the i= parameter (the user) will likely be needed to deal with compromised or abused accounts which might be replayed. > You don't have to have centralised reputation management for that. I > can manage my own address based reputation database, once I know > that email from a given address really is coming from the owner. Yes you could. There are also services related to this effort, such as boxsentry, realmail which attempts to deal with the Asian and Middle Eastern markets. >>> happens from there on is down to local policy - it'll depend on >>> whether the domain belongs to an ISP, a university, an individual, >>> or whatever. But, you'll be able to hold the domain admin >>> responsible for the email. >> >> I see what you're saying but we can do this *today* by IP address >> (and thus by extension) by network. In fact: we ARE doing it, and >> have been for a long time. It works quite well, without the need >> to invent and deploy any new technology. > > Well, it kind of works, but really really poorly. I've had business > requests to whitelist certain domains and always resisted them > because whitelisting a domain would simply open a hole in my anti- > spamming measures. One must include more than a few parameters in order to do this safely. >> Given that it's trivially easy to change domains (spammers go >> through them by the thousands, and ICANN seems quite intent on >> making this even easier and cheaper for them) > > That's irrelevant to whitelisting. And, reputation is earned so new > domains have to work to build reputation. Agreed. In fact it would seem that email must start heading in the direction of white-listing. Such a direction however is politically problematic since this suggests email would no longer represent an open system. One method that might be tried would be for the network providers to register the routes they monitor for abuse related to various public protocols. Then at least only those routes would need to assessed, where the reputation of the network provider. This could help sustain the open nature of email a bit longer. >> but much more difficult to forge IP addresses and change networks, >> it seems much better for anti-spam purposes to focus on addresses >> and networks, and not on domains. But there's a more fundamental >> problem at work here. >> >> We have to take into account the presence of a few hundred million >> 0wned systems -- whose new owners have the ability to immediately >> take possession of any authentication credentials used on them, >> should it please them to do so. Agreed. Only the network providers are truly in a position to accurately monitor the abuse. Having some official open and public body establish a registry as to what the network providers are willing to protect should help. Currently, this is being done in opportunistically, and often based upon poorly managed reverse DNS address space that may not survive IPv6. >> So although we frequently refer to spam as "the problem", it's not >> the problem -- it's merely a symptom of the problem. > > So, actually we've got two problems, given that SMTP has no > mechanism for assigning accountability. Sure, endpoint security > needs addressing, but part of the solution could be to reduce the > attraction of 0wning systems by preventing those systems from > spoofing sender addresses. Any protocol has a mechanism for assigning accountability, BGP. :^) Things like DKIM should help find those that have a vested interest in preserving their reputations whenever the providers fail to curb problematic accounts. >> The problem is a serious and fundamental lack of security on a very >> large number of network endpoints. That problem remains >> unaddressed except in token fashion, which is why it continues to >> get worse with no sign of any turnaround in the forseeable future. >> (And multiple signs that it could get much worse, i.e., the >> inclusion of DRM in popular OS releases, meaning they're pre- >> compromised at the factory, so to speak.) One wonders whether a class action suit might prove helpful. How long must the Internet suffer from stodgy proprietary libraries supporting hundreds of class structures in desperate need of recompilation, or their merged settings which thwart untangling malware from critical functions. There are operating systems that do not build in the means to hide from fully privileged users, while still offering application functionality to restricted users. >> Sure, we could argue "go ahead and do it anyway", but I think >> that's not a good idea. The enemy reads these lists and the RFCs >> and the code, too, and has long since demonstrated the capacity to >> wait until something's deployed, then begin to exploit it. This >> is, by the way, one of my deep concerns with anti-forgery >> technologies: it's my opinion that widespread deployment of one >> will be followed shortly thereafter with widespread exploitation: >> see "few hundred million 0wned systems" above, and note that the >> absence of any reason to think that corporate or ISP or government >> or university or any other networks are free of these. Agreed. Any effort to consolidate accountability at the domain, which ADSP or Sender-ID attempts, clearly enables the next generation of victims where there is no practical mitigation. For this, there is a large industry making Band-Aids. :^( >> I'm worried that if we begin deploying technology that trains users >> to believe that email is REALLY from who/where it claims to be >> from, that they will eventually accept that training...at which >> point forgeries become much more dangerous than they are now, when >> we're training users never to believe that anything is from who/ >> where it claims to be. > > That's bogus. They already do believe that, in my experience. Huh? I suspect the next accepted communication scheme will depend upon SSL certified presences servers acting as gateway channels. SMTP will likely fade when people get tried of deleting spam. -Doug _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 8 12:44:42 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FAB3A6969; Thu, 8 Jan 2009 12:44:42 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6703A6969 for ; Thu, 8 Jan 2009 12:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 BDtSos2tvDUq for ; Thu, 8 Jan 2009 12:44:40 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id BC7AA3A6962 for ; Thu, 8 Jan 2009 12:44:40 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id n08KiHJ4004779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jan 2009 12:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1231447466; x=1231533866; bh=35aEZjuuBo4tl8v2/Z40yE6B6xBSAxZ1H9VSic87Pns=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=bH67XJAzwYKcZp33ycpWrFz8D5GTAvf/4qO6mgB2x0x0PZZlI5x4sCem/tPD0kGob jc4vN0CH+QlHSPH9mLW0EnGnZgcSY0WV2OKEJ+zsayXA8ryBBPb+RUP7i3q41JYMLB qK6vXOHyXry4ghqnuSTeMprr9kKQPmtOHIaQ+Fcs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=P1RPgpY3oX/eoSAbCsh64/o7w2R8ruqZO9OA+DRzBEyy08DhQ770sO7qotvBTO+Mk 5BLIMkg4bmCtBaLNcNxOmghSo+29xdqIsqjixzeBwQ9uGEaIlfZwmt0jrg8JP5RNd05 hV1G8W7RBq6iceMIeuIU5rboU81vTyKi+SUme5k= Message-Id: <6.2.5.6.2.20090108121600.02b28f88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Jan 2009 12:43:58 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> Mime-Version: 1.0 Subject: [Asrg] where the message originated (was: DKIM role?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 12:10 08-01-2009, Douglas Otis wrote: >There are methods that can be used to limit risks related to >whitelisting domains. Often these involve capturing prior >conversations and noting where the message originated. The locations >might then be expanded to CIDRs, routes, or acquired address lists. Is it that important to note where the message originated? Although the where is commonly used as input for lack of a better reference point, it can be a problem when renumbering a network or for mobility. Did this message reach you because: 1. it came from the irtf.org domain 2. it came from the ASRG email address 3. it came from an IP address associated with 1 or 2 4. it came from a CIDR block you view as "safe" Regards, -sm P.S. You may decide not to answer the above question to limit the risks related to whitelisting. _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 8 13:05:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236A63A6849; Thu, 8 Jan 2009 13:05:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03733A6849 for ; Thu, 8 Jan 2009 13:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 dfxBUl-TL2q5 for ; Thu, 8 Jan 2009 13:05:50 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 68E5B3A657C for ; Thu, 8 Jan 2009 13:05:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 3069964F837C for ; Fri, 9 Jan 2009 09:05:44 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl1cEUdp-7VE for ; Fri, 9 Jan 2009 09:05:42 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 0E38264F834A for ; Fri, 9 Jan 2009 09:05:42 +1200 (FJT) Date: Fri, 9 Jan 2009 09:05:41 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <620537.41231448732362.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <5025625.21231448509210.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated (was: DKIM role?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org on 4) for information there is this blocking list: http://www.uceprotect.net/en/rblcheck.php?ipr=202.170.42.206 but it tends to block by AS number and in the above case, AS9241 is the whole country of Fiji. Also as a note, I think dealing with high volume mail sender is not the issue, they are known, we know their technics, etc... it is more to deal with the long tail of little companies, organisations, small ISPs, etc.. ----- Original Message ----- From: "SM" To: "Anti-Spam Research Group - IRTF" Sent: Friday, 9 January, 2009 8:43:58 AM (GMT+1200) Auto-Detected Subject: [Asrg] where the message originated (was: DKIM role?) At 12:10 08-01-2009, Douglas Otis wrote: >There are methods that can be used to limit risks related to >whitelisting domains. Often these involve capturing prior >conversations and noting where the message originated. The locations >might then be expanded to CIDRs, routes, or acquired address lists. Is it that important to note where the message originated? Although the where is commonly used as input for lack of a better reference point, it can be a problem when renumbering a network or for mobility. Did this message reach you because: 1. it came from the irtf.org domain 2. it came from the ASRG email address 3. it came from an IP address associated with 1 or 2 4. it came from a CIDR block you view as "safe" Regards, -sm P.S. You may decide not to answer the above question to limit the risks related to whitelisting. _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org https://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 03:23:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E675728C0FE; Fri, 9 Jan 2009 03:23:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E078728C0FE for ; Fri, 9 Jan 2009 03:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 10kejU7Ng+vm for ; Fri, 9 Jan 2009 03:23:08 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A179E28C0E7 for ; Fri, 9 Jan 2009 03:23:07 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59747) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KD7BPZ-000JSW-MR for asrg@irtf.org; Fri, 09 Jan 2009 11:25:12 +0000 Date: Fri, 09 Jan 2009 11:22:51 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <778C8A65D98105C7AFCC9EE1@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> Originator-Info: login-token=Mulberry:01ETPGgHqUNOVSoBrifVmEqDnzd6vn2nRZhp4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 8 January 2009 12:10:23 -0800 Douglas Otis wrote: > > On Jan 5, 2009, at 7:22 AM, Ian Eiloart wrote: >> --On 22 November 2008 08:43:21 -0500 Rich Kulawiec >> wrote: >> >>> On Thu, Nov 20, 2008 at 02:33:51PM +0000, Ian Eiloart wrote: >>>> The only thing that matters is that you can reach the system >>>> administrator for the domain that sent the email. Then you can >>>> assign reputation to the domain, and even to the email address used. >>> >>> But you can do that today -- well, by IP address, at least, which >>> is (as we've seen from the use of DNSBLs) nearly always good enough >>> to make accept/deny decisions WRT email. >> >> But that's not good enough. In fact it's crap. If I want to >> whitelist an organisation, I can't do it because there's no >> principled way in which I can know what IP address they're using to >> send email. I need to be able to whitelist the domain. As long as >> there's nothing to stop people spoofing the domain, > > There are methods that can be used to limit risks related to whitelisting > domains. Often these involve capturing prior conversations and noting > where the message originated. The locations might then be expanded to > CIDRs, routes, or acquired address lists. "Greylisting"? Or something similar. Well, perhaps, but it seems complicated compared with SPF. I don't understand why there are banks that don't publish SPF records, for example. And, I'd like to be able to whitelist all .ac.uk domains when there's an SPF or DKIM match. Why? Well, I know that the domains are hard to register, that they have a relationship with my organisation, and as a rule I'll be able to contact a competent administrator if something goes wrong. The advantage of DKIM and SPF, of course, is that I don't have to guess about anything technical - like which IP addresses belong to a domain. .... -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 05:54:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1E23A686E; Fri, 9 Jan 2009 05:54:35 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBB03A686E for ; Fri, 9 Jan 2009 05:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 wKgOdMieTGGT for ; Fri, 9 Jan 2009 05:54:33 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 221863A67AB for ; Fri, 9 Jan 2009 05:54:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 2D7DB64F8384 for ; Sat, 10 Jan 2009 01:54:20 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDY+tpcO3E3V for ; Sat, 10 Jan 2009 01:54:14 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 8039364F8349 for ; Sat, 10 Jan 2009 01:54:14 +1200 (FJT) Date: Sat, 10 Jan 2009 01:54:14 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <4426106.01231509232749.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <778C8A65D98105C7AFCC9EE1@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 X-Originating-IP: [113.20.66.143] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org The beauty of DKIM is that the a federation of University could provide a DKIM signature for all UK education centers. Ensuring you are dealing with properly registered education centers. ----- Original Message ----- From: "Ian Eiloart" To: "Anti-Spam Research Group - IRTF" Sent: Friday, 9 January, 2009 11:22:51 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] DKIM role? "Greylisting"? Or something similar. Well, perhaps, but it seems complicated compared with SPF. I don't understand why there are banks that don't publish SPF records, for example. And, I'd like to be able to whitelist all .ac.uk domains when there's an SPF or DKIM match. Why? Well, I know that the domains are hard to register, that they have a relationship with my organisation, and as a rule I'll be able to contact a competent administrator if something goes wrong. The advantage of DKIM and SPF, of course, is that I don't have to guess about anything technical - like which IP addresses belong to a domain. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 06:59:25 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185433A6840; Fri, 9 Jan 2009 06:59:25 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D413A6840 for ; Fri, 9 Jan 2009 06:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 guHw3WUujeCn for ; Fri, 9 Jan 2009 06:59:23 -0800 (PST) Received: from corp-mail.e-dialog.com (corp-mail.e-dialog.com [64.28.75.202]) by core3.amsl.com (Postfix) with ESMTP id 28DCC3A67CF for ; Fri, 9 Jan 2009 06:59:23 -0800 (PST) Received: from jmac.e-dialog.com ([10.0.30.87]) by corp-mail.e-dialog.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 09:59:07 -0500 Date: Fri, 9 Jan 2009 09:59:07 -0500 From: Jeff Macdonald To: Anti-Spam Research Group - IRTF Message-ID: <20090109145907.GA5943@jmac.e-dialog.com> References: <778C8A65D98105C7AFCC9EE1@lewes.staff.uscs.susx.ac.uk> <4426106.01231509232749.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4426106.01231509232749.JavaMail.franck@franck-martins-macbook-pro.local> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 09 Jan 2009 14:59:07.0212 (UTC) FILETIME=[D20088C0:01C9726A] Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sat, Jan 10, 2009 at 01:54:14AM +1200, Franck Martin wrote: >The beauty of DKIM is that the a federation of University could >provide a DKIM signature for all UK education centers. Ensuring you >are dealing with properly registered education centers. What would such a DKIM signature look like? -- Jeff Macdonald jmacdonald@e-dialog.com _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 09:44:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8CB3A68A5; Fri, 9 Jan 2009 09:44:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8753A68A5 for ; Fri, 9 Jan 2009 09:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YKpltSzjzKrD for ; Fri, 9 Jan 2009 09:44:25 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AD0023A6403 for ; Fri, 9 Jan 2009 09:44:25 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F2BB5A94439 for ; Fri, 9 Jan 2009 17:44:11 +0000 (UTC) Message-Id: <6A7A07ED-3551-43B8-A440-6D9C2A9B88E9@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <6.2.5.6.2.20090108121600.02b28f88@resistor.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 9 Jan 2009 09:44:11 -0800 References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> <6.2.5.6.2.20090108121600.02b28f88@resistor.net> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] where the message originated (was: DKIM role?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 8, 2009, at 12:43 PM, SM wrote: > At 12:10 08-01-2009, Douglas Otis wrote: >> There are methods that can be used to limit risks related to >> whitelisting domains. Often these involve capturing prior >> conversations and noting where the message originated. The >> locations might then be expanded to CIDRs, routes, or acquired >> address lists. > > Is it that important to note where the message originated? Although > the where is commonly used as input for lack of a better reference > point, it can be a problem when renumbering a network or for mobility. White-listing based upon a domain would be dangerous without also including the IP address of the SMTP client and message tracking. There are companies currently providing this service, particularly needed where spam remains largely unmanaged. > Did this message reach you because: > > 1. it came from the irtf.org domain > > 2. it came from the ASRG email address > > 3. it came from an IP address associated with 1 or 2 > > 4. it came from a CIDR block you view as "safe" The algorithm can remain oblivious to who owns the SMTP client. It determines whether a conversation was observed, while also allowing also users to submit corrections. A reduction in the false positive detection of spam is achieved through conversation tracking. Some exceptions are needed to accommodate one-way traffic, which often represents transactional notifications. There are services doing this today by using two tiers of information. -Doug _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 12:34:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001763A6889; Fri, 9 Jan 2009 12:34:08 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569213A6889 for ; Fri, 9 Jan 2009 12:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kf9gVwCJt8RV for ; Fri, 9 Jan 2009 12:34:06 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0513D3A67EA for ; Fri, 9 Jan 2009 12:34:05 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id n09KXefL012515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 12:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1231533230; x=1231619630; bh=qy06zsP9CEiBMik0AQxmkwnp7B7eYwzOwGIu/OL5dns=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=pE8jchbSeHHYz4WvKhv9gR5JzTf8IPlT/C3GWq2mnfgYFTVXEmKnxI02C+jyhtjHX AoDMm62kPTaM1rTRlySi9JSugm8nzgW/YSH4t3OgOiohgx2hMOP5pFYtyvfo8lJFdr GlC2gcHyk8nvx0rWI3h0+muYLgCb5VXgnC8t0OY8= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=mOFzjMgLf04FQUdU5FjGQUJgE9Wuk4LTbuI4h6LtY78F2Nzsm050AqmVdKeDhpsUO OqF4qTs1koEw472bJlzxS5dSW534Lk5DxDMKKvkTLMeoZ5/+yP6ZAreiX2TAqgUb1rH IvutyubYcA92gF9dH6J86nqCxvbpCdjTjoyObUM= Message-Id: <6.2.5.6.2.20090109113345.030d80d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 09 Jan 2009 12:30:32 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <620537.41231448732362.JavaMail.franck@franck-martins-macbo ok-pro.local> References: <5025625.21231448509210.JavaMail.franck@franck-martins-macbook-pro.local> <620537.41231448732362.JavaMail.franck@franck-martins-macbook-pro.local> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 13:05 08-01-2009, Franck Martin wrote: >on 4) for information there is this blocking list: >http://www.uceprotect.net/en/rblcheck.php?ipr=202.170.42.206 > >but it tends to block by AS number and in the above case, AS9241 is >the whole country of Fiji. That shouldn't be a problem if you don't communicate with people from Fiji. :-) >Also as a note, I think dealing with high volume mail sender is not >the issue, they are known, we know their technics, etc... it is more >to deal with the long tail of little companies, organisations, small >ISPs, etc.. Some receivers may view these small organizations as statistically insignificant. These small organizations generally adopt antispam policies without analyzing whether such policies can have a negative impact on them in future. At 09:44 09-01-2009, Douglas Otis wrote: >White-listing based upon a domain would be dangerous without also >including the IP address of the SMTP client and message tracking. >There are companies currently providing this service, particularly >needed where spam remains largely unmanaged. The question was whether it is important to note where the message came from. I take it that your answer is yes. >The algorithm can remain oblivious to who owns the SMTP client. It >determines whether a conversation was observed, while also allowing >also users to submit corrections. That only works as long as the two end-points for the conversation are static. Such a constraint is only acceptable to users until they move around and experience a communication failure. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 9 13:00:18 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B9F3A6403; Fri, 9 Jan 2009 13:00:18 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDAC3A6403 for ; Fri, 9 Jan 2009 13:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 TLqBJ747ZHgp for ; Fri, 9 Jan 2009 13:00:10 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id D7C6F3A63D2 for ; Fri, 9 Jan 2009 13:00:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 0408564F8384 for ; Sat, 10 Jan 2009 09:00:01 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skzbObywJLML for ; Sat, 10 Jan 2009 08:59:56 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id BA3E864F8383 for ; Sat, 10 Jan 2009 08:59:56 +1200 (FJT) Date: Sat, 10 Jan 2009 08:59:56 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <6590037.561231534772628.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <4631314.541231534591697.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [113.20.66.143] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] DKIM role? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org http://www.dkim.org/specs/rfc4871-dkimbase.html 4.1 Example Scenarios There are many reasons why a message might have multiple signatures. For example, a given signer might sign multiple times, perhaps with different hashing or signing algorithms during a transition phase. 5.1 Determine Whether the Email Should Be Signed and by Whom A signer can obviously only sign email for domains for which it has a private key and the necessary knowledge of the corresponding public key and selector information. ---------------- But more important: ---------------- i= Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag). The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as or a subdomain of the value of the "d=" tag. INFORMATIVE DISCUSSION: This document does not require the value of the "i=" tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the "i=" tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options. ---------------- So i= and d= can be from a totally different domain than the email is sent from. As long as the MTA has the private key and can use it to sign. ----- Original Message ----- From: "Jeff Macdonald" To: "Anti-Spam Research Group - IRTF" Sent: Saturday, 10 January, 2009 2:59:07 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] DKIM role? On Sat, Jan 10, 2009 at 01:54:14AM +1200, Franck Martin wrote: >The beauty of DKIM is that the a federation of University could >provide a DKIM signature for all UK education centers. Ensuring you >are dealing with properly registered education centers. What would such a DKIM signature look like? -- Jeff Macdonald jmacdonald@e-dialog.com _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 10 19:18:55 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A2F3A6924; Sat, 10 Jan 2009 19:18:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F903A6924 for ; Sat, 10 Jan 2009 19:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 3D40dPEGPGlg for ; Sat, 10 Jan 2009 19:18:52 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by core3.amsl.com (Postfix) with ESMTP id 7CF403A682E for ; Sat, 10 Jan 2009 19:18:52 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with SMTP id 5828096A02F for ; Sun, 11 Jan 2009 03:18:37 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 10, 1, 0, 34cd709878fb81d9, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:2:355:379:599:601:854:960:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1431:1437:1515:1516:1518:1535:1593:1594:1605:1730:1747:1766:1792:2196:2199:2378:2379:2393:2525:2540:2553:2561:2564:2682:2685:2691:2693:2705:2730:2733:2736:2741:2745:2828:2857:2859:2892:2899:2900:2901:2914:2917:2920:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3657:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4117:4250:4321:4659:5007:6114:6117:6248:6996:6997:7576:7652:7679:7809:7875:7903:7914:7974:8501:8599:8985:8987:9010:9025:9040:9149:9388, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf04.hostedemail.com (Postfix) with ESMTP for ; Sun, 11 Jan 2009 03:18:36 +0000 (UTC) Message-ID: <4969650A.7010006@terabites.com> Date: Sat, 10 Jan 2009 21:18:34 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org References: In-Reply-To: X-session-marker: 6765703261407465726162697465732E636F6D Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org It is important to remember that many individuals and many small companies use personal or "vanity" domain names. These domain names appear in their "From:" and "Reply-to:" addresses on their outgoing e-mail messages, but SHOULD NOT be presumed to indicate where the e-mail in question is arriving from. For example, I might be travelling somewhere and sending e-mail messages from an inhabitual location: a cruise ship Internet cafe, an Internet access kiosk above a post office location in Beijing, a coffee bar, or other such public-access location. In such a situation, I will typically have NO control over what outgoing mail server is sending my e-mail message, and since my being there is temporary I obviously don't want to put a return address on my mail that would be connected with the location where I physically am at the time. Another example is where a small company also uses a company domain name, although they might use very different mail handling for their outgoing staff e-mail messages (for example, which might go through a nearby ISP, often for historical reasons) as compared to their automatically generated e-mails (example: invoices, price quotations, EFT transfer notices, and the like) generated by their back-office accounting systems... which might be sent directly by outgoing mail servers inside their NAT router. We've several times been hurt by stupid antispam approaches which refuse perfectly legitimate e-mails because they don't like the IP address they are coming from. Another problem we have had is when we were sending company E-mails through the outgoing mail server provided by our domain hosting company, and one of the (tens of thousands) of companies they were hosting domains for apparently became infected and began sending messages containing a virus or something. The result was that ALL the companies forwarding through that outgoing mail server became blocked, even though our company (and, I'm sure, most of the companies using that same shared outgoing mail server) was never infected or compromised. While we're talking about the issue of antispam nuisances, another is the situation where a spam blocker inadvertently serves as an "IP address laundering agent" when they bounce back a message detected as containing spam, or a virus. It is particularly stupid to bounce back a message because it is detected to contain a virus WHICH IS KNOWN TO FALSIFY OR COUNTERFEIT THE RETURN ADDRESS! In that case, the spam blocker sending the 'bounce'/refused message does not know where the original message was ACTUALLY sent from; commonly they will send the bounce message to the COUNTERFEIT "from" address (n.b. the address the original spammer ACTUALLY wanted to send the message to!) only now, it arrives from a "clean" IP address (i.e. the IP address of the antispam blocker which "bounced" it) rather than from the IP address actually originating the message (which the actually intended recipient might have refused, based on the sender IP address). So now the unwanted message arrives at its intended destination, having "reflected" off a spam reflector and thus now with a "reputable" IP address. (True, it is now shown as an "undeliverable/spam/virus" bounce, but a lot of people DO open such messages). ...ANYHOW, PARTICULARLY when a message is sent by a virus KNOWN to falsify origin addresses, it is NOT helpful to send a bounce message back to the "bogus" "origin" address indicated in the message. I have a folder here with probably something approaching a hundred thousand such bounces, caused by spam messages which were sent using bogus/falsified addresses but counterfeiting one of my domains, and where these messages did not originate from any of my systems. The point is that there is NO value in sending back a bounceback/refused message unless you are SURE you know where it should be sent back to (i.e. who actually sent it). It's NOT enough to just believe the "From:" address. > Subject: Re: [Asrg] where the message originated (was: DKIM role?) > To: Anti-Spam Research Group - IRTF > Message-ID: <6.2.5.6.2.20090109113345.030d80d0@resistor.net> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 13:05 08-01-2009, Franck Martin wrote: >> on 4) for information there is this blocking list: >> http://www.uceprotect.net/en/rblcheck.php?ipr=202.170.42.206 >> >> but it tends to block by AS number and in the above case, AS9241 is >> the whole country of Fiji. > > That shouldn't be a problem if you don't communicate with people from Fiji. :-) > >> Also as a note, I think dealing with high volume mail sender is not >> the issue, they are known, we know their technics, etc... it is more >> to deal with the long tail of little companies, organisations, small >> ISPs, etc.. > > Some receivers may view these small organizations as statistically > insignificant. These small organizations generally adopt antispam > policies without analyzing whether such policies can have a negative > impact on them in future. > > At 09:44 09-01-2009, Douglas Otis wrote: >> White-listing based upon a domain would be dangerous without also >> including the IP address of the SMTP client and message tracking. >> There are companies currently providing this service, particularly >> needed where spam remains largely unmanaged. > > The question was whether it is important to note where the message > came from. I take it that your answer is yes. > >> The algorithm can remain oblivious to who owns the SMTP client. It >> determines whether a conversation was observed, while also allowing >> also users to submit corrections. > > That only works as long as the two end-points for the conversation > are static. Such a constraint is only acceptable to users until they > move around and experience a communication failure. > > Regards, > -sm -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 10 20:04:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720593A6A7E; Sat, 10 Jan 2009 20:04:16 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6083A6A7E for ; Sat, 10 Jan 2009 20:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] 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 cJC9RcRZoRTZ for ; Sat, 10 Jan 2009 20:04:14 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id BBF7E3A682D for ; Sat, 10 Jan 2009 20:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4C28664F8384 for ; Sun, 11 Jan 2009 16:03:58 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWbV7l6wytvC for ; Sun, 11 Jan 2009 16:03:52 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 22C1D64F8383 for ; Sun, 11 Jan 2009 16:03:52 +1200 (FJT) Date: Sun, 11 Jan 2009 16:03:52 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <13300747.21231646591500.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <16499295.01231646463236.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [113.20.68.204] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org In my experience, people are not able to modify their software to change the default smtp server. It seems more efficient to have them connect back via SMTPS+AUTH to the company mailserver and send their email that way. Now, some webmail providers allows you to haev multiple reply-to address, that you use depending on your location. This is nice but then we fall in the categories listed below, and I'm not sure that DKIM provide a meaningful authentication of the reply-to address. ----- Original Message ----- From: "Gordon Peterson" To: asrg@irtf.org Sent: Sunday, 11 January, 2009 3:18:34 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) It is important to remember that many individuals and many small companies use personal or "vanity" domain names. These domain names appear in their "From:" and "Reply-to:" addresses on their outgoing e-mail messages, but SHOULD NOT be presumed to indicate where the e-mail in question is arriving from. For example, I might be travelling somewhere and sending e-mail messages from an inhabitual location: a cruise ship Internet cafe, an Internet access kiosk above a post office location in Beijing, a coffee bar, or other such public-access location. In such a situation, I will typically have NO control over what outgoing mail server is sending my e-mail message, and since my being there is temporary I obviously don't want to put a return address on my mail that would be connected with the location where I physically am at the time. Another example is where a small company also uses a company domain name, although they might use very different mail handling for their outgoing staff e-mail messages (for example, which might go through a nearby ISP, often for historical reasons) as compared to their automatically generated e-mails (example: invoices, price quotations, EFT transfer notices, and the like) generated by their back-office accounting systems... which might be sent directly by outgoing mail servers inside their NAT router. We've several times been hurt by stupid antispam approaches which refuse perfectly legitimate e-mails because they don't like the IP address they are coming from. Another problem we have had is when we were sending company E-mails through the outgoing mail server provided by our domain hosting company, and one of the (tens of thousands) of companies they were hosting domains for apparently became infected and began sending messages containing a virus or something. The result was that ALL the companies forwarding through that outgoing mail server became blocked, even though our company (and, I'm sure, most of the companies using that same shared outgoing mail server) was never infected or compromised. While we're talking about the issue of antispam nuisances, another is the situation where a spam blocker inadvertently serves as an "IP address laundering agent" when they bounce back a message detected as containing spam, or a virus. It is particularly stupid to bounce back a message because it is detected to contain a virus WHICH IS KNOWN TO FALSIFY OR COUNTERFEIT THE RETURN ADDRESS! In that case, the spam blocker sending the 'bounce'/refused message does not know where the original message was ACTUALLY sent from; commonly they will send the bounce message to the COUNTERFEIT "from" address (n.b. the address the original spammer ACTUALLY wanted to send the message to!) only now, it arrives from a "clean" IP address (i.e. the IP address of the antispam blocker which "bounced" it) rather than from the IP address actually originating the message (which the actually intended recipient might have refused, based on the sender IP address). So now the unwanted message arrives at its intended destination, having "reflected" off a spam reflector and thus now with a "reputable" IP address. (True, it is now shown as an "undeliverable/spam/virus" bounce, but a lot of people DO open such messages). ...ANYHOW, PARTICULARLY when a message is sent by a virus KNOWN to falsify origin addresses, it is NOT helpful to send a bounce message back to the "bogus" "origin" address indicated in the message. I have a folder here with probably something approaching a hundred thousand such bounces, caused by spam messages which were sent using bogus/falsified addresses but counterfeiting one of my domains, and where these messages did not originate from any of my systems. The point is that there is NO value in sending back a bounceback/refused message unless you are SURE you know where it should be sent back to (i.e. who actually sent it). It's NOT enough to just believe the "From:" address. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 11 00:44:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325973A67F4; Sun, 11 Jan 2009 00:44:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6083D3A67F4 for ; Sun, 11 Jan 2009 00:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6] 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 CEviVWy23hfc for ; Sun, 11 Jan 2009 00:44:03 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 346DC3A67A7 for ; Sun, 11 Jan 2009 00:44:03 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sun, 11 Jan 2009 09:43:45 +0100 id 00000000005DC031.000000004969B141.00006FCC Message-ID: <4969B141.5020906@tana.it> Date: Sun, 11 Jan 2009 09:43:45 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4969650A.7010006@terabites.com> In-Reply-To: <4969650A.7010006@terabites.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Gordon Peterson wrote: > For example, I might be travelling somewhere and sending e-mail messages > from an inhabitual location: a cruise ship Internet cafe, an Internet > access kiosk above a post office location in Beijing, a coffee bar, or > other such public-access location. In such a situation, I will > typically have NO control over what outgoing mail server is sending my > e-mail message, and since my being there is temporary I obviously don't > want to put a return address on my mail that would be connected with the > location where I physically am at the time. That's a hopeless setting. If you carry a laptop, SMTP+AUTH to the company server is the way to go, as Franck said already. If not, assuming you won't configure an email client, you should use company's webmail server. You are not going to store your userid/password at an unknown box, are you? Thus, you should connect to your outgoing server in the same way that you connect to your incoming one. > Another example is where a small company also uses a company domain > name, although they might use very different mail handling for their > outgoing staff e-mail messages (for example, which might go through a > nearby ISP, often for historical reasons) as compared to their > automatically generated e-mails (example: invoices, price quotations, > EFT transfer notices, and the like) generated by their back-office > accounting systems... which might be sent directly by outgoing mail > servers inside their NAT router. Same comments as above apply. However, for vanity addresses the company's MX just forwards to each employee's actual address. In that case, outgoing mail should also originate from each employee's ESP. The company's SPF record, if any, should take that into account. The historical ISP habit to allow relaying from their own IP addresses since clients already authenticated on connecting, has had its day. > We've several times been hurt by stupid antispam approaches which refuse > perfectly legitimate e-mails because they don't like the IP address they > are coming from. > > Another problem we have had is when we were sending company E-mails > through the outgoing mail server provided by our domain hosting company, > and one of the (tens of thousands) of companies they were hosting > domains for apparently became infected and began sending messages > containing a virus or something. The result was that ALL the companies > forwarding through that outgoing mail server became blocked, even though > our company (and, I'm sure, most of the companies using that same shared > outgoing mail server) was never infected or compromised. Obviously there are the same problems when sharing cars, buildings, and sex mates: whoever catches accidents or infections affects everybody else... > While we're talking about the issue of antispam nuisances, another is > the situation where a spam blocker inadvertently serves as an "IP > address laundering agent" when they bounce back a message detected as > containing spam, or a virus. It is particularly stupid to bounce back a > message because it is detected to contain a virus WHICH IS KNOWN TO > FALSIFY OR COUNTERFEIT THE RETURN ADDRESS! Correct. The anti-virus filter should just swallow the message with no complains nor notices. I don't know what RFC blesses that behavior, though. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 11 13:57:26 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBDD3A68B0; Sun, 11 Jan 2009 13:57:26 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902BA3A68B0 for ; Sun, 11 Jan 2009 13:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 gUeNNPU-+SHc for ; Sun, 11 Jan 2009 13:57:24 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by core3.amsl.com (Postfix) with ESMTP id 5A8593A6866 for ; Sun, 11 Jan 2009 13:57:24 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 6A497164C2CE for ; Sun, 11 Jan 2009 21:57:08 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 10, 1, 0, 8f5ae624ff48b4aa, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:2:355:379:392:408:599:854:946:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1593:1594:1605:1606:1730:1747:1766:1792:2393:2525:2560:2563:2682:2685:2693:2705:2730:2733:2736:2741:2745:2828:2857:2859:2890:2900:2901:2914:2917:2920:2924:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3313:3636:3653:3657:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4042:4117:4250:4321:4401:4427:4659:5007:6114:6119:7576:7652:7679:7754:7809:7903:7974:8501:8985:9025:9040, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf05.hostedemail.com (Postfix) with ESMTP for ; Sun, 11 Jan 2009 21:57:07 +0000 (UTC) Message-ID: <496A6B33.4010606@terabites.com> Date: Sun, 11 Jan 2009 15:57:07 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org X-session-marker: 6765703261407465726162697465732E636F6D Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > > For example, I might be travelling somewhere and sending e-mail messages > > from an inhabitual location: a cruise ship Internet cafe, an Internet > > access kiosk above a post office location in Beijing, a coffee bar, or > > other such public-access location. In such a situation, I will > > typically have NO control over what outgoing mail server is sending my > > e-mail message, and since my being there is temporary I obviously don't > > want to put a return address on my mail that would be connected with the > > location where I physically am at the time. > That's a hopeless setting. If you carry a laptop, SMTP+AUTH to the company server is the way to go, as Franck said already. That's precisely the point. I am not using my habitual mail client, nor am I using my own familiar webmail service. I am using a mail kiosk-type service which allows me to enter a subject, my return address, a to address, and the body of my mail. > If not, assuming you won't configure an email client, you should use company's webmail server. That's not an option, and nor can I configure what e-mail server is being used. > You are not going to store your userid/password at an unknown box, are you? No, of course not. And they don't ask for that. The mail message doesn't go out through my normal e-mail channels, and that's just exactly the point. > Thus, you should connect to your outgoing server in the same way that you connect to your incoming one. Again, that's not one of the options available. When you're travelling on a ship, understandably they want to have you send your mail through the ship's own outgoing mail server, since that minimizes the time they have to keep the (very expen$ive) satellite channel open. > > Another example is where a small company also uses a company domain > > name, although they might use very different mail handling for their > > outgoing staff e-mail messages (for example, which might go through a > > nearby ISP, often for historical reasons) as compared to their > > automatically generated e-mails (example: invoices, price quotations, > > EFT transfer notices, and the like) generated by their back-office > > accounting systems... which might be sent directly by outgoing mail > > servers inside their NAT router. > Same comments as above apply. However, for vanity addresses the company's MX just forwards to each employee's actual address. In that case, outgoing mail should also originate from each employee's ESP. The company's SPF record, if any, should take that into account. And again, that's okay, WHEN THEY ARE MAILING FROM IN-HOUSE. When they are not, is when the problem turns up. > The historical ISP habit to allow relaying from their own IP addresses since clients already authenticated on connecting, has had its day. That's not really the issue. The issue is that people occasionally have very legitimate need to send mail other than through their normal channels, PARTICULARLY when away from the office (at home, perhaps, although sending a mail that's work-related; from a library or airpport public access terminal; at a customer location; and particularly when traveling out of the country.) > > We've several times been hurt by stupid antispam approaches which refuse > > perfectly legitimate e-mails because they don't like the IP address they > > are coming from. > > > > Another problem we have had is when we were sending company E-mails > > through the outgoing mail server provided by our domain hosting company, > > and one of the (tens of thousands) of companies they were hosting > > domains for apparently became infected and began sending messages > > containing a virus or something. The result was that ALL the companies > > forwarding through that outgoing mail server became blocked, even though > > our company (and, I'm sure, most of the companies using that same shared > > outgoing mail server) was never infected or compromised. > Obviously there are the same problems when sharing cars, buildings, and sex mates: whoever catches accidents or infections affects everybody else... In this case, however, the overly-broad-brush of poisoning ALL traffic transiting an IP address just because it has sent "some" unwanted or malicious mail can create a GREAT deal of serious collateral damage. > > While we're talking about the issue of antispam nuisances, another is > > the situation where a spam blocker inadvertently serves as an "IP > > address laundering agent" when they bounce back a message detected as > > containing spam, or a virus. It is particularly stupid to bounce back a > > message because it is detected to contain a virus WHICH IS KNOWN TO > > FALSIFY OR COUNTERFEIT THE RETURN ADDRESS! > Correct. The anti-virus filter should just swallow the message with no complains nor notices. I don't know what RFC blesses that behavior, though. It is very frustrating to get (sometimes hundreds a day) bounce messages that come back to my domain (catch-all address mailbox) for e-mail messages which *I* NEVER SENT, just because the spammers' From: address used a counterfeit/bogus e-mail address forging one of my domains. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 11 14:39:45 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A993A6AED; Sun, 11 Jan 2009 14:39:44 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01E93A6AED for ; Sun, 11 Jan 2009 14:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.832 X-Spam-Level: X-Spam-Status: No, score=-14.832 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 OpK4n9x+13dK for ; Sun, 11 Jan 2009 14:39:39 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 16E503A67CC for ; Sun, 11 Jan 2009 14:39:38 -0800 (PST) Received: (qmail 21935 invoked by uid 100); 11 Jan 2009 22:39:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=W6Bsx70lbODoWIpliSDZxj5HQhrrT4wCt5D49Lwopoc=; b=GcL1pjf3EgqbvrO/9iclIIcMkswFMB273iZ6Pklym92+9eP33vv/0+4EF50I3rnIsWeph6ca4UYz6aaqIxGHI9RC0Ee0H3U73/zAVUKTm4D8JE85WGi5Z3XTn8IOTZVJ4CpJsBDT00MEK0F2+ASjm0EUiIzYKZlDummSLuJp4fE= Date: 11 Jan 2009 22:39:23 -0000 Message-ID: <20090111223923.21933.qmail@gal.iecc.com> From: John Levine To: asrg@ietf.org In-Reply-To: <496A6B33.4010606@terabites.com> Organization: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >That's precisely the point. I am not using my habitual mail client, nor >am I using my own familiar webmail service. I am using a mail >kiosk-type service which allows me to enter a subject, my return >address, a to address, and the body of my mail. Yeah, it's just one more way that the bad guys have screwed up mail for everyone else. The trickle of mail with random to and from addresses coming out of a mail kiosk is pretty much indistinguishable from a zombie, so it's not surprising that they have trouble getting mail through. Poorly conceived path authentication systems like SPF don't help, since they encourage people to claim that their mail can only come from their usual server. Assuming DKIM gets traction, I can see that kiosk vendors will sign all their mail with the kiosk's domain which will, with luck, get a good enough reputation that receivers will say, oh, that's KioskCo, their mail is OK. (This is an example, by the way, of the reason that finer grain reputation is not always better.) In the meantime, if you want to send mail while you're on the road, you better either get a laptop with a MUA configured to relay through home, or web mail. > > If not, assuming you won't configure an email client, you should use >company's webmail server. > >That's not an option, and nor can I configure what e-mail server is >being used. Too bad. I think it would be clearer to say that whoever runs your mail system doesn't consider the problem of sending mail on the road to be serious enough to fix. >In this case, however, the overly-broad-brush of poisoning ALL traffic >transiting an IP address just because it has sent "some" unwanted or >malicious mail can create a GREAT deal of serious collateral damage. Quite true. See comments above. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 02:29:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D8C3A69B4; Mon, 12 Jan 2009 02:29:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2A83A69B4 for ; Mon, 12 Jan 2009 02:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 G4sk2iMuW6tp for ; Mon, 12 Jan 2009 02:29:45 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id E04F33A67D8 for ; Mon, 12 Jan 2009 02:29:44 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49842) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDCT9I-0003IW-9V for asrg@irtf.org; Mon, 12 Jan 2009 10:32:06 +0000 Date: Mon, 12 Jan 2009 10:29:26 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <6A7A07ED-3551-43B8-A440-6D9C2A9B88E9@mail-abuse.org> References: <20081119121300.GA24776@gsp.org> <1382266.121227096977339.JavaMail.franck@franck-martins-macbook-pro.local> <20081119133334.GA6213@gsp.org> <11338BA65CCF9225B4C80B5F@lewes.staff.uscs.susx.ac.uk> <20081119215637.GB16867@gsp.org> <20081122134321.GA17923@gsp.org> <621901AD-55D0-4542-BCEB-2098451F1838@mail-abuse.org> <6.2.5.6.2.20090108121600.02b28f88@resistor.net> <6A7A07ED-3551-43B8-A440-6D9C2A9B88E9@mail-abuse.org> Originator-Info: login-token=Mulberry:015fiFkE5Z8/UmZdnyUR5YbfgDS3Cm6kgeWmM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 9 January 2009 09:44:11 -0800 Douglas Otis wrote: > > On Jan 8, 2009, at 12:43 PM, SM wrote: > >> At 12:10 08-01-2009, Douglas Otis wrote: >>> There are methods that can be used to limit risks related to >>> whitelisting domains. Often these involve capturing prior >>> conversations and noting where the message originated. The >>> locations might then be expanded to CIDRs, routes, or acquired >>> address lists. >> >> Is it that important to note where the message originated? Although >> the where is commonly used as input for lack of a better reference >> point, it can be a problem when renumbering a network or for mobility. > > White-listing based upon a domain would be dangerous without also > including the IP address of the SMTP client and message tracking. There > are companies currently providing this service, particularly needed where > spam remains largely unmanaged. > Absolutely. That's the point of SPF and DKIM. The reason that I don't whitelist sender domains or addresses is that they're so easy to forge at the moment. With deployment of SPF and DKIM, there are domains that I'd be willing to whitelist given either a good SPF or DKIM match. In fact, there are top level domains like .edu, .gov, .ac.uk, .gov.uk, .sch.uk, .coop, and so on that I'd be prepared to conditionally whitelist because the registration process is tougher - though I might find myself making exceptions if certain subdomains didn't behave reasonably. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 02:58:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA893A6A26; Mon, 12 Jan 2009 02:58:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4449228C2E6 for ; Mon, 12 Jan 2009 02:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 1bExF0J08xwb for ; Mon, 12 Jan 2009 02:58:48 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 5D6DB3A6A1F for ; Mon, 12 Jan 2009 02:58:48 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 12 Jan 2009 11:58:32 +0100 id 00000000005DC03A.00000000496B2258.000036E5 Message-ID: <496B2258.8070206@tana.it> Date: Mon, 12 Jan 2009 11:58:32 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090111223923.21933.qmail@gal.iecc.com> In-Reply-To: <20090111223923.21933.qmail@gal.iecc.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: >> That's precisely the point. I am not using my habitual mail >> client, nor am I using my own familiar webmail service. I am >> using a mail kiosk-type service which allows me to enter a >> subject, my return address, a to address, and the body of my >> mail. It must be noted that being able to write but not to read one's mail _is_ an abnormal situation, subject to severe restrictions. For one, it breaks any address checking scheme. > Assuming DKIM gets traction, I can see that kiosk vendors will sign > all their mail with the kiosk's domain which will, with luck, get > a good enough reputation that receivers will say, oh, that's > KioskCo, their mail is OK. However, anyone can write "Gordon Peterson " on that box's return address field. Do we really want that to be signed? Gordon Peterson wrote: >> When you're traveling on a ship, understandably they want to >> have you send your mail through the ship's own outgoing mail >> server, since that minimizes the time they have to keep the (very >> expen$ive) satellite channel open. Nowadays there are satellite links whose costs are comparable to ADSL. I'd reckon broadly available MSAs is the way to go. A somewhat similar deceptive saving occasion used to be office MTAs. Since most of the traffic is embodied by office-to-office messages, one reasoned, it is a waste to route it through an external MTA that requires a (possibly encrypted) leased connection. That's changed too. Actually, most of the traffic is spam, and keeping ill-conditioned mail transfer habits is not going to reduce it. Using the right MSA for each return address allows SPF and DKIM (or other signing scheme) to reliably authenticate messages at their respective protocol entry points. That way, use of false identities will eventually be eliminated, and zombies with it, for the sake of real savings. -- "The best way of dealing with change is to help create it." _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 03:31:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8841E3A6B0F; Mon, 12 Jan 2009 03:31:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F993A6B0F for ; Mon, 12 Jan 2009 03:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 xXtFfjDSCYBl for ; Mon, 12 Jan 2009 03:31:34 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 0ECAA3A6816 for ; Mon, 12 Jan 2009 03:31:33 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50404) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDCW4K-00099E-QW for asrg@irtf.org; Mon, 12 Jan 2009 11:33:56 +0000 Date: Mon, 12 Jan 2009 11:31:16 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <614AF180F147E113AEB6D005@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4969650A.7010006@terabites.com> References: <4969650A.7010006@terabites.com> Originator-Info: login-token=Mulberry:01ayq3AtSLJWeslwtk11Denyp10aLYXM5Q4JU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 10 January 2009 21:18:34 -0600 Gordon Peterson wrote: > It is important to remember that many individuals and many small > companies use personal or "vanity" domain names. > > These domain names appear in their "From:" and "Reply-to:" addresses on > their outgoing e-mail messages, but SHOULD NOT be presumed to indicate > where the e-mail in question is arriving from. > > For example, I might be travelling somewhere and sending e-mail messages > from an inhabitual location: a cruise ship Internet cafe, an Internet > access kiosk above a post office location in Beijing, a coffee bar, or > other such public-access location. In such a situation, I will typically > have NO control over what outgoing mail server is sending my e-mail > message, and since my being there is temporary I obviously don't want to > put a return address on my mail that would be connected with the location > where I physically am at the time. You need to use your email service provider's Message Submission Service. That should be available to authenticating clients on port 587. Alternatively, use their webmail. If your Internet cafe is willing to relay your email, then they're willing to relay spam, too, and should therefore be blacklisted. > -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 03:33:40 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE40C3A6B48; Mon, 12 Jan 2009 03:33:40 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F493A6B47 for ; Mon, 12 Jan 2009 03:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iyes4m9dO6RV for ; Mon, 12 Jan 2009 03:33:39 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id DADCB3A67A8 for ; Mon, 12 Jan 2009 03:33:38 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50420) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDCW84-000A1T-2F for asrg@irtf.org; Mon, 12 Jan 2009 11:36:04 +0000 Date: Mon, 12 Jan 2009 11:33:23 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4969650A.7010006@terabites.com> References: <4969650A.7010006@terabites.com> Originator-Info: login-token=Mulberry:01C2iQlHTJ/vlM1eT2d45+3QMHceCx7m6OgNM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 10 January 2009 21:18:34 -0600 Gordon Peterson wrote: > While we're talking about the issue of antispam nuisances, another is the > situation where a spam blocker inadvertently serves as an "IP address > laundering agent" when they bounce back a message detected as containing > spam, or a virus. It is particularly stupid to bounce back a message > because it is detected to contain a virus WHICH IS KNOWN TO FALSIFY OR > COUNTERFEIT THE RETURN ADDRESS! Actually, it occurred to me that we have mechanisms whereby domain owners can prevent abuse of their domains (SPF and DKIM). Therefore, we should feel free to bounce email to any domain owner the doesn't deploy SPF and DKIM - in order to encourage them to do so. Of course, bouncing email is also OK when you find an SPF or DKIM match. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 03:37:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043313A6B47; Mon, 12 Jan 2009 03:37:32 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAD63A6B4B for ; Mon, 12 Jan 2009 03:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 0HbP56KQpWfO for ; Mon, 12 Jan 2009 03:37:29 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id AD26C3A68C9 for ; Mon, 12 Jan 2009 03:37:29 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50432) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDCWEJ-000BHI-7H for asrg@irtf.org; Mon, 12 Jan 2009 11:39:55 +0000 Date: Mon, 12 Jan 2009 11:37:14 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <4812691B6DEF8113F6E2A283@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <496A6B33.4010606@terabites.com> References: <496A6B33.4010606@terabites.com> Originator-Info: login-token=Mulberry:01oJhB0Qn5rzbhBZUzDL4TDbREBhBiKwO+FQM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 11 January 2009 15:57:07 -0600 Gordon Peterson wrote: > > > For example, I might be travelling somewhere and sending e-mail > messages > > > from an inhabitual location: a cruise ship Internet cafe, an > Internet > > > access kiosk above a post office location in Beijing, a coffee bar, > or > > > other such public-access location. In such a situation, I will > > > typically have NO control over what outgoing mail server is sending > my > > > e-mail message, and since my being there is temporary I obviously > don't > > > want to put a return address on my mail that would be connected with > the > > > location where I physically am at the time. > > > That's a hopeless setting. If you carry a laptop, SMTP+AUTH to the > company server is the way to go, as Franck said already. > > That's precisely the point. I am not using my habitual mail client, nor > am I using my own familiar webmail service. I am using a mail kiosk-type > service which allows me to enter a subject, my return address, a to > address, and the body of my mail. So, what's to stop me using your email address as the return address in that kiosk? That sort of service should not be used, except with very low expectation of delivery. The recipient should not trust the content of the email. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 03:52:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EF03A6B53; Mon, 12 Jan 2009 03:52:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25573A67A8 for ; Mon, 12 Jan 2009 03:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.842 X-Spam-Level: X-Spam-Status: No, score=-14.842 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 K1Zve+N0Tc6z for ; Mon, 12 Jan 2009 03:52:47 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id CCDFB3A6B4C for ; Mon, 12 Jan 2009 03:52:46 -0800 (PST) Received: (qmail 90157 invoked by uid 100); 12 Jan 2009 11:52:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=tMnP/ZYsIyxi9ZsNpr08zR3nuuQ39+S5RoOl/3xhbA4=; b=Os9fc1XX7S6NvEUj+QzNjIT4HDJxYSkUWno+PZEiw8UNhImqJb4HgMMLUNVbfJA5LyIEOrErqYZjSfpDGFv7FMY/M53yXljQBgyVdq6xgGvL3eRFam+MYPlT8wWGtDlIYKCJGdSOr8SO/Ors2iw4n+/pfEH8mwFDHMLaYapvnxw= Date: 12 Jan 2009 11:52:32 -0000 Message-ID: <20090112115232.90155.qmail@gal.iecc.com> From: John Levine To: asrg@ietf.org In-Reply-To: <496B2258.8070206@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Cc: asrg@irtf.org Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> Assuming DKIM gets traction, I can see that kiosk vendors will sign >> all their mail with the kiosk's domain which will, with luck, get >> a good enough reputation that receivers will say, oh, that's >> KioskCo, their mail is OK. >However, anyone can write "Gordon Peterson " on >that box's return address field. Do we really want that to be signed? Signed by KioskCo? Of course. It really did come from their kiosk. The whole point of DKIM is that that people can reliably take responsibility for the mail that passes through their systems, independent of the addresses in the visible headers or the SMTP envelope. I have no idea what kind of anti-abuse techniques KioskCo might use, but if they're effective, why shouldn't people accept their mail? My point was that if all of KisokCo's kiosks apply the same signature, that will be a large enough mailstream that recipients can form an opinion of how good it is, even though the stream from each individual kiosk would be too small. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 03:59:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A403A6B5B; Mon, 12 Jan 2009 03:59:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378A028C0CE for ; Mon, 12 Jan 2009 03:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.842 X-Spam-Level: X-Spam-Status: No, score=-14.842 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 A6bqTtD4pNod for ; Mon, 12 Jan 2009 03:59:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id CBC173A68C9 for ; Mon, 12 Jan 2009 03:59:26 -0800 (PST) Received: (qmail 90157 invoked by uid 100); 12 Jan 2009 11:52:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=tMnP/ZYsIyxi9ZsNpr08zR3nuuQ39+S5RoOl/3xhbA4=; b=Os9fc1XX7S6NvEUj+QzNjIT4HDJxYSkUWno+PZEiw8UNhImqJb4HgMMLUNVbfJA5LyIEOrErqYZjSfpDGFv7FMY/M53yXljQBgyVdq6xgGvL3eRFam+MYPlT8wWGtDlIYKCJGdSOr8SO/Ors2iw4n+/pfEH8mwFDHMLaYapvnxw= Date: 12 Jan 2009 11:52:32 -0000 Message-ID: <20090112115232.90155.qmail@gal.iecc.com> From: John Levine To: asrg@ietf.org In-Reply-To: <496B2258.8070206@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Cc: asrg@irtf.org Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> Assuming DKIM gets traction, I can see that kiosk vendors will sign >> all their mail with the kiosk's domain which will, with luck, get >> a good enough reputation that receivers will say, oh, that's >> KioskCo, their mail is OK. >However, anyone can write "Gordon Peterson " on >that box's return address field. Do we really want that to be signed? Signed by KioskCo? Of course. It really did come from their kiosk. The whole point of DKIM is that that people can reliably take responsibility for the mail that passes through their systems, independent of the addresses in the visible headers or the SMTP envelope. I have no idea what kind of anti-abuse techniques KioskCo might use, but if they're effective, why shouldn't people accept their mail? My point was that if all of KisokCo's kiosks apply the same signature, that will be a large enough mailstream that recipients can form an opinion of how good it is, even though the stream from each individual kiosk would be too small. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 04:28:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEDD3A6A17; Mon, 12 Jan 2009 04:28:59 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23513A6A17 for ; Mon, 12 Jan 2009 04:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9+89bbABB-pz for ; Mon, 12 Jan 2009 04:28:58 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 00E223A67A8 for ; Mon, 12 Jan 2009 04:28:57 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0CCSgjg016149 for ; Mon, 12 Jan 2009 07:28:43 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0CCK44C018208 for ; Mon, 12 Jan 2009 07:20:05 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0CCSaTj002417 for ; Mon, 12 Jan 2009 07:28:36 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0CCSXLc002409 for asrg@irtf.org; Mon, 12 Jan 2009 07:28:33 -0500 Date: Mon, 12 Jan 2009 07:28:33 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090112122833.GA30972@gsp.org> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 11:33:23AM +0000, Ian Eiloart wrote: > can prevent abuse of their domains (SPF and DKIM). Therefore, we should > feel free to bounce email to any domain owner the doesn't deploy SPF and > DKIM - in order to encourage them to do so. Of course, bouncing email is > also OK when you find an SPF or DKIM match. This is utter nonsense, of course. It is *never* acceptable to deliberately generate or redirect spam. I'm appalled to find anyone recommending such a clearly abusive course of action. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 04:45:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6413A67F7; Mon, 12 Jan 2009 04:45:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AEA3A67F7 for ; Mon, 12 Jan 2009 04:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 6jYENXaSehEr for ; Mon, 12 Jan 2009 04:45:09 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 27E613A67A8 for ; Mon, 12 Jan 2009 04:45:08 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 12 Jan 2009 13:44:54 +0100 id 00000000005DC033.00000000496B3B46.00005395 Message-ID: <496B3B45.3000007@tana.it> Date: Mon, 12 Jan 2009 13:44:53 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112115232.90155.qmail@gal.iecc.com> In-Reply-To: <20090112115232.90155.qmail@gal.iecc.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: > >>However, anyone can write "Gordon Peterson " on >>that box's return address field. Do we really want that to be signed? > > Signed by KioskCo? Of course. Hm.. I'm not much into DKIM. It technically allows to sign false identities, but doesn't (or shouldn't) it semantically imply that the signers must have some (possibly small but still positive) degree of trust that what they sign is correct? In that case the question is whether KioskCo would really want to sign that, and publish their slyness in their policy. > My point was that if all of KisokCo's kiosks apply the same signature, > that will be a large enough mailstream that recipients can form an > opinion of how good it is, even though the stream from each individual > kiosk would be too small. Although a critical mass is a common requirement of most anti-spam measures, requiring some kind of threshold for each single sender is more of a weakness. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 04:51:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEE73A6914; Mon, 12 Jan 2009 04:51:32 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FD63A6914 for ; Mon, 12 Jan 2009 04:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 1+ono6PLBa9h for ; Mon, 12 Jan 2009 04:51:30 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 0BF3B3A686D for ; Mon, 12 Jan 2009 04:51:29 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51870) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDCZTT-000LNF-15 for asrg@irtf.org; Mon, 12 Jan 2009 12:53:53 +0000 Date: Mon, 12 Jan 2009 12:51:12 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <0507125E60293720FB528395@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090112122833.GA30972@gsp.org> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112122833.GA30972@gsp.org> Originator-Info: login-token=Mulberry:013mhb9kfJyVsf1a9YSo5R3c5pROB8UEGOU9M=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 07:28:33 -0500 Rich Kulawiec wrote: > On Mon, Jan 12, 2009 at 11:33:23AM +0000, Ian Eiloart wrote: >> can prevent abuse of their domains (SPF and DKIM). Therefore, we should >> feel free to bounce email to any domain owner the doesn't deploy SPF and >> DKIM - in order to encourage them to do so. Of course, bouncing email >> is also OK when you find an SPF or DKIM match. > > This is utter nonsense, of course. It is *never* acceptable to > deliberately generate or redirect spam. I'm appalled to find anyone > recommending such a clearly abusive course of action. > Well, I should clarify that I'm not recommending it, or doing it. However, I do think that it's time that domain owners started taking responsibility for the use of their domains. The technology exists, and it would have the direct benefit to them that collateral spam back to their domains was reduced. In a world where you *can* prevent abuse of your domain, what's wrong with bouncing email? -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 05:00:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BEA3A6B5F; Mon, 12 Jan 2009 05:00:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B573A6B5F for ; Mon, 12 Jan 2009 05:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ekpccow4JC0i for ; Mon, 12 Jan 2009 05:00:25 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 4B1F63A6B5E for ; Mon, 12 Jan 2009 05:00:25 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0CD09QI019445 for ; Mon, 12 Jan 2009 08:00:10 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0CCpVai001890 for ; Mon, 12 Jan 2009 07:51:31 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0CD02iT019093 for ; Mon, 12 Jan 2009 08:00:02 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0CCnO0M012775 for asrg@irtf.org; Mon, 12 Jan 2009 07:49:24 -0500 Date: Mon, 12 Jan 2009 07:49:24 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090112124924.GB30972@gsp.org> References: <496A6B33.4010606@terabites.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496A6B33.4010606@terabites.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sun, Jan 11, 2009 at 03:57:07PM -0600, Gordon Peterson wrote: > That's not really the issue. The issue is that people occasionally have > very legitimate need to send mail other than through their normal > channels, PARTICULARLY when away from the office (at home, perhaps, > although sending a mail that's work-related; from a library or airpport > public access terminal; at a customer location; and particularly when > traveling out of the country.) All the more reason why operations that have such a need should plan and build to meet it: webmail clients are accessible from almost anywhere, and decent open-source ones are free and not particularly difficult to set up. Yes, this leaves out the tiny number of people in odd situations like cruise ships, but that's an edge case. (And surely someone who can afford a cruise can also afford a satellite link or similar if email is REALLY that important to them.) The days when we could freely forge our own addresses into the envelope for convenience are coming to an end. I don't like it much, but it's just another aspect of the damage caused by spammers. > In this case, however, the overly-broad-brush of poisoning ALL traffic > transiting an IP address just because it has sent "some" unwanted or > malicious mail can create a GREAT deal of serious collateral damage. 1. There's no such thing as "collateral damage" because there's no such thing as "damage" in this context. Please review the archives of this list from spring 2008. 2. If an address is emitting abuse, then why should anyone accept *anything* from it, until that situation has been addressed? (Which includes not just fixing the immediate problem, but taking steps to avoid a repeat occurence, and, I think, issuing a public apology and explanation. It's the least that people responsible for such huge amounts of damage [1] can do.) > Correct. The anti-virus filter should just swallow the message with no > complains nor notices. I don't know what RFC blesses that behavior, > though. Incorrect. The receiving MTA should reject with an appropriate error message. While it's much more likely that a malware filter will generate a FN than a FP, it's still possible, and an error message will be helpful in tracking down such situations. It might -- and I may be over-optimistic here -- also help notify the originating site that it has a problem, if they're paying attention to their own logs, and if they're not doing it on purpose. The more general principle here is that mail should never disappear into a black hole. (This is one reason why I've argued strongly against quarantines, which I consider a fundamentally broken concept.) We all make mistakes, the systems we deploy make mistakes, routers break, DNS fails, etc., and the best way to give ourselves a fighting chance of diagnosing such problems is to generate appropriate error messages. The costs of doing so are tiny, and the potential savings in wasted human effort are large. (Yes, I know that some horribly-broken systems mangle carefully-generated error messages. ) > It is very frustrating to get (sometimes hundreds a day) bounce messages > that come back to my domain (catch-all address mailbox) for e-mail > messages which *I* NEVER SENT, just because the spammers' From: address > used a counterfeit/bogus e-mail address forging one of my domains. This is backscatter spam, which results when improperly-configured mail systems run by incompetent mail system administrators fail to reject and instead bounce them to the putative sender. Some DNSBLs will list hosts for backscatter -- as they should, as it's just another variety of spam. You might consider using one of those (if you're not already), and you should definitely consider disabling all catch-all addresses, as they're likely targets for DDoS attacks. [2] ---Rsk [1] I think one reasonable metric for the monetary value of damage can be constructed by considering junk fax statutes. Here in the US, a single junk fax is valued at $500, amount tripled under some circumstances (and doubled again in California). If we consider a mail server compromised for a brief period of time (one hour) and emitting messages at a very low rate (1 per second to 1 user each), that's a minimum of $1.8M in damages. More realistic estimates easily reach into 9 figures. [2] I don't know if there's broad community consensus on this, but I've been routinely disabling all catch-all addresses anywhere I've been for over a decade. Given the huge amounts of spam being sent to never-existed and no-longer-existing addresses, it's not only a good way to deflect a fair amount of junk mail, it can also be useful in detecting spammers. (The failure of some purportedly-legitimate senders to display rudimentary mailing list management skills -- that is, to remove recipients after a sufficient number of rejects/sufficient period of time -- is quite annoying. I've observed that most, but not all, "amateur" mailing lists perform far better in this regard than supposedly-"professional" senders.) _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 07:42:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A018E3A69A0; Mon, 12 Jan 2009 07:42:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE39A3A69A0 for ; Mon, 12 Jan 2009 07:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8ioFDqch5OSJ for ; Mon, 12 Jan 2009 07:42:26 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id E599A3A67D4 for ; Mon, 12 Jan 2009 07:42:26 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 643998095D for ; Mon, 12 Jan 2009 07:42:08 -0800 (PST) Message-Id: <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <496B3B45.3000007@tana.it> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 12 Jan 2009 07:42:11 -0800 References: <20090112115232.90155.qmail@gal.iecc.com> <496B3B45.3000007@tana.it> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote: > John Levine wrote: >>> However, anyone can write "Gordon Peterson " on >>> that box's return address field. Do we really want that to be >>> signed? >> Signed by KioskCo? Of course. > > Hm.. I'm not much into DKIM. It technically allows to sign false > identities, but doesn't (or shouldn't) it semantically imply that > the signers must have some (possibly small but still positive) > degree of trust that what they sign is correct? No. The signature only means that the message you received was the one signed by the signing identity. > In that case the question is whether KioskCo would really want to > sign that, and publish their slyness in their policy. > >> My point was that if all of KisokCo's kiosks apply the same >> signature, >> that will be a large enough mailstream that recipients can form an >> opinion of how good it is, even though the stream from each >> individual >> kiosk would be too small. > > Although a critical mass is a common requirement of most anti-spam > measures, requiring some kind of threshold for each single sender is > more of a weakness. Any mail system that only allows mail to be sent one at a time, and requires that the mail be hand-typed (rather than stored in a signature or pasted in) and which charges for the service via a credit card is going to be a negligible source of abusive email. KioskCo is definitely going to want to sign the outbound mail with their identity, as that identity is unlikely to get a bad reputation and will likely get a good reputation over time. Worst case, DKIM signing the mail will have no effect. More likely it will have some positive effect at some recipients. It's a nice example of why DKIM signing even low volume sources of mail can be a good idea, if they have the resources to actually do the signing. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 08:03:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DD228B56A; Mon, 12 Jan 2009 08:03:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4B928B56A for ; Mon, 12 Jan 2009 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 z1pc1+Az2kM4 for ; Mon, 12 Jan 2009 08:03:52 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 4CF223A69F6 for ; Mon, 12 Jan 2009 08:03:52 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 12 Jan 2009 17:03:37 +0100 id 00000000005DC034.00000000496B69D9.00000CBB Message-ID: <496B69D9.1090807@tana.it> Date: Mon, 12 Jan 2009 17:03:37 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> In-Reply-To: <20090112124924.GB30972@gsp.org> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: >> Correct. The anti-virus filter should just swallow the message with no >> complains nor notices. I don't know what RFC blesses that behavior, >> though. > > Incorrect. The receiving MTA should reject with an appropriate error > message. While it's much more likely that a malware filter will generate > a FN than a FP, it's still possible, and an error message will be helpful > in tracking down such situations. Rejecting has been my first approach when I first installed an avfilter. When I realized the number of infections I was causing that way, I started to drop rather than reject. Since 2001, I've had a couple of FNs and no FP that I'm aware of. (I'm talking specific virus detection, not heuristic anti-malware filters.) > It might -- and I may be over-optimistic > here -- also help notify the originating site that it has a problem, > if they're paying attention to their own logs, and if they're not > doing it on purpose. I have in front of me the latest instance of W32/Netsky-D I received. (I still dump viral messages in a system folder not readable by users.) It is a bounce, so in this case I could have rejected it with less worries. What reaction would the remote postmaster have had? I have difficulties in estimating the worthiness of amending my software so as to reject rather than drop in case the envelope sender is void. For regular messages, rejection causes viruses to be delivered to end users, which is wrong because it spreads them. I don't think virus writers spread their original copies via their own MTAs; that is to say, IMHO MTAs are not doing it on purpose. However, I assume the remote MTA has no avfilter, otherwise it wouldn't relay viruses. Most probably, on rejection it will attempt to deliver a bounce. Failure to do so would result in the same net effect as dropping; so let's consider only infected bounces that are successfully delivered to end users: what are the chances that one of them results in an alert rather than yet another infection? Let's over-optimistically estimate we can get 1 alert for every 10 new infections. I don't deem that is anywhere near a desirable outcome. If I were a judge I would condemn postmasters wittingly doing so. > The more general principle here is that mail should never disappear into > a black hole. Agreed. A virus should be caught right after the client submits it. Reject vs. drop has a different meaning in this case: diagnosing an infected client should sound all available whistles and bells in either case. For relayed infected stuff, feedback loops may be a valid alternative to the black hole. However, zombie detection is not a topic restricted to email management. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 08:07:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FED328C154; Mon, 12 Jan 2009 08:07:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBA728C154 for ; Mon, 12 Jan 2009 08:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] 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 FRqGxK2bgUvV for ; Mon, 12 Jan 2009 08:07:00 -0800 (PST) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 6D6A128C14A for ; Mon, 12 Jan 2009 08:07:00 -0800 (PST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 3B00F34803 for ; Mon, 12 Jan 2009 11:06:44 -0500 (EST) Received: by panix5.panix.com (Postfix, from userid 756) id 28990241DC; Mon, 12 Jan 2009 11:06:44 -0500 (EST) From: Seth To: asrg@irtf.org In-reply-to: <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> (message from Ian Eiloart on Mon, 12 Jan 2009 11:33:23 +0000) References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> Message-Id: <20090112160644.28990241DC@panix5.panix.com> Date: Mon, 12 Jan 2009 11:06:43 -0500 (EST) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > Actually, it occurred to me that we have mechanisms whereby domain > owners can prevent abuse of their domains (SPF and DKIM). Therefore, > we should feel free to bounce email to any domain owner the doesn't > deploy SPF and DKIM - in order to encourage them to do so. And the recipients of the bounces should feel free to report your bounces as spam. And they should also feel free to cut your Internet connection to block further spam from your site, to encourage you to stop spamming. Seth _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 08:27:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FFC3A6903; Mon, 12 Jan 2009 08:27:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A333A6903 for ; Mon, 12 Jan 2009 08:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PTRi-2Bzfn5M for ; Mon, 12 Jan 2009 08:27:46 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 69B393A683A for ; Mon, 12 Jan 2009 08:27:46 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0CGRK1B020673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jan 2009 08:27:26 -0800 Message-ID: <496B6F68.3020507@dcrocker.net> Date: Mon, 12 Jan 2009 08:27:20 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112115232.90155.qmail@gal.iecc.com> <496B3B45.3000007@tana.it> <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> In-Reply-To: <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> X-Virus-Scanned: ClamAV 0.92/8855/Mon Jan 12 05:23:05 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Jan 2009 08:27:26 -0800 (PST) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Steve Atkins wrote: > On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote: >> Hm.. I'm not much into DKIM. It technically allows to sign false >> identities, but doesn't (or shouldn't) it semantically imply that the >> signers must have some (possibly small but still positive) degree of >> trust that what they sign is correct? > > No. The signature only means that the message you received was the one > signed by the signing identity. Not quite right. Or rather, not quite complete. And I'm compelled to pick this nit, since it is fundamental to discussion about DKIM's purpose. What you've described is a data integrity function. Yes, DKIM performs that on the portions of the message it lists in the DKIM-Signature: header field. However, data integrity is a side-effect of DKIM and not it's actual purpose.(*) It's purpose is: "DKIM allows an organization to take responsibility for transmitting a message, in a way that can be validated by a recipient. " So the requirement on the signer is to choose naming granularity and use that will provide the recipient with a stable label of a message stream. The receiver is supposed to take the identifier being proffered by the signer and run it through an assessment process. Presumably, a fake or transient or new identifier is likely to get far less trust than one with a track-record. As noted, the intended benefit of DKIM is across a message stream, with the identifier being used to label that stream consistently. d/ (*) In fact, one can argue that DKIM doesn't perform data integrity all that well, to which the response is that that's ok, it does it well enough for validating the use of the identifier. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 08:32:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E4128C31A; Mon, 12 Jan 2009 08:32:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080243A6A14 for ; Mon, 12 Jan 2009 08:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 khah+HYmPurx for ; Mon, 12 Jan 2009 08:32:10 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 5F82B28C315 for ; Mon, 12 Jan 2009 08:31:07 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 12 Jan 2009 17:30:52 +0100 id 00000000005DC02F.00000000496B703C.00001487 Message-ID: <496B703C.50602@tana.it> Date: Mon, 12 Jan 2009 17:30:52 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112115232.90155.qmail@gal.iecc.com> <496B3B45.3000007@tana.it> <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> In-Reply-To: <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Steve Atkins wrote: > On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote: > >> Hm.. I'm not much into DKIM. It technically allows to sign false >> identities, but doesn't (or shouldn't) it semantically imply that the >> signers must have some (possibly small but still positive) degree of >> trust that what they sign is correct? > > No. The signature only means that the message you received was the one > signed by the signing identity. Thanks for the clarification. > Any mail system that only allows mail to be sent one at a time, and > requires that the mail be hand-typed (rather than stored in a signature > or pasted in) and which charges for the service via a credit card is > going to be a negligible source of abusive email. > > KioskCo is definitely going to want to sign the outbound mail with their > identity, as that identity is unlikely to get a bad reputation and will > likely get a good reputation over time. Wouldn't then make more sense to just sign, say, the date and the message-ID? Besides malicious abuses, typos are also a possible source of confusion for end users. Considering that perhaps one day it will be possible to read the correct email address from the payment card, if I were KioskCo, I would avoid to sign From headers I don't trust, unless specifically required by DKIM or related BCPs. [N.B. "KioskCo" in this thread is understood as an example name, not related to possibly existing companies bearing the same name.] _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:00:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B996F28C329; Mon, 12 Jan 2009 09:00:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7113B28C328 for ; Mon, 12 Jan 2009 09:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 RVmSRQcn+J7e for ; Mon, 12 Jan 2009 09:00:26 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 8ADB828C315 for ; Mon, 12 Jan 2009 09:00:26 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:55576) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDDBCQ-0008IG-9E for asrg@irtf.org; Mon, 12 Jan 2009 17:02:50 +0000 Date: Mon, 12 Jan 2009 17:00:08 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090112160644.28990241DC@panix5.panix.com> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> Originator-Info: login-token=Mulberry:01Y0zDXsytMcOkuRfAz3LWwTbRycTkuMZy2Lc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 11:06:43 -0500 Seth wrote: > Ian Eiloart wrote: > >> Actually, it occurred to me that we have mechanisms whereby domain >> owners can prevent abuse of their domains (SPF and DKIM). Therefore, >> we should feel free to bounce email to any domain owner the doesn't >> deploy SPF and DKIM - in order to encourage them to do so. > > And the recipients of the bounces should feel free to report your > bounces as spam. And they should also feel free to cut your Internet > connection to block further spam from your site, to encourage you to > stop spamming. > Of course they could, but wouldn't they be better advised to take responsibility for their domains, thus preventing me from having to deal with spam sent "from" their domain? -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:02:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0CF28C334; Mon, 12 Jan 2009 09:02:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F2628C334 for ; Mon, 12 Jan 2009 09:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] 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 79CJI4uSZqk7 for ; Mon, 12 Jan 2009 09:02:36 -0800 (PST) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id D6FDE28C328 for ; Mon, 12 Jan 2009 09:02:36 -0800 (PST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 7833429414 for ; Mon, 12 Jan 2009 12:02:22 -0500 (EST) Received: by panix5.panix.com (Postfix, from userid 756) id CE499241DC; Mon, 12 Jan 2009 12:02:22 -0500 (EST) From: Seth To: asrg@irtf.org In-reply-to: <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> (message from Ian Eiloart on Mon, 12 Jan 2009 17:00:08 +0000) References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> Message-Id: <20090112170222.CE499241DC@panix5.panix.com> Date: Mon, 12 Jan 2009 12:02:22 -0500 (EST) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > Of course they could, but wouldn't they be better advised to take > responsibility for their domains, They do: by not emitting spam. That's what they're responsible to do. They aren't responsible to sign up for Clever-Idea-Of-The-Week and implement whatever makes your life easier. > thus preventing me from having to deal > with spam sent "from" their domain? It's not my responsibility to mediate the transaction between two third parties, even if one of them lies about being me. Seth _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:14:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5EC3A6A1D; Mon, 12 Jan 2009 09:14:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C5628C148 for ; Mon, 12 Jan 2009 09:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wLnOxKS1yBdN for ; Mon, 12 Jan 2009 09:14:47 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 3D4163A67D4 for ; Mon, 12 Jan 2009 09:14:47 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0CHEVQj005920 for ; Mon, 12 Jan 2009 12:14:32 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0CH5qNj017937 for ; Mon, 12 Jan 2009 12:05:52 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0CHEPlZ030556 for ; Mon, 12 Jan 2009 12:14:25 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0CHEM49030530 for asrg@irtf.org; Mon, 12 Jan 2009 12:14:22 -0500 Date: Mon, 12 Jan 2009 12:14:22 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090112171422.GA26691@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496B69D9.1090807@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 05:03:37PM +0100, Alessandro Vesely wrote: >> Incorrect. The receiving MTA should reject with an appropriate error >> message. While it's much more likely that a malware filter will generate >> a FN than a FP, it's still possible, and an error message will be helpful >> in tracking down such situations. > > Rejecting has been my first approach when I first installed an avfilter. > When I realized the number of infections I was causing that way, I > started to drop rather than reject. I'll probably have more to comment on in your message, but I stopped here because I'm confused and puzzled, and could use some clarification on what you mean by "infections...[you were] causing". I don't understand how issuing an SMTP reject could cause an infection; wouldn't doing so be the equivalent of telling an already-infected host "you're infected"? Could you expand on what you mean by this? ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:21:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826B428C332; Mon, 12 Jan 2009 09:21:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B342F28C332 for ; Mon, 12 Jan 2009 09:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bFCv6OsBgOsV for ; Mon, 12 Jan 2009 09:21:20 -0800 (PST) Received: from boom.graemef.net (boom.graemef.net [82.113.154.29]) by core3.amsl.com (Postfix) with ESMTP id D5CE528C157 for ; Mon, 12 Jan 2009 09:21:19 -0800 (PST) Received: from squonk.lut.ac.uk ([131.231.87.200]) by boom.graemef.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LMQT6-00053Q-UC for asrg@irtf.org; Mon, 12 Jan 2009 17:20:59 +0000 From: Graeme Fowler To: Anti-Spam Research Group - IRTF In-Reply-To: <20090112160644.28990241DC@panix5.panix.com> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> Date: Mon, 12 Jan 2009 17:20:46 +0000 Message-Id: <1231780846.29802.3.camel@squonk.lboro.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) X-graemef.net-scankey: boom.graemef.net 1LMQT6-00053Q-UC f1d5b722201ab4cc2c2bed37478e1333 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, 2009-01-12 at 11:06 -0500, Seth wrote: > And the recipients of the bounces should feel free to report your > bounces as spam. And they should also feel free to cut your Internet > connection to block further spam from your site, to encourage you to > stop spamming. I have a sneaking suspicion that there may be a terminology problem here: Ian more than likely means "reject" when he says "bounce". The thread becomes rather less argumentative if you do that replacement. Of course, I may be putting words into Ian's mouth which he *didn't* mean, but before anyone else replies I would like to see Ian clarify whether he means "bounce" or "reject". Knowing him at least a little in my professional capacity I would be *very* surprised if he did intend to write "bounce", unless he was being deliberately controversial... Graeme _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:42:22 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1199A28C21C; Mon, 12 Jan 2009 09:42:22 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D7F28C21C for ; Mon, 12 Jan 2009 09:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MGhV5dzWbz9D for ; Mon, 12 Jan 2009 09:42:20 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A128E3A6778 for ; Mon, 12 Jan 2009 09:42:20 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0CHg3803646 for ; Mon, 12 Jan 2009 17:42:03 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Jan 2009 12:41:32 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 12 Jan 2009 12:41:32 -0500 Message-ID: <496B80CB.8060806@nortel.com> Date: Mon, 12 Jan 2009 12:41:31 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> X-OriginalArrivalTime: 12 Jan 2009 17:41:32.0812 (UTC) FILETIME=[021254C0:01C974DD] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > Of course they could, but wouldn't they be better advised to take > responsibility for their domains, thus preventing me from having to deal > with spam sent "from" their domain? Please describe a _practical_ way to deal with Russian or Ukrainian virus/botspammers forging our domains in their spewage. SPF? DKIM? We do SPF. We may end up doing DKIM some day. But it won't make a significant difference to what is being _sent_. This is vaguely reminiscent of the complainer who, when I pointed out that our domain in his complaint was forged, replied with "well, you must be doing something bad if they're forging you like that". Splorf. "Bad" for whom? ;-) _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 09:52:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8946428C355; Mon, 12 Jan 2009 09:52:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B97E28C148 for ; Mon, 12 Jan 2009 09:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.07 X-Spam-Level: X-Spam-Status: No, score=-9.07 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 lNHHHPUC2OU0 for ; Mon, 12 Jan 2009 09:52:25 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 9109E28C33B for ; Mon, 12 Jan 2009 09:52:22 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA22041; Mon, 12 Jan 2009 12:52:06 -0500 (EST) From: der Mouse Message-Id: <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 12 Jan 2009 12:42:59 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090112171422.GA26691@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> Rejecting has been my first approach when I first installed an >> avfilter. When I realized the number of infections I was causing >> that way, I started to drop rather than reject. > [I] could use some clarification on what you mean by > "infections...[you were] causing". I don't understand how issuing an > SMTP reject could cause an infection; wouldn't doing so be the > equivalent of telling an already-infected host "you're infected"? Well, I didn't write it. But I interpreted it as, basically, this scenario: - Malware goes out, addressed to A, (forged) envelope-from B. Sending channel ends up emitting it from a normal MTA, M. - A's MX host rejects it at SMTP time. - M generates and sends a bounce to B. - B receives bounce with embedded malware. Somehow - perhaps B's MUA aggressively looks for and executes live content; perhaps B clicks on the wrong thing; perhaps something else - this ends up with a malware infestation on B's machine. (Cue xkcd #350.) If A's MX host had silently swallowed the mail, nothing would have happened to B - or, at least, not on account of this message. (This is not to say that _I_ think it's fair to say that A's rejection caused B to get infected. Just that this is what I think Alessandro meant.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 10:02:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8B53A67DB; Mon, 12 Jan 2009 10:02:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEFC3A67DB for ; Mon, 12 Jan 2009 10:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.108 X-Spam-Level: X-Spam-Status: No, score=-9.108 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 CK9vr+WCHICM for ; Mon, 12 Jan 2009 10:02:46 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 2FD683A6358 for ; Mon, 12 Jan 2009 10:02:46 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA22171; Mon, 12 Jan 2009 13:02:31 -0500 (EST) From: der Mouse Message-Id: <200901121802.NAA22171@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 12 Jan 2009 12:58:28 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <0507125E60293720FB528395@lewes.staff.uscs.susx.ac.uk> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112122833.GA30972@gsp.org> <0507125E60293720FB528395@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > However, I do think that it's time that domain owners started taking > responsibility for the use of their domains. If I, say, were to forge mail from your domain to, say, some ibm.com user, would you take responsibility for it? That's what you seem to me to be saying. > In a world where you *can* prevent abuse of your domain, what's wrong > with bouncing email? Depends on what that prevention requires. ("Sure you can prevent abuse of your domain. You just need to enter into a bilateral agreement with every receiving mailhost on the net.") But that's not the world we have, so it's a moot question. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 10:05:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4DE28C35C; Mon, 12 Jan 2009 10:05:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CC328C35C for ; Mon, 12 Jan 2009 10:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 aNfvb1fCXXsD for ; Mon, 12 Jan 2009 10:05:00 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 76AAD28C35A for ; Mon, 12 Jan 2009 10:05:00 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 2F25E80756 for ; Mon, 12 Jan 2009 10:04:42 -0800 (PST) Message-Id: <29980FCF-8848-4A1D-917B-2E659FB2CCCC@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <496B703C.50602@tana.it> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 12 Jan 2009 10:04:45 -0800 References: <20090112115232.90155.qmail@gal.iecc.com> <496B3B45.3000007@tana.it> <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> <496B703C.50602@tana.it> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 12, 2009, at 8:30 AM, Alessandro Vesely wrote: > Steve Atkins wrote: >> On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote: >>> Hm.. I'm not much into DKIM. It technically allows to sign false >>> identities, but doesn't (or shouldn't) it semantically imply that >>> the signers must have some (possibly small but still positive) >>> degree of trust that what they sign is correct? >> No. The signature only means that the message you received was the >> one signed by the signing identity. > > Thanks for the clarification. > >> Any mail system that only allows mail to be sent one at a time, and >> requires that the mail be hand-typed (rather than stored in a >> signature or pasted in) and which charges for the service via a >> credit card is going to be a negligible source of abusive email. >> KioskCo is definitely going to want to sign the outbound mail with >> their identity, as that identity is unlikely to get a bad >> reputation and will likely get a good reputation over time. > > Wouldn't then make more sense to just sign, say, the date and the > message-ID? Yes, absolutely it would... ... except for replay attacks. DKIM is intended to allow the recipient to reliably identify the signer of the message they receive. (It intentionally differentiates between "signer" and "sender".) Defining "the message" is important. Anyone can take a signed message, and modify any part of the content that wasn't signed, and resend the modified message and it will still be validly signed by the original signer. For example, if my bank only signed the date and message-id then I could take legitimate mail they sent me, replace the body of the message with a phish and send it out, and it would still appear validly signed by the original signer (the bank). That's why DKIM (when used correctly, anyway) is also used to demonstrate that important recipient-visible parts of the message (such as the body and the subject line) haven't been modified since the message was signed. (There are other possible ways to avoid replay attacks, but DKIM chose - for good reasons, I think - to use this one). > Besides malicious abuses, typos are also a possible source of > confusion for end users. Considering that perhaps one day it will be > possible to read the correct email address from the payment card, if > I were KioskCo, I would avoid to sign From headers I don't trust, > unless specifically required by DKIM or related BCPs. I suspect that KioskCo would just sign the entire message - but the reasons for that are long, vague and not terribly interesting. > [N.B. "KioskCo" in this thread is understood as an example name, not > related to possibly existing companies bearing the same name.] Yup. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 12:04:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B971D3A67FC; Mon, 12 Jan 2009 12:04:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E709B3A67FC for ; Mon, 12 Jan 2009 12:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 tumt-CyBMHve for ; Mon, 12 Jan 2009 12:03:57 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 6AAB13A6783 for ; Mon, 12 Jan 2009 12:03:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id CF0AC64F834A; Tue, 13 Jan 2009 08:03:44 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkMJm1xWoc73; Tue, 13 Jan 2009 08:03:39 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id E3D5964F8349; Tue, 13 Jan 2009 08:03:39 +1200 (FJT) Date: Tue, 13 Jan 2009 08:03:39 +1200 (FJT) From: Franck Martin To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF Message-ID: <15584127.341231790605781.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <496B6F68.3020507@dcrocker.net> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I have run a series of tests, where I sign a message (sent by me) but with only the Return-path containing my domain (DKIM does not sign the return-path as recommended in the spec). I used the DKIM reflectors on www.dkim.org and the assessment I got was: neutral (none of the signed field contain the domain of the signer). like if it is wrong. I think it should be a pass. I fear that many people that verify DKIM make the same mistake. I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier. ----- Original Message ----- From: "Dave CROCKER" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 13 January, 2009 4:27:20 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated Steve Atkins wrote: > On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote: >> Hm.. I'm not much into DKIM. It technically allows to sign false >> identities, but doesn't (or shouldn't) it semantically imply that the >> signers must have some (possibly small but still positive) degree of >> trust that what they sign is correct? > > No. The signature only means that the message you received was the one > signed by the signing identity. Not quite right. Or rather, not quite complete. And I'm compelled to pick this nit, since it is fundamental to discussion about DKIM's purpose. What you've described is a data integrity function. Yes, DKIM performs that on the portions of the message it lists in the DKIM-Signature: header field. However, data integrity is a side-effect of DKIM and not it's actual purpose.(*) It's purpose is: "DKIM allows an organization to take responsibility for transmitting a message, in a way that can be validated by a recipient. " So the requirement on the signer is to choose naming granularity and use that will provide the recipient with a stable label of a message stream. The receiver is supposed to take the identifier being proffered by the signer and run it through an assessment process. Presumably, a fake or transient or new identifier is likely to get far less trust than one with a track-record. As noted, the intended benefit of DKIM is across a message stream, with the identifier being used to label that stream consistently. d/ (*) In fact, one can argue that DKIM doesn't perform data integrity all that well, to which the response is that that's ok, it does it well enough for validating the use of the identifier. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 12:24:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB5C3A6836; Mon, 12 Jan 2009 12:24:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA423A6836 for ; Mon, 12 Jan 2009 12:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] 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 vaDCu4BeVfy6 for ; Mon, 12 Jan 2009 12:24:45 -0800 (PST) Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by core3.amsl.com (Postfix) with ESMTP id 4CAE73A6405 for ; Mon, 12 Jan 2009 12:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1428; t=1231791865; x=1232655865; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20where=20the=20message=20origin ated |Sender:=20 |To:=20Anti-Spam=20Research=20Group=20-=20IRTF=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=AqQVApwDRFKPr1OTxqy07h6ZMdYvMAmy0Uv6ppHEce0=; b=lm2wPNC7ReYw9A9D0ucEyoQM+YopZOJBFfdRE3G/bfE4DGjxSQMrNjHCF/ XG/JyEPWJ+aVbAgESe3qrMrS1WKiYUxHLNoYZJ9OwC08Z786GtWRpnktWDF/ llz7M/PFNhliA41AU2uLKTb+Ox20lDGdVsF6E978cfwduK5aTMaHM=; Received: from [127.0.0.1] (fugu.mtcc.com [127.0.0.1]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id n0CKOOku024880; Mon, 12 Jan 2009 12:24:25 -0800 Message-ID: <496BA6F8.4050401@mtcc.com> Date: Mon, 12 Jan 2009 12:24:24 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <15584127.341231790605781.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <15584127.341231790605781.JavaMail.franck@franck-martins-macbook-pro.local> Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com Cc: dcrocker@bbiw.net Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > I have run a series of tests, where I sign a message (sent by me) but with only the Return-path containing my domain (DKIM does not sign the return-path as recommended in the spec). > > I used the DKIM reflectors on www.dkim.org > > and the assessment I got was: neutral (none of the signed field contain the domain of the signer). > > like if it is wrong. > > I think it should be a pass. I fear that many people that verify DKIM make the same mistake. Note that this not about DKIM but about SSP/ADSP and Authentication-Results. I believe that the SSP/ADSP result should be neutral, but that the DKIM result is "pass". A lot of the reflectors haven't been updated for quite a while, and the earlier drafts of Auth-Res didn't make a distinction between DKIM and SSP/ADSP. So, true to form, differing implementations did differing things in the face of the ambiguity. > > I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier. I _think_ that my reflector does the right thing in that it separates out the dkim results from the ssp results, but I'm pretty sure that it's out of date wrt both the new auth-res draft and the adsp draft. In either case, an X-header isn't going to change anything. The ADSP part is always keyed of of the real live From address. Mike _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 12:51:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9434A3A67C0; Mon, 12 Jan 2009 12:51:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33933A67C0 for ; Mon, 12 Jan 2009 12:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 EkutiLvIO4BH for ; Mon, 12 Jan 2009 12:51:34 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 76F693A6405 for ; Mon, 12 Jan 2009 12:51:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 3F2ED64F834A; Tue, 13 Jan 2009 08:51:25 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAvuB60iOYHd; Tue, 13 Jan 2009 08:51:20 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 1A93064F8349; Tue, 13 Jan 2009 08:51:20 +1200 (FJT) Date: Tue, 13 Jan 2009 08:51:20 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <5729269.421231793469207.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <496BA6F8.4050401@mtcc.com> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Cc: dcrocker@bbiw.net Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I'm curious when you say ADSP is always keyed of the real live From address? You talk about the From: and not the Mail From: (Return-path)? as a side note, all this SSP/ADSP processing looks like a blackbox (or black magic) to me. There is no recommended practices and no one explain what they do to filter mail. like in the statement "AOL will use DKIM to do build reputation based on domain", what does it mean? We know well about spamassassin, DNSBL, DCC but this is about it. I thought security by obscurity was a bad idea? ;) ----- Original Message ----- From: "Michael Thomas" To: "Anti-Spam Research Group - IRTF" Cc: dcrocker@bbiw.net Sent: Tuesday, 13 January, 2009 8:24:24 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated Franck Martin wrote: > I have run a series of tests, where I sign a message (sent by me) but with only the Return-path containing my domain (DKIM does not sign the return-path as recommended in the spec). > > I used the DKIM reflectors on www.dkim.org > > and the assessment I got was: neutral (none of the signed field contain the domain of the signer). > > like if it is wrong. > > I think it should be a pass. I fear that many people that verify DKIM make the same mistake. Note that this not about DKIM but about SSP/ADSP and Authentication-Results. I believe that the SSP/ADSP result should be neutral, but that the DKIM result is "pass". A lot of the reflectors haven't been updated for quite a while, and the earlier drafts of Auth-Res didn't make a distinction between DKIM and SSP/ADSP. So, true to form, differing implementations did differing things in the face of the ambiguity. > > I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier. I _think_ that my reflector does the right thing in that it separates out the dkim results from the ssp results, but I'm pretty sure that it's out of date wrt both the new auth-res draft and the adsp draft. In either case, an X-header isn't going to change anything. The ADSP part is always keyed of of the real live From address. Mike _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 13:15:56 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29A03A696E; Mon, 12 Jan 2009 13:15:56 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D053A696E for ; Mon, 12 Jan 2009 13:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ZmCBqcCLZTYv for ; Mon, 12 Jan 2009 13:15:55 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 2FC903A67EA for ; Mon, 12 Jan 2009 13:15:54 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0CLFP3X030392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 13:15:31 -0800 Message-ID: <496BB2ED.7040605@dcrocker.net> Date: Mon, 12 Jan 2009 13:15:25 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Franck Martin References: <15584127.341231790605781.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <15584127.341231790605781.JavaMail.franck@franck-martins-macbook-pro.local> X-Virus-Scanned: ClamAV 0.92/8856/Mon Jan 12 08:36:19 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Jan 2009 13:15:31 -0800 (PST) Cc: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > I have run a series of tests, where I sign a message (sent by me) but with > only the Return-path containing my domain (DKIM does not sign the return-path > as recommended in the spec). DKIM has nothing to do with the rfc5321.MailFrom address or anything else in SMTP. It is a message-level mechanism, not transfer-level. The dkimbase signing specification's reference to return-path cautions *against* including it as part of the signature data. What are you referring to about "as recommended in the spec"? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 13:21:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C265728C0F0; Mon, 12 Jan 2009 13:21:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5DC28C11C for ; Mon, 12 Jan 2009 13:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 n0ak0PvBFd9F for ; Mon, 12 Jan 2009 13:21:10 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id BD88928C0DF for ; Mon, 12 Jan 2009 13:20:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id CC5A764F834A; Tue, 13 Jan 2009 09:20:50 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjgX5rn5-fvf; Tue, 13 Jan 2009 09:20:50 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 313C364F8349; Tue, 13 Jan 2009 09:20:50 +1200 (FJT) Date: Tue, 13 Jan 2009 09:20:50 +1200 (FJT) From: Franck Martin To: dcrocker@bbiw.net Message-ID: <15339102.591231795238125.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <496BB2ED.7040605@dcrocker.net> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org yes, that part, dkimbase reference to not include return-path as part of the signature data, because it is likely to be modified during transit. ----- Original Message ----- From: "Dave CROCKER" To: "Franck Martin" Cc: dcrocker@bbiw.net, "Anti-Spam Research Group - IRTF" Sent: Tuesday, 13 January, 2009 9:15:25 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated Franck Martin wrote: > I have run a series of tests, where I sign a message (sent by me) but with > only the Return-path containing my domain (DKIM does not sign the return-path > as recommended in the spec). DKIM has nothing to do with the rfc5321.MailFrom address or anything else in SMTP. It is a message-level mechanism, not transfer-level. The dkimbase signing specification's reference to return-path cautions *against* including it as part of the signature data. What are you referring to about "as recommended in the spec"? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 14:38:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB5E3A67EA; Mon, 12 Jan 2009 14:38:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC5D3A68B0 for ; Mon, 12 Jan 2009 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 xvuXKXvxdvbn for ; Mon, 12 Jan 2009 14:38:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 70A193A67DB for ; Mon, 12 Jan 2009 14:38:07 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so13602952rvb.7 for ; Mon, 12 Jan 2009 14:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=76bClQWYZNMHJ+rollt8EBdVNl2F7/Rr+kUGr/M1UXk=; b=fUnzxejlhYPeVJTvnmf7121TTEGdaIzC2fguTEyEKmNySY7BJ8RkVNbY/VUPx0vIh3 YjRYTzJs2OTQwigLYIrDgjhUsPy8nGwYyIRTmqsi5d0UW4+MM/1bZ2HajmMSDSHlNGIw b234cM44IuM/JcJP1xyuJxdLgtZB5N6sCUTfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=fExaK3ihygVai8HKkObMb/d88VtMhmg+dG3qaTPKO5DNoPQx+T44X2QSLKsMwGqEOW vQpKasINMpXy/Vyfeu5ZMEshzU4bgBeRdWYV/O96H1VCY15it36NX9lS4wSaqIgH8evk FSi8dTDCfdq8v7eBPJuR7k1kZwVLvPq+AUhHk= Received: by 10.141.146.4 with SMTP id y4mr14919297rvn.88.1231799872906; Mon, 12 Jan 2009 14:37:52 -0800 (PST) Received: by 10.141.145.10 with HTTP; Mon, 12 Jan 2009 14:37:52 -0800 (PST) Message-ID: <2e6401b50901121437g63be3f35ubb9915c1edf2ae98@mail.gmail.com> Date: Mon, 12 Jan 2009 15:37:52 -0700 From: "Robert Barclay" To: "Anti-Spam Research Group - IRTF" In-Reply-To: <5729269.421231793469207.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 References: <496BA6F8.4050401@mtcc.com> <5729269.421231793469207.JavaMail.franck@franck-martins-macbook-pro.local> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0278707276==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============0278707276== Content-Type: multipart/alternative; boundary="----=_Part_306279_24378498.1231799872897" ------=_Part_306279_24378498.1231799872897 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jan 12, 2009 at 1:51 PM, Franck Martin wrote: > I'm curious when you say ADSP is always keyed of the real live From > address? You talk about the From: and not the Mail From: (Return-path)? Yes, the A is for Author. ADSP is built on top of DKIM and allows domain owners to specify that they sign some or all mail using a specific domain in the From: address > > > as a side note, all this SSP/ADSP processing looks like a blackbox (or > black magic) to me. There is no recommended practices and no one explain > what they do to filter mail. like in the statement "AOL will use DKIM to do > build reputation based on domain", what does it mean? It means they are going to start establishing reputation for DKIM domains based on the DKIM signed mail passing through their systems. This isn't any more of a black box than their existing reputation systems. As for recommended practices I'm not sure there's enough operational experience is most situations to have anything useful to recommend yet. I would be pleased to be wrong here but suspect that we may be starting to get there for some uses of DKIM and are a long way away from that with ADSP. > > > We know well about spamassassin, DNSBL, DCC but this is about it. I thought > security by obscurity was a bad idea? ;) Not sure this qualifies for security by obscurity. It's pretty straightforward how all these technologies work. How people make use of the data these technologies provide, that only seems obscure because people are still figuring it out themselves. Compare this to how people use IP addresses there's a pretty wide variety there and a lot of those uses would qualify as "obscured" from outside users too. > > > ----- Original Message ----- > From: "Michael Thomas" > To: "Anti-Spam Research Group - IRTF" > Cc: dcrocker@bbiw.net > Sent: Tuesday, 13 January, 2009 8:24:24 AM (GMT+1200) Auto-Detected > Subject: Re: [Asrg] where the message originated > > Franck Martin wrote: > > I have run a series of tests, where I sign a message (sent by me) but > with only the Return-path containing my domain (DKIM does not sign the > return-path as recommended in the spec). > > > > I used the DKIM reflectors on www.dkim.org > > > > and the assessment I got was: neutral (none of the signed field contain > the domain of the signer). > > > > like if it is wrong. > > > > I think it should be a pass. I fear that many people that verify DKIM > make the same mistake. > > Note that this not about DKIM but about SSP/ADSP and > Authentication-Results. > I believe that the SSP/ADSP result should be neutral, but that the DKIM > result is "pass". A lot of the reflectors haven't been updated for quite > a > while, and the earlier drafts of Auth-Res didn't make a distinction > between > DKIM and SSP/ADSP. So, true to form, differing implementations did > differing > things in the face of the ambiguity. > > > > > I'm thinking of adding an X-header that will contain my domain and sign > it via DKIM and see if the reflectors are happier. > > I _think_ that my reflector does the right thing in that it separates out > the > dkim results from the ssp results, but I'm pretty sure that it's out of > date > wrt both the new auth-res draft and the adsp draft. > > In either case, an X-header isn't going to change anything. The ADSP part > is > always keyed of of the real live From address. > > Mike > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > ------=_Part_306279_24378498.1231799872897 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Jan 12, 2009 at 1:51 PM, Franck Martin <franck@avonsys.com> wrote:
I'm curious when you say ADSP is always keyed of the real live From address? You talk about the From: and not the Mail From: (Return-path)?
 Yes, the A is for Author. ADSP is built on top of DKIM and allows domain owners to specify that they sign some or all mail using a specific domain in the From: address
 


as a side note, all this SSP/ADSP processing looks like a blackbox (or black magic) to me. There is no recommended practices and no one explain what they do to filter mail. like in the statement "AOL will use DKIM to do build reputation based on domain", what does it mean?

It means they are going to start establishing reputation for DKIM domains based on the DKIM signed mail passing through their systems. This isn't any more of a black box than their existing reputation systems.
As for recommended practices I'm not sure there's enough operational  experience is most situations to have anything useful to recommend yet. I would be pleased to be wrong here but suspect that we may be starting to get there for some uses of DKIM and are a long way away from that with ADSP.

 


We know well about spamassassin, DNSBL, DCC but this is about it. I thought security by obscurity was a bad idea? ;)

Not sure this qualifies for security by obscurity. It's pretty straightforward how all these technologies work. How people make use of the data these technologies provide, that only seems obscure because people are still figuring it out themselves. Compare this to how people use IP addresses there's a pretty wide variety there and a lot of those uses would qualify as "obscured" from outside users too.

 


----- Original Message -----
From: "Michael Thomas" <mike@mtcc.com>
To: "Anti-Spam Research Group - IRTF" <asrg@irtf.org>
Cc: dcrocker@bbiw.net
Sent: Tuesday, 13 January, 2009 8:24:24 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated

Franck Martin wrote:
> I have run a series of tests, where I sign a message (sent by me) but with only the Return-path containing my domain (DKIM does not sign the return-path as recommended in the spec).
>
> I used the DKIM reflectors on www.dkim.org
>
> and the assessment I got was: neutral (none of the signed field contain the domain of the signer).
>
> like if it is wrong.
>
> I think it should be a pass. I fear that many people that verify DKIM make the same mistake.

  Note that this not about DKIM but about SSP/ADSP and Authentication-Results.
  I believe that the SSP/ADSP result should be neutral, but that the DKIM
  result is "pass". A lot of the reflectors haven't been updated for quite a
  while, and the earlier drafts of Auth-Res didn't make a distinction between
  DKIM and SSP/ADSP. So, true to form, differing implementations did differing
  things in the face of the ambiguity.

>
> I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier.

  I _think_ that my reflector does the right thing in that it separates out the
  dkim results from the ssp results, but I'm pretty sure that it's out of date
  wrt both the new auth-res draft and the adsp draft.

  In either case, an X-header isn't going to change anything. The ADSP part is
  always keyed of of the real live From address.

               Mike
_______________________________________________
Asrg mailing list
Asrg@irtf.org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg@irtf.org
http://www.irtf.org/mailman/listinfo/asrg

------=_Part_306279_24378498.1231799872897-- --===============0278707276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0278707276==-- From asrg-bounces@irtf.org Mon Jan 12 15:16:19 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1674A3A67DB; Mon, 12 Jan 2009 15:16:19 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7D53A67C0 for ; Mon, 12 Jan 2009 15:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6rk5+K3XSfP2 for ; Mon, 12 Jan 2009 15:16:16 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id B16933A67EA for ; Mon, 12 Jan 2009 15:15:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 5BB3964F834A for ; Tue, 13 Jan 2009 11:15:40 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynurJfE0tNBB for ; Tue, 13 Jan 2009 11:15:30 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id E053D64F8349 for ; Tue, 13 Jan 2009 11:15:30 +1200 (FJT) Date: Tue, 13 Jan 2009 11:15:30 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <3965870.671231802116697.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <5246927.651231802097384.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015106452==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============0015106452== Content-Type: multipart/alternative; boundary="----=_Part_39_16453968.1231802116696" ------=_Part_39_16453968.1231802116696 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I'm not sure that http://en.wikipedia.org/wiki/Sender_Signing_Policy has a correct definition? spamassassin, DNSBL, DCC are well known, so we know how they behave with different emails, what we don't know is what the google, yahoo, microsoft and others are doing to classify their emails (this is the part about security by obcurity). ----- Original Message ----- From: "Robert Barclay" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 13 January, 2009 10:37:52 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated On Mon, Jan 12, 2009 at 1:51 PM, Franck Martin < franck@avonsys.com > wrote: I'm curious when you say ADSP is always keyed of the real live From address? You talk about the From: and not the Mail From: (Return-path)? Yes, the A is for Author. ADSP is built on top of DKIM and allows domain owners to specify that they sign some or all mail using a specific domain in the From: address as a side note, all this SSP/ADSP processing looks like a blackbox (or black magic) to me. There is no recommended practices and no one explain what they do to filter mail. like in the statement "AOL will use DKIM to do build reputation based on domain", what does it mean? It means they are going to start establishing reputation for DKIM domains based on the DKIM signed mail passing through their systems. This isn't any more of a black box than their existing reputation systems. As for recommended practices I'm not sure there's enough operational experience is most situations to have anything useful to recommend yet. I would be pleased to be wrong here but suspect that we may be starting to get there for some uses of DKIM and are a long way away from that with ADSP. We know well about spamassassin, DNSBL, DCC but this is about it. I thought security by obscurity was a bad idea? ;) Not sure this qualifies for security by obscurity. It's pretty straightforward how all these technologies work. How people make use of the data these technologies provide, that only seems obscure because people are still figuring it out themselves. Compare this to how people use IP addresses there's a pretty wide variety there and a lot of those uses would qualify as "obscured" from outside users too. ------=_Part_39_16453968.1231802116696 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >I'm not sure that http://en.wikipedia.org/wiki/Sender_Signing_Policy has a= correct definition?

spamassassin, DNSBL, DCC are well known, so we = know how they behave with different emails, what we don't know is what the = google, yahoo, microsoft and others are doing to classify their emails (thi= s is the part about security by obcurity).

----- Original Message --= ---
From: "Robert Barclay" <rbbarclay@gmail.com>
To: "Anti-Spam= Research Group - IRTF" <asrg@irtf.org>
Sent: Tuesday, 13 January,= 2009 10:37:52 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the= message originated



On Mon, Jan 1= 2, 2009 at 1:51 PM, Franck Martin <franck@avonsys.com> wrot= e:
I'm curious when you say ADSP is always keyed of the real live From address= ? You talk about the From: and not the Mail From: (Return-path)?
 Yes, the A is for Author. ADSP is built on top of DKIM and all= ows domain owners to specify that they sign some or all mail using a specif= ic domain in the From: address
 


as a side note, all this SSP/ADSP processing looks like a blackbox (or blac= k magic) to me. There is no recommended practices and no one explain what t= hey do to filter mail. like in the statement "AOL will use DKIM to do build= reputation based on domain", what does it mean?

It means they are going to start establishing reputation for DKIM = domains based on the DKIM signed mail passing through their systems. This i= sn't any more of a black box than their existing reputation systems.
As for recommended practices I'm not sure there's enough operational  = experience is most situations to have anything useful to recommend yet. I w= ould be pleased to be wrong here but suspect that we may be starting to get= there for some uses of DKIM and are a long way away from that with ADSP.
 
<= br>
We know well about spamassassin, DNSBL, DCC but this is about it. I thought= security by obscurity was a bad idea? ;)

Not sure thi= s qualifies for security by obscurity. It's pretty straightforward how all = these technologies work. How people make use of the data these technologies= provide, that only seems obscure because people are still figuring it out = themselves. Compare this to how people use IP addresses there's a pretty wi= de variety there and a lot of those uses would qualify as "obscured" from o= utside users too.

 

------=_Part_39_16453968.1231802116696-- --===============0015106452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0015106452==-- From asrg-bounces@irtf.org Mon Jan 12 16:07:26 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B56B3A6836; Mon, 12 Jan 2009 16:07:26 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6F63A6836 for ; Mon, 12 Jan 2009 16:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.814 X-Spam-Level: X-Spam-Status: No, score=-14.814 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 qrDTtk5D31gf for ; Mon, 12 Jan 2009 16:07:24 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 1E67A3A67DB for ; Mon, 12 Jan 2009 16:07:24 -0800 (PST) Received: (qmail 74828 invoked from network); 13 Jan 2009 00:07:09 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Jan 2009 00:07:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=9jq1Rwo4Rz+8FPpJcfrgi1MXXtbbKUDScJ8/0AN65hk=; b=fC2BWRfs0l3mAt5VVLQIJ8yELI2VsRUbCGWgcR8M5eZztN9yvkyv6n/pexTieHyLNM54TKwF6pH+SwEq4q/g+0uXxYTTQM+7YJ2j8UbFTGmSfyFFD/8/g8tpCowLfwHpKwZ6cO61e83wdjTWniuh2tjgG7Dbqu/fCuOlBKfMFMM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; bh=9jq1Rwo4Rz+8FPpJcfrgi1MXXtbbKUDScJ8/0AN65hk=; b=iUGR2qYS7z9MmBEV2hI8Lr3+ihCFEdBesKsVrRU93LAUbr4rBNgoQ7lOiywj0pndGl7U1HUYA8dHA4KSWRgYvV+K9DIzPoO8pmeDJhFmqkQWjws0nb10dVSDP3zdxpfs92wygtaiMD1zG2N0dBGFRJ2zWaaYrML5EM7Syl3AXw8= Date: 13 Jan 2009 00:07:07 -0000 Message-ID: <20090113000707.72142.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <3965870.671231802116697.JavaMail.franck@franck-martins-macbook-pro.local> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >I'm not sure that http://en.wikipedia.org/wiki/Sender_Signing_Policy has >a correct definition? If you're wondering what SSP/ADSP does, how about reading the draft that actually defines it: http://tools.ietf.org/html/draft-ietf-dkim-ssp-08 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 16:15:07 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD2D3A68CC; Mon, 12 Jan 2009 16:15:07 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C8E3A67DB for ; Mon, 12 Jan 2009 16:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 xLSOLeVudx0V for ; Mon, 12 Jan 2009 16:14:58 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 39C753A68CC for ; Mon, 12 Jan 2009 16:14:58 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0D0EacF005153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jan 2009 16:14:41 -0800 Message-ID: <496BDCEC.3090904@dcrocker.net> Date: Mon, 12 Jan 2009 16:14:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090113000707.72142.qmail@simone.iecc.com> In-Reply-To: <20090113000707.72142.qmail@simone.iecc.com> X-Virus-Scanned: ClamAV 0.92/8856/Mon Jan 12 08:36:19 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Jan 2009 16:14:42 -0800 (PST) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: > If you're wondering what SSP/ADSP does, how about reading the draft > that actually defines it: john, you simply have *no* sense of adventure... RTFS (spec) is such an unimaginative approach to life. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 16:43:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805FB3A67DB; Mon, 12 Jan 2009 16:43:59 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C2A28C12B for ; Mon, 12 Jan 2009 16:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.816 X-Spam-Level: X-Spam-Status: No, score=-14.816 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 ZjzBuTZIPHi7 for ; Mon, 12 Jan 2009 16:43:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id DA0B13A67AD for ; Mon, 12 Jan 2009 16:43:57 -0800 (PST) Received: (qmail 10641 invoked from network); 13 Jan 2009 00:43:43 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Jan 2009 00:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; i=johnl@user.iecc.com; bh=T6CVWTti6JIX1E432llpCadiEdWFg20nmX8XgQ6nHCE=; b=G7HIVLz5G4bPGK5nUFdvxtwNdpszzFReeLEDp/06x0fC0tqYEebFxVV6RJyUO0qjqfYMkqBN+cqWZAPYsj86OCZuYzxWMqsf7FLhvdcrdynSfmiyLlbscYXX3DOE102sI3h/Q14BfEkBTPB5CpnKiZG328O0aJ0efQ0bKvZOii4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0812; bh=T6CVWTti6JIX1E432llpCadiEdWFg20nmX8XgQ6nHCE=; b=YOfRtHWg6ZGkJiqmdRoQ+RfFkJS/bL0mNY5ibM++N8So8l65iGNCdjclXO7/eagDkMNmr5GKtULm5MK4X9i1SH/GwwXHuutA4acQ5VfaXjwuQj73WwA3mt/SjDyqGiPFfvH567M7sE0ou70yv8eMbukm4FOy8jBJ1ycZcWrvFQk= Date: 13 Jan 2009 00:43:41 -0000 Message-ID: <20090113004341.81013.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4812691B6DEF8113F6E2A283@lewes.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] kiosks, was where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > So, what's to stop me using your email address as the return address > in that kiosk? Technically, nothing. In practice, it's a pretty poor way to defame people or send spam, particularly if it's the kind of kiosk where you pay with a credit card so there is an extremely reliable audit trail should someone take offense. Keep in mind that any kind of security is a tradeoff, and in this case the tradeoff sure looks like a kiosk will send send mail that people people want, not spam. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 12 20:26:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416B53A67E4; Mon, 12 Jan 2009 20:26:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E233A67AD for ; Mon, 12 Jan 2009 20:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 KfDR84DWPeVE for ; Mon, 12 Jan 2009 20:26:21 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id C172A3A63EC for ; Mon, 12 Jan 2009 20:26:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 6092364F834A; Tue, 13 Jan 2009 16:26:13 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuZSwbM9pBDv; Tue, 13 Jan 2009 16:26:12 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4484C64F8349; Tue, 13 Jan 2009 16:26:12 +1200 (FJT) Date: Tue, 13 Jan 2009 16:26:12 +1200 (FJT) From: Franck Martin To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF Message-ID: <16748369.1431231820757981.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <496BDCEC.3090904@dcrocker.net> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John, It sounds like "read the code, luke!" ;) I like to read wikipedia summaries of RFC, it gives me the essential points, but here I think I'm more lost than by reading the draft, I went to read the draft, but I think it would be helpful if someone could fix the wikipedia entry, so nayone can understand what is all about. ----- Original Message ----- From: "Dave CROCKER" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 13 January, 2009 12:14:36 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated John Levine wrote: > If you're wondering what SSP/ADSP does, how about reading the draft > that actually defines it: john, you simply have *no* sense of adventure... RTFS (spec) is such an unimaginative approach to life. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 05:49:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA8C3A6ABC; Tue, 13 Jan 2009 05:49:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9003A6AA7 for ; Tue, 13 Jan 2009 05:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XFNZVJ3+aBcR for ; Tue, 13 Jan 2009 05:49:52 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id B00783A67FF for ; Tue, 13 Jan 2009 05:49:52 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0DDnY82024633 for ; Tue, 13 Jan 2009 08:49:37 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0DDer1P004314 for ; Tue, 13 Jan 2009 08:40:53 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0DDnS2H027821 for ; Tue, 13 Jan 2009 08:49:29 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0DDnQDE027808 for asrg@irtf.org; Tue, 13 Jan 2009 08:49:26 -0500 Date: Tue, 13 Jan 2009 08:49:26 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090113134926.GA22598@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 12:42:59PM -0500, der Mouse wrote: > Well, I didn't write it. But I interpreted it as, basically, this > scenario: > > - Malware goes out, addressed to A, (forged) envelope-from B. Sending > channel ends up emitting it from a normal MTA, M. > > - A's MX host rejects it at SMTP time. > > - M generates and sends a bounce to B. > > - B receives bounce with embedded malware. Somehow - perhaps B's MUA > aggressively looks for and executes live content; perhaps B clicks > on the wrong thing; perhaps something else - this ends up with a > malware infestation on B's machine. (Cue xkcd #350.) > > If A's MX host had silently swallowed the mail, nothing would have > happened to B - or, at least, not on account of this message. (This is > not to say that _I_ think it's fair to say that A's rejection caused B > to get infected. Just that this is what I think Alessandro meant.) Ah, gotcha. I agree that silently swallowing the message might have spared B a possible infection, but I'm reluctant to blame A's MX for this: it didn't originate, accept or transfer the malware-laden message. I think responsibility lies with M, and/or with whatever system passed the message to M (presuming the message didn't originated on M). While this is a less-than-desirable outcome, I think it may be the best we can do -- we can't block something before we see it, we can only do our best to reject outright spam/malware/junk traffic at the earliest available opportunity. (One of the ways I've expressed this elsewhere is that the best place to stop spam is as near its source as possible. The farther it gets from the origin, the trickier detecting it gets, and the greater the possible consequences.) ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 06:12:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0773A69A8; Tue, 13 Jan 2009 06:12:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835C03A6934 for ; Tue, 13 Jan 2009 06:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aggaxLKrUGGe for ; Tue, 13 Jan 2009 06:12:10 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id C2AE13A6954 for ; Tue, 13 Jan 2009 06:12:10 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so22041wfg.7 for ; Tue, 13 Jan 2009 06:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UR+JIOqYNyitXtDniQQty4khCMA8P9kt9e/pMl1haLs=; b=qgZoMkaAsTJJZgJeTi5ZC6PCDJa5DTxYLsk4IC8K7KmryNFQdhe29SmIlyyQ+vBJdP RBsvnCZWtiS+bvCjKRihh7/2g17PTwv2Is0Zrvp5X4RFu3QInxf5pLqmWJmVZlWn6Cd1 8crdHnPw8EDzlYDdJd7GLxMZahD7bcoydt9ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bnoLlZNkajOWBaqgl8oGdy/HZ2jEvDdDLfNSEjdgDHlhPmVne37dnj8a4tvcVzgIS1 8UFtqxAld3L/QDea9R2av9xYdAnVN35qz5fG34fLelvOX4eXYAI7ZpXgBiskqBKZiti2 S+exCgqwWYbL2B/AzmjPI7gejRiXtfA8zNbmQ= Received: by 10.142.144.16 with SMTP id r16mr12884874wfd.316.1231855915593; Tue, 13 Jan 2009 06:11:55 -0800 (PST) Received: by 10.142.155.11 with HTTP; Tue, 13 Jan 2009 06:11:55 -0800 (PST) Message-ID: <7ae58c220901130611y2429e945l16934f63ce89e449@mail.gmail.com> Date: Tue, 13 Jan 2009 09:11:55 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <20090113004341.81013.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Disposition: inline References: <4812691B6DEF8113F6E2A283@lewes.staff.uscs.susx.ac.uk> <20090113004341.81013.qmail@simone.iecc.com> Subject: Re: [Asrg] kiosks, was where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 7:43 PM, John Levine wrote: >> So, what's to stop me using your email address as the return address >> in that kiosk? > > Technically, nothing. > > In practice, it's a pretty poor way to defame people or send spam, > particularly if it's the kind of kiosk where you pay with a credit > card so there is an extremely reliable audit trail should someone take > offense. > Given the amount of CC information floating around at relatively low cost to people with ill intent, I would not rely on "an extremely reliable audit trail". It will take you to a p0wn3d person in an extremely reliable way. > Keep in mind that any kind of security is a tradeoff, and in this case > the tradeoff sure looks like a kiosk will send send mail that people > people want, not spam. > I don't have enough experience with mail kiosks (I've never used one in my life and haven't noticed receiving from one - and yes, I do tend to look at headers) to make an assertion one way or the other regarding people wanting mail from kiosks. What do you base your assertion on John? Not meaning to be combative, actually looking for a data point. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 06:24:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8F43A6AA5; Tue, 13 Jan 2009 06:24:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ABF3A6A61 for ; Tue, 13 Jan 2009 06:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 npEdZFggC9a4 for ; Tue, 13 Jan 2009 06:24:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 626473A69E3 for ; Tue, 13 Jan 2009 06:24:26 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so27101wfg.7 for ; Tue, 13 Jan 2009 06:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=w4h8Dmxm7wa8PG4INgbbh8nrM1YSbK2is2MKYdb3l3A=; b=rKCy06DZfPNbMZy/KxhafFKngU+D62WF4ph5vMHV7rOw7aPpS/kbEc4J1ELTnl3WUj jO/FpU6uwI2Qr3b+Fa2D7Q4+d97p9BIQ6EzkGekhq/wtyKgnyVuVOHT2erWANhpSZkTw 6L8mUUekPOHWCp3VQ3nQqSK0ebXhY/cad7agY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YlcNb83UeP79EFtu5de7PgagSFDKxGbHj2WSRr+Mj0bKg5Ynsv++93jwGHu3LZIqx/ lGZT9wS2D2dD/nn2oisc2YGFquud+JDT/sJGqjO2Pzh1d6woeXQ0Br9b5wsBQnWGSIpN bgTabwuAaNM0pHh+MThM7br1KGk8U8F8kBL8s= Received: by 10.143.2.7 with SMTP id e7mr12890749wfi.246.1231856650528; Tue, 13 Jan 2009 06:24:10 -0800 (PST) Received: by 10.142.155.11 with HTTP; Tue, 13 Jan 2009 06:24:10 -0800 (PST) Message-ID: <7ae58c220901130624v51832f8fvedd8e5b85fc5b3fd@mail.gmail.com> Date: Tue, 13 Jan 2009 09:24:10 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> MIME-Version: 1.0 Content-Disposition: inline References: <20090112115232.90155.qmail@gal.iecc.com> <496B3B45.3000007@tana.it> <0E71A926-7974-4EEF-9975-5D242CA0DF48@blighty.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 10:42 AM, Steve Atkins wrote: > > > Any mail system that only allows mail to be sent one at a time, and requires > that the mail be hand-typed (rather than stored in a signature or pasted in) > and which charges for the service via a credit card is going to be a > negligible source of abusive email. > > KioskCo is definitely going to want to sign the outbound mail with their > identity, as that identity is unlikely to get a bad reputation and will > likely get a good reputation over time. > > Worst case, DKIM signing the mail will have no effect. More likely it will > have some positive effect at some recipients. It's a nice example of why > DKIM signing even low volume sources of mail can be a good idea, if they > have the resources to actually do the signing. > Steve, You assume the integrity of the KioskCo environment. That is not necessarily a safe assumption to make. I will grant you that KioskCo MIGHT be aggressive in responding to it's hosts being subverted. On the other hand it may not. If blocking or discard of mail originating from KioskCo is in effect, even for a short time, the individual using that kiosk to send mail well may suffer the consequences of using a mechanism with unknown security standards. Just a thought. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 08:22:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999883A6877; Tue, 13 Jan 2009 08:22:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E33B3A67D7 for ; Tue, 13 Jan 2009 08:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 cMmFNXx2snxB for ; Tue, 13 Jan 2009 08:22:34 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A90063A6877 for ; Tue, 13 Jan 2009 08:22:34 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 13 Jan 2009 17:22:16 +0100 id 00000000005DC031.00000000496CBFB8.000008EC Message-ID: <496CBFB8.1000503@tana.it> Date: Tue, 13 Jan 2009 17:22:16 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> In-Reply-To: <20090113134926.GA22598@gsp.org> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > On Mon, Jan 12, 2009 at 12:42:59PM -0500, der Mouse wrote: >> >> - Malware goes out, addressed to A, (forged) envelope-from B. Sending >> channel ends up emitting it from a normal MTA, M. >> >> - A's MX host rejects it at SMTP time. >> >> - M generates and sends a bounce to B. >> >> - B receives bounce with embedded malware. Somehow - perhaps B's MUA >> aggressively looks for and executes live content; perhaps B clicks >> on the wrong thing; perhaps something else - this ends up with a >> malware infestation on B's machine. (Cue xkcd #350.) >> >> If A's MX host had silently swallowed the mail, nothing would have >> happened to B - or, at least, not on account of this message. > > Ah, gotcha. I agree that silently swallowing the message might have > spared B a possible infection, but I'm reluctant to blame A's MX for > this: it didn't originate, accept or transfer the malware-laden message. A's MX knows that M lacks effective anti-virus filtering. Hence, through inaction, it allowed a human being to come to harm. That obviously breaks the first law. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 09:32:06 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE863A6927; Tue, 13 Jan 2009 09:32:06 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959B428C141 for ; Tue, 13 Jan 2009 09:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 MX1MCIQl50ET for ; Tue, 13 Jan 2009 09:31:57 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id E10683A67D7 for ; Tue, 13 Jan 2009 09:31:56 -0800 (PST) Received: by po-out-1718.google.com with SMTP id c31so145248poi.0 for ; Tue, 13 Jan 2009 09:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=tbgWCxFrIsOA6sG5kvi43A2R/N1P65Y0JCTcYOml+3A=; b=Xe/ZT3PJpM0p6A36gSVz+QGnqKP1A3ukJqvJ2lEj5bd+hnhAo1Yld+cs9Zz8eYIbMX Fkc+Yzv/FOpfBuxT4SvjKU4tB6/GlbijeoOynFgETJDgte3F0i6Ouya3oRM3vVTINQhX nDndeTM1gLnIU1hPDORsAvytF5dgNGAH0xOr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=p72gX3T7rGhiIR8J8F7Zz3GPaOq1lgdZxpsjxnhbwCTJpwmwSo/bBDKMubMctlNNhL b4Y51Gu3xcVEOE9JBfbiX/QzdsBY1EDlh22tclAVKa13s6l6iUDaZycgsomCDsi7n22M tAk0YzOvDNKssvbDo1tV5gZnr0xlJ+JN2r0x8= MIME-Version: 1.0 Received: by 10.141.84.17 with SMTP id m17mr15375019rvl.252.1231867901901; Tue, 13 Jan 2009 09:31:41 -0800 (PST) In-Reply-To: <3965870.671231802116697.JavaMail.franck@franck-martins-macbook-pro.local> References: <5246927.651231802097384.JavaMail.franck@franck-martins-macbook-pro.local> <3965870.671231802116697.JavaMail.franck@franck-martins-macbook-pro.local> Date: Tue, 13 Jan 2009 10:31:41 -0700 Message-ID: <2e6401b50901130931p33f19cbdhefd920ac16fbddad@mail.gmail.com> From: Robert Barclay To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735013146==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============1735013146== Content-Type: multipart/alternative; boundary=000e0cd1b658b3fa60046060989b --000e0cd1b658b3fa60046060989b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jan 12, 2009 at 4:15 PM, Franck Martin wrote: > I'm not sure that http://en.wikipedia.org/wiki/Sender_Signing_Policy has a > correct definition? > I think what you're referring to is this statement "Instead of the *From*header, ADSP can also be used for publishing that all mails of the *MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have a corresponding DKIM signature." which as far as I know is not correct. John, Dave, Steve can any of you guys verify this? I admit some of the debates managed to throttle me into zombie-ism so I may have missed something major somewhere. > > > spamassassin, DNSBL, DCC are well known, so we know how they behave with > different emails, what we don't know is what the google, yahoo, microsoft > and others are doing to classify their emails (this is the part about > security by obcurity). > First I think you're talking about a different issue than DKIM/ADSP here. Your complaint appears to be that you don't know generally what the software these guys use to evaluate email does or what they mean when they use the term reputation. This isn't a new issue. It's just sort of the state of the world and I would say it's not limited to these guys. In general unless someone on the receiving end has told you specifically how they evaluate emails then really all you can tell is (sometimes) whether the email got there or not. Second I think you're confusing knowledge of what data a piece of technology provides you with knowledge of how people use that software. Knowing what spamassassin does generally still doesn't give you anything better than a guess at what that might mean to the systems of spamassassin users. In the case of DKIM you at least know that two people running compliant software will come to exactly the same decision on whether a piece of mail passes. You just don't know what either of those people will do with that information. Since that's exactly the case now with every other piece of information people extract from an email you're certainly not any worse off. Robert > > > ----- Original Message ----- > From: "Robert Barclay" > To: "Anti-Spam Research Group - IRTF" > Sent: Tuesday, 13 January, 2009 10:37:52 AM (GMT+1200) Auto-Detected > Subject: Re: [Asrg] where the message originated > > > > On Mon, Jan 12, 2009 at 1:51 PM, Franck Martin wrote: > >> I'm curious when you say ADSP is always keyed of the real live From >> address? You talk about the From: and not the Mail From: (Return-path)? > > Yes, the A is for Author. ADSP is built on top of DKIM and allows domain > owners to specify that they sign some or all mail using a specific domain in > the From: address > > >> >> >> as a side note, all this SSP/ADSP processing looks like a blackbox (or >> black magic) to me. There is no recommended practices and no one explain >> what they do to filter mail. like in the statement "AOL will use DKIM to do >> build reputation based on domain", what does it mean? > > > It means they are going to start establishing reputation for DKIM domains > based on the DKIM signed mail passing through their systems. This isn't any > more of a black box than their existing reputation systems. > As for recommended practices I'm not sure there's enough operational > experience is most situations to have anything useful to recommend yet. I > would be pleased to be wrong here but suspect that we may be starting to get > there for some uses of DKIM and are a long way away from that with ADSP. > > > >> >> >> We know well about spamassassin, DNSBL, DCC but this is about it. I >> thought security by obscurity was a bad idea? ;) > > > Not sure this qualifies for security by obscurity. It's pretty > straightforward how all these technologies work. How people make use of the > data these technologies provide, that only seems obscure because people are > still figuring it out themselves. Compare this to how people use IP > addresses there's a pretty wide variety there and a lot of those uses would > qualify as "obscured" from outside users too. > > > > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > > --000e0cd1b658b3fa60046060989b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 12, 2009 at 4:15 PM, Franck = Martin <franck@a= vonsys.com> wrote:
I'm not sure that http://en.wikipedia.org/wiki/Sende= r_Signing_Policy has a correct definition?

I think what you're referring to is this st= atement "Instead of the From header, ADSP can also be used for = publishing that all mails of the MAIL FROM, Sender, Resent= -Sender and Resent-From headers have a corresponding DKI= M signature." which as far as I know is not correct. John, Dave, S= teve can any of you guys verify this? I admit some of the debates managed t= o throttle me into zombie-ism so I may have missed something major somewher= e.

spamassassin, DNSBL, DCC are well known, so we know how they behave with di= fferent emails, what we don't know is what the google, yahoo, microsoft= and others are doing to classify their emails (this is the part about secu= rity by obcurity).

First I think you're talking about a differ= ent issue than DKIM/ADSP here. Your complaint appears to be that you don= 9;t know generally what the software these guys use to evaluate email does = or what they mean when they use the term reputation. This isn't a new i= ssue. It's just sort of the state of the world and I would say it's= not limited to these guys. In general unless someone on the receiving end = has told you specifically how they evaluate emails then really all you can = tell is (sometimes) whether the email got there or not.

Second I think you're confusing knowledge of what data a piece of t= echnology provides you with knowledge of how people use that software. Know= ing what spamassassin does generally still doesn't give you anything be= tter than a guess at what that might mean to the systems of spamassassin us= ers. In the case of DKIM you at least know that two people running complian= t software will come to exactly the same decision on whether a piece of mai= l passes. You just don't know what either of those people will do with = that information.
Since that's exactly the case now with every other piece of information= people extract from an email you're certainly not any worse off.
Robert

 


----- Original Message -----
= From: "Robert Barclay" <rbbarclay@gmail.com>
To: "Anti-Spam Research Group - IRTF" <asrg@irtf.org>
Sent: Tuesday, 13 January, 2009 10:37:52 AM (GMT+1200) Auto-Detected<= br> Subject: Re: [Asrg] where the message originated



On Mon, Jan 12, 2009 at 1:51 PM= , Franck Martin <franck@avonsys.com> wrote:
I'm curious when you say ADSP is always keyed of the real live From add= ress? You talk about the From: and not the Mail From: (Return-path)?
 Yes, the A is for Author. ADSP is built on top of DKIM and= allows domain owners to specify that they sign some or all mail using a sp= ecific domain in the From: address
 


as a side note, all this SSP/ADSP processing looks like a blackbox (or blac= k magic) to me. There is no recommended practices and no one explain what t= hey do to filter mail. like in the statement "AOL will use DKIM to do = build reputation based on domain", what does it mean?

It means they are going to start establishing reputation for DKIM = domains based on the DKIM signed mail passing through their systems. This i= sn't any more of a black box than their existing reputation systems. As for recommended practices I'm not sure there's enough operationa= l  experience is most situations to have anything useful to recommend = yet. I would be pleased to be wrong here but suspect that we may be startin= g to get there for some uses of DKIM and are a long way away from that with= ADSP.

 
<= br>
We know well about spamassassin, DNSBL, DCC but this is about it. I thought= security by obscurity was a bad idea? ;)

Not sure thi= s qualifies for security by obscurity. It's pretty straightforward how = all these technologies work. How people make use of the data these technolo= gies provide, that only seems obscure because people are still figuring it = out themselves. Compare this to how people use IP addresses there's a p= retty wide variety there and a lot of those uses would qualify as "obs= cured" from outside users too.

 


___________________________= ____________________
Asrg mailing list
Asrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/asrg


--000e0cd1b658b3fa60046060989b-- --===============1735013146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============1735013146==-- From asrg-bounces@irtf.org Tue Jan 13 09:54:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EC03A69FF; Tue, 13 Jan 2009 09:54:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689A43A69FF for ; Tue, 13 Jan 2009 09:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 A2phfiG2sCYk for ; Tue, 13 Jan 2009 09:54:19 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 60B9C3A69D8 for ; Tue, 13 Jan 2009 09:54:19 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0DHs2Bc014941 for ; Tue, 13 Jan 2009 12:54:03 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0DHjIRG012514 for ; Tue, 13 Jan 2009 12:45:19 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0DHrsOt025246 for ; Tue, 13 Jan 2009 12:53:54 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0DHrorE025208 for asrg@irtf.org; Tue, 13 Jan 2009 12:53:50 -0500 Date: Tue, 13 Jan 2009 12:53:50 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090113175350.GA24889@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496CBFB8.1000503@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 13, 2009 at 05:22:16PM +0100, Alessandro Vesely wrote: >> Ah, gotcha. I agree that silently swallowing the message might have >> spared B a possible infection, but I'm reluctant to blame A's MX for >> this: it didn't originate, accept or transfer the malware-laden message. > > A's MX knows that M lacks effective anti-virus filtering. Hence, through > inaction, it allowed a human being to come to harm. That obviously breaks > the first law. But none of this is necessarily true. - While I'm not overly conversant in the nuances of anti-virus systems (I prefer to use operating systems relatively unaffected by them) I'm under the impression that there's wide variability in the detection of various strains by different AV products. So it might not be the case that M lacks effective anti-virus filtering; it may well be the case that A's MX was simply fortuitous enough to be presented with a specimen that it detected while M did not. It may even be the case that this is the exception to the rule -- that is, that M's virus detection is in fact markedly better than that at A's MX, but the latter simply got lucky. - Add to the discussion above the dependency of many (most?) anti-virus products on signature databases which must be updated rather frequently in order to deal with fast-propagating malware. It may be the case that M is in fact running the same anti-virus product as A's MX, but is mere minutes behind in updating. - A human being won't necessarily be harmed by this. For starters, there's no way to know that the message will be delivered. If the putative sender is elsewhere, then the mail system there might detect and reject the message. The putative sender's mail client may be using an anti-virus product that detects it. Or the putative sender may never "open" the message (which seems to effectively defuse most, but not all, of these problems). - Or the putative sender may not be running a mail client that's easily hijacked by malware or may not be running an operating system that's so brittle. (e.g.: mutt on OpenBSD.) There are still more variables in play here, but I think this is enough to illustrate why attempting to guess at them is futile. It's best to just reject the message and content yourself that (a) you've done all you can do (b) you've emitted a reasonable diagnostic message in case this is a goof (c) you've minimized the amount of SMTP traffic you're emitting -- a key factor and (d) you've done something that passes the "what if everyone did this?" test, another key factor. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 10:18:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE693A69CA; Tue, 13 Jan 2009 10:18:16 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2763A69CA for ; Tue, 13 Jan 2009 10:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 f8LCMOFO5dz3 for ; Tue, 13 Jan 2009 10:18:14 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 618EC3A691E for ; Tue, 13 Jan 2009 10:18:14 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Tue, 13 Jan 2009 18:17:59 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090113175350.GA24889@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> Organization: Isode Limited Date: Tue, 13 Jan 2009 18:17:53 +0000 Message-Id: <1231870673.3240.8.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, 2009-01-13 at 12:53 -0500, Rich Kulawiec wrote: > It's best to just > reject the message and content yourself that (a) you've done all you > can do > (b) you've emitted a reasonable diagnostic message in case this is a > goof > (c) you've minimized the amount of SMTP traffic you're emitting -- a > key > factor and (d) you've done something that passes the "what if everyone > did this?" test, another key factor. > If by "reject" you mean "give a 5xx response to the data from the SMTP client, the problem with that is that, as previously discussed, the SMTP client server may generate a DSN or similar which returns the infected message. It does not know that the reason for non-delivery was the suspect message content. You do. So the only safe responses are: - discard the message (i.e. accept it over SMTP and then throw it away with no further processing, apart from possible archiving). - send a DSN or similar which suppresses return of content. In the old days you could get messages which contain inadvertently infected attachments (e.g. in the days of Word macro viruses). I would think that the fraction of infected messages which are like this is negligibly small. So, no-one needs to know that the message is being non-delivered, so discarding the message is the best policy. David _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 12:23:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3FD3A6AD3; Tue, 13 Jan 2009 12:23:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F5A3A6AD3 for ; Tue, 13 Jan 2009 12:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UxpXbelJA7K9 for ; Tue, 13 Jan 2009 12:23:07 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BD9CF3A68DD for ; Tue, 13 Jan 2009 12:23:06 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0DKJ3T23116 for ; Tue, 13 Jan 2009 20:19:03 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 15:22:48 -0500 Received: from [47.9.16.42] (47.9.16.42) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 13 Jan 2009 15:22:47 -0500 Message-ID: <496CF816.3010407@nortel.com> Date: Tue, 13 Jan 2009 15:22:46 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> In-Reply-To: <496CBFB8.1000503@tana.it> X-OriginalArrivalTime: 13 Jan 2009 20:22:48.0305 (UTC) FILETIME=[B3872610:01C975BC] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Alessandro Vesely wrote: > Rich Kulawiec wrote: >> On Mon, Jan 12, 2009 at 12:42:59PM -0500, der Mouse wrote: >>> - Malware goes out, addressed to A, (forged) envelope-from B. Sending >>> channel ends up emitting it from a normal MTA, M. >>> >>> - A's MX host rejects it at SMTP time. >>> >>> - M generates and sends a bounce to B. >>> >>> - B receives bounce with embedded malware. Somehow - perhaps B's MUA >>> aggressively looks for and executes live content; perhaps B clicks >>> on the wrong thing; perhaps something else - this ends up with a >>> malware infestation on B's machine. (Cue xkcd #350.) >>> >>> If A's MX host had silently swallowed the mail, nothing would have >>> happened to B - or, at least, not on account of this message. >> Ah, gotcha. I agree that silently swallowing the message might have >> spared B a possible infection, but I'm reluctant to blame A's MX for >> this: it didn't originate, accept or transfer the malware-laden message. > > A's MX knows that M lacks effective anti-virus filtering. Hence, > through inaction, it allowed a human being to come to harm. That > obviously breaks the first law. A's MX didn't generate _any_ virus-laden email. It just 550'd. The originator did, and M's mailer is complicit by constructing a new email (the bounce) that contains the virus-laden email. A knows its filtering isn't perfect and that every rejection is a potential FP. So, the rejection is the best way to ensure that the appropriate party (if any) is notified. Blackholing would violate the first law. M _should_ know that best practise is now to ensure that the recipient of the bounce knows enough to know what email bounced, and should truncate the email to that minimum. Eg: original recipient, sender (the recipient of the bounce), date, subject, and perhaps a few other snippets. A very large proportion of MTAs now do that by default. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 12:47:35 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A2128C0E2; Tue, 13 Jan 2009 12:47:35 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F55C28C0E2 for ; Tue, 13 Jan 2009 12:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.818 X-Spam-Level: X-Spam-Status: No, score=-14.818 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 oMJQ5BNQIvbY for ; Tue, 13 Jan 2009 12:47:33 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id E3D7E28C0DC for ; Tue, 13 Jan 2009 12:47:32 -0800 (PST) Received: (qmail 35775 invoked from network); 13 Jan 2009 20:47:18 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Jan 2009 20:47:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=pA0eNtafGVjRMY7FMTYw6TXRWq5IAbjGoIHzAXRtG0o=; b=k8uygRwFku1jeXnsuRJlfDrBzBXjEQpxfa/Q8MYpQZU6VSFTgMx3u4t1szcQx6WXJUXDSWlupsa3xpmfHvk1Yw609IYcSxiBU7NJ36cpFIXNn8zsA41enWEkH2QqdqI7oPHJQcfCl6RNXpSwHLhTvsJF9UVgr6b0MGb8Xe4KIrU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=pA0eNtafGVjRMY7FMTYw6TXRWq5IAbjGoIHzAXRtG0o=; b=lwvdQduPJn3etm77QIlRFbOPO7DNCinZjpbds5T2ZqT0fxHD/nAux5g9ktoHZnmT/nQilX2YqZfgCb60jhODagNH3YdVHyL76HrNgNaSPlb62xZnJSE1a6PLrLrbuuy7cov+sRbfNwyP9dH51UQ6UEvTyEgxg4xplonatJZHqug= Date: 13 Jan 2009 20:47:16 -0000 Message-ID: <20090113204716.95920.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <2e6401b50901130931p33f19cbdhefd920ac16fbddad@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >I think what you're referring to is this statement "Instead of the >*From*header, ADSP can also be used for publishing that all mails of >the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have a >corresponding DKIM signature." which as >far as I know is not correct. Wow, is that wrong. I'll see if I can fix it. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 12:53:11 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E8428C178; Tue, 13 Jan 2009 12:53:11 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA6C28B56A for ; Tue, 13 Jan 2009 12:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HpVakEkiXeKk for ; Tue, 13 Jan 2009 12:53:09 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.228]) by core3.amsl.com (Postfix) with ESMTP id 091E228C0E2 for ; Tue, 13 Jan 2009 12:53:08 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id f11so89633qba.17 for ; Tue, 13 Jan 2009 12:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OwwYcBnutIeH59vAzpOkO/kRG9bE9fOARTGb80cdL/I=; b=jYPL59Cc2fO2uyLbqyT84/LS303YyyGvdll/zMB8qwLdF6+I+S4Sx1j7oBm/3/0p3o yV5NYjehHZ2PryqnWBF+BTS1kvle3GiDrOXHw2BWinIjJ2a0mhjTS+VwowfVZZq8C+to wU0is6MBFUuf+2YXKvErrOlaUP/4biJZWCp+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wzArWZVqJyp31uha3VXaVabxcoJkjj/ASZ2gERMQ3yeJiHV5kX7rJH+R/qnX7Ga7k7 plPqErIYVeWRmBdS+xUxYIT1QV3bdZer2tE4+u+i2O0Ry/tOR7t8w1mS4xZ+ccMxP/Wo 4x2PL4yUieHAW3+ffn4OuHBmNC8aj3vJpHM0Y= MIME-Version: 1.0 Received: by 10.141.5.17 with SMTP id h17mr15457296rvi.165.1231879972786; Tue, 13 Jan 2009 12:52:52 -0800 (PST) In-Reply-To: <20090113204716.95920.qmail@simone.iecc.com> References: <2e6401b50901130931p33f19cbdhefd920ac16fbddad@mail.gmail.com> <20090113204716.95920.qmail@simone.iecc.com> Date: Tue, 13 Jan 2009 13:52:52 -0700 Message-ID: <2e6401b50901131252r31998914x9519bd5b1f326a0e@mail.gmail.com> From: Robert Barclay To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1090719915==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============1090719915== Content-Type: multipart/alternative; boundary=000e0cd1129a2f10eb04606368eb --000e0cd1129a2f10eb04606368eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the confirmation. I was pretty sure that was the case but figured someone with more expertise (like say one of the authors of the draft) would let me know otherwise. On Tue, Jan 13, 2009 at 1:47 PM, John Levine wrote: > > >I think what you're referring to is this statement "Instead of the > >*From*header, ADSP can also be used for publishing that all mails of > >the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have > a > >corresponding DKIM signature." which > as > >far as I know is not correct. > > Wow, is that wrong. I'll see if I can fix it. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > --000e0cd1129a2f10eb04606368eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the confirmation. I was pretty sure that was the case but figure= d someone with more expertise (like say one of the authors of the draft) wo= uld let me know otherwise.

On Tue, Jan 13= , 2009 at 1:47 PM, John Levine <johnl@taugh.com> wrote:

>I think what you're referring to is this statement "Instead of= the
>*From*header, ADSP can also be used for publishing that all mails of >the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* header= s have a
>corresponding DKIM <http://en.wikipedia.org/wiki/DKIM> signature.&= quot; which as
>far as I know is not correct.

Wow, is that wrong.  I'll see if I can fix it.

R's,
John
______________________________= _________________
Asrg mailing list
Asrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/asrg

--000e0cd1129a2f10eb04606368eb-- --===============1090719915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============1090719915==-- From asrg-bounces@irtf.org Tue Jan 13 12:54:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C421028C18C; Tue, 13 Jan 2009 12:54:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7751528C189 for ; Tue, 13 Jan 2009 12:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 F5xebqGoAXPM for ; Tue, 13 Jan 2009 12:54:00 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 0E4C728C0E2 for ; Tue, 13 Jan 2009 12:53:59 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0DKrctU019940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2009 12:53:43 -0800 Message-ID: <496CFF52.8070901@dcrocker.net> Date: Tue, 13 Jan 2009 12:53:38 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090113204716.95920.qmail@simone.iecc.com> In-Reply-To: <20090113204716.95920.qmail@simone.iecc.com> X-Virus-Scanned: ClamAV 0.92/8861/Tue Jan 13 08:09:19 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 13 Jan 2009 12:53:43 -0800 (PST) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org i modified the text this morning. d/ John Levine wrote: >> I think what you're referring to is this statement "Instead of the >> *From*header, ADSP can also be used for publishing that all mails of >> the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have a >> corresponding DKIM signature." which as >> far as I know is not correct. > > Wow, is that wrong. I'll see if I can fix it. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 12:57:14 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139AF3A6B19; Tue, 13 Jan 2009 12:57:14 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314E43A69F9 for ; Tue, 13 Jan 2009 12:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.82 X-Spam-Level: X-Spam-Status: No, score=-14.82 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 9y5WCn75jVVt for ; Tue, 13 Jan 2009 12:57:12 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 67D8D3A6B11 for ; Tue, 13 Jan 2009 12:57:09 -0800 (PST) Received: (qmail 52112 invoked from network); 13 Jan 2009 20:56:53 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Jan 2009 20:56:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=TtbDkq4myBGl0j1zcx0x35F0rKC2BjCnYy0u8vy+b/Y=; b=Z4BJPxoGSHLfyPgMUJQBuTt+Xq4QllOgjAHj0t2r5OTffrDIaABLf3+8QdcTwMeDg+iVGFqKxHn0nPASHbtUZr5Cw2oQk4LLOaj4ZemhiyusntNG9q4NkRkUNbT+SK2stIvCR9TB4V0pKgQ8KbRDhURiNqWc6paznIQ5sQw2qO8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=TtbDkq4myBGl0j1zcx0x35F0rKC2BjCnYy0u8vy+b/Y=; b=DKh2Uh4QF+VMP77rnGZqqJDA+oNuen3eLKvlwaa1kLw5NtRJZYk+HgfsSAQbKSGwcpoxB8Icj06S297PxBkN4XI6gil+i7X33Ih0bISmrtdEJsxvc+YH99mSi+fw9HPrzcWy+PfEQxsW9GeQ9/kb7/bwwZw3GBvwalA8wwVtjM8= Date: 13 Jan 2009 20:56:52 -0000 Message-ID: <20090113205652.99275.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090113204716.95920.qmail@simone.iecc.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >>I think what you're referring to is this statement "Instead of the >>*From*header, ADSP can also be used for publishing that all mails of >>the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have a >>corresponding DKIM signature." which as >>far as I know is not correct. > >Wow, is that wrong. I'll see if I can fix it. Looks like Dave already did. Thanks. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 13:00:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E553A6B19; Tue, 13 Jan 2009 13:00:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D84528C16F for ; Tue, 13 Jan 2009 13:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3uPV4xcNp7sQ for ; Tue, 13 Jan 2009 13:00:27 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 4AFF93A6B11 for ; Tue, 13 Jan 2009 13:00:27 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0DL0Ar3016370 for ; Tue, 13 Jan 2009 16:00:12 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0DKpQel024561 for ; Tue, 13 Jan 2009 15:51:27 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0DL02rv026096 for ; Tue, 13 Jan 2009 16:00:02 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0DKaiCY013519 for asrg@irtf.org; Tue, 13 Jan 2009 15:36:44 -0500 Date: Tue, 13 Jan 2009 15:36:42 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090113203638.GA11831@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231870673.3240.8.camel@bravo.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 13, 2009 at 06:17:53PM +0000, David Wilson wrote: > If by "reject" you mean "give a 5xx response to the data from the SMTP > client, the problem with that is that, as previously discussed, the SMTP > client server may generate a DSN or similar which returns the infected > message. It does not know that the reason for non-delivery was the > suspect message content. You do. So the only safe responses are: > - discard the message (i.e. accept it over SMTP and then throw it away > with no further processing, apart from possible archiving). > - send a DSN or similar which suppresses return of content. I've got serious problems with both of those. In the first case, you're telling the sending server one thing and doing another. I don't think that's a good idea on two levels: at a philosophical level, this seems like a bad way to run an Internet. At a practical level, doing so fails to alert the sending site that they may have a problem. (Yes, I'm presuming that they're paying attention to their own logs...or that they will be more inclined to do so when they notice 86,000 5xx error messages in them.) In the second case, generating DSNs is a bad idea in general [1], but it's a REALLY bad idea as a response to spam/virus messages. Look, I understand the motivation, and it's very noble, but it's also pointless. A hypothetical virus relying on this method of propagation will also have many other -- many other SIMPLER -- ways of delivering itself to the very same targets. The best that anyone external can do is (a) don't propagate the problem further (b) communicate via appropriate use of SMTP that there's a problem and (c) don't make the problem worse or more complicated or more obscure. ---Rsk [1] It's not that hard to engineer mail architectures -- including distributed and multi-tier architectures -- that always reject and never bounce. Yes, there are always edge cases to be dealt with, but making them exceptions and not the rule makes it easier to then minimize the occurence/duration of those exceptions. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 13:03:30 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD9E28C144; Tue, 13 Jan 2009 13:03:30 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C711A28C178 for ; Tue, 13 Jan 2009 13:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 XOiJzinIZkmK for ; Tue, 13 Jan 2009 13:03:22 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 895593A6B19 for ; Tue, 13 Jan 2009 13:03:22 -0800 (PST) Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0DL31jZ020405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2009 13:03:06 -0800 Message-ID: <496D0185.8040303@dcrocker.net> Date: Tue, 13 Jan 2009 13:03:01 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090113205652.99275.qmail@simone.iecc.com> In-Reply-To: <20090113205652.99275.qmail@simone.iecc.com> X-Virus-Scanned: ClamAV 0.92/8861/Tue Jan 13 08:09:19 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 13 Jan 2009 13:03:06 -0800 (PST) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I view the changes as a quick hack. The section needs do its tutorial business more cleanly, explaining the purpose of ADSP and its means of accomplishing it. I suggest that all references to other work be relegated to a separate section rather than, for example, showing up in the Introduction. d/ John Levine wrote: >>> I think what you're referring to is this statement "Instead of the >>> *From*header, ADSP can also be used for publishing that all mails of >>> the >*MAIL FROM*, *Sender*, *Resent-Sender* and *Resent-From* headers have a >>> corresponding DKIM signature." which as >>> far as I know is not correct. >> Wow, is that wrong. I'll see if I can fix it. > > Looks like Dave already did. Thanks. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 14:38:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A5D3A68FE; Tue, 13 Jan 2009 14:38:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501F03A68FE for ; Tue, 13 Jan 2009 14:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hQSH6N+1jmlG for ; Tue, 13 Jan 2009 14:38:27 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 81EBA3A6768 for ; Tue, 13 Jan 2009 14:38:25 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Tue, 13 Jan 2009 22:38:09 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090113203638.GA11831@gsp.org> References: <496A6B33.4010606@terabites.com> <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> Organization: Isode Limited Date: Tue, 13 Jan 2009 22:38:02 +0000 Message-Id: <1231886282.3304.6.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, 2009-01-13 at 15:36 -0500, Rich Kulawiec wrote: > On Tue, Jan 13, 2009 at 06:17:53PM +0000, David Wilson wrote: > > If by "reject" you mean "give a 5xx response to the data from the SMTP > > client, the problem with that is that, as previously discussed, the SMTP > > client server may generate a DSN or similar which returns the infected > > message. It does not know that the reason for non-delivery was the > > suspect message content. You do. So the only safe responses are: > > - discard the message (i.e. accept it over SMTP and then throw it away > > with no further processing, apart from possible archiving). > > - send a DSN or similar which suppresses return of content. > > I've got serious problems with both of those. > > In the first case, you're telling the sending server one thing and > doing another. I don't think that's a good idea on two levels: > at a philosophical level, this seems like a bad way to run an Internet. > At a practical level, doing so fails to alert the sending site that > they may have a problem. (Yes, I'm presuming that they're paying > attention to their own logs...or that they will be more inclined to > do so when they notice 86,000 5xx error messages in them.) > > In the second case, generating DSNs is a bad idea in general [1], > but it's a REALLY bad idea as a response to spam/virus messages. > > Look, I understand the motivation, and it's very noble, but it's > also pointless. A hypothetical virus relying on this method of > propagation will also have many other -- many other SIMPLER -- > ways of delivering itself to the very same targets. The best that > anyone external can do is (a) don't propagate the problem further > (b) communicate via appropriate use of SMTP that there's a problem > and (c) don't make the problem worse or more complicated or more obscure. > > ---Rsk > > [1] It's not that hard to engineer mail architectures -- including > distributed and multi-tier architectures -- that always reject and > never bounce. Yes, there are always edge cases to be dealt with, > but making them exceptions and not the rule makes it easier to > then minimize the occurence/duration of those exceptions. I'm not sure what you are saying should be done. If you reject from an SMTP MTA (not a submitting UA) using a 5xx response, what is that MTA going to do: generate some kind of non-delivery message. Normally, that includes the message which was non-delivered, which the rejecting MTA knows to be malicious. In order to prevent that, we need a status code which means "I am not receiving this message because it has a content which is dangerous". SMTP does not have such a status code. (We are not talking about spam here, which is a different case, we are talking about infected messages.) _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 16:58:13 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB7F3A698E; Tue, 13 Jan 2009 16:58:13 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173453A698E for ; Tue, 13 Jan 2009 16:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, GB_I_LETTER=-2] 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 6b1tUxFQvEXb for ; Tue, 13 Jan 2009 16:58:10 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by core3.amsl.com (Postfix) with ESMTP id DF9923A6974 for ; Tue, 13 Jan 2009 16:58:09 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id C3B5B1352969 for ; Wed, 14 Jan 2009 00:57:54 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, 0a0a9e896f811056, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:2:355:379:599:601:854:945:967:972:973:980:982:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1487:1515:1516:1518:1535:1593:1594:1605:1606:1730:1747:1766:1792:2194:2196:2199:2200:2234:2375:2393:2525:2553:2559:2563:2682:2685:2689:2691:2692:2705:2737:2828:2857:2859:2892:2901:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3657:3743:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4031:4117:4250:4321:4659:5007:6114:6117:6119:6248:7522:7652:7679:7809:7903:7904:8501:8557:8985:9010:9025:9040:9108:9149, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 14 Jan 2009 00:57:54 +0000 (UTC) Message-ID: <496D3892.9020705@terabites.com> Date: Tue, 13 Jan 2009 18:57:54 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org References: In-Reply-To: X-session-marker: 6765703261407465726162697465732E636F6D Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Ah, gotcha. I agree that silently swallowing the message might have spared B a possible infection, but I'm reluctant to blame A's MX for this: it didn't originate, accept or transfer the malware-laden message. I think responsibility lies with M, and/or with whatever system passed the message to M (presuming the message didn't originated on M). Well, regardless of who is pointing the finger at who, the fact remains that: 1) an infected E-mail is being passed on to someone who quite likely had NOTHING to do with sending it, nor did they probably have any control over the system(s) that did; 2) the extra bandwidth was wasted by sending mail to someone who didn't want it, and who can't do anything about it; 3) the resulting infected E-mail is now coming from a computer whose IP address is likely in the (actual final) recipient's "trusted" zone, whereas the original actual origin system might well not be. > While this is a less-than-desirable outcome, I think it may be the best we can do -- we can't block something before we see it, we can only do our best to reject outright spam/malware/junk traffic at the earliest available opportunity. (One of the ways I've expressed this elsewhere is that the best place to stop spam is as near its source as possible. The farther it gets from the origin, the trickier detecting it gets, and the greater the possible consequences.) Actually, I believe that that philosophy is incorrect. First of all, ultimately the ONLY authority which TRULY determines FOR A FACT whether a given piece of e-mail is unwanted or not is the final recipient. Other people enroute might conclude that something PROBABLY is spam, but they cannot be sure. I understand the desirability of stopping spam and viruses as close to the sender as possible, WHERE THAT IS POSSIBLE, but I suggest that it often is not. ULTIMATELY, the recipient of the message (i.e. the addressee, not necessarily the place where it ultimately gets bounced to) has a KEY piece of information that MTAs enroute do not have: the knowledge of the (prior?) trust relationship that exists between the addressee and the purported sender. And, let me point out, this even varies WITHIN a single addressee: I have more than one E-mail address, and use them for different purposes. An E-mail message arriving at the "wrong" address might indicate that it is unwanted, EVEN IF THE SAME SENDER MIGHT BE EXPECTED TO MAIL TO ME AT A DIFFERENT ONE OF MY ADDRESSES. This is part of why I still believe that a finely-grained "permissions list", based on the recipient/orignator e-nmail address pair, AND having access by then to the WHOLE message, can do a SIGNIFICANTLY better job of accurately performing the spam/nospam triage than ANY more generalized SMTP-level MTA could ever hope to do enroute. As I have pointed out before, if I get an e-mail containing an executable (a control panel applet, a hard .EXE file, even a piece of Java script or Active X enclosure or whatever) from someone who (a) I do not know, or (b) who I might know but who I do not expect to send me something like THAT, then it's perfectly reasonable to treat that e-mail as at least HIGHLY suspect. Now, there ARE people I correspond with who I might EXPECT to send me stuff like that, or at least SOME of those sorts of things; obviously those should come through to me fine. But there may be OTHER things I would expect to see in mail from those trusted and familiar correspondents; for example, their familiar sig that they put on the e-mails they send out to me, or the masthead I normally see on their e-newsletter, or whatever. Even maybe the familiar way they address me in the accompanying message. Note that this is not unlike the way most of us actually handle "spam triage" in our inboxes now: we look to see mail coming from unfamiliar senders, or unfamiliar subjects, or for that matter common spam-type subject lines. The key thing is that mail coming from an address we recognize might encourage us to look more closely at mail which we might not give a second thought to deleting if it came from someone unfamiliar. I personally think that mail containing attachments (of any type) or HTML (scripting, ActiveX, misrepresentable links, etc) coming from people I don't know and trust are primary examples of mail that stands a strong probability of being unwanted (or at the very least, untrusted). Now, I would agree that e-mail containing certain types of things can probably be axed at a very early point in the delivery process (an example would be mail containing a recognized virus content, especially a virus known to falsify return addresses...!) BUT it is also VERY frustrating when, for example, I find that an absolutely legitimate e-mail message I have sent out gets bounced back to me by someone enroute, containing something like: [quote] Diagnostic-Code: smtp; 554 The message was rejected because it contains prohibited virus or spam content (in reply to end of DATA command) [end quote] ...and particularly when the message contains neither virus nor spam, and where I have not the slightest idea of who I would need to try to contact (and where, or how) to solve the non-delivery problem. And I presume that the addressee I was sending the mail to has similarly no idea of who they would need to complain to about our mail being intercepted and waylaid enroute. Given the choice, I like the simplicity and correctability of people enroute delivering the mail as requested, and having the recipient's mail client (given the additional knowledge that only it has!) doing the BETTER possible job of deciding how to perform the triage. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:05:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2723A6945; Tue, 13 Jan 2009 17:05:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F2D3A6945 for ; Tue, 13 Jan 2009 17:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_GREY=0.25] 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 vlw4B-zhlhyu for ; Tue, 13 Jan 2009 17:05:44 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 2F5E63A67FB for ; Tue, 13 Jan 2009 17:05:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 2304264F8350 for ; Wed, 14 Jan 2009 13:05:37 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqlkRB4h+GkU for ; Wed, 14 Jan 2009 13:05:35 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 61AB864F834F for ; Wed, 14 Jan 2009 13:05:35 +1200 (FJT) Date: Wed, 14 Jan 2009 13:05:35 +1200 (FJT) From: Franck Martin To: asrg@irtf.org Message-ID: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <8245789.751231894894968.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: [Asrg] Replay attack X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589453517==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============1589453517== Content-Type: multipart/alternative; boundary="----=_Part_38_4869859.1231895120670" ------=_Part_38_4869859.1231895120670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, I received an error report that an email could not be delivered to abuse@genocide.ru. The email that was tried to be sent is below. What is interesting, the email seems to be geniune enough, with a DKIM and DomainKey signature. 1) Do anyone knows where on the web I could paste this email and verify the DKIM ? A kind of web form. 2) The return-path has been forged and it seems to me they proceeded this way, generate a legitimate DKIM signed email on legitimate MTA, strip a few headers and mass-mail directly to everyone? RCPT TO does not have to match the TO in the header. What gives me a hint is that the received headers do not follow each others. Any tips, info to prevents such problems? Or by doing only a DKIM verification, this would tell me this message is forged? Here are only the headers of the email I received in a NDR. ------------------------------- Return-path: Received: from broadband-77-37-184-167.nationalcablenetworks.ru ([77.37.184.167] helo=list.mediresource.com) by direct.va.ru with smtp (Exim 4.53) id 1LMsMZ-0003zp-62 for abuse@genocide.ru; Wed, 14 Jan 2009 02:07:59 +0300 DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=v1; d=rodale.delivery.net; h=DKIM-Signature:Received:Date:From:Reply-to:To:Message-ID:Subject:Errors-to:MIME-Version:Content-Type:X-eid:X-pid; b=KxLNSrM9OzjsF/CMM45qFlc0DKKuizMQ2qWRehZCpFy02QKiFV77rJnRdPOL05om cV0wWuLpX1/TssBxGG61McgmU7b5wRtM3XUlZ0ox33uNNiFkl58VgHIIVXNDDwjc SltQL4r5m5CFxLxC5ifJyVJYw2s12bMZc62AVktX7V4= DKIM-Signature: v=1; a=rsa-sha1; d=rodale.delivery.net; s=v1; c=simple/simple; q=dns/txt; i=@rodale.delivery.net; t=1231488648; h=From; bh=F6VyhuMIBItRiT4Rd3AjarPIreY=; b=jU/ncyJ4g53pvr2on0cSjHW0pxtZqApuauJuTV9XlPVJXFY2vvS4zzs5eiJqpZ2i j56GjtfxU1pWScXrwstgIwm1vb4SxvpN2qhf4uMxeGpsZM3Z5lD9j9GuEMAUME+R oiXm9l4kbSw2zIJ7NP65e9dErI20MZRscu6F6u20dx8=; Received: from [192.168.138.141] ([192.168.138.141:53703] helo=fc14a2.dc1.prod) by oms2.dc1.prod (envelope-from ) (ecelerity 2.2.2.36 r(26875/27517M)) with ESMTP id EF/26-77607-64778138; Wed, 14 Jan 2009 02:05:15 +0300 From: Men's Health Reply-to: MensHealth@rodale.delivery.net To: abuse@genocide.ru Message-ID: <20090114050515.6743.qmail@list.mediresource.com> Subject: RE: Bigger snake for few days n few bucks Errors-to: MensHealth@rodale.delivery.net MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-eid: 2.5.3K5.2hv.12hk7c.CdQNXI..N..1TKO.CTbQEQf0 X-pid: 962 ------=_Part_38_4869859.1231895120670 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >Hi all,

I received an error report that an email could not be deliv= ered to abuse@genocide.ru. The email that was tried to be sent is below.
What is interesting, the email seems to be geniune enough, with a DKIM= and DomainKey signature.

1) Do anyone knows where on the web I coul= d paste this email and verify the DKIM ? A kind of web form.
2) The retu= rn-path has been forged and it seems to me they proceeded this way, generat= e a legitimate DKIM signed email on legitimate MTA, strip a few headers and= mass-mail directly to everyone? RCPT TO does not have to match the TO in t= he header. What gives me a hint is that the received headers do not follow = each others. Any tips, info to prevents such problems? Or by doing only a D= KIM verification, this would tell me this message is forged?

Here ar= e only the headers of the email I received in a NDR.
-------------------= ------------
Return-path: <abuse@genius.com>
Received: fro=
m broadband-77-37-184-167.nationalcablenetworks.ru ([77.37.184.167] helo=3D=
list.mediresource.com)
=09by direct.va.ru with smtp (Exim 4.53)
=09id=
 1LMsMZ-0003zp-62
=09for abuse@genocide.ru; Wed, 14 Jan 2009 02:07:59 +0=
300
DomainKey-Signature: q=3Ddns; a=3Drsa-sha1; c=3Dnofws;
=09s=3Dv1;=
 d=3Drodale.delivery.net;
=09h=3DDKIM-Signature:Received:Date:From:Reply=
-to:To:Message-ID:Subject:Errors-to:MIME-Version:Content-Type:X-eid:X-pid;<=
br>=09b=3DKxLNSrM9OzjsF/CMM45qFlc0DKKuizMQ2qWRehZCpFy02QKiFV77rJnRdPOL05om<=
br>=09cV0wWuLpX1/TssBxGG61McgmU7b5wRtM3XUlZ0ox33uNNiFkl58VgHIIVXNDDwjc
=
=09SltQL4r5m5CFxLxC5ifJyVJYw2s12bMZc62AVktX7V4=3D
DKIM-Signature: v=3D1;=
 a=3Drsa-sha1; d=3Drodale.delivery.net; s=3Dv1; c=3Dsimple/simple;
=09q=
=3Ddns/txt; i=3D@rodale.delivery.net; t=3D1231488648;
=09h=3DFrom;
=
=09bh=3DF6VyhuMIBItRiT4Rd3AjarPIreY=3D;
=09b=3DjU/ncyJ4g53pvr2on0cSjHW0p=
xtZqApuauJuTV9XlPVJXFY2vvS4zzs5eiJqpZ2i
=09j56GjtfxU1pWScXrwstgIwm1vb4Sx=
vpN2qhf4uMxeGpsZM3Z5lD9j9GuEMAUME+R
=09oiXm9l4kbSw2zIJ7NP65e9dErI20MZRsc=
u6F6u20dx8=3D;
Received: from [192.168.138.141] ([192.168.138.141:53703]=
 helo=3Dfc14a2.dc1.prod)
=09by oms2.dc1.prod (envelope-from <MensHeal=
th@rodale.delivery.net>)
=09(ecelerity 2.2.2.36 r(26875/27517M)) with=
 ESMTP
=09id EF/26-77607-64778138; Wed, 14 Jan 2009 02:05:15 +0300
Fr=
om: Men's Health <MensHealth@rodale.delivery.net>
Reply-to: MensHe=
alth@rodale.delivery.net
To: abuse@genocide.ru
Message-ID: <200901=
14050515.6743.qmail@list.mediresource.com>
Subject: RE: Bigger snake =
for few days n few bucks
Errors-to: MensHealth@rodale.delivery.net
MI=
ME-Version: 1.0
Content-Type: text/html; charset=3DUTF-8
Content-Tran=
sfer-Encoding: 7bit
X-eid: 2.5.3K5.2hv.12hk7c.CdQNXI..N..1TKO.CTbQEQf0X-pid: 962

------=_Part_38_4869859.1231895120670-- --===============1589453517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============1589453517==-- From asrg-bounces@irtf.org Tue Jan 13 17:13:57 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB1C3A6A0D; Tue, 13 Jan 2009 17:13:56 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E823A6A0F for ; Tue, 13 Jan 2009 17:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 4zKESsqWghyE for ; Tue, 13 Jan 2009 17:13:54 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by core3.amsl.com (Postfix) with ESMTP id 219C13A69FD for ; Tue, 13 Jan 2009 17:13:53 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id CA0DE42BB9 for ; Wed, 14 Jan 2009 01:13:38 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, cb2ab08af3c25175, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:599:854:945:967:973:980:988:989:1042:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:1963:2196:2199:2393:2525:2553:2559:2563:2682:2685:2693:2705:2737:2743:2828:2857:2859:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3636:3657:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:6114:7652:7679:7903:7974:8501:8985:9025:9040, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf04.hostedemail.com (Postfix) with ESMTP for ; Wed, 14 Jan 2009 01:13:38 +0000 (UTC) Message-ID: <496D3C43.2030100@terabites.com> Date: Tue, 13 Jan 2009 19:13:39 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org X-session-marker: 6765703261407465726162697465732E636F6D Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > But none of this is necessarily true. IF the mail is bounced because it contains a virus or worm, and if that virus or worm is KNOWN to falsify return addresses, then I claim that there is little or no value in bouncing it... because it is not clear that ANYONE working backwards is going to be able to figure out reliably who (if anybody!) should be notified of the problem. It doesn't really much matter which antivirus software identified the message as malicious (although it would be nice to have an audit trail somewhere such that a misbehaving piece of related software can be found and fixed). [snip] > - A human being won't necessarily be harmed by this. For starters, there's no way to know that the message will be delivered. If the putative sender is elsewhere, then the mail system there might detect and reject the message. The putative sender's mail client may be using an anti-virus product that detects it. Or the putative sender may never "open" the message (which seems to effectively defuse most, but not all, of these problems). That's a bogus argument. You're basically saying that "someone else will probably pick up on this" and using that as a (lame) excuse to lob a grenade their way. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:31:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7653A691D; Tue, 13 Jan 2009 17:31:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85F93A691D for ; Tue, 13 Jan 2009 17:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BkXNHObP2qwI for ; Tue, 13 Jan 2009 17:31:35 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BE3343A6816 for ; Tue, 13 Jan 2009 17:31:34 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0E1VGo28149 for ; Wed, 14 Jan 2009 01:31:16 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 20:31:16 -0500 Received: from [47.9.28.23] (47.9.28.23) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 13 Jan 2009 20:31:15 -0500 Message-ID: <496D4062.1080509@nortel.com> Date: Tue, 13 Jan 2009 20:31:14 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3892.9020705@terabites.com> In-Reply-To: <496D3892.9020705@terabites.com> X-OriginalArrivalTime: 14 Jan 2009 01:31:16.0174 (UTC) FILETIME=[CB13D6E0:01C975E7] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Gordon Peterson wrote: > BUT it is also VERY frustrating when, for example, I find that an > absolutely legitimate e-mail message I have sent out gets bounced back > to me by someone enroute, containing something like: > > [quote] > > Diagnostic-Code: smtp; 554 The message was rejected because it contains > prohibited virus or spam content (in reply to end of DATA command) > > [end quote] Then most of your concern should evaporate if the message said this: This is the mail delivery agent at I was not able to deliver your message to the following addresses. : : 47.248.0.48 failed after I sent the message. Remote host said: 552 Blocked by filters. If in error, please forward the Session ID: 1231875923.136530000117@ecarhea1) to @nortel.com ONLY (#5.7.1) Instead. [I redacted the userids because that's a _real_ reject message.] > ...and particularly when the message contains neither virus nor spam, > and where I have not the slightest idea of who I would need to try to > contact (and where, or how) to solve the non-delivery problem. See above. > And I presume that the addressee I was sending the mail to has similarly > no idea of who they would need to complain to about our mail being > intercepted and waylaid enroute. In our case, you'd presume incorrectly. > Given the choice, I like the simplicity and correctability of people > enroute delivering the mail as requested, and having the recipient's > mail client (given the additional knowledge that only it has!) doing the > BETTER possible job of deciding how to perform the triage. It's been our experience that the recipients all too often lack the experience and technical knowledge to do the triage in the most dangerous emails. By far the majority of our users want _us_ to stop the crap. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:38:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AC33A6A71; Tue, 13 Jan 2009 17:38:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A602C3A6A71 for ; Tue, 13 Jan 2009 17:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Y8ZHYiziYGc2 for ; Tue, 13 Jan 2009 17:38:26 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id BC5293A6A62 for ; Tue, 13 Jan 2009 17:38:26 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0E1cBtZ027144 for ; Tue, 13 Jan 2009 20:38:11 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0E1TRfV030223 for ; Tue, 13 Jan 2009 20:29:27 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0E1c4Od026359 for ; Tue, 13 Jan 2009 20:38:04 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0E1c2nD026342 for asrg@irtf.org; Tue, 13 Jan 2009 20:38:02 -0500 Date: Tue, 13 Jan 2009 20:38:02 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114013801.GA18217@gsp.org> References: <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231886282.3304.6.camel@bravo.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 13, 2009 at 10:38:02PM +0000, David Wilson wrote: > I'm not sure what you are saying should be done. If you reject from an > SMTP MTA (not a submitting UA) using a 5xx response, what is that MTA > going to do: generate some kind of non-delivery message. Normally, that > includes the message which was non-delivered, which the rejecting MTA > knows to be malicious. In order to prevent that, we need a status code > which means "I am not receiving this message because it has a content > which is dangerous". SMTP does not have such a status code. Yes, I know. (And while I recognize that having such a status code might help solve some problems, it would also open others. Among other things, "malicious" isn't universal. And anti-virus software does not have a 0% FP rate.) What I'm saying is that the recipient MTA should just 5XX the message and hang up. [1] That's all it can do without either (a) making the problem worse and/or (b) redirecting the problem and/or (c) doing something very broken like claiming to accept a message and then /dev/null'ing it. There's no way to "fix" the presenting MTA, if we agree for the sake of argument that it's broken. There's not even any way, with the limited information available during the SMTP conversation, to figure out *how* it's broken. Maybe it's an open relay; maybe it's not but is relaying a virus from an already-infected user; maybe it itself is infected; maybe a kazillion other things. So the best course of action is that which contains the damage, doesn't break anything else, minimizes SMTP traffic: 5XX it and move on. There's no way to know what the consequences will be on the presenting side -- maybe none, maybe some, maybe a lot -- so there's no point in guessing. At least the 5XX gives the presenting side a "heads up", if they're paying attention, that something's amiss. ---Rsk [1] If the problem repeats incessantly or rapidly, maybe 4XX'ing everything for a while would be in order. In some cases, refusing the incoming connection might be appropriate. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:46:42 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206EC28C0D6; Tue, 13 Jan 2009 17:46:42 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5DC3A6A4A for ; Tue, 13 Jan 2009 17:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AW4B0JJjphox for ; Tue, 13 Jan 2009 17:46:40 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 6FD393A6A19 for ; Tue, 13 Jan 2009 17:46:40 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0E1kOSr018479 for ; Tue, 13 Jan 2009 20:46:25 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0E1bfrN022114 for ; Tue, 13 Jan 2009 20:37:42 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0E1kJax029898 for ; Tue, 13 Jan 2009 20:46:19 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0E1kJsU029897 for asrg@irtf.org; Tue, 13 Jan 2009 20:46:19 -0500 Date: Tue, 13 Jan 2009 20:46:19 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114014619.GB18217@gsp.org> References: <496D3C43.2030100@terabites.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496D3C43.2030100@terabites.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 13, 2009 at 07:13:39PM -0600, Gordon Peterson wrote: > That's a bogus argument. You're basically saying that "someone else > will probably pick up on this" and using that as a (lame) excuse to lob > a grenade their way. Perhaps you should review the SMTP protocol: sending a 5XX response *refuses* delivery of a message. It does not transmit (or retransmit) a message. It is difficult to see how one can be accused of "lob[bing] a grenade" when one has never taken possession of it. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:47:04 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B51128C0FD; Tue, 13 Jan 2009 17:47:04 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9963128C0FD for ; Tue, 13 Jan 2009 17:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 djf54Y-SCNx6 for ; Tue, 13 Jan 2009 17:47:02 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 5E21A28C0DD for ; Tue, 13 Jan 2009 17:47:02 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0E1khN21151 for ; Wed, 14 Jan 2009 01:46:43 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 20:46:41 -0500 Received: from [47.9.28.23] (47.9.28.23) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 13 Jan 2009 20:46:40 -0500 Message-ID: <496D43FF.9030707@nortel.com> Date: Tue, 13 Jan 2009 20:46:39 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> X-OriginalArrivalTime: 14 Jan 2009 01:46:41.0367 (UTC) FILETIME=[F2891670:01C975E9] Subject: Re: [Asrg] Replay attack X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > Hi all, > > I received an error report that an email could not be delivered to > abuse@genocide.ru. The email that was tried to be sent is below. > > What is interesting, the email seems to be geniune enough, with a DKIM > and DomainKey signature. > > 1) Do anyone knows where on the web I could paste this email and verify > the DKIM ? A kind of web form. It won't verify, because it's signing the To, I have a copy with a different To, with the same signature. There's at least one BOT going around inserting fixed DKIM signatures. > Return-path: > Received: from broadband-77-37-184-167.nationalcablenetworks.ru ([77.37.184.167] helo=list.mediresource.com) > by direct.va.ru with smtp (Exim 4.53) > id 1LMsMZ-0003zp-62 > for abuse@genocide.ru; Wed, 14 Jan 2009 02:07:59 +0300 It came from the above IP. The rest is fakery. I have quite a number of these with radically different peer addresses. Eg: Received: from dsl15-117.express.oricom.ca (HELO list.mediresource.com) (64.18.184.117) by ertps004.nortel.com (qpsmtpd/0.43rc1) with SMTP; Tue, 13 Jan 2009 20:41:0 1 -0500 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 17:49:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC5228C0D6; Tue, 13 Jan 2009 17:49:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CF13A6A4A for ; Tue, 13 Jan 2009 17:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.143 X-Spam-Level: X-Spam-Status: No, score=-9.143 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 MijQRcYvvyBR for ; Tue, 13 Jan 2009 17:49:21 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id E9FC43A6A19 for ; Tue, 13 Jan 2009 17:49:20 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA03513; Tue, 13 Jan 2009 20:49:05 -0500 (EST) From: der Mouse Message-Id: <200901140149.UAA03513@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 13 Jan 2009 20:34:15 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <496D3892.9020705@terabites.com> References: <496D3892.9020705@terabites.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Well, regardless of who is pointing the finger at who, the fact > remains that: > 1) an infected E-mail is being passed on to someone who quite likely > had NOTHING to do with sending it, nor did they probably have any > control over the system(s) that did; True in the scenario outlined. But there is no way for the host issuing the SMTP-level reject to know, in general, that that is the case; whether a bounce to anyone is generated is up to the SMTP client's software. (Direct-to-MX spamware, for example, generally does not generate bounces in reaction to rejections.) Furthermore, even the best malware detection FPs at least occasionally. If my mail to my friend produces a FP, the _last_ thing I want is for it to silently vanish. (Furthermore, the presence of malware does not necessarily mean the mail is unwanted or shouldn't be delivered; I have no trouble imagining researchers mailing samples to one another. Yes, they _can_ encrypt them or some such, but I see no a priori reason they should have to.) > 2) [...] > 3) [...] > First of all, ultimately the ONLY authority which TRULY determines > FOR A FACT whether a given piece of e-mail is unwanted or not is the > final recipient. If there is one. A lot of spam, and probably a nontrivial amount of malware-bearing email, has no existent addresses anywhere in the envelope (often, not in the headers either). Who is the "final recipient" of such a message? > Note that this is not unlike the way most of us actually handle "spam > triage" in our inboxes now: we look to see mail coming from > unfamiliar senders, or unfamiliar subjects, or for that matter common > spam-type subject lines. Who's this "we"? That's certainly not how I triage my email; the first thing I look at for most of the mail that reaches my mailbox is the beginning of the body. At least a moderate fraction of my mail I never read the Subject: or From: of at all. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 18:25:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C106D3A6A62; Tue, 13 Jan 2009 18:25:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6487928C143 for ; Tue, 13 Jan 2009 18:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 P2jqJuQ4zyCW for ; Tue, 13 Jan 2009 18:25:35 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 10E533A6A4A for ; Tue, 13 Jan 2009 18:25:34 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0E2PHj3010757 for ; Tue, 13 Jan 2009 21:25:20 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0E2GXmP001396 for ; Tue, 13 Jan 2009 21:16:34 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0E2PAIe011873 for ; Tue, 13 Jan 2009 21:25:10 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0E2PAO7011872 for asrg@irtf.org; Tue, 13 Jan 2009 21:25:10 -0500 Date: Tue, 13 Jan 2009 21:25:10 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114022510.GA30167@gsp.org> References: <496D3892.9020705@terabites.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496D3892.9020705@terabites.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I'm only going to tackle two of the many points contained therein. On Tue, Jan 13, 2009 at 06:57:54PM -0600, Gordon Peterson wrote: > First of all, ultimately the ONLY authority which TRULY determines FOR A > FACT whether a given piece of e-mail is unwanted or not is the final > recipient. No, not really. There are multiple authorities which may determine whether a given message is accepted or not. For example: it's possible that network engineers have implemented the Spamhaus DROP list in the border routers of a site, that systems engineers have used the NJBAL DNSBL in a mail system's configuration, and that an end user has used a local filter such as Spambouncer (which does not bounce, by the way). Thus, the logical AND of all three permissions is required before a message will reach a user. This is as it should be: network engineers are probably best positioned to use effective mechanisms like the DROP list -- doubly so since best usage of it encompasses more than just SMTP. Morever, network engineers, charged with the responsibility for implementing a comprehensive network defense policy, may -- correctly in my opinion -- conclude that *regardless* of what any end user wants, permitting traffic to/from networks on the DROP list is a very bad idea. Similar considerations apply to systems admins and end users. End users have been known to argue that this is a Bad Thing, because they cannot get mail they want. I counter-argue that deliberately allowing them to receive mail from J. Random Well-Known spammer is every bit as dangerous to them as deliberately allowing them to receive the Outlook virus-of-the-day, or allowing known-malicious packets to reach the network interface on their system. End users counter-counter-argue that this is fascist and draconian and etc., but usually decline the "opportunity" to be moved outside the effective network perimeter and receive ALL mail, sans any spam or malware filtering, and to be exposed to ALL network traffic. And so on, endlessly goes the policy debate. But my point is that in most environments, there are multiple "layers", if you will, of accept/reject decision-making going on, and while some of those layers may be based on criteria like "wanted", others may not be. None of this is a problem to the rest of us -- nobody is obligated to accept anyone's SMTP traffic -- as long as the accept/reject decision is clearly communicated to the outside world so that can all tell what the heck is going on. > ...and particularly when the message contains neither virus nor spam, > and where I have not the slightest idea of who I would need to try to > contact (and where, or how) to solve the non-delivery problem. It's been a best practice for a long time to arrange for every rejection message to contain a human-readable string that gives some clue as to what the problem was AND provides a means of resolving the problem, should there be a mistake. (This is in addition to the mandatory "postmaster" address and the not-quite-so-mandatory-but-still-a-darn-good-idea "abuse" address.) Part of the problem here lies with broken mail systems that either (a) mangle these strings or (b) substitute their own, neatly undercutting the process. Another part lies with end users, who often cannot or will not take the time to read the rejection message, or won't follow the instructions in it, or who presume that the most likely possibility is not, perhaps, a history of spam from the same mail system, or an errant filter, or a typo, but a personal vendetta directed solely at them for no particular reason. [1] And of course, most of the problem lies with mail systems that don't even try to do this, or whose operators blithely presume that their FP rate is 0%. [2] Incidentally, consider how much worse this problem would get if -- instead of returning a possibly-cryptic error message lacking a recourse -- the recipient system simply discarded your message. ---Rsk [1] See the Truthout & AOL debacle for an example, and note the following for guidance in such situations: Vir: "Londo, they could have killed me!" Londo: "Nonsense, you are not important enough to kill." [2] Maybe it's just me, but it seems that those using appliances are particularly prone to this. "But we paid a lot of money for it, it can't be wrong", someone actually wrote to me. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 18:30:44 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CF828C0FD; Tue, 13 Jan 2009 18:30:44 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2BF28C146 for ; Tue, 13 Jan 2009 18:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VKCNBJ8Mm8rv for ; Tue, 13 Jan 2009 18:30:36 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 0054428C0FD for ; Tue, 13 Jan 2009 18:30:35 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0E2UK4A024266 for ; Tue, 13 Jan 2009 21:30:21 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0E2Lael006600 for ; Tue, 13 Jan 2009 21:21:37 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0E2UDfF014824 for ; Tue, 13 Jan 2009 21:30:13 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0E2UDlr014823 for asrg@irtf.org; Tue, 13 Jan 2009 21:30:13 -0500 Date: Tue, 13 Jan 2009 21:30:13 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114023013.GB30167@gsp.org> References: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> <496D43FF.9030707@nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496D43FF.9030707@nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Replay attack X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 13, 2009 at 08:46:39PM -0500, Chris Lewis wrote: > It won't verify, because it's signing the To, I have a copy with a > different To, with the same signature. Yep, same here. My copy appears to have been deliberately backscattered of an Exchange server (dsmail01.deansteel.com) -- unless, of course, that server's been botted, in which case no backscatter necessary. Most interesting; do either of you think this is a test run for something more subtle? ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 18:32:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE0128C183; Tue, 13 Jan 2009 18:32:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4EB28C183 for ; Tue, 13 Jan 2009 18:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 seljS45PD8Ku for ; Tue, 13 Jan 2009 18:32:27 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id A7E5728C16B for ; Tue, 13 Jan 2009 18:32:27 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id B0574808B2 for ; Tue, 13 Jan 2009 18:32:08 -0800 (PST) Message-Id: <80ACA5D0-CD29-4AA6-8E82-3F197FE56771@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <20090114023013.GB30167@gsp.org> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 18:32:11 -0800 References: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> <496D43FF.9030707@nortel.com> <20090114023013.GB30167@gsp.org> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] Replay attack X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 13, 2009, at 6:30 PM, Rich Kulawiec wrote: > On Tue, Jan 13, 2009 at 08:46:39PM -0500, Chris Lewis wrote: >> It won't verify, because it's signing the To, I have a copy with a >> different To, with the same signature. > > Yep, same here. My copy appears to have been deliberately > backscattered > of an Exchange server (dsmail01.deansteel.com) -- unless, of course, > that server's been botted, in which case no backscatter necessary. > Most interesting; do either of you think this is a test run for > something more subtle? More likely accidental. Creating boilerplates for spamware by copying headers from a random legitimate message is nothing new (e.g. TheBat). Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 19:04:41 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15AD3A6A4A; Tue, 13 Jan 2009 19:04:41 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2553A69AD for ; Tue, 13 Jan 2009 19:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 W17MghHdpGCZ for ; Tue, 13 Jan 2009 19:04:39 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 276B53A6358 for ; Tue, 13 Jan 2009 19:04:38 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0E30YX21551 for ; Wed, 14 Jan 2009 03:00:34 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 22:04:19 -0500 Received: from [47.9.28.23] (47.9.28.23) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 13 Jan 2009 22:04:19 -0500 Message-ID: <496D5632.1080401@nortel.com> Date: Tue, 13 Jan 2009 22:04:18 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <14408623.771231895120671.JavaMail.franck@franck-martins-macbook-pro.local> <496D43FF.9030707@nortel.com> <20090114023013.GB30167@gsp.org> <80ACA5D0-CD29-4AA6-8E82-3F197FE56771@blighty.com> In-Reply-To: <80ACA5D0-CD29-4AA6-8E82-3F197FE56771@blighty.com> X-OriginalArrivalTime: 14 Jan 2009 03:04:19.0631 (UTC) FILETIME=[CB13C3F0:01C975F4] Subject: Re: [Asrg] Replay attack X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Steve Atkins wrote: > On Jan 13, 2009, at 6:30 PM, Rich Kulawiec wrote: > >> On Tue, Jan 13, 2009 at 08:46:39PM -0500, Chris Lewis wrote: >>> It won't verify, because it's signing the To, I have a copy with a >>> different To, with the same signature. >> Yep, same here. My copy appears to have been deliberately >> backscattered >> of an Exchange server (dsmail01.deansteel.com) -- unless, of course, >> that server's been botted, in which case no backscatter necessary. >> Most interesting; do either of you think this is a test run for >> something more subtle? > > More likely accidental. Creating boilerplates for spamware > by copying headers from a random legitimate message is > nothing new (e.g. TheBat). I would suggest that this tidbit doesn't get spread beyond your own filters: they _all_ HELO as list.mediresource.com... [We've seen over 12,000 different IPs doing it in the past hour or three. This must be a "newish" template writer. More likely never knew that such a blatant giveaway would do him harm, as opposed to forgetting. This will probably be short-lived. But you never know - I've seen a giveaway like this last for over a year.] It's entirely normal for bot writers to build templates off of email samples they've acquired. In this particular case, it might even be possible to track it back to _who_ actually had the email. However, as this is the second instance of this (another set of DKIM forgeries appeared about a week ago) I suspect one particular spammer _thinks_ the DKIM signatures will improve his deliverability. Whether he understands that it won't verify OR he presumes (and he may be right) that just mentioning DKIM in the headers might actually work more often than not, I'm not going to guess. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 13 21:27:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945E43A6A62; Tue, 13 Jan 2009 21:27:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB353A6A4A for ; Tue, 13 Jan 2009 21:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BfJHuo8TZ87a for ; Tue, 13 Jan 2009 21:27:07 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CC94D3A6877 for ; Tue, 13 Jan 2009 21:27:06 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0E5QlE08489 for ; Wed, 14 Jan 2009 05:26:48 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 00:26:32 -0500 Received: from [47.9.28.23] (47.9.28.23) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 14 Jan 2009 00:26:32 -0500 Message-ID: <496D7787.1080100@nortel.com> Date: Wed, 14 Jan 2009 00:26:31 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3892.9020705@terabites.com> In-Reply-To: <496D3892.9020705@terabites.com> X-OriginalArrivalTime: 14 Jan 2009 05:26:32.0576 (UTC) FILETIME=[A91BD800:01C97608] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Gordon Peterson wrote: > First of all, ultimately the ONLY authority which TRULY determines FOR A > FACT whether a given piece of e-mail is unwanted or not is the final > recipient. You're being awfully absolute in that statement. RSK has outlined entities (other than the final recipient) who do. That of course you'd counter with "but they shouldn't". So, I'm going to take a different tack - outlining why many should. And in some cases legally must. As a corporate, our email infrastructure is for our business purposes. While we do permit reasonable personal use, exposing our infrastructure, IP or employees to risk of malicious content is simply not on. It's our infrastructure, for us, we need to protect it. For any medium-large infrastructure, they can't _afford_ to let viruses in. Simply from the perspective of self-preservation and integrity of their own networks. Secondly, at least in a business context, there are laws about workplace environment that _require_ us to filter certain things. > Other people enroute might conclude that something PROBABLY is spam, but > they cannot be sure. There are many cases where "people enroute" can be absolutely certain it's spam. Apropos my other posting: anything saying "HELO list.mediresource.com" (except possibly from 209.82.15.228, it's other SPF-permitted IP helos as tempmail.mediresource.com) is spam. Their SPF says so, and all of the emails contain bogus DKIM signatures. We _know_ it's a bot. There are many times you can tell, absolutely with no FPs, that an email is sent by a BOT. Certainly, if you're a, say, spam or virus researcher, you might want to get your email flow raw. Fine. Just don't expect a commodity ISP to accommodate you at commodity prices. They simply can't afford the risk to their infrastructure. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 01:05:43 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CC028C145; Wed, 14 Jan 2009 01:05:43 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F0C3A67F2 for ; Wed, 14 Jan 2009 01:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 whac6+6Z89Ea for ; Wed, 14 Jan 2009 01:05:40 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 07F713A6B4A for ; Wed, 14 Jan 2009 01:05:38 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 09:05:18 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090114014619.GB18217@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> Organization: Isode Limited Date: Wed, 14 Jan 2009 09:04:58 +0000 Message-Id: <1231923898.3253.8.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, 2009-01-13 at 20:46 -0500, Rich Kulawiec wrote: > On Tue, Jan 13, 2009 at 07:13:39PM -0600, Gordon Peterson wrote: > > That's a bogus argument. You're basically saying that "someone else > > will probably pick up on this" and using that as a (lame) excuse to lob > > a grenade their way. > > Perhaps you should review the SMTP protocol: sending a 5XX response > *refuses* delivery of a message. It does not transmit (or retransmit) > a message. It is difficult to see how one can be accused of "lob[bing] > a grenade" when one has never taken possession of it. Because of the normal action of an MTA when it receives such an 5XX response, i.e. it sends a non-delivery message, normally containing the message, to the return path address. If that return path address is forged, then the infection is bounced elsewhere. That is the grenade. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 01:12:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8B428C0DE; Wed, 14 Jan 2009 01:12:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D32328C0DE for ; Wed, 14 Jan 2009 01:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.176 X-Spam-Level: X-Spam-Status: No, score=-9.176 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 gghATEJ4gBeV for ; Wed, 14 Jan 2009 01:12:48 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id BF2B73A681C for ; Wed, 14 Jan 2009 01:12:47 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id EAA12786; Wed, 14 Jan 2009 04:12:32 -0500 (EST) From: der Mouse Message-Id: <200901140912.EAA12786@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 14 Jan 2009 03:52:30 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <496D7787.1080100@nortel.com> References: <496D3892.9020705@terabites.com> <496D7787.1080100@nortel.com> Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> First of all, ultimately the ONLY authority which TRULY determines >> FOR A FACT whether a given piece of e-mail is unwanted or not is the >> final recipient. > You're being awfully absolute in that statement. And in the sense of "unwanted" that I think its author meant, there's nothing wrong with that. I think that "unwanted" is something like "the human behind the destination address would prefer to receive the mail". You - and others - seem to be using values of "unwanted" that include "I don't care who would like to receive it, we don't want to carry it". > Apropos my other posting: anything saying "HELO > list.mediresource.com" (except possibly from 209.82.15.228, it's > other SPF-permitted IP helos as tempmail.mediresource.com) is spam. Um, no, not if it's not bulk. Want me to telnet to your MX host and generate an example manually? :-) > Certainly, if you're a, say, spam or virus researcher, you might want > to get your email flow raw. Fine. Just don't expect a commodity ISP > to accommodate you at commodity prices. They simply can't afford the > risk to their infrastructure. Oh, nonsense. If that constitutes any risk to their infrastructure, they *urgently* need to fix the bugs in question anyway! Their infrastructure has no need to do anything with executable - or any other - content in the mail, except storing it for delivery to the customer on request. Unless they're trying to do content-based filtering, of course, but if their content filtering setup is vulnerable to infection from malware-bearing email, it is catastrophically broken already; it's _job_ is to deal with such mail. The only way I can see any risk to their infrastructure is if their staff use their own services for mail, read mail with MUAs and OSes vulnerable to infestation by email-borne malware, their infrastructure hosts run similarly vulnerable OSes, and their network design permits their staff mail-reading hosts to infect their infrastructure. While the first of these is likely and the second is plausible, the rest are nobody's fault but their own. Any risk to their infrastructure is created by their boneheaded design and actions far more than it is by lack of filtering on independent customer mail streams. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 01:25:26 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F673A6B40; Wed, 14 Jan 2009 01:25:26 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAF628C149 for ; Wed, 14 Jan 2009 01:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ZkOZDMN5u1LT for ; Wed, 14 Jan 2009 01:25:23 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9DC3B3A687E for ; Wed, 14 Jan 2009 01:25:16 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 09:24:57 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090114013801.GA18217@gsp.org> References: <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> Organization: Isode Limited Date: Wed, 14 Jan 2009 09:24:45 +0000 Message-Id: <1231925085.3253.23.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, 2009-01-13 at 20:38 -0500, Rich Kulawiec wrote: > And anti-virus software does not have a 0% FP rate.) > I would be interested to know what actual numbers for, or perhaps some specific instances of, FP from anti-virus. I would be surprised if a non-malicious message would fall foul of AV software unless it contained some kind of executable content. It should not be surprising that a message with executable content runs into problems. FN rates for AV are non-zero, particularly in the few hours after the appearance of a new variant, when the different AV folk are updating their signatures, and the users are downloading them. So it is sometimes not surprising that one MTA finds a virus in a message from another MTA which is doing AV, but the message just hit it in a unfortunate window. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 04:02:15 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7958F3A68B4; Wed, 14 Jan 2009 04:02:15 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F296D3A68AC for ; Wed, 14 Jan 2009 04:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.821 X-Spam-Level: X-Spam-Status: No, score=-14.821 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 2+IHo+m+Ooun for ; Wed, 14 Jan 2009 04:02:12 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 7B6A03A63EC for ; Wed, 14 Jan 2009 04:02:12 -0800 (PST) Received: (qmail 96226 invoked from network); 14 Jan 2009 12:01:57 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 14 Jan 2009 12:01:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=gZKUutuU0jk7XzAuIl9H9YRdEk3bUvkKVmiNTScEdzc=; b=lBfFJEAh1+9Dtgzmz32TnVNP0+ofdGXqZc2Z/ov1MupsWsAcm5smInR9o09e7p+ZWItamApwkg2gUn4oxQ/5Hqm7WwMsqLbve6rMtxAVVTj4/Ty3tV1X2JHK/CoKUKRLc231KmClRE2gpffVJvlo/jjtd1b7FWqtV7LAciXePDk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=gZKUutuU0jk7XzAuIl9H9YRdEk3bUvkKVmiNTScEdzc=; b=aZSi5WRpF7Qb+9N3pL1S+oL2QAREYVoTs9a1wW6FLJmiYGdGDmqcHiFiyGzT06Wyzs4ugijrMCHiFPPDsMt8eAzjejNFRpB3ja//xxKICkj++WiMYYJOWCUb4mCKsslQeX2GIcJIACCgiBhPx+69PzV/vGucsGbaKEQjFjuNy6w= Date: 14 Jan 2009 12:01:55 -0000 Message-ID: <20090114120155.71225.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <1231925085.3253.23.camel@bravo.isode.net> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] virus detectors, was where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >I would be surprised if a non-malicious message would fall foul of AV >software unless it contained some kind of executable content. It should >not be surprising that a message with executable content runs into >problems. When I catch a virus and the sending IP is one for whom I have a known contact address, I send off an autoreport with the first 50 lines of the virus (in case they're wondering what virus it is), and the first line of the base64 of the virus denatured with xxxx so that even if an overenthusiastic Windows MUA were to try to run it, it wouldn't start. Nonetheless, I have problems all the time with my reports being rejected by poorly written virus filters. In one case they've been adding me to a virus sending blacklist, telling me that even though they know I'm not sending viruses, their AV detects it so it must be my fault. Sheesh. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 04:43:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C03A69B6; Wed, 14 Jan 2009 04:43:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11703A69B6 for ; Wed, 14 Jan 2009 04:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SJmHMzeS962w for ; Wed, 14 Jan 2009 04:43:05 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id AEFFB3A6993 for ; Wed, 14 Jan 2009 04:43:05 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0ECgnKu005295 for ; Wed, 14 Jan 2009 07:42:50 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0ECY58F001115 for ; Wed, 14 Jan 2009 07:34:05 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0ECggYH005296 for ; Wed, 14 Jan 2009 07:42:42 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0ECge6J005246 for asrg@irtf.org; Wed, 14 Jan 2009 07:42:40 -0500 Date: Wed, 14 Jan 2009 07:42:40 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114124240.GA26583@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231923898.3253.8.camel@bravo.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 14, 2009 at 09:04:58AM +0000, David Wilson wrote: > > Perhaps you should review the SMTP protocol: sending a 5XX response > > *refuses* delivery of a message. It does not transmit (or retransmit) > > a message. It is difficult to see how one can be accused of "lob[bing] > > a grenade" when one has never taken possession of it. > > Because of the normal action of an MTA when it receives such an 5XX > response, i.e. it sends a non-delivery message, normally containing the > message, to the return path address. If that return path address is > forged, then the infection is bounced elsewhere. That is the grenade. First, even if this is the case -- and it's rather unlikely that it is, as I'll get to in a minute -- it is obviously disengenuous to accuse the refusing system of being responsible for this situation. And second, have you (rhetorical you) been paying attention to the origination points of the vast majority of attempted malware deliveries over the past decade? They're coming from places like this (seen within the last hour here): 11.red-81-43-100.staticip.rima-tde.net [81.43.100.11] 12-216-204-70.client.mchsi.com [12.216.204.70] 122-82-124-91.pool.ukrtel.net [91.124.82.122] 1809ds4-fb.0.fullrate.dk [90.184.161.72] 78-0-202-32.adsl.net.t-com.hr [78.0.202.32] 89-180-255-125.net.novis.pt [89.180.255.125] cable-87-116-168-96.dynamic.sbb.rs [87.116.168.96] cpe-69-133-71-112.columbus.res.rr.com [69.133.71.112] ip-90-187-210-98.web.vodafone.de [90.187.210.98] Do you think any of those are actual mail servers? Do you think that any of them actually are running an SMTP engine which does something with rejected traffic? Do you think that any of them are running an SMTP engine which even *notices* rejected traffic? Malware authors have long since [mostly] outgrown the need to use existing mail systems for distribution. Why should they limit themselves to a small number of systems (~100K if the Leisi Conjecture is correct) when they can use hundreds of millions? And why should they bother coding elaborate, fully-functional, standards-compliant SMTP engines when they don't care and have no reason to care about most of that functionality? Third, you cannot know the state of a system which presents messages carrying malware. It might be okay, except that its particular anti-virus setup did not detect this particular virus at this particular time. Or it might be fully-compromised, 0wned by the enemy, and repurposed as a full-time virus distribution engine. Or anything in between, or something quite different. Because you CANNOT know its state, you CANNOT predict what it will do in response to any SMTP response code you send it. It *might* generate an NDR. It *might* ignore it. It *might* try sending the same message again. It *might* crash instantly. It *might* do all kinds of other things. [1] Because you can't know this, it's pointless to speculate, and even more pointless to arbitrarily choose one possibility among many and then try to address that one as if it were a certainty. It's clear that the best you can do is to refuse the traffic, at which point you've done your part not just for your own operation, but for the rest of the 'net as well. (And optionally, depending on circumstances, refuse *all* traffic from it, as I do from the hosts above, since it's clear that 100% of everything they will ever present will be spam and malware.) Fourth, and this veers a bit off-topic, but do realize that not everyone uses the markedly inferior operating systems which are routinely compromised via malware authored by mere children. I consider any operating system which requires anti-malware software to survive in the wild to be seriously broken and therefore unworthy of any further consideration. ("The brakes on this car don't work, but you can buy this add-on which will patch them...") Yet, out of a sense of responsibility to the greater Internet community, I've expended considerable time and money designing and deploying anti-malware measures, NOT for my benefit, because I don't care about malware and don't have to care, but for theirs. However, the reach of those measures, like everything else I've done, extends only as far as the perimeter of my own operation. That's also as far as my responsibility extends. I can't affect what happens "out there", other than perhaps indirectly via my limited power of persuasion, and I certainly can't be held accountable for it. On the other hand, who can we hold accountable for cpe-69-133-71-112.columbus.res.rr.com [69.133.71.112] and the other systems like it? I'll argue: a) the putative (former) owner whose desk or lap it sits on b) the new (real) owner(s) who have repurposed it c) RoadRunner's network engineers d) the vendor of the operating system it's running (do I even need to mention which one passive OS fingerprinting indicates?) So if we must get into a policy debate about responsibility, I'll be happy to engage in discussion about which of a-d should be at the front of the line, and which should bring up the rear. ---Rsk [1] In the typical case of zombies like the ones I listed above, the treatment of *any* SMTP response code is "ignore it". The SMTP engines installed on such systems are designed to maximize attempted deliveries per unit time, and one excellent way to do that is to ignore everything sent back by the recipient MX. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 05:00:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED863A6B10; Wed, 14 Jan 2009 05:00:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36B23A6B10 for ; Wed, 14 Jan 2009 05:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SO4sCDV8ylLe for ; Wed, 14 Jan 2009 05:00:49 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8F5343A63EC for ; Wed, 14 Jan 2009 05:00:48 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 13:00:32 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090114124240.GA26583@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> Organization: Isode Limited Date: Wed, 14 Jan 2009 13:00:32 +0000 Message-Id: <1231938032.32316.13.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-14 at 07:42 -0500, Rich Kulawiec wrote: > And second, have you (rhetorical you) been paying attention to the > origination points of the vast majority of attempted malware > deliveries over the past decade? The error here is to assume that you get the message from the originating system. There are scenarios in which you get the message from an innocent (perhaps in more than one sense of the word) *intermediate* MTA. It is the reaction of such an MTA to a rejection which is the problem. An intermediate MTA is not be a open relay, because relaying is often defined in terms of the system from which the message arrives. For instance, a company has a "boundary" MTA. A PC within the company's network is compromised (the user accessed an unsuitable web site in their lunch break). The trojan sends messages via the boundary MTA. Unless that MTA checks the return-path address, and the boundary MTA picks up on the virus, then the rejection by the next hop MTA is a problem. After all, if the "MTA" from which you received the infected message is not innocent, perhaps not even a proper MTA, then rejecting the message is also pointless. The rejection will be ignored, and so the overall effect will be the same as if it were accepted and discarded. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 05:45:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1E528C129; Wed, 14 Jan 2009 05:45:59 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05D93A6B60 for ; Wed, 14 Jan 2009 05:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qklR1ATEbyvs for ; Wed, 14 Jan 2009 05:45:57 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id E535328C119 for ; Wed, 14 Jan 2009 05:45:56 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0EDjbV7014515 for ; Wed, 14 Jan 2009 08:45:40 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0EDarWd012508 for ; Wed, 14 Jan 2009 08:36:53 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0EDjW5t022040 for ; Wed, 14 Jan 2009 08:45:32 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0EDjUvx021997 for asrg@irtf.org; Wed, 14 Jan 2009 08:45:30 -0500 Date: Wed, 14 Jan 2009 08:45:30 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114134530.GA32176@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231938032.32316.13.camel@tardis.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 14, 2009 at 01:00:32PM +0000, David Wilson wrote: > The error here is to assume that you get the message from the > originating system. There are scenarios in which you get the message > from an innocent (perhaps in more than one sense of the word) > *intermediate* MTA. It is the reaction of such an MTA to a rejection > which is the problem. That's not an assumption, it's a fact. If 1.2.3.4 connects to my MX's and attempts delivery, then 1.2.3.4 IS the originating system, as far as my MX is concerned. Now the message may -- or may not -- have *really* originated on 1.2.3.4, but that's of course quite impossible to know. (I trust everyone is aware that malware routinely adds fake headers, so anything it claims about itself, including its putative origin, shouldn't be believed. The only things you can know about it are things that you independently determine.) > An intermediate MTA is not be a open relay, because relaying is often > defined in terms of the system from which the message arrives. For > instance, a company has a "boundary" MTA. A PC within the company's > network is compromised (the user accessed an unsuitable web site in > their lunch break). The trojan sends messages via the boundary MTA. > Unless that MTA checks the return-path address, and the boundary MTA > picks up on the virus, then the rejection by the next hop MTA is a > problem. So we are to presume that malware which has taken over user U's PC, and thus is likely already in full control of everything it does, is going to send a copy of itself through the outbound MTA on that network, with the goal that it will be rejected by someone's MX, so that the MTA will generate an NDR and send it back to user U... who is already infected? What, exactly, is the point? Or that this same malware, having rummaged through user U's inbox and outbox and other files resident on the disk drives on U's PC, has now decided to attempt delivery to co-workers V, W, and X, and rather than just attaching itself to the next outbound messages from X to any of them, or crafting a plausible forgery and sending it now, will instead try to forge V/W/X's addresses as the putative sender, submit it to the outbound MTA, and hope that something rejects it so that the local MTA will send an NDR with it to V/W/X? We've wandered into fantasyland here. Why should such elaborate tricks be used when there are a large number of much easier, eminently successful tactics to try? After all, if the MTA doesn't know how to detect this particular bit of malware when it's headed to an external destination, then it seems unlikely it'll detect it when it's headed to an internal one. The simplest course is for it to just send itself directly -- or, even better, to infest the system running the MTA, which makes further propagation considerably simpler. > After all, if the "MTA" from which you received the infected message is > not innocent, perhaps not even a proper MTA, then rejecting the message > is also pointless. The rejection will be ignored, and so the overall > effect will be the same as if it were accepted and discarded. *If* it's not a proper MTA, yes. But you have no way to know that, nor can you be certain that you're not making a classification error, so best practice remains to use the SMTP protocol to indicate rejection. If it does turn out to be a proper MTA and/or if it does turn out you've made an error, you've given everyone a decent chance of noting it, tracking it, and fixing it. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 05:51:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506F53A6B63; Wed, 14 Jan 2009 05:51:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF833A6B63 for ; Wed, 14 Jan 2009 05:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7zvs+gxFmVpn for ; Wed, 14 Jan 2009 05:51:18 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id E5E7D3A6B62 for ; Wed, 14 Jan 2009 05:51:17 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0EDp28a020805 for ; Wed, 14 Jan 2009 08:51:02 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0EDgIUb010500 for ; Wed, 14 Jan 2009 08:42:18 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0EDovUT025952 for ; Wed, 14 Jan 2009 08:50:57 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0EDovEZ025951 for asrg@irtf.org; Wed, 14 Jan 2009 08:50:57 -0500 Date: Wed, 14 Jan 2009 08:50:57 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090114135057.GA22217@gsp.org> References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <1231925085.3253.23.camel@bravo.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231925085.3253.23.camel@bravo.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 14, 2009 at 09:24:45AM +0000, David Wilson wrote: > I would be interested to know what actual numbers for, or perhaps some > specific instances of, FP from anti-virus. As more and more AV packages are being (incorrectly, in my opinion) taught how to recognize phishes, I'm seeing more and more FP rejects of *discussions* of phishes. Like John, I've seen rejects based on partial virus-related content - in some cases, apparently based on string matches. But it is axiomatic that all anti-virus (and anti-spam) systems have nonzero FP and FN rates (with the exception of the edge cases "reject all" and "accept all"). Given that we know we will make these mistakes, we need to consider how we can make them visibly, so that we give ourselves and everyone else a reasonable chance of observing and correcting them. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 06:04:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D2428C119; Wed, 14 Jan 2009 06:04:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E0F28C119 for ; Wed, 14 Jan 2009 06:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DTyOxSGBpYLv for ; Wed, 14 Jan 2009 06:04:35 -0800 (PST) Received: from mx-p2.cc.nd.edu (mx-p2.cc.nd.edu [129.74.250.58]) by core3.amsl.com (Postfix) with ESMTP id 70D0B28B797 for ; Wed, 14 Jan 2009 06:04:35 -0800 (PST) Received: from osgood.cc.nd.edu (osgood.cc.nd.edu [129.74.250.227]) by mx-p2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0EE54SN030634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Jan 2009 09:05:04 -0500 Received: from [192.168.0.100] (173-24-16-9.client.mchsi.com [173.24.16.9]) (authenticated bits=0) by osgood.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id n0EE4CN8021653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 09:04:16 -0500 (EST) Message-ID: <496DF0DC.5020506@nd.edu> Date: Wed, 14 Jan 2009 09:04:12 -0500 From: Paul Russell Organization: University of Notre Dame User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> In-Reply-To: <1231923898.3253.8.camel@bravo.isode.net> X-Source-IP: 129.74.250.227 X-ND-MTA-Date: Wed, 14 Jan 2009 09:05:04 EST Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 1/14/2009 4:04 AM, David Wilson wrote: > On Tue, 2009-01-13 at 20:46 -0500, Rich Kulawiec wrote: >> On Tue, Jan 13, 2009 at 07:13:39PM -0600, Gordon Peterson wrote: >>> That's a bogus argument. You're basically saying that "someone else >>> will probably pick up on this" and using that as a (lame) excuse to lob >>> a grenade their way. >> Perhaps you should review the SMTP protocol: sending a 5XX response >> *refuses* delivery of a message. It does not transmit (or retransmit) >> a message. It is difficult to see how one can be accused of "lob[bing] >> a grenade" when one has never taken possession of it. > > Because of the normal action of an MTA when it receives such an 5XX > response, i.e. it sends a non-delivery message, normally containing the > message, to the return path address. If that return path address is > forged, then the infection is bounced elsewhere. That is the grenade. The grenade was not lobbed by the MTA which issued the 5xx response; it was lobbed by the MTA which previously accepted the message from some source and attempted to deliver it to the MTA which issued the 5xx response during the SMTP session. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 06:20:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794E228C159; Wed, 14 Jan 2009 06:20:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23DE28C159 for ; Wed, 14 Jan 2009 06:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] 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 opSVadSPpTNs for ; Wed, 14 Jan 2009 06:20:04 -0800 (PST) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id DAA9028C101 for ; Wed, 14 Jan 2009 06:20:03 -0800 (PST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id E832D34809 for ; Wed, 14 Jan 2009 09:19:48 -0500 (EST) Received: by panix5.panix.com (Postfix, from userid 756) id D5B3A241DC; Wed, 14 Jan 2009 09:19:48 -0500 (EST) From: Seth To: asrg@irtf.org In-reply-to: <496D7787.1080100@nortel.com> (clewis@nortel.com) References: <496D3892.9020705@terabites.com> <496D7787.1080100@nortel.com> Message-Id: <20090114141948.D5B3A241DC@panix5.panix.com> Date: Wed, 14 Jan 2009 09:19:48 -0500 (EST) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org "Chris Lewis" wrote: > Gordon Peterson wrote: >> First of all, ultimately the ONLY authority which TRULY determines FOR A >> FACT whether a given piece of e-mail is unwanted or not is the final >> recipient. > > You're being awfully absolute in that statement. Wanting is something that anybody can do. The only authority who can truly determine if the final recipient wants the mail is the final recipient. And that opinion is subjet to change over time, even for the same piece of mail. (User gets an ad to take a friend to a particular movie for free, does so, and the movie is so awful he wishes he hadn't received the ad.) The only authority who can determine whether I want the final recipient to receive the mail is me. The only authority who can determine whether the final recipient's employer wants the final recipient to recieve the mail is the final recipient's employer. Etc. > Certainly, if you're a, say, spam or virus researcher, you might > want to get your email flow raw. Fine. Just don't expect a > commodity ISP to accommodate you at commodity prices. They simply > can't afford the risk to their infrastructure. Some will; what's the risk to a BSD infrastructure of letting customers receive Windoze viruses? (Sure, they have to be careful about outgoing mail, but that's true anyway because there are plenty of non-email ways for lusers to become infected.) Seth _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 06:22:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA3A3A69D3; Wed, 14 Jan 2009 06:22:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC3A3A6880 for ; Wed, 14 Jan 2009 06:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 brU8587HMBTX for ; Wed, 14 Jan 2009 06:22:04 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id 63FF93A63EC for ; Wed, 14 Jan 2009 06:22:04 -0800 (PST) Received: from mta-1.cc.nd.edu (mta-1.cc.nd.edu [129.74.250.35]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0EEIuks025885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Jan 2009 09:18:56 -0500 Received: from [192.168.0.100] (173-24-16-9.client.mchsi.com [173.24.16.9]) (authenticated bits=0) by mta-1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0EELlFr016974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 09:21:48 -0500 (EST) Message-ID: <496DF4FB.2010304@nd.edu> Date: Wed, 14 Jan 2009 09:21:47 -0500 From: Paul Russell Organization: University of Notre Dame User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> In-Reply-To: <1231938032.32316.13.camel@tardis.isode.net> X-Source-IP: 129.74.250.35 X-ND-MTA-Date: Wed, 14 Jan 2009 09:18:57 EST Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 1/14/2009 8:00 AM, David Wilson wrote: > > After all, if the "MTA" from which you received the infected message is > not innocent, perhaps not even a proper MTA, then rejecting the message > is also pointless. The rejection will be ignored, and so the overall > effect will be the same as if it were accepted and discarded. If I understand your position correctly, you want the receiving MTA to issue a 5xx when the sender is a real mail server, but you want it to accept and discard the message when the sender is a bot. As has already been pointed out, for systems outside your control, you can only speculate as to their true nature and their likely reaction of a 5xx response. Why waste time trying to discern the true nature of the sender, and run the risk that you will discard messages which should have been rejected, because your analysis of the sender is imperfect? Just issue the 5xx and be done with it. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 07:45:57 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2C93A69C4; Wed, 14 Jan 2009 07:45:57 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A593A63CB for ; Wed, 14 Jan 2009 07:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aSYrTBrH6PCY for ; Wed, 14 Jan 2009 07:45:52 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 475993A69C4 for ; Wed, 14 Jan 2009 07:45:51 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 15:45:33 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <496DF4FB.2010304@nd.edu> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> Organization: Isode Limited Date: Wed, 14 Jan 2009 15:45:32 +0000 Message-Id: <1231947932.32316.126.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-14 at 09:21 -0500, Paul Russell wrote: > > After all, if the "MTA" from which you received the infected message > is > > not innocent, perhaps not even a proper MTA, then rejecting the > message > > is also pointless. The rejection will be ignored, and so the overall > > effect will be the same as if it were accepted and discarded. > > If I understand your position correctly, you want the receiving MTA to > issue a > 5xx when the sender is a real mail server, but you want it to accept > and discard > the message when the sender is a bot. As has already been pointed > out, for > systems outside your control, you can only speculate as to their true > nature and > their likely reaction of a 5xx response. Why waste time trying to > discern the > true nature of the sender, and run the risk that you will discard > messages which > should have been rejected, because your analysis of the sender is > imperfect? > Just issue the 5xx and be done with it. No, quite the reverse. If you have received an infected message from a real MTA, then issuing a 5xx response might "do bad things". I.e. that real MTA might send a DSN containing the infection to a forged returned path. What I said was that there was no point in sending a 5xx response to a bot, since they will ignore it. (I suppose they might remove the recipient address from their list, but I don't know if this actually happens.) So, I believe that sending 5xx to an innocent sender can be dangerous, and sending 5xx to a bot is pointless. The only problem with not sending 5xx (or not sending a DSN) could be with false positives. However, I believe this is a very small problem, at least for the majority of users, and the danger of using 5xx is significantly greater. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 07:54:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8903A6B66; Wed, 14 Jan 2009 07:54:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78AD3A6B66 for ; Wed, 14 Jan 2009 07:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 axxRJtMcn10i for ; Wed, 14 Jan 2009 07:54:37 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id B1D2A3A6B5E for ; Wed, 14 Jan 2009 07:54:36 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0EFsJE29931 for ; Wed, 14 Jan 2009 15:54:19 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 10:54:03 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 14 Jan 2009 10:54:03 -0500 Message-ID: <496E0A9A.4060403@nortel.com> Date: Wed, 14 Jan 2009 10:54:02 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3892.9020705@terabites.com> <496D7787.1080100@nortel.com> <200901140912.EAA12786@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200901140912.EAA12786@Sparkle.Rodents-Montreal.ORG> X-OriginalArrivalTime: 14 Jan 2009 15:54:03.0918 (UTC) FILETIME=[530EB2E0:01C97660] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org der Mouse wrote: >> Apropos my other posting: anything saying "HELO >> list.mediresource.com" (except possibly from 209.82.15.228, it's >> other SPF-permitted IP helos as tempmail.mediresource.com) is spam. > Um, no, not if it's not bulk. Want me to telnet to your MX host and > generate an example manually? :-) Except for mice in the works ;-) It may not be bulk, but forgery in the face of the domain owner asserting otherwise is still undesirable. >> Certainly, if you're a, say, spam or virus researcher, you might want >> to get your email flow raw. Fine. Just don't expect a commodity ISP >> to accommodate you at commodity prices. They simply can't afford the >> risk to their infrastructure. > Oh, nonsense. If that constitutes any risk to their infrastructure, > they *urgently* need to fix the bugs in question anyway! Oh, nonsense on your nonsense! ;-) Perhaps I should have said "network" instead of "infrastructure". But the fact remains that an infection on one recipient's machine has consequences far beyond _that_ machine alone. The components of an infrastructure do not need to be infected to be damaged by infections. Surely you remember slammer? A handful of infected desktops took out out entire networks without infecting anything further. Simply by bandwidth exhaustion. Then of course there's the potential reputation loss if something manages to spam outwards through your MTAs. Nor does choice of O/S barricade you more than quantitatively. As secure as *BSD (for example, for you Seth ;-), it's not immune to going awry, especially in the face of naive users poking at things they shouldn't be. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 08:01:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C57B3A68D6; Wed, 14 Jan 2009 08:01:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1CE3A68D6 for ; Wed, 14 Jan 2009 08:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] 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 g03bjSifGHn1 for ; Wed, 14 Jan 2009 08:00:59 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A55613A63CB for ; Wed, 14 Jan 2009 08:00:59 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id n0EG0WRh027278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 08:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1231948841; x=1232035241; bh=Xujo7+N7SVaHifEFh5fGUkd+s68VMbzoKws2oDG0BuU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=1f5HB61xTvHxI/uPzvlfd5U6duxuhKEYWGpqf38GDdJnTq7eohTj+LCDhx8Q7/owD 7bfkEg9yDdhV/HoIoufcjHIEa2/pzmflvZpBcT6/Nrzln2KYL8EhhwiDklYEyiLZux p7CmFqxpze7RIBafTXDLBafIfRmE7ip0fmEMVJtQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=dvLa5MCqLazHPclQ3PgK9VbHjcxCvSt4Hk5s4HJmV3jz2d5SQp0/e4T9nGBJU2Hsz P5jHq3YgthHJmx5IOOhoc/FvxevSwmLkDj5rCG5uE4oYMt1s1+tmZWjte8AOwFP1r2y 8CWjxE0/b7eeMup0zwsJ/JCrxSfEemnj0kQCakk= Message-Id: <6.2.5.6.2.20090114072600.031e4970@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Jan 2009 07:56:34 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <20090114120155.71225.qmail@simone.iecc.com> References: <1231925085.3253.23.camel@bravo.isode.net> <20090114120155.71225.qmail@simone.iecc.com> Mime-Version: 1.0 Subject: Re: [Asrg] virus detectors, was where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 04:01 14-01-2009, John Levine wrote: >When I catch a virus and the sending IP is one for whom I have a known >contact address, I send off an autoreport with the first 50 lines of >the virus (in case they're wondering what virus it is), and the first [snip] >Nonetheless, I have problems all the time with my reports being >rejected by poorly written virus filters. In one case they've been >adding me to a virus sending blacklist, telling me that even though >they know I'm not sending viruses, their AV detects it so it must be >my fault. Sheesh. You also get that kind of reply (if detectors says so, then it must be true) about spam. At 01:24 14-01-2009, David Wilson wrote: >I would be surprised if a non-malicious message would fall foul of AV >software unless it contained some kind of executable content. It should >not be surprising that a message with executable content runs into >problems. The usual document formats (PDFs, .doc, etc) are also scanned for viruses nowadays. They can fall foul of Anti-virus software. The report (see first paragraph above) would have helped in identifying problems if the postmaster actually cared about mail delivery. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 08:08:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3A73A6977; Wed, 14 Jan 2009 08:08:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487AD3A6878 for ; Wed, 14 Jan 2009 08:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EPkruV5K-Y1g for ; Wed, 14 Jan 2009 08:08:30 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A774528C129 for ; Wed, 14 Jan 2009 08:08:30 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0EG8CE02498 for ; Wed, 14 Jan 2009 16:08:13 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 11:07:42 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 14 Jan 2009 11:07:42 -0500 Message-ID: <496E0DCD.1040307@nortel.com> Date: Wed, 14 Jan 2009 11:07:41 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> In-Reply-To: <1231947932.32316.126.camel@tardis.isode.net> X-OriginalArrivalTime: 14 Jan 2009 16:07:42.0814 (UTC) FILETIME=[3B284FE0:01C97662] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org David Wilson wrote: > The only problem with not sending 5xx (or not sending a DSN) could be > with false positives. However, I believe this is a very small problem, > at least for the majority of users, and the danger of using 5xx is > significantly greater. Our experience, issuing 55x at levels of 250,000-1,300,000 per day since 1997 indicates exactly the reverse. Certainly, there's no way to prove that "it" (an infection) hasn't happened, but considering we've had precisely _one_ report of a 55x (for any reason whatsoever) landing in the forgee's mailbox in all that time, it can't be significant. In contrast to the dozen or so FPs per day that we do handle. Silently dropping emails would mean that those dozen or so FPs would go unnoticed by anyone. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 08:40:34 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971D628C1C6; Wed, 14 Jan 2009 08:40:34 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E54E28C1C6 for ; Wed, 14 Jan 2009 08:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] 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 cRTQnWWh90LJ for ; Wed, 14 Jan 2009 08:40:31 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id E747228C1BF for ; Wed, 14 Jan 2009 08:40:30 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id n0EGe5qp023691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 08:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1231951214; x=1232037614; bh=+Ih50KRUIYmnXxUpcn4mgf3tRBb32W5dqTkcIvimRbY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=l+adrMHDjAYQSVJDxYx544PoSlrj09WK/pvBFekaoivNIGWeBiMcd7SBlvMpJ5ge2 98hqnjHSBMegkDBxIiKEcW0Dc1tNapgUH1TPL61xgiOWHHFOxa7+oD7SImitcPDby4 1Isw1AoICUjjrCt4g2rt40lv9On9CU/rrTDoeBZE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=L7M/7FXXtdzaPP6klx/ThcYkqLO/KLEL/KidMwh7L+sbN/qCYXiffbN0i4ia2Rz3X 6D0x1vgTpfF4Jz+w4WaCMRPh3wfOEoONOIhSewpzSu4T1y3ApGMYsL/fHAap0eBfd15 5RbMhU3yTbe/d+Xv+Eu6K5HKgz770BpL0MMcl3I= Message-Id: <6.2.5.6.2.20090114075729.031e4828@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Jan 2009 08:39:41 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <20090114124240.GA26583@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 04:42 14-01-2009, Rich Kulawiec wrote: >And second, have you (rhetorical you) been paying attention to the >origination points of the vast majority of attempted malware deliveries >over the past decade? They're coming from places like this (seen within >the last hour here): > > 11.red-81-43-100.staticip.rima-tde.net [81.43.100.11] > 12-216-204-70.client.mchsi.com [12.216.204.70] > 122-82-124-91.pool.ukrtel.net [91.124.82.122] > 1809ds4-fb.0.fullrate.dk [90.184.161.72] > 78-0-202-32.adsl.net.t-com.hr [78.0.202.32] > 89-180-255-125.net.novis.pt [89.180.255.125] > cable-87-116-168-96.dynamic.sbb.rs [87.116.168.96] > cpe-69-133-71-112.columbus.res.rr.com [69.133.71.112] > ip-90-187-210-98.web.vodafone.de [90.187.210.98] > >Do you think any of those are actual mail servers? Do you think that >any of them actually are running an SMTP engine which does something >with rejected traffic? Do you think that any of them are running an SMTP >engine which even *notices* rejected traffic? A few of them may be actual mail servers. Not all of them may be listening for SMTP connections. A negligible number of them may do something about rejected traffic. Some people find it easier to block SMTP traffic from such origination points than to put in the resources to handle them. If we are looking for an identifier which says that "this IP address may originate SMTP traffic", then it's better to invent one than to rely on hostnames. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 09:04:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88813A6A08; Wed, 14 Jan 2009 09:04:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD173A69FB for ; Wed, 14 Jan 2009 09:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 cSSypcrmUYBi for ; Wed, 14 Jan 2009 09:04:45 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AC5F23A6A08 for ; Wed, 14 Jan 2009 09:04:45 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 17:04:30 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <6.2.5.6.2.20090114075729.031e4828@resistor.net> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <6.2.5.6.2.20090114075729.031e4828@resistor.net> Organization: Isode Limited Date: Wed, 14 Jan 2009 17:04:29 +0000 Message-Id: <1231952669.32316.136.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-14 at 08:39 -0800, SM wrote: > Some people find it easier to block SMTP traffic from such > origination points than to put in the resources to handle them. If > we are looking for an identifier which says that "this IP address may > originate SMTP traffic", then it's better to invent one than to rely > on hostnames. Some DNSBLs have categories which identify IP addresses which are not expected to originate SMTP traffic. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 09:12:43 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D185F3A6A15; Wed, 14 Jan 2009 09:12:43 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708E03A69B8 for ; Wed, 14 Jan 2009 09:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 kvKaVjM28p16 for ; Wed, 14 Jan 2009 09:12:42 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1D6A93A6A15 for ; Wed, 14 Jan 2009 09:12:41 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 14 Jan 2009 18:12:24 +0100 id 00000000005DC036.00000000496E1CF8.00000F49 Message-ID: <496E1CF7.3080701@tana.it> Date: Wed, 14 Jan 2009 18:12:23 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> In-Reply-To: <20090114013801.GA18217@gsp.org> Subject: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Can we draw any conclusions from that thread? Rich Kulawiec wrote: > On Tue, Jan 13, 2009 at 10:38:02PM +0000, David Wilson wrote: >> I'm not sure what you are saying should be done. If you reject from an >> SMTP MTA (not a submitting UA) using a 5xx response, what is that MTA >> going to do: generate some kind of non-delivery message. Normally, that >> includes the message which was non-delivered, which the rejecting MTA >> knows to be malicious. In order to prevent that, we need a status code >> which means "I am not receiving this message because it has a content >> which is dangerous". SMTP does not have such a status code. > > Yes, I know. (And while I recognize that having such a status code > might help solve some problems, it would also open others. 599 Bounce to postmaster. What would be wrong if it existed? (I mean, besides how hard it would be to reliably introduce it now.) > Among other things, "malicious" isn't universal. And anti-virus software > does not have a 0% FP rate.) I agree it cannot be 0%, but better than 0.000001% is expected. See e.g. http://www.sophos.com/support/knowledgebase/article/35504.html. It is also false that any executable content is likely to be reported as infected: the same AV software is used to scan hard disks, looking at executables only. (I'm not saying the same reliability cannot be reached for phishing or spam, though.) Chris Lewis wrote: > Our experience, issuing 55x at levels of 250,000-1,300,000 per day since > 1997 indicates exactly the reverse. [...] Silently dropping emails would > mean that those dozen or so FPs would go unnoticed by anyone. A dozen at those levels is more than 0.001%. It seems very poor. What AV/config do you use? Perhaps, at that percentage I would do the same. The reliability I experience reliefs me when I violate the SMTP protocol by dropping messages. Since I have to err, I try and minimize damages. Curiously, some viruses (e.g. Netsky) directly produce a bounce. Possibly, their authors reasoned that since there are brain damaged MUAs that conceal the body of DSNs but not the attachments, an attachment in a DSN has better probabilities of being opened. As a matter of fact, some virus variants have been surviving autonomously for years, which suggests that that reasoning was correct. Bounce addresses are extremely likely to be spoofed. Sending disinfected bounces is hardly an option. At any rate, even when it is not spoofed, the author of a message is not always the right recipient for a technical report. Besides malware, SPF or DKIM rejections are difficult to understand and impossible to fix for end users. MTAs strive to only produce bounces for messages that they have accepted for relay from their legitimate users. However, in some cases that's not possible. Forwarding comes to mind. Also, rfc5321 mandates no AV filter, thus the much exemplified virus-relaying MTA is perfectly legal. Why don't we have a meta channel for those cases? Some bounces should be sent to postmasters, who can then send more meaningful DSNs, possibly after seeking the relevant message-ID in their logs, and fix the problem. I don't think sending to would make much sense, there ought to be a better mechanism... _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 10:00:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5E83A6A72; Wed, 14 Jan 2009 10:00:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633A63A6A55 for ; Wed, 14 Jan 2009 10:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 yHC0Dn3qpjRk for ; Wed, 14 Jan 2009 10:00:25 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7307D3A6A33 for ; Wed, 14 Jan 2009 10:00:24 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 14 Jan 2009 18:00:08 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <496E0DCD.1040307@nortel.com> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> Organization: Isode Limited Date: Wed, 14 Jan 2009 18:00:07 +0000 Message-Id: <1231956007.32316.175.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-14 at 11:07 -0500, Chris Lewis wrote: > . > > Our experience, issuing 55x at levels of 250,000-1,300,000 per day since > 1997 indicates exactly the reverse. > > Certainly, there's no way to prove that "it" (an infection) hasn't > happened, but considering we've had precisely _one_ report of a 55x (for > any reason whatsoever) landing in the forgee's mailbox in all that time, > it can't be significant. In contrast to the dozen or so FPs per day > that we do handle. Silently dropping emails would mean that those dozen > or so FPs would go unnoticed by anyone. Interesting. At least there are some numbers here. Just to check, are these 250K-1300K 5xx response *just* for messages which have fallen foul of Anti-Virus checks (i.e. the number does not include 5xx responses for other causes like invalid recipients). As Alessandro Vesely has commented, this does seem a high AV FP rate. How do you find out about the FP (since the message is, by definition, rejected)? Obviously, if the sender simply resends, it would be rejected again. So, there must be some other mechanism you have for finding out that this particular message was not actually infected. What kinds of message typically generate FPs? What AV signatures are being hit by these FPs? How do you verify that the message is not actually a problem? Maybe we are lucky, but we do not see many messages which appear to be infected - perhaps only 0.6% of the overall traffic. Nearly 90% of received messages appear to be spam. Do you get a significantly higher proportion of (purported) infected messages? Although the number of reported infections from rejected messages is just one, maybe this is not surprising. Firstly, there are clearly "out there" a very large number of machines which are infected and the owner either does not know or does not care. So, if any of these have been infected as a result of one of your rejections, you would not know. Even if the owner finds out their machine is infected, I would think it is rare for them to try to trace the origin of the infection. The work involved in getting their machine clean is probably enough for them. It might involve re-installing the OS, which would probably wipe the evidence. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 10:45:26 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7A728C1C0; Wed, 14 Jan 2009 10:45:26 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE0328C1C0 for ; Wed, 14 Jan 2009 10:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 kxgCHSmklOLb for ; Wed, 14 Jan 2009 10:45:24 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 535E328C1BB for ; Wed, 14 Jan 2009 10:45:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 03D5B64F8383 for ; Thu, 15 Jan 2009 06:45:11 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCxNGfaJmE1i for ; Thu, 15 Jan 2009 06:45:06 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 6412C64F8350 for ; Thu, 15 Jan 2009 06:45:06 +1200 (FJT) Date: Thu, 15 Jan 2009 06:45:06 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <8386639.121231958691337.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <6.2.5.6.2.20090114072600.031e4970@resistor.net> MIME-Version: 1.0 X-Originating-IP: [113.20.66.166] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] virus detectors, was where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I block a number of file extensions (all of which could contain a payload). I'd like to block doc attachments but they are a bt everywhere. I advice people to send as pdf (internally we usually don't do much than print/or read external documents) or to rename the extension. At least there is a not straight forward process, whihc gives an extra 5picosecond for people to think if it is a virus or not. ----- Original Message ----- From: "SM" To: "Anti-Spam Research Group - IRTF" Sent: Thursday, 15 January, 2009 3:56:34 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] virus detectors, was where the message originated At 04:01 14-01-2009, John Levine wrote: >When I catch a virus and the sending IP is one for whom I have a known >contact address, I send off an autoreport with the first 50 lines of >the virus (in case they're wondering what virus it is), and the first [snip] >Nonetheless, I have problems all the time with my reports being >rejected by poorly written virus filters. In one case they've been >adding me to a virus sending blacklist, telling me that even though >they know I'm not sending viruses, their AV detects it so it must be >my fault. Sheesh. You also get that kind of reply (if detectors says so, then it must be true) about spam. At 01:24 14-01-2009, David Wilson wrote: >I would be surprised if a non-malicious message would fall foul of AV >software unless it contained some kind of executable content. It should >not be surprising that a message with executable content runs into >problems. The usual document formats (PDFs, .doc, etc) are also scanned for viruses nowadays. They can fall foul of Anti-virus software. The report (see first paragraph above) would have helped in identifying problems if the postmaster actually cared about mail delivery. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 10:58:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F3D3A69A9; Wed, 14 Jan 2009 10:58:59 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420183A69A9 for ; Wed, 14 Jan 2009 10:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UBBAB5J7PWzv for ; Wed, 14 Jan 2009 10:58:57 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E5F783A6A15 for ; Wed, 14 Jan 2009 10:58:56 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0EIsqU00867 for ; Wed, 14 Jan 2009 18:54:52 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 13:58:37 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 14 Jan 2009 13:58:37 -0500 Message-ID: <496E35DC.7010906@nortel.com> Date: Wed, 14 Jan 2009 13:58:36 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> <1231956007.32316.175.camel@tardis.isode.net> In-Reply-To: <1231956007.32316.175.camel@tardis.isode.net> X-OriginalArrivalTime: 14 Jan 2009 18:58:37.0930 (UTC) FILETIME=[1BAED4A0:01C9767A] Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org David Wilson wrote: > On Wed, 2009-01-14 at 11:07 -0500, Chris Lewis wrote: >> . >> >> Our experience, issuing 55x at levels of 250,000-1,300,000 per day since >> 1997 indicates exactly the reverse. >> >> Certainly, there's no way to prove that "it" (an infection) hasn't >> happened, but considering we've had precisely _one_ report of a 55x (for >> any reason whatsoever) landing in the forgee's mailbox in all that time, >> it can't be significant. In contrast to the dozen or so FPs per day >> that we do handle. Silently dropping emails would mean that those dozen >> or so FPs would go unnoticed by anyone. > > Interesting. At least there are some numbers here. > > Just to check, are these 250K-1300K 5xx response *just* for messages > which have fallen foul of Anti-Virus checks (i.e. the number does not > include 5xx responses for other causes like invalid recipients). It's all filter hits, including spam, but not invalid recipients (we don't, but should, count these at present - at least in production. On the traps invalid recipient is 20-30M/day by definition ;-). That said: 1) That 1.3M/day was virus rejects - the Mydoom explosion in Feb 2006 (IIR the year correctly). The total rejects for those days was actually 1.6M/day (I rechecked the numbers - was remembering Mydoom's numbers alone for the total). 2) The FN rate of AV tools these days is atrociously bad. Studies have shown that "new" viruses (in this context meaning different MD5 checksums, meaning the same old virus just packed differently) is missed by 90% of all AV packages, and that only rises to 50% after a month. In fact, some AV vendors are not bothering to update MD5 databases for certain viruses, because they're different for every copy. That's not supposition, at least one vendor explicitly said so. In person ;-) I can't tell you how many times I've submitted a cutwail binary to virustotal and found that not one of virustotal's battery of detectors (commercial AV products) fired on it. Despite cutwail being (a) the 2nd or 3rd most prolific malcious email sender (peaked at over 20% of all malicious email), and (b) out there for better than a year. As a consequence of (2), any non-trivial environment who relies purely on AV products (even multi-layer such as us, with email and web and generalized) for virus protection is going to get hosed. They have to add in different approaches, such as DNSBL, SURBL, custom patterning and executable detection. With _both_ a higher FP rate, and the inability to tell whether it's a virus or not. You can't choose to "bounce (or reject) spam and not viruses" because the filter is unable to make the distinction. We used to publish "virus rejects" - we don't anymore, because we can't distinguish them. We have an internal formal AV engine in email. But we don't rely on it for the heavy lifting of the majority of malicious attacks. The front ends use anti-spam techniques, and catch better than 99% of it before the AV sees (and probably misses) it. > As Alessandro Vesely has commented, this does seem a high AV FP rate. The dozen or two FPs is are all a result of rejects, regardless of actual rule (virus, spam or otherwise) > How do you find out about the FP (since the message is, by definition, > rejected)? Obviously, if the sender simply resends, it would be rejected > again. So, there must be some other mechanism you have for finding out > that this particular message was not actually infected.\ The rejection message (see previously in this thread for a real example) states very clearly what the sender should do. Email the FP handler. Which is my responsibility. So I see them all. > What kinds of message typically generate FPs? What AV signatures are > being hit by these FPs? How do you verify that the message is not > actually a problem? Executables that aren't viruses. Ordinary email coming from infected machines, or in amongst large numbers of badly infested machines. Very badly configured machines. Etc. We treat the FP process as simply part of filtering. If you get a reject, report it, and we'll fix. No email lost. Merely delayed. > Maybe we are lucky, but we do not see many messages which appear to be > infected - perhaps only 0.6% of the overall traffic. Nearly 90% of > received messages appear to be spam. Do you get a significantly higher > proportion of (purported) infected messages? I think you have an overly narrow definition of viruses - specifically, emails that carry malicious executables _directly_. The trap demonstrates that, at times, you'll see up to 50% of its entire flow is viral in the sense of, for example, links to malicious files. Most AV products probably didn't fire on the MSNBC/CNN viral attack. Yet, at one point a few months ago, that alone was 25% of all trap traffic. That was concurrent with several other bot families expending a considerable fraction of their output trying to propagate instead of sending spam. > Although the number of reported infections from rejected messages is > just one, maybe this is not surprising. Firstly, there are clearly "out > there" a very large number of machines which are infected and the owner > either does not know or does not care. So, if any of these have been > infected as a result of one of your rejections, you would not know. We'd get reports of us being responsible for sending a virus if _only_ from us being mentioned in the rejection notice buried in the email. Given the sheer volume of people who can't read headers well enough to identify obviously forged received lines and report the spam to us because it has a 47/8 address in it, we'd get at least _some_ reports of us (apparently) bouncing viruses at one point in the past 11 years. We NEVER have. The only rejection notice of this type we've ever had drawn to our attention is when an infected ISP customer sent us a spam forged in another customer of that same ISP, and our rejection caused the ISP to send the reject back to the forgee. Only once in 11 years. At our volumes, even if off by several orders of magnitude, the risk of reject-induced-bounce-of-virus is insignificant. Even more insignificant when you factor in the cost of missing business email because you blackholed it because of a filter FP. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 14 11:18:57 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4283A6A33; Wed, 14 Jan 2009 11:18:57 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF013A6A55 for ; Wed, 14 Jan 2009 11:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599] 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 DhuTFpkhuSlz for ; Wed, 14 Jan 2009 11:18:55 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 1D5673A6A13 for ; Wed, 14 Jan 2009 11:18:54 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id n0EJITld010471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 11:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1231960717; x=1232047117; bh=0Xzg8RR6jEsGeJu0rluhAE6JxQJvLuAa0uXU9ublWHk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=xpOrfiZKbbFvW3Nq6XYrDkhPGvRr8Qbx7JKrqQ/9F/MkwdySnEl6JeCdkamgFHymt OB/R9Fv7cctG+OVHjx56dakdAijQ3A09AXHRmBaTtGjT4KPSUNyrruhiw+8OSfLIkN S6/od/Gcg91n8CNLePysU1ueoowkskEh6w0UQjWU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=PTCMKODU2u16hsEB+baJJGX/7vLjd9zIV2I1luotCEr1+X1ikV8P9quMl/goriD5v UYvJ2W2KhLIeugq85scqnkTwqxYIr9ZWOEZiGTVh0ysW2RchhiQLB9rEveujZpnsvS5 pQaU8oyAbYGp0ISggud3dgmcuCvaKx4RxM0Y9d8= Message-Id: <6.2.5.6.2.20090114100939.02eef3f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Jan 2009 11:17:30 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <1231952669.32316.136.camel@tardis.isode.net> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <6.2.5.6.2.20090114075729.031e4828@resistor.net> <1231952669.32316.136.camel@tardis.isode.net> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 09:04 14-01-2009, David Wilson wrote: >Some DNSBLs have categories which identify IP addresses which are not >expected to originate SMTP traffic. That cannot be standardized. The usual suspects are already aware of the arguments that have been brought up in this thread as they have heard them before. Even though my question about where the message originated wasn't about the techniques used to validate the origin, I'll summarize them: SPF and SenderID - IP address evaluation (for the long answer, see relevant specifications) DomainKeys and DKIM - Domain-based evaluation DNSBL - IP address evaluation (usually proprietary) Hostnames - Reverse DNS evaluation (heuristics) Whitelisting - Determined by operational considerations These techniques are about how to restrict who can talk to us. At another level, we can frame the question as what content is safe and relevant to us. None of the techniques listed above address that. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 06:58:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BB528C23F; Thu, 15 Jan 2009 06:58:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DC628C216 for ; Thu, 15 Jan 2009 06:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WkwdaekaRJc3 for ; Thu, 15 Jan 2009 06:58:19 -0800 (PST) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 7F3A03A69C7 for ; Thu, 15 Jan 2009 06:58:18 -0800 (PST) Received: from ianeiloart.plus.com ([212.159.124.126]:40549 helo=[192.168.1.12]) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDIPOW-000AAT-0G for asrg@irtf.org; Thu, 15 Jan 2009 15:00:32 +0000 Date: Thu, 15 Jan 2009 14:57:59 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <6E93F2D47C53A44AE5C2BBE9@paine.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 12:58:28 -0500 der Mouse wrote: >> However, I do think that it's time that domain owners started taking >> responsibility for the use of their domains. > > If I, say, were to forge mail from your domain to, say, some ibm.com > user, would you take responsibility for it? That's what you seem to me > to be saying. Not quite, but not far off. I'm not taking responsibility for your decision to forge the domain. However, I AM responsible for the fact that IBM have no easy way to detect that forgery. I SHOULD accept that IBM are therefore more likely to bounce that email back to me. When a spammer forges my domain, and the recipient bounces the message, they're doing what SMTP is designed to do. I shouldn't get pissed off with the recipient, if I've failed to publish records that allow them to check for forgeries. What I should take responsibility for is publishing records that let IBM easily check whether the email is legitimate. For example, if I publish SPF records, and sign all my outgoing mail with DKIM, and require my users to use my Message Submission Service, then I think I've discharged that responsibility. Having taken those actions (actually, I haven't but this is hypthetical), I'm quite happy to accept any bounce messages from IBM - provided they've checked for an SPF or DKIM record match before accepting the message. Now, given that I haven't yet published SPF or DKIM records, I still get lots of spam bounced into my domain. Who do I blame? Well, in part it's my responsibility for failing to help the spam recipients. If I did publish those records, then recipient domains could more easily detect forgeries out of my domain. SPF records would be useful because you can check them early, and cheaply. DKIM give senders the opportunity to get messages through forwarders. Now, what I'm suggesting (not advocating yet, because I'm not certain that this is right), is that when there's no SPF record published, that we should not feel too bad about bouncing email because the domain administrator isn't taking adequate steps to protect the domain against spam blowback, and against phishing. Of course, I'm NOT suggesting that lack of an SPF record should score very high in any any spamicity measure, but it might count for something. Now, an SPF or DKIM match gives us the huge gain that we can bounce messages selectively based on the content. Some recipients may not want certain message content, but by the time we've seen the content SMTP doesn't allow us to selectively reject. And, a pass allows us to confidently whitelist a domain or sender address without opening up a huge hole in our spam defences. For example, I've refused to whitelist UK academic research boards because they don't publish SPF records. Now, the question is, what do we do when we see an SPF softfail, and no DKIM record? Well, at first I'd be reluctant to bounce the message, because I want to reward admins that are taking steps to protect their domains. However, that's not something that I'd be happy with on a permanent basis. Eventually, I want the world to be in a position where all forwarders check SPF on the way in, and rewrite sender domains. When we're sufficiently advanced in that project, then bouncing softfail would be more acceptable. No SPF record: SPF fail: reject the message at SMTP time. SPF softfail: check DKIM SPF pass: accept if you trust the domain, otherwise do other spam checks. You can reject, bounce or accept depending on other spam checks. Importantly, you can bounce PER RECIPIENT depending on the content, which you can't do with SMTP rejections. > >> In a world where you *can* prevent abuse of your domain, what's wrong >> with bouncing email? > > Depends on what that prevention requires. ("Sure you can prevent abuse > of your domain. You just need to enter into a bilateral agreement with > every receiving mailhost on the net.") No, you just need to sign your outgoing email, and publish SPF records. I know, someone's going to tell me that SPF breaks forwarding. Well email is already broken. I get up to a million spam messages into my domain daily. Everything we do to prevent spam causes problems ranging from additional load on our DNS servers to loss of important emails. The question is, are we going to fix it? I think what I'm proposing would at least allow people to do safe whitelisting -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 07:35:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA0C28C22F; Thu, 15 Jan 2009 07:35:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B977328C22F for ; Thu, 15 Jan 2009 07:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6YyxEqevhp7p for ; Thu, 15 Jan 2009 07:35:11 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id C875728C203 for ; Thu, 15 Jan 2009 07:35:10 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FFYswK013245 for ; Thu, 15 Jan 2009 10:34:55 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FFQ6PP013023 for ; Thu, 15 Jan 2009 10:26:06 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FFYlvp023858 for ; Thu, 15 Jan 2009 10:34:47 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FFYlAp023849 for asrg@irtf.org; Thu, 15 Jan 2009 10:34:47 -0500 Date: Thu, 15 Jan 2009 10:34:47 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115153447.GA13843@gsp.org> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1231947932.32316.126.camel@tardis.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 14, 2009 at 03:45:32PM +0000, David Wilson wrote: > So, I believe that sending 5xx to an innocent sender can be dangerous, > and sending 5xx to a bot is pointless. But you have no way to tell which is which. For example: putatively-"real" mail servers get botted as well. How should we then treat them? And from time to time, a system will turn up that looks much like a bot -- generic rDNS, fingerprints as Windows, etc. -- but turns out to be a real mail server. Note as well that 5XX responses do not go to senders: they go to connecting SMTP clients. There's no way to know whether or not those clients will in turn deliver anything to the putative sender. (Nor is there any way to know, in the cases where they *do* deliver something, and in the subset of those cases where this delivery includes putatively-malignant content, whether or not it's something that's already long since been delivered to the user by something else.) > The only problem with not sending 5xx (or not sending a DSN) could be > with false positives. However, I believe this is a very small problem, > at least for the majority of users, and the danger of using 5xx is > significantly greater. Just the opposite is true here. Malware is a trifling concern (thanks to the usage of superior operating systems and mail clients, along with abundant paranoia), but false positives are an intermittent, and annoying, problem. So while I don't doubt that your perspective applies to your operation, it doesn't apply here: what to some people is a crafty, dangerous virus that represents an immediate threat is to us merely a curious collection of bits. The broader point is that I see no reason why we should change the SMTP protocol in order to accomodate the thriving malware ecosystem made possible in large measure by the abysmally low quality of Microsoft products. That's akin to putting duct tape over a brightly-flashing red light because we don't want to know there's a problem. I think a much better approach is to attack the problem at its source, or, failing that, to at least contain the problem at our network perimeters using the tools we already have. (And as to my [rhetorical my, mostly] supposed responsibility to others, I've spent decades discharging that obligation not just by making it my highest priority to prevent outbound abuse from anything I touch, whether /32 or /8, but by freely giving my best professional advice in re the selection of operating systems and applications. I can hardly be held at fault by those who have failed to heed that advice and are now dealing with the very predictable consequences. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 07:45:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49403A69C7; Thu, 15 Jan 2009 07:45:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B95E3A69C7 for ; Thu, 15 Jan 2009 07:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 E6JAYuQHqT28 for ; Thu, 15 Jan 2009 07:45:47 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 0E55C3A68DA for ; Thu, 15 Jan 2009 07:45:46 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FFjVZu007330 for ; Thu, 15 Jan 2009 10:45:31 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FFagrL005862 for ; Thu, 15 Jan 2009 10:36:43 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FFjPml032681 for ; Thu, 15 Jan 2009 10:45:25 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FFjPmn032676 for asrg@irtf.org; Thu, 15 Jan 2009 10:45:25 -0500 Date: Thu, 15 Jan 2009 10:45:25 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115154525.GB13843@gsp.org> References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496E1CF7.3080701@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 14, 2009 at 06:12:23PM +0100, Alessandro Vesely wrote: > 599 Bounce to postmaster. What would be wrong if it existed? (I mean, > besides how hard it would be to reliably introduce it now.) I think -- even if there was widespread concurrence that it's a great idea -- "years" would be the timeline. And I'm not sure it's advisable or even worth it. Let me explain: I tend to loosely group mail system operators into two ad hoc categories: the first read "postmaster" mail, examine their inbound/outbound logs, run statistics on them, note anomalies, investigate them, and are pretty much invisible to me because their system are rarely, if ever, a problem. The second don't have a working "postmaster" address, pay no attention to their logs, complain vociferously when [correct] allegations of problems are made, and as a consequence, are a major irritant. Those in the first group are likely to know before you need to tell them. They'll note an unusually high number of 5XX responses to outbound traffic, investigate, and figure it out. Those in the second group will ignore you (most likely) or deny the facts, or accuse you of some malicious act, or something less pleasant. So there's little need to tell the first and little point in telling the second. >> Among other things, "malicious" isn't universal. And anti-virus software >> does not have a 0% FP rate.) > > I agree it cannot be 0%, but better than 0.000001% is expected. I think that's hopelessly optimistic in real-world settings. I routinely see a handful of FP's every month -- then again, I tend to send out mail talking about spam and phishes and so on, which most people don't. Also see Chris's excellent explanation, which I think is roughly typical of that at many large sites (it's certainly similar to the large sites I've worked on). Besides: AV vendors issue incorrect signatures, people misconfigure their mailers (I've seen multiple instances of reversed tests), networks fail, routers hiccup, DNS botches, and so on. There are so many things that go wrong that our only chance at diagnosis and repair relies on appropriate error messages. > Why don't we have a meta channel for those cases? Some bounces should be > sent to postmasters, who can then send more meaningful DSNs, possibly > after seeking the relevant message-ID in their logs, and fix the problem. Bounces are a bad idea because they add still more SMTP traffic, they can easily be abused to conduct DDoS attacks, and because of the situation outlined above. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 08:13:41 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C170D3A6A0B; Thu, 15 Jan 2009 08:13:41 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CB53A6969 for ; Thu, 15 Jan 2009 08:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0M+DHR5q0SG3 for ; Thu, 15 Jan 2009 08:13:37 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D98C728C13A for ; Thu, 15 Jan 2009 08:13:36 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 15 Jan 2009 16:13:20 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <6E93F2D47C53A44AE5C2BBE9@paine.local> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> Organization: Isode Limited Date: Thu, 15 Jan 2009 16:13:20 +0000 Message-Id: <1232036000.32316.296.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, 2009-01-15 at 14:57 +0000, Ian Eiloart wrote: > > Depends on what that prevention requires. ("Sure you can prevent > abuse > > of your domain. You just need to enter into a bilateral agreement > with > > every receiving mailhost on the net.") > > No, you just need to sign your outgoing email, and publish SPF > records. And make sure that you send from hosts which are permitted by your SPF info. At one point I purchased on-line from Maplin, so they send me marketing messages. maplin.co.uk has SPF information, but these messages are not sent from one of the permitted hosts! I have also seen an SPF failure on a message from a friend who has a 'vanity' domain for their family. The message came via their ISP's MTA, and so failed as this is not permitted by their SPF info. In this case the SPF info has probably been created by the domain registration organization. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 08:17:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9056E28C252; Thu, 15 Jan 2009 08:17:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590CA3A6A0A for ; Thu, 15 Jan 2009 08:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LGGyf151hAe9 for ; Thu, 15 Jan 2009 08:17:43 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 5FB5028C260 for ; Thu, 15 Jan 2009 08:17:41 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FGHPOW016605 for ; Thu, 15 Jan 2009 11:17:26 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FG8bFc014244 for ; Thu, 15 Jan 2009 11:08:38 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FGHKvl029987 for ; Thu, 15 Jan 2009 11:17:20 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FGHGLL029978 for asrg@irtf.org; Thu, 15 Jan 2009 11:17:16 -0500 Date: Thu, 15 Jan 2009 11:17:16 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115161716.GA21077@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6E93F2D47C53A44AE5C2BBE9@paine.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 02:57:59PM +0000, Ian Eiloart wrote: > Now, given that I haven't yet published SPF or DKIM records, I still get > lots of spam bounced into my domain. Who do I blame? Oh, that's easy. You blame the people running badly-broken mail systems that bounce instead of rejecting. Their IP addresses are contained in your logs and in the headers of the backscatter you're getting. Fixing this problem is a straightforward exercise modulo a few edge cases -- but the practical impact of those edge cases can be minimized by judicious use of simple tools and procedures (e.g., cron, make, rsync). (Example: one of the common problems of this type comes up in multi-tier mail systems lacking LDAP or another directory service. The problem arises when an address becomes invalid on the internal system but is still considered valid on the external MXs. One easy solution to this is to use a script to grab the current-list-of-valid-addresses from the internal system at intervals, process it, and then rsync it out to the external MX's. This reduces possible backscatter due to this problem to "the set of recently-removed addresses" and further to "the subset of those receiving forged-sender mail during the interval between updates". It's thus possible to reduce the probability of backscatter arbitrarily by reducing the interval.) ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 08:37:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111933A6969; Thu, 15 Jan 2009 08:37:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4E53A6969 for ; Thu, 15 Jan 2009 08:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 dRKQb4KHNvk4 for ; Thu, 15 Jan 2009 08:37:45 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B28A93A67D6 for ; Thu, 15 Jan 2009 08:37:44 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 15 Jan 2009 16:37:29 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090115154525.GB13843@gsp.org> References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> Organization: Isode Limited Date: Thu, 15 Jan 2009 16:37:28 +0000 Message-Id: <1232037448.32316.305.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, 2009-01-15 at 10:45 -0500, Rich Kulawiec wrote: > Bounces are a bad idea because they add still more SMTP traffic, they > can easily be abused to conduct DDoS attacks, and because of the > situation outlined above. > Something on which we are agreed! However, what I have been saying is that rejecting using 5xx will generate a bounce if the reject is sent as a response to an intermediate MTA. If the message is very likely to be dangerous, rather than just inconvenient, any bounce containing the message is itself dangerous. No doubt, most such dangerous messages come directly from some compromised PC, and a 5xx response will not give a bounce. But there will be some proportion which come via an intermediate MTA, which will. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 08:57:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EE328C268; Thu, 15 Jan 2009 08:57:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96E128C254 for ; Thu, 15 Jan 2009 08:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 DTcdYxfcCoQX for ; Thu, 15 Jan 2009 08:57:08 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6922728C258 for ; Thu, 15 Jan 2009 08:57:06 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 15 Jan 2009 16:56:50 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090115154525.GB13843@gsp.org> References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> Organization: Isode Limited Date: Thu, 15 Jan 2009 16:56:50 +0000 Message-Id: <1232038610.32316.324.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, 2009-01-15 at 10:45 -0500, Rich Kulawiec wrote: > >> Among other things, "malicious" isn't universal. And anti-virus > software > >> does not have a 0% FP rate.) > > > > I agree it cannot be 0%, but better than 0.000001% is expected. > > I think that's hopelessly optimistic in real-world settings. I > routinely > see a handful of FP's every month -- then again, I tend to send out > mail > talking about spam and phishes and so on, which most people don't. > Also see Chris's excellent explanation, which I think is roughly > typical of that at many large sites (it's certainly similar to the > large sites I've worked on). If I read Chris' message, then I believe that he is not giving evidence for AV false positives. He does not trust AV software, so the rejects quoted are for *all* filtering (presumably various kinds of anti-spam, as well as AV scanning) and the false positives quoted are for reports he gets back from rejects (many of which I suspect are seen by the user in a bounce generated from the MTA which received the reject). So there is actually no data here on specifically AV false positives, they are data on false positives from the overall filtering system. If someone discusses the nature of spam messages or phishing messages via email, I would think that false positives are not surprising; annoying, but not surprising. After all, one can be sending a message containing precisely the kind of thing filters are attempting to detect. So, I would say that there is a class of positives which should not count against the detection mechanism. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 09:12:25 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD2B28C25A; Thu, 15 Jan 2009 09:12:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C536F28C25A for ; Thu, 15 Jan 2009 09:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aF0uqXsZPGnt for ; Thu, 15 Jan 2009 09:12:23 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D8BB828C258 for ; Thu, 15 Jan 2009 09:12:22 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 15 Jan 2009 17:12:04 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <496E35DC.7010906@nortel.com> References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> <1231956007.32316.175.camel@tardis.isode.net> <496E35DC.7010906@nortel.com> Organization: Isode Limited Date: Thu, 15 Jan 2009 17:12:04 +0000 Message-Id: <1232039524.32316.338.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-14 at 13:58 -0500, Chris Lewis wrote: > I think you have an overly narrow definition of viruses - > specifically, > emails that carry malicious executables _directly_. The trap > demonstrates that, at times, you'll see up to 50% of its entire flow > is > viral in the sense of, for example, links to malicious files. > What I am talking about is messages for which the content is reported by AV software as being infected. The probability that such a message is not harmful is likely to be very, very small. A system should behave responsibly with such a message, and not risk sending it in a bounce message anywhere. Rejecting it might result in the generation of such a bounce, if you have received the message from an intermediate MTA. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 10:38:39 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E133B3A6842; Thu, 15 Jan 2009 10:38:39 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E913A6842 for ; Thu, 15 Jan 2009 10:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 AgZtBkenXNuc for ; Thu, 15 Jan 2009 10:38:37 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1C3F63A6774 for ; Thu, 15 Jan 2009 10:38:36 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 15 Jan 2009 19:38:18 +0100 id 00000000005DC031.00000000496F829A.000017FC Message-ID: <496F8299.9060506@tana.it> Date: Thu, 15 Jan 2009 19:38:17 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> In-Reply-To: <20090115154525.GB13843@gsp.org> Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > On Wed, Jan 14, 2009 at 06:12:23PM +0100, Alessandro Vesely wrote: >> 599 Bounce to postmaster. What would be wrong if it existed? (I mean, >> besides how hard it would be to reliably introduce it now.) > > I think -- even if there was widespread concurrence that it's a great > idea -- "years" would be the timeline. Yup, that's why I said "if it already existed". > And I'm not sure it's advisable or even worth it. Let me explain: > > I tend to loosely group mail system operators into two ad hoc categories: > [attentive vs. lame postmasters dissection dissertation] > So there's little need to tell the first and little point in telling > the second. Yet, attentive postmasters are not omniscient. They need a data feed. >> I agree it cannot be 0%, but better than 0.000001% is expected. > > I think that's hopelessly optimistic in real-world settings. Not for an AV filter. People routinely scan their hard disks with AV; perhaps they miss some viruses, but no legitimate software is quarantined. Obviously bugs exist, and FPs are a particular kind of bug for an AV package. I never saw one, but each AV vendor should have a list of open issues, and possibly also of the closed historical records. SMTP implementation also have bugs. However, when discussing the protocol we take it for granted that they can be fixed. > Also see Chris's excellent explanation, which I think is roughly > typical of that at many large sites (it's certainly similar to the > large sites I've worked on). Chris said their filter is not able to distinguish viruses from generic malware. Otherwise, for viruses they could issue a "599 Don't bounce this dangerous content to the user" after data transfer, if that code existed... > Besides: AV vendors issue incorrect signatures, people misconfigure > their mailers (I've seen multiple instances of reversed tests), networks > fail, routers hiccup, DNS botches, and so on. There are so many things > that go wrong that our only chance at diagnosis and repair relies on > appropriate error messages. Having an appropriate error message is not enough. It is also necessary to deliver that message to the right operator. Delivering error messages to end users may be counter productive. For a non-viral example, what can users do if their mail is bounced because of bad DKIM signatures? >> Why don't we have a meta channel for those cases? Some bounces should be >> sent to postmasters, who can then send more meaningful DSNs, possibly >> after seeking the relevant message-ID in their logs, and fix the problem. > > Bounces are a bad idea because they add still more SMTP traffic, they > can easily be abused to conduct DDoS attacks, and because of the > situation outlined above. That's exactly why I proposed a meta channel: to direct error messages to someone who can act appropriately. Some large sites have established feedback loops whereby a message is "bounced" to some postmaster. Apparently, they are mainly meant for "this is spam" actions. However, the ARF format (quite similar to DSN) provides fields for reporting bad DKIM signatures. I don't know at what level such bounces could be generated. It is technically possible to generate them right after the data transfer, just like for viral content. If we recognize that viruses are a problem, don't they deserve using that meta channel as well? This leaves us wondering how can such a meta channel be established for small and medium sites as well... _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 10:53:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CC028C27E; Thu, 15 Jan 2009 10:53:32 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842F23A6774 for ; Thu, 15 Jan 2009 10:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599] 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 7D3VrAKHSZmG for ; Thu, 15 Jan 2009 10:53:30 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id C1D193A6778 for ; Thu, 15 Jan 2009 10:53:30 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0FIr6gh022556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jan 2009 10:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232045594; x=1232131994; bh=9PAMzKKvJemRKR2G0a5YqcsQNbiONiVkPQsNeVYLhNo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Fn2x+IyECpAtWxJbI2wbr6W/jQXjapcDMEgFPTcFWvFHALldvsYhJ+Rp52zghS1AG VgkIcqAgGhOhhpHRGz/+LPDIEVgo97g9HrfnAe2B9mQGe1E4hnOylngEsFCE8Ya39P UVWzxhz2dg8C3v89k1dutxD2loseriSLK5h6H6/c= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=GE3+gb0XjhmMkPJ3hm487vgREld/Ts9oQV0cSAaa5ZC5TIcGyRKbiRNQB8OWPRXeN mzX/k4sSklXFO+o8AyBO0EqwLbCgQM6Fmt93jMVUE+BkDF3x5uDpdJ+aq4zPDVHVyqd OG3yCmlJ56FePkgPZkqXe11P3irP+1+X1qUi/4E= Message-Id: <6.2.5.6.2.20090115104638.02bb06d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Jan 2009 10:52:51 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <496E1CF7.3080701@tana.it> References: <20090112124924.GB30972@gsp.org> <496B69D9.1090807@tana.it> <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> Mime-Version: 1.0 Subject: Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 09:12 14-01-2009, Alessandro Vesely wrote: >599 Bounce to postmaster. What would be wrong if it existed? (I >mean, besides how hard it would be to reliably introduce it now.) There was a discussion about enhanced error codes where having a code conveying the reason for rejection was proposed. The idea was rejected. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 12:19:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674F03A6A10; Thu, 15 Jan 2009 12:19:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538013A6A07 for ; Thu, 15 Jan 2009 12:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CBfmAm6wDkCT for ; Thu, 15 Jan 2009 12:19:49 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 85B223A69F6 for ; Thu, 15 Jan 2009 12:19:49 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8CC7CA9443C for ; Thu, 15 Jan 2009 20:19:32 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <1232039524.32316.338.camel@tardis.isode.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 15 Jan 2009 12:19:31 -0800 References: <496D3C43.2030100@terabites.com> <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> <1231956007.32316.175.camel@tardis.isode.net> <496E35DC.7010906@nortel.com> <1232039524.32316.338.camel@tardis.isode.net> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 15, 2009, at 9:12 AM, David Wilson wrote: > On Wed, 2009-01-14 at 13:58 -0500, Chris Lewis wrote: >> I think you have an overly narrow definition of viruses - >> specifically, emails that carry malicious executables _directly_. >> The trap demonstrates that, at times, you'll see up to 50% of its >> entire flow is viral in the sense of, for example, links to >> malicious files. > > What I am talking about is messages for which the content is > reported by AV software as being infected. The probability that such > a message is not harmful is likely to be very, very small. A system > should behave responsibly with such a message, and not risk sending > it in a bounce message anywhere. Rejecting it might result in the > generation of such a bounce, if you have received the message from > an intermediate MTA. Chris Lewis made excellent points about low detection rates with today's highly polymorphic threats. Some providers in emerging markets are transparently intercepting traffic in a store and forward mode, and then bounce rejections. Those bouncing the message should adhere to RFC 3464, use the top level content type of multipart/ report, and then minimize the amount of original content. This makes NDNs less inviting as a method to distribute spam, creates less danger with respect to malware, and lowers the chances of being identified as a source of spam. False positives can still be determined by the sender, but better MUA automation for locating original messages would be helpful. -Doug _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 12:47:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0483A69A9; Thu, 15 Jan 2009 12:47:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269513A6842 for ; Thu, 15 Jan 2009 12:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8GmG1MFODIDy for ; Thu, 15 Jan 2009 12:47:48 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 1A09D3A6848 for ; Thu, 15 Jan 2009 12:47:48 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FKlVLx015174 for ; Thu, 15 Jan 2009 15:47:32 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FKcgKq014143 for ; Thu, 15 Jan 2009 15:38:42 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FKlPoS013527 for ; Thu, 15 Jan 2009 15:47:25 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FKlMEw013516 for asrg@irtf.org; Thu, 15 Jan 2009 15:47:22 -0500 Date: Thu, 15 Jan 2009 15:47:22 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115204722.GA27031@gsp.org> References: <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <496F8299.9060506@tana.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496F8299.9060506@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 07:38:17PM +0100, Alessandro Vesely wrote: > Yet, attentive postmasters are not omniscient. They need a data feed. It's called "their own log files". Those who do not pay attention to what's in them are highly unlikely to pay attention to anything else. > Having an appropriate error message is not enough. It is also necessary > to deliver that message to the right operator. Delivering error messages > to end users may be counter productive. For a non-viral example, what can > users do if their mail is bounced because of bad DKIM signatures? Nothing. Again, it's up to mail system administrators to read their own log files and act (if necessary) on what they find. I would think a log file full of SMTP rejects with "Hey, your DKIM signature is wrong" would get their attention. If not -- hey, if they don't care, why should anyone else? > That's exactly why I proposed a meta channel: to direct error messages > to someone who can act appropriately. But there's no point in going through all the debate and design and implementation and deployment effort associated with this. The same people who are presently ignoring their own log files will ignore this too. A much easier way to reach that subset of postmasters who are actually paying attention is to use appropriately verbose messages in rejection messages. For example: message rejected isn't nearly as helpful as message rejected; our antivirus scanner detected Blottosplang; contact jan2009@example.com if you believe this is an error and reference case 1234abcde where of course jan2009@example.com is unfiltered and forwards to the mailbox(es) of the right people. It also changes periodically because not only will it be harvested by spammers and targeted, but because every now and then someone's truly broken system will spew a backlog of several hundred no-longer-relevant messages at it. This is a better method because (a) it avoids generating more SMTP traffic (b) it's much harder to game and (c) it caters the most to the people who are paying the most attention: those who are monitoring their mail server logs in real time and (d) it utilizes what we already have without the need to invent or deploy new technology. There *are* issues with it: for example, information leakage (do you really want to tell the world *which* virus scanner you're running?) and non-standardization of error messages, for starters. But the former is addressed by some judicious local choices, and the latter with Perl. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 12:51:31 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9583A68E4; Thu, 15 Jan 2009 12:51:31 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E333A6848 for ; Thu, 15 Jan 2009 12:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qF55t1Kns0a4 for ; Thu, 15 Jan 2009 12:51:29 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D5B053A6842 for ; Thu, 15 Jan 2009 12:51:28 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0FKp9p13316 for ; Thu, 15 Jan 2009 20:51:09 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 15:50:54 -0500 Received: from [47.9.28.80] (47.9.28.80) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 15 Jan 2009 15:50:53 -0500 Message-ID: <496FA1AC.4090806@nortel.com> Date: Thu, 15 Jan 2009 15:50:52 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <1232037448.32316.305.camel@tardis.isode.net> In-Reply-To: <1232037448.32316.305.camel@tardis.isode.net> X-OriginalArrivalTime: 15 Jan 2009 20:50:54.0164 (UTC) FILETIME=[F5345140:01C97752] Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org David Wilson wrote: > However, what I have been saying is that rejecting using 5xx will > generate a bounce if the reject is sent as a response to an intermediate > MTA. And what I've been saying is that this is an insignificant issue in reality. "Intermediate" MTAs, in the sense of MTAs _other_ than the sender's or recipient's perimeter/internal servers are insignificant in the scheme of things. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 13:05:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E123A6A3E; Thu, 15 Jan 2009 13:05:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332C13A6A3E for ; Thu, 15 Jan 2009 13:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 Vox-EMAUBWrQ for ; Thu, 15 Jan 2009 13:05:00 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2AA913A6A07 for ; Thu, 15 Jan 2009 13:04:59 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0FL0sx02475 for ; Thu, 15 Jan 2009 21:00:54 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 16:04:41 -0500 Received: from [47.9.28.80] (47.9.28.80) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 15 Jan 2009 16:04:40 -0500 Message-ID: <496FA4E8.9080306@nortel.com> Date: Thu, 15 Jan 2009 16:04:40 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <1232038610.32316.324.camel@tardis.isode.net> In-Reply-To: <1232038610.32316.324.camel@tardis.isode.net> X-OriginalArrivalTime: 15 Jan 2009 21:04:41.0154 (UTC) FILETIME=[E220FA20:01C97754] Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org David Wilson wrote: > On Thu, 2009-01-15 at 10:45 -0500, Rich Kulawiec wrote: >>>> Among other things, "malicious" isn't universal. And anti-virus >> software >>>> does not have a 0% FP rate.) >>> I agree it cannot be 0%, but better than 0.000001% is expected. >> I think that's hopelessly optimistic in real-world settings. I >> routinely >> see a handful of FP's every month -- then again, I tend to send out >> mail >> talking about spam and phishes and so on, which most people don't. >> Also see Chris's excellent explanation, which I think is roughly >> typical of that at many large sites (it's certainly similar to the >> large sites I've worked on). > > If I read Chris' message, then I believe that he is not giving evidence > for AV false positives. That wasn't my point. My point was directly as to the "hazard" of 550-rejecting viruses. In that, despite having 550-rejected millions of viruses (1.3M Mydooms/day at peak), we haven't, in 11 years, heard of _one_ virus bounced by a MTA receiving one of our 550's landing in anyone's lap, let alone infecting anyone. That even if somehow blaming a virus on us for a 550 is extremely unlikely, that out of 10's of millions of real viruses being rejected, we would have heard of at least _one_. But we haven't. Thus, the hazards of 550'ing viruses are vastly overblown. Furhermore, since virus-intended rules aren't FP-free, the hazard of losing the DSN on a FP is far higher than the largely non-existent hazard of 550-ing a virus. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 13:17:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85023A6940; Thu, 15 Jan 2009 13:17:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2005C3A6940 for ; Thu, 15 Jan 2009 13:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gzgKgE6P1uzU for ; Thu, 15 Jan 2009 13:17:51 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 15BD13A6804 for ; Thu, 15 Jan 2009 13:17:50 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0FLHWp15717 for ; Thu, 15 Jan 2009 21:17:33 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 16:17:32 -0500 Received: from [47.9.28.80] (47.9.28.80) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 15 Jan 2009 16:17:32 -0500 Message-ID: <496FA7EB.1020902@nortel.com> Date: Thu, 15 Jan 2009 16:17:31 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <496F8299.9060506@tana.it> In-Reply-To: <496F8299.9060506@tana.it> X-OriginalArrivalTime: 15 Jan 2009 21:17:32.0674 (UTC) FILETIME=[ADFD9620:01C97756] Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Alessandro Vesely wrote: > Chris said their filter is not able to distinguish viruses from > generic malware. That should be read to mean "not in general", as opposed to "never". > Having an appropriate error message is not enough. It is also > necessary to deliver that message to the right operator. Thus becoming a DDOS vector. > Some large sites have established feedback loops whereby a message is > "bounced" to some postmaster. Apparently, they are mainly meant for > "this is spam" actions. However, the ARF format (quite similar to DSN) > provides fields for reporting bad DKIM signatures. I don't know at > what level such bounces could be generated. It is technically possible > to generate them right after the data transfer, just like for viral > content. If we recognize that viruses are a problem, don't they > deserve using that meta channel as well? This leaves us wondering how > can such a meta channel be established for small and medium sites as > well... Thus becoming a DDOS vector. Went through this conversation on another list recently. It is technically possible (in fact trivial in many cases) to instrument a MTA to automatically generate and send ARF in real time. Even assuming that the MTA can figure out the _right_ place to send the ARF, it becomes a WMD. Imagine, if you will, everybody did it. Some moderately sized site gets a reasonably prolific (single) infection, and spews out a few million viruses. You're expecting the site's MTAs to handle a few million ARFs, when only one _should_ suffice. If broadly implemented, it'd cause global meltdown. God help us all if the site receiving the ARF somehow doesn't recognize it as ARF, and replies with its own ARFs. Or, if the virus writer figures out a way to get the ARF generators to send it to the wrong place - believe me, they'd be trying... ARF is good stuff. But only insofar as there is limitations on how it's emitted/deployed. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 13:43:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1973A6783; Thu, 15 Jan 2009 13:43:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AD13A6783 for ; Thu, 15 Jan 2009 13:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 cxYIq6xLhJyI for ; Thu, 15 Jan 2009 13:43:10 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 2B9333A6405 for ; Thu, 15 Jan 2009 13:43:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id C608D64F8383 for ; Fri, 16 Jan 2009 09:42:58 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ4X4DRpiFX4 for ; Fri, 16 Jan 2009 09:42:53 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id EF17764F8350 for ; Fri, 16 Jan 2009 09:42:52 +1200 (FJT) Date: Fri, 16 Jan 2009 09:42:52 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <3815722.341232055759579.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <496FA7EB.1020902@nortel.com> MIME-Version: 1.0 X-Originating-IP: [113.20.66.166] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Well, any way to modify SMTP to still send ARF reports without taking down the whole Internet? Speaking out loud, a new capability in ESMTP, that would advertise the reception of ARF report, or a special mailbox standard on all MTA to accept ARF reports. We have postmaster, abuse, why not ARF? Or may be send this ARF report to a DNSBL service? After Authentication, it would place the original sender in a DNSBL stopping other from receiving further infected emails? Cheers ----- Original Message ----- From: "Chris Lewis" To: "Anti-Spam Research Group - IRTF" Sent: Friday, 16 January, 2009 9:17:31 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] Meta channel, not bounces Alessandro Vesely wrote: > Chris said their filter is not able to distinguish viruses from > generic malware. That should be read to mean "not in general", as opposed to "never". > Having an appropriate error message is not enough. It is also > necessary to deliver that message to the right operator. Thus becoming a DDOS vector. > Some large sites have established feedback loops whereby a message is > "bounced" to some postmaster. Apparently, they are mainly meant for > "this is spam" actions. However, the ARF format (quite similar to DSN) > provides fields for reporting bad DKIM signatures. I don't know at > what level such bounces could be generated. It is technically possible > to generate them right after the data transfer, just like for viral > content. If we recognize that viruses are a problem, don't they > deserve using that meta channel as well? This leaves us wondering how > can such a meta channel be established for small and medium sites as > well... Thus becoming a DDOS vector. Went through this conversation on another list recently. It is technically possible (in fact trivial in many cases) to instrument a MTA to automatically generate and send ARF in real time. Even assuming that the MTA can figure out the _right_ place to send the ARF, it becomes a WMD. Imagine, if you will, everybody did it. Some moderately sized site gets a reasonably prolific (single) infection, and spews out a few million viruses. You're expecting the site's MTAs to handle a few million ARFs, when only one _should_ suffice. If broadly implemented, it'd cause global meltdown. God help us all if the site receiving the ARF somehow doesn't recognize it as ARF, and replies with its own ARFs. Or, if the virus writer figures out a way to get the ARF generators to send it to the wrong place - believe me, they'd be trying... ARF is good stuff. But only insofar as there is limitations on how it's emitted/deployed. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 15:40:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1790B28C1DD; Thu, 15 Jan 2009 15:40:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDFB28C1B1 for ; Thu, 15 Jan 2009 15:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 8yi8sCL3X+dd for ; Thu, 15 Jan 2009 15:40:10 -0800 (PST) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id 9451328C14B for ; Thu, 15 Jan 2009 15:40:09 -0800 (PST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 56D9E29404 for ; Thu, 15 Jan 2009 18:39:54 -0500 (EST) Received: by panix5.panix.com (Postfix, from userid 756) id 4042724246; Thu, 15 Jan 2009 18:39:54 -0500 (EST) From: Seth To: asrg@irtf.org In-reply-to: <496FA7EB.1020902@nortel.com> (clewis@nortel.com) References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <496F8299.9060506@tana.it> <496FA7EB.1020902@nortel.com> Message-Id: <20090115233954.4042724246@panix5.panix.com> Date: Thu, 15 Jan 2009 18:39:54 -0500 (EST) Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org "Chris Lewis" wrote: > It is technically possible (in fact trivial in many cases) to > instrument a MTA to automatically generate and send ARF in real > time. Even assuming that the MTA can figure out the _right_ place > to send the ARF, it becomes a WMD. > > Imagine, if you will, everybody did it. Some moderately sized site > gets a reasonably prolific (single) infection, and spews out a few > million viruses. You're expecting the site's MTAs to handle a few > million ARFs, when only one _should_ suffice. If one suffices, then the site immediately closes or blocks the infected machine, and it doesn't get all that many notices. > If broadly implemented, it'd cause global meltdown. For a value of "global" closer to "sites that don't react to their infections in a sufficiently timely manner". > God help us all if the site receiving the ARF somehow doesn't > recognize it as ARF, and replies with its own ARFs. It would be better to create a new protocol for the ARF responses (even if it's just email on a new port, though I'd include some extensions to allow for "Report of virus emitter on " "I already know" "QUIT") Seth _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 15:45:44 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2073A6893; Thu, 15 Jan 2009 15:45:44 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36A73A6893 for ; Thu, 15 Jan 2009 15:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qjE3kl9Zk2mI for ; Thu, 15 Jan 2009 15:45:42 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id DB5523A6405 for ; Thu, 15 Jan 2009 15:45:41 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FNjQSl011815 for ; Thu, 15 Jan 2009 18:45:26 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FNabrc016638 for ; Thu, 15 Jan 2009 18:36:37 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FNjKCW012471 for ; Thu, 15 Jan 2009 18:45:20 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FNjISg012448 for asrg@irtf.org; Thu, 15 Jan 2009 18:45:18 -0500 Date: Thu, 15 Jan 2009 18:45:18 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115234518.GB31038@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1232036000.32316.296.camel@tardis.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 04:13:20PM +0000, David Wilson wrote: > On Thu, 2009-01-15 at 14:57 +0000, Ian Eiloart wrote: > > > Depends on what that prevention requires. ("Sure you can prevent > > abuse > > > of your domain. You just need to enter into a bilateral agreement > > with > > > every receiving mailhost on the net.") > > > > No, you just need to sign your outgoing email, and publish SPF > > records. > > And make sure that you send from hosts which are permitted by your SPF > info: This still isn't enough to prevent abuse of your domain. Let's make three assumptions, two of which (I think) you're advocating: 1. Lots and lots of hosts that are backscattering today don't fix the fundamental problem (that is, they continue to allow their systems to bounce instead of rejecting). Given how many mail system operators don't even know what backscatter, aka outscatter, is, and that some have openly declared themselves "required" to send it, this seems better-than-plausible. 2. Lots and lots of hosts adopt something like SPF. 3. You -- the keeper of example.com -- set up something like SPF. (Don't take any of this as an endorsement of SPF.) Let's press on and have some fun with example.com, by way of illustrating what I said above: A. I register throwaway domain a1s2d3f5g6h7.info. B. I arrange to have the domain hosted somewhere with, shall we say, less than stringent oversight. C. I set up DNS, including SPF, for a1s2d3f5g6h7.info. D. I send out a kazillion messages from user@a1s2d3f5g6h7.info, all of which will of course pass SPF checks. They're addressed to a kazillion addresses at a kazillion domains. Maybe some have malware attached. Maybe some have boilerplate spam content. Maybe some are addressed to probably-don't-exist addresses. E. Some of the receiving MX's will reject. Some will try to bounce. F. And this is where step (C) comes in, because I didn't point the MX records for a1s2d3f5g6h7.info at my own server: I pointed them at example.com's MXs. That's where the bounces will try to go. Oh, sure, the MX's for example.com are rather unlikely to accept any mail for a1s2d3f5g6h7.info, because of course they're not configured to, but how do you think those MX's will react when a kazillion mail systems (nearly) simultaneously all try to open up connections on port 25 and start shoving mail at them? G. Since I did all this using someone else's credit card, money is really no object. Repeat steps (A) - (D) several hundred times using diverse registrars, DNS services, hosting services, outbound message targets, etc. I can make this more interesting with some optional steps: use of botnets instead of host service, use of fast-flux DNS, pre-selection of hosts known to backscatter for (D), and/or making the putative sender of all these messages user@example.com.a1s2d3f5g6h7.info, which will confuse the hell out of a significant subset of people. Yes, this behavior will probably get each one of those domains and originating IP addresses of mine noticed and listed on various DNSBLs and RHSBLs relatively quickly, not that this will be much consolation to example.com while they're recovering from the DDoS attack. This is one of the more benign possible scenarios. And yes, there are all kinds of ways to counter this particular one, but my general point is that anything that lets third parties cause someone's mail system to emit outbound SMTP traffic to arbitrary destinations is a cause for concern...which is why I think one of the easiest and most productive things we could and should be doing is getting our mail systems set up to always reject and never bounce -- or as close as we can, modulo edge cases I've discussed elsewhere in the thread. That doesn't really "fix" anything, per se, but at least it minimizes ensuing secondary and tertiary consequences, and avoids adding still more SMTP traffic to the excess we already deal with. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 15 15:54:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BEE3A68D0; Thu, 15 Jan 2009 15:54:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C423A68D0 for ; Thu, 15 Jan 2009 15:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IS9mCcNVqL9m for ; Thu, 15 Jan 2009 15:54:35 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 884163A683D for ; Thu, 15 Jan 2009 15:54:35 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0FNsJPX003208 for ; Thu, 15 Jan 2009 18:54:20 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0FNjUFl007592 for ; Thu, 15 Jan 2009 18:45:30 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0FNsEAl016638 for ; Thu, 15 Jan 2009 18:54:14 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0FNsEWV016637 for asrg@irtf.org; Thu, 15 Jan 2009 18:54:14 -0500 Date: Thu, 15 Jan 2009 18:54:14 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090115235414.GC31038@gsp.org> References: <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> <1231956007.32316.175.camel@tardis.isode.net> <496E35DC.7010906@nortel.com> <1232039524.32316.338.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1232039524.32316.338.camel@tardis.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 05:12:04PM +0000, David Wilson wrote: > What I am talking about is messages for which the content is reported by > AV software as being infected. The probability that such a message is > not harmful is likely to be very, very small. A system should behave > responsibly with such a message, and not risk sending it in a bounce > message anywhere. Rejecting it might result in the generation of such a > bounce, if you have received the message from an intermediate MTA. But this is exactly the opposite of the situation here. You can send Windows malware here all day long and nothing will happen except maybe bemusement: there are no Windows systems here. "harm" is not an absolute. Not everyone's environment is the same. Moreover, trying to guess what someone else's mail system will do is pointless, and trying to correct it if you think it's wrong is futile. All you can do is *your part*, which is to reject with an appropriate error message and move on. (And as a practical matter, if it's not a real mail server talking to you, then it's not going to generate a bounce. If it *is* a real mail server talking to you, and it's trying to deliver malware, then it's probably already so badly hosed that nothing you could possibly do or not do will make it any worse.) ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 00:33:15 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6703A6894; Fri, 16 Jan 2009 00:33:15 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9053A6894 for ; Fri, 16 Jan 2009 00:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bkiT1zBQw2bv for ; Fri, 16 Jan 2009 00:33:13 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0F50C3A63EB for ; Fri, 16 Jan 2009 00:33:13 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 16 Jan 2009 08:32:57 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090115234518.GB31038@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> Organization: Isode Limited Date: Fri, 16 Jan 2009 08:32:48 +0000 Message-Id: <1232094768.3259.1.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, 2009-01-15 at 18:45 -0500, Rich Kulawiec wrote: > > And make sure that you send from hosts which are permitted by your > SPF > > info: > > This still isn't enough to prevent abuse of your domain. My point was not that this would prevent abuse of your domain. Rather that it is stupid to register information which is intended to go some way to prevent domain abuse, and then send messages which appear to be such abuse. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 02:26:08 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07D728C1ED; Fri, 16 Jan 2009 02:26:08 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5246928C113 for ; Fri, 16 Jan 2009 02:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GieBlfT3k8xJ for ; Fri, 16 Jan 2009 02:26:07 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7704228C1ED for ; Fri, 16 Jan 2009 02:25:59 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 16 Jan 2009 10:25:43 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090115235414.GC31038@gsp.org> References: <20090114014619.GB18217@gsp.org> <1231923898.3253.8.camel@bravo.isode.net> <20090114124240.GA26583@gsp.org> <1231938032.32316.13.camel@tardis.isode.net> <496DF4FB.2010304@nd.edu> <1231947932.32316.126.camel@tardis.isode.net> <496E0DCD.1040307@nortel.com> <1231956007.32316.175.camel@tardis.isode.net> <496E35DC.7010906@nortel.com> <1232039524.32316.338.camel@tardis.isode.net> <20090115235414.GC31038@gsp.org> Organization: Isode Limited Date: Fri, 16 Jan 2009 10:25:43 +0000 Message-Id: <1232101543.32316.368.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, 2009-01-15 at 18:54 -0500, Rich Kulawiec wrote: > Moreover, trying to guess what someone else's mail system will do is > pointless, and trying to correct it if you think it's wrong is futile. > All you can do is *your part*, which is to reject with an appropriate > error message and move on. > What a conforming MTA will do with a 5xx reject from your MTA is well > defined. From RFC 5321 Section 6.1: If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. The MTA has accepted the message, and the next-hop MTA has rejected it, so the message is suffering delivery failure. Therefore the MTA is obliged ("MUST") to send a notification message. Therefore, if you always 5xx messages which are known to contain malicious content, some fraction of those rejections will result in notification messages which are likely to contain that malicious content. If the vast majority of malicious content comes from bots or similar, then the fraction may be small. However, the MTA which generates the "bounce" is not at fault, it is doing what it is obliged to do. > (And as a practical matter, if it's not a real mail server talking to > you, then it's not going to generate a bounce. If it *is* a real mail > server talking to you, and it's trying to deliver malware, then it's > probably already so badly hosed that nothing you could possibly do or > not do will make it any worse.) An MTA has no obligation to inspect the content of messages which it is passing through. You might suggest that it does have that obligation, but there is none. Indeed, inspection of the content of messages by every MTA might be regarded as a violation of privacy. An MTA is not "badly hosed" that is simply doing its job of transferring messages based on the data in the message "envelope" (any more than a postal worker in a sorting office is at fault for sorting messages which happen to contain illegal images). _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 02:51:17 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4883E3A6961; Fri, 16 Jan 2009 02:51:17 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55CA3A6961 for ; Fri, 16 Jan 2009 02:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.893 X-Spam-Level: X-Spam-Status: No, score=-13.893 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_20=-0.74, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 k1Hh92avLxKw for ; Fri, 16 Jan 2009 02:51:15 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 641C83A6831 for ; Fri, 16 Jan 2009 02:51:14 -0800 (PST) Received: (qmail 60340 invoked from network); 16 Jan 2009 10:50:57 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 16 Jan 2009 10:50:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=IyUOAByTza1TeoJJFbPbigQrqoVTnsDmoFmG3EC+zEc=; b=E/s9UrMj/Is90Xqsskrbh+otCBSlWtVBZ0KulvnnMftdBcbpMIoWBTV8WtM3lNZIUcwvmlFc+QfNXUt/76tjIs+Kk/bJASS5OFJx7R+lHX1Br7TVUuxx/zAggXvcbhI9Dgx90ZAHnlrPToSVRtYSPIzWHOujd/iYdP+/a+1C5s0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=IyUOAByTza1TeoJJFbPbigQrqoVTnsDmoFmG3EC+zEc=; b=eR9+Bz6ezj1290TNeWPXtxw+mhQoM+oumtQnvPZjrXw8jkVsxU/CtiNJbvXVZTgqMjZUl+Uwjvx5ExfsyTxF2AbMy7UekQPLqlab9sX6uOo7JJ59P3Q34EP36JvNLyo6WgehMzDV1kBcWYZxpnyQLXgdvtBzhq2Sw7J8+KWGyI8= Date: 16 Jan 2009 10:50:54 -0000 Message-ID: <20090116105054.87916.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <1232101543.32316.368.camel@tardis.isode.net> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >Therefore, if you always 5xx messages which are known to contain >malicious content, some fraction of those rejections will result in >notification messages which are likely to contain that malicious >content. ... and as Chris has told you several times, that fraction has been observed to be less than 1/1,000,000, orders of magnitude less than the rejections that alert real users to false positives. So stop. Perhaps it's time to amend the ASRG charter to exclude easily visualized but actually hypothetical threats. If you disagree that they're hypothetical, first you have to go get real data to support your claim. Regards, John Levine, ASRG chair _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 03:10:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293C328C233; Fri, 16 Jan 2009 03:10:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F17F28C1FB for ; Fri, 16 Jan 2009 03:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 u2JqVwAjaZhC for ; Fri, 16 Jan 2009 03:10:45 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C93F23A6824 for ; Fri, 16 Jan 2009 03:10:44 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 16 Jan 2009 12:10:29 +0100 id 00000000005DC033.0000000049706B25.00001A64 Message-ID: <49706B24.6090801@tana.it> Date: Fri, 16 Jan 2009 12:10:28 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090112171422.GA26691@gsp.org> <200901121752.MAA22041@Sparkle.Rodents-Montreal.ORG> <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <496F8299.9060506@tana.it> <496FA7EB.1020902@nortel.com> <20090115233954.4042724246@panix5.panix.com> In-Reply-To: <20090115233954.4042724246@panix5.panix.com> Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Seth wrote: > "Chris Lewis" wrote: > >> It is technically possible (in fact trivial in many cases) to >> instrument a MTA to automatically generate and send ARF in real >> time. Even assuming that the MTA can figure out the _right_ place >> to send the ARF, it becomes a WMD. Yeah, standardizing arf@example.com can generate much confusion... >> Imagine, if you will, everybody did it. Some moderately sized site >> gets a reasonably prolific (single) infection, and spews out a few >> million viruses. You're expecting the site's MTAs to handle a few >> million ARFs, when only one _should_ suffice. > > If one suffices, then the site immediately closes or blocks the > infected machine, and it doesn't get all that many notices. If I understood Chris' point, there would be a few millions different MTAs that have been reached by the site's fallout. None of them knows whether anyone else already reported that notice. However, the number of notices is linear with the number of viral messages sent. If the site has been able to send so many messages, it might (should?) also be able to receive so many notices. Unlike DSN (which existed before their format was standardized), the response should be machine readable. Reporting to a DNSBL service, as Franck suggested, might overcome that risk. In facts there are monitoring services that do such kind of service. However, the server may submit its report to a different organization than the one(s) subscribed by the client. Unless they exchange data, thus forming a global distributed organization, report delivery would be at stake. Unfortunately, RIRs don't do that. > It would be better to create a new protocol for the ARF responses > (even if it's just email on a new port, though I'd include some > extensions to allow for "Report of virus emitter on " "I already > know" "QUIT") "I already know" requires a strong standardization of the reasons. Probably keying on faulty IPs can drastically reduce the number of repeated messages. For ARF reports, the receiving site doesn't have to reject or bounce what it doesn't want. Having two DATA commands, one for the machine readable part and a rejectable one for the original body, can save bandwidth; but currently ARF does not provide for that. Something new is required in order to let the client and server MTAs become aware that they both support ARF reporting. Perhaps they should negotiate what reports they are interested in, which ones with full bodies, for which types they only want one, etcetera. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 03:15:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7193628C21B; Fri, 16 Jan 2009 03:15:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B584F28C21B for ; Fri, 16 Jan 2009 03:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 a3Jj8a2vExm4 for ; Fri, 16 Jan 2009 03:15:01 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CE2F628C20D for ; Fri, 16 Jan 2009 03:15:00 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 16 Jan 2009 11:14:45 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090116105054.87916.qmail@simone.iecc.com> References: <20090116105054.87916.qmail@simone.iecc.com> Organization: Isode Limited Date: Fri, 16 Jan 2009 11:14:44 +0000 Message-Id: <1232104484.32316.402.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, 2009-01-16 at 10:50 +0000, John Levine wrote: > >Therefore, if you always 5xx messages which are known to contain > >malicious content, some fraction of those rejections will result in > >notification messages which are likely to contain that malicious > >content. > > ... and as Chris has told you several times, that fraction has been > observed to be less than 1/1,000,000, orders of magnitude less than > the rejections that alert real users to false positives. So stop. > > Perhaps it's time to amend the ASRG charter to exclude easily > visualized but actually hypothetical threats. If you disagree that > they're hypothetical, first you have to go get real data to support > your claim. So, just to clarify, you are saying that the view of ASRG is that if an MTA receives a message which when checked using anti-virus software such as Sophos or ClamAV (note this, my discussion was not about other anti-spam techniques) give a positive, the correct course of action is to reject the message using a 5xx response? _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 03:45:53 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB8B3A6917; Fri, 16 Jan 2009 03:45:53 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122CD3A6917 for ; Fri, 16 Jan 2009 03:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 6nsyZpv48-GE for ; Fri, 16 Jan 2009 03:45:52 -0800 (PST) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id D66C63A684C for ; Fri, 16 Jan 2009 03:45:50 -0800 (PST) Received: from ianeiloart.plus.com ([212.159.124.126]:62543 helo=[192.168.1.12]) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDKBGA-000GXG-0R for asrg@irtf.org; Fri, 16 Jan 2009 11:48:10 +0000 Date: Fri, 16 Jan 2009 11:45:33 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <775CA0FF2824E018986610DB@paine.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 12:58:28 -0500 der Mouse wrote: >> However, I do think that it's time that domain owners started taking >> responsibility for the use of their domains. > > If I, say, were to forge mail from your domain to, say, some ibm.com > user, would you take responsibility for it? That's what you seem to me > to be saying. Not quite, but not far off. I'm not taking responsibility for your decision to forge the domain. However, I AM responsible for the fact that IBM have no easy way to detect that forgery. I SHOULD accept that IBM are therefore more likely to bounce that email back to me. When a spammer forges my domain, and the recipient bounces the message, they're doing what SMTP is designed to do. I shouldn't get pissed off with the recipient, if I've failed to publish records that allow them to check for forgeries. What I should take responsibility for is publishing records that let IBM easily check whether the email is legitimate. For example, if I publish SPF records, and sign all my outgoing mail with DKIM, and require my users to use my Message Submission Service, then I think I've discharged that responsibility. Having taken those actions (actually, I haven't but this is hypthetical), I'm quite happy to accept any bounce messages from IBM - provided they've checked for an SPF or DKIM record match before accepting the message. Now, given that I haven't yet published SPF or DKIM records, I still get lots of spam bounced into my domain. Who do I blame? Well, in part it's my responsibility for failing to help the spam recipients. If I did publish those records, then recipient domains could more easily detect forgeries out of my domain. SPF records would be useful because you can check them early, and cheaply. DKIM give senders the opportunity to get messages through forwarders. Now, what I'm suggesting (not advocating yet, because I'm not certain that this is right), is that when there's no SPF record published, that we should not feel too bad about bouncing email because the domain administrator isn't taking adequate steps to protect the domain against spam blowback, and against phishing. Of course, I'm NOT suggesting that lack of an SPF record should score very high in any any spamicity measure, but it might count for something. Now, an SPF or DKIM match gives us the huge gain that we can bounce messages selectively based on the content. Some recipients may not want certain message content, but by the time we've seen the content SMTP doesn't allow us to selectively reject. And, a pass allows us to confidently whitelist a domain or sender address without opening up a huge hole in our spam defences. For example, I've refused to whitelist UK academic research boards because they don't publish SPF records. Now, the question is, what do we do when we see an SPF softfail, and no DKIM record? Well, at first I'd be reluctant to bounce the message, because I want to reward admins that are taking steps to protect their domains. However, that's not something that I'd be happy with on a permanent basis. Eventually, I want the world to be in a position where all forwarders check SPF on the way in, and rewrite sender domains. When we're sufficiently advanced in that project, then bouncing softfail would be more acceptable. > >> In a world where you *can* prevent abuse of your domain, what's wrong >> with bouncing email? > > Depends on what that prevention requires. ("Sure you can prevent abuse > of your domain. You just need to enter into a bilateral agreement with > every receiving mailhost on the net.") No, you just need to sign your outgoing email, and publish SPF records. I know, someone's going to tell me that SPF breaks forwarding. Well email is already broken. I get up to a million spam messages into my domain daily. Everything we do to prevent spam causes problems ranging from additional load on our DNS servers to loss of important emails. The question is, are we going to fix it? I think what I'm proposing would at least allow people to do safe whitelisting -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 03:46:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CF83A684C; Fri, 16 Jan 2009 03:46:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC33D3A695B for ; Fri, 16 Jan 2009 03:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.806 X-Spam-Level: X-Spam-Status: No, score=-14.806 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 ve07NtSyjNv4 for ; Fri, 16 Jan 2009 03:46:34 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id A117A3A67FD for ; Fri, 16 Jan 2009 03:46:34 -0800 (PST) Received: (qmail 5728 invoked from network); 16 Jan 2009 11:46:09 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 16 Jan 2009 11:46:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=CB6FzBJXOg0BhKW68anWYWjcndQX+RGThpIBUOuu1J4=; b=TOSsVaahSoId4acnHhQeRLwYJDAd4gejhoj3kLdO+Ykx0GHJeG9nC3cS/xoFTsbHc9Yrf6oWWtvjHencZvO4Fdp1bgicRJr5bpcmWWSIFjBT+j6RjglMbZdYYHoXSSWO2tLQ+I0rud8Y8W7U3K/tYXIK2ikpwPISAXobLegMOO4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=CB6FzBJXOg0BhKW68anWYWjcndQX+RGThpIBUOuu1J4=; b=Z3batDe6hd9Z2GrtpG245gzVwll6AyOPJ3MZaJQtBQA7E6zfJvukWM99Rl0t6iJNwhVCnWBPbf6A3mhKeD/0Ab1pBMJpvk7UxD+fvJ/eTycl9CQCYmTkeBK+204UendEj+I/Uo5IuKA+j7Fz4/EXPUIfsFKXdpIPf1rbaeapc9E= Date: 16 Jan 2009 11:46:06 -0000 Message-ID: <20090116114606.7261.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <1232104484.32316.402.camel@tardis.isode.net> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >So, just to clarify, you are saying that the view of ASRG is that if an >MTA receives a message which when checked using anti-virus software such >as Sophos or ClamAV (note this, my discussion was not about other >anti-spam techniques) give a positive, the correct course of action is >to reject the message using a 5xx response? That seems to be the consensus here, yes. My MTA does rejects on anything that has an attached EXE file, and I don't ever recall getting any complaints about backscatter. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 04:41:11 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237A43A69D4; Fri, 16 Jan 2009 04:41:11 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37503A69D4 for ; Fri, 16 Jan 2009 04:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 sm0ERMFnRjXh for ; Fri, 16 Jan 2009 04:41:09 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 047B63A6836 for ; Fri, 16 Jan 2009 04:41:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 8936D64F8396 for ; Sat, 17 Jan 2009 00:40:53 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opbkXdB3E3Bi for ; Sat, 17 Jan 2009 00:40:48 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id A2FCA64F8395 for ; Sat, 17 Jan 2009 00:40:48 +1200 (FJT) Date: Sat, 17 Jan 2009 00:40:48 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <8772147.41232109632377.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <20090116114606.7261.qmail@simone.iecc.com> MIME-Version: 1.0 X-Originating-IP: [113.20.66.166] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org It is standard to do that at the end of DATA. And it is best to do it there than later. Whoever is connecting is told "no", rather than sending an NDR to the "mail from" which is likely to be forged. Sync NDR are better than async NDR. ----- Original Message ----- From: "John Levine" To: asrg@irtf.org Sent: Friday, 16 January, 2009 11:46:06 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] enough about backscatter >So, just to clarify, you are saying that the view of ASRG is that if an >MTA receives a message which when checked using anti-virus software such >as Sophos or ClamAV (note this, my discussion was not about other >anti-spam techniques) give a positive, the correct course of action is >to reject the message using a 5xx response? That seems to be the consensus here, yes. My MTA does rejects on anything that has an attached EXE file, and I don't ever recall getting any complaints about backscatter. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 05:52:18 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F333A67EE; Fri, 16 Jan 2009 05:52:18 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8333A6817 for ; Fri, 16 Jan 2009 05:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 gIHOLeAuPdyB for ; Fri, 16 Jan 2009 05:52:13 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id B22523A67EE for ; Fri, 16 Jan 2009 05:52:13 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so1773737wfg.7 for ; Fri, 16 Jan 2009 05:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=RucFtGmRZyq1CFEDHK08R2rHXyA8cCPWPAfDta5WBFc=; b=ZI5H112/9NlwfGNOQjekCRNdd08oSDRDH99d3nYyYjDXrG3JeAJFXCfDmGqV5+ipRw z1vQoNNy9Db18wph7dRfoz6az6rP5LCPrEmkIWIkzYGArJcZmQkv2E3LRrozZRihb+jh NcgY0S06C6B/WRun/yWjJY6UFuRLNezdpPpoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mRmPy2S2R29jykSOFQDE6Ce9vAwPHF6cozCxY219vnx7BUGxinmHL+e5ujygakMghd rOqVNYgy36Y44zrwltk22VUB0sWOG0hpxHQGv0aCh009clQg1BGG3yShSFO7e9LhMvrv oGjusAX0ZqY3GUgEPkHMC+2UkElrToMNA2tF4= Received: by 10.142.50.15 with SMTP id x15mr1034400wfx.280.1232113917453; Fri, 16 Jan 2009 05:51:57 -0800 (PST) Received: by 10.142.155.11 with HTTP; Fri, 16 Jan 2009 05:51:57 -0800 (PST) Message-ID: <7ae58c220901160551r1b801c51hd0f8256a15323138@mail.gmail.com> Date: Fri, 16 Jan 2009 08:51:57 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 12, 2009 at 6:33 AM, Ian Eiloart wrote: > > > Actually, it occurred to me that we have mechanisms whereby domain owners > can prevent abuse of their domains (SPF and DKIM). Therefore, we should feel > free to bounce email to any domain owner the doesn't deploy SPF and DKIM - > in order to encourage them to do so. Of course, bouncing email is also OK > when you find an SPF or DKIM match. > Ian, the correct way of phrasing it is that SPF and DKIM can MITIGATE (my emphasis) certain types of abuse of their domains. I would also point out that someone could deploy an SPF record with a +all. How does that prevent anything? _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 06:05:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEF03A6824; Fri, 16 Jan 2009 06:05:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77213A6851 for ; Fri, 16 Jan 2009 06:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 l-iqWUfhkaiZ for ; Fri, 16 Jan 2009 06:05:03 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 145AE3A6824 for ; Fri, 16 Jan 2009 06:05:03 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0GE4kP3030789 for ; Fri, 16 Jan 2009 09:04:47 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0GDtuDB012028 for ; Fri, 16 Jan 2009 08:55:56 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0GE4fEX031451 for ; Fri, 16 Jan 2009 09:04:41 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0GE4Tu0031426 for asrg@irtf.org; Fri, 16 Jan 2009 09:04:29 -0500 Date: Fri, 16 Jan 2009 09:04:29 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090116140429.GA29881@gsp.org> References: <20090116114606.7261.qmail@simone.iecc.com> <8772147.41232109632377.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8772147.41232109632377.JavaMail.franck@franck-martins-macbook-pro.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sat, Jan 17, 2009 at 12:40:48AM +1200, Franck Martin wrote: > It is standard to do that at the end of DATA. And it is best to do it there than later. Well, you can also do it much earlier. I reject the overwhelming majority of mail (>95% of all rejections) before DATA, based on connecting IP, connecting IP's rDNS, putative sender, recipient, and so on. "Reject early, reject often" is one way I've jokingly put it -- after all, once something has demonstrated that it's actively malicious, there's no point in even bothering to stick around for the data: 5XX it, hang up, and move on. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 06:14:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79233A68CF; Fri, 16 Jan 2009 06:14:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9FD3A6836 for ; Fri, 16 Jan 2009 06:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eeaF8ccbnhod for ; Fri, 16 Jan 2009 06:14:36 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id D6BCC3A67DD for ; Fri, 16 Jan 2009 06:14:35 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0GEEJC6002744 for ; Fri, 16 Jan 2009 09:14:20 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0GE5Wwu005915 for ; Fri, 16 Jan 2009 09:05:32 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0GEEI0L002419 for ; Fri, 16 Jan 2009 09:14:18 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0GEEIUo002418 for asrg@irtf.org; Fri, 16 Jan 2009 09:14:18 -0500 Date: Fri, 16 Jan 2009 09:14:18 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090116141418.GC29881@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> <1232094768.3259.1.camel@bravo.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1232094768.3259.1.camel@bravo.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, Jan 16, 2009 at 08:32:48AM +0000, David Wilson wrote: > My point was not that this would prevent abuse of your domain. Rather > that it is stupid to register information which is intended to go some > way to prevent domain abuse, and then send messages which appear to be > such abuse. An SMTP reject is not a mail message. But more broadly, you could have stopped after the first clause: *nothing* you register will prevent domain abuse if someone (or something) is determined to inflict it, since whatever you've done can simply be ignored (and probably will be). Besides, domain abuse is not a systemic, persistent problem; spam, including backscatter/outscatter as one of its variants, is, which is why (I believe) this RG exists. That said, one of the best, easiest, and cheapest ways to gain free assistance with abuse of one's domain is to maintain the "abuse" address, per RFC 2142 (which dates from 1997). I'm often struck by what byzantine schemes are proposed (for abuse control) while this simple measure goes almost entirely overlooked. (Note for example yesterday's traffic on Dave Farber's excellent "IP" list in re the difficulties of contacting Facebook's abuse/fraud group.) ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 08:11:04 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3882E3A689B; Fri, 16 Jan 2009 08:11:04 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D593A68B0 for ; Fri, 16 Jan 2009 08:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pB9k95D4cvQU for ; Fri, 16 Jan 2009 08:11:01 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 589463A6836 for ; Fri, 16 Jan 2009 08:11:01 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0GG6sA13331 for ; Fri, 16 Jan 2009 16:06:55 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 11:10:41 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 16 Jan 2009 11:10:41 -0500 Message-ID: <4970B180.2050900@nortel.com> Date: Fri, 16 Jan 2009 11:10:40 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090116114606.7261.qmail@simone.iecc.com> <8772147.41232109632377.JavaMail.franck@franck-martins-macbook-pro.local> <20090116140429.GA29881@gsp.org> In-Reply-To: <20090116140429.GA29881@gsp.org> X-OriginalArrivalTime: 16 Jan 2009 16:10:41.0652 (UTC) FILETIME=[FA945340:01C977F4] Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > On Sat, Jan 17, 2009 at 12:40:48AM +1200, Franck Martin wrote: >> It is standard to do that at the end of DATA. And it is best to do it there than later. > > Well, you can also do it much earlier. I reject the overwhelming majority > of mail (>95% of all rejections) before DATA, based on connecting IP, > connecting IP's rDNS, putative sender, recipient, and so on. "Reject > early, reject often" is one way I've jokingly put it -- after all, > once something has demonstrated that it's actively malicious, there's no > point in even bothering to stick around for the data: 5XX it, hang up, > and move on. Well, you _could_ reject earlier, but not via a content-based filter, such as ClamAV. Secondly, there is occasionally point of sticking around for data, even if you've already decided you're not going to pass it through to the recipient. Your filter could be wrong, and allowing thru to end of DATA permits you to quarantine, allow the user to see if if they wish via per-user quarantine, and forward later if required. Secondly, you can derive useful information from the body (eg: for other filtering, virus forensics, samples for virustotal etc) The first "point" was mandated upon us - the "no lost email" rule. We could reject earlier, or even by firewall rule for some situations. There are tricks with MXes that we've used to completely eliminate some BOTs managing to connect to us at all. But at present, we swallow everything thru to end-of-data. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 08:34:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564673A6896; Fri, 16 Jan 2009 08:34:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907273A68CC for ; Fri, 16 Jan 2009 08:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 UWtbn2cPZrIK for ; Fri, 16 Jan 2009 08:34:21 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5D27D3A67FF for ; Fri, 16 Jan 2009 08:34:21 -0800 (PST) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 16 Jan 2009 16:34:04 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <20090116141418.GC29881@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> <1232094768.3259.1.camel@bravo.isode.net> <20090116141418.GC29881@gsp.org> Organization: Isode Limited Date: Fri, 16 Jan 2009 16:34:04 +0000 Message-Id: <1232123644.32316.568.camel@tardis.isode.net> X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) MIME-Version: 1.0 Subject: Re: [Asrg] SPF and backscatter (was: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, 2009-01-16 at 09:14 -0500, Rich Kulawiec wrote: > > My point was not that this would prevent abuse of your domain. > Rather > > that it is stupid to register information which is intended to go > some > > way to prevent domain abuse, and then send messages which appear to > be > > such abuse. > > An SMTP reject is not a mail message. > > But more broadly, you could have stopped after the first clause: > *nothing* you register will prevent domain abuse if someone (or > something) > is determined to inflict it, since whatever you've done can simply be > ignored (and probably will be). Besides, domain abuse is not a > systemic, > persistent problem; spam, including backscatter/outscatter as one of > its variants, is, which is why (I believe) this RG exists. I'm not sure where I was promoting anything. Ian wrote about SPF and DKIM. I gave a couple of example of domain for which SPF information had been registered, but the owners of the domain were going against their own action. (In one case it was the domain owner's agent who probably added the SPF information). I said nothing about the value or otherwise of SPF for domain abuse. Having said that, since we registered SPF information for our domain, the amount of backscatter seems to have been dramatically reduced. I'm talking about certainly a factor of 10, and perhaps much higher (it would be some work to verify this). I don't know if this is because: - receivers are using SPF information to reject at, say, MAIL FROM, or otherwise - spammers avoid forging return paths with domains with SPF info Roughly 15% of message from the outside world which we receive are suffering SPF failures (about 3:1 soft fails to hard fails, and about 15% of the failures are for our own domain, typically as a result of using the same address for originator and recipient). So, I suspect that the first of the reasons is playing a significant part in reducing backscatter. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 10:01:01 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513C83A69DF; Fri, 16 Jan 2009 10:01:01 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2921D3A6806 for ; Fri, 16 Jan 2009 10:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599] 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 4RQb6Bpaiyhc for ; Fri, 16 Jan 2009 10:00:59 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 4048F3A698F for ; Fri, 16 Jan 2009 10:00:59 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0GI0Ybj018972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Jan 2009 10:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232128842; x=1232215242; bh=h+4W1SGuJ5fsGfAUVYIEO+rk5ffjgPMJF3gMCpjZWUY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=XMhZynTtaqOjMDY6XpYZ1zJkFbqHHlY7WzlmBB9/jOc7Uo2o99+PX01nhmwKbybzX 1Z4FNVNUL0qw3R2IeepasZftDZzDqUvkjavQphDCQhuWSUnfVsxn5dhN3rhdyTFSnB oiOOpvRe5TMqbmabgWuKtuU7457Py9TPSTXKm11M= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=KGIk35hMuZ/yme+XIXFYah90OH0dVRF9Z5JL4dkTzSGguXD3MhYrMPfZ4kyouHQDc UuaDlUtNNomWHLc1uuM3MBzou+8sSMUNMd2sqe7yFqxvgVhsjxUlHlIbI6RYylsvaBr 9PJdfD5rfh8j12Lvr/ZLsPv8o5C0Tbnbh1of6As= Message-Id: <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Jan 2009 10:00:17 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <775CA0FF2824E018986610DB@paine.local> References: <775CA0FF2824E018986610DB@paine.local> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 03:45 16-01-2009, Ian Eiloart wrote: >Now, what I'm suggesting (not advocating yet, because I'm not >certain that this is right), is that when there's no SPF record >published, that we should not feel too bad about bouncing email >because the domain administrator isn't taking adequate steps to >protect the domain against spam blowback, and against phishing. Of >course, I'm NOT suggesting that lack of an SPF record should score >very high in any any spamicity measure, but it might count for something. What does SPF have to do with phishing? I prefer to take adequate steps to prevent "invalid" bounces. It helps me if the postmaster takes adequate steps for me to determine what is valid. Some people do not use SPF due to its restrictions on email usage. >Now, an SPF or DKIM match gives us the huge gain that we can bounce >messages selectively based on the content. Some recipients may not >want certain message content, but by the DKIM-signed messages coming through this mailing list cannot be verified. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 15:48:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DA33A69C9; Fri, 16 Jan 2009 15:48:16 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620483A69C9 for ; Fri, 16 Jan 2009 15:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_NUMERIC_HELO=2.067] 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 iQTGfUzufd9P for ; Fri, 16 Jan 2009 15:48:15 -0800 (PST) Received: from webmail.returnpath.net (webmail.returnpath.net [67.154.224.203]) by core3.amsl.com (Postfix) with ESMTP id 945653A694F for ; Fri, 16 Jan 2009 15:48:15 -0800 (PST) Received: from 38.109.196.53 ([38.109.196.53]) by rpnyex01.rpcorp.local ([192.168.1.16]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Jan 2009 23:47:08 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 16 Jan 2009 16:47:41 -0700 From: "J.D. Falk" To: Anti-Spam Research Group - IRTF Message-ID: Thread-Topic: [Asrg] enough about backscatter Thread-Index: Acl4NNHI7VyA1ExpbUir8bNUB6dEyQ== In-Reply-To: <20090116105054.87916.qmail@simone.iecc.com> Mime-version: 1.0 Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 16/01/2009 03:50, "John Levine" wrote: > Perhaps it's time to amend the ASRG charter to exclude easily > visualized but actually hypothetical threats. If you disagree that > they're hypothetical, first you have to go get real data to support > your claim. +1 However, I wouldn't mind discussion about /how/ to get real data.... _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 16 17:47:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0631D28C0F0; Fri, 16 Jan 2009 17:47:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FEB3A69DD for ; Fri, 16 Jan 2009 17:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] 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 Ig+wpzlebXwN for ; Fri, 16 Jan 2009 17:47:51 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 1CBD53A698E for ; Fri, 16 Jan 2009 17:47:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 3FA2264F8396 for ; Sat, 17 Jan 2009 13:47:45 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD1Nx83AqRyF for ; Sat, 17 Jan 2009 13:47:43 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4E0E764F8395 for ; Sat, 17 Jan 2009 13:47:43 +1200 (FJT) Date: Sat, 17 Jan 2009 13:47:43 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <13264039.81232156850779.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <8431661.61232153583954.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Subscribe to SDNS from MS, with a wide range of IPs with the authorisation of the various IP "owners" Get data from Return-Path that operates a few feedback loops for big ESP. ----- Original Message ----- From: "J.D. Falk" To: "Anti-Spam Research Group - IRTF" Sent: Saturday, 17 January, 2009 11:47:41 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] enough about backscatter On 16/01/2009 03:50, "John Levine" wrote: > Perhaps it's time to amend the ASRG charter to exclude easily > visualized but actually hypothetical threats. If you disagree that > they're hypothetical, first you have to go get real data to support > your claim. +1 However, I wouldn't mind discussion about /how/ to get real data.... _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 18 17:06:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFEA3A6A62; Sun, 18 Jan 2009 17:06:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BCF28C128 for ; Sun, 18 Jan 2009 17:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 Q25m9CD5jm6a for ; Sun, 18 Jan 2009 17:06:24 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id E67243A6A0A for ; Sun, 18 Jan 2009 17:06:24 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 0D447A9443A for ; Mon, 19 Jan 2009 01:06:05 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 18 Jan 2009 17:05:57 -0800 References: X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 16, 2009, at 3:47 PM, J.D. Falk wrote: > On 16/01/2009 03:50, "John Levine" wrote: > >> Perhaps it's time to amend the ASRG charter to exclude easily >> visualized but actually hypothetical threats. If you disagree that >> they're hypothetical, first you have to go get real data to support >> your claim. > > +1 > > However, I wouldn't mind discussion about /how/ to get real data.... Some decisions depend upon doubts expressed of potential threats. Proponents are likely to insist a threat is only theoretical and do little more than make poorly considered comparisons. Proving a point will likely require staging a vectored attack exploiting recipient resources, which seems dangerous from a legal standpoint. Anything less is likely to be dismissed. MTA administrators appear to pay little attention to a problem not directly effecting them. In the meantime, the problem results in a greater number of confidence artist victims, and millions of dollars in damages occur due to DDoS attacks against those reporting on spam or malware threats, for example. Unfortunately, these attacks rarely target MTA administrators who seem willing to look the other way. After all, the championed path registration schemes can be structured to deflect accountability away from the MTA. The excuses for doing this can be found in appendix D of the Authentication-Results header draft. See: http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-19.txt With the introduction of the Authentication-Results header, the underlying goal becomes clearer as a scheme to deflect assessments away from the MTA onto that of an authorizing domain. Basing treatment upon an authorizing domain allows an MTA that may suffering from compromised access to remain otherwise unimpaired. The Authentication-Results draft never stipulates that the authentication results header should not be added without making a reputation check of assumed protections. Only that the results of this header should not be revealed without a reputation check, which included an example of a phishing domain. Of course, no phishing domain should be accepted, let alone given an Authentication-Results header right? Nevertheless, this check is to be made prior to revealing the content of this header, a function likely provided by the MUA. Those revealing these results are required to assume the authorizing domain's reputation had been checked in a manner that directly pertains to identity being asserted without the check ever being directly indicated within the header. The draft also states that, given the passage of time, rejections (rather than annotations being withheld), might occur when MUAs are allowed to ensure these checks separately. This draft seems happy to have checks made against the local-part and domain, while also stating that there is a DDoS concern regarding the use of the IP address of the SMTP client. Checks against the local-part and the domain represent several orders of increased overhead as compared to what is required of the IP address of an SMTP client. Take for example the SPF local-part macros. These macros are almost _never_ legitimately used, and _can_ be exploited by spam campaigns to leverage cached SPF records when constructing vectored DDoS attacks that do not expend additional resources of the attacker. It is fairly normal to see millions of bot-net sources (IP addresses) becoming active for short intervals out of a set of several hundred million that may have been dormant for months to years. Although concern has been expressed about how these macros can be exploited, and how impractical it is to use local-part macros to produce positive assertions, nothing seems to deter this feature from being institutionalized as a means to obtain message annotations as is now required by the Authentication-Results header draft! When one wants their email to be noticed, this draft stipulates the use of local-part macros as an unintended requirement. Of course, including the IP address within the Authentication-Results header permits a means to mitigate difficult problems that might be related to compromised servers or BGP route injections that completely defeat path registrations, but this protective information is purposely omitted. The period that separates a message being received to when it is handled by the MUA provides valuable time to offer protection in the way of annotation. Instead the draft conflates annotation with that of message rejection. The MailMan program running many of the IETF mailing lists handles and annotates messages behind the MTA, where the use of RFC 3464 becomes important. If if something more elaborate were to be implemented by the MUA, there are solutions in current use to mitigate these threats. A reputation service can easily extend the time of a reporting by indicating the number of hours since a threat has been resolved. An annotation can be applied perhaps just in time, or not depending upon the threat information that relates to the actual source of the message, the SMTP client. -Doug _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 18 17:35:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4063E3A69A2; Sun, 18 Jan 2009 17:35:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5358D28C128 for ; Sun, 18 Jan 2009 17:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 S69m8uwpk+L7 for ; Sun, 18 Jan 2009 17:35:18 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 6527B3A67D6 for ; Sun, 18 Jan 2009 17:35:18 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0J1YwL19664 for ; Mon, 19 Jan 2009 01:34:58 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Jan 2009 20:34:58 -0500 Received: from [47.9.28.51] (47.9.28.51) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 18 Jan 2009 20:34:57 -0500 Message-ID: <4973D8BD.3070403@nortel.com> Date: Sun, 18 Jan 2009 20:34:53 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: In-Reply-To: X-OriginalArrivalTime: 19 Jan 2009 01:34:58.0529 (UTC) FILETIME=[23AD4510:01C979D6] Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org J.D. Falk wrote: > On 16/01/2009 03:50, "John Levine" wrote: > >> Perhaps it's time to amend the ASRG charter to exclude easily >> visualized but actually hypothetical threats. If you disagree that >> they're hypothetical, first you have to go get real data to support >> your claim. > However, I wouldn't mind discussion about /how/ to get real data.... It seems to me to be part of a process. A "threat model" comes up, and we remember that part of the discussion should be to figure out how likely/possible/extant they really are. Indeed, if you don't think a threat model is realistic, it's kinda hard to prove that it isn't - proving a negative. In the discussion at hand, I wasn't able to give concise quantitative numbers. Because they are, to a great degree, unknowable. What I did instead was to show, by inference/within orders of magnitude, that i wasn't happening with _huge_ numbers of "supposedly dangerous actions" (rejecting). _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 18 18:37:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D1E3A6A39; Sun, 18 Jan 2009 18:37:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF153A69EB for ; Sun, 18 Jan 2009 18:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 U28TucEKQOCf for ; Sun, 18 Jan 2009 18:37:51 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 539713A68C9 for ; Sun, 18 Jan 2009 18:37:51 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id A7F294F803A for ; Sun, 18 Jan 2009 18:37:30 -0800 (PST) Message-Id: <78A953E0-D723-48D3-8BEB-7A2F89066F7A@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <4973D8BD.3070403@nortel.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 18 Jan 2009 18:37:33 -0800 References: <4973D8BD.3070403@nortel.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] enough about backscatter X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 18, 2009, at 5:34 PM, Chris Lewis wrote: > J.D. Falk wrote: >> On 16/01/2009 03:50, "John Levine" wrote: >> >>> Perhaps it's time to amend the ASRG charter to exclude easily >>> visualized but actually hypothetical threats. If you disagree that >>> they're hypothetical, first you have to go get real data to support >>> your claim. > >> However, I wouldn't mind discussion about /how/ to get real data.... > > It seems to me to be part of a process. A "threat model" comes up, > and > we remember that part of the discussion should be to figure out how > likely/possible/extant they really are. > Indeed, if you don't think a threat model is realistic, it's kinda > hard > to prove that it isn't - proving a negative. Also, part of the process is either the deployment of the supposed countermeasure and watching the result, or construction of a plausible theoretical model, designed by thoughtful, well-informed people, of the same. Measuring how well some countermeasure works on traffic monitored _today_, before widespread adoption of the countermeasure and changes by other parties on the network in response to that deployment is often going to be entirely worthless. In those cases, the only way to measure (as opposed to predict) the efficacy of a countermeasure is fairly large scale deployment. > In the discussion at hand, I wasn't able to give concise quantitative > numbers. Because they are, to a great degree, unknowable. What I did > instead was to show, by inference/within orders of magnitude, that i > wasn't happening with _huge_ numbers of "supposedly dangerous actions" > (rejecting). Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 02:21:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785FD3A69A3; Mon, 19 Jan 2009 02:21:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7073A68C7 for ; Mon, 19 Jan 2009 02:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 rNurDBimy-cV for ; Mon, 19 Jan 2009 02:21:26 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 0431C3A677C for ; Mon, 19 Jan 2009 02:21:24 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50053) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPRJY-000A5S-88 for asrg@irtf.org; Mon, 19 Jan 2009 10:23:58 +0000 Date: Mon, 19 Jan 2009 10:21:04 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <9A6505ABB645EDF6F7FA1806@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090112170222.CE499241DC@panix5.panix.com> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> <20090112170222.CE499241DC@panix5.panix.com> Originator-Info: login-token=Mulberry:01T6yPfLgN/eGQGePeu9LCIQLvtSSw1rLSxBc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 12:02:22 -0500 Seth wrote: > Ian Eiloart wrote: > >> Of course they could, but wouldn't they be better advised to take >> responsibility for their domains, > > They do: by not emitting spam. That's what they're responsible to do. No, that's not taking responsibility for your domain, that's taking responsibility for your network. It's not the same thing, even if you think it's adequate. > They aren't responsible to sign up for Clever-Idea-Of-The-Week and > implement whatever makes your life easier. But, primarily it make the domain owner's life easier. In two ways. First, they will get less collateral spam into their mailboxes. Second, they will find that their email becomes more deliverable. >> thus preventing me from having to deal >> with spam sent "from" their domain? > > It's not my responsibility to mediate the transaction between two > third parties, even if one of them lies about being me. True. Just as it isn't your responsibility to prevent criminals from using your credit card details. However, you suffer when they do. Therefore you are well advised to take what security measures you can to prevent that. Actually, it's something that the world has to collaborate on. We all have a collective responsibility. But maybe you don't care? > Seth > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 02:45:31 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADA33A6A36; Mon, 19 Jan 2009 02:45:30 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5F43A6A36 for ; Mon, 19 Jan 2009 02:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 l8e-Fb2YFK76 for ; Mon, 19 Jan 2009 02:45:28 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 26B833A677C for ; Mon, 19 Jan 2009 02:45:27 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50316) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPSO3-000K1S-P5 for asrg@irtf.org; Mon, 19 Jan 2009 10:48:04 +0000 Date: Mon, 19 Jan 2009 10:45:10 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <887A166BF10DC7D3E6D36663@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <496B80CB.8060806@nortel.com> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> <496B80CB.8060806@nortel.com> Originator-Info: login-token=Mulberry:01U5rZUbz7R7aUBy2zv8DGD0zEuRL6q7bAyAU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 12:41:31 -0500 Chris Lewis wrote: > Ian Eiloart wrote: > >> Of course they could, but wouldn't they be better advised to take >> responsibility for their domains, thus preventing me from having to deal >> with spam sent "from" their domain? > > Please describe a _practical_ way to deal with Russian or Ukrainian > virus/botspammers forging our domains in their spewage. Practical. Well, you're doing more than many people do. What I'm suggesting isn't going to fix the problem overnight, and not for any specific individual. This is a political issue, now given that the technologies exist. To solve the political problem, we need to convince others to publish the records, and to respect them. When enough people are respecting SPF records with strong policies, then spammers will stop using domains that publish those records. They need their spam to be deliverable. Of course, that doesn't mean that they'll stop spamming, just that they'll stop using your domain. You'll benefit from reduced spam blowback. You'll benefit from improved reputation. You can benefit now by respecting your own SPF records - thus preventing spammers from spoofing "internal" email. > SPF? DKIM? We do SPF. We may end up doing DKIM some day. But it > won't make a significant difference to what is being _sent_. > > This is vaguely reminiscent of the complainer who, when I pointed out > that our domain in his complaint was forged, replied with "well, you > must be doing something bad if they're forging you like that". > > Splorf. "Bad" for whom? ;-) > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:08:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA313A6A45; Mon, 19 Jan 2009 03:08:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DBE3A6A45 for ; Mon, 19 Jan 2009 03:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 ZPZRQUZwJBf2 for ; Mon, 19 Jan 2009 03:08:50 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id DF9AF3A685B for ; Mon, 19 Jan 2009 03:08:49 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50469) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPTR1-0006R9-CX for asrg@irtf.org; Mon, 19 Jan 2009 11:11:25 +0000 Date: Mon, 19 Jan 2009 11:08:32 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <1231780846.29802.3.camel@squonk.lboro.ac.uk> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <1231780846.29802.3.camel@squonk.lboro.ac.uk> Originator-Info: login-token=Mulberry:015mdv3U/I3UIn1MM/Uo1Z3OJQTN+QN0mNW9I=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 12 January 2009 17:20:46 +0000 Graeme Fowler wrote: > On Mon, 2009-01-12 at 11:06 -0500, Seth wrote: >> And the recipients of the bounces should feel free to report your >> bounces as spam. And they should also feel free to cut your Internet >> connection to block further spam from your site, to encourage you to >> stop spamming. > > I have a sneaking suspicion that there may be a terminology problem > here: Ian more than likely means "reject" when he says "bounce". The > thread becomes rather less argumentative if you do that replacement. No, actually I mean bounce. I mean "generate a new message". Domain owners are able to help the world detect forgeries. If they don't do that, then perhaps the rest of the world should not feel too bad about using SMTP in the way that it was designed by generating a bounce message. > Of course, I may be putting words into Ian's mouth which he *didn't* > mean, but before anyone else replies I would like to see Ian clarify > whether he means "bounce" or "reject". > > Knowing him at least a little in my professional capacity I would be > *very* surprised if he did intend to write "bounce", unless he was being > deliberately controversial... Thanks. I am deliberately trying to generate discussion of the idea. I'm well aware, that it's not very nice to be on the receiving end of collateral spam. And have for some time thought that the solution is to argue that nobody should bounce email. However it occurred to me recently, that actually you don't need to be on the receiving end of collateral spam. Rather than trying to persuade people to NEVER bounce an email, it might be better to let people know which emails can be bounced - those with proper SPF or DKIM matches. There are at least two very good reasons for wanting to bounce rather than reject emails. a) when a message has two or more local recipients, you can't have different policies for each recipient about what to reject. You reject for all or no recipients. There are some workarounds, but they're kludgy and cause their own problems. b) when you reject a message you can try to explain why, but often the sending MTA will throw away some or all of your explanation. Usually, it will wrap your explanation inside it's own. The end result is that the recipient of the bounce message (if there is one) doesn't understand what's going on. If you generate a bounce, you have full control of what the bounce recipient sees. For example, you could include an explanation of why they should lobby their domain controller to publish SPF records. > Graeme > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:13:13 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67E13A6B90; Mon, 19 Jan 2009 03:13:13 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07183A6B90 for ; Mon, 19 Jan 2009 03:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 10Nx71WejTqJ for ; Mon, 19 Jan 2009 03:13:12 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id D4ED53A6A36 for ; Mon, 19 Jan 2009 03:13:11 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50509) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPTYC-0008EQ-07 for asrg@irtf.org; Mon, 19 Jan 2009 11:15:48 +0000 Date: Mon, 19 Jan 2009 11:12:55 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <7ae58c220901160551r1b801c51hd0f8256a15323138@mail.gmail.com> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <7ae58c220901160551r1b801c51hd0f8256a15323138@mail.gmail.com> Originator-Info: login-token=Mulberry:01n/UAUAhWbrXgYlSyCxsSanPDBW0hqgIbFGA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 16 January 2009 08:51:57 -0500 Dotzero wrote: > On Mon, Jan 12, 2009 at 6:33 AM, Ian Eiloart wrote: >> >> >> Actually, it occurred to me that we have mechanisms whereby domain owners >> can prevent abuse of their domains (SPF and DKIM). Therefore, we should >> feel free to bounce email to any domain owner the doesn't deploy SPF and >> DKIM - in order to encourage them to do so. Of course, bouncing email is >> also OK when you find an SPF or DKIM match. >> > > Ian, the correct way of phrasing it is that SPF and DKIM can MITIGATE > (my emphasis) certain types of abuse of their domains. > > I would also point out that someone could deploy an SPF record with a > +all. How does that prevent anything? It doesn't prevent anything. SPF records don't prevent anyone attempting to forge email. Of course, if you publish an SPF record with +all, then nobody here is going to argue that I shouldn't bounce email into your domain, are they? And, my guess is that domains with such records are going to find it hard to deliver email to anyone. In the end, it will be equivalent to publishing an SPF record with "-all". And, it's not all or nothing. The more liberal your SPF record, the sooner you'll find that people stop accepting ANY email from you. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:16:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A7F28C196; Mon, 19 Jan 2009 03:16:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA7D28C196 for ; Mon, 19 Jan 2009 03:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 lQVaITGbwkDK for ; Mon, 19 Jan 2009 03:16:35 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A83CF28C140 for ; Mon, 19 Jan 2009 03:16:35 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50528) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPU3Z-0009KC-HC for asrg@irtf.org; Mon, 19 Jan 2009 11:19:11 +0000 Date: Mon, 19 Jan 2009 11:16:19 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <1232036000.32316.296.camel@tardis.isode.net> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> Originator-Info: login-token=Mulberry:01xu0UoS9OggYHWmgDMhM5YocULGU1+ykTO1g=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 15 January 2009 16:13:20 +0000 David Wilson wrote: > On Thu, 2009-01-15 at 14:57 +0000, Ian Eiloart wrote: >> > Depends on what that prevention requires. ("Sure you can prevent >> abuse >> > of your domain. You just need to enter into a bilateral agreement >> with >> > every receiving mailhost on the net.") >> >> No, you just need to sign your outgoing email, and publish SPF >> records. > > And make sure that you send from hosts which are permitted by your SPF > info. > > At one point I purchased on-line from Maplin, so they send me marketing > messages. maplin.co.uk has SPF information, but these messages are not > sent from one of the permitted hosts! And, right now, they don't much care about that. Why? Because too few people respect SPF records. I'll bet that if, say, a couple of the major email service providers, or all .gov or .gov.uk addresses started to do so, then Maplin would start to get that right. > > I have also seen an SPF failure on a message from a friend who has a > 'vanity' domain for their family. The message came via their ISP's MTA, > and so failed as this is not permitted by their SPF info. In this case > the SPF info has probably been created by the domain registration > organization. They'll need to get their SPF records right. We probably need better tools to enable this. > > > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:34:15 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED8228C1A0; Mon, 19 Jan 2009 03:34:15 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566E828C1A0 for ; Mon, 19 Jan 2009 03:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] 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 9XgBQEsfOytg for ; Mon, 19 Jan 2009 03:34:13 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 02AB928C19E for ; Mon, 19 Jan 2009 03:34:12 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50663) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPUXC-000H1R-M8 for asrg@irtf.org; Mon, 19 Jan 2009 11:36:49 +0000 Date: Mon, 19 Jan 2009 11:33:56 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <83AC5E40AC3FE7BD13C6E434@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090115234518.GB31038@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> Originator-Info: login-token=Mulberry:01YkqbtMurCRmjt+8WznDVvw4nyMK8DsVw17U=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 15 January 2009 18:45:18 -0500 Rich Kulawiec wrote: > On Thu, Jan 15, 2009 at 04:13:20PM +0000, David Wilson wrote: >> On Thu, 2009-01-15 at 14:57 +0000, Ian Eiloart wrote: >> > > Depends on what that prevention requires. ("Sure you can prevent >> > abuse >> > > of your domain. You just need to enter into a bilateral agreement >> > with >> > > every receiving mailhost on the net.") >> > >> > No, you just need to sign your outgoing email, and publish SPF >> > records. >> >> And make sure that you send from hosts which are permitted by your SPF >> info: > > This still isn't enough to prevent abuse of your domain. Let's make > three assumptions, two of which (I think) you're advocating: > > 1. Lots and lots of hosts that are backscattering today don't > fix the fundamental problem (that is, they continue to allow > their systems to bounce instead of rejecting). Given how > many mail system operators don't even know what backscatter, > aka outscatter, is, and that some have openly declared themselves > "required" to send it, this seems better-than-plausible. True. I think there's a real need for serious education in how to manage email systems. I don't know of any formal course or qualification that you can take. Peer pressure can be effective, though. We've seen, for example, the end of open relays. We've also seen a lot of providers take up MSA - which is also essential to the plan. > 2. Lots and lots of hosts adopt something like SPF. Yep. > 3. You -- the keeper of example.com -- set up something like SPF. Yep. > (Don't take any of this as an endorsement of SPF.) OK :) > Let's press on and have some fun with example.com, by way of > illustrating what I said above: There's no point to what you describe below, except to create a DoS attack on the MX host. Why? Because the messages won't get delivered to sites that use sender verification callouts. The callouts should be acceptable when there's an SPF pass for domains that are set up properly. Callouts are typically cached, which should mitigate the attack. It could be further mitigated by use of 5.1.2 replies "Bad destination system address", which tells the caller that the domain is incorrect. That means that the DoS attack is only good for a single message from any given MTA, you don't have significant amplification. In fact, even without any of these measures, my server isn't going to amplify your attack, because I'll only bounce any message once. So, spammers should not be able to use this mechanism to deliver email. The DoS attack is an issue. Perhaps "reverse" MX records should be published, too. So, I can look up an IP address and discover whether it will accept email for a particular domain. Why go to all that trouble when you've already got a botnet that's capable of doing the damage directly? > A. I register throwaway domain a1s2d3f5g6h7.info. > > B. I arrange to have the domain hosted somewhere with, shall we > say, less than stringent oversight. > > C. I set up DNS, including SPF, for a1s2d3f5g6h7.info. > > D. I send out a kazillion messages from user@a1s2d3f5g6h7.info, > all of which will of course pass SPF checks. They're addressed > to a kazillion addresses at a kazillion domains. Maybe some > have malware attached. Maybe some have boilerplate spam content. > Maybe some are addressed to probably-don't-exist addresses. > > E. Some of the receiving MX's will reject. Some will try to bounce. > > F. And this is where step (C) comes in, because I didn't point > the MX records for a1s2d3f5g6h7.info at my own server: I pointed > them at example.com's MXs. That's where the bounces will try to go. > > Oh, sure, the MX's for example.com are rather unlikely to accept > any mail for a1s2d3f5g6h7.info, because of course they're not > configured to, but how do you think those MX's will react when > a kazillion mail systems (nearly) simultaneously all try to > open up connections on port 25 and start shoving mail at them? > G. Since I did all this using someone else's credit card, money > is really no object. Repeat steps (A) - (D) several hundred > times using diverse registrars, DNS services, hosting services, > outbound message targets, etc. > > I can make this more interesting with some optional steps: > use of botnets instead of host service, use of fast-flux DNS, > pre-selection of hosts known to backscatter for (D), and/or > making the putative sender of all these messages > user@example.com.a1s2d3f5g6h7.info, which will confuse > the hell out of a significant subset of people. > > Yes, this behavior will probably get each one of those domains > and originating IP addresses of mine noticed and listed on various > DNSBLs and RHSBLs relatively quickly, not that this will be > much consolation to example.com while they're recovering > from the DDoS attack. > > This is one of the more benign possible scenarios. And yes, there > are all kinds of ways to counter this particular one, but my general > point is that anything that lets third parties cause someone's mail > system to emit outbound SMTP traffic to arbitrary destinations is a > cause for concern...which is why I think one of the easiest and most > productive things we could and should be doing is getting our mail > systems set up to always reject and never bounce -- or as close as > we can, modulo edge cases I've discussed elsewhere in the thread. > That doesn't really "fix" anything, per se, but at least it minimizes > ensuing secondary and tertiary consequences, and avoids adding still > more SMTP traffic to the excess we already deal with. > > ---Rsk > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:40:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7AA28C1B1; Mon, 19 Jan 2009 03:40:32 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDF028C1B0 for ; Mon, 19 Jan 2009 03:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 EurkQa1uVN+0 for ; Mon, 19 Jan 2009 03:40:30 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 83FDC28C1AB for ; Mon, 19 Jan 2009 03:40:30 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50702) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPV7U-000JRS-CR for asrg@irtf.org; Mon, 19 Jan 2009 11:43:06 +0000 Date: Mon, 19 Jan 2009 11:40:13 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090116141418.GC29881@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> <1232094768.3259.1.camel@bravo.isode.net> <20090116141418.GC29881@gsp.org> Originator-Info: login-token=Mulberry:01fRiKY+Z5+Mi+hd7F6T7wjf3W45CrveA+8oM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 16 January 2009 09:14:18 -0500 Rich Kulawiec wrote: > On Fri, Jan 16, 2009 at 08:32:48AM +0000, David Wilson wrote: >> My point was not that this would prevent abuse of your domain. Rather >> that it is stupid to register information which is intended to go some >> way to prevent domain abuse, and then send messages which appear to be >> such abuse. > > An SMTP reject is not a mail message. > > But more broadly, you could have stopped after the first clause: > *nothing* you register will prevent domain abuse if someone (or something) > is determined to inflict it, since whatever you've done can simply be > ignored (and probably will be). Besides, domain abuse is not a systemic, > persistent problem; spam, including backscatter/outscatter as one of > its variants, is, which is why (I believe) this RG exists. The problem is with spam. However, the natural response of email users is to say "can you block (or whitelist) email from such and such a domain"? Currently there's little point because it's so hard to determine whether the sender address is a forgery. I'd love to whitelist all .ac.uk addresses, because we do a lot of critical business with users of those domains, they can't be freely registered, and I know how to contact administrators of those domains. And, I've been asked to do so. Spammers would love me to do that, too. > That said, one of the best, easiest, and cheapest ways to gain free > assistance with abuse of one's domain is to maintain the "abuse" address, > per RFC 2142 (which dates from 1997). I'm often struck by what byzantine > schemes are proposed (for abuse control) while this simple measure goes > almost entirely overlooked. (Note for example yesterday's traffic on > Dave Farber's excellent "IP" list in re the difficulties of contacting > Facebook's abuse/fraud group.) Agreed. Of course abuse and postmaster email addresses can be quite hard to monitor, since they can get a lot of spam. > ---Rsk > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:52:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620DC3A693F; Mon, 19 Jan 2009 03:52:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973A13A69F1 for ; Mon, 19 Jan 2009 03:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 Q2+JSEtHHnTA for ; Mon, 19 Jan 2009 03:52:36 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 752AA3A693F for ; Mon, 19 Jan 2009 03:52:36 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50790) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPVS0-00022V-KO for asrg@irtf.org; Mon, 19 Jan 2009 11:55:12 +0000 Date: Mon, 19 Jan 2009 11:52:20 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <118B2527E93C7F5634A119C0@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090115161716.GA21077@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <20090115161716.GA21077@gsp.org> Originator-Info: login-token=Mulberry:01Q3rL1KzbOTmE5x82r6C27z5HqfLsLqaguOU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 15 January 2009 11:17:16 -0500 Rich Kulawiec wrote: > On Thu, Jan 15, 2009 at 02:57:59PM +0000, Ian Eiloart wrote: >> Now, given that I haven't yet published SPF or DKIM records, I still get >> lots of spam bounced into my domain. Who do I blame? > > Oh, that's easy. You blame the people running badly-broken mail systems > that bounce instead of rejecting. Their IP addresses are contained > in your logs and in the headers of the backscatter you're getting. Well, that's the traditional answer. However, I don't now think that it's reasonable. I *could* be publishing SPF records to tell them that the email isn't from me, but I'm not. I MUST shoulder some of the responsibility. > > Fixing this problem is a straightforward exercise modulo a few edge > cases -- but the practical impact of those edge cases can be minimized > by judicious use of simple tools and procedures (e.g., cron, make, rsync). > > (Example: one of the common problems of this type comes up in multi-tier > mail systems lacking LDAP or another directory service. The problem > arises when an address becomes invalid on the internal system but is > still considered valid on the external MXs. One easy solution to > this is to use a script to grab the current-list-of-valid-addresses > from the internal system at intervals, process it, and then rsync > it out to the external MX's. This reduces possible backscatter due > to this problem to "the set of recently-removed addresses" and further > to "the subset of those receiving forged-sender mail during the > interval between updates". It's thus possible to reduce the > probability of backscatter arbitrarily by reducing the interval.) > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 03:55:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF34028C19E; Mon, 19 Jan 2009 03:55:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E528928C19B for ; Mon, 19 Jan 2009 03:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] 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 9q90Q0Aiw3SQ for ; Mon, 19 Jan 2009 03:55:23 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id F310928C15B for ; Mon, 19 Jan 2009 03:55:22 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50812) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPVWN-0003AH-4N for asrg@irtf.org; Mon, 19 Jan 2009 11:57:59 +0000 Date: Mon, 19 Jan 2009 11:55:06 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> Originator-Info: login-token=Mulberry:01n7MVZggUg8vgIGnIC9kSKIjZBSs2wALZFB4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 16 January 2009 10:00:17 -0800 SM wrote: > At 03:45 16-01-2009, Ian Eiloart wrote: >> Now, what I'm suggesting (not advocating yet, because I'm not >> certain that this is right), is that when there's no SPF record >> published, that we should not feel too bad about bouncing email >> because the domain administrator isn't taking adequate steps to >> protect the domain against spam blowback, and against phishing. Of >> course, I'm NOT suggesting that lack of an SPF record should score >> very high in any any spamicity measure, but it might count for something. > > What does SPF have to do with phishing? Er, a lot. Would you rather bank with an organisation that published SPF records, or not? I know I would. I'd also like an email client that tells me when the From: header domain doesn't match the return-path domain. > > I prefer to take adequate steps to prevent "invalid" bounces. It helps > me if the postmaster takes adequate steps for me to determine what is > valid. Some people do not use SPF due to its restrictions on email usage. > >> Now, an SPF or DKIM match gives us the huge gain that we can bounce >> messages selectively based on the content. Some recipients may not >> want certain message content, but by the > > DKIM-signed messages coming through this mailing list cannot be verified. > > Regards, > -sm > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 04:06:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147373A68FD; Mon, 19 Jan 2009 04:06:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473D63A68FD for ; Mon, 19 Jan 2009 04:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jj7j-gO-NUA7 for ; Mon, 19 Jan 2009 04:06:34 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 726AC3A6831 for ; Mon, 19 Jan 2009 04:06:34 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0JC6Hjr014866 for ; Mon, 19 Jan 2009 07:06:18 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0JBvGIm023107 for ; Mon, 19 Jan 2009 06:57:17 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0JC6B4X018790 for ; Mon, 19 Jan 2009 07:06:11 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0JC6BWc018781 for asrg@irtf.org; Mon, 19 Jan 2009 07:06:11 -0500 Date: Mon, 19 Jan 2009 07:06:11 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090119120611.GA14837@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090115234518.GB31038@gsp.org> <83AC5E40AC3FE7BD13C6E434@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <83AC5E40AC3FE7BD13C6E434@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 11:33:56AM +0000, Ian Eiloart wrote: > There's no point to what you describe below, except to create a DoS > attack on the MX host. Why? Because the messages won't get delivered to > sites that use sender verification callouts. We can stop right there. It's fairly well known that such callouts are inherently abusive, and should never be used. Please see the copious discussion in the archives of spam-l, where this has been covered extensively. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 04:29:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3829928B56A; Mon, 19 Jan 2009 04:29:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250303A6821 for ; Mon, 19 Jan 2009 04:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.378 X-Spam-Level: X-Spam-Status: No, score=-5.378 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_MED=-4] 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 OF4vzdFyMd84 for ; Mon, 19 Jan 2009 04:29:07 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 1B4D13A68B3 for ; Mon, 19 Jan 2009 04:29:07 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0JCSmCg026890 for ; Mon, 19 Jan 2009 07:28:50 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0JCJlJV014560 for ; Mon, 19 Jan 2009 07:19:47 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0JCSgJ5025233 for ; Mon, 19 Jan 2009 07:28:42 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0JCSg31025232 for asrg@irtf.org; Mon, 19 Jan 2009 07:28:42 -0500 Date: Mon, 19 Jan 2009 07:28:42 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090119122842.GA22164@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 11:16:19AM +0000, Ian Eiloart wrote: > And, right now, they don't much care about that. Why? Because too few > people respect SPF records. I'll bet that if, say, a couple of the major > email service providers, or all .gov or .gov.uk addresses started to do > so, then Maplin would start to get that right. You seem to think that SPF is a good idea. It's not. There's a reason why the earliest and most prolific adopters were spammers, and it's most certainly not because it stops spam. There's also a reason why it's been abandoned by some rather large operations who rolled it out at some point in the past. The days when sending bounces was acceptable are fading into the distance. Attempts to preserve them are doomed by the ability of bad actors to redirect that traffic to destinations of their choosing and thus to enlist bystanders in DoS and other attacks. I think in part this is because the community is slowly realizing a general principle: anything that allows third parties to cause them to generate outbound traffic to arbitrary destinations is a bad idea. (This applies to much more than mail, but since that's our focus here...) SPF belongs on the same scrap heap with C/R, SAV, e-postage, and other pre-failed ideas that are one or more of (a) abusive (b) ineffective (c) unworkable or (d) attack vectors. And I think we've already extracted from it all the lessons we're going to learn about *why* it's a failure, so let's move on to something -- anything -- that might have a chance. Whatever-it-is might also turn out to be worthless, but at least we may learn something new from it. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 05:03:11 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12BC28C19F; Mon, 19 Jan 2009 05:03:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FAA3A6A48 for ; Mon, 19 Jan 2009 05:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, MANGLED_SAVELE=2.3] 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 fvQo8ajs7s+f for ; Mon, 19 Jan 2009 05:03:08 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 788223A67FD for ; Mon, 19 Jan 2009 05:03:08 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51361) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDPZ1I-0007YK-EZ for asrg@irtf.org; Mon, 19 Jan 2009 13:05:42 +0000 Date: Mon, 19 Jan 2009 13:02:49 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090119122842.GA22164@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> Originator-Info: login-token=Mulberry:01pSyOYA6N/MXmmeLCEVIYoQHTC6SvughSGpc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 07:28:42 -0500 Rich Kulawiec wrote: > On Mon, Jan 19, 2009 at 11:16:19AM +0000, Ian Eiloart wrote: >> And, right now, they don't much care about that. Why? Because too few >> people respect SPF records. I'll bet that if, say, a couple of the major >> email service providers, or all .gov or .gov.uk addresses started to do >> so, then Maplin would start to get that right. > > You seem to think that SPF is a good idea. It's not. There's a reason > why the earliest and most prolific adopters were spammers, and it's > most certainly not because it stops spam. It's because it increases deliverability of email, but that's indiscriminate and needs to be combined with an effective reputation service for email domains. The reputation service would make spf less attractive for spammers, and more attractive for the rest of us. SPF on it's own does little. SPF + DKIM a good reputation management system could achieve a lot. > There's also a reason why > it's been abandoned by some rather large operations who rolled it out at > some point in the past. > The days when sending bounces was acceptable are fading into the distance. Yes, and that's a bad thing. It's bad that spammers have made an effective notification system virtually unusable. However, it's the spam that's the root problem. We shouldn't be throwing the baby out with the bathwater, we should be trying to reclaim SMTP so that we can use it as it was designed. That means getting effective accountability into the system. Certainly, if we were starting from scratch, then SPF would be a part of the system, and forwarding mechanisms would have accounted for SPF. That's where we need to get to. The question is how do we get there from here? > Attempts to preserve them are doomed by the ability of bad actors to > redirect that traffic to destinations of their choosing and thus to > enlist bystanders in DoS and other attacks. I think in part this is > because the community is slowly realizing a general principle: anything > that allows third parties to cause them to generate outbound traffic to > arbitrary destinations is a bad idea. (This applies to much more than > mail, but since that's our focus here...) > SPF belongs on the same scrap heap with C/R, SAV, e-postage, and other > pre-failed ideas that are one or more of (a) abusive (b) ineffective > (c) unworkable or (d) attack vectors. And I think we've already extracted > from it all the lessons we're going to learn about *why* it's a failure, > so let's move on to something -- anything -- that might have a chance. > Whatever-it-is might also turn out to be worthless, but at least we may > learn something new from it. > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 06:07:34 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12A73A68F4; Mon, 19 Jan 2009 06:07:34 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66773A68F4 for ; Mon, 19 Jan 2009 06:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Fz3+ERn+wkWZ for ; Mon, 19 Jan 2009 06:07:32 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id AD8353A67E5 for ; Mon, 19 Jan 2009 06:07:32 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so2981911wfg.7 for ; Mon, 19 Jan 2009 06:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GIKf6wzY9nak13/oh3MUk9JRz7uKUDacvVPrqC6YWoA=; b=EdAlCTYoOHy3OLrwoZ1tO9Qq6Gos++j+tbdYOZU8Lj3Xps/qGr2rh9bw0oY7ffz7K2 s7gNt/lqGNM/iB7bjlo5Mp84Fg4/tOb4nQP36lcmlzSzkgm5P/qYX+YG4AWDTNF0Z3KR r5CkBrtsf9grYXGKGxQL8WnKzXdwjrXBZx75w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uSR3eenfh7j+b+d5ivuZO8vQbAksrzneymd6ygM0ghQ1rhoaHUTLQBB22Z/OJhCuEw C10sMQ6XWQskDE4QNZB06XkuMzTb43JyFrWSLTAURW74YopGHwYQwbK/wu93C/aMHdUB FP1Xmqf+U93yb9beW30MrJTzwypshf4RP79O4= Received: by 10.143.157.12 with SMTP id j12mr2004713wfo.213.1232374036727; Mon, 19 Jan 2009 06:07:16 -0800 (PST) Received: by 10.142.126.17 with HTTP; Mon, 19 Jan 2009 06:07:16 -0800 (PST) Message-ID: <7ae58c220901190607o3dd74667m9c52cdfed0cf1d@mail.gmail.com> Date: Mon, 19 Jan 2009 09:07:16 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 6:55 AM, Ian Eiloart wrote: > > > --On 16 January 2009 10:00:17 -0800 SM wrote: > >> At 03:45 16-01-2009, Ian Eiloart wrote: >>> >>> Now, what I'm suggesting (not advocating yet, because I'm not >>> certain that this is right), is that when there's no SPF record >>> published, that we should not feel too bad about bouncing email >>> because the domain administrator isn't taking adequate steps to >>> protect the domain against spam blowback, and against phishing. Of >>> course, I'm NOT suggesting that lack of an SPF record should score >>> very high in any any spamicity measure, but it might count for something. >> >> What does SPF have to do with phishing? > > Er, a lot. Would you rather bank with an organisation that published SPF > records, or not? I know I would. > > I'd also like an email client that tells me when the From: header domain > doesn't match the return-path domain. > >> >> I prefer to take adequate steps to prevent "invalid" bounces. It helps >> me if the postmaster takes adequate steps for me to determine what is >> valid. Some people do not use SPF due to its restrictions on email usage. >> >>> Now, an SPF or DKIM match gives us the huge gain that we can bounce >>> messages selectively based on the content. Some recipients may not >>> want certain message content, but by the >> >> DKIM-signed messages coming through this mailing list cannot be verified. >> >> Regards, >> -sm >> _______________________________________________ >> Asrg mailing list >> Asrg@irtf.org >> http://www.irtf.org/mailman/listinfo/asrg > > > > -- > Ian Eiloart > IT Services, University of Sussex > x3148 Ian, While I appreciate your ardent fervor in support of SPF and DKIM, it would appear that your practical experience is somewhat limited. For the domains I'm responsible for I've sent 700 million+ DKIM signed messages and in excess of 1 billion messages since changing the SPF records for these domains to end with -all. While I am supportive of both these approaches, I recognize that there are specific ways that breakage occurs for otherwise legitimate mail. There has been plenty of discussion on these issues on other lists such as spf-discuss and ietf-dkim. Your analysis of whether and how domains should implement these approaches is somewhat simplistic and as you point out above, you don't even eat the dog food that you advocate others should. An exercise you might engage in.... what types of breakage occur when a domain publishes -all at the end of their SPF record (Assuming that receivers respect the published record and act accordingly)? What sorts of breakage occurs for messages from a domain assuming they were able to communicate that they sign all messages for a particular domain? Just a few thoughts. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 06:33:03 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59ABE3A6B6B; Mon, 19 Jan 2009 06:33:03 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A7A28C113 for ; Mon, 19 Jan 2009 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] 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 2yNv-PddMAf3 for ; Mon, 19 Jan 2009 06:33:01 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A4C653A6B6B for ; Mon, 19 Jan 2009 06:33:01 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52139) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDQ37C-000KI6-37 for asrg@irtf.org; Mon, 19 Jan 2009 14:35:36 +0000 Date: Mon, 19 Jan 2009 14:32:42 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <867E6E37B84E1C866B43DFF3@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220901190607o3dd74667m9c52cdfed0cf1d@mail.gmail.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <7ae58c220901190607o3dd74667m9c52cdfed0cf1d@mail.gmail.com> Originator-Info: login-token=Mulberry:01a92mb9Q+FNSsSvrR1wPeUhni0VXHyc4D4Eg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 09:07:16 -0500 Dotzero wrote: > > Ian, > > While I appreciate your ardent fervor in support of SPF and DKIM, it > would appear that your practical experience is somewhat limited. For > the domains I'm responsible for I've sent 700 million+ DKIM signed > messages and in excess of 1 billion messages since changing the SPF > records for these domains to end with -all. > > While I am supportive of both these approaches, I recognize that there > are specific ways that breakage occurs for otherwise legitimate mail. > There has been plenty of discussion on these issues on other lists > such as spf-discuss and ietf-dkim. Yes, I'm aware of the discussions. However, I'm also aware that email is already very broken in many ways. We seem to be stuck in a place where we can't move for fear of breaking something, even if the place we want to go would be so much better than where we are. > Your analysis of whether and how domains should implement these > approaches is somewhat simplistic and as you point out above, you > don't even eat the dog food that you advocate others should. Yes, I think I said that I'm engaged in discussing an idea, rather than advocating it. Probably I've actually said both things. > An exercise you might engage in.... what types of breakage occur when a > domain publishes -all at the end of their SPF record (Assuming that > receivers respect the published record and act accordingly)? That, I'm certainly not yet advocating. I'm suggesting that publication of records, even with "~all", is a huge step forward. It'll improve deliverability of properly submitted emails in domains that are able to maintain good reputation. That'll encourage deployment of proper MSA servers. It'll encourage deployment of MSA and DKIM compatible forwarding services, because they'll be more successful. Eventually, we'll end up in a place where more and more admins are happy to publish, and respect "-all" records. Heck, I might even suggest that the UK (just cos that's where I am) should legislate that financial services organisations (those regulated by the Financial Services Authority) MUST publish SPF records and sign their outgoing email. > What sorts of breakage occurs for messages from a domain assuming they were > able to communicate that they sign all messages for a particular > domain? > > Just a few thoughts. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 06:44:32 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18FE3A6B95; Mon, 19 Jan 2009 06:44:31 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DE93A6B94 for ; Mon, 19 Jan 2009 06:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ts1sUmjKLy-J for ; Mon, 19 Jan 2009 06:44:30 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 08EFE3A69F1 for ; Mon, 19 Jan 2009 06:44:29 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0JEiDl8027214 for ; Mon, 19 Jan 2009 09:44:13 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0JEZCKc004086 for ; Mon, 19 Jan 2009 09:35:12 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0JEi7pD017019 for ; Mon, 19 Jan 2009 09:44:07 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0JEi5Q6017014 for asrg@irtf.org; Mon, 19 Jan 2009 09:44:05 -0500 Date: Mon, 19 Jan 2009 09:44:05 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090119144404.GA16377@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 01:02:49PM +0000, Ian Eiloart wrote: >> The days when sending bounces was acceptable are fading into the distance. > > Yes, and that's a bad thing. It's bad that spammers have made an > effective notification system virtually unusable. I don't see a problem here that needs solving. Rejects are far more efficient, and have two huge advantages: (a) they don't generate more largely-worthless SMTP traffic at a time when we're drowning in largely-worthless SMTP traffic (b) they're much harder to co-opt for abusive purposes. [1] There are other areas where the damage spammers have done (or are likely to do when it suits their purposes) is much more of an issue. And it's certainly not worth trying to salvage a fundamentally-broken technology like SPF in order to fix a problem we don't have. ---Rsk [1] And in most of the scenarios I've worked through where they *could* be co-opted, they're a distant third or fourth choice, because attackers in a position to carry those approaches out will quite likely already have preferable means at their disposal. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 07:30:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B563A6857; Mon, 19 Jan 2009 07:30:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6953A6A1D for ; Mon, 19 Jan 2009 07:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ms5Q3W5SZ9Zw for ; Mon, 19 Jan 2009 07:30:25 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 8EE1F3A6774 for ; Mon, 19 Jan 2009 07:30:25 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3014647wfg.7 for ; Mon, 19 Jan 2009 07:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LimyT0aafB4jH0vsp+GErrXTrFkzq7dwagr+QyGtANE=; b=X9dm+jzYYxt2Cl0ioSrWf7VN52OBqaOjXbCDR0gUzIZIOVJHYJWDezd9wWR1mZ/jWg 1tsFRkaU9/NSpTuug3umvQjA2L7+fHZV9wsYimZIxyMtiFj16vWVkMa0BO75wSdMQCPF o0pQs2mzZMiMAW2RLQSOlIkWLYOHQc8jnXgP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pbb7/JkIhpF+zOhDHEAelkvFAgt3HN1fzitsIdxSaCgFtFfWsKRYAr65XIx4tEaa89 AKfsuyMkixURjl1hOCT1RqdB3j7QhQzdYAejNDtA4lphsSdmyfvJiTRMihFQK/UFYQoY dAuNZN/+8X15Jm0WYrXgba4gmGGqOU+k7hnoA= Received: by 10.142.134.17 with SMTP id h17mr2405035wfd.284.1232379008348; Mon, 19 Jan 2009 07:30:08 -0800 (PST) Received: by 10.142.126.17 with HTTP; Mon, 19 Jan 2009 07:30:08 -0800 (PST) Message-ID: <7ae58c220901190730t5d7f3c59ncd586d244111c591@mail.gmail.com> Date: Mon, 19 Jan 2009 10:30:08 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <867E6E37B84E1C866B43DFF3@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <7ae58c220901190607o3dd74667m9c52cdfed0cf1d@mail.gmail.com> <867E6E37B84E1C866B43DFF3@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 9:32 AM, Ian Eiloart wrote: > > > --On 19 January 2009 09:07:16 -0500 Dotzero wrote: > >> >> Ian, >> >> While I appreciate your ardent fervor in support of SPF and DKIM, it >> would appear that your practical experience is somewhat limited. For >> the domains I'm responsible for I've sent 700 million+ DKIM signed >> messages and in excess of 1 billion messages since changing the SPF >> records for these domains to end with -all. >> >> While I am supportive of both these approaches, I recognize that there >> are specific ways that breakage occurs for otherwise legitimate mail. >> There has been plenty of discussion on these issues on other lists >> such as spf-discuss and ietf-dkim. > > Yes, I'm aware of the discussions. However, I'm also aware that email is > already very broken in many ways. We seem to be stuck in a place where we > can't move for fear of breaking something, even if the place we want to go > would be so much better than where we are. > Note that I did not talk about breakage in general, I pointed out that there are very specific ways in which mail breaks for each of these approaches. I'm not speaking theoretically. As I pointed out, domains I'm responsible for have sent a nontrivial amount of mail under both of these approaches. Given that these domains have been heavily abused we have accepted the tradeoff between reduced abuse vs breakage of otehrwise legitimate mail. This tradeoff may not make sense for other domains. I reiterate, I am speaking as someone who as already implemented. >> Your analysis of whether and how domains should implement these >> approaches is somewhat simplistic and as you point out above, you >> don't even eat the dog food that you advocate others should. > > Yes, I think I said that I'm engaged in discussing an idea, rather than > advocating it. Probably I've actually said both things. > Might I ask why you are not publishing SPF records that end in -all or signing DKIM for all the email from your domains? >> An exercise you might engage in.... what types of breakage occur when a >> domain publishes -all at the end of their SPF record (Assuming that >> receivers respect the published record and act accordingly)? > > That, I'm certainly not yet advocating. I'm suggesting that publication of > records, even with "~all", is a huge step forward. It'll improve > deliverability of properly submitted emails in domains that are able to > maintain good reputation. Why is ~all a huge step forward? What do you expect receivers to do with mail from domains that make an assertion that translates to "I don't really know where legitimate email purporting to be from my domain eminates from"? >That'll encourage deployment of proper MSA > servers. It'll encourage deployment of MSA and DKIM compatible forwarding > services, because they'll be more successful. DKIM is not path based. >Eventually, we'll end up in a > place where more and more admins are happy to publish, and respect "-all" > records. > You appear to beleive that DKIM is dependent on SPF. > Heck, I might even suggest that the UK (just cos that's where I am) should > legislate that financial services organisations (those regulated by the > Financial Services Authority) MUST publish SPF records and sign their > outgoing email. > I might suggest that you check with the mail and abuse folks at financial organizations and ask what issues they are encountering. >> What sorts of breakage occurs for messages from a domain assuming they > > were >> >> able to communicate that they sign all messages for a particular >> domain? >> >> Just a few thoughts. >> _______________________________________________ >> Asrg mailing list >> Asrg@irtf.org >> http://www.irtf.org/mailman/listinfo/asrg > > > > -- > Ian Eiloart > IT Services, University of Sussex > x3148 > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 07:32:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246783A6844; Mon, 19 Jan 2009 07:32:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B373A6774 for ; Mon, 19 Jan 2009 07:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.13 X-Spam-Level: X-Spam-Status: No, score=-9.13 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 TXynlLFQvcz7 for ; Mon, 19 Jan 2009 07:32:52 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 8304D3A6844 for ; Mon, 19 Jan 2009 07:32:52 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA26938; Mon, 19 Jan 2009 10:32:25 -0500 (EST) From: der Mouse Message-Id: <200901191532.KAA26938@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 19 Jan 2009 10:24:40 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <1231780846.29802.3.camel@squonk.lboro.ac.uk> <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > a) when a message has two or more local recipients, you can't have > different policies for each recipient about what to reject. Sure you can. You just need to push that information to your border so you can 4xx all recipients whose rejection policies differ sufficiently from those of the first 2xxed recipient. (Where differing "sufficiently" means differing in ways such that the SMTP body contents could cause them to make different rejection decisions.) > There are some workarounds, but they're kludgy and cause their own > problems. I implemented the above, once. The only problem I saw was when accepting mail from broken MUAs that tried to send not with SMTP but with some ill-defined SMTPish protocol in which a 4xxed recipient meant the mail had failed entirely. Even if you have to accommodate such brokenware, all this means is that you mustn't do differential recipient rejection for MUA submissions. Unless you know of an MTA that misbehaves that badly? > b) when you reject a message you can try to explain why, but often > the sending MTA will throw away some or all of your explanation. And that's your problem...why? There are lots of ways that information could get lost. The end user could ignore the bounce, too, or may not be competent to read the language you generate it in. > If you generate a bounce, you have full control of what the bounce > recipient sees. For example, you could include an explanation of why > they should lobby their domain controller to publish SPF records. And you really think that anyone who doesn't already grok bounces is going to have any clue what you're going on about? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 07:38:58 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710E93A6A07; Mon, 19 Jan 2009 07:38:58 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9213A6A07 for ; Mon, 19 Jan 2009 07:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] 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 r2TvV5DPxLmJ for ; Mon, 19 Jan 2009 07:38:57 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A97553A6774 for ; Mon, 19 Jan 2009 07:38:56 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52894) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDQ699-0001TZ-IR for asrg@irtf.org; Mon, 19 Jan 2009 15:41:33 +0000 Date: Mon, 19 Jan 2009 15:38:39 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090119144404.GA16377@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> Originator-Info: login-token=Mulberry:01me/5OQJQZ57aXE2bBRUMZGys/2cak/wVDlo=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 09:44:05 -0500 Rich Kulawiec wrote: > On Mon, Jan 19, 2009 at 01:02:49PM +0000, Ian Eiloart wrote: >>> The days when sending bounces was acceptable are fading into the >>> distance. >> >> Yes, and that's a bad thing. It's bad that spammers have made an >> effective notification system virtually unusable. > > I don't see a problem here that needs solving. Rejects are far more > efficient, and have two huge advantages: (a) they don't generate > more largely-worthless SMTP traffic at a time when we're drowning in > largely-worthless SMTP traffic (b) they're much harder to co-opt > for abusive purposes. [1] I agree, but bounces have two huge advantages, 1. You can bounce selectively. IE, you can accept a message for one recipient, while bouncing it for another, even after seeing the content. So, you can have different delivery policies for different people. 2. The content of the bounce message is generated by the MTA that made the decision. Therefore, it can contain content that's easier to understand. So, you may not agree that the balance is in favour of bouncing, but it certainly would be better to bounce if you KNOW that the sender address is not forged - regardless of how you know that. In fact, we adopt that policy when we know that the sender is local and authenticated. Because most mail clients are very unhelpful when you reject their mail submissions. > There are other areas where the damage spammers have done (or are likely > to do when it suits their purposes) is much more of an issue. And it's > certainly not worth trying to salvage a fundamentally-broken technology > like SPF in order to fix a problem we don't have. It's not fundamentally broken. It's a tool that has some useful applications, even if you can use it to shoot yourself in the foot. For example, two organisations that want to improve their email communications could agree to deploy SPF and whitelist each other when SPF passes happen. It'll work better when they also ensure that their users use their message submission services, and when their networks are secure, and when they can easily contact each others administrators. That works because they trust each other, and because they can now reliably associate the domain with the organisation under certain circumstances (with SPF passes). The trust model can be extended through domain reputation servers. Is there any other way to do this, that doesn't involve publishing information that says where my email can originate, or signing outbound email? > ---Rsk > > [1] And in most of the scenarios I've worked through where they *could* > be co-opted, they're a distant third or fourth choice, because attackers > in a position to carry those approaches out will quite likely already have > preferable means at their disposal. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 07:40:06 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC27928C156; Mon, 19 Jan 2009 07:40:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3293A6A3B for ; Mon, 19 Jan 2009 07:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.159 X-Spam-Level: X-Spam-Status: No, score=-9.159 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 n1xlhv22LYNP for ; Mon, 19 Jan 2009 07:40:03 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 74A143A69AC for ; Mon, 19 Jan 2009 07:40:03 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA26989; Mon, 19 Jan 2009 10:39:47 -0500 (EST) From: der Mouse Message-Id: <200901191539.KAA26989@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 19 Jan 2009 10:32:58 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <9A6505ABB645EDF6F7FA1806@lewes.staff.uscs.susx.ac.uk> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <247EE1376A7242596A2EA210@lewes.staff.uscs.susx.ac.uk> <20090112170222.CE499241DC@panix5.panix.com> <9A6505ABB645EDF6F7FA1806@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> They aren't responsible to sign up for Clever-Idea-Of-The-Week and >> implement whatever makes your life easier. > But, primarily it make the domain owner's life easier. In two ways. > First, they will get less collateral spam into their mailboxes. > Second, they will find that their email becomes more deliverable. Will they? Where are the numbers? I suspect both may actually be false, given how spammers adopted SPF with greater eagerness than other senders. A practical statistician without an axe to grind over SPF would see a positive correlation between SPF presence and spamminess, causing senders with SPF to see lower deliverability. Less collateral spam is less clear, depending on what counts as "collateral" spam, but I suspect the lower deliverability from recipients who've noticed that SPF indicates higher spaminess would outweigh the benefit from recipients who are using SPF the way you seem to want it to be used. (I suspect both effects are so far down in the noise that it would require a huge sample size to tease out which way the effects actually go. If anyone has real measurements either way, I'd love to see them.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 07:56:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC5C3A6B1D; Mon, 19 Jan 2009 07:56:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8489D28C197 for ; Mon, 19 Jan 2009 07:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, GB_I_LETTER=-2] 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 76YW8sjfS8kt for ; Mon, 19 Jan 2009 07:56:46 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id B730028C190 for ; Mon, 19 Jan 2009 07:56:46 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0JFuIXS027627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jan 2009 07:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232380587; x=1232466987; bh=C21PbgUujQPX7MShEfV40SXEwRapv/CXweNr/hIk2zk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=SFBAokTBEwFwLot28VMAj+4p140zQipQzyVlz6BB5HBqWy6VtfUU0wPC3P9i4WFj5 +hgTuZY54y+Xn26rYv1D5J1bLYOfgibz8vRz21L3Nw0sI2W8B/qmoBKZuJ/a+fNeRh GlfOg0dbQs42/Yh9gSUARpZMLHfLB8l/Q8pFfKJ8= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=YxR3T1ltpLqppQSn0cekiiO0FGjcr9Lmmf5IyTC273LFcW2l0v3NoWeiNSLvwU6cr g8TKkl3QYQRNKd5k8kn+7nxibIPblBrMM4lPSdIQL1vvo4q0DPS5JDI6NZsfPAg/St3 QOOTfECNpNUQPteBtQ8EgK5nUHGGYBX7CnBJUng= Message-Id: <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Jan 2009 07:55:26 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 03:55 19-01-2009, Ian Eiloart wrote: >Er, a lot. Would you rather bank with an organisation that published >SPF records, or not? I know I would. I would prefer if my bank used a mechanism for email that protects the integrity of the content. >I'd also like an email client that tells me when the From: header >domain doesn't match the return-path domain. There are cases where the From: header may not match the Return-path domain; for example, messages from this mailing list. It's also common for web-generated email traffic but that's mainly because most users are not aware that specifying the email address for the From: header doesn't set the email address for the Return-path. The Return-path only tells us where to bounce the message. It doesn't tell us who actually sent the message. In paper communication, we use the signature and not the return address to validate authorship. When we receive a letter, we rarely look at the return address. That information is useful for the delivery service. Most people don't determine where the message originated. The only information we notice, if we have access to the envelope, is whether the letter is domestic or comes from a foreign country. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 08:54:53 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E0B3A6A04; Mon, 19 Jan 2009 08:54:53 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44E43A6A04 for ; Mon, 19 Jan 2009 08:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 B6Q9b1ivUokA for ; Mon, 19 Jan 2009 08:54:51 -0800 (PST) Received: from pmx1.sophos.com (pmx1.sophos.com [213.31.172.16]) by core3.amsl.com (Postfix) with ESMTP id 7D5303A68D0 for ; Mon, 19 Jan 2009 08:54:51 -0800 (PST) Received: from pmx1.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64D482FE871 for ; Mon, 19 Jan 2009 16:54:34 +0000 (GMT) Received: from uk-exch2.green.sophos (uk-exch2.green.sophos [10.100.199.17]) by pmx1.sophos.com (Postfix) with ESMTP id 56AFC2FE84F for ; Mon, 19 Jan 2009 16:54:34 +0000 (GMT) Received: from UK-EXCHMBX1.green.sophos ([fe80:0000:0000:0000:e1bd:d3c1:23.222.229.221]) by uk-exch2.green.sophos ([10.100.199.17]) with mapi; Mon, 19 Jan 2009 16:54:34 +0000 From: Martijn Grooten To: "asrg@irtf.org" Date: Mon, 19 Jan 2009 16:54:29 +0000 Thread-Topic: Call for papers: VB2009 conference on malware and spam Thread-Index: Acl6Vphjz6DVbkLCS6m0fdwUKR8+bg== Message-ID: <18B53BA2A483AD45962AAD1397BE132501D358C8@UK-EXCHMBX1.green.sophos> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AOZp Aegm Bgpq CBwB CXkB Ce3p DCSv Erwe FP0h Fwm3 F4AQ HKjV Hl/2 IhFX JwiQ K8QL; 1; YQBzAHIAZwBAAGkAcgB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {2A95B135-29C1-47BF-95CE-D51A25D69400}; bQBhAHIAdABpAGoAbgAuAGcAcgBvAG8AdABlAG4AQAB2AGkAcgB1AHMAYgB0AG4ALgBjAG8AbQA=; Mon, 19 Jan 2009 16:54:29 GMT; QwBhAGwAbAAgAGYAbwByACAAcABhAHAAZQByAHMAOgAgAFYAQgAyADAAMAA5ACAAYwBvAG4AZgBlAHIAZQBuAGMAZQAgAG8AbgAgAG0AYQBsAHcAYQByAGUAIABhAG4AZAAgAHMAcABhAG0A x-cr-puzzleid: {2A95B135-29C1-47BF-95CE-D51A25D69400} acceptlanguage: en-US, en-GB MIME-Version: 1.0 Subject: [Asrg] Call for papers: VB2009 conference on malware and spam X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org All, Please find at the bottom of this email a call for papers for VB2009, an international conference on (anti-)malware and (anti-)spam, two subjects that, as we all know, are far from mutually exclusive these days. In case this isn't clear from the list of suggested topics for papers linked below, any of the topics discussed here recently will be considered by the selection committee. We are looking for submissions from spam-filter vendors, researchers, system administrators and anyone else who has an opinion on anti-spam. Best Regards Martijn Grooten Virus Bulletin ---- VB2009, Geneva: Call for papers Virus Bulletin is seeking submissions from those wishing to present at VB2009, the 19th VB International Conference, which will take place from 23-25 September 2009 at the Crowne Plaza, Geneva, Switzerland. The conference will include a programme of 40-minute presentations running in two concurrent streams: Technical and Corporate. Submissions are invited on all subjects relevant to anti-malware and anti-spam. In particular, VB welcomes the submission of papers that will provide delegates with ideas, advice and/or practical techniques, and encourages presentations that include practical demonstrations of techniques or new technologies. Abstracts should be submitted via the online abstract submission system at http://www.virusbtn.com/conference/abstracts/ and must be submitted no later than FRIDAY 6th MARCH 2009. Further details of the paper submission and selection process, including a list of suggested topics for papers, can be found at http://www.virusbtn.com/conference/vb2009/call/. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 09:48:58 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32AD3A69AC; Mon, 19 Jan 2009 09:48:58 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E593A69F1 for ; Mon, 19 Jan 2009 09:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, GB_I_LETTER=-2] 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 rWiRuvwvY+ng for ; Mon, 19 Jan 2009 09:48:56 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 923C43A69E2 for ; Mon, 19 Jan 2009 09:48:55 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54159) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDQC9U-0002NQ-PQ for asrg@irtf.org; Mon, 19 Jan 2009 17:51:31 +0000 Date: Mon, 19 Jan 2009 17:48:36 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> Originator-Info: login-token=Mulberry:01vyFMzCiCujEAjqAuK0cylr8/JZltJiJHNIw=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 07:55:26 -0800 SM wrote: > At 03:55 19-01-2009, Ian Eiloart wrote: >> Er, a lot. Would you rather bank with an organisation that published >> SPF records, or not? I know I would. > > I would prefer if my bank used a mechanism for email that protects the > integrity of the content. > >> I'd also like an email client that tells me when the From: header >> domain doesn't match the return-path domain. > > There are cases where the From: header may not match the Return-path > domain; for example, messages from this mailing list. It's also common > for web-generated email traffic but that's mainly because most users are > not aware that specifying the email address for the From: header doesn't > set the email address for the Return-path. Yes, I know. Presumably your bank doesn't email you through this list or any other, though. What I'm after here is avoiding bank phishing. When communicating with my bank, I want them emailing me directly, to my current email address. I'd be just as happy if they used DKIM to sign the message. I'd still need my mail client to tell me that it was signed properly, though. And, signed by the owner of the address that I can see in the message headers. > > The Return-path only tells us where to bounce the message. It doesn't > tell us who actually sent the message. In paper communication, we use > the signature and not the return address to validate authorship. When we > receive a letter, we rarely look at the return address. That information > is useful for the delivery service. Most people don't determine where > the message originated. The only information we notice, if we have > access to the envelope, is whether the letter is domestic or comes from a > foreign country. > > Regards, > -sm > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 10:38:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317323A6834; Mon, 19 Jan 2009 10:38:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A423A6834 for ; Mon, 19 Jan 2009 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 oyheKCYU0N1X for ; Mon, 19 Jan 2009 10:38:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id D9ADA3A67E2 for ; Mon, 19 Jan 2009 10:38:06 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3094712wfg.7 for ; Mon, 19 Jan 2009 10:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=KCa3BfCiVqthcYHAgdckCwgi5E/x/jL7ajoLLbnr2pw=; b=ekYft4aoYLr2S3pKd9rbwboMDrTJSr+Y5V6EPgG2iKX07U8LI1gWcYiWVLtdwSmmr7 I9gQdw0uXBO0EJ9ozEB8mRI+FScj6kNMIRoWHY9rTBqiV4Y63C0oB2lje7eP0cdyqn6r Y0okJoB/SuduAHKMdsCks5zaasJ+7dYQ0jT3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mYeM3FFUqAWtZdCsnp54itfD/40TL40FQ3PTxon3hCeWzUUPsOmyJf734jJa/Tl0tt RY0bm6P4KMjdp4BetCcb0UageD/0NPWX/2e2Ue0cMbk4+emq7KxchZcmg8HYbWGYSNKj upN0kIAy2VNP3azMVFyLGKbyI1awmg6Dkb9JI= Received: by 10.143.10.15 with SMTP id n15mr2461399wfi.319.1232390271021; Mon, 19 Jan 2009 10:37:51 -0800 (PST) Received: by 10.142.126.17 with HTTP; Mon, 19 Jan 2009 10:37:50 -0800 (PST) Message-ID: <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> Date: Mon, 19 Jan 2009 13:37:50 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 12:48 PM, Ian Eiloart wrote: > > > --On 19 January 2009 07:55:26 -0800 SM wrote: > >> At 03:55 19-01-2009, Ian Eiloart wrote: >>> >>> Er, a lot. Would you rather bank with an organisation that published >>> SPF records, or not? I know I would. >> >> I would prefer if my bank used a mechanism for email that protects the >> integrity of the content. >> >>> I'd also like an email client that tells me when the From: header >>> domain doesn't match the return-path domain. >> >> There are cases where the From: header may not match the Return-path >> domain; for example, messages from this mailing list. It's also common >> for web-generated email traffic but that's mainly because most users are >> not aware that specifying the email address for the From: header doesn't >> set the email address for the Return-path. > > Yes, I know. Presumably your bank doesn't email you through this list or any > other, though. What I'm after here is avoiding bank phishing. When > communicating with my bank, I want them emailing me directly, to my current > email address. > > I'd be just as happy if they used DKIM to sign the message. I'd still need > my mail client to tell me that it was signed properly, though. And, signed > by the owner of the address that I can see in the message headers. > How happy will you be when your ISP checked the DKIM signature upstream from your mail client, added in x-headers showing the check (and possibly other things) and broke the signature? _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 10:46:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396873A680E; Mon, 19 Jan 2009 10:46:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EEE3A694E for ; Mon, 19 Jan 2009 10:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 07GAZhy5d3OO for ; Mon, 19 Jan 2009 10:46:22 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EC42C3A67E2 for ; Mon, 19 Jan 2009 10:46:21 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0JIk2W16609 for ; Mon, 19 Jan 2009 18:46:02 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 13:46:01 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 19 Jan 2009 13:46:01 -0500 Message-ID: <4974CA68.2010008@nortel.com> Date: Mon, 19 Jan 2009 13:46:00 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> In-Reply-To: <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> X-OriginalArrivalTime: 19 Jan 2009 18:46:01.0752 (UTC) FILETIME=[2D07F980:01C97A66] Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Dotzero wrote: > On Mon, Jan 19, 2009 at 12:48 PM, Ian Eiloart wrote: > How happy will you be when your ISP checked the DKIM signature > upstream from your mail client, added in x-headers showing the check > (and possibly other things) and broke the signature? Or, if your ISP checked SPF and DKIM, and reported the email as legit ... for a domain name very much like, but not exactly like your bank...? Even with reputation services telling you whether the domain is supposedly good, phishers generate domains so fast, and reputation services are of necessity going to have to score new ones as "neutral" at worst, it's not going to get you very far overall. We need a feasible mechanism for forcing end users to be smarter ;-) _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 11:08:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3741D28C157; Mon, 19 Jan 2009 11:08:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163A428C157 for ; Mon, 19 Jan 2009 11:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.808 X-Spam-Level: X-Spam-Status: No, score=-14.808 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 a6H-yRxbC3qy for ; Mon, 19 Jan 2009 11:08:34 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 15B283A6827 for ; Mon, 19 Jan 2009 11:08:33 -0800 (PST) Received: (qmail 3402 invoked from network); 19 Jan 2009 19:08:17 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Jan 2009 19:08:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=qBz2O35uiRffJFhBAOeqkRV+Dzzpu6n66/RVfUI/DSI=; b=Fih0JLjiefbudc6BpgtOQoPqzE45XXdCC8bHB3KkCL6l+3bUBbuT5HU5priEU7DL/Qv99Tt4D31uQ+7d1IG/4fKxPkbGUEd9sdPMoWI+59DsW/IeH4oPyKjl707QDoNdiSRvBHCztoa53uqKF8aZXwtBVf0U+BTyxGhfwW2DamI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=qBz2O35uiRffJFhBAOeqkRV+Dzzpu6n66/RVfUI/DSI=; b=ic5daQBLTQ9o/hPlYs594fBgCe4lKwhkn8miptoGty5XF8wUO6VnnWPf4lZfpZqFLBsv0ei+Hj7aDM3m+MuHhJVKMe/Xd9KqsLeajGozkIzGreLZqxlHL8yVyfTxTpETLCEkzPRcFBIhKWyXbrx1nWPgYg34hrY8d5RYgs1FM/c= Date: 19 Jan 2009 19:08:14 -0000 Message-ID: <20090119190814.38720.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >>> I'd also like an email client that tells me when the From: header >>> domain doesn't match the return-path domain. ... >Yes, I know. Presumably your bank doesn't email you through this list or >any other, though. What I'm after here is avoiding bank phishing. Have you actually looked at the mail from your bank? As likely as not, the return path points back at the ESP that sends their mail and doesn't match the From: address. Address matching is a totally ineffective way to verify the source of any mail. You also can't make many assumptions about where it will be sent from; I got a real message today from HSBC in the Channel Islands that was sent from Hong Kong. >I'd be just as happy if they used DKIM to sign the message. I'd still need >my mail client to tell me that it was signed properly, though. And, signed >by the owner of the address that I can see in the message headers. Well, yes, we all know that effective use of DKIM requires some sort of reputation system to decide what to make of the signature. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 11:13:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736CB3A6906; Mon, 19 Jan 2009 11:13:16 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC663A6906 for ; Mon, 19 Jan 2009 11:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 DPbHO6T8tB-n for ; Mon, 19 Jan 2009 11:13:14 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id C27DE3A6827 for ; Mon, 19 Jan 2009 11:13:14 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3109453wfg.7 for ; Mon, 19 Jan 2009 11:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=U9uYIr8bK9+cXV0/IGOEdJb3yn3GQqH9080wXAK/VCM=; b=X9oh847/36vtZlJTMJHucPXCFIDICLXx+KjrNCU2rARCHZKnsKvBd3bE9vBQjUpNHf 5Tf7Uq+vJpkN43f3gOeB4K+0YpIFcSx0AcrQDk93JsfJ5/28aBwBMg2JNML/wVG9xKPU TdEgtd5Z5AewRMGbGWAa0zYHNkDovoIDyF4fU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HXIUO8FR9GKuBAJ5auMsTFsKqowGlica/s9HrpKC7DiRrsf3qblV8WvON5dA4jpuwi N6rxF3CxR5lY7/9aXUlW9YkOgtaCe5/u2/cyXmOSn7YBbfNp4moVvedzndWXQixNob33 ivqwJrPWBqWFiYKk62rnKKfzhs2WQldR2s7W8= Received: by 10.142.147.15 with SMTP id u15mr2477804wfd.78.1232391879552; Mon, 19 Jan 2009 11:04:39 -0800 (PST) Received: by 10.142.126.17 with HTTP; Mon, 19 Jan 2009 11:04:39 -0800 (PST) Message-ID: <7ae58c220901191104t643dc590qa286dfc1f1a8d4f5@mail.gmail.com> Date: Mon, 19 Jan 2009 14:04:39 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <4974CA68.2010008@nortel.com> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <4974CA68.2010008@nortel.com> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 1:46 PM, Chris Lewis wrote: > > Even with reputation services telling you whether the domain is > supposedly good, phishers generate domains so fast, and reputation > services are of necessity going to have to score new ones as "neutral" > at worst, it's not going to get you very far overall. > > We need a feasible mechanism for forcing end users to be smarter ;-) If you figure that one out Chris I'll provide your beverage of choice. Personally I have come to the conclusion that once a questionable email gets to the enduser (generically) all hope is lost. This is why I have focused my efforts and thought around the MTA. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 11:50:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3312F3A6A45; Mon, 19 Jan 2009 11:50:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E133A6A45 for ; Mon, 19 Jan 2009 11:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.187 X-Spam-Level: X-Spam-Status: No, score=-9.187 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 f55fZstQ9-iY for ; Mon, 19 Jan 2009 11:50:07 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 572D33A6A29 for ; Mon, 19 Jan 2009 11:50:07 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA28940; Mon, 19 Jan 2009 14:49:35 -0500 (EST) From: der Mouse Message-Id: <200901191949.OAA28940@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 19 Jan 2009 14:44:24 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090119190814.38720.qmail@simone.iecc.com> References: <20090119190814.38720.qmail@simone.iecc.com> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Have you actually looked at the mail from your bank? Thank you for explaining so clearly why I do not, ever, do anything "online" with my bank. (Makes it really easy to identify phishes. :) Now, if they were to sign the mail with some content mechanism like PGP or S/MIME, with the key available by going to the branch in person, I might trust it. More likely not, though, since I've seen enough over my bank's personnel's shoulders to convince me they run Windows internally, so I don't trust them to manage their private key data properly either. (Of course, if they got enough clue to start doing real signatures on email, they might also grow a clue when it comes to managing their internal systems.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 12:31:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2AE3A6856; Mon, 19 Jan 2009 12:31:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D203A6856 for ; Mon, 19 Jan 2009 12:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_40=-0.185] 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 MOO0WKkNaixo for ; Mon, 19 Jan 2009 12:31:44 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by core3.amsl.com (Postfix) with ESMTP id 697DB3A67B1 for ; Mon, 19 Jan 2009 12:31:44 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id EEDA66F3966 for ; Mon, 19 Jan 2009 20:31:26 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, 7a12b6d7b887bc6e, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:854:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2194:2199:2393:2525:2559:2563:2682:2685:2705:2741:2828:2857:2859:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3636:3657:3865:3866:3867:3868:3869:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:6114:6119:6120:7602:7652:7679:7903:8501:8985:9025, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 19 Jan 2009 20:31:26 +0000 (UTC) Message-ID: <4974E31F.6010808@terabites.com> Date: Mon, 19 Jan 2009 14:31:27 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org X-session-marker: 6765703261407465726162697465732E636F6D Subject: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > I know, someone's going to tell me that SPF breaks forwarding. Well email is already broken. I get up to a million spam messages into my domain daily. Everything we do to prevent spam causes problems ranging from additional load on our DNS servers to loss of important emails. The question is, are we going to fix it? I think what I'm proposing would at least allow people to do safe whitelisting SPF breaks more than forwarding. It also harms people who occasionally need to send messages from kiosks, Internet cafes, cruise ships, international post offices, and other inhabitual locations elsewhere. I object to people expecting people to implement braindead, ill-conceived antispam strategies, just because "well, they would be efficient, if they worked right, which they don't." I agree that E-mail has serious problems, but the way to solve that isn't by putting into effect stupid, ill-designed, broken ideas just because you WISH they worked reliably. It's not enough for them to work just "some of the time", IF they also break legitimate, reasonable uses. At least not unless the intended recipient grants **informed** consent. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 12:37:19 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167C73A6892; Mon, 19 Jan 2009 12:37:19 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A239E3A690D for ; Mon, 19 Jan 2009 12:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 d5xi6BogqztQ for ; Mon, 19 Jan 2009 12:37:16 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 243373A67B1 for ; Mon, 19 Jan 2009 12:37:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id E034E64F83AE for ; Tue, 20 Jan 2009 08:37:10 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8gXNrC-X-4N for ; Tue, 20 Jan 2009 08:37:09 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id E3E5B64F839B for ; Tue, 20 Jan 2009 08:37:09 +1200 (FJT) Date: Tue, 20 Jan 2009 08:37:09 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <4559692.101232397415633.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <8789576.81232397227985.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Banks use credit card which have been proven weak. They compensate by insuring you against fraud and having a big legal department that follow the cases. That's if the bank is respectable, but they are becoming less and less.. Before you would go to a bank because they projected trust and reputation, now you have to go to the bank if you want to buy anything. Many online commerce appply filtering rules based on credit card location, IP location, and other hidden mechanism. But that's a discussion for another forum. My point is that solving email authentication, may not solve real world problems. ----- Original Message ----- From: "der Mouse" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 20 January, 2009 7:44:24 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) > Have you actually looked at the mail from your bank? Thank you for explaining so clearly why I do not, ever, do anything "online" with my bank. (Makes it really easy to identify phishes. :) Now, if they were to sign the mail with some content mechanism like PGP or S/MIME, with the key available by going to the branch in person, I might trust it. More likely not, though, since I've seen enough over my bank's personnel's shoulders to convince me they run Windows internally, so I don't trust them to manage their private key data properly either. (Of course, if they got enough clue to start doing real signatures on email, they might also grow a clue when it comes to managing their internal systems.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 12:39:42 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0993A6944; Mon, 19 Jan 2009 12:39:42 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0E63A6944 for ; Mon, 19 Jan 2009 12:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 QoJzD70KB3+2 for ; Mon, 19 Jan 2009 12:39:40 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id BCC583A691E for ; Mon, 19 Jan 2009 12:39:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 51B0164F83AE for ; Tue, 20 Jan 2009 08:39:35 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgCgx02ONL-C for ; Tue, 20 Jan 2009 08:39:34 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id E0DAE64F839B for ; Tue, 20 Jan 2009 08:39:34 +1200 (FJT) Date: Tue, 20 Jan 2009 08:39:34 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <16302945.121232397562045.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <4974E31F.6010808@terabites.com> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Let switch off the Internet, it just does not work ;) ----- Original Message ----- From: "Gordon Peterson" To: asrg@irtf.org Sent: Tuesday, 20 January, 2009 8:31:27 AM (GMT+1200) Auto-Detected Subject: [Asrg] SPF and other bad ideas > I know, someone's going to tell me that SPF breaks forwarding. Well email is already broken. I get up to a million spam messages into my domain daily. Everything we do to prevent spam causes problems ranging from additional load on our DNS servers to loss of important emails. The question is, are we going to fix it? I think what I'm proposing would at least allow people to do safe whitelisting SPF breaks more than forwarding. It also harms people who occasionally need to send messages from kiosks, Internet cafes, cruise ships, international post offices, and other inhabitual locations elsewhere. I object to people expecting people to implement braindead, ill-conceived antispam strategies, just because "well, they would be efficient, if they worked right, which they don't." I agree that E-mail has serious problems, but the way to solve that isn't by putting into effect stupid, ill-designed, broken ideas just because you WISH they worked reliably. It's not enough for them to work just "some of the time", IF they also break legitimate, reasonable uses. At least not unless the intended recipient grants **informed** consent. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 12:47:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBEA28C1D1; Mon, 19 Jan 2009 12:47:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224CC28C1C4 for ; Mon, 19 Jan 2009 12:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] 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 zGc1ZDTdgWMt for ; Mon, 19 Jan 2009 12:47:26 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by core3.amsl.com (Postfix) with ESMTP id 326AC28C1B1 for ; Mon, 19 Jan 2009 12:47:25 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 5C8DA1C53E30 for ; Mon, 19 Jan 2009 20:47:09 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, 341171326427ca14, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:854:945:967:973:988:989:1042:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2194:2199:2393:2525:2559:2563:2682:2685:2705:2731:2828:2857:2859:2861:2894:2912:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3636:3657:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:6114:6119:7652:7679:7688:7903:8501:8568:8985:9025, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf08.hostedemail.com (Postfix) with ESMTP for ; Mon, 19 Jan 2009 20:47:08 +0000 (UTC) Message-ID: <4974E6CD.3070705@terabites.com> Date: Mon, 19 Jan 2009 14:47:09 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org X-session-marker: 6765703261407465726162697465732E636F6D Subject: [Asrg] Software bashing X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > I see no reason why we should change (...snip...) in order to accomodate the thriving malware ecosystem made possible in large measure by the abysmally low quality of Microsoft products. It doesn't advance the discussion in any useful direction to condemn any given software vendor. The DOD/NSA for years has had bids out for totally "secure" operating systems and everything produced has either not been particularly secure, or hasn't been usable. If 90% of all the computer workstations were running Linux, then the virus/malware authors would be writing viruses for THAT platform. Same is true for Macs. The problems in software engineering that result in holes and exploitable bugs are NOT limited to any specific platform or hardware architecture. Besides, the problems of malware are not all due to unreliable software anyhow... phishing exploits are a good counter-example. For all their many sins (including of omission), Microsoft has probably done more than ANY other vendor to automate and accelerate the distribution of patches to correct security problems. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 12:48:40 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1BB28C196; Mon, 19 Jan 2009 12:48:40 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508AA28C196 for ; Mon, 19 Jan 2009 12:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 j7OlE0bIaqoB for ; Mon, 19 Jan 2009 12:48:37 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 72CB53A67B1 for ; Mon, 19 Jan 2009 12:48:37 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3148121wfg.7 for ; Mon, 19 Jan 2009 12:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=10A9yTVLiT/fATVph8GQg9ctE0RlYgLOb9LbPhRzf+w=; b=OXZ6S8XVL5FfRtqTh3NB3GYLEsQcE0YerwY2TipCu1jzktbb6LjzFuQNuj9lqEmnSF P+uTRtF2pF+kVaFULlmjSCnYjn1y8RuEhGaCXfTSjxkYorKR42E4e6eKZLFB4B2Ec563 v9tq7GweUCDMEALvZD4AIxx1mkSTAtw8RIq5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jfpjjzdh88cwKXIY/mnb3+vORAhhU3okutZ8+s4GS1GQ9W0d8DNrFkIWSsbBghGI6b WpFzBbtm2VAJIR+IPKx0frmrWpL5lSmAfn4VfS9tIga5GvEWLCf0V3sat8dR6oNkIOIl KNeXzGVRBhMSXrsu4ehkatCj4HIC/lAYw0PO0= Received: by 10.142.231.7 with SMTP id d7mr2509835wfh.243.1232398100537; Mon, 19 Jan 2009 12:48:20 -0800 (PST) Received: by 10.142.126.17 with HTTP; Mon, 19 Jan 2009 12:48:20 -0800 (PST) Message-ID: <7ae58c220901191248j136b9b36o2f04ffe2827d1032@mail.gmail.com> Date: Mon, 19 Jan 2009 15:48:20 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <4974E31F.6010808@terabites.com> MIME-Version: 1.0 Content-Disposition: inline References: <4974E31F.6010808@terabites.com> Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 3:31 PM, Gordon Peterson wrote: >> I know, someone's going to tell me that SPF breaks forwarding. Well email >> is already broken. I get up to a million spam messages into my domain daily. >> Everything we do to prevent spam causes problems ranging from additional >> load on our DNS servers to loss of important emails. The > question is, are we going to fix it? I think what I'm proposing would at > least allow people to do safe whitelisting > > SPF breaks more than forwarding. It also harms people who occasionally need > to send messages from kiosks, Internet cafes, cruise ships, international > post offices, and other inhabitual locations elsewhere. > > I object to people expecting people to implement braindead, ill-conceived > antispam strategies, just because "well, they would be efficient, if they > worked right, which they don't." > > I agree that E-mail has serious problems, but the way to solve that isn't by > putting into effect stupid, ill-designed, broken ideas just because you WISH > they worked reliably. > > It's not enough for them to work just "some of the time", Sure it is. But not in the sense you are using above. For example, the domains I have implemented strong SPF assertions for are website domains where with only a handful of exceptions the accounts are all role accounts associated with the functioning of the websites. For the handful of accounts used by individuals, policy is that they are not allowed to send mail from anywhere except our environment. The only breakage case in this instance is where a recipient is using a vanity domain and/or sending the mail on to another account of theirs without using something like SRS. Based on experience, the tradeoff is a small fraction of a percent of the email with this type of problem versus a very very large number of people that can be afforded additional protection from phishing attacks because the ISP or Mail Admin can identify mail that originates from us vs mail that purports to be us. If an enduser wants the flexibility to send from Kiosks or through other MTAs and their company or mail provider allows this by policy then the use of strong SPF assertions is likely inappropriate. My response to you is the old saw about the person who goes tot he doctor about a pain.... "Doctor, it hurts when I do that" ...... and the Doctor says..... "Don't do that". >IF they also break > legitimate, reasonable uses. At least not unless the intended recipient > grants **informed** consent. > Whether or not the use is legitimate or reasonable is certainly a matter for discussion. The use of SPF or DKIM is not a MUST. It is a MAY and whether it is appropriate for a particular domain or user is something that must be considered. If the owner of the domain chooses to implement these approaches and you as an individual are unhappy, then you face some choices. If it is company policy you can try to convince them to allow you to send email from wherever you want or you can conform....you might even choose to quit on principle if you feel that strongly about it. If you are a customer of an ISP/mailprovider you have similar choices except that quitting is not likely to reduce your income. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 13:45:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51013A694A; Mon, 19 Jan 2009 13:45:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74823A6934 for ; Mon, 19 Jan 2009 13:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LIX6RACvi-6U for ; Mon, 19 Jan 2009 13:45:50 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id CF9C03A6912 for ; Mon, 19 Jan 2009 13:45:49 -0800 (PST) Received: from osgood.cc.nd.edu (osgood.cc.nd.edu [129.74.250.227]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0JLgWjg032068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Jan 2009 16:42:33 -0500 Received: from [10.40.4.245] (prussell-wi.nomad.nd.edu [10.40.4.245]) (authenticated bits=0) by osgood.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id n0JLjVA8016545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jan 2009 16:45:32 -0500 (EST) Message-ID: <4974F47B.4020409@nd.edu> Date: Mon, 19 Jan 2009 16:45:31 -0500 From: Paul Russell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <1231780846.29802.3.camel@squonk.lboro.ac.uk> <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> X-Source-IP: 129.74.250.227 X-ND-MTA-Date: Mon, 19 Jan 2009 16:42:33 EST Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 1/19/2009 6:08 AM, Ian Eiloart wrote: > There are at least two very good reasons for wanting to bounce rather than > reject emails. > > a) when a message has two or more local recipients, you can't have > different policies for each recipient about what to reject. You reject for > all or no recipients. There are some workarounds, but they're kludgy and > cause their own problems. Perhaps that is true of your MTA, but we have been doing this with sendmail for several years. This is a supported feature which can be enabled or disabled by any reasonably competent system administrator. I would not describe it as a 'work-around' or a 'kludge', and it has not caused us any problems. > b) when you reject a message you can try to explain why, but often the > sending MTA will throw away some or all of your explanation. Usually, it > will wrap your explanation inside it's own. The end result is that the > recipient of the bounce message (if there is one) doesn't understand what's > going on. If you generate a bounce, you have full control of what the > bounce recipient sees. For example, you could include an explanation of why > they should lobby their domain controller to publish SPF records. Some mail servers add boilerplate text - sometimes accurate, sometime completely inaccurate - to every inbound DSN. How are you going to deal with that issue? The fact is, you cannot control the operation of every mail server that might handle your completely meaningful, easily understandable, and perfectly hand-crafted 'bounce'. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 13:54:18 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9CB3A69A0; Mon, 19 Jan 2009 13:54:18 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8123A69A0 for ; Mon, 19 Jan 2009 13:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 05MmVEeMCc+P for ; Mon, 19 Jan 2009 13:54:16 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id AF69C3A6852 for ; Mon, 19 Jan 2009 13:54:16 -0800 (PST) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0JLoxgZ013348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Jan 2009 16:50:59 -0500 Received: from [10.40.4.245] (prussell-wi.nomad.nd.edu [10.40.4.245]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0JLrwto018006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jan 2009 16:53:58 -0500 (EST) Message-ID: <4974F676.4000706@nd.edu> Date: Mon, 19 Jan 2009 16:53:58 -0500 From: Paul Russell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Mon, 19 Jan 2009 16:51:00 EST Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 1/19/2009 10:38 AM, Ian Eiloart wrote: > > I agree, but bounces have two huge advantages, > > 1. You can bounce selectively. IE, you can accept a message for one > recipient, while bouncing it for another, even after seeing the content. > So, you can have different delivery policies for different people. I know that sendmail can be configured to accept for one recipient and reject for another recipient. I assume there are other MTA products which also support this functionality. If yours does not, perhaps you should consider using a different MTA. > 2. The content of the bounce message is generated by the MTA that made the > decision. Therefore, it can contain content that's easier to understand. If your MTA cannot be configured to issue meaningful rejection messages, perhaps you should consider using a different MTA. In an earlier message, you noted that the MTA which receives the rejection message may replace a meaningful error message with text with less meaningful text. There are mail servers which modify the body of any inbound DSN, so generating a 'bounce' does not ensure that your meaningful message will survive transit to the intended recipient. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 13:55:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265853A6912; Mon, 19 Jan 2009 13:55:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770653A6912 for ; Mon, 19 Jan 2009 13:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OYEs2IRQ2DTf for ; Mon, 19 Jan 2009 13:55:52 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 82ADC3A6852 for ; Mon, 19 Jan 2009 13:55:52 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0JLtZ7l015692 for ; Mon, 19 Jan 2009 16:55:36 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0JLkXdG019008 for ; Mon, 19 Jan 2009 16:46:33 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0JLtSW4004597 for ; Mon, 19 Jan 2009 16:55:29 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0JLtOQU004574 for asrg@irtf.org; Mon, 19 Jan 2009 16:55:24 -0500 Date: Mon, 19 Jan 2009 16:55:22 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090119215522.GA2509@gsp.org> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 07:55:26AM -0800, SM wrote: > I would prefer if my bank used a mechanism for email that protects the > integrity of the content. That's an excellent point. In addition, I would prefer my bank to (a) not outsource their mail, (b) not send mail marked up with HTML (the phisher's best friend) and (c) not send mail which includes any URLs in the text. ( About (c): If they never send any, they can never typo them. Nor can I, when copying them from mail by hand or cut-and-pasting. If I rely solely on the single URL I entered -- very carefully, by hand, once -- then my chances of going to a typosquatted site drop considerably. An attacker would need to gain control of the place I've stored that URL, which would require gaining control of my computer, which would mean that there would be no need for them to bother sending me a phish, since they could just extract the URL/username/password triplet directly the next time I used it. Moreover, if the bank trained all their customers in this -- just like they [try to] train them that they will never, ever ask for a password -- then they'd be training their customers to be phish-resistant, since they'd know that any message with a putative URL for the bank is a phish. This in turn would discourage phishers, who would be presented with a reduced attack surface. Maybe. On a good day. See Chris's comment about educating users and recall Marcus Ranum's advice on that very topic: "If it were going to work, it would have worked by now". I concur that we need to attack this problem at the MTA and network layers, because by the time it gets to users, it's too late. ) But banks (and other financial institutions) don't do this. It appears, if I can attempt to intuit their priorities from the methods and content of their email messages, that they are far more interested in marketing and assessing marketing effectiveness than they are in message privacy, security and integrity. I think if it were otherwise, then, among other things, PKI would have long since become widely deployed, and they wouldn't actively be training their customers to click on links in mail messages. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 16:09:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66863A6A5A; Mon, 19 Jan 2009 16:09:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F433A6A5A for ; Mon, 19 Jan 2009 16:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bd3dHLUBntco for ; Mon, 19 Jan 2009 16:09:49 -0800 (PST) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 1F0993A6872 for ; Mon, 19 Jan 2009 16:09:48 -0800 (PST) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.1/8.13.8) with ESMTP id n0K09SxE057284 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 19 Jan 2009 19:09:29 -0500 (EST) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.7+Sun/8.12.10) with ESMTP id n0K06Zq1025345; Mon, 19 Jan 2009 19:06:35 -0500 (EST) Received: from localhost (feenberg@localhost) by nber6.nber.org (8.13.7+Sun/8.13.7/Submit) with ESMTP id n0K06YeZ025342; Mon, 19 Jan 2009 19:06:35 -0500 (EST) X-Authentication-Warning: nber6.nber.org: feenberg owned process doing -bs Date: Mon, 19 Jan 2009 19:06:34 -0500 (EST) From: Daniel Feenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <4974F676.4000706@nd.edu> Message-ID: References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> MIME-Version: 1.0 X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20090119 #1481086, check: 20090120 clean Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, 19 Jan 2009, Paul Russell wrote: > On 1/19/2009 10:38 AM, Ian Eiloart wrote: >> >> I agree, but bounces have two huge advantages, >> >> 1. You can bounce selectively. IE, you can accept a message for one >> recipient, while bouncing it for another, even after seeing the content. >> So, you can have different delivery policies for different people. > > I know that sendmail can be configured to accept for one recipient and reject > for another recipient. I assume there are other MTA products which also > support this functionality. If yours does not, perhaps you should consider > using a different MTA. If I may contribute... Sendmail can selectively reject receipients while processing "RCPT TO:" commands, but not after the header and body are received. So anti-spam processing based on the sending IP address can be different for different users (and still use rejection rather than DSNs), but it isn't straightforward to selectively handle items based on content or headers without resorting to DSNs or spam folders. That is one of the advantages DNSBLs have over content analysis. Or do you have a specific suggestion? As I understand it, this is a consequence of the SMTP protocol, and not something that sendmail can program around. Dan Feenberg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 16:12:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F7728C19F; Mon, 19 Jan 2009 16:12:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E21B3A6A12 for ; Mon, 19 Jan 2009 16:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599] 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 tn2jDrhZl4P1 for ; Mon, 19 Jan 2009 16:12:17 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A3AA83A67B1 for ; Mon, 19 Jan 2009 16:12:17 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0K0BoVK023411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jan 2009 16:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232410319; x=1232496719; bh=hH2HlRVm1eOliJLTW2bg96Axg0LboDYYUjNbHHbTf9E=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=delsfechLo4i40F5W5LclWENl8MyRdIV3GAdnuaEZ0SLAOQcWhMGopNWgX22hwzfL CcglKvucu9AhpZ6gNrF4Tyz0ZwnKd7zVRgYGgHpwxRPfCrOKfD4yGISUfvS+k3EVpY vx10g9UwENyc4T+qcImUENg3yD0irh3S9fbdacrI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=4a9vBZN4ONOSws1jwbPCeJmSTkyBymmzvoWqLsdKzbTgtGq0Gykkg20O96iyHumB1 H3003y4lNNJ77nWBwMlsrfD1mPp26k2iFQdkpEMbS+e2HmjwpAu21+BPXpj7akt8/07 eBPHMC3PEDipjmQqPOq/vgsEBcIi1m7DIDUxze8= Message-Id: <6.2.5.6.2.20090119143404.031c56f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Jan 2009 16:02:19 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <20090119215522.GA2509@gsp.org> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <20090119215522.GA2509@gsp.org> Mime-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 13:55 19-01-2009, Rich Kulawiec wrote: >That's an excellent point. In addition, I would prefer my bank to >(a) not outsource their mail, (b) not send mail marked up with HTML >(the phisher's best friend) and (c) not send mail which includes any >URLs in the text. The economy and specialization works in favor of (a) and marketing in favor of (b). >( About (c): If they never send any, they can never typo them. Nor can I, >when copying them from mail by hand or cut-and-pasting. If I rely >solely on the single URL I entered -- very carefully, by hand, once -- >then my chances of going to a typosquatted site drop considerably. >An attacker would need to gain control of the place I've stored that >URL, which would require gaining control of my computer, which would >mean that there would be no need for them to bother sending me a phish, >since they could just extract the URL/username/password triplet directly >the next time I used it. We commonly see URLs in emails which are different from the site the actual link points to. We live in an age of convenience. People find it easier to click on a URL than to copy and paste or type in the URL. It doesn't require a leap of imagination to see how all this contributes to phishing. It's difficult to counter (c) as business communication is centered around how to get people to a web site as it's seen as a low-cost and accessible medium to interact with the customer. >Moreover, if the bank trained all their customers in this -- just like >they [try to] train them that they will never, ever ask for a password >-- then they'd be training their customers to be phish-resistant, >since they'd know that any message with a putative URL for the bank >is a phish. This in turn would discourage phishers, who would be presented >with a reduced attack surface. Maybe. On a good day. See Chris's comment Customers may have been trained not to give out their password if they are asked (over the phone) but they are giving it out by logging into an web site. If banks were to implement (c), then it does, as you put it, reduce the attack surface. >about educating users and recall Marcus Ranum's advice on that very topic: >"If it were going to work, it would have worked by now". I concur that >we need to attack this problem at the MTA and network layers, because >by the time it gets to users, it's too late. ) Responding to Chris' comment, there isn't a feasible mechanism for forcing end users to be smarter. Utilization of a technology should not be an IQ test. Don't read all this as saying that I don't agree with your points. It's more about whether we are taking the right approach to solve the problem. I agree that each time the problem gets to the users, it's a disaster in waiting. One of the issues in dealing with the problem at the MTA level is that we have to second guess the user's desires and we can get it wrong. >But banks (and other financial institutions) don't do this. It appears, >if I can attempt to intuit their priorities from the methods and content >of their email messages, that they are far more interested in marketing >and assessing marketing effectiveness than they are in message privacy, >security and integrity. I think if it were otherwise, then, among >other things, PKI would have long since become widely deployed, and >they wouldn't actively be training their customers to click on links >in mail messages. You hit the nail on the head there. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 16:27:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B783A6A6C; Mon, 19 Jan 2009 16:27:38 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78C53A6A6C for ; Mon, 19 Jan 2009 16:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] 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 CcGp6iMyzJgj for ; Mon, 19 Jan 2009 16:27:37 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id ADB7D3A67DF for ; Mon, 19 Jan 2009 16:27:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4039164F83BD for ; Tue, 20 Jan 2009 12:27:31 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KwL+OzAHcGU for ; Tue, 20 Jan 2009 12:27:26 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 06E5E64F83BB for ; Tue, 20 Jan 2009 12:27:25 +1200 (FJT) Date: Tue, 20 Jan 2009 12:27:25 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <6781676.541232411229999.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <6.2.5.6.2.20090119143404.031c56f8@resistor.net> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Well, take a stroll and go to talk to your marketing manager, ask him what he thinks of email as a marketing tool and what you can do or cannot do with it. You may be surprised. ----- Original Message ----- From: "SM" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 20 January, 2009 12:02:19 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) >But banks (and other financial institutions) don't do this. It appears, >if I can attempt to intuit their priorities from the methods and content >of their email messages, that they are far more interested in marketing >and assessing marketing effectiveness than they are in message privacy, >security and integrity. I think if it were otherwise, then, among >other things, PKI would have long since become widely deployed, and >they wouldn't actively be training their customers to click on links >in mail messages. You hit the nail on the head there. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 23:12:56 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BB43A68C5; Mon, 19 Jan 2009 23:12:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0A33A68C5 for ; Mon, 19 Jan 2009 23:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 UceSY10Tj-YH for ; Mon, 19 Jan 2009 23:12:54 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 3BBF63A6820 for ; Mon, 19 Jan 2009 23:12:53 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 20 Jan 2009 08:12:33 +0100 id 00000000005DC030.0000000049757961.00006F6F Message-ID: <49757961.6010107@tana.it> Date: Tue, 20 Jan 2009 08:12:33 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4974E31F.6010808@terabites.com> In-Reply-To: <4974E31F.6010808@terabites.com> Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Gordon Peterson wrote: > SPF breaks more than forwarding. Not quite, forwarding is already broken even without SPF. > It's not enough for them to work just "some of the time", IF they also > break legitimate, reasonable uses. Since we are not able to come up with a definition of spam, we cannot define what is legitimate use either. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 19 23:35:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E983A69B9; Mon, 19 Jan 2009 23:35:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F6E3A69B9 for ; Mon, 19 Jan 2009 23:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 wCk+3mGJnjUz for ; Mon, 19 Jan 2009 23:35:08 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 3F8953A67FB for ; Mon, 19 Jan 2009 23:35:08 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 20 Jan 2009 08:34:51 +0100 id 00000000005DC030.0000000049757E9B.000075AA Message-ID: <49757E9B.1080702@tana.it> Date: Tue, 20 Jan 2009 08:34:51 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> In-Reply-To: Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Daniel Feenberg wrote: > On Mon, 19 Jan 2009, Paul Russell wrote: >> On 1/19/2009 10:38 AM, Ian Eiloart wrote: >>> 1. You can bounce selectively. >> >> I know that sendmail can be configured to accept for one recipient and >> reject for another recipient. > > Sendmail can selectively reject receipients while processing "RCPT TO:" > commands, but not after the header and body are received. > [...] > As I understand it, this is a consequence of the SMTP > protocol, and not something that sendmail can program around. Given a set of recipients (r1, r2, ..., rn) the server can partition it in subsets that have homogeneous filtering recipes. It does that in steps. Each step consists in responding 250 for r1 and any other recipient with identical filtering, 4xx to the rest. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 02:39:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38613A6BC0; Tue, 20 Jan 2009 02:39:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977C128C127 for ; Tue, 20 Jan 2009 02:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] 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 0kAIHNPALaug for ; Tue, 20 Jan 2009 02:39:25 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A11213A698D for ; Tue, 20 Jan 2009 02:39:24 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56585) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRN23-000N1O-KP for asrg@irtf.org; Tue, 20 Jan 2009 10:42:03 +0000 Date: Tue, 20 Jan 2009 10:39:04 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <9B9EEF3CFE61794237642102@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4974F47B.4020409@nd.edu> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112160644.28990241DC@panix5.panix.com> <1231780846.29802.3.camel@squonk.lboro.ac.uk> <4DF4FC54A01E70470CFD0173@lewes.staff.uscs.susx.ac.uk> <4974F47B.4020409@nd.edu> Originator-Info: login-token=Mulberry:01ejyYH+OdBoS7qeyB5mLtsQuS4LS5ed1i76c=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 16:45:31 -0500 Paul Russell wrote: > On 1/19/2009 6:08 AM, Ian Eiloart wrote: >> There are at least two very good reasons for wanting to bounce rather >> than reject emails. >> >> a) when a message has two or more local recipients, you can't have >> different policies for each recipient about what to reject. You reject >> for all or no recipients. There are some workarounds, but they're >> kludgy and cause their own problems. > > Perhaps that is true of your MTA, but we have been doing this with > sendmail for several years. This is a supported feature which can be enabled or > disabled by any reasonably competent system administrator. I would not describe it > as a 'work-around' or a 'kludge', and it has not caused us any problems. With SMTP, you have to give recipient specific defers before you see the body of the message. Either you defer everyone after the first recipient, or you split them into policy classes and defer everyone who isn't in the first policy class. The defers cause delays which may be severe when there are very many policy classes. I guess the ideal solution would be an SMTP extension allowing MTAs to switch to LMTP if they're both capable. I think something similar exists. They may even cause delivery failure. For example, I've seen an airline ticketing agency that failed to retry delivery of messages! However, we can't be expected to design around that kind of stupidity. However, if you defer a whole bunch of people, then reject the message for the first person, the sender might be forgiven for thinking that your rejection of the message is definitive. > > b) when you reject a message you can try to explain why, but often the > > sending MTA will throw away some or all of your explanation. Usually, it > > will wrap your explanation inside it's own. The end result is that the > > recipient of the bounce message (if there is one) doesn't understand what's > > going on. If you generate a bounce, you have full control of what the > > bounce recipient sees. For example, you could include an explanation of why > > they should lobby their domain controller to publish SPF records. > > Some mail servers add boilerplate text - sometimes accurate, sometime > completely inaccurate - to every inbound DSN. How are you going to deal with that > issue? The fact is, you cannot control the operation of every mail server that > might handle your completely meaningful, easily understandable, and perfectly > hand-crafted 'bounce'. Really? That's crazy. However, the ALL do it to rejection messages. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 03:31:01 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A29E3A68BC; Tue, 20 Jan 2009 03:31:01 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6EA3A6802 for ; Tue, 20 Jan 2009 03:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 ppcS3bEr-xkc for ; Tue, 20 Jan 2009 03:30:52 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 6C1453A6BC1 for ; Tue, 20 Jan 2009 03:30:52 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56999) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRPFW-000JBT-AR for asrg@irtf.org; Tue, 20 Jan 2009 11:33:32 +0000 Date: Tue, 20 Jan 2009 11:30:33 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <49757E9B.1080702@tana.it> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> Originator-Info: login-token=Mulberry:01EXOvT3rUHbRS4AOxfZmE6CLCd+vQqXSZht4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 08:34:51 +0100 Alessandro Vesely wrote: > Daniel Feenberg wrote: >> On Mon, 19 Jan 2009, Paul Russell wrote: >>> On 1/19/2009 10:38 AM, Ian Eiloart wrote: >>>> 1. You can bounce selectively. >>> >>> I know that sendmail can be configured to accept for one recipient and >>> reject for another recipient. >> >> Sendmail can selectively reject receipients while processing "RCPT TO:" >> commands, but not after the header and body are received. >> [...] >> As I understand it, this is a consequence of the SMTP >> protocol, and not something that sendmail can program around. > > Given a set of recipients (r1, r2, ..., rn) the server can partition it > in subsets that have homogeneous filtering recipes. It does that in > steps. Each step consists in responding 250 for r1 and any other > recipient with identical filtering, 4xx to the rest. Yes, that's the scheme I was referring to. It can be implemented with my MTA - Exim. However, if any filter subset doesn't want the message, then you should give a 5yz response after seeing the body. RFC2821 says that the sending MTA "SHOULD not again attempt delivery to the same server without user review and intervention of the message". I guess most MTA's aren't RFC2821 compliant in that respect. RFC 5321 says the client "may either return it to the user or requeue it for a subsequent attempt". That's an improvement, but at best there's no guarantee that members of the second and subsequent subsets will ever see the message. If they do, it will be after a delay that many people find unacceptable. 2821 and 5321 both say retry intervals should be at least 30 minutes, but that might be unusual. Exim's default policy is every 15 minutes for the first two hours, for example, then at decreasing intervals. If the number of subsets is large enough, you may even exceed the retry timeout on the sending MTA, so a large site had better not have too many filter recipes. The limit would be about 30 different filter recipes when the sending server is using Exim's default retry policy. . 30 recipes lets you give your user four binary, or three ternary options. Even if the say "don't filter" to all of those options, they can still lose email if the first recipient has enabled filtering, and the sending server is rfc2821 compliant. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 03:43:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A1D3A6BC1; Tue, 20 Jan 2009 03:43:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23393A6BC1 for ; Tue, 20 Jan 2009 03:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 Z6obZH+36UoB for ; Tue, 20 Jan 2009 03:43:48 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 634CE3A6AED for ; Tue, 20 Jan 2009 03:43:48 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:57144) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRQ1I-0001KA-I8 for asrg@irtf.org; Tue, 20 Jan 2009 11:46:30 +0000 Date: Tue, 20 Jan 2009 11:43:31 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <3742C33BB804F95AECAF73B9@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4974CA68.2010008@nortel.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <4974CA68.2010008@nortel.com> Originator-Info: login-token=Mulberry:014pQ11Ev1ozkjAYk2TrpVCahHSAxWLkW6V/8=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 13:46:00 -0500 Chris Lewis wrote: > Dotzero wrote: >> On Mon, Jan 19, 2009 at 12:48 PM, Ian Eiloart wrote: > >> How happy will you be when your ISP checked the DKIM signature >> upstream from your mail client, added in x-headers showing the check >> (and possibly other things) and broke the signature? > > Or, if your ISP checked SPF and DKIM, and reported the email as legit > ... for a domain name very much like, but not exactly like your bank...? That would be a problem. However, a smart mail client could also check that the domain is used in my address book. And, it could also check my address book and history for matching domains. Near matches should be flagged as suspect. Use of relatively secure top level domains could help. I don't understand why my bank stopped using its ".coop" domain. It's much harder for spammers to register those domains. I'd like to see a ".fin.uk" (or similar) domain, where only organisations regulated by the Financial Services Authority can register domains, and where they're required to use SPF. > Even with reputation services telling you whether the domain is > supposedly good, phishers generate domains so fast, and reputation > services are of necessity going to have to score new ones as "neutral" > at worst, it's not going to get you very far overall. Frankly, I'm not going to bank with a bank that can only achieve "neutral" for it's email domain reputation. > We need a feasible mechanism for forcing end users to be smarter ;-) Agreed! Banks that use email should take care to educate their users on this matter. Holding the bank (rather than the account holder) at least partially responsible for fraudulent use of accounts that they manage would help. They might have to prove that they'd taken reasonable steps to educate their customers about phishing, and that they'd deployed domain protection technologies. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 03:49:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB603A68BC; Tue, 20 Jan 2009 03:49:58 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C395A3A68BC for ; Tue, 20 Jan 2009 03:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 SWYGP8dLMM4P for ; Tue, 20 Jan 2009 03:49:56 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id CA41A3A67F2 for ; Tue, 20 Jan 2009 03:49:56 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:57194) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRQBR-0003WL-6T for asrg@irtf.org; Tue, 20 Jan 2009 11:52:39 +0000 Date: Tue, 20 Jan 2009 11:49:40 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090119190814.38720.qmail@simone.iecc.com> References: <20090119190814.38720.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01c4rsdtzrWtu090DY37Dm/1/p2QIN0Naw6PU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 19:08:14 +0000 John Levine wrote: >>>> I'd also like an email client that tells me when the From: header >>>> domain doesn't match the return-path domain. ... > >> Yes, I know. Presumably your bank doesn't email you through this list or >> any other, though. What I'm after here is avoiding bank phishing. > > Have you actually looked at the mail from your bank? As likely as > not, the return path points back at the ESP that sends their mail and > doesn't match the From: address. Address matching is a totally > ineffective way to verify the source of any mail. Right now, that's true. If the banks were serious about preventing phishing, they'd do something more sensible. > You also can't make > many assumptions about where it will be sent from; I got a real > message today from HSBC in the Channel Islands that was sent from Hong > Kong. > >> I'd be just as happy if they used DKIM to sign the message. I'd still >> need my mail client to tell me that it was signed properly, though. >> And, signed by the owner of the address that I can see in the message >> headers. > > Well, yes, we all know that effective use of DKIM requires some sort of > reputation system to decide what to make of the signature. Absolutely. I should be able to tell my mail client or ESP which domains and addresses to trust (my bank, my employer, my doctor...), in the first instance. Only when DKIM and SPF are in wider use will a centralised reputation system be very useful. But "wider use" needn't mean most of the world. It could just mean, "most of the financial institutions in the UK", for it to be of utility to most people in the UK. Or "most academic institutions in the UK" for it to be of use here. > > R's, > John > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 03:55:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6F53A6BC9; Tue, 20 Jan 2009 03:55:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC643A6BC8 for ; Tue, 20 Jan 2009 03:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 TCQN6Br3ULCc for ; Tue, 20 Jan 2009 03:55:19 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 11BD13A6889 for ; Tue, 20 Jan 2009 03:55:18 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:57234) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRQKP-0006JD-FG for asrg@irtf.org; Tue, 20 Jan 2009 11:58:01 +0000 Date: Tue, 20 Jan 2009 11:55:02 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <6.2.5.6.2.20090119143404.031c56f8@resistor.net> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <20090119215522.GA2509@gsp.org> <6.2.5.6.2.20090119143404.031c56f8@resistor.net> Originator-Info: login-token=Mulberry:01wK36CikOaG8BGk5sLNMzIm19JiUbZCPTNRg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 16:02:19 -0800 SM wrote: > > At 13:55 19-01-2009, Rich Kulawiec wrote: >> That's an excellent point. In addition, I would prefer my bank to >> (a) not outsource their mail, (b) not send mail marked up with HTML >> (the phisher's best friend) and (c) not send mail which includes any >> URLs in the text. > > The economy and specialization works in favor of (a) and marketing in > favor of (b). Yes, but legislation requiring banks to do sensible things here, is feasible. At least, it is in the UK and probably elsewhere given their current reputation for incompetence. Actually, it's not the outsourcing that's the problem. They just need to do that properly, with sensible return-paths and appropriate SPF records. If banks were doing that properly, it would be easier for ESPs to detect phishing, then you could conceivably hold them responsible when they fail to do so. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 03:57:34 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957CD3A68BC; Tue, 20 Jan 2009 03:57:34 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4CC3A6BC6 for ; Tue, 20 Jan 2009 03:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HUN0Czm4wW0Y for ; Tue, 20 Jan 2009 03:57:33 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 65D023A6858 for ; Tue, 20 Jan 2009 03:57:33 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0KBvGbk008202 for ; Tue, 20 Jan 2009 06:57:17 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0KBmC29028029 for ; Tue, 20 Jan 2009 06:48:12 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0KBvA03012661 for ; Tue, 20 Jan 2009 06:57:10 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0KBv8a3012649 for asrg@irtf.org; Tue, 20 Jan 2009 06:57:08 -0500 Date: Tue, 20 Jan 2009 06:57:08 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090120115708.GA11455@gsp.org> References: <4974E31F.6010808@terabites.com> <49757961.6010107@tana.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49757961.6010107@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 08:12:33AM +0100, Alessandro Vesely wrote: > Since we are not able to come up with a definition of spam, we cannot > define what is legitimate use either. The correct definition of spam has been well-known as "unsolicited bulk email" for many years -- a definition that traces its lineage back to the use of earlier, less precise terms such as "mail mail abuse" and "junk mail" that were around in the early 1980's. Please, let's not reopen this question here, as there is absolutely no need to do so given that it's been covered in excruciating depth elsewhere. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 04:00:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6E03A6889; Tue, 20 Jan 2009 04:00:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F693A686C for ; Tue, 20 Jan 2009 04:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] 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 H+-D+am-oike for ; Tue, 20 Jan 2009 04:00:44 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 3135D3A6BD3 for ; Tue, 20 Jan 2009 04:00:44 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:57271) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRQTQ-000A1X-JS for asrg@irtf.org; Tue, 20 Jan 2009 12:03:26 +0000 Date: Tue, 20 Jan 2009 12:00:27 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <7ae58c220901191248j136b9b36o2f04ffe2827d1032@mail.gmail.com> References: <4974E31F.6010808@terabites.com> <7ae58c220901191248j136b9b36o2f04ffe2827d1032@mail.gmail.com> Originator-Info: login-token=Mulberry:0134H9Y0jia8gg7lHFS6dS9nDWRfkevUKnVOw=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 15:48:20 -0500 Dotzero wrote: > > If an enduser wants the flexibility to send from Kiosks or through > other MTAs and their company or mail provider allows this by policy > then the use of strong SPF assertions is likely inappropriate. My > response to you is the old saw about the person who goes tot he doctor > about a pain.... "Doctor, it hurts when I do that" ...... and the > Doctor says..... "Don't do that". In any case, you can use ~all. All I want to do is be able to whitelist email that's being sent by the usual methods from trusted sources. There's no reason that a Kiosk shouldn't be set up to use a webmail client. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 04:06:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDCB3A6BC1; Tue, 20 Jan 2009 04:06:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824CC3A69DD for ; Tue, 20 Jan 2009 04:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 A9FxMUytSD-9 for ; Tue, 20 Jan 2009 04:06:44 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 901323A6950 for ; Tue, 20 Jan 2009 04:06:44 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0KC6MZj015534 for ; Tue, 20 Jan 2009 07:06:24 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0KBvITU008135 for ; Tue, 20 Jan 2009 06:57:19 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0KC6HrL016434 for ; Tue, 20 Jan 2009 07:06:17 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0KC6HQ0016433 for asrg@irtf.org; Tue, 20 Jan 2009 07:06:17 -0500 Date: Tue, 20 Jan 2009 07:06:17 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090120120617.GB11455@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 03:38:39PM +0000, Ian Eiloart wrote: > 1. You can bounce selectively. IE, you can accept a message for one > recipient, while bouncing it for another, even after seeing the content. > So, you can have different delivery policies for different people. (a) I don't want to bounce at all, ever and (b) I don't see the value in this approach. If the message is from a spammer (or is classified as spam by some mechanism), then it gets rejected [for all recipients] no matter who wants it or why. I don't permit users to selectively decide to receive bogons; I don't permit them to selectively decide to receive spam, and for the same reason: I think it's very poor security policy. > 2. The content of the bounce message is generated by the MTA that made > the decision. Therefore, it can contain content that's easier to > understand. This doesn't follow. Reject messages, like bounces, are also generated by the MTA that made the decision. Any sufficiently-broken mail system that mangles those is probably going to mangle bounces or do other silly things as well. If you need to transmit a long, detailed message, then provide a static URL, as in: 550 blah blah Your message rejected because your momma dresses you funny; see http://www.example.com/rejects/your-momma.html Of course there's no guarantee that will survive transit either. The bottom line is that you can't do anything to fix other peoples' broken mail systems. > So, you may not agree that the balance is in favour of bouncing, but it > certainly would be better to bounce if you KNOW that the sender address > is not forged - regardless of how you know that. But I don't care if the sender address is forged or not. It plays no role in my anti-spam setup, and has no impact on what I do with such traffic, since my intention is to either accept or reject it outright during the SMTP connection. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 04:10:40 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558443A6BD8; Tue, 20 Jan 2009 04:10:40 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634963A6BD7 for ; Tue, 20 Jan 2009 04:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SSflwI5Od6Yw for ; Tue, 20 Jan 2009 04:10:38 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 3E1703A6BD6 for ; Tue, 20 Jan 2009 04:10:38 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0KCALhZ005245 for ; Tue, 20 Jan 2009 07:10:21 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0KC1Hlw024583 for ; Tue, 20 Jan 2009 07:01:17 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0KCAF3Q017696 for ; Tue, 20 Jan 2009 07:10:15 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0KCAFeJ017695 for asrg@irtf.org; Tue, 20 Jan 2009 07:10:15 -0500 Date: Tue, 20 Jan 2009 07:10:15 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090120121015.GC11455@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 11:49:40AM +0000, Ian Eiloart wrote: > Only when DKIM and SPF are in wider use will a centralised > reputation system be very useful. Don't hold your breath. SPF is dead -- and good riddance, it was a very stupid idea -- and a centralized reputation system of any kind would be a disaster. It's one of the very last things anyone who is actually opposed to spam should ever want to see happen. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 05:27:13 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E443A6AEC; Tue, 20 Jan 2009 05:27:13 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849523A68DF for ; Tue, 20 Jan 2009 05:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_00=-2.599, DRUGS_ERECTILE=1, SARE_ADULT2=1.42] 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 iRwj00OQAf6F for ; Tue, 20 Jan 2009 05:27:07 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 63C1A3A67F2 for ; Tue, 20 Jan 2009 05:27:07 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:58197) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRUTN-000LIL-O6 for asrg@irtf.org; Tue, 20 Jan 2009 13:29:48 +0000 Date: Tue, 20 Jan 2009 13:26:48 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090120120617.GB11455@gsp.org> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> Originator-Info: login-token=Mulberry:019mPIFF/ENnk30Bx2Yolp2DuHXNvpblmJa84=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 07:06:17 -0500 Rich Kulawiec wrote: > n Mon, Jan 19, 2009 at 03:38:39PM +0000, Ian Eiloart wrote: >> 1. You can bounce selectively. IE, you can accept a message for one >> recipient, while bouncing it for another, even after seeing the content. >> So, you can have different delivery policies for different people. > > (a) I don't want to bounce at all, ever and (b) I don't see the value in > this approach. If the message is from a spammer (or is classified as spam > by some mechanism), then it gets rejected [for all recipients] no matter > who wants it or why. I don't permit users to selectively decide to > receive bogons; I don't permit them to selectively decide to receive > spam, and for the same reason: I think it's very poor security policy. I work in an academic environment with a medical school, where a word like "viagra" or "penis" can mean spam to some people, or a vital research grant application to others. I don't like content filtering at all, and only apply it quite lightly. I'd like to allow people to opt in to heaver filtering (eg, those that are particularly sensitive to obscenity), or opt out completely. While I'm not permitted to bounce messages (I don't) I can't do that well when there are multiple recipients. Pre-data, of course, I can apply selective filtering, but only for policies that most people don't understand (source IP address reputation, and EHLO string). And not based on the sender address. Blacklisting specific senders is ineffective, whitelisting creates holes in my spam filter. >> 2. The content of the bounce message is generated by the MTA that made >> the decision. Therefore, it can contain content that's easier to >> understand. > > This doesn't follow. Reject messages, like bounces, are also generated by > the MTA that made the decision. Any sufficiently-broken mail system > that mangles those is probably going to mangle bounces or do other > silly things as well. If you need to transmit a long, detailed message, > then provide a static URL, as in: > > 550 blah blah Your message rejected because your momma dresses > you funny; see http://www.example.com/rejects/your-momma.html > > Of course there's no guarantee that will survive transit either. The > bottom line is that you can't do anything to fix other peoples' broken > mail systems. Yes, I thought that's what I said. Not only might it not survive, but it might be replaced with a misleading error message. For example, if I reject a sender address after RCPT TO (in case the rcpt is postmaster), some MTA's will generate a bounce message which says the recipient doesn't exist. Anyway, it's almost always embedded in some other message. Does anyone know of an MTA that doesn't add something to a reject message when generating a bounce message? Would such a bounce be of any value? I do put URLs in my messages, usually on the first line because that seems more likely to survive. IIRC, there are MTAs that preserve only the first line of an error message in a bounce. I also use enhanced error codes, in the hope that some MTAs might generate better bounce messages. I don't buy the argument that an MTA that mangles reject messages (that requires little or no administrative effort) will also mangle bounce messages (that requires more effort). Perhaps I'm wrong. Does anyone know of an MTA that mangles bounce messages in its default configuration? -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 05:41:18 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F35B3A6923; Tue, 20 Jan 2009 05:41:18 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F5B3A67EC for ; Tue, 20 Jan 2009 05:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] 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 Wd0sW56o7SVc for ; Tue, 20 Jan 2009 05:41:16 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id C69FB3A6923 for ; Tue, 20 Jan 2009 05:41:15 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:58372) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRVHA-00047A-JM for asrg@irtf.org; Tue, 20 Jan 2009 13:43:58 +0000 Date: Tue, 20 Jan 2009 13:40:59 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090120121015.GC11455@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> Originator-Info: login-token=Mulberry:01iVPtUvK0W7fKwEG09Xn8yGDF78sOrOx5/r4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 07:10:15 -0500 Rich Kulawiec wrote: > On Tue, Jan 20, 2009 at 11:49:40AM +0000, Ian Eiloart wrote: >> Only when DKIM and SPF are in wider use will a centralised >> reputation system be very useful. > > Don't hold your breath. SPF is dead -- and good riddance, it was a very > stupid idea -- and a centralized reputation system of any kind would > be a disaster. It's one of the very last things anyone who is actually > opposed to spam should ever want to see happen. I disagree fundamentally about the centralise reputation system. My most effective anti-spam tool is a centralised reputation system for IP addresses - the two RBLs that I consult. For example, a few days ago, I rejected 260,000 messages and delivered 56,000. 170,000 were rejected as a result of RBL lookups. I get very few complaints about false positives from those RBLs. Anyway, if you don't want to use a centralised reputation system, then use a local one. I would do that in the first instance, then fall back to a centralised system when I got a neutral result. The key thing is that you can't use any kind of email domain or email address based reputation system unless you have evidence that the sender address isn't forged. > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 05:44:55 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2203A6AEC; Tue, 20 Jan 2009 05:44:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281C23A6AEC for ; Tue, 20 Jan 2009 05:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 tkRZR35oyYty for ; Tue, 20 Jan 2009 05:44:53 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 434113A69B6 for ; Tue, 20 Jan 2009 05:44:53 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:58410) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRVNC-0005RH-9K for asrg@irtf.org; Tue, 20 Jan 2009 13:47:36 +0000 Date: Tue, 20 Jan 2009 13:44:36 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> Originator-Info: login-token=Mulberry:017kl8+Veq6l4vttBbWm9hvu9sVMGdU1FvY7Q=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 19 January 2009 13:37:50 -0500 Dotzero wrote: > >> Yes, I know. Presumably your bank doesn't email you through this list or >> any other, though. What I'm after here is avoiding bank phishing. When >> communicating with my bank, I want them emailing me directly, to my >> current email address. >> >> I'd be just as happy if they used DKIM to sign the message. I'd still >> need my mail client to tell me that it was signed properly, though. And, >> signed by the owner of the address that I can see in the message headers. >> > > How happy will you be when your ISP checked the DKIM signature > upstream from your mail client, added in x-headers showing the check > (and possibly other things) and broke the signature? That would make me unhappy. Presumably they're not supposed to do that, but doesn't DKIM allow the signer to say what they're signing? And, doesn't that survive addition of new headers? If my ESP (of course I don't use my ISP for email) broke a DKIM signature, I'd expect them to replace the signature with a good one. But, I'd prefer that they simply delivered the message unbroken. Of course, all of this works better when it's correctly implemented. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 05:50:06 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0861128C13F; Tue, 20 Jan 2009 05:50:06 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4940728C13F for ; Tue, 20 Jan 2009 05:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HHl0EZxJ7XaG for ; Tue, 20 Jan 2009 05:50:03 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 7DC9128B23E for ; Tue, 20 Jan 2009 05:50:03 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3525473wfg.7 for ; Tue, 20 Jan 2009 05:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iQsPoGJC7vrF+IhFib5fuZzUueI2zFNApL07mnQp3EU=; b=q/TGlr5NmOxb+gynN38rISeBoCgeqP7iaEgqjn/Z6PMto1dC/VnMck+mTBJa4/83D+ G9zOCkzDf0UPFjJLEsQDnmCb4xrWC95IXJs/oRtJlbBY3ygi5E1c3UQaNPGw43LKsCnJ XoC94nRa0b7S3obs50i/xDIPxaENVge0hqnXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=er0GiYFTmprSGhie+JCuFAQ61f0fw4aAtFiXcIqMlWGaFQVKOIBNYwAA6xp3yzTQw7 dlBZQntEut9FzqSfC2vQFK1jwx9mMi/aZIyw43PqzIIAVB/UTp6aDxdzSJgF2nAtfINC oEW0zb5d7IrrWXnY+z/YxQW6AXdCyMpsbxqT8= Received: by 10.142.103.2 with SMTP id a2mr2882954wfc.164.1232459386148; Tue, 20 Jan 2009 05:49:46 -0800 (PST) Received: by 10.142.126.17 with HTTP; Tue, 20 Jan 2009 05:49:46 -0800 (PST) Message-ID: <7ae58c220901200549l61afc5c2ja141bf07b584f31a@mail.gmail.com> Date: Tue, 20 Jan 2009 08:49:46 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4974E31F.6010808@terabites.com> <7ae58c220901191248j136b9b36o2f04ffe2827d1032@mail.gmail.com> Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 7:00 AM, Ian Eiloart wrote: > > > --On 19 January 2009 15:48:20 -0500 Dotzero wrote: > >> >> If an enduser wants the flexibility to send from Kiosks or through >> other MTAs and their company or mail provider allows this by policy >> then the use of strong SPF assertions is likely inappropriate. My >> response to you is the old saw about the person who goes tot he doctor >> about a pain.... "Doctor, it hurts when I do that" ...... and the >> Doctor says..... "Don't do that". > > In any case, you can use ~all. All I want to do is be able to whitelist > email that's being sent by the usual methods from trusted sources. There's > no reason that a Kiosk shouldn't be set up to use a webmail client. > Of course there are reasons Ian. Read what I wrote. If your organizations policy prohibits the use of kiosks in conjunction with the account they provide you with, that would seem to be a pretty good reason to me. Another good reason might be that shared computers (including kiosks) have quite the track record of being compromised by folks with ill intent. The fact that you can find some cases where some people choose to use a kiosk does not change the fact that a persons use of an email account is subject to the terms and conditions of use set by the owner of the domain providing the account. If it's your domain or the provider of your account says you cand o whatever youw ant then knock your socks off. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 06:02:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742033A697B; Tue, 20 Jan 2009 06:02:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840CB3A697B for ; Tue, 20 Jan 2009 06:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 6-PmYSmpxerS for ; Tue, 20 Jan 2009 06:02:48 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 9D2523A6923 for ; Tue, 20 Jan 2009 06:02:48 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3530916wfg.7 for ; Tue, 20 Jan 2009 06:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=9Yx4hBbNQw7AUZuFbm/okr6M3eMjm45/eGseibzU3to=; b=o8QBTG7SkS1Hz3jI9KviTLQSB9gBezk6ivliIedjal1vwz/U0ePvNjaaZ8nAe6CnzP 1xe5e56is0ALCNNda2EPpQENB20TXWSaqGEiMz7hGx6vwOoyoPULew+/6Nmgus6JQ/te FHwzyZOyFsKQZzU9aVkwRLFwcUR6LGspZMgRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eiSnnvYvFBc9t7KX7TWm8OOaIXo7MIIw/5nr3uHiQ0ksrtklWphCU4zjKIrdnXsSWo Ijafjda7ivBusBJ/gQ4Hk5KqOko/gykuWSk7dd6S11QXcmg4809sdD0NmbgOTUoQ2kWc EhyGPCNQm3BKNPWjVfu07HVqtfKkVoASFGHz8= Received: by 10.142.153.8 with SMTP id a8mr995972wfe.15.1232460151393; Tue, 20 Jan 2009 06:02:31 -0800 (PST) Received: by 10.142.126.17 with HTTP; Tue, 20 Jan 2009 06:02:31 -0800 (PST) Message-ID: <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> Date: Tue, 20 Jan 2009 09:02:31 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 8:44 AM, Ian Eiloart wrote: > > > --On 19 January 2009 13:37:50 -0500 Dotzero wrote: > >> >>> Yes, I know. Presumably your bank doesn't email you through this list or >>> any other, though. What I'm after here is avoiding bank phishing. When >>> communicating with my bank, I want them emailing me directly, to my >>> current email address. >>> >>> I'd be just as happy if they used DKIM to sign the message. I'd still >>> need my mail client to tell me that it was signed properly, though. And, >>> signed by the owner of the address that I can see in the message headers. >>> >> >> How happy will you be when your ISP checked the DKIM signature >> upstream from your mail client, added in x-headers showing the check >> (and possibly other things) and broke the signature? > > That would make me unhappy. Presumably they're not supposed to do that, but > doesn't DKIM allow the signer to say what they're signing? And, doesn't that > survive addition of new headers? If my ESP (of course I don't use my ISP for > email) broke a DKIM signature, I'd expect them to replace the signature with > a good one. But, I'd prefer that they simply delivered the message unbroken. > > Of course, all of this works better when it's correctly implemented. > Why aren't they supposed to do that? How many MUAs are checking DKIM signatures at the moment? I can think of a numbe rof ISPs that are adding headers to indicate various checks. From a DKIM perspective, the less you sign the greater the risk. Don't do the body length (full length that is)? Evil bad person can engate in replay attacks with content of their choice. This is not only about what you prefer personally. This is about what works generally. You work for a University. What percentage of your endusers are checking DKIM? I'm going to take a wild leap and assert that it approximates zero if it isn't actually zero. As far as I know, DKIM checking is happening at the MTA or in association with the MTA (Seperate host behind the front line MTA or something similar). It isn't happening at the user level. And that makes sense, at least to me. Maybe in some distant future MUAs will do DKIM checking but I wouldn't hold my breath. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 06:54:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DD528C0FB; Tue, 20 Jan 2009 06:54:16 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227DB28C0FB for ; Tue, 20 Jan 2009 06:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.809 X-Spam-Level: X-Spam-Status: No, score=-14.809 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 exnVva8jO0Aj for ; Tue, 20 Jan 2009 06:54:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id E995A28C0DD for ; Tue, 20 Jan 2009 06:54:13 -0800 (PST) Received: (qmail 50651 invoked from network); 20 Jan 2009 14:53:58 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 20 Jan 2009 14:53:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=AjDls01FNmvU3/S2RzBSigtonGznocSM9N924Jkix0M=; b=dvIEdEaeZTgNxoksbzysBYmdI9/3/+pWP8fehHQ4g9yDUuhe8F3c8LNe3JmXyHiK1IR4cyTSPiYYxk5le5eEaTfqB5TGGoCnspVuJSNdL+R30LqGLVT06WPeBIu3NHAZm+4nFxBOB3RZF/EGoGykotZ1NBzHyBVgm+371v4vsVY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=AjDls01FNmvU3/S2RzBSigtonGznocSM9N924Jkix0M=; b=nzJwadRUsOFfUXUlFvxQBxaOuQRjL/4rTdDN1qcS89Pj5MGtOC4vh/g8CFb24qjlAmI97ZpZKfXtLEahHjXzQj8dESnrjLnmHCvuneC0ocuO/teMva1cjDAs1VzT/ajfA7G00WeuJ35tAfKRQdhhYH+Qz1CC7F9RCPvLK4Rk6DM= Date: 20 Jan 2009 14:53:54 -0000 Message-ID: <20090120145354.57509.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >Yes, but legislation requiring banks to do sensible things here, is >feasible. At least, it is in the UK and probably elsewhere given their >current reputation for incompetence. I suppose. I sometimes drop by the weekly computer security seminar at the Cambridge computer lab, where I've heard some amazing stuff to buttress that reputation for incompetence. >Actually, it's not the outsourcing that's the problem. They just need >to do that properly, with sensible return-paths and appropriate SPF >records. Why do you keep harping on SPF? Of all of the proposed security schemes on offer, it is by far the worst. It doesn't even attempt to secure any part of the message visible to recipients, and it only works for the subset of mail that is sent from a fixed point to recipients who don't remail or forward it. (Despite endless claims by SPF's fans, that last part is a fundamental design failure of SPF, not of the mail system.) DKIM at least starts to address those problems, but it still doesn't begin to try to deal with the much harder problem of lookalike domains. Let's say you get a message from security@pay-pal.com, which is 100% DKIM, SPF, and Sender-ID approved. Is that Paypal? How can you tell short of manually looking up WHOIS registrations? R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 06:54:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AB128C13B; Tue, 20 Jan 2009 06:54:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B026628C13B for ; Tue, 20 Jan 2009 06:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] 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 Zow5lY+c03Bs for ; Tue, 20 Jan 2009 06:54:44 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id CABC628C0D9 for ; Tue, 20 Jan 2009 06:54:43 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59001) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRYVR-000BD2-2A for asrg@irtf.org; Tue, 20 Jan 2009 14:57:27 +0000 Date: Tue, 20 Jan 2009 14:54:27 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> Originator-Info: login-token=Mulberry:01hTt1xu6c4yvGqMko8WH4sOg567OWIOhh+qY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 09:02:31 -0500 Dotzero wrote: > > Why aren't they supposed to do that? Well, because they haven't delivered the message yet, for example. They might be about to forward it to another MTA. I know that Exim does most of its header manipulation before delivery. > How many MUAs are checking DKIM > signatures at the moment? Probably none, but it's an obvious thing to want to do, isn't it? Anyway, what's the point of delivering a message with DKIM signature that you've already broken. At least, you could remove the signature. > I can think of a numbe rof ISPs that are > adding headers to indicate various checks. From a DKIM perspective, > the less you sign the greater the risk. Don't do the body length (full > length that is)? Evil bad person can engate in replay attacks with > content of their choice. > > This is not only about what you prefer personally. This is about what > works generally. You work for a University. What percentage of your > endusers are checking DKIM? I'm going to take a wild leap and assert > that it approximates zero if it isn't actually zero. > > As far as I know, DKIM checking is happening at the MTA or in > association with the MTA (Seperate host behind the front line MTA or > something similar). It isn't happening at the user level. And that > makes sense, at least to me. Maybe in some distant future MUAs will do > DKIM checking but I wouldn't hold my breath. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 06:56:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF37A3A6BDA; Tue, 20 Jan 2009 06:56:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C2928C0D9 for ; Tue, 20 Jan 2009 06:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] 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 PaAWJHRGqjNm for ; Tue, 20 Jan 2009 06:56:50 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id C9F3D3A6921 for ; Tue, 20 Jan 2009 06:56:49 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59019) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDRYZ9-000C8Y-3B for asrg@irtf.org; Tue, 20 Jan 2009 14:59:33 +0000 Date: Tue, 20 Jan 2009 14:56:33 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <9566874E665E87C0E89DA756@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220901200549l61afc5c2ja141bf07b584f31a@mail.gmail.com> References: <4974E31F.6010808@terabites.com> <7ae58c220901191248j136b9b36o2f04ffe2827d1032@mail.gmail.com> <7ae58c220901200549l61afc5c2ja141bf07b584f31a@mail.gmail.com> Originator-Info: login-token=Mulberry:01Mz2nFpyeFXt0qvt4n2OmshqJmbXIcJZjqKg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 08:49:46 -0500 Dotzero wrote: > On Tue, Jan 20, 2009 at 7:00 AM, Ian Eiloart wrote: >> >> >> --On 19 January 2009 15:48:20 -0500 Dotzero wrote: >> >>> >>> If an enduser wants the flexibility to send from Kiosks or through >>> other MTAs and their company or mail provider allows this by policy >>> then the use of strong SPF assertions is likely inappropriate. My >>> response to you is the old saw about the person who goes tot he doctor >>> about a pain.... "Doctor, it hurts when I do that" ...... and the >>> Doctor says..... "Don't do that". >> >> In any case, you can use ~all. All I want to do is be able to whitelist >> email that's being sent by the usual methods from trusted sources. >> There's no reason that a Kiosk shouldn't be set up to use a webmail >> client. >> > > Of course there are reasons Ian. Read what I wrote. Sorry, I mis-read it. I guess we agree on this. > If your > organizations policy prohibits the use of kiosks in conjunction with > the account they provide you with, that would seem to be a pretty good > reason to me. Another good reason might be that shared computers > (including kiosks) have quite the track record of being compromised by > folks with ill intent. > > The fact that you can find some cases where some people choose to use > a kiosk does not change the fact that a persons use of an email > account is subject to the terms and conditions of use set by the owner > of the domain providing the account. If it's your domain or the > provider of your account says you cand o whatever youw ant then knock > your socks off. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:19:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615AF3A6BF7; Tue, 20 Jan 2009 07:19:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4CB3A6BE8 for ; Tue, 20 Jan 2009 07:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 zi6wq2GF+6F7 for ; Tue, 20 Jan 2009 07:19:46 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 06DC33A6A51 for ; Tue, 20 Jan 2009 07:19:46 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so3563537wfg.7 for ; Tue, 20 Jan 2009 07:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YzThISSdDiCQBoKjov8Q1DeWKAoFkIKqDIprPBXrEMI=; b=MhmH75T1KDn7jrD3DUUZyA3oX8YX/x95oiJONPixZPYcAw3EpURDd8EA5jXmGinTKW FeweZeywXVJtD1firK8iQWIIyrQflC0l+Mt7sqo+Xti5WqXw9y38BiJ+rxKy2uO9gVcQ 2P/GnNHTkq9pZ7zcsag2X0QFb+ajWt/2c5n5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BBW4yqGi0LimseApcJcSyl13PI5gDNZGecT35mrU75UtdOf7bnmj0ABbnoumqZrKDz pfAYK3YHpEyggPGBmaU7cN+gyJxN9Os6gIjAgM8HRHyfNzpa5iXjTVv4iMvg7eKDsZky zxOTKDcjpDXGw+smoj4gLHRLQFouAeUSw0UX4= Received: by 10.142.69.11 with SMTP id r11mr1127030wfa.28.1232464769867; Tue, 20 Jan 2009 07:19:29 -0800 (PST) Received: by 10.142.126.17 with HTTP; Tue, 20 Jan 2009 07:19:29 -0800 (PST) Message-ID: <7ae58c220901200719o673b822bkacfd1456c67126ba@mail.gmail.com> Date: Tue, 20 Jan 2009 10:19:29 -0500 From: Dotzero To: "Anti-Spam Research Group - IRTF" In-Reply-To: <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 9:54 AM, Ian Eiloart wrote: > > > --On 20 January 2009 09:02:31 -0500 Dotzero wrote: > >> >> Why aren't they supposed to do that? > > Well, because they haven't delivered the message yet, for example. They > might be about to forward it to another MTA. I know that Exim does most of > its header manipulation before delivery. > You are assuming facts not in evidence. They might also be about to be hit by an asteroid. >> How many MUAs are checking DKIM >> signatures at the moment? > > Probably none, but it's an obvious thing to want to do, isn't it? Anyway, > what's the point of delivering a message with DKIM signature that you've > already broken. At least, you could remove the signature. > Hmmm...I dunno..... maybe because the header they added says something like..... "DKIM check....PASS". that is, they are creating something that a human being can look at today and go....:"YEA! my ISP or Mail Admin cares enough about me to check DKIM AND to let me know what the otucome of the check was." I could see some people going "Damn my ISP or Mail Admin for breaking something today because at some distant point in the future I or someone else might want to take advantage of that". While the former might be a small number in relation to all users, the latter is probably a number orders of magnitude smaller again. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:26:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7556028C20C; Tue, 20 Jan 2009 07:26:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D883528C20B for ; Tue, 20 Jan 2009 07:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 oBv86LP7ZQNm for ; Tue, 20 Jan 2009 07:26:49 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B238E3A6C05 for ; Tue, 20 Jan 2009 07:25:54 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 20 Jan 2009 16:25:38 +0100 id 00000000005DC031.000000004975ECF2.00007ED5 Message-ID: <4975ECF1.3000000@tana.it> Date: Tue, 20 Jan 2009 16:25:37 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4974E31F.6010808@terabites.com> <49757961.6010107@tana.it> <20090120115708.GA11455@gsp.org> In-Reply-To: <20090120115708.GA11455@gsp.org> Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > On Tue, Jan 20, 2009 at 08:12:33AM +0100, Alessandro Vesely wrote: >> Since we are not able to come up with a definition of spam, we cannot >> define what is legitimate use either. > > The correct definition of spam has been well-known as "unsolicited bulk > email" for many years -- a definition that traces its lineage back to > the use of earlier, less precise terms such as "mail mail abuse" and > "junk mail" that were around in the early 1980's. Please, let's not > reopen this question here, as there is absolutely no need to do so given > that it's been covered in excruciating depth elsewhere. Although I like the first definition that you quoted, I think there must be a reason why it is not the official definition of spam given in the ASRG home page. I didn't mean to reopen that question. I was only pointing out that "legitimate use" can be defined as the complement of spam. Explicitly, mail is legitimate when it is either sent upon recipient's request, or not in bulk. Spam cannot be stopped because the software is not able to recognize the legitimacy of a message from the above definition. Actually, there is neither a registry of users' requests, nor a method for determining whether a stream of bytes has been handcrafted or produced in bulk. (Please note that while a few days of clerk work might suffice to define such a [distributed] registry, the latter method is plainly not feasible with current technology.) Some people apparently claim that if a message's transmission has been permitted by SPF, a DKIM signature proves that its headers have not been altered, and its content's PGP signature is verified, then the message is not spam. That claim is obviously false, according to any of the above definitions. The point I was trying to make with the short comment I posted earlier, is that the concept of legitimate use can be slightly refined so as to avoid that spammers inject their payload in our mailboxes without revealing their true identities. To that end, it is technically possible for a kiosk to correctly handle SPF+DKIM+PGP. However, none of those is mandated, and, if using obsolete equipment is considered legitimate, we're stuck to the '80s. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:28:33 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149E43A6BE8; Tue, 20 Jan 2009 07:28:33 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5C63A6BE8 for ; Tue, 20 Jan 2009 07:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.213 X-Spam-Level: X-Spam-Status: No, score=-9.213 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 AhxWbLu0OZZs for ; Tue, 20 Jan 2009 07:28:31 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id EF0A43A69F9 for ; Tue, 20 Jan 2009 07:28:30 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA06346; Tue, 20 Jan 2009 10:28:14 -0500 (EST) From: der Mouse Message-Id: <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 20 Jan 2009 10:23:32 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090120121015.GC11455@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Don't hold your breath. SPF is dead -- Interesting you should say that. Just yesterday I had to diagnose a mail bounce for someone; it proved to be a sender who advertised SPF with -all sending mail thorugh an alias expansion on my mailserver. (The really discouraging part is, what did the sending domain's admin do? Drop SPF? No; he added my machines to his SPF record!) > and good riddance, it was a very stupid idea -- Actually, it was a good idea, at the core. But the devil is in the details, and the details chosen were ones that, um, don't work well. > and a centralized reputation system of any kind would be a disaster. Strongly disgaree. There are almost as many centralized reputation systems out there right now as there are DNSBLs (some DNSBLs, such as noprimes, are not reputation systems), and the best of them are very far indeed from disasters. (Well, possibly excepting to those who want Atlas to shrug in this case.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:35:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A613C3A6929; Tue, 20 Jan 2009 07:35:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A343B3A68AC for ; Tue, 20 Jan 2009 07:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] 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 rq-KsH9FZYwz for ; Tue, 20 Jan 2009 07:35:50 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id AD85A3A6929 for ; Tue, 20 Jan 2009 07:35:50 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59565) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDS0SA-0004BQ-5L for asrg@irtf.org; Tue, 20 Jan 2009 15:38:34 +0000 Date: Tue, 20 Jan 2009 15:35:33 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <6258CE32FDAAAD4305BA332B@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220901200719o673b822bkacfd1456c67126ba@mail.gmail.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200719o673b822bkacfd1456c67126ba@mail.gmail.com> Originator-Info: login-token=Mulberry:01SwEjMLRikZWMbneStye+dpajsXlEiq4nwGw=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 10:19:29 -0500 Dotzero wrote: > On Tue, Jan 20, 2009 at 9:54 AM, Ian Eiloart wrote: >> >> >> --On 20 January 2009 09:02:31 -0500 Dotzero wrote: >> >>> >>> Why aren't they supposed to do that? >> >> Well, because they haven't delivered the message yet, for example. They >> might be about to forward it to another MTA. I know that Exim does most >> of its header manipulation before delivery. >> > > You are assuming facts not in evidence. They might also be about to be > hit by an asteroid. > >>> How many MUAs are checking DKIM >>> signatures at the moment? >> >> Probably none, but it's an obvious thing to want to do, isn't it? Anyway, >> what's the point of delivering a message with DKIM signature that you've >> already broken. At least, you could remove the signature. >> > > Hmmm...I dunno..... maybe because the header they added says something > like..... "DKIM check....PASS". that is, they are creating something > that a human being can look at today and go....:"YEA! my ISP or Mail > Admin cares enough about me to check DKIM AND to let me know what the > otucome of the check was." I could see some people going "Damn my ISP > or Mail Admin for breaking something today because at some distant Maybe not so distant: This is a plea from Dave Crocker (author of rfc822) to take a Thunderbird extension that checks spf and dk, and add support for dkim. > point in the future I or someone else might want to take advantage of > that". While the former might be a small number in relation to all > users, the latter is probably a number orders of magnitude smaller > again. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:40:14 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146A03A68AC; Tue, 20 Jan 2009 07:40:14 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5D13A68AC for ; Tue, 20 Jan 2009 07:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] 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 TsK2Z++DDKBI for ; Tue, 20 Jan 2009 07:40:12 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 2C88B3A67AC for ; Tue, 20 Jan 2009 07:40:12 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59589) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDS0ZJ-0005VB-NP for asrg@irtf.org; Tue, 20 Jan 2009 15:42:55 +0000 Date: Tue, 20 Jan 2009 15:39:55 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <09F395E191A8D05A65441AD9@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> Originator-Info: login-token=Mulberry:01E1QNYXy1e8ZUwWHDf3qGyYDUecwuu3Z6iL8=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 10:23:32 -0500 der Mouse wrote: >> Don't hold your breath. SPF is dead -- > > Interesting you should say that. Just yesterday I had to diagnose a > mail bounce for someone; it proved to be a sender who advertised SPF > with -all sending mail thorugh an alias expansion on my mailserver. > (The really discouraging part is, what did the sending domain's admin > do? Drop SPF? No; he added my machines to his SPF record!) With a "~" or "?" I hope. That's reasonable given that he'd got notice from a contactable administrator. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 07:50:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC0B3A6B69; Tue, 20 Jan 2009 07:50:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7D43A69F9 for ; Tue, 20 Jan 2009 07:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 b6XhOItgpX+U for ; Tue, 20 Jan 2009 07:50:22 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 81D873A6B69 for ; Tue, 20 Jan 2009 07:50:21 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7127733C59; Tue, 20 Jan 2009 10:50:05 -0500 (EST) Date: Tue, 20 Jan 2009 10:50:05 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090120155005.GJ24908@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090120145354.57509.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: > > Why do you keep harping on SPF? Of all of the proposed security > schemes on offer, it is by far the worst. SPF has been due for its 2-year review (of Experimental Status) for a while now. Hopefully it will get a useful review, and I choose to hope it will get enough of an overhaul to become useful. With some simple changes it could give a measured likelihood that a 5321-MailFrom deserves to be trusted for generating bounces -- a major win. > It doesn't even attempt to secure any part of the message visible to > recipients, Nor should it, IMHO. Other approaches are better for that. > and it only works for the subset of mail that is sent from a fixed point > to recipients who don't remail or forward it. This feature could be substantially mitigated in a number of ways. Unfortunately the Experimental spec freezes a moment in time where MARID was struggling with that issue (and others) without having time to reach a useful consensus. Fundamentally, of course, the attempt to have one-size-fits-all processing by the receiving MTA is dubious. It's not the coding of SPF records that breaks forwarding: it's the processing of them. Relaxing the processing rules could help a lot. > (Despite endless claims by SPF's fans, that last part is a fundamental > design failure of SPF, not of the mail system.) The original SPF design tried to be all things to all emailers -- a hopeless task. I think two years of experience in Experimental status has moderated that desire. And I see promise in the use of the pending Authentication-Results header (though I must agree with Doug Otis that it would be stronger if it included the IP address). > DKIM at least starts to address those problems, but it still doesn't > begin to try to deal with the much harder problem of lookalike > domains. Nor should it, IMHO. > Let's say you get a message from security@pay-pal.com, which is 100% > DKIM, SPF, and Sender-ID approved. Is that Paypal? How can you tell > short of manually looking up WHOIS registrations? Most folks couldn't tell if they _did_ look up WHOIS -- so at first blush I'd say that's the wrong question. Let's think about it differently. Why does phishing work? It works because the security of financial transactions depends on obviously insecure passwords (anything simple enough for average folks to remember _must_ be insecure) entered onto loosely secured websites. Compare that to ssh. Is there a record kept of what certificate is used? Are there obvious warnings when you start a session with a server whose certificate you've never seen before? Or even a warning when the certificate changes? More to the point: why do financial institutions depend upon code in browsers instead of calling a separate application for authentication? The quality of security in browsers varies from barely adequate to downright laughable (with a lot of customers using outdated browsers closer to the laughable end of that range). Is there actually any point in trying to solve phishing issues by verifying the origin of email if the customer is going to depend on a known-insecure web-browser? -- John Leslie _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 08:06:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E823A6B10; Tue, 20 Jan 2009 08:06:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F713A6B10 for ; Tue, 20 Jan 2009 08:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 J7V7UUziPuBt for ; Tue, 20 Jan 2009 08:06:08 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id AE64D3A69F9 for ; Tue, 20 Jan 2009 08:06:08 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 20 Jan 2009 17:05:49 +0100 id 00000000005DC02F.000000004975F65D.00000B52 Message-ID: <4975F65D.8030500@tana.it> Date: Tue, 20 Jan 2009 17:05:49 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org der Mouse wrote: >> Don't hold your breath. SPF is dead -- > > Interesting you should say that. Just yesterday I had to diagnose a > mail bounce for someone; it proved to be a sender who advertised SPF > with -all sending mail thorugh an alias expansion on my mailserver. > (The really discouraging part is, what did the sending domain's admin > do? Drop SPF? No; he added my machines to his SPF record!) (He probably did so because you provide no name to include...) Setting SPF records is error-prone, as there is no way to collect results of test carried out with the softfail (~) qualifier. >> and good riddance, it was a very stupid idea -- > > Actually, it was a good idea, at the core. But the devil is in the > details, and the details chosen were ones that, um, don't work well. Yet, if the idea was good, it might be worth to rescue it. There is not such an abundance of good ideas at the transfer level to throw away the ones that don't work smoothly right from the start. And it is fair to note that, for some reasons, SPF is still in its experimental infancy. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 08:13:25 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B18E3A6993; Tue, 20 Jan 2009 08:13:25 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055E63A6993 for ; Tue, 20 Jan 2009 08:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 ia+N+Sol+U76 for ; Tue, 20 Jan 2009 08:13:23 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id F3E163A6929 for ; Tue, 20 Jan 2009 08:13:22 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59918) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDS2IU-000IP4-DJ for asrg@irtf.org; Tue, 20 Jan 2009 16:16:06 +0000 Date: Tue, 20 Jan 2009 16:13:05 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090120121015.GC11455@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> Originator-Info: login-token=Mulberry:01f4M3uejkpR7A8Isb66ny+Kos5ftYE+Kp9O4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 07:10:15 -0500 Rich Kulawiec wrote: > On Tue, Jan 20, 2009 at 11:49:40AM +0000, Ian Eiloart wrote: >> Only when DKIM and SPF are in wider use will a centralised >> reputation system be very useful. > > Don't hold your breath. SPF is dead -- and good riddance, it was a very > stupid idea -- and a centralized reputation system of any kind would > be a disaster. It's one of the very last things anyone who is actually > opposed to spam should ever want to see happen. So dead that of hotmail.com, gmail.com, mac.com, apple.com, microsoft.com, facebook.com, ebay.com only er..., all of them publish SPF records. Hmm, lets take a look at the email I've received today. These are the top 20 domains that have delivered to one of my cluster machines. Several of the domains do use -all in their records, but most don't. Facebookmail.com top the list at 10% of inbound mail. They do publish spf records. Of the rest, three yahoo domains, and one other don't have spf records. One is ours, one is null (bounces), and the remaining 13 domains all do publish spf records. The 14 domains in the top 20 account for 28% of all the email that we accepted for delivery. That's certainly enough to justify building a local whitelisting mechanism against. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 08:28:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5B83A69CD; Tue, 20 Jan 2009 08:28:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0003A69CD for ; Tue, 20 Jan 2009 08:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.237 X-Spam-Level: X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 ew1b2WaLmaJR for ; Tue, 20 Jan 2009 08:28:47 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id E74543A6947 for ; Tue, 20 Jan 2009 08:28:46 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA06736; Tue, 20 Jan 2009 11:28:29 -0500 (EST) From: der Mouse Message-Id: <200901201628.LAA06736@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 20 Jan 2009 11:24:54 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <4975ECF1.3000000@tana.it> References: <4974E31F.6010808@terabites.com> <49757961.6010107@tana.it> <20090120115708.GA11455@gsp.org> <4975ECF1.3000000@tana.it> Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > I was only pointing out that "legitimate use" can be defined as the > complement of spam. That is a very dangerous idea, actually. There is a lot of abusive or otherwise illegitimate use that is not bulk and therefore not spam. Abuse _on_ the net, not abuse _of_ the net. Dividing the world into "spam" and "legitimate" leads to shoehorning all other mail into ojne of those two categories, and neither one is a good fit. (As a simple exmaple of such mail, consider a social-engineering attack, targeted to a particular person, carried out via forged email. Abusive and illegitimate, but definitely not spam because not bulk.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 08:32:39 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D0F3A6BE3; Tue, 20 Jan 2009 08:32:39 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37653A6BE3 for ; Tue, 20 Jan 2009 08:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.26 X-Spam-Level: X-Spam-Status: No, score=-9.26 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 pKytK-PYlFEu for ; Tue, 20 Jan 2009 08:32:38 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id BDBBD3A69CD for ; Tue, 20 Jan 2009 08:32:37 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA06768; Tue, 20 Jan 2009 11:32:20 -0500 (EST) From: der Mouse Message-Id: <200901201632.LAA06768@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 20 Jan 2009 11:28:57 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <09F395E191A8D05A65441AD9@lewes.staff.uscs.susx.ac.uk> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <200901201528.KAA06346@Sparkle.Rodents-Montreal.ORG> <09F395E191A8D05A65441AD9@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> (The really discouraging part is, what did the sending domain's >> admin do? Drop SPF? No; he added my machines to his SPF record!) > With a "~" or "?" I hope. No; just s/-all/mx:rodents-montreal.org &/ (You might find this more reasonable when you know that the admin in question and I have known one another personally for years.) But his competence at writing SPF records is not my real point. My point is that this is an example of a sender and a different receiver who have SPF in live use today. Misguided, perhaps; broken, perhaps - but "dead" seems to me to be overstating the case. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 08:35:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE6628C0DF; Tue, 20 Jan 2009 08:35:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D954928C0DF for ; Tue, 20 Jan 2009 08:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 85w79TtQti+t for ; Tue, 20 Jan 2009 08:35:28 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id E5F6E3A6BE3 for ; Tue, 20 Jan 2009 08:35:27 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60114) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDS3JN-00040E-IG for asrg@irtf.org; Tue, 20 Jan 2009 16:38:11 +0000 Date: Tue, 20 Jan 2009 16:35:11 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <98068CD58CEC28800BA35B59@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090120155005.GJ24908@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> Originator-Info: login-token=Mulberry:01fNA5yOUxpy29PY0q6PbvRaw74khaIt/28Ts=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 10:50:05 -0500 John Leslie wrote: > John Levine wrote: >> >> Let's say you get a message from security@pay-pal.com, which is 100% >> DKIM, SPF, and Sender-ID approved. Is that Paypal? How can you tell >> short of manually looking up WHOIS registrations? Well, without all those technologies, it's simple to simply use paypal's domain. Then there's no clue. Now, if you use a look-alike domain name, then you're probably violating the trademark. That's illegal, so your ESP and your mail client will be quite justified in looking for domains that are similar to ones that you trust. That list might come from several sources - trademark registrars, your address book, your whitelist, and so on. > Most folks couldn't tell if they _did_ look up WHOIS -- so at first > blush I'd say that's the wrong question. > > Let's think about it differently. > > Why does phishing work? > > It works because the security of financial transactions depends on > obviously insecure passwords (anything simple enough for average folks > to remember _must_ be insecure) entered onto loosely secured websites. > > Compare that to ssh. Is there a record kept of what certificate is > used? Are there obvious warnings when you start a session with a > server whose certificate you've never seen before? Or even a warning > when the certificate changes? > > More to the point: why do financial institutions depend upon code in > browsers instead of calling a separate application for authentication? Because, when the security is breached the customer pays. That needs to change. Make the banks liable for frauds that are committed against them, and then they'll start taking it seriously. They'll block insecure browsers, and the browser authors will be forced to catch up. The downside is that it's their poorest customers who may be forced to pay for hardware or o/s upgrades. There's also a risk that they might decide to only support one browser. > The quality of security in browsers varies from barely adequate to > downright laughable (with a lot of customers using outdated browsers > closer to the laughable end of that range). > > Is there actually any point in trying to solve phishing issues by > verifying the origin of email if the customer is going to depend on > a known-insecure web-browser? > > -- > John Leslie > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 09:04:13 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A8B3A69D5; Tue, 20 Jan 2009 09:04:13 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7D93A69D5 for ; Tue, 20 Jan 2009 09:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 h7V4+x29gPOk for ; Tue, 20 Jan 2009 09:04:11 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 747BE3A6982 for ; Tue, 20 Jan 2009 09:04:11 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0KH3pc08950 for ; Tue, 20 Jan 2009 17:03:51 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 12:03:50 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 20 Jan 2009 12:03:50 -0500 Message-ID: <497603F5.6060600@nortel.com> Date: Tue, 20 Jan 2009 12:03:49 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200719o673b822bkacfd1456c67126ba@mail.gmail.com> <6258CE32FDAAAD4305BA332B@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <6258CE32FDAAAD4305BA332B@lewes.staff.uscs.susx.ac.uk> X-OriginalArrivalTime: 20 Jan 2009 17:03:50.0821 (UTC) FILETIME=[111FE550:01C97B21] Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > Maybe not so distant: > > > This is a plea from Dave Crocker (author of rfc822) to take a Thunderbird > extension that checks spf and dk, and add support for dkim. I remember that and the plea. The plugin didn't do SPF. It couldn't do SPF, because it didn't have access to either the MAIL FROM or HELO/EHLO. It did something similar to SPF (From:). Even to get it to do From: "properly" required intimate knowledge of your mail server architecture. You could make it do SPF properly if you hacked your MTAs to add various headers showing details about the perimeter connection (HELO, IP, rDNS, MAIL FROM). We do insert such info, but it obviously wasn't going to be worthwhile hacking the plugin to recognize our additional headers. The DK stuff didn't work at all AFAIK. It was an experiment. As an experiment, I believe it died. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 09:21:50 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FEA3A6AFD; Tue, 20 Jan 2009 09:21:50 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8353A6AFD for ; Tue, 20 Jan 2009 09:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 UfSb095lkb1l for ; Tue, 20 Jan 2009 09:21:48 -0800 (PST) Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id D9E3D3A69D5 for ; Tue, 20 Jan 2009 09:21:47 -0800 (PST) Received: by zeno.hjp.at (Postfix, from userid 1000) id B1EB4D015; Tue, 20 Jan 2009 18:21:30 +0100 (CET) Date: Tue, 20 Jan 2009 18:21:30 +0100 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20090120172130.GA32423@hjp.at> References: <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 In-Reply-To: <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0605905646==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============0605905646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-01-20 11:30:33 +0000, Ian Eiloart wrote: > --On 20 January 2009 08:34:51 +0100 Alessandro Vesely =20 > wrote: >=20 > >Daniel Feenberg wrote: > >>On Mon, 19 Jan 2009, Paul Russell wrote: > >>>On 1/19/2009 10:38 AM, Ian Eiloart wrote: > >>>>1. You can bounce selectively. > >>> > >>>I know that sendmail can be configured to accept for one recipient and > >>>reject for another recipient. > >> > >>Sendmail can selectively reject receipients while processing "RCPT TO:" > >>commands, but not after the header and body are received. > >>[...] > >>As I understand it, this is a consequence of the SMTP > >>protocol, and not something that sendmail can program around. > > > >Given a set of recipients (r1, r2, ..., rn) the server can partition it > >in subsets that have homogeneous filtering recipes. It does that in > >steps. Each step consists in responding 250 for r1 and any other > >recipient with identical filtering, 4xx to the rest. >=20 > Yes, that's the scheme I was referring to. It can be implemented with my= =20 > MTA - Exim. However, if any filter subset doesn't want the message, then= =20 > you should give a 5yz response after seeing the body. RFC2821 says that t= he=20 > sending MTA "SHOULD not again attempt delivery to the same server without= =20 > user review and intervention of the message".=20 > I guess most MTA's= =20 > aren't RFC2821 compliant in that respect. I'm not sure how you interpret this sentence. Consider: MAIL FROM: 250 ok RCPT TO: 250 ok RCPT TO: 450 try again later DATA 354 send message =2E.. 550 message rejected Should the client assume a permanent failure for both recipients? Or should it assume a permanent failure only for and requeue the message for ?=20 >=20 > RFC 5321 says the client "may either return it to the user or requeue it= =20 > for a subsequent attempt". That's an improvement, Erm, that's for a 4xx reply. I am quite certain that RFC 5321 did not intend any semantic changes relative to RFC 2821. All changes are only meant to clarify. > there's no guarantee that members of the second and subsequent subsets > will ever see the message. If they do, it will be after a delay that > many people find unacceptable. > If the number of subsets is large enough, you may even exceed the retry= =20 > timeout on the sending MTA, so a large site had better not have too many= =20 > filter recipes. Right. That's why I didn't consider looking at "filter recipies", when I implemented a similar scheme for qpsmtpd. Instead I look at the result. There are only 2 different results: Accept or reject, so unless the result changes between delivery attempts (which can happen if e.g., a blackist is updated or a recipient changes a rule), there are at most three delivery attempts: 1) The results of the content filters for the different recipients don't agree. Use the results to split the recipients into two sets. 2) All the recipients from set1 get 2xx reply to RCPT, all the=20 recipients from set2 get a 4xx reply. Now the results of the content filters for all recipients agree (they are all from set1), so we can reply with either 2xx or 5xx. 3) All the remaining recipients are now from set2, so the content filters agree again, and we can again reply with 2xx or 5xx. (the actual implementation is a little bit more complicated, but that's the basic idea). For most mails, the content filters of all recipients agree on the result, so the mail can be accepted or rejected at the first delivery attempt. It's a really ugly hack, but it works quite nicely. hp --=20 _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJdggafZ+RkG8quy0RAveNAJwO4yYtefGWzjjkoptLuKgHSNjgjwCfVO+J nubif4zPMKi48dy4WdIwLnA= =Xk4Y -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- --===============0605905646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0605905646==-- From asrg-bounces@irtf.org Tue Jan 20 09:42:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DFC3A69EA; Tue, 20 Jan 2009 09:42:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD963A690D for ; Tue, 20 Jan 2009 09:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MPQ2UsAKtIBR for ; Tue, 20 Jan 2009 09:42:18 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 3A36F3A69EA for ; Tue, 20 Jan 2009 09:42:18 -0800 (PST) Received: from [192.168.1.64] (75-25-136-172.lightspeed.plalca.sbcglobal.net [75.25.136.172]) by m.wordtothewise.com (Postfix) with ESMTP id 6E4F180D22 for ; Tue, 20 Jan 2009 09:41:56 -0800 (PST) Message-Id: <8E2D9209-46F6-456A-B0BF-313DE193EDED@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <20090120115708.GA11455@gsp.org> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 09:41:55 -0800 References: <4974E31F.6010808@terabites.com> <49757961.6010107@tana.it> <20090120115708.GA11455@gsp.org> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] SPF and other bad ideas X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 20, 2009, at 3:57 AM, Rich Kulawiec wrote: > On Tue, Jan 20, 2009 at 08:12:33AM +0100, Alessandro Vesely wrote: >> Since we are not able to come up with a definition of spam, we cannot >> define what is legitimate use either. > > The correct definition of spam has been well-known as "unsolicited > bulk > email" for many years -- a definition that traces its lineage back to > the use of earlier, less precise terms such as "mail mail abuse" and > "junk mail" that were around in the early 1980's. Actually, no. The "correct" definition of spam varies depending on the context you're using the term in. Which is one of the reasons it's a good idea to avoid the term entirely, and instead be specific in your terminology. > Please, let's not > reopen this question here, as there is absolutely no need to do so > given > that it's been covered in excruciating depth elsewhere. That I can agree with. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 09:50:08 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8AC3A6B38; Tue, 20 Jan 2009 09:50:08 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550003A6B38 for ; Tue, 20 Jan 2009 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.281 X-Spam-Level: X-Spam-Status: No, score=-9.281 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 1Ar9Fgx07t7s for ; Tue, 20 Jan 2009 09:50:06 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 3C3AC3A690D for ; Tue, 20 Jan 2009 09:50:06 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA07139; Tue, 20 Jan 2009 12:49:49 -0500 (EST) From: der Mouse Message-Id: <200901201749.MAA07139@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 20 Jan 2009 12:45:20 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090120172130.GA32423@hjp.at> References: <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > [Assuming no config changes], there are at most three delivery > attempts: This doesn't look right. > 1) The results of the content filters for the different recipients > don't agree. Use the results to split the recipients into two > sets. > 2) All the recipients from set1 get 2xx reply to RCPT, all the > recipients from set2 get a 4xx reply. Now the results of the > content filters for all recipients agree (they are all from set1), > so we can reply with either 2xx or 5xx. Right so far. > 3) All the remaining recipients are now from set2, Yes. > so the content filters agree again, No - or rather, not necessarily, not unless you have only two possible filtering setups. All we know about set2 is that their filtering choices differ from those of set1. We have no particular reason to think that set2 is uniform within itself (unless, as I said, there are only two choices possible). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 11:02:19 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE30E3A6878; Tue, 20 Jan 2009 11:02:19 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004A03A6942 for ; Tue, 20 Jan 2009 11:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 belgbBhXPv4j for ; Tue, 20 Jan 2009 11:02:18 -0800 (PST) Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id A9C633A6878 for ; Tue, 20 Jan 2009 11:02:17 -0800 (PST) Received: by zeno.hjp.at (Postfix, from userid 1000) id D96FBD015; Tue, 20 Jan 2009 20:01:59 +0100 (CET) Date: Tue, 20 Jan 2009 20:01:59 +0100 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20090120190159.GB32423@hjp.at> References: <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> <200901201749.MAA07139@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 In-Reply-To: <200901201749.MAA07139@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0773663152==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============0773663152== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-01-20 12:45:20 -0500, der Mouse wrote: > > [Assuming no config changes], there are at most three delivery > > attempts: >=20 > This doesn't look right. As I wrote, the actual algorithm is more complicated. If you are really interested, you can get the perl source code from http://www.hjp.at/projekte/qpsmtpd/cf_wrapper/. But I'll explain a little more below. > > 1) The results of the content filters for the different recipients > > don't agree. Use the results to split the recipients into two > > sets. >=20 > > 2) All the recipients from set1 get 2xx reply to RCPT, all the > > recipients from set2 get a 4xx reply. Now the results of the > > content filters for all recipients agree (they are all from set1), > > so we can reply with either 2xx or 5xx. >=20 > Right so far. >=20 > > 3) All the remaining recipients are now from set2, >=20 > Yes. >=20 > > so the content filters agree again, >=20 > No - or rather, not necessarily, not unless you have only two possible > filtering setups. All we know about set2 is that their filtering > choices differ from those of set1. Yup. So for this particular message (unless the setup has changed in the mean time) if the result for set1 was "accept", for set2 it must be "reject" and vice versa. (If the setup does change, it can affect delivery attempt 2 just the same as attempt 3 - if it does happen, new sets are created and a 4xx reply is returned - theoretically that can continue until there is only one recipient left) > We have no particular reason to think that set2 is uniform within > itself (unless, as I said, there are only two choices possible). There are, if we are only interested acception/rejection of the message. You cannot include specific messages, of course (currently I just concatenate all the rejection reasons into a single message). The real problem is in the phrase "this particular message". At the time the server receives the first "RCPT TO:" command it has no way to know that this is a new delivery attempt for a message which was temporarily rejected earlier, much less which message (envid is per-transaction, and you couldn't rely on the client sending it anyway). So, as a weak approximation, I use sender/recipient pairs instead of message/recipient pairs as elements of the sets. This works quite well because a recipient usually wants to receive all messages from a specific sender or none. But yes, theoretically it can happen that the sets are split again and again until each recipient is in a set of their own. In practice I haven't seen it yet (after more than 3 years, but admittedly on a relatively small number of email addresses). hp --=20 _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJdh+nfZ+RkG8quy0RAnaWAKCaUunrehQnI5gRxf077lnEA04viQCaAxyt Pz/Xs5GklpsrM3q3XCR/Qj4= =7mKd -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- --===============0773663152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0773663152==-- From asrg-bounces@irtf.org Tue Jan 20 11:40:57 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B753A6895; Tue, 20 Jan 2009 11:40:57 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135DD3A6895 for ; Tue, 20 Jan 2009 11:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 OcABqYM-Sipt for ; Tue, 20 Jan 2009 11:40:55 -0800 (PST) Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id DC3323A684B for ; Tue, 20 Jan 2009 11:40:54 -0800 (PST) Received: by zeno.hjp.at (Postfix, from userid 1000) id C1D1FD015; Tue, 20 Jan 2009 20:40:37 +0100 (CET) Date: Tue, 20 Jan 2009 20:40:37 +0100 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20090120194037.GC32423@hjp.at> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 In-Reply-To: <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0217839075==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --===============0217839075== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-01-20 13:26:48 +0000, Ian Eiloart wrote: > Anyway, it's almost always embedded in some other message. Does anyone kn= ow=20 > of an MTA that doesn't add something to a reject message when generating = a=20 > bounce message? Would such a bounce be of any value? A MTA conforming to RFC 3462 is required to include a human-readable explanation as the first part of the message. Theoretically that could consist of the single sentence: "This message could not be delivered, see below for details". But I don't know of any MTA which is so minimalistic. All of them try to be helpful by adding an explanation, tips, etc. BTW, I do collect DSNs at http://www.hjp.at/mail/dsn/index.en.rxml If you have some particularly nice or nasty specimens, I'll be happy to add them to the collection. > I don't buy the argument that an MTA that mangles reject messages (that= =20 > requires little or no administrative effort) will also mangle bounce=20 > messages (that requires more effort). I assume with "reject message" you mean the text in a 5xx reply, and with "mangle reject message" you mean "doesn't include the complete reject message in the DSN it generates, and/or adds a confusing "explanation" (like "Recipient doesn't exist" for "550 Message from 61.251.173.243 rejected, because it is listed in XBL/CBL."). With "bounce message" you mean a DSN conforming to RFC 3462 or an equivalent message in a non-standardized format. > Perhaps I'm wrong. Does anyone know=20 > of an MTA that mangles bounce messages in its default configuration? Lotus Domino. It removes the first (human-readable) part of any RFC 3462 conforming DSN and replaces it with a "user-friendly" explanation, which usually has nothing to do with the problem. It also completely mangles the Received lines in the third part (the headers of the bounced message). At least it leaves the second part alone so you usually know why the message was rejected, unless you are already confused by the 1st part (which most users are). [If anybody knows how that can be turned off, please tell me - it's driving me nuts] hp --=20 _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJdii1fZ+RkG8quy0RAiEPAJ9wPDZpyvMyAM6GVtxXKwr2TX+YkQCgn3TE L3vh+qR1eWXLGKf/PFZ8jU8= =2KbV -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- --===============0217839075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0217839075==-- From asrg-bounces@irtf.org Tue Jan 20 11:44:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13183A6989; Tue, 20 Jan 2009 11:44:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F043A69CF for ; Tue, 20 Jan 2009 11:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8OKeHPVTwv8D for ; Tue, 20 Jan 2009 11:44:50 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 14AAE3A684B for ; Tue, 20 Jan 2009 11:44:49 -0800 (PST) Received: from [192.168.0.4] (ppp-68-120-199-27.dsl.pltn13.pacbell.net [68.120.199.27]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0KJiQmP031541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jan 2009 11:44:32 -0800 Message-ID: <4976299A.7060502@dcrocker.net> Date: Tue, 20 Jan 2009 11:44:26 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090120145354.57509.qmail@simone.iecc.com> In-Reply-To: <20090120145354.57509.qmail@simone.iecc.com> X-Virus-Scanned: ClamAV 0.92/8881/Tue Jan 20 06:48:51 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Jan 2009 11:44:32 -0800 (PST) Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: > DKIM at least starts to address those problems, but it still doesn't > begin to try to deal with the much harder problem of lookalike > domains. Let's say you get a message from security@pay-pal.com, which > is 100% DKIM, SPF, and Sender-ID approved. Is that Paypal? How can > you tell short of manually looking up WHOIS registrations? Two points: 1. The word "security" is not all that helpful in these discussions. To security technology experts, it means too many things to know what is meant in a particular case. To the rest of us, it carries too little precise meaning. 2. Almost all of the discussions about these authentication-related technologies start with the authenticated identifier and then talk about what you can derive from it or how it might be spoofed or otherwise abused. Since that is exactly what must be done with suspect messages, the model seems to make sense to (re-)apply for authentication. I now believe it is exactly the wrong model. That's a model that looks for the problem, the attack, the basis for suspicion. A very different model starts as a model of trust and specifies a table of who is part of the model. In other words, it works in the oppsoite direction. When a message shows up, the only question is whether that message falls under that umbrella of trust. If it doesn't, then we are done with that model, for that message. Any further consideration of that message has nothing at all to do with the trust model. The authenticated identifier is the sole, simple lookup string into that the model. Either the identifier string works or it doesn't. Concerns about spoofing the identifier, re-purposing its use, and corrupting the content -- authentication, authorization and data and signature integrity -- are all valid for evaluating the underlying technology but they really are secondary to any serious discussion of the model. After the briefest review to ensure that a particular technology has made specific and acceptable choices for the "security" questions, the questions should not burden debate about use of the technology. Instead we seem to find these questions hashed, rehashed and hashed again, as the focus of community debate. When the anti-abuse world discusses use of these authentication technologies, we need to stop being the anti-abuse world and start being the trust world. The anti-abuse world really has the receiving assessor as an isolated island of suspicious. In today's Internet, that's required. But the trust world is quite different. It is collaborative -- between signer and receiving assessor -- and deterministic, rather than vague and heuristic, and strictly the effort of the receiving assessor. Totally different model. So we need a totally different approach to talking about it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 12:02:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771253A6AFD; Tue, 20 Jan 2009 12:02:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115743A6841 for ; Tue, 20 Jan 2009 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4kQV+Lh-zWe6 for ; Tue, 20 Jan 2009 12:02:18 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CA1313A68B4 for ; Tue, 20 Jan 2009 12:01:07 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0KK0mU28164 for ; Tue, 20 Jan 2009 20:00:48 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 15:00:45 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 20 Jan 2009 15:00:45 -0500 Message-ID: <49762D6C.1010902@nortel.com> Date: Tue, 20 Jan 2009 15:00:44 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> <20090120194037.GC32423@hjp.at> In-Reply-To: <20090120194037.GC32423@hjp.at> X-OriginalArrivalTime: 20 Jan 2009 20:00:45.0480 (UTC) FILETIME=[C7F45280:01C97B39] Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Peter J. Holzer wrote: > I assume with "reject message" you mean the text in a 5xx reply, and > with "mangle reject message" you mean "doesn't include the complete > reject message in the DSN it generates, and/or adds a confusing > "explanation" (like "Recipient doesn't exist" for "550 Message from > 61.251.173.243 rejected, because it is listed in XBL/CBL."). I also see exchange spitting back "site didn't give a reason", and then there's the full reason string (including SMTP extended error codes) further down. >> Perhaps I'm wrong. Does anyone know >> of an MTA that mangles bounce messages in its default configuration? > > Lotus Domino. It removes the first (human-readable) part of any RFC 3462 > conforming DSN and replaces it with a "user-friendly" explanation, which > usually has nothing to do with the problem. It also completely mangles > the Received lines in the third part (the headers of the bounced > message). At least it leaves the second part alone so you usually know > why the message was rejected, unless you are already confused by the 1st > part (which most users are). [If anybody knows how that can be turned > off, please tell me - it's driving me nuts] We've also seen Exchange replacing site names in DSNs that were _manually_forwarded_. Same DSN, when manually forwarded to two different places (one with Exchange, one without) are _different_. Exchange (2007 methinks, not sure) substitutes in its own server name. Makes you freak out when it's a DSN for an email that NEVER went anywhere near your servers and had nothing to do with you. [IOW: something like: user sends email from Yahoo to MSN, and gets a bounce. Forwards it to me for explanation, and the enclosed DSNs say _our_ server issued the bounce. WTF?] _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 16:57:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992EA3A6A7C; Tue, 20 Jan 2009 16:57:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171943A6A81 for ; Tue, 20 Jan 2009 16:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.461 X-Spam-Level: X-Spam-Status: No, score=-14.461 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, SARE_BIZOP=0.7] 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 i8d67G6RW9sh for ; Tue, 20 Jan 2009 16:57:19 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 2487F3A6A72 for ; Tue, 20 Jan 2009 16:57:18 -0800 (PST) Received: (qmail 43039 invoked from network); 21 Jan 2009 00:57:00 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 21 Jan 2009 00:57:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=AXkL3LsaqVJHTj5UhZ37iOk/9z3dgQYqLTsvSDbEFwk=; b=JqYDFDoBnbne/roMePvY+gPdB2Sv9RPDsVpIgF39LO6P4rm5tit/Ht4unfXP8I2kyhvZSrFpSv2gStlZLZm89nfxep7KjKd+vk97hc5X7GmMmouKMmlkAUb1lhNkTr6HdIChAj+gvAqVUUvLlwrAW+jq7R3uM1XJRWQQbcv4OhE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=AXkL3LsaqVJHTj5UhZ37iOk/9z3dgQYqLTsvSDbEFwk=; b=H1FwE2W64Wjch4fI/tU8jk/EIyODexN3tIUHvPjJdKUzCGaoM1AkzTsl9OlvppkLVbhNcDEb2hIFY3XFOh+kj8bASWBunEY7wo4qRdCbfHXvdwJcp0HM9RiKsSxkl60YXhhmaedAsxuKh9Mjn4JZxuPFlYyOuksw/FSEwgCbY78= Date: 21 Jan 2009 00:56:55 -0000 Message-ID: <20090121005655.5954.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <98068CD58CEC28800BA35B59@lewes.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >>> Let's say you get a message from security@pay-pal.com, which is 100% >>> DKIM, SPF, and Sender-ID approved. Is that Paypal? How can you tell >>> short of manually looking up WHOIS registrations? > >Well, without all those technologies, it's simple to simply use paypal's >domain. Then there's no clue. Now, if you use a look-alike domain name, >then you're probably violating the trademark. That's illegal, ... Uh, dude, we're talking about phishing here. If that's not already illegal in Australia, I think I've found a major recession-resistant business opportunity. R's, John PS: >> Is there actually any point in trying to solve phishing issues by >> verifying the origin of email if the customer is going to depend on >> a known-insecure web-browser? Maybe. One of my bank accounts requires me to use a physical dongle to generate a code number. I expect in the future they'll give you a USB dongle with a small screen and a couple of buttons so you do most of your banking session on the computer, but when you hit go, the dongle lights up with the details of the transaction the bank is about to do and you have to push YES or NO on the dongle to confirm. That seems like it could be made reasonably secure. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 17:04:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4D83A6A72; Tue, 20 Jan 2009 17:04:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B983A6A72 for ; Tue, 20 Jan 2009 17:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.806 X-Spam-Level: X-Spam-Status: No, score=-14.806 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 d1g7dmmmrMZ7 for ; Tue, 20 Jan 2009 17:04:45 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 5119D3A6A6F for ; Tue, 20 Jan 2009 17:04:45 -0800 (PST) Received: (qmail 47843 invoked from network); 21 Jan 2009 01:04:30 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 21 Jan 2009 01:04:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=r3iqmOHhpoHLoazub5SpZgnv3olvKHklwmYwHPj6KkA=; b=OqJqOXfuAvnvflTMY5aEcpRZpKF0V8AQ99rZRsMFIlRk5TGUspivtSM3H0PN4rMyHPvvOjC5VYqyv+PfkQ6ap3UoUgF0QRJpXi774YcAg5yw4Bzcbai6eE/jp8tPGaDTt2uzAguT7jEdWL5lBgFO5JbFjLMxWwiDXbrodE7RhAg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=r3iqmOHhpoHLoazub5SpZgnv3olvKHklwmYwHPj6KkA=; b=QSX9z38ebIVGME9jEnfBeKDLdw9MAk82pAoqPlM1CWI4f9vHMQNS7lfSqILiiAbuUngiS2Q05jAvcVwoA/JtVbqmPPR5Hba7gjoZS7YUtix3p3CrLeFyPfPYtcBO2s070j683u0mZ2dmfTi6CmAiabq9m5ObWncNgsK8rhuz94s= Date: 21 Jan 2009 01:04:27 -0000 Message-ID: <20090121010427.7829.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> Don't hold your breath. SPF is dead -- and good riddance, it was a very >> stupid idea -- > >So dead that of hotmail.com, gmail.com, mac.com, apple.com, microsoft.com, >facebook.com, ebay.com only er..., all of them publish SPF records. For largely political reasons, Hotmail requires anyone sending a significant amount of mail to them to have Sender-ID records. For senders that are on its whitelist, AOL reverse engineers the IP addresses to whitelist from the sender's SPF records, which is way easier all around than the former mostly manual system. Since S-ID falls back to SPF records, most senders just publish one set of SPF records for both. Note that neither of these are using SPF for its nominal purpose; I'm not aware of any large system that does. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 17:05:39 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F2328C0F3; Tue, 20 Jan 2009 17:05:39 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D8328C12F for ; Mon, 19 Jan 2009 17:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.294 X-Spam-Level: X-Spam-Status: No, score=-3.294 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 2PKIJjTbcjVE for ; Mon, 19 Jan 2009 17:02:22 -0800 (PST) Received: from email.curtin.edu.au (exfe2.curtin.edu.au [134.7.32.166]) by core3.amsl.com (Postfix) with ESMTP id 66F5E3A6A24 for ; Mon, 19 Jan 2009 17:02:21 -0800 (PST) Received: from exmsp4.staff.ad.curtin.edu.au ([134.7.178.18]) by email.curtin.edu.au with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 10:02:02 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 10:02:02 +0900 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP - Special Session on Web Spam in IEEE DEST 2009, Istanbul, Turkey, 1-3 June 2009 Thread-Index: Acl6mrPPU9bAbkGfQfq1yswVDhwoUg== From: "Vidyasagar Potdar" To: X-OriginalArrivalTime: 20 Jan 2009 01:02:02.0394 (UTC) FILETIME=[B438BFA0:01C97A9A] X-Mailman-Approved-At: Tue, 20 Jan 2009 17:05:37 -0800 Subject: [Asrg] CFP - Special Session on Web Spam in IEEE DEST 2009, Istanbul, Turkey, 1-3 June 2009 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0741150239==" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org This is a multi-part message in MIME format. --===============0741150239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A9A.B45F46FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A9A.B45F46FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Apologies if you receive this more than once] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Call for Paper Adversarial Information Retrieval in Digital Ecosystems with focus on Web Spam IEEE International Conference on Digital Ecosystems and Business Intelligence (IEEE-DEST 2009) Istanbul, Turkey, June 1-3, 2009 http://dest2009.debii.curtin.edu.au/index.php?option=3Dcom_content&task=3D= vi ew&id=3D26&Itemid=3D40 ******************************************************************* Full Research Paper Due: ** February 1 **, 2009 The first AIR-DE-WS 2009 workshop will be held along with the 3rd IEEE Digital Ecosystems and Business Intelligence Conference to be held in Istanbul, Turkey. Web spam has become a major problem for quality and sustainability of digital ecosystems. There has been a strong competition between spammers and anti-spam filters to control spam. As anti-spam filters improve their capability to detect spam, spammers find new way to bypass these anti-spam filters. It not only waste's computer and network resources but also it decreases the reliability of the content available on the Internet. The main purpose of this workshop is to identify and explore different issues and challenges related to web spam within the digital environment. It also aims at increasing the synergy between academic and industrial practitioners. We are interested in experimental, systems-related, theoretical, and work-in-progress papers in all aspects of web spam. Topics of interest include, but are not limited to, the following:=20 Web Spam - Splog (Spam over weblogs) - Spamdexing (Spam aim on search engine algorithms) - Review/Opinion spam - Social-network spam (Spam over social network websites) - Comment spam - Tag spam - Wiki spam - Image spam Communication Spam - SPIT (Spam over Internet telephony) - SPIM (Spam over instant messenger) - Email spam - Phishing Other - Machine Learning & Natural language processing in Spam Detection - Adversarial learning - Challenge-response Important Dates Full Paper Submissions 1 February 2009 =20 Paper Acceptance Notifications 1 March 2009 =20 Final 'Camera Ready' Papers Due 15 April 2009=20 Track Chairs Dr Vidyasagar Potdar - Curtin University of Technology, Australia Mr Pedram Hayati - Curtin University of Technology, Australia ------_=_NextPart_001_01C97A9A.B45F46FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Apologies if you receive this more than once]

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Call for Paper
Adversarial Information Retrieval in = Digital Ecosystems with focus on Web Spam
IEEE International Conference on Digital Ecosystems and Business = Intelligence (IEEE-DEST 2009)
Istanbul, = Turkey, June 1-3, 2009

http://dest2009.debii.curt= in.edu.au/index.php?option=3Dcom_content&task=3Dview&id=3D26&= Itemid=3D40
*******************************************************************<= /o:p>

Full Research Paper Due: ** February 1 **, = 2009

The first AIR-DE-WS 2009 workshop will be held along with = the 3rd IEEE Digital Ecosystems and Business Intelligence Conference to be held = in Istanbul, = Turkey. Web spam has become a major problem for quality and sustainability of = digital ecosystems. There has been a strong competition between spammers and = anti-spam filters to control spam. As anti-spam filters improve their capability = to detect spam, spammers find new way to bypass these anti-spam filters. It = not only waste's computer and network resources but also it decreases the reliability of the content available on the Internet. The main purpose = of this workshop is to identify and explore different issues and challenges = related to web spam within the digital environment. It also aims at increasing the = synergy between academic and industrial practitioners. We are interested in experimental, systems-related, theoretical, and work-in-progress papers = in all aspects of web spam. Topics of interest include, but are not limited to, = the following:

Web Spam
- Splog (Spam over weblogs)
- Spamdexing (Spam aim on search engine algorithms)
- Review/Opinion spam
- Social-network spam (Spam over social network websites)
- Comment spam
- Tag spam
- Wiki spam
- Image spam

Communication Spam
- SPIT (Spam over Internet telephony)
- SPIM (Spam over instant messenger)
- Email spam
- Phishing

Other
- Machine Learning & Natural language processing in = Spam Detection
- Adversarial learning
- Challenge-response

Important Dates
Full Paper Submissions    =              = 1 February 2009  
Paper Acceptance Notifications      1 March 2009  
Final 'Camera Ready' Papers Due   =         15 April 2009


Track Chairs

Dr Vidyasagar = Potdar – Curtin University of Technology, Australia
Mr Pedram Hayati - Curtin = University of Technology, = Australia

------_=_NextPart_001_01C97A9A.B45F46FE-- --===============0741150239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg --===============0741150239==-- From asrg-bounces@irtf.org Tue Jan 20 18:08:18 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E551A3A6885; Tue, 20 Jan 2009 18:08:17 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780B23A6885 for ; Tue, 20 Jan 2009 18:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 lcCOmSzV9HFw for ; Tue, 20 Jan 2009 18:08:15 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 89DB03A682C for ; Tue, 20 Jan 2009 18:08:15 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0L27tTi022632 for ; Tue, 20 Jan 2009 21:07:59 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0L1wo2t027802 for ; Tue, 20 Jan 2009 20:58:50 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0L27oMR001434 for ; Tue, 20 Jan 2009 21:07:50 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0L27m08001432 for asrg@irtf.org; Tue, 20 Jan 2009 21:07:48 -0500 Date: Tue, 20 Jan 2009 21:07:48 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090121020748.GB30757@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Tue, Jan 20, 2009 at 01:40:59PM +0000, Ian Eiloart wrote: > I disagree fundamentally about the centralise reputation system. Every attempt made at these thus far has been an absolute failure. (See "TrustE" and "Habeas", for example.) I can't think of any reason why the outcome will change if the experiment is run again. BTW, I don't consider DNSBLs and RHSBLs to be reputation systems. That's not a knock on them: on the contrary, they are, by an enormous margin, the most effective anti-spam measures we have. But they're not trying to be reputation systems, and they don't need to be. > The key thing is that you can't use any kind of email domain or email > address based reputation system unless you have evidence that the sender > address isn't forged. I disagree, because I don't really *care* whether mail is forged or not, and regard that as largely an insignificant problem, when compared to the monumental problem posed by spam. (Morever, for most purposes, it doesn't matter: when a known spammer domain shows up, reject the message. If it was really from them: correct decision. If it was from someone dumb enough to forge a known spammer domain: still correct.) I think perhaps I have this viewpoint because my focus is on my biggest (ongoing) problem: what to do about the 99% of incoming mail that needs to be rejected outright before it can get anywhere near a user. Now, if I get past that and focus on the remaining 1% that I'd actually like to allow in, *then* I can see some reason to think about possible problems with that: authentication, integrity, privacy, etc. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 18:47:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509C83A6A08; Tue, 20 Jan 2009 18:47:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2FE3A6A08 for ; Tue, 20 Jan 2009 18:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] 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 Ko6l3S6WEg8S for ; Tue, 20 Jan 2009 18:47:21 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 937293A6935 for ; Tue, 20 Jan 2009 18:47:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id C0F3E64F83CD for ; Wed, 21 Jan 2009 14:47:15 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NKwJ2vC18sT for ; Wed, 21 Jan 2009 14:47:13 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id ACF8A64F839D for ; Wed, 21 Jan 2009 14:47:13 +1200 (FJT) Date: Wed, 21 Jan 2009 14:47:13 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <13659817.401232506016811.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <20090121010427.7829.qmail@simone.iecc.com> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Same, you MUST implement domainkeys because yahoo likes it. Hopefully domainkey will retire this year when yahoo moves from dk to dkim. Anyone heard of dates? ----- Original Message ----- From: "John Levine" To: asrg@irtf.org Sent: Wednesday, 21 January, 2009 1:04:27 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] SPF, was where the message >> Don't hold your breath. SPF is dead -- and good riddance, it was a very >> stupid idea -- > >So dead that of hotmail.com, gmail.com, mac.com, apple.com, microsoft.com, >facebook.com, ebay.com only er..., all of them publish SPF records. For largely political reasons, Hotmail requires anyone sending a significant amount of mail to them to have Sender-ID records. For senders that are on its whitelist, AOL reverse engineers the IP addresses to whitelist from the sender's SPF records, which is way easier all around than the former mostly manual system. Since S-ID falls back to SPF records, most senders just publish one set of SPF records for both. Note that neither of these are using SPF for its nominal purpose; I'm not aware of any large system that does. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 20 19:33:10 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA4A3A6863; Tue, 20 Jan 2009 19:33:10 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F198A3A6863 for ; Tue, 20 Jan 2009 19:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 whI2Nw0qOBsU for ; Tue, 20 Jan 2009 19:33:08 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 7AB163A682C for ; Tue, 20 Jan 2009 19:33:07 -0800 (PST) Received: from [192.168.0.4] (ppp-68-120-199-27.dsl.pltn13.pacbell.net [68.120.199.27]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0L3Wf5l019456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jan 2009 19:32:48 -0800 Message-ID: <49769759.8070102@dcrocker.net> Date: Tue, 20 Jan 2009 19:32:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> In-Reply-To: X-Virus-Scanned: ClamAV 0.92/8881/Tue Jan 20 06:48:51 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Jan 2009 19:32:49 -0800 (PST) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > So dead that of hotmail.com, gmail.com, mac.com, apple.com, > microsoft.com, facebook.com, ebay.com only er..., all of them publish > SPF records. It's not interesting who publishes SPF records. It's interesting who reads them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 02:01:11 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C113A6A4A; Wed, 21 Jan 2009 02:01:11 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645CD3A6A4A for ; Wed, 21 Jan 2009 02:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 ISBTMtPa67es for ; Wed, 21 Jan 2009 02:01:09 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 1C0CB3A684C for ; Wed, 21 Jan 2009 02:01:07 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:62454) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTFYG-000JDM-M1 for asrg@irtf.org; Wed, 21 Jan 2009 10:03:53 +0000 Date: Wed, 21 Jan 2009 10:00:47 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <668443174BC91350A133360F@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090120172130.GA32423@hjp.at> References: <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> Originator-Info: login-token=Mulberry:01yESqtjGlGBsJsf4YNGo7uR0pLrzLECtqPa8=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 18:21:30 +0100 "Peter J. Holzer" wrote: > On 2009-01-20 11:30:33 +0000, Ian Eiloart wrote: >> --On 20 January 2009 08:34:51 +0100 Alessandro Vesely >> wrote: >> >> > Daniel Feenberg wrote: >> >> On Mon, 19 Jan 2009, Paul Russell wrote: >> >>> On 1/19/2009 10:38 AM, Ian Eiloart wrote: >> >>>> 1. You can bounce selectively. >> >>> >> >>> I know that sendmail can be configured to accept for one recipient >> >>> and reject for another recipient. >> >> >> >> Sendmail can selectively reject receipients while processing "RCPT >> >> TO:" commands, but not after the header and body are received. >> >> [...] >> >> As I understand it, this is a consequence of the SMTP >> >> protocol, and not something that sendmail can program around. >> > >> > Given a set of recipients (r1, r2, ..., rn) the server can partition it >> > in subsets that have homogeneous filtering recipes. It does that in >> > steps. Each step consists in responding 250 for r1 and any other >> > recipient with identical filtering, 4xx to the rest. >> >> Yes, that's the scheme I was referring to. It can be implemented with my >> MTA - Exim. However, if any filter subset doesn't want the message, then >> you should give a 5yz response after seeing the body. RFC2821 says that >> the sending MTA "SHOULD not again attempt delivery to the same server >> without user review and intervention of the message". >> I guess most MTA's >> aren't RFC2821 compliant in that respect. > > I'm not sure how you interpret this sentence. Consider: > > MAIL FROM: > 250 ok > RCPT TO: > 250 ok > RCPT TO: > 450 try again later > DATA > 354 send message > ... > 550 message rejected > > Should the client assume a permanent failure for both recipients? > Or should it assume a permanent failure only for > and requeue the message for > ? Well, to me it means that there's something wrong with recipient1's mailbox - perhaps currently over quota, but that the DATA isn't acceptable according to some site policy. I think the RFC's authors probably didn't have in mind the contortions of the selective filtering mechanism. Really, autonegotiation of a switch to LMTP would be the solution here. Of course, spammers wouldn't adopt it. But, if it caught on then eventually people would start treating smtp clients which refused to switch to LMTP with suspicion. > >> >> RFC 5321 says the client "may either return it to the user or requeue it >> for a subsequent attempt". That's an improvement, > > Erm, that's for a 4xx reply. I am quite certain that RFC 5321 did not > intend any semantic changes relative to RFC 2821. All changes are only > meant to clarify. Sorry, you're quite right. I confused two fairly similar paragraphs. Both drafts say that you MAY retry after a 4xx post-data error, and that you SHOULD NOT retry after a 5xx error. So, the proposed mechanism shouldn't work. However, I'm sure I've heard of sites that actually do implement it, so perhaps MTAs are mostly requeueing messages after they see the 4xx on RCPT TO. > >> there's no guarantee that members of the second and subsequent subsets >> will ever see the message. If they do, it will be after a delay that >> many people find unacceptable. > >> If the number of subsets is large enough, you may even exceed the retry >> timeout on the sending MTA, so a large site had better not have too many >> filter recipes. > > Right. That's why I didn't consider looking at "filter recipies", when I > implemented a similar scheme for qpsmtpd. Instead I look at the result. > There are only 2 different results: Accept or reject, so unless the > result changes between delivery attempts (which can happen if e.g., a > blackist is updated or a recipient changes a rule), there are at most > three delivery attempts: > > 1) The results of the content filters for the different recipients > don't agree. Use the results to split the recipients into two sets. > 2) All the recipients from set1 get 2xx reply to RCPT, all the > recipients from set2 get a 4xx reply. Now the results of the content > filters for all recipients agree (they are all from set1), so we can > reply with either 2xx or 5xx. > 3) All the remaining recipients are now from set2, so the content > filters agree again, and we can again reply with 2xx or 5xx. > > (the actual implementation is a little bit more complicated, but that's > the basic idea). > > For most mails, the content filters of all recipients agree on the > result, so the mail can be accepted or rejected at the first delivery > attempt. > > It's a really ugly hack, but it works quite nicely. > > hp -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 02:21:21 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6953A6AA0; Wed, 21 Jan 2009 02:21:21 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3AAB3A6AA0 for ; Wed, 21 Jan 2009 02:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] 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 YDL7NIPHympQ for ; Wed, 21 Jan 2009 02:21:19 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id BF0663A67D2 for ; Wed, 21 Jan 2009 02:21:19 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:62704) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTGW8-00046M-3Y for asrg@irtf.org; Wed, 21 Jan 2009 10:24:08 +0000 Date: Wed, 21 Jan 2009 10:21:02 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <1E693C5F7DEB6ABF793E051A@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090120190159.GB32423@hjp.at> References: <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> <200901201749.MAA07139@Sparkle.Rodents-Montreal.ORG> <20090120190159.GB32423@hjp.at> Originator-Info: login-token=Mulberry:01NwJDTaBjsbJ4b5evoyiqd7bAnXpkp5oorG0=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 20:01:59 +0100 "Peter J. Holzer" wrote: > > There are, if we are only interested acception/rejection of the message. > You cannot include specific messages, of course (currently I just > concatenate all the rejection reasons into a single message). > > > The real problem is in the phrase "this particular message". At the time > the server receives the first "RCPT TO:" command it has no way to > know that this is a new delivery attempt for a message which was > temporarily rejected earlier, much less which message (envid is > per-transaction, and you couldn't rely on the client sending it anyway). > So, as a weak approximation, I use sender/recipient pairs instead of > message/recipient pairs as elements of the sets. This works quite well > because a recipient usually wants to receive all messages from a > specific sender or none. But yes, theoretically it can happen that the > sets are split again and again until each recipient is in a set of their > own. In practice I haven't seen it yet (after more than 3 years, but > admittedly on a relatively small number of email addresses). > > hp Oh, that's a pretty good solution. There are edge cases, and perhaps even exploits, but it's probably going to work most of the time - provided the client MTA ignores 4.2.5 of the RFC. It still delays messages for some recipients, but only up to an hour or so. It might cause problems with conversations on lists like this - but they could be mitigated by caching the "sender/recipient/source IP" triplet. The exploit, of course, is that spammers could open channels by sending apparently innocent messages. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 02:30:39 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B57A3A6A94; Wed, 21 Jan 2009 02:30:39 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5784A3A6A94 for ; Wed, 21 Jan 2009 02:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] 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 AYwhBFsMQFKj for ; Wed, 21 Jan 2009 02:30:37 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 291963A68CC for ; Wed, 21 Jan 2009 02:30:37 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:62762) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTHBP-000808-AW for asrg@irtf.org; Wed, 21 Jan 2009 10:33:25 +0000 Date: Wed, 21 Jan 2009 10:30:20 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <91B7CE63110DD306D7A5F837@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <497603F5.6060600@nortel.com> References: <775CA0FF2824E018986610DB@paine.local> <6.2.5.6.2.20090116094007.02ba3f60@resistor.net> <958E4963CC5DD3398A1792C4@lewes.staff.uscs.susx.ac.uk> <6.2.5.6.2.20090119055812.02d1e2f0@resistor.net> <1C5876057B0C4E47AB4CD650@lewes.staff.uscs.susx.ac.uk> <7ae58c220901191037s76dc0302lc8b0dc05f259c44d@mail.gmail.com> <7B7E3C13E90AEF7B1D3E6840@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200602r63427b0ct5a71e06c2f568c6b@mail.gmail.com> <178C4C15B617B422216FC45C@lewes.staff.uscs.susx.ac.uk> <7ae58c220901200719o673b822bkacfd1456c67126ba@mail.gmail.com> <6258CE32FDAAAD4305BA332B@lewes.staff.uscs.susx.ac.uk> <497603F5.6060600@nortel.com> Originator-Info: login-token=Mulberry:01znxFZzfds8wP6ZnJOqJB8bjaNPRmwTGiQ+c=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 12:03:49 -0500 Chris Lewis wrote: > Ian Eiloart wrote: > >> Maybe not so distant: >> >> >> This is a plea from Dave Crocker (author of rfc822) to take a >> Thunderbird extension that checks spf and dk, and add support for dkim. > > I remember that and the plea. > > The plugin didn't do SPF. It couldn't do SPF, because it didn't have > access to either the MAIL FROM or HELO/EHLO. It did something similar > to SPF (From:). Hmm, I'd have assumed that it checked the Received: headers to find an IP address that got an SPF pass with the content of the Return-Path: header. Of course, a spammer could always forge a suitable Received: header. I can't see that this could have worked 100% reliably. There would have been cases where are reliable warning could have been given, but they'd require a -all entry in the SPF record. > > Even to get it to do From: "properly" required intimate knowledge of > your mail server architecture. > > You could make it do SPF properly if you hacked your MTAs to add various > headers showing details about the perimeter connection (HELO, IP, rDNS, > MAIL FROM). > > We do insert such info, but it obviously wasn't going to be worthwhile > hacking the plugin to recognize our additional headers. > > The DK stuff didn't work at all AFAIK. Well, that sucks. Is that because the DK signature was broken in transit? > It was an experiment. As an experiment, I believe it died. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 02:40:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EAF3A6933; Wed, 21 Jan 2009 02:40:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0E13A6965 for ; Wed, 21 Jan 2009 02:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 UsfBKmcNu1Zk for ; Wed, 21 Jan 2009 02:40:32 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 107423A67A4 for ; Wed, 21 Jan 2009 02:40:32 -0800 (PST) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 21 Jan 2009 10:40:14 +0000 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <1E693C5F7DEB6ABF793E051A@lewes.staff.uscs.susx.ac.uk> References: <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> <200901201749.MAA07139@Sparkle.Rodents-Montreal.ORG> <20090120190159.GB32423@hjp.at> <1E693C5F7DEB6ABF793E051A@lewes.staff.uscs.susx.ac.uk> Organization: Isode Limited Date: Wed, 21 Jan 2009 10:40:13 +0000 Message-Id: <1232534413.8547.34.camel@bravo.isode.net> X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) MIME-Version: 1.0 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, 2009-01-21 at 10:21 +0000, Ian Eiloart wrote: > It still delays messages for some > recipients, but only up to an hour or so. A few years back, when we were experimenting with greylisting, we had a problem with someone we know sending from a site which only retried at roughly 24 hour intervals, (and also from a different IP address each time). The organization is a reasonably well known UK professional institution. The lesson was that you cannot necessarily rely upon reasonable retry strategies from "legitimate" sources. cheers David _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 02:48:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB16B3A6B08; Wed, 21 Jan 2009 02:48:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB703A6ABC for ; Wed, 21 Jan 2009 02:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 yKEDvS0IinBp for ; Wed, 21 Jan 2009 02:48:27 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id C66893A6AA3 for ; Wed, 21 Jan 2009 02:48:26 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:62885) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTI5D-000ETS-O6 for asrg@irtf.org; Wed, 21 Jan 2009 10:51:14 +0000 Date: Wed, 21 Jan 2009 10:48:08 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <8406D1E92C5D95C9DF48BCEB@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090121020748.GB30757@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> <20090121020748.GB30757@gsp.org> Originator-Info: login-token=Mulberry:01xmL5TC/DZ7EHz02uMog512y/LNoapimIO80=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 21:07:48 -0500 Rich Kulawiec wrote: > On Tue, Jan 20, 2009 at 01:40:59PM +0000, Ian Eiloart wrote: >> I disagree fundamentally about the centralise reputation system. > > Every attempt made at these thus far has been an absolute failure. > (See "TrustE" and "Habeas", for example.) I can't think of any > reason why the outcome will change if the experiment is run again. > > BTW, I don't consider DNSBLs and RHSBLs to be reputation systems. > That's not a knock on them: on the contrary, they are, by an enormous > margin, the most effective anti-spam measures we have. But they're > not trying to be reputation systems, and they don't need to be. I guess that depends on the nature of the RBL. Some of them really are reputation systems. IP addresses get listed because someone has seen spam coming from them. Spamhaus' SBL is an example. If you don't agree that that's a reputation service, please explain. Others aren't, Spamhaus' Policy Blocklist, for example is a list that IP address owners have added. I'm not sure why they don't just firewall the hosts, though. Perhaps so that some can be whitelisted. Of course each site can have its own local reputation policy that would trump a centralised reputation server - that's what whitelisting is about. However, currently it's hard to know what to whitelist. There's only one widespread, easy to use mechanism for managing information about which IP addresses an organisation is likely to send messages from - that's SPF. OK, so if you wanted to be sure to get mail from me, you could whitelist my /24 address block, but are you sure that I'd keep you updated if we outsourced our email? And, you can't reliably whitelist my domain, because spammers could then easily bypass your filters. If I had a domain whitelist for my site, then spammers would be on a pretty good bet that forging any .ac.uk address would make their email more deliverable. It would also make it more likely to be read. So, I can't whitelist those domains unless the email is coming the right IP addresses. Only SPF can tell me that. >> The key thing is that you can't use any kind of email domain or email >> address based reputation system unless you have evidence that the sender >> address isn't forged. > > I disagree, because I don't really *care* whether mail is forged or > not, and regard that as largely an insignificant problem, when compared > to the monumental problem posed by spam. (Morever, for most purposes, it > doesn't matter: when a known spammer domain shows up, reject the message. > If it was really from them: correct decision. If it was from someone > dumb enough to forge a known spammer domain: still correct.) Yes, the problem of course is when a spammer forges a domain that I'd like to trust. If I'm filtering mail from the domain of my chief funders, then false positives can be really painful. If I whitelist them, then spammers can easily bypass my filters. So what I'm discussing IS all about forgery. > > I think perhaps I have this viewpoint because my focus is on my biggest > (ongoing) problem: what to do about the 99% of incoming mail that needs > to be rejected outright before it can get anywhere near a user. You mean you want to know how to identify it? Or what to do with it after you've identified it? > Now, if > I get past that and focus on the remaining 1% that I'd actually like to > allow in, *then* I can see some reason to think about possible problems > with that: authentication, integrity, privacy, etc. > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 03:07:20 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D6528C0FB; Wed, 21 Jan 2009 03:07:20 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AC628C0EC for ; Wed, 21 Jan 2009 03:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 h8Ie8rN7w3MU for ; Wed, 21 Jan 2009 03:07:18 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id EA0103A6B15 for ; Wed, 21 Jan 2009 03:07:16 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63006) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTJ0T-000MJE-7D for asrg@irtf.org; Wed, 21 Jan 2009 11:10:05 +0000 Date: Wed, 21 Jan 2009 11:06:59 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <98A1ECB08BB15EE100D00EAA@lewes.staff.uscs.susx.ac.uk> Originator-Info: login-token=Mulberry:01FsnGWX8qNL5XNhq7gu+JPjnMfEHns3nvizQ=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 01:04:27 +0000 John Levine wrote: >>> Don't hold your breath. SPF is dead -- and good riddance, it was a very >>> stupid idea -- >> >> So dead that of hotmail.com, gmail.com, mac.com, apple.com, >> microsoft.com, facebook.com, ebay.com only er..., all of them publish >> SPF records. > > For largely political reasons, Hotmail requires anyone sending a > significant amount of mail to them to have Sender-ID records. > > For senders that are on its whitelist, AOL reverse engineers the IP > addresses to whitelist from the sender's SPF records, which is way > easier all around than the former mostly manual system. > > Since S-ID falls back to SPF records, most senders just publish one set of > SPF records for both. Note that neither of these are using SPF for its > nominal purpose; I'm not aware of any large system that does. They're using it for whitelisting purposes instead of its nominal purpose? That's exactly what I'm discussing. I think SPF has a bad reputation in some quarters because people think of how it breaks forwarding (etc). That's a shame, because it has huge potential when it comes to whitelisting, and therefore reducing false positives in filtering. Heck, a career change isn't the same thing as death! > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 03:08:23 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D251B3A6AA6; Wed, 21 Jan 2009 03:08:23 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEE53A6AA6 for ; Wed, 21 Jan 2009 03:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, SARE_BIZOP=0.7] 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 EPsavXFbM+J9 for ; Wed, 21 Jan 2009 03:08:22 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id B37C23A697A for ; Wed, 21 Jan 2009 03:08:22 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63010) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTJ2N-000MYC-92 for asrg@irtf.org; Wed, 21 Jan 2009 11:11:11 +0000 Date: Wed, 21 Jan 2009 11:08:05 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <3FA967097816D0418BFFF75E@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090121005655.5954.qmail@simone.iecc.com> References: <20090121005655.5954.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01QfvURqpcQquCaCiorSG0cEe5p3P1oKQhtmY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 00:56:55 +0000 John Levine wrote: >>>> Let's say you get a message from security@pay-pal.com, which is 100% >>>> DKIM, SPF, and Sender-ID approved. Is that Paypal? How can you tell >>>> short of manually looking up WHOIS registrations? >> >> Well, without all those technologies, it's simple to simply use paypal's >> domain. Then there's no clue. Now, if you use a look-alike domain name, >> then you're probably violating the trademark. That's illegal, ... > > Uh, dude, we're talking about phishing here. If that's not already > illegal in Australia, I think I've found a major recession-resistant > business opportunity. Phishing illegal? I don't know about Australia, but I don't think there are specific anti-phishing laws in the UK. Certainly, fraud perpetrated with information gained by phishing is illegal. It's fraud. It could be argued that the Phishing attempt itself is a form of fraud, but probably only if you actually do something with the information gained. My point about trademarks is that registering a domain that could be easily confused with a trademark is illegal. Therefore, it's reasonable to code phishing defences that rely in whole or in part on detecting sender address domains that are similar, but not identical, to trademarked domains. This means that technical measures to protect a domain from precise forgery can be supplemented with technical measures to protect near matches to those domains. Thus mitigating (not eliminating) the problem. [Whether it's legal or not, it is a business opportunity. It's probably not totally recession-resistant because recession probably reduces the gains to be had.] > > R's, > John > > PS: > >>> Is there actually any point in trying to solve phishing issues by >>> verifying the origin of email if the customer is going to depend on >>> a known-insecure web-browser? > > Maybe. One of my bank accounts requires me to use a physical dongle > to generate a code number. I expect in the future they'll give you a > USB dongle with a small screen and a couple of buttons so you do most > of your banking session on the computer, but when you hit go, the > dongle lights up with the details of the transaction the bank is about > to do and you have to push YES or NO on the dongle to confirm. That > seems like it could be made reasonably secure. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 03:16:59 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8129E3A6B37; Wed, 21 Jan 2009 03:16:59 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFC63A6B39 for ; Wed, 21 Jan 2009 03:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 Q7YExHXat-Rx for ; Wed, 21 Jan 2009 03:16:57 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id DAB513A697A for ; Wed, 21 Jan 2009 03:16:56 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63075) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTJGX-0003SI-7L for asrg@irtf.org; Wed, 21 Jan 2009 11:19:45 +0000 Date: Wed, 21 Jan 2009 11:16:39 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <9A0FFEBAE08F54A70FF9B022@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <13659817.401232506016811.JavaMail.franck@franck-martins-macbook-pro.local> References: <13659817.401232506016811.JavaMail.franck@franck-martins-macbook-pro.local> Originator-Info: login-token=Mulberry:01Z1MiF9C0kHyowHZ503nayJWKzctDccp53L4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 14:47:13 +1200 Franck Martin wrote: > Same, you MUST implement domainkeys because yahoo likes it. > > Hopefully domainkey will retire this year when yahoo moves from dk to > dkim. > Anyone heard of dates? Actually, Yahoo have just implemented a new complaint feedback loop in the past few days. They ask for details of DomainKeys or DKIM, but don't seem to require either. Oh, actually, you can sign up without either DomainKeys or DKIM, but you only get feedback when they see a DK or DKIM signature. Interestingly, you don't get feedback when Yahoo has put your mail into a spam mailbox. Only when it's marked as spam by the end user. > ----- Original Message ----- > From: "John Levine" > To: asrg@irtf.org > Sent: Wednesday, 21 January, 2009 1:04:27 PM (GMT+1200) Auto-Detected > Subject: Re: [Asrg] SPF, was where the message > >>> Don't hold your breath. SPF is dead -- and good riddance, it was a very >>> stupid idea -- >> >> So dead that of hotmail.com, gmail.com, mac.com, apple.com, >> microsoft.com, facebook.com, ebay.com only er..., all of them publish >> SPF records. > > For largely political reasons, Hotmail requires anyone sending a > significant amount of mail to them to have Sender-ID records. > > For senders that are on its whitelist, AOL reverse engineers the IP > addresses to whitelist from the sender's SPF records, which is way > easier all around than the former mostly manual system. > > Since S-ID falls back to SPF records, most senders just publish one set of > SPF records for both. Note that neither of these are using SPF for its > nominal purpose; I'm not aware of any large system that does. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 03:29:00 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1393A6B40; Wed, 21 Jan 2009 03:29:00 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545FB28C0EC for ; Wed, 21 Jan 2009 03:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 bPb4-JnkZ-4D for ; Wed, 21 Jan 2009 03:28:57 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 688CC28C0D8 for ; Wed, 21 Jan 2009 03:28:57 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63143) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTK0X-00089Z-A3; Wed, 21 Jan 2009 11:31:45 +0000 Date: Wed, 21 Jan 2009 11:28:39 +0000 From: Ian Eiloart To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF Message-ID: <639946698B170D6E856E1DF3@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <49769759.8070102@dcrocker.net> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <49769759.8070102@dcrocker.net> Originator-Info: login-token=Mulberry:01lRrSvf57QCLWhyYfAUAIj0Uw+5LzF/hACoU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 19:32:41 -0800 Dave CROCKER wrote: > > > Ian Eiloart wrote: >> So dead that of hotmail.com, gmail.com, mac.com, apple.com, >> microsoft.com, facebook.com, ebay.com only er..., all of them publish >> SPF records. > > > It's not interesting who publishes SPF records. > > It's interesting who reads them. That depends on whether you're deciding whether to publish them, or whether to read them. If you're deciding whether to read them, then it's very interesting to know who's publishing them. Who else is reading them is of secondary importance. If you're deciding whether to publish them, then it's interesting (but harder) to know who's reading them. Of course, there's a cycle here. The value of SPF to readers increases as their trusted correspondents publish records, and to publishers as their trusted correspondents read records. The value to the world probably varies according to the product of the two probabilities: A that a received non-abusive email was received from an IP address with a positive SPF match, and B that the recipient checks the record. The value for me, depends only on those emails that pass my server. For inbound email, B is zero or one according to my choice. A is outside my control, but appears to be better than 30% already (for messages that pass IP address reputation checks). > > d/ -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 03:44:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E63C3A6AC3; Wed, 21 Jan 2009 03:44:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5411828C116 for ; Wed, 21 Jan 2009 03:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 uJgJAxu7JZke for ; Wed, 21 Jan 2009 03:43:59 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id ECFE63A6AC3 for ; Wed, 21 Jan 2009 03:43:58 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63222) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDTKPW-000FVC-OW; Wed, 21 Jan 2009 11:46:45 +0000 Date: Wed, 21 Jan 2009 11:43:39 +0000 From: Ian Eiloart To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF Message-ID: <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4976299A.7060502@dcrocker.net> References: <20090120145354.57509.qmail@simone.iecc.com> <4976299A.7060502@dcrocker.net> Originator-Info: login-token=Mulberry:01UFHujLmyXPGRvkLuvHfDxmH/tskP5rN3xbw=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 20 January 2009 11:44:26 -0800 Dave CROCKER wrote: > > > John Levine wrote: >> DKIM at least starts to address those problems, but it still doesn't >> begin to try to deal with the much harder problem of lookalike >> domains. Let's say you get a message from security@pay-pal.com, which >> is 100% DKIM, SPF, and Sender-ID approved. Is that Paypal? How can >> you tell short of manually looking up WHOIS registrations? > > > > Two points: > > 1. The word "security" is not all that helpful in these discussions. To > security technology experts, it means too many things to know what is > meant in a particular case. To the rest of us, it carries too little > precise meaning. > > 2. Almost all of the discussions about these authentication-related > technologies start with the authenticated identifier and then talk about > what you can derive from it or how it might be spoofed or otherwise > abused. Since that is exactly what must be done with suspect messages, > the model seems to make sense to (re-)apply for authentication. I now > believe it is exactly the wrong model. That's a model that looks for the > problem, the attack, the basis for suspicion. > > > > A very different model starts as a model of trust and specifies a table > of who is part of the model. In other words, it works in the oppsoite > direction. When a message shows up, the only question is whether that > message falls under that umbrella of trust. If it doesn't, then we are > done with that model, for that message. Any further consideration of > that message has nothing at all to do with the trust model. The > authenticated identifier is the sole, simple lookup string into that the > model. Either the identifier string works or it doesn't. Agreed. That's why I'm discussing SPF or DKIM with a reputation service. In the first instance, my reputation service is going to be a local whitelisting mechanism. I'll probably have some domains whitelisted for my entire site. Perhaps all .ac.uk domains, for example. Then I'll allow users to whitelist domains and addresses that they trust. However, the whitelisting mechanism will rely on an SPF or DKIM pass. So, as you say, I'll check that the sender address falls under my umbrella of trust - that it's in my whitelist. If not, I'll fall back to my old mechanisms. But, if it does fall under my umbrella of trust, I'm still going to check for either an SPF or a DKIM positive match. If I don't get that, then I fall back to my old mechanisms. I hope that an trustworthy external reputation service will emerge that allows me to place others under my umbrella of trust, even when they're not listed locally. I'll need some rules about who people can whitelist (and blacklist, too). For example, I don't think I'd allow anyone to whitelist hotmail.com as a domain, but I'd allow then to whitelist specific addresses. On the other hand, I'd allow them to whitelist the domain of a local school or local government organisation. > Concerns about spoofing the identifier, re-purposing its use, and > corrupting the content -- authentication, authorization and data and > signature integrity -- are all valid for evaluating the underlying > technology but they really are secondary to any serious discussion of the > model. After the briefest review to ensure that a particular technology > has made specific and acceptable choices for the "security" questions, > the questions should not burden debate about use of the technology. > Instead we seem to find these questions hashed, rehashed and hashed > again, as the focus of community debate. > > When the anti-abuse world discusses use of these authentication > technologies, we need to stop being the anti-abuse world and start being > the trust world. The anti-abuse world really has the receiving assessor > as an isolated island of suspicious. In today's Internet, that's > required. But the trust world is quite different. It is collaborative > -- between signer and receiving assessor -- and deterministic, rather > than vague and heuristic, and strictly the effort of the receiving > assessor. > > Totally different model. So we need a totally different approach to > talking about it. > > d/ -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 07:14:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E254E3A6A6E; Wed, 21 Jan 2009 07:14:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1557B28C0EC for ; Wed, 21 Jan 2009 07:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 tBrzTceq9LWI for ; Wed, 21 Jan 2009 07:14:26 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 3ABB83A6973 for ; Wed, 21 Jan 2009 07:14:26 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 21 Jan 2009 16:14:06 +0100 id 00000000005DC031.0000000049773BBE.000076C2 Message-ID: <49773BBD.1090900@tana.it> Date: Wed, 21 Jan 2009 16:14:05 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <4974F676.4000706@nd.edu> <49757E9B.1080702@tana.it> <3D26D5087712DC3B2B991C82@lewes.staff.uscs.susx.ac.uk> <20090120172130.GA32423@hjp.at> <668443174BC91350A133360F@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <668443174BC91350A133360F@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > --On 20 January 2009 18:21:30 +0100 "Peter J. Holzer" > wrote: >> I'm not sure how you interpret this sentence. Consider: >> >> MAIL FROM: >> 250 ok >> RCPT TO: >> 250 ok >> RCPT TO: >> 450 try again later "412 you are whitelisted" is also sometimes encountered. >> DATA >> 354 send message >> ... >> 550 message rejected >> >> Should the client assume a permanent failure for both recipients? >> Or should it assume a permanent failure only for >> and requeue the message for >> ? > > Well, to me it means that there's something wrong with recipient1's > mailbox - perhaps currently over quota, but that the DATA isn't > acceptable according to some site policy. I assume you meant recipient2. The server rejects a message, not a DATA block. In case the sender's MX resolves to the same server, any MTA would send the bounce there, notwithstanding that DATA block isn't acceptable according to some site policy. The message that should not be retried is inclusive of the envelope, and recipient2 is not currently in the server's recipients buffer. So much so that the client should retry recipient2 even if the server accepted the data for recipient1. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 08:05:31 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9527A3A6BDD; Wed, 21 Jan 2009 08:05:31 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D41828C155 for ; Wed, 21 Jan 2009 08:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6] 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 OVTI6O8+gZwv for ; Wed, 21 Jan 2009 08:05:29 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 75CD93A6A90 for ; Wed, 21 Jan 2009 08:05:29 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 21 Jan 2009 17:05:12 +0100 id 00000000005DC031.00000000497747B8.0000095F Message-ID: <497747B8.5030206@tana.it> Date: Wed, 21 Jan 2009 17:05:12 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Leslie References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> In-Reply-To: <20090120155005.GJ24908@verdi> Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Leslie wrote: > John Levine wrote: >> [SPF] only works for the subset of mail that is sent from a fixed point >> to recipients who don't remail or forward it. It works well also with a number of mailing lists. Alias expansions admittedly leaves something to be desired. However, considering that even rfc5321 screws up the term "forwarding" in that section, it should be tolerated in an experimental rfc... > Fundamentally, of course, the attempt to have one-size-fits-all > processing by the receiving MTA is dubious. It's not the coding of SPF > records that breaks forwarding: it's the processing of them. Relaxing > the processing rules could help a lot. Would you please expand on that? Relaxing rules implies the knowledge that a message is being forwarded. Are you talking about whitelisting well known forwarders, or what? > And I see promise in the use of the pending > Authentication-Results header (though I must agree with Doug Otis that > it would be stronger if it included the IP address). ( Hm... the header's name suggests it is reporting already acquired results, as had been noted. I'm surprised Doug didn't propose an additional test more in tune with that spirit, e.g. Authentication-Results: example.com; dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3 ) _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 08:12:37 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C4628C152; Wed, 21 Jan 2009 08:12:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A673628C152 for ; Wed, 21 Jan 2009 08:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nLPm2Wj1NDO9 for ; Wed, 21 Jan 2009 08:12:34 -0800 (PST) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 138363A67D8 for ; Wed, 21 Jan 2009 08:12:33 -0800 (PST) Received: from [192.168.0.4] (ppp-68-120-199-27.dsl.pltn13.pacbell.net [68.120.199.27]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n0LGCAPg020714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 08:12:16 -0800 Message-ID: <49774959.1090203@dcrocker.net> Date: Wed, 21 Jan 2009 08:12:09 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ian Eiloart References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <49769759.8070102@dcrocker.net> <639946698B170D6E856E1DF3@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <639946698B170D6E856E1DF3@lewes.staff.uscs.susx.ac.uk> X-Virus-Scanned: ClamAV 0.92/8884/Wed Jan 21 05:15:32 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 21 Jan 2009 08:12:16 -0800 (PST) Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: >> It's not interesting who publishes SPF records. >> >> It's interesting who reads them. > > That depends on whether you're deciding whether to publish them, or > whether to read them. For the purpose of assessing Internet utility, consumption is a better indicator than publication. I understood this thread to be discussing utility. Publication without consumption has zero utility. So does consumption without publication, of course, but if there is a community wishing to consume, there will almost certainly come to be a community doing the publication. In contrast we've had ample demonstration that that publication does not have any automatic implication about consumption. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 09:28:16 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5D728C20C; Wed, 21 Jan 2009 09:28:15 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168A728C20B for ; Wed, 21 Jan 2009 09:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] 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 yIXRXvk32-qY for ; Wed, 21 Jan 2009 09:28:14 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id EBA8328C20A for ; Wed, 21 Jan 2009 09:28:13 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 57D1133C22; Wed, 21 Jan 2009 12:27:57 -0500 (EST) Date: Wed, 21 Jan 2009 12:27:56 -0500 From: John Leslie To: Alessandro Vesely Message-ID: <20090121172756.GL24908@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <497747B8.5030206@tana.it> User-Agent: Mutt/1.4.1i Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Alessandro Vesely wrote: > John Leslie wrote: > >> Fundamentally, of course, the attempt to have one-size-fits-all >> processing by the receiving MTA is dubious. It's not the coding of >> SPF records that breaks forwarding: it's the processing of them. >> Relaxing the processing rules could help a lot. > > Would you please expand on that? Relaxing rules implies the knowledge > that a message is being forwarded. Are you talking about whitelisting > well known forwarders, or what? I was intentionally vague... However, there are a limited number of ways that forwarding might be shown in the trace headers, so it should be practical to determine that a forwarding is documented (though possibly forged). We then have a quite different situation from what raw SPF processing would indicate. Thus I claim the rules deserve to be relaxed (without going into detail how). Forging headers to indicate forwarding which didn't happen indicates evil intent, and should be practical to block-list like other spamming IPs. Well-known forwarders could be whitelisted, enabling us to trust their pre-forwarding headers. Et cetera... >> And I see promise in the use of the pending Authentication-Results >> header (though I must agree with Doug Otis that it would be stronger >> if it included the IP address). > > Hm... the header's name suggests it is reporting already acquired > results, as had been noted. I'm surprised Doug didn't propose an > additional test more in tune with that spirit, e.g. > > Authentication-Results: example.com; > dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3 I'll let Doug speak for himself. I didn't propose such a thing because I believe arguing over extensions would detract from getting the basic header adopted. (I do believe that adding a resinfo listing the IP address is a practical way to deal with SPF's choice to omit it from their resinfo.) -- John Leslie _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 09:31:36 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DBF28C20E; Wed, 21 Jan 2009 09:31:36 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345E628C1F6 for ; Wed, 21 Jan 2009 09:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_NUMERIC_HELO=2.067] 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 jiXviujoCmuJ for ; Wed, 21 Jan 2009 09:31:35 -0800 (PST) Received: from webmail.returnpath.net (webmail.returnpath.net [67.154.224.203]) by core3.amsl.com (Postfix) with ESMTP id 6DD0128C19C for ; Wed, 21 Jan 2009 09:31:35 -0800 (PST) Received: from 38.109.196.53 ([38.109.196.53]) by rpnyex01.rpcorp.local ([192.168.1.16]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jan 2009 17:30:34 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 10:31:15 -0700 From: "J.D. Falk" To: Anti-Spam Research Group - IRTF Message-ID: Thread-Topic: DK & DKIM (was Re: [Asrg] SPF, was where the message) Thread-Index: Acl77g+LbuyxaajyCkyU6JSJKPPnzA== In-Reply-To: <13659817.401232506016811.JavaMail.franck@franck-martins-macbook-pro.local> Mime-version: 1.0 Subject: [Asrg] DK & DKIM (was Re: SPF, was where the message) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 20/01/2009 19:47, "Franck Martin" wrote: > Same, you MUST implement domainkeys because yahoo likes it. I haven't seen any reliable evidence that they're rejecting unsigned messages. Could you point us towards the announcement? > Anyone heard of dates? Yahoo!'s complaint feedback loop (re-launched yesterday, with help from Return Path) routes based on either DK or DKIM, so that's progress. They aren't sharing dates for when they'll be working with DKIM in the rest of the mailstream. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 09:34:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABBB28C19C; Wed, 21 Jan 2009 09:34:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B23A28C19C for ; Wed, 21 Jan 2009 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_NUMERIC_HELO=2.067] 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 qCPijxO3y57h for ; Wed, 21 Jan 2009 09:34:10 -0800 (PST) Received: from webmail.returnpath.net (webmail.returnpath.net [67.154.224.203]) by core3.amsl.com (Postfix) with ESMTP id 53E7A28C158 for ; Wed, 21 Jan 2009 09:34:10 -0800 (PST) Received: from 38.109.196.53 ([38.109.196.53]) by rpnyex01.rpcorp.local ([192.168.1.16]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jan 2009 17:33:09 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 10:33:50 -0700 From: "J.D. Falk" To: Anti-Spam Research Group - IRTF Message-ID: Thread-Topic: [Asrg] SPF, was where the message Thread-Index: Acl77mvup8sHhGqjs0yP9yTrq2RyIw== In-Reply-To: <9A0FFEBAE08F54A70FF9B022@lewes.staff.uscs.susx.ac.uk> Mime-version: 1.0 Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 21/01/2009 04:16, "Ian Eiloart" wrote: > Interestingly, you don't get feedback when Yahoo has put your mail into a > spam mailbox. Only when it's marked as spam by the end user. That's why it's called a Complaint Feedback Loop. All of the other North American ISPs who provide feedback work basically the same way. I've heard that there are a few European ISPs who provide filtering-based feedback to each other, but not to just anyone who asks. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 11:01:35 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45293A685D; Wed, 21 Jan 2009 11:01:35 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1713A685D for ; Wed, 21 Jan 2009 11:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 vIsSeIxNfMTa for ; Wed, 21 Jan 2009 11:01:33 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 4AB603A67A3 for ; Wed, 21 Jan 2009 11:01:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id C283964F83D8 for ; Thu, 22 Jan 2009 07:01:23 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o75l89uu3F7J for ; Thu, 22 Jan 2009 07:01:20 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 09E7964F839E for ; Thu, 22 Jan 2009 07:01:20 +1200 (FJT) Date: Thu, 22 Jan 2009 07:01:19 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <15104592.341232564464306.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <8549099.321232564391136.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [113.20.68.192] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] DK & DKIM (was Re: SPF, was where the message) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I never said they were rejecting unsigned messages and the context of the thread was mass mailing. yes I just saw the Y! fbl announcement. ----- Original Message ----- From: "J.D. Falk" To: "Anti-Spam Research Group - IRTF" Sent: Thursday, 22 January, 2009 5:31:15 AM (GMT+1200) Auto-Detected Subject: [Asrg] DK & DKIM (was Re: SPF, was where the message) On 20/01/2009 19:47, "Franck Martin" wrote: > Same, you MUST implement domainkeys because yahoo likes it. I haven't seen any reliable evidence that they're rejecting unsigned messages. Could you point us towards the announcement? > Anyone heard of dates? Yahoo!'s complaint feedback loop (re-launched yesterday, with help from Return Path) routes based on either DK or DKIM, so that's progress. They aren't sharing dates for when they'll be working with DKIM in the rest of the mailstream. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 18:02:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D193A699E; Wed, 21 Jan 2009 18:02:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748763A699E for ; Wed, 21 Jan 2009 18:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.808 X-Spam-Level: X-Spam-Status: No, score=-14.808 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 FI7WIkBbjkjP for ; Wed, 21 Jan 2009 18:02:49 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 4D25A3A6A88 for ; Wed, 21 Jan 2009 18:02:49 -0800 (PST) Received: (qmail 1273 invoked from network); 22 Jan 2009 02:02:32 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 22 Jan 2009 02:02:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=j7vpZ3GGGYVw4sUCv9NNkKqLzHEXeUZ5X9/RKJLDHs8=; b=oaW2IqR3U1nabQ10d+ZvkE24c2aN9TDA6NKZrAyLhTdTebPrnL0mmzSDxCiDVwK8GTckVhZaNc2NiReHP+rI64jaU+5ZN9y5o2hz4pu/2p84+I3pthA1BiyhD7GQjAigODh/VbMXX7sHdpreWTtnO9AMlxe8O3x2eo8R7feRzjk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=j7vpZ3GGGYVw4sUCv9NNkKqLzHEXeUZ5X9/RKJLDHs8=; b=L4tSl7mlT37Ahgo7QsvW5aj4dO6y9BdaGM33Q5lR7wzcyjX7UdI+gu7BiFqXoT+ANgncrA8JCq85t6ZuGu0ByZwqCvV8iOF29yhQ5HUksB7Jdth9czNNc9T1HU9fNWkLqmrkRKhfYUHMhIpCZVNDB3Wam3TMy+yLsr6XWqYF/OE= Date: 22 Jan 2009 02:02:29 -0000 Message-ID: <20090122020229.45279.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <98A1ECB08BB15EE100D00EAA@lewes.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> For senders that are on its whitelist, AOL reverse engineers the IP >> addresses to whitelist from the sender's SPF records, which is way >> easier all around than the former mostly manual system. >> >> Since S-ID falls back to SPF records, most senders just publish one set of >> SPF records for both. Note that neither of these are using SPF for its >> nominal purpose; I'm not aware of any large system that does. > >They're using it for whitelisting purposes instead of its nominal purpose? >That's exactly what I'm discussing. Every once in a while, AOL fetches the SPF records for senders in their whitelist, crunches them to get a set of IP addresses, and then puts those IP addresses into their whitelist. AOL's whitelisting process is based on IPs, with the SPF bit merely being a cheap way for senders to tell AOL what IPs they use. They do not use SPF per-message, nor as far as I can tell do they make any attempt to match up the bounce address on incoming mail to the domain from which they got the IP in the whitelist. > I think SPF has a bad reputation in some quarters because people > think of how it breaks forwarding (etc). It could be somewhat useful for whitelisting some kinds of mail. Too bad it's been so egregiously oversold. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 21 19:39:55 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DB128C17F; Wed, 21 Jan 2009 19:39:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4915C28C17F for ; Wed, 21 Jan 2009 19:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 j0tUVXU3pqCL for ; Wed, 21 Jan 2009 19:39:53 -0800 (PST) Received: from tomts24-srv.bellnexxia.net (tomts24-srv.bellnexxia.net [209.226.175.187]) by core3.amsl.com (Postfix) with ESMTP id 53F1028C175 for ; Wed, 21 Jan 2009 19:39:53 -0800 (PST) Received: from toip41-bus.srvr.bell.ca ([67.69.240.42]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090122033930.IRHZ1558.tomts24-srv.bellnexxia.net@toip41-bus.srvr.bell.ca> for ; Wed, 21 Jan 2009 22:39:30 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAB53d0lMQf/l/2dsb2JhbACKGL9HhXM Received: from mtlxpqak-1279393765.sdsl.bell.ca (HELO JohnGlubeMain) ([76.65.255.229]) by toip41-bus.srvr.bell.ca with ESMTP; 21 Jan 2009 22:39:30 -0500 From: "John Glube" To: "'Anti-Spam Research Group - IRTF'" References: <98A1ECB08BB15EE100D00EAA@lewes.staff.uscs.susx.ac.uk> <20090122020229.45279.qmail@simone.iecc.com> Date: Wed, 21 Jan 2009 22:39:30 -0500 Organization: Glube's - Business Services Message-ID: <25B2E5216CEF414282EC36DB8FDB577E@JohnGlubeMain> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 thread-index: Acl8NYmThSn2xEKrR6WeGnfZP5M83gACkEEg In-Reply-To: <20090122020229.45279.qmail@simone.iecc.com> Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: john.glube@trusted-email-sender.com, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > >They're using it for whitelisting purposes instead of its nominal > purpose? > >That's exactly what I'm discussing. > > Every once in a while, AOL fetches the SPF records for senders in > their whitelist, crunches them to get a set of IP addresses, and then > puts those IP addresses into their whitelist. AOL's whitelisting > process is based on IPs, with the SPF bit merely being a cheap way for > senders to tell AOL what IPs they use. They do not use SPF > per-message, nor as far as I can tell do they make any attempt to > match up the bounce address on incoming mail to the domain from which > they got the IP in the whitelist. > > > I think SPF has a bad reputation in some quarters because people > > think of how it breaks forwarding (etc). > > It could be somewhat useful for whitelisting some kinds of mail. Too > bad it's been so egregiously oversold. > Up until the Spring of 2008, AOL was using SPF to check what AOL called the "SPF_helo" and the "SPF_822_from." We know this because the following headers were observed in FBL data: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo: n X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : n ("n" indicated the test failed. "y" indicated the test passed.) My understanding is that the "SPF_helo" check was based on the perceived value of CSV and that the "SPF_822 from" was part of the overall effort in deciding whether to incorporate SID checks. It was presumed that the data was also used as part of the reputation analysis that AOL was running on incoming mail. I do not know whether AOL is still running these checks. Investigation shows that AOL dropped the X-AOL-Scoll-Authentication header sometime in the summer of 2008. My recollection from discussions with a former AOL postmaster shortly after the collapse of MARID is that AOL felt running an SPF_helo and SPF_822_from check would be useful information as part of the overall process of detecting and blocking the "low hanging" spam. John Glube _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 04:37:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539DA3A686D; Thu, 22 Jan 2009 04:37:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C6128C140 for ; Thu, 22 Jan 2009 04:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.81 X-Spam-Level: X-Spam-Status: No, score=-14.81 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 QgET9oZzoFIM for ; Thu, 22 Jan 2009 04:37:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 6CA753A6818 for ; Thu, 22 Jan 2009 04:37:21 -0800 (PST) Received: (qmail 98093 invoked from network); 22 Jan 2009 12:37:05 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 22 Jan 2009 12:37:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=LT2Y2kFDpNQ2VialKTNB8AL1k16g7wbFYsR436J2iGA=; b=LMgiwB4jV1cOD3h0EtdMzFs+AMTj9J2SvcvN0kFoafCeG2VaZsKho3Re3UJpw+1NbYh8VhmUqA+ndpvqKTDPK1LPAiguMJYCrnGXbS2pi3NL8VMKE7zk8sPJP0bWvqurOBUEptPFtA/YqpbrOx5CJg8kVIVcB8JHqRAHs2Jrr5A= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=LT2Y2kFDpNQ2VialKTNB8AL1k16g7wbFYsR436J2iGA=; b=ZE6ysiLzhZbO8PwPatg3wHKGXWqmjG12gv5wFUiR0olUgnewu/WFbvgpIrussh7RyXtUa+YQ6oql4hpeziv+qpDg+n/Ce3cC4s3WJHimb4xbYT/MTDtsDnbi3U1ty4FUiPE8FuWR2K34MAZWVIt4WCOJMTJBzymt6flZW6vaDck= Date: 22 Jan 2009 12:37:02 -0000 Message-ID: <20090122123702.39209.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org About a month ago, some ASRG members published this draft: http://tools.ietf.org/html/draft-irtf-asrg-postage-00 Since then I haven't heard a peep about it. Since this is the asRg, the least we could do would be to try to do another version that adds some discussion of where it might be used and what the deployment issues are. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 06:44:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0929A3A6985; Thu, 22 Jan 2009 06:44:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2565C3A6985 for ; Thu, 22 Jan 2009 06:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Px2zf5Nfr0yk for ; Thu, 22 Jan 2009 06:44:21 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id AD6423A6821 for ; Thu, 22 Jan 2009 06:44:21 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6A8E033C2D; Thu, 22 Jan 2009 09:44:02 -0500 (EST) Date: Thu, 22 Jan 2009 09:44:02 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090122144402.GN24908@verdi> References: <20090122123702.39209.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090122123702.39209.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote: > > About a month ago, some ASRG members published this draft: > > http://tools.ietf.org/html/draft-irtf-asrg-postage-00 > > Since then I haven't heard a peep about it. Since this is > the asRg, the least we could do would be to try to do another > version that adds some discussion of where it might be used and > what the deployment issues are. I hardly think all that needs to be in the draft... Nonetheless, we have perhaps been too quiet about it. Usage, of course, _could_ be on every email transaction. If the extension were implemented for the popular open-source MTAs, widespread adoption would be feasible. (Of course, any actual exchange of value would require a "banking" structure: Ben April is working on that, but I haven't asked him for a progress report.) I don't believe it appropriate to tie asrg-postage to any particular "banking" structure. It needs only to deal with transfer of opaque tokens between MTAs. I have jokingly suggested we do an inital deployment using Zimbabwean dollars -- which nobody in his right mind could actually want to redeem. ;^) One side of deployment is getting at least one commonly-used MTA to implement it. I am trying to entice college students into doing that. Another side of deployment is getting at least one party to put some (currency) value into the system. A bit counter-intuitively, that part looks easy: many mass-emailers would happily pay some small fraction of snail-mail postage to get past spam-filtering (which silently drops their "crucially-important" emails). It's important to understand that any real "banking" system is going to deal in "settlements" -- only exchanging actual value between banks based on the net differences of transactions. Thus, recipients' banks will accumulate value as mass-emailers add it to their banks, leaving recipients' MTAs' accounts with a surplus "too small to redeem" available for paying "postage" on their outgoing emails that might get caught in spam-filters. So long as mass-email remains well over 50% of email, there's no need for average ISPs to put any net value into email postage! I think that's enough exposition for one email. There are bunches of research topics in how to set postage rates, and maybe how to shame larger ISPs into actually "paying", which I'd be happy to discuss in _other_ emails. -- John Leslie _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 08:07:51 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990103A6938; Thu, 22 Jan 2009 08:07:51 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E1F3A6938 for ; Thu, 22 Jan 2009 08:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MVzM979uYq6a for ; Thu, 22 Jan 2009 08:07:49 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id D95F43A68B6 for ; Thu, 22 Jan 2009 08:07:48 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0MG7SFo015451 for ; Thu, 22 Jan 2009 11:07:31 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0MFwHCH005602 for ; Thu, 22 Jan 2009 10:58:17 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0MG7N1x030560 for ; Thu, 22 Jan 2009 11:07:23 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0MG7KFX030558 for asrg@irtf.org; Thu, 22 Jan 2009 11:07:20 -0500 Date: Thu, 22 Jan 2009 11:07:20 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090122160720.GA29632@gsp.org> References: <20090120145354.57509.qmail@simone.iecc.com> <4976299A.7060502@dcrocker.net> <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 21, 2009 at 11:43:39AM +0000, Ian Eiloart wrote: > Agreed. That's why I'm discussing SPF or DKIM with a reputation service. > In the first instance, my reputation service is going to be a local > whitelisting mechanism. I'll probably have some domains whitelisted for > my entire site. Perhaps all .ac.uk domains, for example. Then I'll allow > users to whitelist domains and addresses that they trust. However, the > whitelisting mechanism will rely on an SPF or DKIM pass. Even if you go that route -- and I'll skip getting into its instrinsic merits and problems here -- I think you shouldn't allow users to whitelist *anything*, ever, without manual review by qualified personnel, for at least two reasons I can think of. First, users have very poor skills in this area. (Not their fault, really, it's not their gig.) We can tell how poor their skills by a number of methods, but I think the most obvious is: if they were any good at it, then phishing would be an inconsequential problem. Another way to tell is to monitor outbound SMTP and HTTP requests and note which ones have being directed to known-fraudulent domains. I see this constantly, even in environments where users have been told ad infinitum to never reply to a suspected spam/phish, never to follow any links in them, etc. (In some environments, I block them. I'm beginning to think that's a best practice, even in cases where subsequently the real targets have acquired the phisher domains, as I think they know never to use them.) Second, how do you know that it's actually the users doing this? I'm not saying that you shouldn't maintain something along the lines of a whitelist, or an exempted-from-blacklist, or some other function. I'm saying that nothing should ever go into that list until somebody who knows about DNS and WHOIS and is appropriately paranoid has looked at it. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 16:35:55 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6953A67DF; Thu, 22 Jan 2009 16:35:55 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1883A677C for ; Thu, 22 Jan 2009 16:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.811 X-Spam-Level: X-Spam-Status: No, score=-14.811 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 XJdrn-uJOnCN for ; Thu, 22 Jan 2009 16:35:46 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 9207A3A6981 for ; Thu, 22 Jan 2009 16:35:46 -0800 (PST) Received: (qmail 9203 invoked from network); 23 Jan 2009 00:35:29 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 23 Jan 2009 00:35:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=7EoR6+MqZyKFU4D3ILNTEm6Gafq30bo4HtOLX4qkZ8M=; b=i802kw27i773NzEwa67brQAFMKuBHjH08mi6JbmKWTFkkl+Nw/nuyu45pcChmpE+j1yZffeoV0VoxFK/8CRSmMIiT7Q3qYRzFiZJByxA5Pe9e1X1C2hXaPiZqNNAigw8os5erJaKdbrOs2L1v3KQwQErIMngnBbGLTe2LuikKJM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=7EoR6+MqZyKFU4D3ILNTEm6Gafq30bo4HtOLX4qkZ8M=; b=Lp0gT1Zssy/18d7d7qyMJpP1JqUv/BTHP4PGaB0PKckalB/EuIKINj/WRJsP9IJF5+ub6nnndMJMVA46DqYp1SwxxPC0EATVLp9qRiH34MQDDNYiFMgdkSjFEbr0XViAK/LkiMD3SxBAXNQWsA+FQNMlBx/W5JYsni8sL97ELrw= Date: 23 Jan 2009 00:35:12 -0000 Message-ID: <20090123003512.13970.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090122144402.GN24908@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> Since then I haven't heard a peep about it. Since this is >> the asRg, the least we could do would be to try to do another >> version that adds some discussion of where it might be used and >> what the deployment issues are. > > I hardly think all that needs to be in the draft... We're a research group -- if you want to do standards track, the IETF is right down the hall. I think it would be quite useful to have something that describes a well thought out e-postage system, and all the reasons it failed. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 20:48:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90333A682B; Thu, 22 Jan 2009 20:48:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEE33A682B for ; Thu, 22 Jan 2009 20:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AUsPSnJZslsX for ; Thu, 22 Jan 2009 20:48:21 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 9B2933A6816 for ; Thu, 22 Jan 2009 20:48:21 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0N4m1Rj024263 for ; Thu, 22 Jan 2009 23:48:04 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0N4cmYM015620 for ; Thu, 22 Jan 2009 23:38:48 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0N4ltR0007862 for ; Thu, 22 Jan 2009 23:47:55 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0N4lr7r007845 for asrg@irtf.org; Thu, 22 Jan 2009 23:47:53 -0500 Date: Thu, 22 Jan 2009 23:47:53 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090123044753.GA28612@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> <20090121020748.GB30757@gsp.org> <8406D1E92C5D95C9DF48BCEB@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8406D1E92C5D95C9DF48BCEB@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Wed, Jan 21, 2009 at 10:48:08AM +0000, Ian Eiloart wrote: > I guess that depends on the nature of the RBL. Some of them really are > reputation systems. IP addresses get listed because someone has seen spam > coming from them. Spamhaus' SBL is an example. If you don't agree that > that's a reputation service, please explain. I don't agree that's a reputation service. It's a binary flag (on a per-IP basis) saying "this address has been observed (at one or more observation points) as sending spam". And that's all it says -- and it only says it about a subset of IP addresses (those seen emitting spam) and only about a subset of those (those seen by Spamhaus-affiliated sensors) and only about a subset of those (add some notion of "recently" -- an address that spewed in the past may not be listed now). That's highly useful information if my goal is to block spam, but it's only marginally useful if my goal is to do anything else. (BTW: there's only one RBL, and Spamhaus doesn't run it. They run DNSBLs.) Maybe I'm just quibbling over the definition of "reputation service", or maybe my definition isn't broad enough. But I don't think of DNSBLs or RHSBLs that way, yet. I'll mull it over. > However, currently it's hard to know what to whitelist. There's only one > widespread, easy to use mechanism for managing information about which IP > addresses an organisation is likely to send messages from - that's SPF. > OK, so if you wanted to be sure to get mail from me, you could whitelist > my /24 address block, but are you sure that I'd keep you updated if we > outsourced our email? But this is not one of my pressing concerns: oh, it's not totally off my radar, but it's far down on the priority scale. I'll try to explain below. > Yes, the problem of course is when a spammer forges a domain that I'd > like to trust. If I'm filtering mail from the domain of my chief funders, > then false positives can be really painful. If I whitelist them, then > spammers can easily bypass my filters. So what I'm discussing IS all > about forgery. If you are efficiently blocking spam, then this may be somewhat of a non-issue. (It pretty much is for me.) Let me illustrate with an example: traffic was presented a little while ago on port 25 from 123.140.212.144: I could have sanity-checked the HELO. I could have run it through SPF or similar, but didn't. I could have waited for the data phase and run the content through SpamAssassin and/or ClamAV, but didn't. I could have looked up rDNS to see if it existed, but didn't. (Or, having it looked it up and found it to exist, checked the domain against various RHSBLs. And/or for MX sanity.) I could have checked the IP address it against various DNSBLs. Instead, the mail system noted that it's in Korean IP space, which for that mail server is a 100% source of spam and a 0% source of mail. So it was immediately rejected. So maybe it was a phish with forged sender address at Paypal -- and maybe I could have figured that out via one of the methods that have been discussed here. But my point is that I didn't need to, because I knew it was spam before getting that far. Repeat this for myriad variations -- use of various DNSBLs, use of the Spamhaus DROP list, various country allocations, thousands and thousands of spammer domains, dynamic/generic IP and name space, and so on. What I've found is that if I'm sufficiently aggressive about blocking spam sources (including pre-emptive blocks) that I don't need to worry so much about what's in the spam -- forged headers, bogus URLs, etc. -- because it never makes it to the point where I have concern myself with any of that. So my response to someone who says "I'm getting a lot of forged traffic claiming to be from Paypal and I need an anti-forgery method to figure that out" is "No, you need to be a lot more aggressive about blocking spam. AFTER you do that, you should re-assess, see if this is still actually a problem for you, and then, maybe, you might consider anti-forgery technology of one sort or another, or even ad hoc local checks for some specific cases, like maybe the credit union that serves your university." Does this kinda clarify where I'm coming from? >> I think perhaps I have this viewpoint because my focus is on my biggest >> (ongoing) problem: what to do about the 99% of incoming mail that needs >> to be rejected outright before it can get anywhere near a user. > > You mean you want to know how to identify it? Or what to do with it after > you've identified it? The former -- because my approach to the latter is "issue a reject, hang up, move on" in all cases. (Although I should mention in passing that DNS lookup failures get a 4XX 'cause maybe their DNS is hosed, maybe mine is hosed, maybe transport is fubar.) The former is tougher, because -- despite my aggressive approach to spam, I don't want to deal with a high FP rate. I've come to conclusion that one approach which seems to work boils down to "know your email": study traffic patterns, inbound and outbound. Every mail server (that I've ever looked at) has different characteristics, and if you can figure out what they are, then you can twiddle the knobs in very server-specific ways that minimize FN and FP at the same time. (See example above, which clearly would not work at all on some other servers -- say for a research university.) Of course, this takes time and patience -- but I'll argue that we should be trying to extract the most from the methods we already have (like the ones I tossed out above), that we understand fairly well, and that we know work on a large scale in production environments, before we try to invent and deploy new methods. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 20:54:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006CC3A6852; Thu, 22 Jan 2009 20:54:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0C63A68F7 for ; Thu, 22 Jan 2009 20:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] 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 rCfLYmeLwQeB for ; Thu, 22 Jan 2009 20:54:50 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id BA0383A67F7 for ; Thu, 22 Jan 2009 20:54:50 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0N4sWXE010675 for ; Thu, 22 Jan 2009 23:54:33 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0N4j0Xp012915 for ; Thu, 22 Jan 2009 23:45:20 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0N4s72A011356 for ; Thu, 22 Jan 2009 23:54:07 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0N4s7Pl011355 for asrg@irtf.org; Thu, 22 Jan 2009 23:54:07 -0500 Date: Thu, 22 Jan 2009 23:54:07 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090123045407.GB28612@gsp.org> References: <4974E6CD.3070705@terabites.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4974E6CD.3070705@terabites.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Mon, Jan 19, 2009 at 02:47:09PM -0600, Gordon Peterson wrote: > If 90% of all the computer workstations were running Linux, then the > virus/malware authors would be writing viruses for THAT platform. Same > is true for Macs. This is nonsense: there *was* a time when most of the computer workstations on this network were running Unix, yet we did not see massive malware infections with network-wide negative impact on a recurring and persistent basis. We saw one. Over twenty years ago. And it was eradicated in 48 hours. That's roughly 10000 times lower than the malware incidence rate for Windows. And if this claim were true today, then we would expect to see infected systems roughly in proportion to their deployment: if OS type A was 6% of the population, then we would expect to see systems of OS type A accounting for 6% of infections. But we don't. We don't see anything even remotely close to that. ( Actually, since Unix/Linux systems are vastly preferable targets -- thanks to their markedly superior capabilities and their frequent use in security-critical applications, we should expect to see infection rates somewhat *higher* than their population percentage. We see precisely the opposite. ) What we do see is a minimum of at least a hundred million compromised Windows systems. Credible and experienced observers have postulated that the real number may now be two to three times that, and I've found no contradicting evidence. ( Of course, that speculation can't be directly proven or disproven, since any system which doesn't provide evidence to an external detector won't be observed. Every those with very large numbers of detectors, e.g., the CBL, are no doubt missing large numbers of these. Moreover, any system which has been zombied but which emits no traffic signalling that state will remain undetected indefinitely no matter how many detectors there are and how adept they are at noticing the signs. Given what we know of abuser strategy and tactics, it seems very likely that large numbers of such systems are held in reserve. ) Whatever the "real" number is: it's very big, and getting bigger. And there's no reason to anticipate that the trend will reverse, and a number of reasons to believe it will get worse. [2] But don't take my word for it: run the experiment yourself. Turn on passive OS fingerprinting in your perimeter devices (or on your servers) and correlate that data with: - spam attempts - ssh attempts - ftp attempts - pop/imap attempts - port scans - crafted packet attacks - http-based exploit attempts - DoS attacks - etc. After a year or two, I think you'll find is what I've found after running this experiment in multiple environments of different sizes, characteristics, purposes, etc.: the abuse problem is largely (in some cases, almost exclusively) a Microsoft Windows problem. [1] And it's clear that the correlation far exceeds the population percentage, either as-observed or as-guesstimated. (Some of my sensors have gone for months without detecting a non-Windows-originated ssh attempt, for instance.) Incoming spam, for example, differentiates into three categories: (a) zombies, and the number of non-Windows zombies is negligible; (b) incompetently-run mail servers, e.g., Yahoo, Hotmail, of varying OS composition; and (c) spammer-owned/leased mail servers, also of varying OS composition. And category (a) dominates - by attempts, by volume, by extent, by everything. (Hardly surprising: it's the most cost-effective and anti-spam-resistant method for abusers. They'd be silly not to exploit it.) This isn't a new observation nor is it original with me: note this wonderfully clever hack, from almost exactly 5 years ago: openbsd's fingerprinting and shaping used for evil^Wgood http://use.perl.org/~merlyn/journal/17094 As a result, it's long since become part of my anti-spam and overall security strategy to consider anything originating on a Windows system as "suspect", at best, and to subject such traffic to (a) rate-limiting (b) refusal (c) higher scrutiny and/or (d) modified services. I highly recommend this approach for anybody with the facilities to use it: the results are striking. ---Rsk [1] You'll also find that zombies are obviously acting in concert. We've known for years that a variety of techniques are used to coordinate their activities: top-down control, P2P methods, etc. It seems more than likely that following incidents like the McColo shutdown that abusers will reconsider and develop more resilient methods that are more resistant to the loss of any control point. [2] Among those reasons: I'm waiting for the use of virtualization by malware, so that (a) the putative owner of the system can be sandboxed into a VM which checks out as "clean" when scanned by anti-malware products and (b) VM instances can be separately created and leased in bulk, thus permitting multiple abusers to utilize a system's hardware resources simultaneously. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 22 21:18:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BED3A6994; Thu, 22 Jan 2009 21:18:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428D83A6994 for ; Thu, 22 Jan 2009 21:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.372 X-Spam-Level: X-Spam-Status: No, score=-8.372 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 NNESOiyqCm3C for ; Thu, 22 Jan 2009 21:18:52 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 2A7213A689F for ; Thu, 22 Jan 2009 21:18:51 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id AAA09161; Fri, 23 Jan 2009 00:18:34 -0500 (EST) From: der Mouse Message-Id: <200901230518.AAA09161@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 23 Jan 2009 00:10:19 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090123045407.GB28612@gsp.org> References: <4974E6CD.3070705@terabites.com> <20090123045407.GB28612@gsp.org> Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >> If 90% of all the computer workstations were running Linux, then the >> virus/malware authors would be writing viruses for THAT platform. >> Same is true for Macs. > This is nonsense: there *was* a time when most of the computer > workstations on this network were running Unix, yet we did not see > massive malware infections with network-wide negative impact on a > recurring and persistent basis. Yes, but there were some other important differences. To name just the first two that comes to mind, there was basically no money to be had writing malware, and the network was substantially more heterogenous than today's is. ("Windows" now is not homogenous, no, but I believe it's closer than "Unix" then was.) Furthermore, the claim you're replying to is about what would be written. What sort of infection rates the resulting malware would achieve are a separate question. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 00:02:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5093228C163; Fri, 23 Jan 2009 00:02:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D218128C199 for ; Fri, 23 Jan 2009 00:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599] 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 ZQK1J2f02hlJ for ; Fri, 23 Jan 2009 00:02:07 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 7D6A028C15B for ; Fri, 23 Jan 2009 00:01:04 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0N80b9n014637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2009 00:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232697646; x=1232784046; bh=H+2LpQrkS5tHjjq4Jcz3v8B9JE7NB81iQdgRlHcxm2g=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=aiPtDeTlko2I6U2rx8lPIm/zTYEWHqKBqy0by/N+RJdhFr34QyWs9JJP9ZXebNISn hez2+dQFxnCcKa2fNm9k/+FSoaz41xTT6s1z1bQgEQG/DkT7mZdHYQ4FjCNtlzCSjt BmI9/2knAfaLBWHesZDgM+ejlfX78OdBG65CiJtg= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=bbZcm5uO6iGvTQw830kKby12Oqp1U8OjvUeYvuRtaYYqXRNiirX2m3t/A7q+MS9o3 OgDuiQWIk1VippOVQWXpHqNcAEKXvEnOkJ4dtfAvYvOcjVkdm82aRORSrRGpVgD7ivm 7MUK4atDnzwgM2OVtyVuw5qrK6wLdOoHTF7zIIE= Message-Id: <6.2.5.6.2.20090122233519.02ebdf20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Jan 2009 00:00:24 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <20090123045407.GB28612@gsp.org> References: <4974E6CD.3070705@terabites.com> <20090123045407.GB28612@gsp.org> Mime-Version: 1.0 Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 20:54 22-01-2009, Rich Kulawiec wrote: >But don't take my word for it: run the experiment yourself. Turn on >passive OS fingerprinting in your perimeter devices (or on your servers) >and correlate that data with: > > - spam attempts > - ssh attempts > - ftp attempts > - pop/imap attempts > - port scans > - crafted packet attacks > - http-based exploit attempts > - DoS attacks > - etc. > >After a year or two, I think you'll find is what I've found after running >this experiment in multiple environments of different sizes, characteristics, >purposes, etc.: the abuse problem is largely (in some cases, almost >exclusively) a Microsoft Windows problem. [1] And it's clear that >the correlation far exceeds the population percentage, either as-observed >or as-guesstimated. (Some of my sensors have gone for months without >detecting a non-Windows-originated ssh attempt, for instance.) I'm commenting on the spam attempts only as I've been running an experiment on that since several years. In general, most of the SMTP sessions from Windows hosts are spam attempts. Passive OS Fingerprinting in combination with other heuristics can be quite effective in detecting spam attempts. >As a result, it's long since become part of my anti-spam and overall >security strategy to consider anything originating on a Windows system >as "suspect", at best, and to subject such traffic to (a) rate-limiting >(b) refusal (c) higher scrutiny and/or (d) modified services. I highly >recommend this approach for anybody with the facilities to use it: >the results are striking. Such a strategy doesn't work well in some environments where there is a higher proportion of valid messages from Windows-based mail servers. Some people might need an exception list if they implement the above methods. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 02:41:22 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4511D3A69DE; Fri, 23 Jan 2009 02:41:22 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5DB3A6900 for ; Fri, 23 Jan 2009 02:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] 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 Owa7Kd5DF3uL for ; Fri, 23 Jan 2009 02:41:19 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 031E13A6832 for ; Fri, 23 Jan 2009 02:41:18 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64145) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDX75J-000KF8-DZ for asrg@irtf.org; Fri, 23 Jan 2009 10:44:08 +0000 Date: Fri, 23 Jan 2009 10:40:58 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090123044753.GA28612@gsp.org> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <5A9E442BA44F58E41B9FA2D4@lewes.staff.uscs.susx.ac.uk> <20090121020748.GB30757@gsp.org> <8406D1E92C5D95C9DF48BCEB@lewes.staff.uscs.susx.ac.uk> <20090123044753.GA28612@gsp.org> Originator-Info: login-token=Mulberry:01ii14W/OO5sDLmsy99lP9ouvO8KWZte1T/5g=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 22 January 2009 23:47:53 -0500 Rich Kulawiec wrote: > On Wed, Jan 21, 2009 at 10:48:08AM +0000, Ian Eiloart wrote: >> I guess that depends on the nature of the RBL. Some of them really are >> reputation systems. IP addresses get listed because someone has seen >> spam coming from them. Spamhaus' SBL is an example. If you don't agree >> that that's a reputation service, please explain. > > I don't agree that's a reputation service. It's a binary flag (on a > per-IP basis) saying "this address has been observed (at one or more > observation points) as sending spam". And that's all it says -- and it > only says it about a subset of IP addresses (those seen emitting spam) > and only about a subset of those (those seen by Spamhaus-affiliated > sensors) and only about a subset of those (add some notion of "recently" > -- an address that spewed in the past may not be listed now). > > That's highly useful information if my goal is to block spam, but it's > only marginally useful if my goal is to do anything else. > > (BTW: there's only one RBL, and Spamhaus doesn't run it. They run > DNSBLs.) I stand corrected. > Maybe I'm just quibbling over the definition of "reputation service", > or maybe my definition isn't broad enough. But I don't think of DNSBLs > or RHSBLs that way, yet. I'll mull it over. OK, I see where you're coming from now. I guess we might agree that DNSBLs collectively provide a minimalist reputation service. I do think that DNSBLs speak to the reputation of some email emitters. In that respect, I'd argue that even a single data point constitutes a comment on reputation, and it it's available to me then it's providing me with a service - even if the service is no good. However, even a single datapoint could be a useful service if it stopped lots of spam for me. Collectively, DNSBLs provide more than binary information about a single IP address. For example, you could consult a dozen of them, and compare a weighted sum of their responses against a threshold determined in your local anti-spam policy. I disagree that they say nothing about addresses that they don't list. Silence is a comment, in this context. Provided that list policies apply to all IP addresses equally, then they are commenting on all IP addresses. However, if a DNSBL had a policy (explicit or implicit) that it would never list a certain address range, then the service ceases to be comprehensive. It doesn't cease to be a service, though. >> However, currently it's hard to know what to whitelist. There's only one >> widespread, easy to use mechanism for managing information about which >> IP addresses an organisation is likely to send messages from - that's >> SPF. OK, so if you wanted to be sure to get mail from me, you could >> whitelist my /24 address block, but are you sure that I'd keep you >> updated if we outsourced our email? > > But this is not one of my pressing concerns: oh, it's not totally > off my radar, but it's far down on the priority scale. I'll try > to explain below. > >> Yes, the problem of course is when a spammer forges a domain that I'd >> like to trust. If I'm filtering mail from the domain of my chief >> funders, then false positives can be really painful. If I whitelist >> them, then spammers can easily bypass my filters. So what I'm >> discussing IS all about forgery. > > If you are efficiently blocking spam, then this may be somewhat > of a non-issue. (It pretty much is for me.) Let me illustrate > with an example: traffic was presented a little while ago on > port 25 from 123.140.212.144: > > I could have sanity-checked the HELO. > > I could have run it through SPF or similar, but didn't. > > I could have waited for the data phase and run the content > through SpamAssassin and/or ClamAV, but didn't. > > I could have looked up rDNS to see if it existed, but didn't. > (Or, having it looked it up and found it to exist, checked > the domain against various RHSBLs. And/or for MX sanity.) > > I could have checked the IP address it against various DNSBLs. > > Instead, the mail system noted that it's in Korean IP space, > which for that mail server is a 100% source of spam and a 0% > source of mail. So it was immediately rejected. > > So maybe it was a phish with forged sender address at Paypal -- > and maybe I could have figured that out via one of the methods > that have been discussed here. But my point is that I didn't > need to, because I knew it was spam before getting that far. > > Repeat this for myriad variations -- use of various DNSBLs, use of > the Spamhaus DROP list, various country allocations, thousands and > thousands of spammer domains, dynamic/generic IP and name space, > and so on. What I've found is that if I'm sufficiently aggressive > about blocking spam sources (including pre-emptive blocks) > that I don't need to worry so much about what's in the spam -- forged > headers, bogus URLs, etc. -- because it never makes it to the point > where I have concern myself with any of that. > > So my response to someone who says "I'm getting a lot of forged > traffic claiming to be from Paypal and I need an anti-forgery > method to figure that out" is "No, you need to be a lot more > aggressive about blocking spam. AFTER you do that, you should > re-assess, see if this is still actually a problem for you, and > then, maybe, you might consider anti-forgery technology of one > sort or another, or even ad hoc local checks for some specific > cases, like maybe the credit union that serves your university." > > Does this kinda clarify where I'm coming from? Yes, it does. However, I'm an admin for a University with students from most countries in the world, and academics that work in most countries in the world, and studying every topic under the sun - including SPAM! So, it's very difficult for me to be that aggressive. I certainly block IP addresses according to country allocation. That's why I need more information about who the IP addresses belong to. Without that information, and with the prevalance of sender address forgery, the IP address is the only real information that I have about a message before it's too late to reliably apply recipient specific filtering. >>> I think perhaps I have this viewpoint because my focus is on my biggest >>> (ongoing) problem: what to do about the 99% of incoming mail that needs >>> to be rejected outright before it can get anywhere near a user. >> >> You mean you want to know how to identify it? Or what to do with it >> after you've identified it? > > The former -- because my approach to the latter is "issue a reject, > hang up, move on" in all cases. (Although I should mention in passing > that DNS lookup failures get a 4XX 'cause maybe their DNS is hosed, > maybe mine is hosed, maybe transport is fubar.) > > The former is tougher, because -- despite my aggressive approach > to spam, I don't want to deal with a high FP rate. I've come to > conclusion that one approach which seems to work boils down to > "know your email": study traffic patterns, inbound and outbound. > Every mail server (that I've ever looked at) has different > characteristics, and if you can figure out what they are, then you can > twiddle the knobs in very server-specific ways that minimize FN and FP at > the same time. (See example above, which clearly would not work at > all on some other servers -- say for a research university.) > > Of course, this takes time and patience -- but I'll argue that > we should be trying to extract the most from the methods we already have > (like the ones I tossed out above), that we understand fairly well, > and that we know work on a large scale in production environments, > before we try to invent and deploy new methods. > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 02:43:49 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8608B3A6900; Fri, 23 Jan 2009 02:43:49 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30503A69C6 for ; Fri, 23 Jan 2009 02:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] 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 aadrCj9VGKbA for ; Fri, 23 Jan 2009 02:43:48 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id DB9DC3A6900 for ; Fri, 23 Jan 2009 02:43:47 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64172) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDX79R-000LEG-KE for asrg@irtf.org; Fri, 23 Jan 2009 10:46:39 +0000 Date: Fri, 23 Jan 2009 10:43:30 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <50D22D801CEFD7939A12A8A6@lewes.staff.uscs.susx.ac.uk> In-Reply-To: References: Originator-Info: login-token=Mulberry:01tiygVh+NDrv3mfS4IlIpoRPJHKTBsBlSK5c=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 10:33:50 -0700 "J.D. Falk" wrote: > On 21/01/2009 04:16, "Ian Eiloart" wrote: > >> Interestingly, you don't get feedback when Yahoo has put your mail into a >> spam mailbox. Only when it's marked as spam by the end user. > > That's why it's called a Complaint Feedback Loop. All of the other North > American ISPs who provide feedback work basically the same way. Yes, I guess it makes sense, but it's not something that I'd really thought about. > I've heard that there are a few European ISPs who provide filtering-based > feedback to each other, but not to just anyone who asks. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 02:48:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7393A6A85; Fri, 23 Jan 2009 02:48:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9353A6A85 for ; Fri, 23 Jan 2009 02:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] 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 4mHWtDu+3voa for ; Fri, 23 Jan 2009 02:48:23 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 208033A6A84 for ; Fri, 23 Jan 2009 02:48:22 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64227) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDX7HE-0000IG-A5; Fri, 23 Jan 2009 10:51:14 +0000 Date: Fri, 23 Jan 2009 10:48:05 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF , Alessandro Vesely Message-ID: <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090121172756.GL24908@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> Originator-Info: login-token=Mulberry:01vX0F3Cbec0H+6lk+KaMw8nhPI/UmNiCjMug=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 12:27:56 -0500 John Leslie wrote: > Alessandro Vesely wrote: >> John Leslie wrote: >> >>> Fundamentally, of course, the attempt to have one-size-fits-all >>> processing by the receiving MTA is dubious. It's not the coding of >>> SPF records that breaks forwarding: it's the processing of them. >>> Relaxing the processing rules could help a lot. >> >> Would you please expand on that? Relaxing rules implies the knowledge >> that a message is being forwarded. Are you talking about whitelisting >> well known forwarders, or what? > > I was intentionally vague... > > However, there are a limited number of ways that forwarding might be > shown in the trace headers, so it should be practical to determine that > a forwarding is documented (though possibly forged). > > We then have a quite different situation from what raw SPF processing > would indicate. Thus I claim the rules deserve to be relaxed (without > going into detail how). > > Forging headers to indicate forwarding which didn't happen indicates > evil intent, and should be practical to block-list like other spamming > IPs. Well-known forwarders could be whitelisted, enabling us to trust > their pre-forwarding headers. Et cetera... Blech. Why not just let them rewrite the sender address. People just should not be encouraged to send email with return-paths in domains that don't belong to them. It simply postpones the day when we can hold senders accountable for their traffic. > >>> And I see promise in the use of the pending Authentication-Results >>> header (though I must agree with Doug Otis that it would be stronger >>> if it included the IP address). >> >> Hm... the header's name suggests it is reporting already acquired >> results, as had been noted. I'm surprised Doug didn't propose an >> additional test more in tune with that spirit, e.g. >> >> Authentication-Results: example.com; >> dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3 > > I'll let Doug speak for himself. I didn't propose such a thing > because I believe arguing over extensions would detract from getting > the basic header adopted. > > (I do believe that adding a resinfo listing the IP address is a > practical way to deal with SPF's choice to omit it from their resinfo.) > > -- > John Leslie > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 03:00:47 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619093A6A3A; Fri, 23 Jan 2009 03:00:47 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCD03A6A3A for ; Fri, 23 Jan 2009 03:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 A8r2hBy-M1-n for ; Fri, 23 Jan 2009 03:00:44 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 4F3EB3A69DE for ; Fri, 23 Jan 2009 03:00:44 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64355) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDX820-0005PJ-0T for asrg@irtf.org; Fri, 23 Jan 2009 11:03:36 +0000 Date: Fri, 23 Jan 2009 11:00:26 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <27D11DE5599870766A451060@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090122160720.GA29632@gsp.org> References: <20090120145354.57509.qmail@simone.iecc.com> <4976299A.7060502@dcrocker.net> <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> <20090122160720.GA29632@gsp.org> Originator-Info: login-token=Mulberry:01sxlo5Bx61kn0hrxGHz8mjttXGZGJPhY/KIQ=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 22 January 2009 11:07:20 -0500 Rich Kulawiec wrote: > On Wed, Jan 21, 2009 at 11:43:39AM +0000, Ian Eiloart wrote: >> Agreed. That's why I'm discussing SPF or DKIM with a reputation service. >> In the first instance, my reputation service is going to be a local >> whitelisting mechanism. I'll probably have some domains whitelisted for >> my entire site. Perhaps all .ac.uk domains, for example. Then I'll allow >> users to whitelist domains and addresses that they trust. However, the >> whitelisting mechanism will rely on an SPF or DKIM pass. > > Even if you go that route -- and I'll skip getting into its instrinsic > merits and problems here -- I think you shouldn't allow users to whitelist > *anything*, ever, without manual review by qualified personnel, for > at least two reasons I can think of. Well, I don't think we have the staff capacity to do that. I guess we might require review when entire domains are whitelisted, and I guess that if we're permitting one person to whitelist a domain, then we should permit anyone to whitelist that domain. Of course, if a domain doesn't have an SPF or DKIM record, then we won't let anyone whitelist it or any address in that domain. And, if a message doesn't have a positive SPF or DKIM match, we'll ignore the whitelist entry - or perhaps warn the recipient if we don't accept the message. I don't know how I could be a better judge than a user about whether they want to whitelist a specific email address. However, we could present them with a warning if the try to list an address (in a domain)? with a poor rating in our reputation service. The point here is that permitting address A to email address B only exposes one person to risk - the person doing the whitelisting. Oh, and I'd never allow any email (other than to postmaster@ or abuse@) to bypass our malware filter. That would turn a spam threat to an individual into a threat to our network. > > First, users have very poor skills in this area. (Not their fault, > really, it's not their gig.) We can tell how poor their skills by > a number of methods, but I think the most obvious is: if they were > any good at it, then phishing would be an inconsequential problem. > > Another way to tell is to monitor outbound SMTP and HTTP requests > and note which ones have being directed to known-fraudulent domains. > I see this constantly, even in environments where users have been > told ad infinitum to never reply to a suspected spam/phish, never > to follow any links in them, etc. (In some environments, I block them. > I'm beginning to think that's a best practice, even in cases where > subsequently the real targets have acquired the phisher domains, > as I think they know never to use them.) > > Second, how do you know that it's actually the users doing this? > > I'm not saying that you shouldn't maintain something along the lines > of a whitelist, or an exempted-from-blacklist, or some other function. > I'm saying that nothing should ever go into that list until somebody who > knows about DNS and WHOIS and is appropriately paranoid has looked at it. > > ---Rsk > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 03:07:35 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F9C3A6A56; Fri, 23 Jan 2009 03:07:35 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10D83A6A56 for ; Fri, 23 Jan 2009 03:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 KANBRDjJvJkK for ; Fri, 23 Jan 2009 03:07:34 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id DA55E3A69DE for ; Fri, 23 Jan 2009 03:07:32 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64432) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDX8DC-0008DW-L2 for asrg@irtf.org; Fri, 23 Jan 2009 11:10:24 +0000 Date: Fri, 23 Jan 2009 11:07:15 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <42CED4A2DDC3CA3E79A061E5@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090122020229.45279.qmail@simone.iecc.com> References: <20090122020229.45279.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:018kQ3yFulpS0zsYsqXmpluao7WLxYIlVqZ68=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF, was where the message X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 22 January 2009 02:02:29 +0000 John Levine wrote: >>> For senders that are on its whitelist, AOL reverse engineers the IP >>> addresses to whitelist from the sender's SPF records, which is way >>> easier all around than the former mostly manual system. >>> >>> Since S-ID falls back to SPF records, most senders just publish one set >>> of SPF records for both. Note that neither of these are using SPF for >>> its nominal purpose; I'm not aware of any large system that does. >> >> They're using it for whitelisting purposes instead of its nominal >> purpose? That's exactly what I'm discussing. > > Every once in a while, AOL fetches the SPF records for senders in > their whitelist, crunches them to get a set of IP addresses, and then > puts those IP addresses into their whitelist. AOL's whitelisting > process is based on IPs, with the SPF bit merely being a cheap way for > senders to tell AOL what IPs they use. They do not use SPF > per-message, nor as far as I can tell do they make any attempt to > match up the bounce address on incoming mail to the domain from which > they got the IP in the whitelist. Aren't the two things functionally equivalent? Oh, I guess that they're effectively whitelisting ALL email from IP addresses for which they trust ANY domain. I hope they've got some process that prevents them falling foul of the obvious attack. > >> I think SPF has a bad reputation in some quarters because people >> think of how it breaks forwarding (etc). > > It could be somewhat useful for whitelisting some kinds of mail. Too > bad it's been so egregiously oversold. Agreed. It's exactly why publication of SPF records (with ~all) should be encouraged. Once people get the hang of that, and using MSA, we'll be in a world where -all records will be less risky. > R's, > John > > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 05:05:17 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F15A3A686C; Fri, 23 Jan 2009 05:05:17 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80403A686C for ; Fri, 23 Jan 2009 05:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 OFaGtLcU67GB for ; Fri, 23 Jan 2009 05:05:15 -0800 (PST) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id D07DB3A6867 for ; Fri, 23 Jan 2009 05:05:13 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50448) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDXDQJ-0006YC-NL for asrg@irtf.org; Fri, 23 Jan 2009 13:06:19 +0000 Date: Fri, 23 Jan 2009 13:04:53 +0000 From: Ian Eiloart cc: Anti-Spam Research Group - IRTF Message-ID: <715F61B951D3302E646D646E@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <49774959.1090203@dcrocker.net> References: <20090119190814.38720.qmail@simone.iecc.com> <703FA3568538C7F152F87491@lewes.staff.uscs.susx.ac.uk> <20090120121015.GC11455@gsp.org> <49769759.8070102@dcrocker.net> <639946698B170D6E856E1DF3@lewes.staff.uscs.susx.ac.uk> <49774959.1090203@dcrocker.net> Originator-Info: login-token=Mulberry:01BFB1122x4zxFvck5cHZ3xehKasiWMWd2ebs=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 21 January 2009 08:12:09 -0800 Dave CROCKER wrote: > > > Ian Eiloart wrote: >>> It's not interesting who publishes SPF records. >>> >>> It's interesting who reads them. >> >> That depends on whether you're deciding whether to publish them, or >> whether to read them. > > > For the purpose of assessing Internet utility, consumption is a better > indicator than publication. Like I said, you need both. But, I'm not interested in "Internet utility", whatever that might be. I'm interested in utility to me. I presume that what's useful to me might also be useful to some others. > I understood this thread to be discussing utility. There are many kinds. > Publication without consumption has zero utility. So does consumption > without publication, of course, but if there is a community wishing to > consume, there will almost certainly come to be a community doing the > publication. Except that there's no obvious way to advertise the fact that you're consuming. We know that there's widespread publication. We don't know whether there's widespread consumption - unless someone has stats gathered from DNS servers. Even if we had stats from DNS servers, it's hard to know what anyone is doing with the information. Widespread selective whitelisting would be hard to detect, for example. > > In contrast we've had ample demonstration that that publication does not > have any automatic implication about consumption. > > d/ -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 05:09:27 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE4128C163; Fri, 23 Jan 2009 05:09:27 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600C428C15B for ; Fri, 23 Jan 2009 05:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5vU-MXId5BGd for ; Fri, 23 Jan 2009 05:09:25 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 6EE6828C14A for ; Fri, 23 Jan 2009 05:09:25 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0ND979r025935 for ; Fri, 23 Jan 2009 08:09:08 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0NCxYxW026323 for ; Fri, 23 Jan 2009 07:59:54 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0ND8fYL027604 for ; Fri, 23 Jan 2009 08:08:42 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0ND8fG3027603 for asrg@irtf.org; Fri, 23 Jan 2009 08:08:41 -0500 Date: Fri, 23 Jan 2009 08:08:41 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090123130841.GA24196@gsp.org> References: <20090120145354.57509.qmail@simone.iecc.com> <4976299A.7060502@dcrocker.net> <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> <20090122160720.GA29632@gsp.org> <27D11DE5599870766A451060@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <27D11DE5599870766A451060@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, Jan 23, 2009 at 11:00:26AM +0000, Ian Eiloart wrote: > Well, I don't think we have the staff capacity to do that. It's not really that difficult, if well-organized. Having done this in practice for a number of years, I can report that my experience has been that nearly all such requests can be denied on inspection -- to the point where I've scripted much of it. For example: all requests to whitelist the incompetently-managed and spammer-infested domain "yahoo.com" are automatically denied. All requests to whitelist domains that have been placed in the local blacklist (which is done only after considerable study) are denied, since there is never any reason to delist any known spammer. The ones that actually merit attention and might result in action are almost always transient, accidental cases: e.g., example.com is a long-time source of non-spam mail but fubar'd their DNS while making a change, and we need to exempt them from DNS checks while they work it out. One thing that's quite revealing is how many users ask for obvious phish domains to be whitelisted. Were the process automated, without human review, any number of fake eBay and Chase and Visa &etc. domains would have long since been repeatedly whitelisted. I'm skeptical about the merits of doing per-address whitelisting, even though I do some of it. On the one hand, it accomodates people who are stuck with poorly-run systems and networks. On the other hand, it removes much of their motivation to agitate for a change in that situation. A compromise that I've used, some of the time, is to provide them with service, but slower/degraded service, and explain to them that I'd be delighted to extend to them the same privileges as others enjoy, but that their operation needs to step up the responsibility that goes along with that. Sometimes this works, other times it fails. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 05:17:09 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBC63A6858; Fri, 23 Jan 2009 05:17:09 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373503A6858 for ; Fri, 23 Jan 2009 05:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] 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 IU0QeURrh6Eq for ; Fri, 23 Jan 2009 05:17:07 -0800 (PST) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 418BD3A6837 for ; Fri, 23 Jan 2009 05:17:07 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50646) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDXEAF-000B95-PC for asrg@irtf.org; Fri, 23 Jan 2009 13:18:16 +0000 Date: Fri, 23 Jan 2009 13:16:49 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090123130841.GA24196@gsp.org> References: <20090120145354.57509.qmail@simone.iecc.com> <4976299A.7060502@dcrocker.net> <9AA650282911ED79058C8C16@lewes.staff.uscs.susx.ac.uk> <20090122160720.GA29632@gsp.org> <27D11DE5599870766A451060@lewes.staff.uscs.susx.ac.uk> <20090123130841.GA24196@gsp.org> Originator-Info: login-token=Mulberry:01byuJdtiM99uwmN3Y21HioPzp1aOq0NJR5JY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 23 January 2009 08:08:41 -0500 Rich Kulawiec wrote: > On Fri, Jan 23, 2009 at 11:00:26AM +0000, Ian Eiloart wrote: >> Well, I don't think we have the staff capacity to do that. > > It's not really that difficult, if well-organized. Having done this > in practice for a number of years, I can report that my experience has > been that nearly all such requests can be denied on inspection -- to > the point where I've scripted much of it. For example: all requests > to whitelist the incompetently-managed and spammer-infested domain > "yahoo.com" are automatically denied. All requests to whitelist domains > that have been placed in the local blacklist (which is done only after > considerable study) are denied, since there is never any reason to > delist any known spammer. The ones that actually merit attention and > might result in action are almost always transient, accidental cases: > e.g., example.com is a long-time source of non-spam mail but fubar'd > their DNS while making a change, and we need to exempt them from > DNS checks while they work it out. Yes, yes, yes. But I want to do something smarter that that, with more granularity. OK, I'm not going whitelist "yahoo.co.uk" or any of the other well known ESPs. However, I'm not going to spend staff time (there's me versus 16,000 users here) on determining whether foobar@yahoo.com is really a friend of barfoo@sussex.ac.uk > > One thing that's quite revealing is how many users ask for obvious > phish domains to be whitelisted. Were the process automated, without > human review, any number of fake eBay and Chase and Visa &etc. domains > would have long since been repeatedly whitelisted. > > I'm skeptical about the merits of doing per-address whitelisting, even > though I do some of it. On the one hand, it accomodates people who are > stuck with poorly-run systems and networks. On the other hand, it removes > much of their motivation to agitate for a change in that situation. I've a lot of sympathy with that. And, I currently don't do any whitelisting, and that's part of my reasoning. However, it does mean that spammers are making it harder to create working email communications systems, and that our anti-spam systems are often merely RFC compliance enforcement systems. I'd rather be fighting evil than incompetence! > A compromise that I've used, some of the time, is to provide them with > service, but slower/degraded service, and explain to them that I'd be > delighted to extend to them the same privileges as others enjoy, but > that their operation needs to step up the responsibility that goes > along with that. Sometimes this works, other times it fails. > > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 05:57:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36763A6A41; Fri, 23 Jan 2009 05:57:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA493A6A41 for ; Fri, 23 Jan 2009 05:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 51yZ80gYV7Wi for ; Fri, 23 Jan 2009 05:57:44 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id B8A1E3A6A07 for ; Fri, 23 Jan 2009 05:57:44 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0NDvQw1009256 for ; Fri, 23 Jan 2009 08:57:27 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0NDlruk002306 for ; Fri, 23 Jan 2009 08:48:13 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0NDv1xY010492 for ; Fri, 23 Jan 2009 08:57:01 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0NDuxSM010387 for asrg@irtf.org; Fri, 23 Jan 2009 08:56:59 -0500 Date: Fri, 23 Jan 2009 08:56:59 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090123135659.GA8168@gsp.org> References: <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <1232038610.32316.324.camel@tardis.isode.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1232038610.32316.324.camel@tardis.isode.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 04:56:50PM +0000, David Wilson wrote: > If someone discusses the nature of spam messages or phishing messages > via email, I would think that false positives are not surprising; > annoying, but not surprising. After all, one can be sending a message > containing precisely the kind of thing filters are attempting to detect. > So, I would say that there is a class of positives which should not > count against the detection mechanism. I don't agree. If the anti-X filter is so poorly written that mere discussions about X trip it, then that's a FP by definition. This is one of the many reasons why I largely eschew content-based filters, and why I try to use them only after all other methods have been tried: it's very hard to get them right. And it's also one of the reasons why I think anyone who's using them should be prepared not just for FNs, but for FPs -- which I believe Chris's operation is, based on what they return in reject messages. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 06:03:00 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8EF3A68D7; Fri, 23 Jan 2009 06:03:00 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBE53A6807 for ; Fri, 23 Jan 2009 06:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6kvShH8Cq5IE for ; Fri, 23 Jan 2009 06:02:58 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id A3A303A68D7 for ; Fri, 23 Jan 2009 06:02:58 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0NE2ex6028792 for ; Fri, 23 Jan 2009 09:02:41 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0NDr7Px010369 for ; Fri, 23 Jan 2009 08:53:27 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0NE2FYJ011666 for ; Fri, 23 Jan 2009 09:02:15 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0NE2Fiv011665 for asrg@irtf.org; Fri, 23 Jan 2009 09:02:15 -0500 Date: Fri, 23 Jan 2009 09:02:15 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090123140215.GA10727@gsp.org> References: <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <496F8299.9060506@tana.it> <496FA7EB.1020902@nortel.com> <20090115233954.4042724246@panix5.panix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090115233954.4042724246@panix5.panix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Thu, Jan 15, 2009 at 06:39:54PM -0500, Seth wrote: > It would be better to create a new protocol for the ARF responses > (even if it's just email on a new port, though I'd include some > extensions to allow for "Report of virus emitter on " "I already > know" "QUIT") This is a good point (as are others you made, which I've elided). But I'll argue that before we set about the difficult work of inventing and implementing another protocol, we should use the ones we have. SMTP rejects of malware-laden mail messages are one way of signalling emitters that they have problem, without allowing the problem to cause the external system to generate more outbound traffic. Should we be doing HTTP rejects? FTP rejects? And so on? And if we do, what are the benefits and risks? Can we make the FP rate low enough that we don't end up creating a secondary problem that's worse the one we're trying to solve? Can we avoid attempts to game the system and thus conduct DoS-by-proxy attacks? And so on. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 06:13:40 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF143A6923; Fri, 23 Jan 2009 06:13:40 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6B33A6923 for ; Fri, 23 Jan 2009 06:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ETekhnhnlguH for ; Fri, 23 Jan 2009 06:13:37 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id CBD903A6867 for ; Fri, 23 Jan 2009 06:13:37 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E46BE33C2C; Fri, 23 Jan 2009 09:13:19 -0500 (EST) Date: Fri, 23 Jan 2009 09:13:19 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090123141319.GA52653@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Ian Eiloart wrote: > --On 21 January 2009 12:27:56 -0500 John Leslie wrote: > >> However, there are a limited number of ways that forwarding might be >> shown in the trace headers, so it should be practical to determine that >> a forwarding is documented (though possibly forged). >> >> We then have a quite different situation from what raw SPF processing >> would indicate. Thus I claim the rules deserve to be relaxed (without >> going into detail how). The point I was attempting to make is that SPF records _can_ accurately reflect sender policy, while SPF processing will incorrectly indicate a violation of it. As things stand in SPF, folks end up publishing less-correct records in an attempt to tune to a more satisfactory result. >> Forging headers to indicate forwarding which didn't happen indicates >> evil intent, and should be practical to block-list like other spamming >> IPs. Well-known forwarders could be whitelisted, enabling us to trust >> their pre-forwarding headers. Et cetera... > > Blech. Why not just let them rewrite the sender address. You, of course, are welcome to do whatever you want with SPF records; I happen to dislike punishing MTAs for following the SMTP specs. But please understand that strict SPF processing hasn't yet stopped forwarding MTAs from documenting the forwarding according to spec rather than rewriting addresses the way you want them to. Do you really believe this will change? > People just should not be encouraged to send email with return-paths > in domains that don't belong to them. It simply postpones the day when > we can hold senders accountable for their traffic. Unfortunately, that is what the SMTP RFCs call for: if you don't like it, you should be seeking consensus to change them. Furthermore, you seem to be confusing "people who send email" with MTAs which process it. The return-path is intended to be the "best" address for notifications. As things currently stand, MTAs are in no position to second-guess whether some other address would be "better". -- John Leslie _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 06:23:13 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A443A68D7; Fri, 23 Jan 2009 06:23:13 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85433A68D7 for ; Fri, 23 Jan 2009 06:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] 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 bX9UJxI5u-Qk for ; Fri, 23 Jan 2009 06:23:12 -0800 (PST) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id CFC9A3A6807 for ; Fri, 23 Jan 2009 06:23:11 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51851) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KDXHCH-000FK7-ER for asrg@irtf.org; Fri, 23 Jan 2009 14:24:18 +0000 Date: Fri, 23 Jan 2009 14:22:49 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <4D481FE56A88C6276A9BF80A@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090123141319.GA52653@verdi> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> <20090123141319.GA52653@verdi> Originator-Info: login-token=Mulberry:01cO3RBdlOP2qxWiVn3BPjYkR41mXyX9MT5Vg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 23 January 2009 09:13:19 -0500 John Leslie wrote: > Ian Eiloart wrote: >> --On 21 January 2009 12:27:56 -0500 John Leslie wrote: >> >>> However, there are a limited number of ways that forwarding might be >>> shown in the trace headers, so it should be practical to determine that >>> a forwarding is documented (though possibly forged). >>> >>> We then have a quite different situation from what raw SPF processing >>> would indicate. Thus I claim the rules deserve to be relaxed (without >>> going into detail how). > > The point I was attempting to make is that SPF records _can_ accurately > reflect sender policy, while SPF processing will incorrectly indicate a > violation of it. > > As things stand in SPF, folks end up publishing less-correct records > in an attempt to tune to a more satisfactory result. > >>> Forging headers to indicate forwarding which didn't happen indicates >>> evil intent, and should be practical to block-list like other spamming >>> IPs. Well-known forwarders could be whitelisted, enabling us to trust >>> their pre-forwarding headers. Et cetera... >> >> Blech. Why not just let them rewrite the sender address. > > You, of course, are welcome to do whatever you want with SPF records; > I happen to dislike punishing MTAs for following the SMTP specs. > > But please understand that strict SPF processing hasn't yet stopped > forwarding MTAs from documenting the forwarding according to spec > rather than rewriting addresses the way you want them to. Do you really > believe this will change? Something has to. Every false positive I encounter says so. My guess is that deployment of spf will grow gradually to the point where people start taking notice, and one day it will be normal, and people will start to notice that they're having difficulty forwarding email without, for example, using SRS. >> People just should not be encouraged to send email with return-paths >> in domains that don't belong to them. It simply postpones the day when >> we can hold senders accountable for their traffic. > > Unfortunately, that is what the SMTP RFCs call for: if you don't > like it, you should be seeking consensus to change them. I'm sort of doing that here. DKIM might be a suitable solution for this, but it's something you can only process after seeing the data. > Furthermore, you seem to be confusing "people who send email" with > MTAs which process it. The return-path is intended to be the "best" > address for notifications. As things currently stand, MTAs are in no > position to second-guess whether some other address would be "better". No, I think that's what SRS was for, though. > -- > John Leslie > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 09:31:25 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479EC3A6A51; Fri, 23 Jan 2009 09:31:25 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B003A6A21 for ; Fri, 23 Jan 2009 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.563 X-Spam-Level: X-Spam-Status: No, score=-7.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 C5Kjrt5wQlZT for ; Fri, 23 Jan 2009 09:31:23 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 499603A6A51 for ; Fri, 23 Jan 2009 09:31:23 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0NHV3n06209 for ; Fri, 23 Jan 2009 17:31:03 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 12:31:03 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 23 Jan 2009 12:31:02 -0500 Message-ID: <4979FED6.1040404@nortel.com> Date: Fri, 23 Jan 2009 12:31:02 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090113134926.GA22598@gsp.org> <496CBFB8.1000503@tana.it> <20090113175350.GA24889@gsp.org> <1231870673.3240.8.camel@bravo.isode.net> <20090113203638.GA11831@gsp.org> <1231886282.3304.6.camel@bravo.isode.net> <20090114013801.GA18217@gsp.org> <496E1CF7.3080701@tana.it> <20090115154525.GB13843@gsp.org> <1232038610.32316.324.camel@tardis.isode.net> <20090123135659.GA8168@gsp.org> In-Reply-To: <20090123135659.GA8168@gsp.org> X-OriginalArrivalTime: 23 Jan 2009 17:31:03.0514 (UTC) FILETIME=[5D8653A0:01C97D80] Subject: Re: [Asrg] Meta channel, not bounces X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Rich Kulawiec wrote: > This is one of the many reasons why I largely eschew content-based filters, Many of us in the biz remember when AOL hit the media for trying to block porn spam by filtering on the word "breast". One of the highest FP rates I've _ever_ seen was on the four letter word starting with "f" (no, it wasn't my idea, but the FP rate gave me the argument to kill the rule). > and why I try to use them only after all other methods have been tried: > it's very hard to get them right. And it's also one of the reasons why > I think anyone who's using them should be prepared not just for FNs, > but for FPs -- which I believe Chris's operation is, based on what they > return in reject messages. Serious spam filtering environments have to put a lot more effort into dealing with FPs than FNs. FNs are forgivable. Unrecoverable FPs are not. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 11:02:39 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCCA3A6AC5; Fri, 23 Jan 2009 11:02:39 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC2F3A6A6D for ; Fri, 23 Jan 2009 11:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 b0g-FTKBm-gn for ; Fri, 23 Jan 2009 11:02:31 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 10FF63A6814 for ; Fri, 23 Jan 2009 11:02:30 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 23 Jan 2009 20:02:10 +0100 id 00000000005DC037.00000000497A1432.0000250E Message-ID: <497A1432.1030800@tana.it> Date: Fri, 23 Jan 2009 20:02:10 +0100 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> <20090123141319.GA52653@verdi> In-Reply-To: <20090123141319.GA52653@verdi> Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Leslie wrote: > Ian Eiloart wrote: >> --On 21 January 2009 12:27:56 -0500 John Leslie wrote: >> >>> However, there are a limited number of ways that forwarding might be >>> shown in the trace headers, so it should be practical to determine that >>> a forwarding is documented (though possibly forged). >>> >>> We then have a quite different situation from what raw SPF processing >>> would indicate. Thus I claim the rules deserve to be relaxed (without >>> going into detail how). > > The point I was attempting to make is that SPF records _can_ accurately > reflect sender policy, while SPF processing will incorrectly indicate a > violation of it. That's quite correct. I say "quite" because SPF provides for various levels of results, without mandating any particular behavior. However, the quickest behavior, reject on fail, does not allow to examine the message headers. > As things stand in SPF, folks end up publishing less-correct records > in an attempt to tune to a more satisfactory result. Yup. With rules like "?ip4:80.0.0.0/5" one can succinctly "neutralize" many IPv4 addresses, possibly excluding forwarders located elsewhere. For geographically characterized sites, half of the world would still be much less than all of it. > [...] > But please understand that strict SPF processing hasn't yet stopped > forwarding MTAs from documenting the forwarding according to spec > rather than rewriting addresses the way you want them to. Do you really > believe this will change? I hope it will. Headers that document forwarding are unmanageable. Some include full explanations in the body, but most don't. Wild forwarding breaks more than SPF: it breaks most countries' privacy laws by not letting a recipient know where an alias was expanded from. More mumblings at http://fixforwarding.org/wiki/privacy_laws _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 11:31:30 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC01B3A6878; Fri, 23 Jan 2009 11:31:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31483A67B4 for ; Fri, 23 Jan 2009 11:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 Xpw2zUA4uJXz for ; Fri, 23 Jan 2009 11:31:27 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 8DE013A6878 for ; Fri, 23 Jan 2009 11:31:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id F230164F82DE for ; Sat, 24 Jan 2009 07:31:21 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry6539en0PWk for ; Sat, 24 Jan 2009 07:31:20 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4482264F825C for ; Sat, 24 Jan 2009 07:31:20 +1200 (FJT) Date: Sat, 24 Jan 2009 07:31:20 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <6.2.5.6.2.20090122233519.02ebdf20@resistor.net> MIME-Version: 1.0 X-Originating-IP: [113.20.67.234] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org This seems an interesting thread and an interesting way of fighting spam. Can we get more info and stats on the correlation of spam and fingerprinting of the OS? We are a research group after all. Now what happens to all the small businesses that use MS-Exchange to send email? ----- Original Message ----- From: "SM" To: "Anti-Spam Research Group - IRTF" Sent: Friday, 23 January, 2009 8:00:24 PM (GMT+1200) Auto-Detected Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] At 20:54 22-01-2009, Rich Kulawiec wrote: >But don't take my word for it: run the experiment yourself. Turn on >passive OS fingerprinting in your perimeter devices (or on your servers) >and correlate that data with: > > - spam attempts > - ssh attempts > - ftp attempts > - pop/imap attempts > - port scans > - crafted packet attacks > - http-based exploit attempts > - DoS attacks > - etc. > >After a year or two, I think you'll find is what I've found after running >this experiment in multiple environments of different sizes, characteristics, >purposes, etc.: the abuse problem is largely (in some cases, almost >exclusively) a Microsoft Windows problem. [1] And it's clear that >the correlation far exceeds the population percentage, either as-observed >or as-guesstimated. (Some of my sensors have gone for months without >detecting a non-Windows-originated ssh attempt, for instance.) I'm commenting on the spam attempts only as I've been running an experiment on that since several years. In general, most of the SMTP sessions from Windows hosts are spam attempts. Passive OS Fingerprinting in combination with other heuristics can be quite effective in detecting spam attempts. >As a result, it's long since become part of my anti-spam and overall >security strategy to consider anything originating on a Windows system >as "suspect", at best, and to subject such traffic to (a) rate-limiting >(b) refusal (c) higher scrutiny and/or (d) modified services. I highly >recommend this approach for anybody with the facilities to use it: >the results are striking. Such a strategy doesn't work well in some environments where there is a higher proportion of valid messages from Windows-based mail servers. Some people might need an exception list if they implement the above methods. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 11:55:22 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5E13A6A7B; Fri, 23 Jan 2009 11:55:22 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A493A6A7B for ; Fri, 23 Jan 2009 11:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.995 X-Spam-Level: X-Spam-Status: No, score=-7.995 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 SlaiCKLJD1C8 for ; Fri, 23 Jan 2009 11:55:20 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id B85473A6878 for ; Fri, 23 Jan 2009 11:55:19 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA13439; Fri, 23 Jan 2009 14:54:44 -0500 (EST) From: der Mouse Message-Id: <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 23 Jan 2009 14:49:12 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Now what happens to all the small businesses that use MS-Exchange to > send email? The same thing that happens if they unwittingly pick someone on ROSKO for a mailout house: they get a sharp lesson in why due diligence is not only good but damn near essential, and how a non-spammer looking enough like a spammer will get treated like a spammer. I see no more need to support direct-to-MX-from-Exchange (or any other package that evidences Exchange's level of imperviousness to mail-handling clue) than to support an unwitting-and-otherwise-legitimate client of a spam-for-hire house. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 12:20:17 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B5C3A6B1D; Fri, 23 Jan 2009 12:20:17 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86F13A6B1F for ; Fri, 23 Jan 2009 12:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001] 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 XkCrqFKBQnXs for ; Fri, 23 Jan 2009 12:20:09 -0800 (PST) Received: from secure.jdmc.org (secure.jdmc.org [164.58.70.160]) by core3.amsl.com (Postfix) with ESMTP id 9990F3A6B1D for ; Fri, 23 Jan 2009 12:20:09 -0800 (PST) Received: from mail (mithril@localhost) by secure.jdmc.org with ESMTP id n0NKJqE23464 for ; Fri, 23 Jan 2009 14:19:52 -0600 (CST) (envelope-from jjohnson@jdmc.org) Received: from mail.jdmc.org (mail [164.58.70.150]) by secure.jdmc.org ([164.58.70.161]); 23 Jan 2009 14:19:52 -0600 (CST) Received: (qmail 3281 invoked by uid 509); 23 Jan 2009 14:19:52 -0600 Received: from 164.58.70.130 by mail.jdmc.org (envelope-from , uid 508) with qmail-scanner-1.24-st-qms (clamdscan: 0.88.2/1480. spamassassin: 3.1.1. perlscan: 1.24-st-qms. Clear:RC:0(164.58.70.130):SA:0(-4.2/5.0):. Processed in 12.641479 secs); 23 Jan 2009 20:19:52 -0000 Received: from gatore.jdmc.org (HELO ?192.168.3.212?) (jjohnson@jdmc.org@164.58.70.130) by mail.jdmc.org with SMTP; 23 Jan 2009 14:19:39 -0600 X-Enigmail-Version: 0.95.7 References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> User-Agent: Thunderbird 2.0.0.19 (X11/20081209) X-Antivirus-MYDOMAIN: 1.24-st-qms (Clear:RC:0(164.58.70.130):SA:0(-4.2/5.0):. Processed in 12.641479 secs Process 3218) X-Antivirus-MYDOMAIN-Mail-From: jjohnson@jdmc.org via mail.jdmc.org From: "John Johnson" To: "Anti-Spam Research Group - IRTF" Date: Fri, 23 Jan 2009 14:19:34 -0600 Message-ID: <497A2656.3070202@jdmc.org> In-Reply-To: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > This seems an interesting thread and an interesting way of fighting spam. > > Can we get more info and stats on the correlation of spam and fingerprinting of the OS? > > We are a research group after all. > > Now what happens to all the small businesses that use MS-Exchange to send email? > Please take a look at the following paper - it appears it would impact MS-Exchange less than you would imagine. http://www.sans.org/reading_room/whitepapers/email/zombie_profiling_with_smtp_greylisting_33008 for a working sendmail specific milter example, I found this interesting: http://www.elandsys.com/scam/ _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 12:23:03 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F40D28C241; Fri, 23 Jan 2009 12:23:03 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482F028C24A for ; Fri, 23 Jan 2009 12:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BdJU6+-Lrsvm for ; Fri, 23 Jan 2009 12:23:01 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 44FFD28C241 for ; Fri, 23 Jan 2009 12:23:01 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0NKMf709568 for ; Fri, 23 Jan 2009 20:22:41 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 15:22:11 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 23 Jan 2009 15:22:11 -0500 Message-ID: <497A26F2.9030009@nortel.com> Date: Fri, 23 Jan 2009 15:22:10 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> X-OriginalArrivalTime: 23 Jan 2009 20:22:11.0498 (UTC) FILETIME=[45B858A0:01C97D98] Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org der Mouse wrote: >> Now what happens to all the small businesses that use MS-Exchange to >> send email? > > The same thing that happens if they unwittingly pick someone on ROSKO > for a mailout house: they get a sharp lesson in why due diligence is > not only good but damn near essential, and how a non-spammer looking > enough like a spammer will get treated like a spammer. > > I see no more need to support direct-to-MX-from-Exchange (or any other > package that evidences Exchange's level of imperviousness to > mail-handling clue) than to support an > unwitting-and-otherwise-legitimate client of a spam-for-hire house. Direct-to-MX-from-Exchange? That's what it's _supposed_ to do. It's the MTA. There are some annoyances in Exchange, but true infections on Exchange servers are extremely rare. ITYM: direct-to-MX-from-Outlook. AFAIK Outlook _can't_ do direct-to-MX, because it doesn't have the MX lookup code for it. In fact, if you know how to detect what _would_ be direct-to-MX from Outlook, it's a good filtering rule. [High volume/long term experience: Moderate to high return at times, zero FPs. Tho, obviously, you shouldn't apply this on your outbound submission servers!!!!!] This probably applies to most other MUAs - they can't MX no matter what. Our experience indicates that MTA servers, of _any_ flavour or O/S, are seldom infected with anything viral or wormlike. This is largely due to the fact that "ordinary users" are virtually never reading or browsing on the server, and the vast majority of current worm/viral compromises require one or the other. [Tho, in the face of a network spreader like SQLSlammer, all bets are off.] Exchange may be worse than some other O/S/MTA combinations, but not by a lot. It's subject to sloppy admin/config, but so is everything else. The real issue with "compromised" Exchange (or any other MTA) is more things like poorly chosen passwords, not worm/viral. Not exclusive to windows by any stretch. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 12:55:22 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA3028C24F; Fri, 23 Jan 2009 12:55:22 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B94028C24F for ; Fri, 23 Jan 2009 12:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 5xaEFwlqslJp for ; Fri, 23 Jan 2009 12:55:19 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 4EC5028C243 for ; Fri, 23 Jan 2009 12:55:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 1682F64F82DE for ; Sat, 24 Jan 2009 08:55:13 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIfrgPF9bnWn for ; Sat, 24 Jan 2009 08:55:12 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 2A21864F825C for ; Sat, 24 Jan 2009 08:55:12 +1200 (FJT) Date: Sat, 24 Jan 2009 08:55:12 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <8147302.391232744014604.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 X-Originating-IP: [113.20.67.234] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org I cannot get to the first link for the second link, this is grey listing, so nothing new here To be noted I see now that infected machines will send several times the same message to the same email. So I think the spammers are now fighting greylisting, and greylisting is becoming less and less effective. I kind of like the idea of OS fingerprinting, anyone has a working filter? ----- Original Message ----- From: "John Johnson" To: "Anti-Spam Research Group - IRTF" Sent: Saturday, 24 January, 2009 8:19:34 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] Franck Martin wrote: > This seems an interesting thread and an interesting way of fighting spam. > > Can we get more info and stats on the correlation of spam and fingerprinting of the OS? > > We are a research group after all. > > Now what happens to all the small businesses that use MS-Exchange to send email? > Please take a look at the following paper - it appears it would impact MS-Exchange less than you would imagine. http://www.sans.org/reading_room/whitepapers/email/zombie_profiling_with_smtp_greylisting_33008 for a working sendmail specific milter example, I found this interesting: http://www.elandsys.com/scam/ _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 12:59:58 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2203A6B19; Fri, 23 Jan 2009 12:59:58 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D933A6B19 for ; Fri, 23 Jan 2009 12:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.278 X-Spam-Level: X-Spam-Status: No, score=-9.278 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 Ah+G0OIurTzW for ; Fri, 23 Jan 2009 12:59:52 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 07CF53A6B11 for ; Fri, 23 Jan 2009 12:59:51 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA13766; Fri, 23 Jan 2009 15:59:34 -0500 (EST) From: der Mouse Message-Id: <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 23 Jan 2009 15:46:11 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <497A26F2.9030009@nortel.com> References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> <497A26F2.9030009@nortel.com> Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >>> Now what happens to all the small businesses that use MS-Exchange >>> to send email? >> [T]hey get a sharp lesson in [...] how a non-spammer looking enough >> like a spammer will get treated like a spammer. >> I see no more need to support direct-to-MX-from-Exchange [...] > Direct-to-MX-from-Exchange? That's what it's _supposed_ to do. It's > the MTA. Right. But it's an unusually badly behaved one. Exchange is good groupware with a bad MTA duct-taped onto the side. > ITYM: direct-to-MX-from-Outlook. You think wrong. Look enough like a spammer and you can expect to be treated like a spammer, even if you're not. Someone using Exchange as a world-facing outgoing MTA may not be a spammer, but will be running Windows on what to the rest of the world is an SMTP client. This looks like a spammer from the perspective of this thread (which was about OS fingerprinting of SMTP client hosts). You wrote > There are some annoyances in Exchange, but true infections on > Exchange servers are extremely rare. which, even if true, is pretty much irrelevant without some way to tell whether that Windows machine connecting to you is an Exchange outgoing MTA or a direct-to-MX zombie. Some would say that this makes it "impossible" to use this technique. The stance behind my note is that Exchange is a bad enough MTA that the pressure this technique would exert against it would be of net positive value. And if there were some way to identify Exchange, all its getting a free pass would mean would be that bitnet herders would mass-install Exchange on their zombies and send through it - or, perhaps even more likely, just forge whatever Exchange indicator(s) get(s) widely used. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 13:08:14 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF023A6873; Fri, 23 Jan 2009 13:08:14 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB293A6359 for ; Fri, 23 Jan 2009 13:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tSy6qs3zXuq2 for ; Fri, 23 Jan 2009 13:08:12 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 0E8CB3A685F for ; Fri, 23 Jan 2009 13:08:12 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id CF4E3808A9 for ; Fri, 23 Jan 2009 13:07:50 -0800 (PST) Message-Id: From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 13:07:54 -0800 References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> <497A26F2.9030009@nortel.com> <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 23, 2009, at 12:46 PM, der Mouse wrote: >>>> Now what happens to all the small businesses that use MS-Exchange >>>> to send email? >>> [T]hey get a sharp lesson in [...] how a non-spammer looking enough >>> like a spammer will get treated like a spammer. > >>> I see no more need to support direct-to-MX-from-Exchange [...] > >> Direct-to-MX-from-Exchange? That's what it's _supposed_ to do. It's >> the MTA. > > Right. But it's an unusually badly behaved one. Exchange is good > groupware with a bad MTA duct-taped onto the side. > >> ITYM: direct-to-MX-from-Outlook. > > You think wrong. Look enough like a spammer and you can expect to be > treated like a spammer, even if you're not. Someone using Exchange as > a world-facing outgoing MTA may not be a spammer, but will be running > Windows on what to the rest of the world is an SMTP client. This > looks > like a spammer from the perspective of this thread (which was about OS > fingerprinting of SMTP client hosts). You wrote > >> There are some annoyances in Exchange, but true infections on >> Exchange servers are extremely rare. > > which, even if true, is pretty much irrelevant without some way to > tell > whether that Windows machine connecting to you is an Exchange outgoing > MTA or a direct-to-MX zombie. Which is usually easy enough to tell by other approaches. I see some legitimate email from Windows systems (Exchange, primarily, but also a few others). The majority of the spam I see in my inbox (which is filtered, but not by anything that takes source address into account) comes, AFAICT, from Linux boxes or email appliances (primarily linux based). Compromised PHP boxes and spam coming from sources that emit a mixture of spam and legitimate email dominate the traffic that makes it to my inbox, AFAICT from a quick look. Which doesn't tell me much, but does suggest that A) people blaming Windows for all the net's ills may not be basing it on representative traffic and B) research is likely useful, speculation probably isn't. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 13:15:41 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A492C3A691A; Fri, 23 Jan 2009 13:15:41 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE67C3A691A for ; Fri, 23 Jan 2009 13:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 0dR+dklK3JgE for ; Fri, 23 Jan 2009 13:15:39 -0800 (PST) Received: from secure.jdmc.org (secure.jdmc.org [164.58.70.160]) by core3.amsl.com (Postfix) with ESMTP id 0E04E3A6873 for ; Fri, 23 Jan 2009 13:15:38 -0800 (PST) Received: from mail (mithril@localhost) by secure.jdmc.org with ESMTP id n0NLFMC27519 for ; Fri, 23 Jan 2009 15:15:22 -0600 (CST) (envelope-from jjohnson@jdmc.org) Received: from mail.jdmc.org (mail [164.58.70.150]) by secure.jdmc.org ([164.58.70.161]); 23 Jan 2009 15:15:22 -0600 (CST) Received: (qmail 10129 invoked by uid 509); 23 Jan 2009 15:15:21 -0600 Received: from 164.58.70.130 by mail.jdmc.org (envelope-from , uid 508) with qmail-scanner-1.24-st-qms (clamdscan: 0.88.2/1480. spamassassin: 3.1.1. perlscan: 1.24-st-qms. Clear:RC:0(164.58.70.130):SA:0(-4.3/5.0):. Processed in 3.518275 secs); 23 Jan 2009 21:15:21 -0000 Received: from gatore.jdmc.org (HELO ?192.168.3.212?) (jjohnson@jdmc.org@164.58.70.130) by mail.jdmc.org with SMTP; 23 Jan 2009 15:15:18 -0600 X-Enigmail-Version: 0.95.7 References: <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> User-Agent: Thunderbird 2.0.0.19 (X11/20081209) X-Antivirus-MYDOMAIN: 1.24-st-qms (Clear:RC:0(164.58.70.130):SA:0(-4.3/5.0):. Processed in 3.518275 secs Process 10117) X-Antivirus-MYDOMAIN-Mail-From: jjohnson@jdmc.org via mail.jdmc.org From: "John Johnson" To: "Anti-Spam Research Group - IRTF" Date: Fri, 23 Jan 2009 15:15:12 -0600 Message-ID: <497A3360.4070102@jdmc.org> In-Reply-To: <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > I cannot get to the first link > My apologies, sent attachment off-list. > for the second link, this is grey listing, so nothing new here > > To be noted I see now that infected machines will send several times the same message to the same email. > That's one of the points in the paper - an infected bot will attempt to send From: many different addresses without retrying the initial To: target. It'll happy provide many domains that it's from. > So I think the spammers are now fighting greylisting, and greylisting is becoming less and less effective. > It would appear that OS fingerprinting WITH greylisting is an effective tool to research. It may be one of those short term bandaids, but worthy of looking at. > I kind of like the idea of OS fingerprinting, anyone has a working filter? > _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 13:42:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AF13A680D; Fri, 23 Jan 2009 13:42:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2774A3A680D for ; Fri, 23 Jan 2009 13:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eVAO0gPFss-Y for ; Fri, 23 Jan 2009 13:41:57 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 255843A693D for ; Fri, 23 Jan 2009 13:41:57 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0NLfb718733 for ; Fri, 23 Jan 2009 21:41:37 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 16:41:30 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 23 Jan 2009 16:41:30 -0500 Message-ID: <497A3989.1070504@nortel.com> Date: Fri, 23 Jan 2009 16:41:29 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> <497A26F2.9030009@nortel.com> <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> X-OriginalArrivalTime: 23 Jan 2009 21:41:30.0543 (UTC) FILETIME=[5A54FBF0:01C97DA3] Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org der Mouse wrote: >>>> Now what happens to all the small businesses that use MS-Exchange >>>> to send email? >>> [T]hey get a sharp lesson in [...] how a non-spammer looking enough >>> like a spammer will get treated like a spammer. > >>> I see no more need to support direct-to-MX-from-Exchange [...] > >> Direct-to-MX-from-Exchange? That's what it's _supposed_ to do. It's >> the MTA. > > Right. But it's an unusually badly behaved one. Exchange is good > groupware with a bad MTA duct-taped onto the side. That was true of archaic Exchange implementations. Eg: the infamous "Exchange 5" (aka IIS 5). As was Sun Sendmail SMI 4.1. But, reasonably recent Exchange is just fine in SMTP. A consumer level site may see a different mix of MTAs than we do, but it's been our experience that Exchange as an outbound is generally not a problem, and we see lots of perfectly legit email from Exchange servers. Many small-to-medium businesses lack the expertise to run something else. I wouldn't dream of blocking an email based on a p0f signature of "Windows" (tho, maybe Win95, 98 ;-) I'd score it. > And if there were some way to identify Exchange, all its getting a free > pass would mean would be that bitnet herders would mass-install > Exchange on their zombies and send through it - or, perhaps even more > likely, just forge whatever Exchange indicator(s) get(s) widely used. If there was some way to identify windows via passive O/S fingerprinting, all that giving anything else a free[r] pass would mean that the botnet herders would get something to fake that something else. Hint: it's already in BOTs. And that's _all_ I'm going to say about that. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Fri Jan 23 16:17:24 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A4828C275; Fri, 23 Jan 2009 16:17:24 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FC028C22B for ; Fri, 23 Jan 2009 16:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] 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 NXIy5KDaDcXi for ; Fri, 23 Jan 2009 16:17:22 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 68BC528C275 for ; Fri, 23 Jan 2009 16:17:22 -0800 (PST) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0O0GtrT016738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2009 16:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1232756224; x=1232842624; bh=uCraIQ/wz1NJuV4p8clSGRu+G7VZ+ikX3+oGwYQUCi0=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0xnmnexrgix3315ThSvaQMp0an0fUuq2/0SnoXOsDNa+hzl/EkjgoLNlWN7V0hPSC HCLYZ6WJupL/sAPZI+hITGuK7lfy7pMFV2ZZX9yoG+0gvAvqMeIvxLWirGCseSNxGw NYZZyG9hyAv7+kGkGOv9Hpgg4HGYyhr2J1ONOSE4= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ARkM6BeQ0Wfeid13nZ/XFaLABFRZikLnBgCSNGLHDqJelHkbba08W7FR+ZQfXe2gN 9DzOMy+Bt6z46AMrZ6t0p+6/pV5WGPr3oEMqsfkcfLP22RhSXo31ciqEmrTvOxQkC7b p9LmOt9/47X1OHO238TxZxaGyyXOEr47I/IlWY0= Message-Id: <6.2.5.6.2.20090123144212.02fe4298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Jan 2009 16:01:39 -0800 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <4883162.311232739061145.JavaMail.franck@franck-martins-mac book-pro.local> References: <6.2.5.6.2.20090122233519.02ebdf20@resistor.net> <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> Mime-Version: 1.0 Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org At 11:31 23-01-2009, Franck Martin wrote: >Can we get more info and stats on the correlation of spam and >fingerprinting of the OS? The following figures are not representative as the mail traffic is biased because of the user-base. About 60% of identified SMTP sessions are from Windows hosts and 99% of the messages they sent were identified as spam. >Now what happens to all the small businesses that use MS-Exchange to >send email? Either you discriminate against them and lose business or else you combine your fingerprinting with other heuristics to reduce its effect. Some MS-Exchange hosts are behind non-Windows devices and the OS won't be detected as Windows. Regards, -sm _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 04:09:28 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABFF3A6AA3; Sat, 24 Jan 2009 04:09:28 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14A628C0F4 for ; Sat, 24 Jan 2009 04:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zasE3QsHhFU8 for ; Sat, 24 Jan 2009 04:09:27 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id E08F33A67A5 for ; Sat, 24 Jan 2009 04:09:26 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0OC95Q2027784 for ; Sat, 24 Jan 2009 07:09:09 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0OBxTbE009228 for ; Sat, 24 Jan 2009 06:59:49 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0OC8e8h002774 for ; Sat, 24 Jan 2009 07:08:40 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0OC8e3Y002773 for asrg@irtf.org; Sat, 24 Jan 2009 07:08:40 -0500 Date: Sat, 24 Jan 2009 07:08:40 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090124120840.GA2369@gsp.org> References: <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <200901231954.OAA13439@Sparkle.Rodents-Montreal.ORG> <497A26F2.9030009@nortel.com> <200901232059.PAA13766@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, Jan 23, 2009 at 01:07:54PM -0800, Steve Atkins wrote: > The majority of the spam I see in my inbox (which is filtered, but not > by anything that takes source address into account) comes, AFAICT, > from Linux boxes or email appliances (primarily linux based). You know what? I see pretty much the same thing in my mailbox. But that's after: - network perimeter filtering - system firewall filtering - numerous DNS existence and consistency checks - numerous SMTP protocol checks - numerous network allocation blocks - numerous (okay, huge) domain blocks - numerous subdomain blocks - numerous other blocks - DNSBls - RHSBLs - etc. What finally makes it through doesn't look anything like what's trying to make it through. It's a fraction (roughly 1-2%) of the presented SMTP traffic and very much unrepresentative. I can say much the same thing about HTTP exploit attempts and SSH brute-force attempts and all the other kinds of real/attempted abuse: what's observed at the server level doesn't look much like what's really incoming. So the best place to measure this isn't your mailbox; it's on the outer perimeter of your network -- at the packet level. Or, to refine that slightly, on the outer perimeter of a network that nobody knows you're associated with, since at least some abusers do seem to make a point of at least trying to enumerate the ones where their adversaries are watching. > Which doesn't tell me much, but does suggest that A) people blaming > Windows for all the net's ills may not be basing it on representative > traffic and B) research is likely useful, speculation probably isn't. I didn't blame Windows for "all the net's ills". I said that the abuse problem is mostly a Microsoft Windows problem. And, clearly, "abuse" is only one of the many things wrong with the Internet. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 04:34:46 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEED028C2BC; Sat, 24 Jan 2009 04:34:46 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401FA28C28B for ; Sat, 24 Jan 2009 04:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vdsyOTUgR7nV for ; Sat, 24 Jan 2009 04:34:43 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 251C228C115 for ; Sat, 24 Jan 2009 04:34:43 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0OCYON7026107 for ; Sat, 24 Jan 2009 07:34:25 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0OCOmiO015042 for ; Sat, 24 Jan 2009 07:25:08 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0OCXxat007055 for ; Sat, 24 Jan 2009 07:33:59 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0OCXx9S007054 for asrg@irtf.org; Sat, 24 Jan 2009 07:33:59 -0500 Date: Sat, 24 Jan 2009 07:33:59 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090124123359.GB2369@gsp.org> References: <6.2.5.6.2.20090122233519.02ebdf20@resistor.net> <4883162.311232739061145.JavaMail.franck@franck-martins-macbook-pro.local> <6.2.5.6.2.20090123144212.02fe4298@resistor.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20090123144212.02fe4298@resistor.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Fri, Jan 23, 2009 at 04:01:39PM -0800, SM wrote: >> Now what happens to all the small businesses that use MS-Exchange to >> send email? > > Either you discriminate against them and lose business or else you > combine your fingerprinting with other heuristics to reduce its effect. Exactly what I've done in some cases -- after observing something about patterns of inbound mail on many different mail servers: in almost all cases, the number of sources for mail (excluded spam-only sources) is surprisingly small. (Spare me the counterexamples, I already know about them.) If that number is weighted by message count, then the resulting graph is pretty lopsided. This means that it's actually reasonable to consider enumerating the primary sources of mail and treating them differently. In one setup that I built, logs were analyzed to determine the top senders, who, combined, accounted for 92% of all mail the site received. Those top sending networks were then presented with a DNS view that specified a different MX order from the rest of the world, with the top MX's configured with a firewall that only permits connections from those senders. They've also got greylisting turned off, and they don't impose OS-specific rate limiting. What happens if someone else grabs this DNS view and tries to hit the "private" MX's? They can't: firewall. What happens if one of those known sending sites starts using a different network allocation? Then they get the same DNS view as the rest of the world, which specifies the "public" MXs, for lack of a better term, and their mail still gets through: just not as quickly and with more scrutiny. But: since all the logs are post-processed every day, and part of that post-processing includes looking for exactly this situation, when it happens the DNS view and firewall config will be updated to track the change, and soon thereafter they'll be back to delivering to the "private" MX's. (What happens if they have their old DNS view but are sending from a new network? They step through the MX list until they find the "public" ones.) This kind of split-view essentially provides two tiers of mail service: the "we know who you are" tier, and the "you look like a stranger" tier. It requires detailed knowledge of mail traffic patterns, but IMHO anyone running a mail server should already have that. One of the nice things about it is that it allows resources to be allocated where they're most needed -- on the servers that will handle most of the real mail traffic, as opposed to fending off abuse. This isn't a new idea; I think possibly the only thing I added to it was the use of passive OS fingerprinting on the "public" MX's, and in practice, that's turned out not to be particularly needed because of all the other blocking enabled on those. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 04:38:52 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA31F28C2C7; Sat, 24 Jan 2009 04:38:52 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6287228C2C7 for ; Sat, 24 Jan 2009 04:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1xT4fKrJVIJz for ; Sat, 24 Jan 2009 04:38:51 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 0092428C28B for ; Sat, 24 Jan 2009 04:38:50 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0OCcWAr019229 for ; Sat, 24 Jan 2009 07:38:33 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0OCSuTC012953 for ; Sat, 24 Jan 2009 07:29:16 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0OCc7Ar007596 for ; Sat, 24 Jan 2009 07:38:07 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0OCc7eC007595 for asrg@irtf.org; Sat, 24 Jan 2009 07:38:07 -0500 Date: Sat, 24 Jan 2009 07:38:07 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090124123807.GC2369@gsp.org> References: <8147302.391232744014604.JavaMail.franck@franck-martins-macbook-pro.local> <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sat, Jan 24, 2009 at 08:55:12AM +1200, Franck Martin wrote: > To be noted I see now that infected machines will send several times > the same message to the same email. So I think the spammers are now > fighting greylisting, and greylisting is becoming less and less effective. Somewhat, but not entirely. One thing that greylisting still does is buy time for various DNSBLs and RHSBLs to note abuse and create an entry. Granted, this is a roll of the dice, but if the greylisting period is sufficiently long (which is probably appropriate for some classes of hosts) then it sometimes works. (And when it doesn't? It may result in a FN.) > I kind of like the idea of OS fingerprinting, anyone has a working filter? The one I provided a link to: http://use.perl.org/~merlyn/journal/17094 is an example. You'll need a packet filter (like pf) that has the capability in order to use it, or something similar. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 04:41:29 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBB03A6893; Sat, 24 Jan 2009 04:41:29 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163D73A6893 for ; Sat, 24 Jan 2009 04:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 fcNjiQZ6N1sd for ; Sat, 24 Jan 2009 04:41:27 -0800 (PST) Received: from twinlark.arctic.org (twinlark.arctic.org [208.69.40.136]) by core3.amsl.com (Postfix) with ESMTP id EC7163A67B6 for ; Sat, 24 Jan 2009 04:41:26 -0800 (PST) Received: (qmail 12718 invoked from network); 21 Jan 2009 20:41:09 -0000 Received: from unknown (HELO rpco-jdmacbook.rpcorp.local) (AUTH jdfalk) (38.109.196.53) by 208.69.40.137 with ESMTPSA (AES256-SHA); 21 Jan 2009 20:41:09 -0000 Message-ID: <4977885F.9020601@cybernothing.org> Date: Wed, 21 Jan 2009 13:41:03 -0700 From: "J.D. Falk" User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <15104592.341232564464306.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <15104592.341232564464306.JavaMail.franck@franck-martins-macbook-pro.local> Subject: Re: [Asrg] DK & DKIM (was Re: SPF, was where the message) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Franck Martin wrote: > I never said they were rejecting unsigned messages and the context of the thread was mass mailing. Okay, I guess I didn't understand what you meant by "MUST" in this context. Could you explain further? > On 20/01/2009 19:47, "Franck Martin" wrote: > >> Same, you MUST implement domainkeys because yahoo likes it. -- J.D. Falk Return Path Inc http://www.returnpath.net/ _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 04:52:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664093A6AB6; Sat, 24 Jan 2009 04:52:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E863A6A1A for ; Sat, 24 Jan 2009 04:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 dVOOhBkvnrja for ; Sat, 24 Jan 2009 04:52:45 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 923E53A6879 for ; Sat, 24 Jan 2009 04:52:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 1FDCB64F82EF for ; Sun, 25 Jan 2009 00:52:40 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVwo+S2ZOnia for ; Sun, 25 Jan 2009 00:52:34 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id B2D9164F82ED for ; Sun, 25 Jan 2009 00:52:34 +1200 (FJT) Date: Sun, 25 Jan 2009 00:52:34 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <5714776.181232801534326.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <4977885F.9020601@cybernothing.org> MIME-Version: 1.0 X-Originating-IP: [113.20.67.234] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] DK & DKIM (was Re: SPF, was where the message) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Having domainkeys when you send to yahoo, allows them to assess it is coming from you, therefore bypass a few filters and giving you a higher confidence (or non confidence) level based on previous traffic. You needed domainkeys if you wanted to have a feedbackloop with them to. It seems not true anymore, they re-enabled the feedbackloop program a few days ago and you need either DK or DKIM. ----- Original Message ----- From: "J.D. Falk" To: "Anti-Spam Research Group - IRTF" Sent: Thursday, 22 January, 2009 8:41:03 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] DK & DKIM (was Re: SPF, was where the message) Franck Martin wrote: > I never said they were rejecting unsigned messages and the context of the thread was mass mailing. Okay, I guess I didn't understand what you meant by "MUST" in this context. Could you explain further? > On 20/01/2009 19:47, "Franck Martin" wrote: > >> Same, you MUST implement domainkeys because yahoo likes it. -- J.D. Falk Return Path Inc http://www.returnpath.net/ _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 09:41:54 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A9C28C138; Sat, 24 Jan 2009 09:41:54 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2042428C138 for ; Sat, 24 Jan 2009 09:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.193 X-Spam-Level: X-Spam-Status: No, score=-14.193 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 few8B5k-i+5X for ; Sat, 24 Jan 2009 09:41:52 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 2A87E3A6B8F for ; Sat, 24 Jan 2009 09:41:52 -0800 (PST) Received: (qmail 51029 invoked from network); 24 Jan 2009 17:41:36 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Jan 2009 17:41:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=rcY5juvs1HO7sjAHVyoLjekPPDXogG6xorAMVKF4isg=; b=rYIKP1F67pJnryxZ8TSp84K9j9iqWoMJnFVwsvcWT/lMmMGgZ/il1vsX/EPrdX2dDLxZ94lKTz2HNlAfyuhiqfXUX99h/il81cPRWWOjbHUT/BEY7dHkUjV2TZiEiOvtiZzX0aC83aZjt5qJxyzdGPmu65arETibPopH5RcPT2I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=rcY5juvs1HO7sjAHVyoLjekPPDXogG6xorAMVKF4isg=; b=pV++treRmNcePZVXR3/zGj0M75uLElDw76+KOF7PKVqgvUim9UW3ZQm3OE2xv7/TigB1dPD+ibnIjqA2/JpCbrJ3mFzziiocutnLF+wpWvHkMRe5z+t0NUMlBOLAwDJEk6Xp/FPKh4eYHDTdXx2ub7QUqHhCWDq9a38iGojmYWI= Date: 24 Jan 2009 17:41:32 -0000 Message-ID: <20090124174132.80812.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4055894.411232744096736.JavaMail.franck@franck-martins-macbook-pro.local> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] greylisting, was Software bashing X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org >So I think the spammers are now fighting greylisting, and greylisting >is becoming less and less effective. I looked at my greylist logs for the past month. It shows 4911 previously unseen IPs that retried, and 51,348 that didn't. I'd say that a technique that turns away 91% of the mail it touches is still pretty effective. The month before that the numbers were 4707 and 41,487, for about 90%, so in the short term at least, it's pretty consistent. I have data back to May, could crunch it if people wanted. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 13:13:34 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE2928C10E; Sat, 24 Jan 2009 13:13:34 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8D428C10E for ; Sat, 24 Jan 2009 13:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 af7qANNr-ufW for ; Sat, 24 Jan 2009 13:13:32 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 4B56128C0FE for ; Sat, 24 Jan 2009 13:13:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 4288364F82F5 for ; Sun, 25 Jan 2009 09:13:19 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sJ+HOXa8uOU for ; Sun, 25 Jan 2009 09:13:15 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 591E164F82F3 for ; Sun, 25 Jan 2009 09:13:15 +1200 (FJT) Date: Sun, 25 Jan 2009 09:13:15 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <12894329.231232831577892.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <20090124174132.80812.qmail@simone.iecc.com> MIME-Version: 1.0 X-Originating-IP: [113.20.67.234] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] greylisting, was Software bashing X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Yes it is still pretty much effective, but should we wait for it to become less effective, or think of a better scheme or simply improve it? ----- Original Message ----- From: "John Levine" To: asrg@irtf.org Sent: Sunday, 25 January, 2009 5:41:32 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] greylisting, was Software bashing >So I think the spammers are now fighting greylisting, and greylisting >is becoming less and less effective. I looked at my greylist logs for the past month. It shows 4911 previously unseen IPs that retried, and 51,348 that didn't. I'd say that a technique that turns away 91% of the mail it touches is still pretty effective. The month before that the numbers were 4707 and 41,487, for about 90%, so in the short term at least, it's pretty consistent. I have data back to May, could crunch it if people wanted. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 14:23:34 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E66A3A69DC; Sat, 24 Jan 2009 14:23:34 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5EA3A69DC for ; Sat, 24 Jan 2009 14:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.804 X-Spam-Level: X-Spam-Status: No, score=-14.804 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 Hed11TKSM5Tx for ; Sat, 24 Jan 2009 14:23:32 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id D10AB3A6984 for ; Sat, 24 Jan 2009 14:23:31 -0800 (PST) Received: (qmail 64150 invoked from network); 24 Jan 2009 22:23:14 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Jan 2009 22:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; i=johnl@user.iecc.com; bh=+70fGY4WT1NfHvGbUx/cSnUjwu+tWzx/Ush7IWtkzII=; b=D8/WbGF0EtinC+DUcg2suE1W8I5vWbMlXYGjL5g81sLgtjuuX3SEGMoxXPO9qHgN/+E9xsL4RHkl+VLmOvA5N9X4Oegis0mHaOwKxWSezJm05auH5G/6mvswoDxaDmcpNWWwCDs+FnkjM4wFfxyXiBbP6uikpbsVN97ZA7jWZrk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0901; bh=+70fGY4WT1NfHvGbUx/cSnUjwu+tWzx/Ush7IWtkzII=; b=JgP9NAEis2Ss9lb9xC9hDsKYIqYlcaNQC6FKH4XS/uJil+lntSKPMyIEAF3a2IJ0HAqMdQjqPvyZoAKDrybghopgEQNTghS1n35gEXsd3UiEq45Tyx5cGP37+buZySCxM2OYZiiLS/lM+8sHZvWiLxo29lVWxSabsgSP2BzpuR4= Date: 24 Jan 2009 22:23:10 -0000 Message-ID: <20090124222310.49488.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <12894329.231232831577892.JavaMail.franck@franck-martins-macbook-pro.local> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Asrg] greylisting, was Software bashing X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > Yes it is still pretty much effective, but should we wait for it to > become less effective, or think of a better scheme or simply improve > it? In 2005 when I wrote my CEAS paper, 16% of greylisted IPs retried. Now it's about 10%, which means that if anything, it works better than ever. Given that we don't have infinite resources, I see little reason to spend more time on greylisting. R's, John _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sat Jan 24 14:35:38 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96633A6B11; Sat, 24 Jan 2009 14:35:37 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10ED03A6B11 for ; Sat, 24 Jan 2009 14:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eoSBxMWzrn5o for ; Sat, 24 Jan 2009 14:35:36 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 2EB023A6AF4 for ; Sat, 24 Jan 2009 14:35:36 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n0OMZG5U017051 for ; Sat, 24 Jan 2009 17:35:18 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n0OMPcdL012593 for ; Sat, 24 Jan 2009 17:25:58 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n0OMYo9m006018 for ; Sat, 24 Jan 2009 17:34:50 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n0OMYmwS006017 for asrg@irtf.org; Sat, 24 Jan 2009 17:34:48 -0500 Date: Sat, 24 Jan 2009 17:34:48 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090124223448.GA5201@gsp.org> References: <12894329.231232831577892.JavaMail.franck@franck-martins-macbook-pro.local> <20090124222310.49488.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090124222310.49488.qmail@simone.iecc.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] greylisting, was Software bashing X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sat, Jan 24, 2009 at 10:23:10PM -0000, John Levine wrote: > Given that we don't have infinite resources, I see little reason to > spend more time on greylisting. I concur with John on this. The one refinement I have fiddled with is the use of greylisting behavior to slowly classify connecting systems as known-friendly, known-hostile, and can't-tell, with different levels of service provided to each. But I'm not at all sure that the payoff for all this work compensates for the effort. ---Rsk _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Sun Jan 25 19:13:05 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C593A6954; Sun, 25 Jan 2009 19:13:05 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5253A6954 for ; Sun, 25 Jan 2009 19:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 3BbCV25KwmhL for ; Sun, 25 Jan 2009 19:13:03 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id AFE543A6768 for ; Sun, 25 Jan 2009 19:13:03 -0800 (PST) Received: from pickering.cc.nd.edu (pickering.cc.nd.edu [129.74.250.225]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n0Q39XN2029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Jan 2009 22:09:33 -0500 Received: from [192.168.0.100] (173-24-16-9.client.mchsi.com [173.24.16.9]) (authenticated bits=0) by pickering.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id n0Q3CPI0003811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Jan 2009 22:12:41 -0500 (EST) Message-ID: <497D2A17.60101@nd.edu> Date: Sun, 25 Jan 2009 22:12:23 -0500 From: Paul Russell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> X-Source-IP: 129.74.250.225 X-ND-MTA-Date: Sun, 25 Jan 2009 22:09:33 EST Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On 1/20/2009 8:26 AM, Ian Eiloart wrote: > I don't buy the argument that an MTA that mangles reject messages (that > requires little or no administrative effort) will also mangle bounce > messages (that requires more effort). Perhaps I'm wrong. Does anyone know > of an MTA that mangles bounce messages in its default configuration? Exchange parses an inbound DSN to identify every address for which delivery status information is provided, then pre-pends the entire DSN with boilerplate text for every address in the DSN, regardless of the specific status code and text for that address. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 26 02:27:41 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2D93A6A67; Mon, 26 Jan 2009 02:27:41 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7613A6A60 for ; Mon, 26 Jan 2009 02:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] 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 JNPc43pdewGy for ; Mon, 26 Jan 2009 02:27:39 -0800 (PST) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 073773A6A47 for ; Mon, 26 Jan 2009 02:27:38 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54831) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KE2QIU-00043C-EY for asrg@irtf.org; Mon, 26 Jan 2009 10:30:30 +0000 Date: Mon, 26 Jan 2009 10:27:17 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <5182781DDB1B0A011A4CCB95@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <497A1432.1030800@tana.it> References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> <20090123141319.GA52653@verdi> <497A1432.1030800@tana.it> Originator-Info: login-token=Mulberry:0159dnzVA41TIoRLsvU/1aTNpATU+IJ0r9XEI=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 23 January 2009 20:02:10 +0100 Alessandro Vesely wrote: > We then have a quite different situation from what raw SPF processing >>>> would indicate. Thus I claim the rules deserve to be relaxed (without >>>> going into detail how). >> >> The point I was attempting to make is that SPF records _can_ >> accurately reflect sender policy, while SPF processing will >> incorrectly indicate a violation of it. > > That's quite correct. I say "quite" because SPF provides for various > levels of results, without mandating any particular behavior. However, > the quickest behavior, reject on fail, does not allow to examine the > message headers. Beware of the word "quite". It can mean "totally" or "partly", depending on context. For example, the term "quite correct" means "absolutely correct", but the term "quite good" could mean "good, but not very good"! The OED thinks that the "partly" meaning is rare in North America, though. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 26 12:54:48 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196EA3A6A57; Mon, 26 Jan 2009 12:54:48 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86FF3A685E for ; Mon, 26 Jan 2009 12:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 X59v+m-++l0I for ; Mon, 26 Jan 2009 12:54:46 -0800 (PST) Received: from boom.graemef.net (boom.graemef.net [82.113.154.29]) by core3.amsl.com (Postfix) with ESMTP id D793B3A687B for ; Mon, 26 Jan 2009 12:54:45 -0800 (PST) Received: from cpc1-shep3-0-0-cust909.lei3.cable.ntl.com ([82.5.39.142]) by boom.graemef.net with esmtpa (Exim 4.69) (envelope-from ) id 1LRYTR-0008P7-Vp for asrg@irtf.org; Mon, 26 Jan 2009 20:54:26 +0000 From: Graeme Fowler To: Anti-Spam Research Group - IRTF In-Reply-To: <497D2A17.60101@nd.edu> References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> <497D2A17.60101@nd.edu> Date: Mon, 26 Jan 2009 20:54:20 +0000 Message-Id: <1233003260.16735.6.camel@ernie.internal.graemef.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) X-graemef.net-scankey: boom.graemef.net 1LRYTR-0008P7-Vp 3e91ae818d7a42c38560e0f918aeaa03 Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Sun, 2009-01-25 at 22:12 -0500, Paul Russell wrote: > Exchange parses an inbound DSN to identify every address for which delivery > status information is provided, then pre-pends the entire DSN with boilerplate > text for every address in the DSN, regardless of the specific status code and > text for that address. In my current experience, it's *Outlook* which does the mangling/prepending/call-it-what-you-will. In $dayjob we run Outlook as the supported desktop client (both 2k3 and 2k7) against a non-MS backend groupware server. When I see, using Outlook 2k7, bounces arrive to our role account handling most of the postmaster guff, I very briefly see the original MTA-provided bounce message in my viewing pane. After a split second this is replaced by the MS-ified version, rendering the item almost completely worthless. I'd put money on Outlook having a DLL included which decodes the message and does the metaphorical email equivalent of "It looks like you're writing a letter!" for the DSN. If I view the messages in Thunderbird, or Evolution, or any other sane(ish) MUA they display as expected - MIME parts, in order or as attachments. Unfortunately I know so little about Windows that debugging this behaviour is all but impossible. You can tar Exchange with many brushes, but apparently not this one - it looks very much like client behaviour to me; that said it's quite rare to see Outlook in "groupware" mode not using Exchange as the backend so I can understand the confluence of data. Graeme _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 26 13:31:42 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB603A69CF; Mon, 26 Jan 2009 13:31:42 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D2E3A69CF for ; Mon, 26 Jan 2009 13:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3rhvqrAAiKKD for ; Mon, 26 Jan 2009 13:31:40 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 46D823A6814 for ; Mon, 26 Jan 2009 13:31:40 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0QLVJR12306 for ; Mon, 26 Jan 2009 21:31:19 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 16:31:08 -0500 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 26 Jan 2009 16:31:07 -0500 Message-ID: <497E2B9B.50200@nortel.com> Date: Mon, 26 Jan 2009 16:31:07 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> <497D2A17.60101@nd.edu> <1233003260.16735.6.camel@ernie.internal.graemef.net> In-Reply-To: <1233003260.16735.6.camel@ernie.internal.graemef.net> X-OriginalArrivalTime: 26 Jan 2009 21:31:08.0176 (UTC) FILETIME=[669C9100:01C97FFD] Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Graeme Fowler wrote: > On Sun, 2009-01-25 at 22:12 -0500, Paul Russell wrote: >> Exchange parses an inbound DSN to identify every address for which delivery >> status information is provided, then pre-pends the entire DSN with boilerplate >> text for every address in the DSN, regardless of the specific status code and >> text for that address. > > In my current experience, it's *Outlook* which does the > mangling/prepending/call-it-what-you-will. Unless this is a different "issue", in our case the DSN mangling _has_ to be being done in Exchange. I'm running Thunderbird, and (some) inbound DSNs get mangled. I don't think the MUA knows enough about or infrastructure to mangle it the way we see it ("reporting MTAs" completely unrelated to us being replaced with internal servers). I suspect it's simple "oh yeah, this is a DSN. I'll report it as a DSN - I'm the "reporter" now", not realizing that "Reporting MTA" _should_ be the server who reports the initial error, not umpty-ump intermediate servers regenerating the same DSN. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 26 19:55:15 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9E33A6992; Mon, 26 Jan 2009 19:55:15 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F633A6989 for ; Mon, 26 Jan 2009 19:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, URIBL_PH_SURBL=1.787] 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 wUQFwNp+b8T6 for ; Mon, 26 Jan 2009 19:55:12 -0800 (PST) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 7A5583A6851 for ; Mon, 26 Jan 2009 19:55:10 -0800 (PST) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 7D1B982F14C for ; Mon, 26 Jan 2009 22:54:47 -0500 (EST) Message-ID: <497E8583.2070301@billmail.scconsult.com> Date: Mon, 26 Jan 2009 22:54:43 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090120145354.57509.qmail@simone.iecc.com> In-Reply-To: <20090120145354.57509.qmail@simone.iecc.com> Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Levine wrote, On 1/20/09 9:53 AM: [...] > Why do you keep harping on SPF? Of all of the proposed security > schemes on offer, it is by far the worst. It doesn't even attempt to > secure any part of the message visible to recipients, and it only > works for the subset of mail that is sent from a fixed point to > recipients who don't remail or forward it. (Despite endless claims by > SPF's fans, that last part is a fundamental design failure of SPF, not > of the mail system.) I should preface this by saying that I deeply regret my public and private discussions of the embryonic source concepts that spawned SPF and Sender-ID and if in any way I helped evangelize a single SPF fan in my 2000-2004 delusional state, I am terribly sorry and beg forgiveness. I was so wrong. My only excuse is that a lot of other smarter and/or more influential people were also wrong... The reason that SPF is here to stay is that it is good enough authentication for most of the mail that most receivers and senders care the most about. A lot of people get significant quantities of mail they care about via forwarding systems or have to send through paths that can't get them a SPF '+' anywhere that matters without +all, but we are a minority. Legitimate bulk senders, consumer retail ISP's, and non-bulk business mail senders can all make their outbound mail pass SPF at their border, and the largest (i.e. consumer ISP) and pickiest (i.e. corporate) receiving systems can get some benefit by using SPF in some way on some of their incoming mail. The people who encounter significant breakage in SPF are an elite class, including a large fraction of the people who actually work with mail technology directly (i.e. *US*) but having created this breakage with our eyes open and having given the masses a tool that mostly works for them, we are stuck with SPF until something that works significantly better for them with similar or less effort can replace it. > DKIM at least starts to address those problems, but it still doesn't > begin to try to deal with the much harder problem of lookalike > domains. Let's say you get a message from security@pay-pal.com, which > is 100% DKIM, SPF, and Sender-ID approved. Is that Paypal? How can > you tell short of manually looking up WHOIS registrations? Which is half of why DKIM is not a SPF-killer. It shares a key gap with SPF that actually makes a difference to the masses: some way to tell whether an authenticated sender is actually a good sender. The other half is that it is significantly harder to deploy on both ends. The fact that it is more robust than SPF when dealing with mail that takes interesting paths can't make up for the big gap: it is only an authentication tool, and the authentication only goes as far as demonstrating the cooperation of a mail admin and a dns admin (or someone who can crack the relevant mail and DNS systems) with a sender. It seems to me that if anyone ever devises a trustworthy and broadly deployable/applicable shared *authorization* layer for mail, SPF and DKIM will both be too weak on other grounds to be the dominant authentication mechanism. If there were such a thing as a trustworthy domain vouching system to tell me that I can be sure that mail definitely from a paypal.com sender is not phishing and mail definitely from a pay-pal.com sender is, then I don't see why I'd use DKIM to do the authentication instead of nagging the paypal.com folks to sign their mail with S/MIME so that I don't have to support 2 signing technologies. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Mon Jan 26 20:17:26 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE373A6A16; Mon, 26 Jan 2009 20:17:26 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63A73A6A16 for ; Mon, 26 Jan 2009 20:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.894, BAYES_00=-2.599] 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 nFmJ8tb6VTMb for ; Mon, 26 Jan 2009 20:17:24 -0800 (PST) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 8D3453A688F for ; Mon, 26 Jan 2009 20:17:24 -0800 (PST) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 3EE6082F185 for ; Mon, 26 Jan 2009 23:17:06 -0500 (EST) Message-ID: <497E8AB7.6010305@billmail.scconsult.com> Date: Mon, 26 Jan 2009 23:16:55 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090120145354.57509.qmail@simone.iecc.com> <20090120155005.GJ24908@verdi> <497747B8.5030206@tana.it> <20090121172756.GL24908@verdi> <77EC9269686778C04201F039@lewes.staff.uscs.susx.ac.uk> <20090123141319.GA52653@verdi> In-Reply-To: <20090123141319.GA52653@verdi> Subject: Re: [Asrg] mail security X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org John Leslie wrote, On 1/23/09 9:13 AM: > Ian Eiloart wrote: >> --On 21 January 2009 12:27:56 -0500 John Leslie wrote: >> >>> However, there are a limited number of ways that forwarding might be >>> shown in the trace headers, so it should be practical to determine that >>> a forwarding is documented (though possibly forged). >>> >>> We then have a quite different situation from what raw SPF processing >>> would indicate. Thus I claim the rules deserve to be relaxed (without >>> going into detail how). > > The point I was attempting to make is that SPF records _can_ accurately > reflect sender policy, while SPF processing will incorrectly indicate a > violation of it. There's also a subtle variation on that... It was discussed (even here) in the early development of SPF that a trailing '-all' can and perhaps should be read as a 'do not forward' policy statement by a domain owner. That was not considered a valuable feature by the people who ended up promoting SPF, but there are people who publish such records with the intent of expressing such a policy. Whether such a policy should be within the authority of a domain owner is a knotty question. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 27 15:35:02 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0391B3A6937; Tue, 27 Jan 2009 15:35:02 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729933A6937 for ; Tue, 27 Jan 2009 15:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001] 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 9Sd90rvEw9L7 for ; Tue, 27 Jan 2009 15:35:00 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by core3.amsl.com (Postfix) with ESMTP id 146173A683A for ; Tue, 27 Jan 2009 15:34:59 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with SMTP id CE6A4197308E for ; Tue, 27 Jan 2009 23:34:40 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, ace4ce6e64ad83a8, cd14ec2c010f1043, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:854:945:967:972:973:980:982:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2194:2199:2393:2525:2559:2563:2682:2685:2689:2691:2693:2705:2828:2857:2859:2910:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3353:3636:3657:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:6114:6119:6120:7652:7679:7903:8501:8957:8985:9025:9108, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 27 Jan 2009 23:34:39 +0000 (UTC) Message-ID: <497F9A11.1000604@terabites.com> Date: Tue, 27 Jan 2009 17:34:41 -0600 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: asrg@irtf.org X-session-marker: 6765703261407465726162697465732E636F6D Subject: [Asrg] SPF apologies X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org > The reason that SPF is here to stay is that it is good enough authentication for most of the mail that most receivers and senders care the most about. With all due respect, that's kind of like saying that you've developed an airplane which will get the passengers there for 95 (or even 99) flights out of a hundred...! The fact that SPF screws up on so many ENTIRELY ANTICIPATED AND LEGIITIMATE cases, IMHO, makes it not viable, even though it works for SOME mails, MOST of the time. Personally, I *strongly* believe that the best approach requires a mix of techniques, including (again) a combination of: 1) fine-grained content criteria based upon the sender/recipient duple; 2) a suitably restrictive default policy to apply to senders previously unknown (or untrusted) to the indicated intended recipient; 3) following THOSE techniques, which by default will block virtually all worms/viruses and other evasions, then use SpamAssassin or similar to analyze the actual content of the message (which, after scripting/HTML/attachments/ActiveX and so forth are out of the equation) can probably do a pretty good job. 4) additional optional content tests for familiar senders (familiar mastheads, sig files, or other familiar-looking authenticating content that recipient expects in mail from that sender). If implemented intelligently, I believe this will provide the MOST safety, the FEWEST false positives, and give the recipient (the one who counts the most) the best feeling of control over their Inbox. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Tue Jan 27 16:00:43 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1ADD3A68CD; Tue, 27 Jan 2009 16:00:43 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D483A68CD for ; Tue, 27 Jan 2009 16:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 TxHWvdWVLK3b for ; Tue, 27 Jan 2009 16:00:42 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 850BF3A67EF for ; Tue, 27 Jan 2009 16:00:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id CBE0964F831E for ; Wed, 28 Jan 2009 12:00:36 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3X5-MzQzBtx for ; Wed, 28 Jan 2009 12:00:36 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 7A3BB64F8263 for ; Wed, 28 Jan 2009 12:00:36 +1200 (FJT) Date: Wed, 28 Jan 2009 12:00:36 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <12487815.141233100818271.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <497F9A11.1000604@terabites.com> MIME-Version: 1.0 X-Originating-IP: [192.168.69.118] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/0.92_1433_Mac) Subject: Re: [Asrg] SPF apologies X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org It seems this thread is going into flamewar. I think better leave it to "running code" and see which one become a standard because people just use it. Also, what has been found by experience, is that the IETF is not very goo at creating new protocols but it is very good at taking a protocol and make it rock solid. ----- Original Message ----- From: "Gordon Peterson" To: asrg@irtf.org Sent: Wednesday, 28 January, 2009 11:34:41 AM (GMT+1200) Auto-Detected Subject: [Asrg] SPF apologies > The reason that SPF is here to stay is that it is good enough authentication for most of the mail that most receivers and senders care the most about. With all due respect, that's kind of like saying that you've developed an airplane which will get the passengers there for 95 (or even 99) flights out of a hundred...! The fact that SPF screws up on so many ENTIRELY ANTICIPATED AND LEGIITIMATE cases, IMHO, makes it not viable, even though it works for SOME mails, MOST of the time. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 28 02:51:12 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E60E3A69A2; Wed, 28 Jan 2009 02:51:12 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5465228C107 for ; Wed, 28 Jan 2009 02:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] 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 XH73MTTt9QDi for ; Wed, 28 Jan 2009 02:51:11 -0800 (PST) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 68F513A69A2 for ; Wed, 28 Jan 2009 02:51:11 -0800 (PST) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52299) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KE6GXY-000G2I-J2 for asrg@irtf.org; Wed, 28 Jan 2009 10:53:58 +0000 Date: Wed, 28 Jan 2009 10:50:48 +0000 From: Ian Eiloart To: Anti-Spam Research Group - IRTF Message-ID: <2B7B83981CD90161C9637DC8@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <497F9A11.1000604@terabites.com> References: <497F9A11.1000604@terabites.com> Originator-Info: login-token=Mulberry:01voLe/ifjTGP/7zJgKqgx91FxJPr/WCGoM+0=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] SPF apologies X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org --On 27 January 2009 17:34:41 -0600 Gordon Peterson wrote: > > The reason that SPF is here to stay is that it is good enough > authentication for most of the mail that most receivers and senders care > the most about. > > With all due respect, that's kind of like saying that you've developed an > airplane which will get the passengers there for 95 (or even 99) flights > out of a hundred...! > > The fact that SPF screws up on so many ENTIRELY ANTICIPATED AND > LEGIITIMATE cases, IMHO, makes it not viable, even though it works for > SOME mails, MOST of the time. > > Personally, I *strongly* believe that the best approach requires a mix of > techniques, including (again) a combination of: > > 1) fine-grained content criteria based upon the sender/recipient > duple; > > 2) a suitably restrictive default policy to apply to senders > previously unknown (or untrusted) to the indicated intended recipient; > > 3) following THOSE techniques, which by default will block virtually > all worms/viruses and other evasions, then use SpamAssassin or similar to > analyze the actual content of the message (which, after > scripting/HTML/attachments/ActiveX and so forth are out of the equation) > can probably do a pretty good job. > > 4) additional optional content tests for familiar senders (familiar > mastheads, sig files, or other familiar-looking authenticating content > that recipient expects in mail from that sender). > > If implemented intelligently, I believe this will provide the MOST > safety, the FEWEST false positives, and give the recipient (the one who > counts the most) the best feeling of control over their Inbox. With all due respect, that's kind of like saying that you've developed an airplane which will get the passengers there for 95 (or even 99) flights out of a hundred...! Only this time, the airplane was designed by Heath Robinson or Rube Goldberg. -- Ian Eiloart IT Services, University of Sussex x3148 _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Wed Jan 28 19:55:58 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571613A6872; Wed, 28 Jan 2009 19:55:58 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9C33A6872 for ; Wed, 28 Jan 2009 19:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] 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 z9kSCrgeqea9 for ; Wed, 28 Jan 2009 19:55:56 -0800 (PST) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 503163A67D8 for ; Wed, 28 Jan 2009 19:55:56 -0800 (PST) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id E61EA831846 for ; Wed, 28 Jan 2009 22:55:36 -0500 (EST) Message-ID: <498128B8.1020703@billmail.scconsult.com> Date: Wed, 28 Jan 2009 22:55:36 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <497F9A11.1000604@terabites.com> In-Reply-To: <497F9A11.1000604@terabites.com> Subject: Re: [Asrg] SPF apologies X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org Gordon Peterson wrote, On 1/27/09 6:34 PM: > > The reason that SPF is here to stay is that it is good enough > authentication for most of the mail that most receivers and senders care > the most about. > > With all due respect, that's kind of like saying that you've developed > an airplane which will get the passengers there for 95 (or even 99) > flights out of a hundred...! After all, we all know that a failed email delivery is as significant as a failed airline delivery... I think a closer analogy is to airline scheduling. Flights get cancelled and people get bumped off of overbooked flights all the time. Probably more frequently as a percentage of passengers than the percentage of mail that is rejected (rightly or wrongly) solely as a result of SPF. > The fact that SPF screws up on so many ENTIRELY ANTICIPATED AND > LEGIITIMATE cases, IMHO, makes it not viable, even though it works for > SOME mails, MOST of the time. Objective reality disagrees with you. Use of SPF in non-harmful ways is fairly widespread, and there's not much indication of it going away. The willingness of MS to misuse SPF and SenderID to actively degrade the value of Hotmail addresses has spurred publication of SPF addresses and made the safe use of SPF more beneficial. SPF is not viable as a direct anti-spam tool because it cannot be trusted generally to identify forged messages, and will yield derogatory results for mail that generally would be considered legitimate. However, it has demonstrated viability as a tool to exempt (quasi-)authenticated mail from known-good senders from error-prone filtering. SPF derogatory results are marginally useful (e.g. in heuristic scoring systems like SA.) The limits on is safe use have not been enough to kill it altogether and probably never will be. I am absolutely in agreement that it was a strategic error to push SPF to a formal RFC spec, but that is hindsight. SPF is not going away. > Personally, I *strongly* believe that the best approach requires a mix > of techniques, Right, and SPF has carved out a niche in a layered system. It's a lot weaker than some people hoped it would be but it serves a purpose. We'd all be better off if people who should have known better had not pressed for publication of RFC's 4406-4408, but that's done. > including (again) a combination of: > > 1) fine-grained content criteria based upon the sender/recipient duple; > > 2) a suitably restrictive default policy to apply to senders > previously unknown (or untrusted) to the indicated intended recipient; Which is where SPF has entrenched itself. It is the easiest standardized mechanism for affirmative authentication of senders. It's not a general tool for identifying all forgeries, but it is useful and it is in widespread use. Ranting against its use is a few years late and not constructive, particularly when the critique is aimed at flaws that are avoided by the narrow uses that are actually common. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg-bounces@irtf.org Thu Jan 29 17:33:07 2009 Return-Path: X-Original-To: asrg-archive@optimus.ietf.org Delivered-To: ietfarch-asrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2923A6A63; Thu, 29 Jan 2009 17:33:06 -0800 (PST) X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B4F3A6AFB for ; Thu, 29 Jan 2009 17:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 oQxHphG6JpD1 for ; Thu, 29 Jan 2009 17:33:04 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 87F963A6AB0 for ; Thu, 29 Jan 2009 17:33:04 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EEBDEA9443D for ; Thu, 29 Jan 2009 23:20:44 +0000 (UTC) Message-Id: <00CC0095-2A40-4A03-8645-5A516B8849C1@mail-abuse.org> From: Douglas Otis To: asrg@irtf.org In-Reply-To: <498128B8.1020703@billmail.scconsult.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 29 Jan 2009 15:20:44 -0800 References: <497F9A11.1000604@terabites.com> <498128B8.1020703@billmail.scconsult.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] SPF apologies X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: asrg-bounces@irtf.org Errors-To: asrg-bounces@irtf.org On Jan 28, 2009, at 7:55 PM, Bill Cole wrote: > Which is where SPF has entrenched itself. It is the easiest > standardized mechanism for affirmative authentication of senders. > It's not a general tool for identifying all forgeries, but it is > useful and it is in widespread use. Ranting against its use is a few > years late and not constructive, particularly when the critique is > aimed at flaws that are avoided by the narrow uses that are actually > common. Bill, There is now the Authentication-Results header that offers dangerous ways to reveal SPF results. The draft defining the use of this header suggests, in so many words, that local-parts are not to be included unless local-part macros are employed. Please be careful about misrepresenting what is achieved when an SMTP client has been SPF authorized by a domain. Don't describe the authorization as having "authenticated" the source domain. It is worrisome to contemplate the number of people who will be mislead and harmed by the many ways that this erroneous conclusion can be exploited by those with access outbound servers. Earning the status of Authentication should not be based upon a number of doubtful assumptions. -Doug _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg