From asrg-bounces@ietf.org Mon Nov 1 11:42:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00690 for ; Mon, 1 Nov 2004 11:42:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfVe-0003cW-RD for asrg-web-archive@ietf.org; Mon, 01 Nov 2004 11:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COerK-0006Jc-Dh; Mon, 01 Nov 2004 11:16:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COe9k-00069M-9l for asrg@megatron.ietf.org; Mon, 01 Nov 2004 10:31:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18563 for ; Mon, 1 Nov 2004 10:31:38 -0500 (EST) Received: from h-69-3-215-47.lsanca54.covad.net ([69.3.215.47] helo=mushu.greatscot.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COeOQ-0001B4-F1 for asrg@ietf.org; Mon, 01 Nov 2004 10:47:01 -0500 Received: from mushu.greatscot.org (localhost.craniumpro.com [127.0.0.1]) by mushu.greatscot.org (8.12.8/8.12.8) with ESMTP id iA1FVD7W008218; Mon, 1 Nov 2004 07:31:13 -0800 Received: (from apache@localhost) by mushu.greatscot.org (8.12.8/8.12.8/Submit) id iA1FV9qg008216; Mon, 1 Nov 2004 07:31:09 -0800 Received: from ([192.45.66.42]) by www.craniumpro.com with HTTP; Mon, 1 Nov 2004 07:31:09 -0800 (PST) Message-ID: <9190.192.45.66.42.1099323069.squirrel@192.45.66.42> In-Reply-To: <200410301624.i9UGOs7W027210@mushu.greatscot.org> References: <200410301624.i9UGOs7W027210@mushu.greatscot.org> Date: Mon, 1 Nov 2004 07:31:09 -0800 (PST) From: "Douglas Campbell" To: asrg@ietf.org User-Agent: SquirrelMail/1.4.3 X-Mailer: SquirrelMail/1.4.3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SPAMFLAMBEAU-ID: (2259) 2004-11-01 07:31:13.673405-07:00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit Subject: [Asrg] Re: A plea for more hierarchy in DNS X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Doug.Campbell@craniumpro.com List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit On 30 OCT 2004, Peter J. Holzer said: > Last time I looked, MTAmark needed only a couple of TXT records. No > change of DNS or BIND necessary. > Ah, thank you Peter. The light comes on. >> To be really honest, I'm small fry. I don't do my own DNS -- I let my >> registrar do it. And the interface they have doesn't seem to allow for >> TXT records. > > You aren't the only one. My ISP doesn't delegate reverse DNS for /29 > networks, so I couldn't implement MTAmark for my home network myself but > need my ISP to do that. (OTOH, maybe that isn't that bad - let ISPs > publish MTA=no indications for their whole range and customers who want > to run their own MTA have to explicitely tell their ISP). This is why the light took so long. I read the spec but didn't get the part about the TXT records for reverse lookups being the only valid ones. That means I can't set them myself, but must rely on the controller of my address range to do it (which might NOT be my ISP). This does not seem onerous; I'd expect them to be eager to cut the spam transiting their network. I would certainly be willing to pay a fee to allow my mailserver access to the network. Some of the ISP's (particularly those in Asia and Latin America) just don't seem to care what their network emits -- they take the money and turn a blind eye. I have whole countries on my blacklists now. What a pain. The problem is that SPAM is business -- the big spammers would find the maximum fee I'm willing to pay chump change (throw away money). _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 1 23:30:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23574 for ; Mon, 1 Nov 2004 23:30:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COqYv-0006bp-Q8 for asrg-web-archive@ietf.org; Mon, 01 Nov 2004 23:46:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COqC0-0007Ik-Lc; Mon, 01 Nov 2004 23:22:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COq4A-00023n-Eq for asrg@megatron.ietf.org; Mon, 01 Nov 2004 23:14:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22722 for ; Mon, 1 Nov 2004 23:14:40 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COqJC-0006Ll-9m for asrg@ietf.org; Mon, 01 Nov 2004 23:30:14 -0500 Received: by rproxy.gmail.com with SMTP id 75so249454rnk for ; Mon, 01 Nov 2004 20:14:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=n3ZVWQHJmr9zD6EWfCrjgb3VZYfR7rC/r1BjgzV860ws0qBaDZMOp0GTDblaV5Jzh5sWZZAkXrQnMK5a/gIhWxqGOqqRufjR8X8p8ytyqCT/AoB19DC2z2KvwgoWatJFRHRpdu06tv1E0MbBKp1dpaH2a60POD4AGzFyxjaeyxE= Received: by 10.38.72.20 with SMTP id u20mr1221453rna; Mon, 01 Nov 2004 20:14:34 -0800 (PST) Received: by 10.38.22.55 with HTTP; Mon, 1 Nov 2004 20:14:33 -0800 (PST) Message-ID: <4ee41db604110120143caa2968@mail.gmail.com> Date: Tue, 2 Nov 2004 09:44:33 +0530 From: Krishna To: asrg Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Asrg] fake messages X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Krishna List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit hi, SMTP can act as a relay server. This property can be misused by the spammers ( one who sends spams) to send fake messages. This is a serious problem because an ordinary man does not check the inner details of the mail, he just sees the from address. It was even possible to send fake messages to the popular mail accounts (like yahoo,gmail) which are using some kind of spam filters. I got a free account from a Internet service provider with SMTP and JSP support. then i wrote a simple program in JavaMail, using which it was very easy for me to send fake messages, i mean it was possible to send a message and make it appear as if it came from some else. Also i found that many ISP's are not using any kind of filters. I think that using filter would not completely solve this problem. Also this is the from the start of SMTP protocol. I wonder why this problem is not yet solved ( if solved i would not have been possible for me to send fake message). Please let me know the improvements and research going on to avoid this so that I can try to solve this problem.Also, please let me know if these issues are being addressed elsewhere. thanks -- Krishna http://geocities.com/krishna_ani _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Nov 2 09:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25682 for ; Tue, 2 Nov 2004 09:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0D1-0003IS-3U for asrg-web-archive@ietf.org; Tue, 02 Nov 2004 10:04:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzkN-0002W0-EE; Tue, 02 Nov 2004 09:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzi8-00018o-NA for asrg@megatron.ietf.org; Tue, 02 Nov 2004 09:32:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24412 for ; Tue, 2 Nov 2004 09:32:35 -0500 (EST) Received: from teal.hjp.at ([62.99.236.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COzxG-0002sz-3q for asrg@ietf.org; Tue, 02 Nov 2004 09:48:15 -0500 Received: (qmail 6765 invoked by uid 500); 2 Nov 2004 14:31:59 -0000 Date: Tue, 2 Nov 2004 15:31:59 +0100 From: "Peter J. Holzer" To: asrg Subject: Re: [Asrg] fake messages Message-ID: <20041102143159.GA6595@teal.hjp.at> Mail-Followup-To: asrg References: <4ee41db604110120143caa2968@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <4ee41db604110120143caa2968@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2076856282==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============2076856282== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-11-02 09:44:33 +0530, Krishna wrote: [open relays and faked senders] > Also i found that many ISP's are not using any kind of filters. I > think that using filter would not completely solve this problem. Also > this is the from the start of SMTP protocol. I wonder why this problem > is not yet solved ( if solved i would not have been possible for me to > send fake message). >=20 > Please let me know the improvements and research going on to avoid > this so that I can try to solve this problem.Also, please let me know > if these issues are being addressed elsewhere. Please see the archives of this list at http://www1.ietf.org/mail-archive/web/asrg/current/index.html (and also the archives of the various sub-groups) and the documentsa on this working groups home page at http://asrg.sp.am/. These issues have been discussed many times and many partial solutions have been proposed. hp --=20 _ | Peter J. Holzer | Je h=F6her der Norden, desto weniger wird |_|_) | Sysadmin WSR | =FCberhaupt gesprochen, also auch kein Dialekt. | | | hjp@hjp.at | Hallig Gr=F6de ist fast g=E4nzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBh5pefZ+RkG8quy0RAg98AKC2lz8zALR866L2YmMFfErD/Gs0dQCgxnLp hCsC3D/XMUFu/zE4SOr65DU= =onIq -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============2076856282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============2076856282==-- From asrg-bounces@ietf.org Tue Nov 2 18:48:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01908 for ; Tue, 2 Nov 2004 18:48:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8dJ-0002Eo-BH for asrg-web-archive@ietf.org; Tue, 02 Nov 2004 19:04:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8EI-00023l-92; Tue, 02 Nov 2004 18:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7wn-0002ee-Io for asrg@megatron.ietf.org; Tue, 02 Nov 2004 18:20:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29452 for ; Tue, 2 Nov 2004 18:20:15 -0500 (EST) Received: from teal.hjp.at ([62.99.236.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CP8Bz-0001Yv-RP for asrg@ietf.org; Tue, 02 Nov 2004 18:36:00 -0500 Received: (qmail 10940 invoked by uid 500); 2 Nov 2004 23:19:44 -0000 Date: Wed, 3 Nov 2004 00:19:44 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: MTAmark deployment (was: [Asrg] Re: A plea for more hierarchy in DNS) Message-ID: <20041102231944.GA10424@teal.hjp.at> Mail-Followup-To: asrg@ietf.org References: <200410301624.i9UGOs7W027210@mushu.greatscot.org> <9190.192.45.66.42.1099323069.squirrel@192.45.66.42> Mime-Version: 1.0 In-Reply-To: <9190.192.45.66.42.1099323069.squirrel@192.45.66.42> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1844016856==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --===============1844016856== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-11-01 07:31:09 -0800, Douglas Campbell wrote: > This is why the light took so long. I read the spec but didn't get the > part about the TXT records for reverse lookups being the only valid ones.= =20 > That means I can't set them myself, but must rely on the controller of my > address range to do it (which might NOT be my ISP). This does not seem > onerous; I'd expect them to be eager to cut the spam transiting their > network.=20 I'd expect that, too. Unfortunately our expectations aren't met. I just tested all the 155k IP addresses which connected during October to our main MX for MTAmark records. Results (excluding our own network): 155173 MTA=3Dunknown 8 MTA=3Dno 6 MTA=3Dyes Well, that's a a bit better than a similar test I did in July, but there clearly aren't enough MTAmark records yet to bother implementing filters based on them. Even worse, while the MTA=3Dyes records seem correct, the MTA=3Dno records are a bit suspicious: Host 177.211.151.12.in-addr.arpa not found: 2(SERVFAIL) 10.122.171.136.in-addr.arpa domain name pointer ctsmtpho1.chevrontexaco.com. 19.162.87.192.in-addr.arpa domain name pointer mail.iss.nl. 144.5.87.192.in-addr.arpa domain name pointer relay.surfnet.nl. 16.50.87.192.in-addr.arpa domain name pointer swets-fw1.swets.nl. Host 13.52.171.194.in-addr.arpa not found: 3(NXDOMAIN) 46.182.41.212.in-addr.arpa domain name pointer d429b62e.adsl.legend.co.uk. 87.225.69.212.in-addr.arpa domain name pointer outbound2.mail.legend.net.uk. Half of the names seem to have something to do with mail, and one of the hosts is even called "outbound2". I can't help but think that in these cases someone created an MTA=3Dno record for the whole network but forgot to add the MTA=3Dyes records for the mail servers (Happened to me, too: I posted a record for the main mail server, but forgot the mailing list server). I also talked to the postmaster of another Austrian ISP (who happens to be responsible for 5 of the 6 MTA=3Dyes records) and he said they would only publish MTA=3Dyes records for their servers, but no MTA=3Dno records f= or their dial-up and DSL customers. Which doesn't seem to be very useful to me. hp PS: If someone wants to do similar stats, the script I used is at http://www.hjp.at/mail/spam/mtamark/mtamark.pl It expects one IP address per line as input and spits out the MTAmark record for each IP address. It is quite slow (about 1 second per IP address on average), so if you want to test lots of addresses you should split the input into several files and run them in parallel. --=20 _ | Peter J. Holzer | Je h=F6her der Norden, desto weniger wird |_|_) | Sysadmin WSR | =FCberhaupt gesprochen, also auch kein Dialekt. | | | hjp@hjp.at | Hallig Gr=F6de ist fast g=E4nzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBiBYQfZ+RkG8quy0RAuyqAJ92nY+R1hyrP8ChLVhzdEzfEVv9ogCcC+J7 pxKgERRUIHtzMsHaAePBNmE= =M8lT -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- --===============1844016856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1844016856==-- From asrg-bounces@ietf.org Mon Nov 8 21:25:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04077 for ; Mon, 8 Nov 2004 21:25:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRLhg-0005cS-8t for asrg-web-archive@ietf.org; Mon, 08 Nov 2004 21:25:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLdg-0007Zy-9D; Mon, 08 Nov 2004 21:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLYo-00060w-93 for asrg@megatron.ietf.org; Mon, 08 Nov 2004 21:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03304 for ; Mon, 8 Nov 2004 21:16:39 -0500 (EST) Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRLZS-0005Qe-Ap for asrg@ietf.org; Mon, 08 Nov 2004 21:17:23 -0500 Received: (qmail 95487 invoked by uid 1013); 9 Nov 2004 02:16:29 -0000 Date: Tue, 9 Nov 2004 03:16:29 +0100 From: Markus Stumpf To: asrg@ietf.org Subject: Re: MTAmark deployment (was: [Asrg] Re: A plea for more hierarchy in DNS) Message-ID: <20041109021629.GB90089@Space.Net> References: <200410301624.i9UGOs7W027210@mushu.greatscot.org> <9190.192.45.66.42.1099323069.squirrel@192.45.66.42> <20041102231944.GA10424@teal.hjp.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041102231944.GA10424@teal.hjp.at> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Wed, Nov 03, 2004 at 12:19:44AM +0100, Peter J. Holzer wrote: > Well, that's a a bit better than a similar test I did in July, but there > clearly aren't enough MTAmark records yet to bother implementing filters > based on them. We have added MTAMARK records to some hundred of our ASP mailservers ;-) > Even worse, while the MTA=yes records seem correct, the MTA=no records > are a bit suspicious: The most I have seen were wildcard records. Some of them said 'no DNS yet' some gave all kinds of information, some had SPF records ;-) > I also talked to the postmaster of another Austrian ISP (who happens to > be responsible for 5 of the 6 MTA=yes records) and he said they would > only publish MTA=yes records for their servers, but no MTA=no records for > their dial-up and DSL customers. Which doesn't seem to be very useful to me. It is useful enough ;-) We do greylisting and disable greylisting in cases there is a MTA=yes record. Works very good for connections between our customers or with e.g. utanet.at servers. There is native support for MTAMARK in the current sendmail versions. I hope to have a qmail interface/patch ready by the end of this week. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Nov 17 16:47:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22151 for ; Wed, 17 Nov 2004 16:47:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXgR-0006Qi-4E for asrg-web-archive@ietf.org; Wed, 17 Nov 2004 16:49:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXIg-0000HB-Mu; Wed, 17 Nov 2004 16:25:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWiQ-0002Uq-Ep for asrg@megatron.ietf.org; Wed, 17 Nov 2004 15:47:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10970 for ; Wed, 17 Nov 2004 15:47:44 -0500 (EST) Received: from bay2-f6.bay2.hotmail.com ([65.54.247.6] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUWkp-0002yh-70 for asrg@ietf.org; Wed, 17 Nov 2004 15:50:20 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Nov 2004 12:47:02 -0800 Received: from 192.85.16.3 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 17 Nov 2004 20:46:37 GMT X-Originating-IP: [192.85.16.3] X-Originating-Email: [kmn_asgr@hotmail.com] X-Sender: kmn_asgr@hotmail.com From: "Kurt Magnusson" To: asrg@ietf.org Date: Wed, 17 Nov 2004 17:46:37 -0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2004 20:47:02.0142 (UTC) FILETIME=[970491E0:01C4CCE6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Asrg] SURBL and newer URL's + is ASRG shuting down ? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 In may last year I put up an proposal for a spam method, using the fact that spam is a business proposal from the sender, therefore having to provide a communication method for the "customer", generally a phone no or a URL. The method, that I called Earnest, because I look for real info in the spams, got some critisism for that the blacklist over Ph.no's and URL's to find the spams, could be tainted. I have now for 1.5 year been running a PoC, with generally very good results, using a simple shellscript with some grep lines. The blacklist, built using spams that got through and Spamarchive.org repositories, held up fine to the present Rolex/Viagra campaines. Before the Rolex explosion, I had an average of 2-3 spams in of ca 35 a day over the 1.5 years. To cope with Rolex, I added SURBL DNS list to the PoC, which thankfully decreased the post-Rolex hits from 20-30 in of 40-50 spams a day to 6-8 passing in. SURBL has become a good tool, but it still have a turnaround of a couple of hours before a URL domain is in the DNS, for in my tests of SURBL, it later correctly has identified the spams that got in. I want to decrease the turnaround time, from when I can identify them. Does anyone know of a spamlist/webpage using multiple independent honeypots, comparing spams and identifying them by the multiplicity of mails with the same contact info, then presenting data realtime, so one can use it to extract domains for blocking? It is OK if it is full mails, just that I can generate temp blocklists, until SURBL publish the domains. Then the list has been rather low-volume the last 1.5 month, at least at the IETF web where I read it, is the group dying out, giving up? Kurt Magnusson _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Nov 18 12:28:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14226 for ; Thu, 18 Nov 2004 12:28:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUq7i-0006j5-SB for asrg-web-archive@ietf.org; Thu, 18 Nov 2004 12:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpy1-0002DY-01; Thu, 18 Nov 2004 12:21:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUphq-0003z3-OY for asrg@megatron.ietf.org; Thu, 18 Nov 2004 12:04:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11970 for ; Thu, 18 Nov 2004 12:04:24 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUpkV-00064j-QU for asrg@ietf.org; Thu, 18 Nov 2004 12:07:12 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CUphn-0003wy-00 for ; Thu, 18 Nov 2004 18:04:23 +0100 Received: from c-134-88-163.hh.dial.de.ignite.net ([62.134.88.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2004 18:04:23 +0100 Received: from nobody by c-134-88-163.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2004 18:04:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Thu, 18 Nov 2004 17:54:01 +0100 Organization: Lines: 20 Message-ID: <419CD3A9.5258@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-163.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 2.9 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: SURBL and newer URL's + is ASRG shuting down ? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Kurt Magnusson wrote: > is the group dying out, giving up? The IETF closed MARID without prior consultation with the WG, they offer RfC 3865. Maybe you forgot to implement RfC 3865. Accelerating SURBL is discussed on the SURBL list, you find it on Each "FUSSP" has its own mailing list, that's a feature because the spammers never find out what anti-spammers try next (except from shooting in their own feet and deleting mails with random devices. ;-) "R*lex" is a new synonym of "Vi*gr*", test "JHD". Joke off, there was a new ASRG draft less than three days ago: http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-01.txt Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Nov 19 14:14:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03312 for ; Fri, 19 Nov 2004 14:14:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEFz-0004Cn-Im for asrg-web-archive@ietf.org; Fri, 19 Nov 2004 14:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVE3d-0007kv-4T; Fri, 19 Nov 2004 14:04:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVDwS-0005fX-BA for asrg@megatron.ietf.org; Fri, 19 Nov 2004 13:57:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01758 for ; Fri, 19 Nov 2004 13:57:07 -0500 (EST) From: Gary.Allmond@do.treas.gov Received: from mx-relay24.treas.gov ([199.196.132.8] helo=mxrelay23.treas.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVDzJ-0003l3-5N for asrg@ietf.org; Fri, 19 Nov 2004 14:00:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mxrelay23.treas.gov (Postfix) with ESMTP id 6AC2EFEA for ; Fri, 19 Nov 2004 13:57:04 -0500 (EST) Received: from mxrelay23.treas.gov ([127.0.0.1]) by localhost (mx-relay23 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28261-02-79 for ; Fri, 19 Nov 2004 13:57:03 -0500 (EST) Received: from tias23.treas.gov (tias23.treas.gov [199.196.132.23]) by mxrelay23.treas.gov (Postfix) with ESMTP id 626E41003 for ; Fri, 19 Nov 2004 13:57:00 -0500 (EST) Received: from mailhub.treas.gov by tias23.treas.gov via smtpd (for mx-mart-relay.treas.gov [199.196.132.8]) with ESMTP; Fri, 19 Nov 2004 13:57:00 -0500 Received: from mailhub-22.treas.gov (localhost [127.0.0.1]) by localhost.mailer.treas.gov (Postfix) with ESMTP id 334C9115 for ; Fri, 19 Nov 2004 13:57:00 -0500 (EST) Received: from dofw1.net.treas.gov (dofw1.do.treas.gov [10.0.8.231]) by mailhub-22.treas.gov (Postfix) with ESMTP id 0D5D2A8 for ; Fri, 19 Nov 2004 13:57:00 -0500 (EST) Received: from no.name.available by dofw1.net.treas.gov via smtpd (for mailhub.treas.gov [172.25.25.250]) with ESMTP; Fri, 19 Nov 2004 13:56:34 -0500 Received: from msbr02.do.treas.gov ([10.75.16.56]) by vms.do.treas.gov (PMDF V6.2 #41007) with ESMTP id <01LHF5YVTL0G8Y57QR@vms.do.treas.gov> for asrg@ietf.org; Fri, 19 Nov 2004 13:56:08 -0500 (EST) Received: by msbr02.do.treas.gov with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Nov 2004 13:56:58 -0500 Content-return: allowed Date: Fri, 19 Nov 2004 13:56:57 -0500 To: asrg@ietf.org Message-id: <390D47AD88C6FA4B8B56DAF65F0A28050786B35F@ms04.do.treas.gov> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Asrg] draft-irtf-asrg-dnsbl-01.txt X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1819272014==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1819272014== Content-return: allowed Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C4CE69.8B46BF0C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CE69.8B46BF0C Content-Type: text/plain Reading the above mentioned draft, may I play Devil's Advocate for a minute? First, let me preface that I am new to the group. Forgive any stupid comments that I may make and credit them to ignorance. My comment regards 2, the DNS entry. Knowing that spammers are thinking of ways to get around blocks, is the following a possible scenario? If the IP number is: 192.2.2.3, with a domain of "bad.example.com", the DNS entry would be: 3.2.2.192.bad.example.com. I understand that without a problem. Suppose, just for grins (or panic), that the spammer adds lower level domains and has a domain name of: 4.5.6.192.bad.example.com. Keeping the IP number from the example above, the DNS entry would be: 3.2.2.192.4.5.6.192.bad.example.com. Would this pose a problem? I know that this may be a wild scenario, but think about some of the e-mail addresses that are used for Spam now, this may not be that outrageous. Gary Allmond ------_=_NextPart_001_01C4CE69.8B46BF0C Content-Type: text/html

Reading the above mentioned draft, may I play Devil's Advocate for a minute?

 

First, let me preface that I am new to the group. Forgive any stupid comments that I may make and credit them to ignorance.

 

My comment regards 2, the DNS entry. Knowing that spammers are thinking of ways to get around blocks, is the following a possible scenario?

 

If the IP number is: 192.2.2.3, with a domain of "bad.example.com", the DNS entry would be: 3.2.2.192.bad.example.com. I understand that without a problem. Suppose, just for grins (or panic), that the spammer adds lower level domains and has a domain name of: 4.5.6.192.bad.example.com. Keeping the IP number from the example above, the DNS entry would be: 3.2.2.192.4.5.6.192.bad.example.com. Would this pose a problem? I know that this may be a wild scenario, but think about some of the e-mail addresses that are used for Spam now, this may not be that outrageous.

 

Gary Allmond

------_=_NextPart_001_01C4CE69.8B46BF0C-- --===============1819272014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1819272014==-- From asrg-bounces@ietf.org Fri Nov 19 15:00:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07308 for ; Fri, 19 Nov 2004 15:00:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEyC-0005IP-S1 for asrg-web-archive@ietf.org; Fri, 19 Nov 2004 15:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVEpH-00031G-RH; Fri, 19 Nov 2004 14:53:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVEhw-0001CG-A1 for asrg@megatron.ietf.org; Fri, 19 Nov 2004 14:46:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06108 for ; Fri, 19 Nov 2004 14:46:10 -0500 (EST) Received: from sc1.scconsult.com ([66.73.230.190] helo=toaster.scconsult.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEkp-0004uk-7E for asrg@ietf.org; Fri, 19 Nov 2004 14:49:11 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id 84A9630CD2D for ; Fri, 19 Nov 2004 14:45:57 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <390D47AD88C6FA4B8B56DAF65F0A28050786B35F@ms04.do.treas.gov> References: <390D47AD88C6FA4B8B56DAF65F0A28050786B35F@ms04.do.treas.gov> Date: Fri, 19 Nov 2004 14:45:45 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] draft-irtf-asrg-dnsbl-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 1:56 PM -0500 11/19/04, Gary.Allmond@do.treas.gov imposed structure on a stream of electrons, yielding: >Reading the above mentioned draft, may I play Devil's Advocate for a minute? > >First, let me preface that I am new to the group. Forgive any stupid >comments that I may make and credit them to ignorance. > >My comment regards 2, the DNS entry. Knowing that spammers are >thinking of ways to get around blocks, is the following a possible >scenario? > >If the IP number is: 192.2.2.3, with a domain of "bad.example.com", >the DNS entry would be: 3.2.2.192.bad.example.com. I understand that >without a problem. Suppose, just for grins (or panic), that the >spammer adds lower level domains and has a domain name of: >4.5.6.192.bad.example.com. Keeping the IP number from the example >above, the DNS entry would be: 3.2.2.192.4.5.6.192.bad.example.com. >Would this pose a problem? I know that this may be a wild scenario, >but think about some of the e-mail addresses that are used for Spam >now, this may not be that outrageous. I think you've misunderstood the document's description of DNSBL entries. DNSBL's are not (generally) run by spammers, but by people providing identification of network space used by spammers and sometimes to do other things like identifying address space owned by particular netowrk operators or allocated into particular countries. DNSBL entries do not exist underneath a spammer's DNS zone, but under a zone controlled by the DNSBL operator. Using an existing DNSBL as an example, the entries in the Spamhaus XBL look like "3.2.2.192.xbl.spamhaus.org." A DNSBL entry is completely unrelated to what the reverse DNS (i.e. PTR record under in-addr.arpa) for an IP address is. -- Bill Cole bill@scconsult.com Clues for the blacklisted: http://www.scconsult.com/bill/dnsblhelp.html _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 20 20:18:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14185 for ; Sat, 20 Nov 2004 20:18:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVgQ2-0002K6-Qb for asrg-web-archive@ietf.org; Sat, 20 Nov 2004 20:21:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVgJn-0007AK-8k; Sat, 20 Nov 2004 20:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVgEY-0006Cv-34 for asrg@megatron.ietf.org; Sat, 20 Nov 2004 20:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13741 for ; Sat, 20 Nov 2004 20:09:40 -0500 (EST) Received: from rockridge.uits.indiana.edu ([129.79.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVgHW-0002BS-Jl for asrg@ietf.org; Sat, 20 Nov 2004 20:12:57 -0500 Received: from mail-relay.iu.edu (logchain.uits.indiana.edu [129.79.1.77]) by rockridge.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id iAL19NQU005474 for ; Sat, 20 Nov 2004 20:09:23 -0500 (EST) Received: from [10.0.2.2] (dial-64-151-129-215.bton.kiva.net [64.151.129.215]) (authenticated bits=0) by mail-relay.iu.edu (8.12.10/8.12.10/IUPO) with ESMTP id iAL19Jg3013646 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 20 Nov 2004 20:09:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) To: ASRG Message-Id: From: Jim Witte Date: Sat, 20 Nov 2004 20:09:18 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Asrg] [Q] Malformed Spam.. On the rise?? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1887743243==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac --===============1887743243== Content-Type: multipart/alternative; boundary=Apple-Mail-1-285590466 --Apple-Mail-1-285590466 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, I just got this spam, which is *massively* malformed HTML. Is this becoming more common, because the spam-bot writers are getting stupider, or are intervening MTA's trying to cut the spam out but are not doing a good enough job? Jim > From: jcaudills@priestbusters.com > Date: November 20, 2004 12:53:37 PM EST > > SMTPSVC(5.0.2195.6713); > Sun, 21 Nov 2004 03:49:18 -0400 > Message-ID: > From: "Rosemarie Norton" > To: jamesm@bloomington.in.us > Subject: Some Things 2 Get Before U Go To Vegas > Date: Sun, 21 Nov 2004 01:50:18 -0600 > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="--2846486998687197970" > > ----2846486998687197970 > Content-Type: text/plain; > Content-Transfer-Encoding: quoted-printable > > Selling every prescription u can think of! > http://www.barbarism8scarfs.inf= > o/?Q0yG/f=3D0/yjVu/oaNeq > > > assassin exterminate mezzo lucretia sutton macromolecular tab ogle > cambric= > calligraph=20 > > ----2846486998687197970-- > > Jim --Apple-Mail-1-285590466 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit 0000,0000,0000Hi, I just got this spam, which is *massively* malformed HTML. Is this becoming more common, because the spam-bot writers are getting stupider, or are intervening MTA's trying to cut the spam out but are not doing a good enough job? Jim0000,0000,0000 0000,0000,0000From: jcaudills@priestbusters.com 0000,0000,0000Date: November 20, 2004 12:53:37 PM EST SMTPSVC(5.0.2195.6713); Sun, 21 Nov 2004 03:49:18 -0400 Message-ID: < From: "Rosemarie Norton" < To: jamesm@bloomington.in.us Subject: Some Things 2 Get Before U Go To Vegas Date: Sun, 21 Nov 2004 01:50:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2846486998687197970" ----2846486998687197970 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Selling every prescription u can think of! http://www.barbarism8scarfs.inf= o/?Q0yG/f=3D0/yjVu/oaNeq assassin exterminate mezzo lucretia sutton macromolecular tab ogle cambric= calligraph=20 ----2846486998687197970-- Jim --Apple-Mail-1-285590466-- --===============1887743243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1887743243==-- From asrg-bounces@ietf.org Sun Nov 21 20:44:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15638 for ; Sun, 21 Nov 2004 20:44:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW3Iz-00008L-Mm for asrg-web-archive@ietf.org; Sun, 21 Nov 2004 20:47:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW3Bq-0007aH-Kt; Sun, 21 Nov 2004 20:40:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW3B3-0007Rt-SM for asrg@megatron.ietf.org; Sun, 21 Nov 2004 20:39:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15421 for ; Sun, 21 Nov 2004 20:39:33 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW3EN-0008VW-1Y for asrg@ietf.org; Sun, 21 Nov 2004 20:43:03 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CW3Ay-00081S-00 for ; Mon, 22 Nov 2004 02:39:32 +0100 Received: from 212.82.251.36 ([212.82.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 02:39:32 +0100 Received: from nobody by 212.82.251.36 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 02:39:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 22 Nov 2004 02:38:42 +0100 Organization: Lines: 10 Message-ID: <41A14322.32CE@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.36 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: [Q] Malformed Spam.. On the rise?? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Jim Witte wrote: > I just got this spam, which is *massively* malformed HTML. There's no HTML at all in it, you got a single text/plain part within multipart/alternative. Just like an election with only one candidate it's boring but not "malformed". For more details see RfC 2046 chapter 5.1.4. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 22 09:54:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03970 for ; Mon, 22 Nov 2004 09:54:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFdl-00083f-T5 for asrg-web-archive@ietf.org; Mon, 22 Nov 2004 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFTH-0004h9-R4; Mon, 22 Nov 2004 09:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFN9-0003cG-Jy for asrg@megatron.ietf.org; Mon, 22 Nov 2004 09:40:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03160 for ; Mon, 22 Nov 2004 09:40:54 -0500 (EST) From: aseem_jakhar@persistent.co.in Received: from smtp.persistent.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFQQ-0007Il-TF for asrg@ietf.org; Mon, 22 Nov 2004 09:44:30 -0500 Received: from webmail.persistent.co.in (webmail.pspl.co.in [202.54.11.103]) (authenticated bits=0) by smtp.pspl.co.in (8.12.9/8.12.9) with ESMTP id iAMEeJk1027296; Mon, 22 Nov 2004 20:10:20 +0530 Received: from 203.199.147.2 (SquirrelMail authenticated user aseem_jakhar) by webmail.persistent.co.in with HTTP; Mon, 22 Nov 2004 20:14:50 +0530 (IST) Message-ID: <36937.203.199.147.2.1101134690.squirrel@webmail.persistent.co.in> In-Reply-To: <41A14322.32CE@xyzzy.claranet.de> References: <41A14322.32CE@xyzzy.claranet.de> Date: Mon, 22 Nov 2004 20:14:50 +0530 (IST) Subject: Re: [Asrg] Re: [Q] Malformed Spam.. On the rise?? To: "Frank Ellermann" User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit > >> I just got this spam, which is *massively* malformed HTML. > > There's no HTML at all in it, you got a single text/plain > part within multipart/alternative. Just like an election > with only one candidate it's boring but not "malformed". It is a malformed mail because the part after the Date header will be shown as message body and will not be parsed for header contents. > From: jcaudills@priestbusters.com > Date: November 20, 2004 12:53:37 PM EST > > SMTPSVC(5.0.2195.6713); > Sun, 21 Nov 2004 03:49:18 -0400 > Message-ID: This usually happens with newbie spammers. - Aseem Jakhar _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Nov 26 10:38:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19455 for ; Fri, 26 Nov 2004 10:38:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiFl-0003zb-GH for asrg-web-archive@ietf.org; Fri, 26 Nov 2004 10:43:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi44-0007It-7m; Fri, 26 Nov 2004 10:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhnR-0005C2-FN for asrg@megatron.ietf.org; Fri, 26 Nov 2004 10:14:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27985 for ; Fri, 26 Nov 2004 06:10:44 -0500 (EST) Received: from guttormur.frisk-software.com ([213.220.100.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXe4F-0005uK-La for asrg@ietf.org; Fri, 26 Nov 2004 06:15:12 -0500 Received: by guttormur.frisk-software.com (Postfix, from userid 517) id 7948C3816A; Fri, 26 Nov 2004 11:10:00 +0000 (GMT) Received: from pc28.frisk-software.com. (pc28.frisk-software.com [172.16.5.2]) by guttormur.frisk-software.com (Postfix) with ESMTP id 296B4381BF for ; Fri, 26 Nov 2004 11:10:00 +0000 (GMT) Received: by pc28.frisk-software.com. (8.11.6/client-1.3) id iAQBA0F19457; Fri, 26 Nov 2004 11:10:00 GMT Date: Fri, 26 Nov 2004 11:10:00 +0000 From: Fridrik Skulason To: asrg@ietf.org Message-ID: <20041126111000.GU31887@f-prot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Asrg] "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 My own definition of "spam" is pretty broad, not just UCE, but pretty much any unwanted crap in my mailbox. In particular that includes worms as well as worm-generated bounces and other mail directly or indirectly created as a result of computer worm activity. As everyone probably knows, there is a pretty large outbreak going on right now. According to our mail filters at http://aves.f-prot.com, 10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, there is a significant number of bounces as well. According to my definition that is "spam" - and even those who prefer a more narrow definition should at least agree that this is unsolicited and unwanted. I have said before that universal adoption of SPF would kill off the current generation of worms (and that includes Sober.J) - however, there are a few points worth noting. * We (f-prot.com) published a SPF record, with -all. I am not going discuss the possible problems with that policy, but we did evaluate the advantages and disadvantages. Hopefully someone has rejected some worms based on that policy - however, we are getting plenty of "bounces" from domains that obviously have not implemented SPF checking. * Some of the domains that send us those bounces have published SPF records, which indicates they are aware of SPF, but for one reason or another they have decided not to implement SPF checking, so they continue to cause problems for everyone else with those bounces. * In fact, it is irrelevant how many domains publish SPF records. Even if every single domain had a record with "-all", it would not help one bit with the bounces. The reason is of course that what really matters is the number of domains that actually check SPF records and reject and drop mails that fail. * Even worse are the domains that do not bounce the message, but analyze it and reply with a message like "MDaemon Warning - virus found". Sending such messages is completely unacceptable behaviour. Most "current generation" worms forge the sender's address, and a mail filter that replies to the "From:" line with a warning of this kind is worse than useless - it is a part of the problem, not a part of the solution as it is generating spam (under my own broad definition of "spam", as mentioned earlier). So, the bottom line regarding worm-spam and SPF is: * Publishing SPF records may reduce the number of worm bounce messages, but that depends on the number of other domains checking the records. * Doing SPF checking will block the vast majority of the worms, but it will not help with the bounces or the filter alerts. * Too many domains have incorrectly configured mail filters that reply with an alert to the (forged) sender's address when they find a worm. That behaviour is just not acceptable - if fact, I urge everyone receiving a message telling them (incorrectly) that they sent out a worm to contact the domain sending out that alert and inform them that their mail filters are incorrectly configured. My own standard reply follows....feel free to use that for inspiration ---- start of reply ---- Your automated software just sent me the message below, where you are basically accusing me of sending you a virus. I must express my displeasure, and insist that you fix the problem. The virus in question forges the "From:" field. The sender can be anyone, and even a cursory check of the envelope address should reveal that the mail originated elsewhere. Incorrectly accusing people of spreading viruses is not only impolite - it could potentially be a legal problem - no, I am not threatening to sue you for defamation, but someone else might. My advice is to reconfigure your mail filter not to send alerts to the "From:" address. If you do not, you should probably get legal advice on your policy. ---- end of reply ---- -- Fridrik Skulason Frisk Software International phone: +354-540-7400 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Nov 26 22:08:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23081 for ; Fri, 26 Nov 2004 22:08:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXt0y-0004bu-99 for asrg-web-archive@ietf.org; Fri, 26 Nov 2004 22:12:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXsjX-0000Og-Cq; Fri, 26 Nov 2004 21:54:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXsjQ-0000J7-Qn for asrg@megatron.ietf.org; Fri, 26 Nov 2004 21:54:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22156 for ; Fri, 26 Nov 2004 21:54:39 -0500 (EST) Received: from linuxbox.org ([24.155.83.21] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXsnp-00043E-QQ for asrg@ietf.org; Fri, 26 Nov 2004 21:59:14 -0500 Received: from [192.115.22.106] (prometheus.solaris.org.il [192.115.22.106]) (authenticated bits=0) by linuxbox.org (8.12.11/8.12.11/Debian-3) with ESMTP id iAR2rgb5007059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Nov 2004 20:53:44 -0600 Message-ID: <41A7EDBF.9030207@linuxbox.org> Date: Sat, 27 Nov 2004 05:00:15 +0200 From: Gadi Evron User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fridrik Skulason Subject: Re: [Asrg] "worm spam" and SPF References: <20041126111000.GU31887@f-prot.com> In-Reply-To: <20041126111000.GU31887@f-prot.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on linuxbox.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit > As everyone probably knows, there is a pretty large outbreak going on > right now. According to our mail filters at http://aves.f-prot.com, > 10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, > there is a significant number of bounces as well. We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV calls it Sober.I@mm. I agree, bounces are the very evil of the net itself. Where I'd have to disagree is here: > * Doing SPF checking will block the vast majority of the worms, but it > will not help with the bounces or the filter alerts. It may block the vast majority of current worms, but I doubt it would stop the tide for long. VX-ers will find other ways of abusing infected victims.. they might even send out email using the user's own email account and/or email client. As long as there are huge drone armies out there, and their likes - I don't see how spam solutions today would really work as people hope. They will help reduce the numbers by a 0 or two though (if widely implemented in a reasonable period of time). I may actually get hundreds instead of thousands of spam messages a day. Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Nov 26 22:33:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25328 for ; Fri, 26 Nov 2004 22:33:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXtP8-0005gP-Fv for asrg-web-archive@ietf.org; Fri, 26 Nov 2004 22:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXtIc-0006AA-Ne; Fri, 26 Nov 2004 22:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXtGi-0005vI-0J for asrg@megatron.ietf.org; Fri, 26 Nov 2004 22:29:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25116 for ; Fri, 26 Nov 2004 22:29:02 -0500 (EST) Received: from mx1.cloudmark.com ([63.80.128.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXtL4-0005Ys-1d for asrg@ietf.org; Fri, 26 Nov 2004 22:33:37 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Asrg] "worm spam" and SPF Date: Fri, 26 Nov 2004 19:28:33 -0800 Message-ID: Thread-Topic: [Asrg] "worm spam" and SPF Thread-Index: AcTULmAe24+8JBgyQ2WU4Ue3EAWG1wAARS8p From: "Vipul Ved Prakash" To: "Gadi Evron" , "Fridrik Skulason" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0984020929==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 This is a multi-part message in MIME format. --===============0984020929== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D431.2C85B105" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D431.2C85B105 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The worm attack on authentication schemes is a particularly bad one. I = have recently joined the list, so I apologize if this has been discussed = previously. But consider the following scenario: A new worm come out = that uses infected machine's designated servers to send out mail. Say = these mail servers have a SPF or DK record and further they enjoy good = reputations on the various reputation services (since they mostly send = out good mail). The recipient machines do a SPF/DK check, it passes, = they lookup the reputation, which checks out too, and deliver the mail = bypassing all content-based filtration sub-systems. The recipient = systems get infected. The smarter users start reporting the worm to = reputation services, who in turn punish the senders. After a while the = senders reputation drops so much that they are unable to send out legit = mail.=20 This is bit of an extreme scenario, but a plausable one. Once it = happens, spammers will adopt it and change the payload (worm + spam).=20 cheers, vipul -----Original Message----- From: asrg-bounces@ietf.org on behalf of Gadi Evron Sent: Fri 11/26/2004 7:00 PM To: Fridrik Skulason Cc: asrg@ietf.org Subject: Re: [Asrg] "worm spam" and SPGF =20 > As everyone probably knows, there is a pretty large outbreak going on=20 > right now. According to our mail filters at http://aves.f-prot.com, > 10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, > there is a significant number of bounces as well. =20 We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV=20 calls it Sober.I@mm. I agree, bounces are the very evil of the net itself. Where I'd have to disagree is here: > * Doing SPF checking will block the vast majority of the worms, but = it > will not help with the bounces or the filter alerts. It may block the vast majority of current worms, but I doubt it would=20 stop the tide for long. VX-ers will find other ways of abusing infected victims.. they might=20 even send out email using the user's own email account and/or email = client. As long as there are huge drone armies out there, and their likes - I=20 don't see how spam solutions today would really work as people hope.=20 They will help reduce the numbers by a 0 or two though (if widely=20 implemented in a reasonable period of time). I may actually get hundreds = instead of thousands of spam messages a day. Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg ------_=_NextPart_001_01C4D431.2C85B105 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Asrg] "worm spam" and SPF

The worm attack on authentication schemes is a = particularly bad one. I have recently joined the list, so I apologize if = this has been discussed previously. But consider the following scenario: = A new worm come out that uses infected machine's designated servers to = send out mail.  Say these mail servers have a SPF or DK record and = further they enjoy good reputations on the various reputation services = (since they mostly send out good mail). The recipient machines do a = SPF/DK check, it passes, they lookup the reputation, which checks out = too, and deliver the mail bypassing all content-based filtration = sub-systems. The recipient systems get infected.  The smarter users = start reporting the worm to reputation services, who in turn punish the = senders. After a while the senders reputation drops so much that they = are unable to send out legit mail.

This is bit of an extreme scenario, but a plausable one. Once it = happens, spammers will adopt it and change the payload (worm + = spam).

cheers,
vipul

-----Original Message-----
From: asrg-bounces@ietf.org on behalf of Gadi Evron
Sent: Fri 11/26/2004 7:00 PM
To: Fridrik Skulason
Cc: asrg@ietf.org
Subject: Re: [Asrg] "worm spam" and SPGF

> As everyone probably knows, there is a pretty large outbreak going = on
> right now. According to our mail filters at http://aves.f-prot.com,
> 10.56% of all filtered E-mail contains W32/Sober.J@mm.  In = addition,
> there is a significant number of bounces as well. 

We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV
calls it Sober.I@mm.

I agree, bounces are the very evil of the net itself.

Where I'd have to disagree is here:

 > * Doing SPF checking will block the vast majority of the = worms, but it
 >   will not help with the bounces or the filter = alerts.

It may block the vast majority of current worms, but I doubt it = would
stop the tide for long.
VX-ers will find other ways of abusing infected victims.. they might
even send out email using the user's own email account and/or email = client.

As long as there are huge drone armies out there, and their likes - = I
don't see how spam solutions today would really work as people hope.
They will help reduce the numbers by a 0 or two though (if widely
implemented in a reasonable period of time). I may actually get = hundreds
instead of thousands of spam messages a day.

        Gadi.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.or= g/mailman/listinfo/asrg

------_=_NextPart_001_01C4D431.2C85B105-- --===============0984020929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0984020929==-- From asrg-bounces@ietf.org Fri Nov 26 22:55:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26752 for ; Fri, 26 Nov 2004 22:55:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXtkw-0006Ui-KR for asrg-web-archive@ietf.org; Fri, 26 Nov 2004 23:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXtde-0008My-Gp; Fri, 26 Nov 2004 22:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXta6-0007mk-Ll for asrg@megatron.ietf.org; Fri, 26 Nov 2004 22:49:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26315 for ; Fri, 26 Nov 2004 22:49:04 -0500 (EST) Received: from www.scconsult.com ([66.73.230.185] helo=toaster.scconsult.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXteW-0006Cq-0i for asrg@ietf.org; Fri, 26 Nov 2004 22:53:40 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id D1EA234E0DC for ; Fri, 26 Nov 2004 22:48:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41A7EDBF.9030207@linuxbox.org> References: <20041126111000.GU31887@f-prot.com> <41A7EDBF.9030207@linuxbox.org> Date: Fri, 26 Nov 2004 22:48:21 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] "worm spam" and SPF Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc At 5:00 AM +0200 11/27/04, Gadi Evron wrote: >>As everyone probably knows, there is a pretty large outbreak going >>on right now. According to our mail filters at >>http://aves.f-prot.com, >>10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, >>there is a significant number of bounces as well. > >We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV >calls it Sober.I@mm. > >I agree, bounces are the very evil of the net itself. No, they are not. They are a critically important part of the robustness of email. Broad acceptance of the idea that bounces are evil will be the last nail in the coffin of email. Systems which generate bounces as a result of determining that particular messages are untrustworthy are evil. Software which determines that mail is spam (or viral, which is logically a subset of spam) and then goes on to trust that mail enough to generate a bounce message is designed by people who are either evil or stupid enough to be indistinguishable from evil. >Where I'd have to disagree is here: > >> * Doing SPF checking will block the vast majority of the worms, but it >> will not help with the bounces or the filter alerts. > >It may block the vast majority of current worms, but I doubt it >would stop the tide for long. >VX-ers will find other ways of abusing infected victims.. they might >even send out email using the user's own email account and/or email >client. Uh, have you heard of Swen??? Viruses are already using the victim machine's mailer configuration to send mail. They have been doing so for a year and more. The problem is deep design flaws in Microsoft's mailers and operating system. The problem is Microsoft. >As long as there are huge drone armies out there, and their likes - >I don't see how spam solutions today would really work as people >hope. They will help reduce the numbers by a 0 or two though (if >widely implemented in a reasonable period of time). I may actually >get hundreds instead of thousands of spam messages a day. I reject about 10,000 port 25 connection attempts ever day from various parts of the net that I believe to house no valid correspondents and to house an inordinate number of zombies and machines owned 'legitimately' by slimeballs like Alan Ralsky, Scott Richter, Verisign, DoubleClick, and other untrustworthy, deceptive, spamming entities. The domains behind that router house less than a dozen distinct mail receivers. I reject a few thousand spam attempts daily in SMTP based on the IP address of the connecting system. Most of that is done by rejecting machines which have been seen by others to be spam and worm zombies (Spamhaus XBL) or which are in networks I've seen machines trying to deliver in zombie-like ways. 95%+ of the mail delivered here is not spam. 99%+ of the attempts to send mail here are spam, much via zombie armies. Killing the zombie armies would let me move some router blocking back to SMTP and reduce some SMTP blocking. Global SPF adoption would kill off today's zombie armies, but with Swen out there as an example, that would be a brief respite. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 12:28:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06936 for ; Sat, 27 Nov 2004 12:28:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY6RK-0002xN-9k for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 12:32:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6Fo-0005km-2D; Sat, 27 Nov 2004 12:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY64N-0001Ca-Q1 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 12:09:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05175 for ; Sat, 27 Nov 2004 05:15:10 -0500 (EST) Received: from guttormur.frisk-software.com ([213.220.100.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXzgD-0003Ny-V3 for asrg@ietf.org; Sat, 27 Nov 2004 05:19:50 -0500 Received: by guttormur.frisk-software.com (Postfix, from userid 517) id A3FB5380B6; Sat, 27 Nov 2004 10:14:38 +0000 (GMT) Received: from pc28.frisk-software.com. (pc28.frisk-software.com [172.16.5.2]) by guttormur.frisk-software.com (Postfix) with ESMTP id CD67538015 for ; Sat, 27 Nov 2004 10:14:37 +0000 (GMT) Received: by pc28.frisk-software.com. (8.11.6/client-1.3) id iARAEdr25710; Sat, 27 Nov 2004 10:14:39 GMT Date: Sat, 27 Nov 2004 10:14:39 +0000 From: Fridrik Skulason To: asrg@ietf.org Subject: Re: [Asrg] "worm spam" and SPF] Message-ID: <20041127101439.GG31887@f-prot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > No, they are not. They are a critically important part of the > robustness of email. Broad acceptance of the idea that bounces are > evil will be the last nail in the coffin of email. Bounces are useful if they go to the person who actually sent the mail. Those "bounces" do not - they go to an innocent bystander. Whether this is due to inherent flaws in the SMTP protocol, sloppy management or incorrect configuration is arguable - but the fact is that those bounces are making the problem worse and they NEED to be eliminated. >Uh, have you heard of Swen??? Swen is NOT an example of the behaviour being discussed. Most worms harvest e-mail addresses from the infected machine, and typically select one of them at random as the sender. This can of course result in the worm sending itself out as being from the "actual" owner of the machine - however, usually this is not the case. Swen typically pretended to be from "MS Technical Support" or something like that. As far as I know, there is not a single worm in the wild that searches for the "real" owner of the infected machine and *only* uses that. I expect that practice to become more common in the future, as one way of avoiding SPF checking, but currently this is simply not the case. -- Fridrik Skulason Frisk Software International phone: +354-540-7400 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 12:35:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07637 for ; Sat, 27 Nov 2004 12:35:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY6YV-0003Gc-SK for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 12:40:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6GZ-00074y-S4; Sat, 27 Nov 2004 12:21:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY66I-0001Z0-ST for asrg@megatron.ietf.org; Sat, 27 Nov 2004 12:11:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08521 for ; Sat, 27 Nov 2004 01:54:53 -0500 (EST) Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXwYM-0004p0-RZ for asrg@ietf.org; Sat, 27 Nov 2004 01:59:32 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id CE8F4981AD for ; Sat, 27 Nov 2004 01:54:53 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id iAR6scF14204; Sat, 27 Nov 2004 01:54:38 -0500 (EST) Date: Sat, 27 Nov 2004 01:54:38 -0500 (EST) Message-Id: <200411270654.iAR6scF14204@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: <20041126111000.GU31887@f-prot.com> (message from Fridrik Skulason on Fri, 26 Nov 2004 11:10:00 +0000) Subject: Re: [Asrg] "worm spam" and SPF References: <20041126111000.GU31887@f-prot.com> X-Spam-Score: 1.6 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Fridrik Skulason wrote: > My own definition of "spam" is a concept that makes spam-fighting worthless and undefinable. Consider that spammers all define spam as what they don't do. There is one agreed definition (in the email area): Unsolicited Bulk Email. > is pretty broad, not just UCE, but pretty much > any unwanted crap in my mailbox. If the bully who picked on you in fifth grade found your email address and started picking on you in email, that would be unwanted crap, but it wouldn't be spam. On the other hand, "Jesus Is Coming Soon (Look Busy!)" sent to 50 million email addresses isn't commercial, but is spam. > In particular that includes worms as well as worm-generated bounces > and other mail directly or indirectly created as a result of > computer worm activity. Unsolicited, surely. Bulk, unless it's an individual worm (in which case it isn't a worm), yes. Email, yes. Hence spam; no need for a private definition. > I have said before that universal adoption of SPF would kill off the > current generation of worms (and that includes Sober.J) 1. "universal adoption" is part of being a FUSSP. 2. The next generation would just be more careful about who they claimed to be. > * Some of the domains that send us those bounces have published SPF > records, which indicates they are aware of SPF, but for one reason > or another they have decided not to implement SPF checking, so > they continue to cause problems for everyone else with those > bounces. At this point, strong SPF checking breaks too much stuff (especially forwarding). Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 12:38:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07914 for ; Sat, 27 Nov 2004 12:38:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY6bU-0003P6-OJ for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 12:43:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6Gh-0007JO-87; Sat, 27 Nov 2004 12:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY66M-0001Z0-FZ for asrg@megatron.ietf.org; Sat, 27 Nov 2004 12:11:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26228 for ; Sat, 27 Nov 2004 03:03:03 -0500 (EST) Received: from linuxbox.org ([24.155.83.21] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXxcI-00070H-Dc for asrg@ietf.org; Sat, 27 Nov 2004 03:07:40 -0500 Received: from [192.115.22.106] (prometheus.solaris.org.il [192.115.22.106]) (authenticated bits=0) by linuxbox.org (8.12.11/8.12.11/Debian-3) with ESMTP id iAR81wWP009564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Nov 2004 02:02:30 -0600 Message-ID: <41A835F7.8010706@linuxbox.org> Date: Sat, 27 Nov 2004 10:08:23 +0200 From: Gadi Evron User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vipul Ved Prakash Subject: Re: [Asrg] "worm spam" and SPF References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on linuxbox.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org, Fridrik Skulason X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Vipul Ved Prakash wrote: > The worm attack on authentication schemes is a particularly bad one. I have recently joined the list, so I apologize if this has been discussed previously. But consider the following scenario: A new worm come out that uses infected machine's designated servers to send out mail. Say these mail servers have a SPF or DK record and further they enjoy good reputations on the various reputation services (since they mostly send out good mail). The recipient machines do a SPF/DK check, it passes, they lookup the reputation, which checks out too, and deliver the mail bypassing all content-based filtration sub-systems. The recipient systems get infected. The smarter users start reporting the worm to reputation services, who in turn punish the senders. After a while the senders reputation drops so much that they are unable to send out legit mail. > > This is bit of an extreme scenario, but a plausable one. Once it happens, spammers will adopt it and change the payload (worm + spam). Actually, it usually goes that way today. Spammers use many methods to send out their annoying viagra email messages. They mostly rely on methods that allow them to send the spam out of somebody else's machine. Drone armies are just the next logical step, and it happened a few years ago. Last year, AV companies pretty much publicly ignored the existence of drone armies. A couple of us kept yelling "wolf" and indeed - this year, they are all finally jumping on the PR wagon. This time not with a new worm they can hype the death out of, but with an actual threat. They are still rather careful with their estimates.. I just read on CSI that SYMC saw 20,000 drones at one time, together. Fact of the matter is, that we have seen 10K, 20K and a 100K drone armies (multiple) many times, and the fact that we are just now becoming publicly aware of it is silly. Spammers first became interested in this method of sending out s**t at around 1997. Cheap, expendable and in huge amounts - it was just calling to them. I remember one particular spammer who went on IRC to "help" users get "cured" in one of the many help channels over there (Trojan horses made their huge comeback on IRC at around 1996-7, not that they ever really disappeared). After learning the subject and investing in it, he disappeared. If I remember right he owned nekkidchicks.something. Whether they buy the collection from a kid (and believe me, the kids trade these like candy, as a friend of mine likes to comment), or collect them on their own - they have them. Trojan horse and worm development jumped a few notches up in direct link with spammers getting interested (there is the issue of organized crime, but it's off-topic, kinda). Nowadays most of these machines are on Cable/DSL lines, and most of them are infected with several "viruses" - making them members of several armies. Spammers now spam for two reasons: 1. Get their word out. 2. Find new users to infect who would get the word out. An example on Yahoo!: Yahoo! is one of the most uncaring provider there is when it comes to abuse. On Yahoo!, you can find huge amounts of infected machines who send you a URL of their own IP, which re-directs you to another URL with a Trojan horse, which in turn infects you and you go on Yahoo! doing the same. Spammers never get tired of collecting, and building a 10K drone army on Yahoo! would take just a few days. But we are discussing email, right? Thing is - even if every client/end user in the world would be able to send, say - 1000 legit messages before the ISP blocks it.. 1000 * 50000 * 365 * S (where 50000 is number of drones and S is number of spammers) is still a huge amount of spam per day. Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 12:39:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07975 for ; Sat, 27 Nov 2004 12:39:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY6bs-0003Pt-BB for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 12:43:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6Gp-0007R8-VN; Sat, 27 Nov 2004 12:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY66h-0001Z0-JF for asrg@megatron.ietf.org; Sat, 27 Nov 2004 12:11:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19903 for ; Sat, 27 Nov 2004 02:15:43 -0500 (EST) Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXwsX-0005QJ-6s for asrg@ietf.org; Sat, 27 Nov 2004 02:20:22 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 9E90C981C0 for ; Sat, 27 Nov 2004 02:15:44 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id iAR7FiJ12975; Sat, 27 Nov 2004 02:15:44 -0500 (EST) Date: Sat, 27 Nov 2004 02:15:44 -0500 (EST) Message-Id: <200411270715.iAR7FiJ12975@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (vipul@cloudmark.com) Subject: Re: [Asrg] "worm spam" and SPF References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 "Vipul Ved Prakash" wrote: [some MIME cruft elided] > But consider the following scenario: A new worm come out that uses > infected machine's designated servers to send out mail. Say these > mail servers have a SPF or DK record and further they enjoy good = > reputations on the various reputation services (since they mostly > send out good mail). The recipient machines do a SPF/DK check, it > passes, they lookup the reputation, which checks out too, and > deliver the mail bypassing all content-based filtration > sub-systems. The recipient systems get infected. The smarter > users start reporting the worm to reputation services, who in turn > punish the senders. After a while the senders reputation drops so > much that they are unable to send out legit mail. Therefore, an ISP (or other sender) that wishes to retain a good reputation will set its outgoing mailservers to check for the latest worms fairly soon after they're discovered, and throttle mail from any particular sender so not too many worms get out before they're learned about. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 13:12:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11657 for ; Sat, 27 Nov 2004 13:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY785-0004xD-Rl for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 13:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6t9-0007Ga-P3; Sat, 27 Nov 2004 13:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY6pu-0006rd-4F for asrg@megatron.ietf.org; Sat, 27 Nov 2004 12:58:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10424 for ; Sat, 27 Nov 2004 12:58:14 -0500 (EST) Received: from www.scconsult.com ([66.73.230.185] helo=toaster.scconsult.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY6uQ-0004Pz-Nf for asrg@ietf.org; Sat, 27 Nov 2004 13:02:59 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id 97363352203 for ; Sat, 27 Nov 2004 12:57:36 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041127101439.GG31887@f-prot.com> References: <20041127101439.GG31887@f-prot.com> Date: Sat, 27 Nov 2004 12:57:32 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] "worm spam" and SPF] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 At 10:14 AM +0000 11/27/04, Fridrik Skulason wrote: >> No, they are not. They are a critically important part of the >> robustness of email. Broad acceptance of the idea that bounces are >> evil will be the last nail in the coffin of email. > >Bounces are useful if they go to the person who actually sent the mail. >Those "bounces" do not - they go to an innocent bystander. Whether this >is due to inherent flaws in the SMTP protocol, sloppy management or >incorrect configuration is arguable - but the fact is that those bounces >are making the problem worse and they NEED to be eliminated. On that we agree: bounces should never be the result of some system deeming the bounced mail to be in some class that is typically malicious or deceptive, i.e. spam of any variety including Microsoft OS worm spam. >>Uh, have you heard of Swen??? > >Swen is NOT an example of the behaviour being discussed. Here was the specific context to which I was responding: they might even send out email using the user's own email account and/or email client. Swen does that. Really. >Most worms >harvest e-mail addresses from the infected machine, and typically >select one of them at random as the sender. This can of course result >in the worm sending itself out as being from the "actual" owner of the >machine - however, usually this is not the case. Swen typically >pretended to be from "MS Technical Support" or something like that. Only in the headers. The SMTP envelope of a Swen message is consistently the address configured into Outlook Express on the infected system, and the mail travels through the configured outbound mail server. This is reliable enough that Swen will break on systems where those configurations don't work. >As far as I know, there is not a single worm in the wild that searches >for the "real" owner of the infected machine and *only* uses that. I >expect that practice to become more common in the future, as one way >of avoiding SPF checking, but currently this is simply not the case. Keep in mind that SPF has nothing to do with headers, and is solely for SMTP envelope checking. I still see a trickle of Swen even though I shun machines transporting it, and SPF does nothing at all to stop it. For example, here's the latest Swen I have where the envelope sender domain had an SPF record: Return-Path: js.bennett@ntlworld.com Received: from mta05-winn.mailhost.ntl.com ([212.250.162.8] verified) by sc1.scconsult.com (Stalker SMTP Server 1.8b9d14) with ESMTP id S.0000707800 for ; Mon, 15 Nov 2004 12:19:11 -0500 Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20041115171908.TIIG3998.mta05-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Mon, 15 Nov 2004 17:19:08 +0000 Received: from itmup ([62.255.124.16]) by aamta04-winn.mailhost.ntl.com with SMTP id <20041115171835.PROX6712.aamta04-winn.mailhost.ntl.com@itmup>; Mon, 15 Nov 2004 17:18:35 +0000 FROM: "Network Message Storage Service" TO: "inet client" SUBJECT: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="qielpyeqr" Message-Id: <20041115171835.PROX6712.aamta04-winn.mailhost.ntl.com@itmup> Date: Mon, 15 Nov 2004 17:19:08 +0000 The relevant SPF record: ntlworld.com. 43200 IN TXT "v=spf1 ip4:212.250.162.0/26 ip4:62.253.162.0/24 ?all" -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 14:22:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15722 for ; Sat, 27 Nov 2004 14:22:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8Dj-0007Nd-Cj for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 14:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY863-0006FC-JX; Sat, 27 Nov 2004 14:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY84S-0005t3-W7 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 14:17:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15364 for ; Sat, 27 Nov 2004 14:17:21 -0500 (EST) Message-Id: <200411271917.OAA15364@ietf.org> Received: from mail6.speakeasy.net ([216.254.0.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY88z-00079d-RQ for asrg@ietf.org; Sat, 27 Nov 2004 14:22:06 -0500 Received: (qmail 10597 invoked from network); 27 Nov 2004 19:17:15 -0000 Received: from dsl081-214-187.nyc2.dsl.speakeasy.net (HELO elliot) (lseltzer@[64.81.214.187]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Nov 2004 19:17:15 -0000 From: "Larry Seltzer" To: Subject: RE: [Asrg] "worm spam" and SPF] Date: Sat, 27 Nov 2004 14:14:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTUrFk/7hJJ8FvBTQOaU/ZApIXPhwABWs5g X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit >>Here was the specific context to which I was responding: >>>> they might even send out email using the user's own email >>>> account and/or email client. >>Swen does that. Really. No, it doesn't. Different versions of Swen do different things to get an SMTP server to use, but they all use a built-in SMTP engine and none of them use SMTP AUTH account information. In some circumstances Swen will put up a fake MAPI32 exception handler that asks you for your email account server, username and password (see a copy at http://www.trendmicro.com/vinfo/images/worm_swen_a_img2.gif). According to Symantec (http://securityresponse.symantec.com/avcenter/venc/data/w32.swen.a@mm.h tml) Swen uses the username and password to check the POP3 account for copies of itself. So Swen might use the default SMTP server (harvested from the registry), but that's as close as it gets to using the user's own e-mail account. How would a worm work if everyone had SMTP AUTH? It would either have to use a social engineering trick like Swen does with the MAPI32 dialog - and there's no evidence that there's a big problem with people filling out that form - or it would have to find the cached account credentials in the registry and use them. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer larryseltzer@ziffdavis.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 14:34:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16366 for ; Sat, 27 Nov 2004 14:34:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8P9-0007mJ-Ah for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 14:38:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8Id-0007Ke-Ae; Sat, 27 Nov 2004 14:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8Fw-00076o-5E for asrg@megatron.ietf.org; Sat, 27 Nov 2004 14:29:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16086 for ; Sat, 27 Nov 2004 14:29:12 -0500 (EST) Received: from mx1.cloudmark.com ([63.80.128.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8KS-0007au-TT for asrg@ietf.org; Sat, 27 Nov 2004 14:33:58 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Asrg] "worm spam" and SPF Date: Sat, 27 Nov 2004 11:28:47 -0800 Message-ID: Thread-Topic: [Asrg] "worm spam" and SPF Thread-Index: AcTUp/TgIjOQhZBGScav2TLN5NeVlwADoQl2 From: "Vipul Ved Prakash" To: "Seth Breidbart" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427339033==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. --===============1427339033== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D4B7.50B3D11A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D4B7.50B3D11A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nod. This moves the content filtration problem to a different=20 place: on the outgoing servers. If the only way to send out spam=20 is through drones, then all spammers will move to using drones.=20 The conclusion that I draw from this is that content filtration=20 techniques used on outbound mail would have to be of the same=20 level of sophistication as inbound filtration today.=20 cheers, vipul -----Original Message----- From: asrg-bounces@ietf.org on behalf of Seth Breidbart Sent: Fri 11/26/2004 11:15 PM To: asrg@ietf.org Subject: Re: [Asrg] "worm spam" and SPF =20 "Vipul Ved Prakash" wrote: [some MIME cruft elided] > But consider the following scenario: A new worm come out that uses > infected machine's designated servers to send out mail. Say these > mail servers have a SPF or DK record and further they enjoy good =3D > reputations on the various reputation services (since they mostly > send out good mail). The recipient machines do a SPF/DK check, it > passes, they lookup the reputation, which checks out too, and > deliver the mail bypassing all content-based filtration > sub-systems. The recipient systems get infected. The smarter > users start reporting the worm to reputation services, who in turn > punish the senders. After a while the senders reputation drops so > much that they are unable to send out legit mail. Therefore, an ISP (or other sender) that wishes to retain a good reputation will set its outgoing mailservers to check for the latest worms fairly soon after they're discovered, and throttle mail from any particular sender so not too many worms get out before they're learned about. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg ------_=_NextPart_001_01C4D4B7.50B3D11A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Asrg] "worm spam" and SPF

Nod. This moves the content filtration problem to a = different
place: on the outgoing servers. If the only way to send out spam
is through drones, then all spammers will move to using drones.
The conclusion that I draw from this is that content filtration
techniques used on outbound mail would have to be of the same
level of sophistication as inbound filtration today.

cheers,
vipul

-----Original Message-----
From: asrg-bounces@ietf.org on behalf of Seth Breidbart
Sent: Fri 11/26/2004 11:15 PM
To: asrg@ietf.org
Subject: Re: [Asrg] "worm spam" and SPF

"Vipul Ved Prakash" <vipul@cloudmark.com> wrote:

[some MIME cruft elided]

> But consider the following scenario: A new worm come out that = uses
> infected machine's designated servers to send out mail.  Say = these
> mail servers have a SPF or DK record and further they enjoy good = =3D
> reputations on the various reputation services (since they = mostly
> send out good mail). The recipient machines do a SPF/DK check, = it
> passes, they lookup the reputation, which checks out too, and
> deliver the mail bypassing all content-based filtration
> sub-systems. The recipient systems get infected.  The = smarter
> users start reporting the worm to reputation services, who in = turn
> punish the senders. After a while the senders reputation drops = so
> much that they are unable to send out legit mail.

Therefore, an ISP (or other sender) that wishes to retain a good
reputation will set its outgoing mailservers to check for the latest
worms fairly soon after they're discovered, and throttle mail from = any
particular sender so not too many worms get out before they're = learned
about.

Seth

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.or= g/mailman/listinfo/asrg

------_=_NextPart_001_01C4D4B7.50B3D11A-- --===============1427339033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1427339033==-- From asrg-bounces@ietf.org Sat Nov 27 14:38:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16752 for ; Sat, 27 Nov 2004 14:38:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8T0-0007un-RV for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 14:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8Lp-0007if-4f; Sat, 27 Nov 2004 14:35:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8JZ-0007Nc-N9 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 14:33:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16265 for ; Sat, 27 Nov 2004 14:32:57 -0500 (EST) Received: from linuxbox.org ([24.155.83.21] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8O6-0007hq-EB for asrg@ietf.org; Sat, 27 Nov 2004 14:37:43 -0500 Received: from [192.115.22.106] (prometheus.solaris.org.il [192.115.22.106]) (authenticated bits=0) by linuxbox.org (8.12.11/8.12.11/Debian-3) with ESMTP id iARJTkPf013236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Nov 2004 13:30:51 -0600 Message-ID: <41A8D724.4010902@linuxbox.org> Date: Sat, 27 Nov 2004 21:36:04 +0200 From: Gadi Evron User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Breidbart Subject: Re: [Asrg] "worm spam" and SPF References: <200411270715.iAR7FiJ12975@panix5.panix.com> In-Reply-To: <200411270715.iAR7FiJ12975@panix5.panix.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on linuxbox.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Seth Breidbart wrote: > Therefore, an ISP (or other sender) that wishes to retain a good > reputation will set its outgoing mailservers to check for the latest > worms fairly soon after they're discovered, and throttle mail from any > particular sender so not too many worms get out before they're learned > about. And you think that's easy? This is what the ENTIRE AV _industry_ is about... Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 14:43:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17237 for ; Sat, 27 Nov 2004 14:43:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8Xz-00087m-79 for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 14:47:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8RA-0008LD-GQ; Sat, 27 Nov 2004 14:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8PU-000882-51 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 14:39:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16863 for ; Sat, 27 Nov 2004 14:39:04 -0500 (EST) Received: from linuxbox.org ([24.155.83.21] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8U2-0007vm-8H for asrg@ietf.org; Sat, 27 Nov 2004 14:43:50 -0500 Received: from [192.115.22.106] (prometheus.solaris.org.il [192.115.22.106]) (authenticated bits=0) by linuxbox.org (8.12.11/8.12.11/Debian-3) with ESMTP id iARJcdY4013322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Nov 2004 13:39:00 -0600 Message-ID: <41A8D946.1060605@linuxbox.org> Date: Sat, 27 Nov 2004 21:45:10 +0200 From: Gadi Evron User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vipul Ved Prakash Subject: Re: [Asrg] "worm spam" and SPF References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on linuxbox.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org, Seth Breidbart X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Vipul Ved Prakash wrote: > Nod. This moves the content filtration problem to a different > place: on the outgoing servers. If the only way to send out spam > is through drones, then all spammers will move to using drones. > The conclusion that I draw from this is that content filtration > techniques used on outbound mail would have to be of the same > level of sophistication as inbound filtration today. I don't want to sound like some FUSSP guy, but I still honestly believe this can be controlled and pushed to the level we discuss by ISP's blocking port 25 on dynamic ranges. All a user has to do is ask for port 25 to be opened... and besides.. if they are running a server on a dynamic range.. Good luck! Closing port 25 on dynamic ranges would effectively make most mass mailers today useless. And thats a fact. Should port 25 be blocked? AOL and comcast say yes.. many others say no. Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 14:58:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18146 for ; Sat, 27 Nov 2004 14:58:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8mP-0000Cp-GO for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 15:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8e0-00029F-C9; Sat, 27 Nov 2004 14:54:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY8dn-000250-L1 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 14:53:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17850 for ; Sat, 27 Nov 2004 14:53:51 -0500 (EST) Received: from www.scconsult.com ([66.73.230.185] helo=toaster.scconsult.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY8iK-0008Ro-OE for asrg@ietf.org; Sat, 27 Nov 2004 14:58:38 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id 866E73522DF for ; Sat, 27 Nov 2004 14:53:15 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200411271917.OAA15364@ietf.org> References: <200411271917.OAA15364@ietf.org> Date: Sat, 27 Nov 2004 14:53:12 -0500 To: asrg@ietf.org From: Bill Cole Subject: RE: [Asrg] "worm spam" and SPF] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c At 2:14 PM -0500 11/27/04, Larry Seltzer imposed structure on a stream of electrons, yielding: >>>Here was the specific context to which I was responding: >>>>> they might even send out email using the user's own email >>>>> account and/or email client. >>>Swen does that. Really. > >No, it doesn't. I confess to a lot of ignorance regarding Windows, but are you actually stating that the perfect matching I see between SMTP envelope senders and the machines handing me Swen is the result of tens of thousands of lucky guesses? >Different versions of Swen do different things to get an SMTP server to >use, but they all use a built-in SMTP engine and none of them use SMTP >AUTH account information. I must have missed some previous reference to SMTP AUTH. This is the first I recall seeing it mentioned in this conversation. >In some circumstances Swen will put up a fake MAPI32 exception handler >that asks you for your email account server, username and password (see >a copy at http://www.trendmicro.com/vinfo/images/worm_swen_a_img2.gif). >According to Symantec >(http://securityresponse.symantec.com/avcenter/venc/data/w32.swen.a@mm.h >tml) Swen uses the username and password to check the POP3 account for >copies of itself. So Swen might use the default SMTP server (harvested >from the registry), but that's as close as it gets to using the user's >own e-mail account. I know that to not be so in all cases where I've tracked specific Swen copies back to the machines sending them and identified the owner of the machines. A small set admittedly (4,) however in every case the envelope sender was the real email address of the machine's owner. Every one of the thousands of Swen's I've seen is consistent with the envelope sender being the real email address of the machine's owner. Frankly, I trust the evidence I've seen myself far more than the combined opinions of Symantec and a tech journalist. Sorry. >How would a worm work if everyone had SMTP AUTH? It would either have to >use a social engineering trick like Swen does with the MAPI32 dialog - >and there's no evidence that there's a big problem with people filling >out that form - or it would have to find the cached account credentials >in the registry and use them. Worms wouldn't work at all if everyone used competently designed operating systems and mailers or if they used the dominant garbageware with half a brain. Technical tweaks are nice mind games, but the real world argues for them being largely pointless. People open encrypted zip files from people they do not know and run the contents. There are a lot of perfect fixes for the spam and malware problems given a user population that is predominantly not made up of blithering idiots. Such solutions are not realistic. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 15:25:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20372 for ; Sat, 27 Nov 2004 15:25:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY9Cj-00015C-Lj for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 15:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY94D-0007tp-Ra; Sat, 27 Nov 2004 15:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY90F-0005mD-Ur for asrg@megatron.ietf.org; Sat, 27 Nov 2004 15:17:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19510 for ; Sat, 27 Nov 2004 15:17:05 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY94n-0000mz-7I for asrg@ietf.org; Sat, 27 Nov 2004 15:21:50 -0500 Received: by wproxy.gmail.com with SMTP id 50so570603wri for ; Sat, 27 Nov 2004 12:16:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=h1ZnGm+J5mBE0uYNC9pXFTWcS4Vo/Myih2H3dBSxd3U5Z2bAzdGWdDXIN3dxeNL8VsfiMvkubnmIg/tMPuZ27g+mWGq1hv5BAfUtgGnGUBSVY+EPwtkMoGM+yNqj0LgAdXCJv00XkFgrFUeFksYoLKUw5d/ZpXsR5c3tEWeS4Zk= Received: by 10.54.23.3 with SMTP id 3mr1896107wrw; Sat, 27 Nov 2004 12:16:35 -0800 (PST) Received: by 10.54.35.57 with HTTP; Sat, 27 Nov 2004 12:16:35 -0800 (PST) Message-ID: <8fd7f6ff04112712162df0c5ce@mail.gmail.com> Date: Sun, 28 Nov 2004 04:16:35 +0800 From: M Z R To: Larry Seltzer Subject: Re: [Asrg] "worm spam" and SPF] In-Reply-To: <200411271917.OAA15364@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200411271917.OAA15364@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: M Z R List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Sat, 27 Nov 2004 14:14:59 -0500, Larry Seltzer wrote: > >>Here was the specific context to which I was responding: > >>>> they might even send out email using the user's own email > >>>> account and/or email client. > >>Swen does that. Really. > > No, it doesn't. > [snip] > tml) Swen uses the username and password to check the POP3 account for > copies of itself. > There it goes, POP-before-SMTP (PBS) defeated. Those who are still sticking to PBS, guess it's about time they switch to SMTP AUTH. > How would a worm work if everyone had SMTP AUTH? It would either have to > use a social engineering trick like Swen does with the MAPI32 dialog - > and there's no evidence that there's a big problem with people filling > out that form - or it would have to find the cached account credentials > in the registry and use them. > It could sniff the outgoing traffic to get the SMTP AUTH pass (not sure how though??) as almost nobody uses TLS/SSL to encrypt SMTP traffic. Regards, Zia _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 15:32:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20884 for ; Sat, 27 Nov 2004 15:32:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY9Js-0001JF-Qq for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 15:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY9Cx-0004PP-G7; Sat, 27 Nov 2004 15:30:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY9Bq-0003pa-1K for asrg@megatron.ietf.org; Sat, 27 Nov 2004 15:29:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20633 for ; Sat, 27 Nov 2004 15:29:04 -0500 (EST) Received: from teal.hjp.at ([62.99.236.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CY9GO-0001Bo-85 for asrg@ietf.org; Sat, 27 Nov 2004 15:33:48 -0500 Received: (qmail 29718 invoked by uid 500); 27 Nov 2004 20:28:28 -0000 Date: Sat, 27 Nov 2004 21:28:28 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] "worm spam" and SPF Message-ID: <20041127202828.GF27750@teal.hjp.at> Mail-Followup-To: asrg@ietf.org References: <41A8D946.1060605@linuxbox.org> Mime-Version: 1.0 In-Reply-To: <41A8D946.1060605@linuxbox.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684613844==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --===============0684613844== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XIiC+We3v3zHqZ6Z" Content-Disposition: inline --XIiC+We3v3zHqZ6Z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-11-27 21:45:10 +0200, Gadi Evron wrote: > I don't want to sound like some FUSSP guy, but I still honestly believe= =20 > this can be controlled and pushed to the level we discuss by ISP's=20 > blocking port 25 on dynamic ranges. [...] > Should port 25 be blocked? AOL and comcast say yes.. If they say so, why don't they do it? I still see a lot of connections from comcast DSL addresses (and a few from AOL). hp --=20 _ | Peter J. Holzer | Je h=F6her der Norden, desto weniger wird |_|_) | Sysadmin WSR | =FCberhaupt gesprochen, also auch kein Dialekt. | | | hjp@hjp.at | Hallig Gr=F6de ist fast g=E4nzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd --XIiC+We3v3zHqZ6Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBqONsfZ+RkG8quy0RAlYBAJ9DVYn+sszOwOAffzfCXsQses+NYQCgwx1l jPzWM59MPQqeGai5SmkqxkM= =Avoq -----END PGP SIGNATURE----- --XIiC+We3v3zHqZ6Z-- --===============0684613844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0684613844==-- From asrg-bounces@ietf.org Sat Nov 27 18:23:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00652 for ; Sat, 27 Nov 2004 18:23:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYBzF-0006pM-DD for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 18:28:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYBrI-0006Ao-1e; Sat, 27 Nov 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYBqj-0005r1-91 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 18:19:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00338 for ; Sat, 27 Nov 2004 18:19:26 -0500 (EST) Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYBvI-0006iL-Re for asrg@ietf.org; Sat, 27 Nov 2004 18:24:13 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.8/8.12.8) with SMTP id iARNItjA023204 for ; Sat, 27 Nov 2004 18:18:55 -0500 Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail1.nber.org (8.12.8/8.12.8) with ESMTP id iARNIonO023179; Sat, 27 Nov 2004 18:18:50 -0500 Date: Sat, 27 Nov 2004 18:18:50 -0500 (EST) From: Daniel Feenberg To: Bill Cole Subject: Re: [Asrg] "worm spam" and SPF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Fri, 26 Nov 2004, Bill Cole wrote: > At 5:00 AM +0200 11/27/04, Gadi Evron wrote: > >>As everyone probably knows, there is a pretty large outbreak going > >>on right now. According to our mail filters at > >>http://aves.f-prot.com, > >>10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, > >>there is a significant number of bounces as well. > > > >We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV > >calls it Sober.I@mm. > > > >I agree, bounces are the very evil of the net itself. > > > No, they are not. They are a critically important part of the > robustness of email. Broad acceptance of the idea that bounces are > evil will be the last nail in the coffin of email. > Rejection during SMTP processing is a good substitute for delayed DSN messages. It is not necessary to drop any messages on the floor, which would, I agree, be a terrific loss. I am aware that this is easier with some MTAs than others, but the technical reasons for delaying notification untill after message acceptance are not sufficiently strong to justify the practice into the future. For example, it has been argued that there is a security advantage in not having the user list available to the "outside" MTA, or that there is a reliability advantage in have the secondary MX at a remote location without access to the user list, or that anti-spam or anti-virus processing is so CPU intensive that it needs to be queued for delayed execution. All of these are cogent, but none are sufficiently powerfull to justify sending DSNs to possibly forged From addresses. It is true that some MTAs make it extremely difficult to reject invalid users, or spam or virus messages during SMTP processing, but in the fullness of time they will be fixed or left behind, and MTAs will be capable of making accept/reject decisions in real time while the connecting server waits for the final "." in the data step of the SMTP dialog. Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 19:09:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03223 for ; Sat, 27 Nov 2004 19:09:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYChT-0008LD-CC for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 19:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYCan-00044Y-BO; Sat, 27 Nov 2004 19:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYCZk-0003q0-K6 for asrg@megatron.ietf.org; Sat, 27 Nov 2004 19:06:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03144 for ; Sat, 27 Nov 2004 19:05:57 -0500 (EST) Received: from linuxbox.org ([24.155.83.21] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYCeK-0008Fs-Pi for asrg@ietf.org; Sat, 27 Nov 2004 19:10:45 -0500 Received: from [192.115.22.106] (prometheus.solaris.org.il [192.115.22.106]) (authenticated bits=0) by linuxbox.org (8.12.11/8.12.11/Debian-3) with ESMTP id iAS05jvZ014448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Nov 2004 18:05:50 -0600 Message-ID: <41A917E0.9050902@linuxbox.org> Date: Sun, 28 Nov 2004 02:12:16 +0200 From: Gadi Evron User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Feenberg Subject: Re: [Asrg] "worm spam" and SPF References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,WHY_WAIT autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on linuxbox.org X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit > It is true that some MTAs make it extremely difficult to reject invalid > users, or spam or virus messages during SMTP processing, but in the > fullness of time they will be fixed or left behind, and MTAs will be > capable of making accept/reject decisions in real time while the > connecting server waits for the final "." in the data step of the SMTP > dialog. Most GW AV's act as mail relays.. dealing with it is not a problem.. there is always a queue (unless some emulation etc. starts getting involved). Unrelated.. why wait for th '.'? Has anyone else noticed how sendmail would die after a certain amount of un-closed connections are made? We've seen this happening a few times in the past few months. Gadi. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 19:14:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03621 for ; Sat, 27 Nov 2004 19:14:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYCmF-000052-9J for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 19:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYCfd-0004xy-ND; Sat, 27 Nov 2004 19:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYCcX-0004Jf-Ri for asrg@megatron.ietf.org; Sat, 27 Nov 2004 19:08:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03199 for ; Sat, 27 Nov 2004 19:08:49 -0500 (EST) Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYCgr-0008Kk-9N for asrg@ietf.org; Sat, 27 Nov 2004 19:13:37 -0500 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041128000805.DWON20100.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net> for ; Sat, 27 Nov 2004 18:08:05 -0600 Received: from opwvbrownb ([12.45.253.11]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20041128000802.POUH7908.mm-ismta4.bizmailsrvcs.net@opwvbrownb> for ; Sat, 27 Nov 2004 18:08:02 -0600 From: "Bruce Brown" To: Subject: RE: [Asrg] "worm spam" and SPF Date: Sat, 27 Nov 2004 16:08:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTU2DMvnJBLfxOOT0KkzYfhxzrg5AABZekg Message-Id: <20041128000802.POUH7908.mm-ismta4.bizmailsrvcs.net@opwvbrownb> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit After consideration and reconsideration I've come to the conclusion that delayed rejection to hide the user list is much like security through obfuscation -- it is too easily defeated. Consequently, I've found it better to reject messages "on the wire" and keeping them from getting past the first MTA. Delays, so that you can send a bounce (often to a bogus address) is at best a waste of resources. -- Bruce > -----Original Message----- > From: asrg-bounces@ietf.org [mailto:asrg-bounces@ietf.org] On Behalf Of > Daniel Feenberg > Sent: Saturday, November 27, 2004 3:19 PM > To: Bill Cole > Cc: asrg@ietf.org > Subject: Re: [Asrg] "worm spam" and SPF > > > > On Fri, 26 Nov 2004, Bill Cole wrote: > > > At 5:00 AM +0200 11/27/04, Gadi Evron wrote: > > >>As everyone probably knows, there is a pretty large outbreak going > > >>on right now. According to our mail filters at > > >>http://aves.f-prot.com, > > >>10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, > > >>there is a significant number of bounces as well. > > > > > >We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV > > >calls it Sober.I@mm. > > > > > >I agree, bounces are the very evil of the net itself. > > > > > > No, they are not. They are a critically important part of the > > robustness of email. Broad acceptance of the idea that bounces are > > evil will be the last nail in the coffin of email. > > > > Rejection during SMTP processing is a good substitute for delayed DSN > messages. It is not necessary to drop any messages on the floor, which > would, I agree, be a terrific loss. I am aware that this is easier with > some MTAs than others, but the technical reasons for delaying notification > untill after message acceptance are not sufficiently strong to justify the > practice into the future. > > For example, it has been argued that there is a security advantage in not > having the user list available to the "outside" MTA, or that there is a > reliability advantage in have the secondary MX at a remote location > without access to the user list, or that anti-spam or anti-virus > processing is so CPU intensive that it needs to be queued for delayed > execution. All of these are cogent, but none are sufficiently powerfull to > justify sending DSNs to possibly forged From addresses. > > It is true that some MTAs make it extremely difficult to reject invalid > users, or spam or virus messages during SMTP processing, but in the > fullness of time they will be fixed or left behind, and MTAs will be > capable of making accept/reject decisions in real time while the > connecting server waits for the final "." in the data step of the SMTP > dialog. > > Daniel Feenberg > > > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 19:39:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04594 for ; Sat, 27 Nov 2004 19:39:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDAm-0000s4-8x for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 19:44:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYD4E-0008JV-V2; Sat, 27 Nov 2004 19:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYD1u-00083V-SW for asrg@megatron.ietf.org; Sat, 27 Nov 2004 19:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04481 for ; Sat, 27 Nov 2004 19:34:42 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYD5l-0000l7-AX for asrg@ietf.org; Sat, 27 Nov 2004 19:39:30 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYD15-00063D-00 for ; Sun, 28 Nov 2004 01:34:15 +0100 Received: from 213.191.80.203 ([213.191.80.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 01:34:15 +0100 Received: from nobody by 213.191.80.203 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 01:34:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 01:32:13 +0100 Organization: Lines: 29 Message-ID: <41A91C8C.59BE@xyzzy.claranet.de> References: <20041126111000.GU31887@f-prot.com> <200411270654.iAR6scF14204@panix5.panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 213.191.80.203 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Seth Breidbart wrote: > 1. "universal adoption" is part of being a FUSSP. True. But in the case of SPF it's good eough if most spammers and worm authors "adopt" it - by simply not forging proteted addresses. > 2. The next generation would just be more careful about who > they claimed to be. Yes, that's the idea. Like closing resp. blacklisting open relays SPF is not the FUSSP, it's the next "necessary" step. Defining "necessary" by the minimal modification you can get away with (excl. radical approaches like "delete all bounces" because that breaks SMTP). > At this point, strong SPF checking breaks too much stuff > (especially forwarding). It's not "especially forwarding", it's only 251-forwarding to third parties abusing the original MAIL FROM. That was always illegal in STD 10, you had to add the route to the MAIL FROM. RfC 2821 removed the routing from bounces, and that implicitly obsoleted 251-forwarding. It's not SPF breaking stuff, quite the contrary, SPF tries to fix something broken by 2821. Bye. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 20:00:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05697 for ; Sat, 27 Nov 2004 20:00:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDUj-0001ak-Ma for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 20:05:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDNs-0002tc-3p; Sat, 27 Nov 2004 19:57:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDKa-0002Qc-2K for asrg@megatron.ietf.org; Sat, 27 Nov 2004 19:54:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05511 for ; Sat, 27 Nov 2004 19:54:20 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDOl-0001OJ-Uk for asrg@ietf.org; Sat, 27 Nov 2004 19:59:09 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYDK9-00076P-00 for ; Sun, 28 Nov 2004 01:53:57 +0100 Received: from 213.191.80.203 ([213.191.80.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 01:53:57 +0100 Received: from nobody by 213.191.80.203 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 01:53:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 01:51:59 +0100 Organization: Lines: 25 Message-ID: <41A9212F.46FC@xyzzy.claranet.de> References: <20041127101439.GG31887@f-prot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 213.191.80.203 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF] X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Bill Cole wrote: > Here was the specific context to which I was responding: > they might even send out email using the user's own > email account and/or email client. > Swen does that. Really. Yes, but not necessarily. Its installation procedure asks the user to enter his smart host and credentials, and the "effects" can be very interesting... ;-) Generally it was possible to determine the relevant abuse@ for SWEN by looking at the Return-Path, but not _always_ > SPF does nothing at all to stop it. Yes, SWEN is quite unusual. SPF could help to enforce the _always_ in this case, but it can't replace a working abuse@ or the "enforced submission rights" in RfC 2476 option 6.1. Take care if you send SWEN complaints automatically, it's not always correct to use the Return-Path with local part abuse@. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 20:20:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06678 for ; Sat, 27 Nov 2004 20:20:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDng-0002Il-Lq for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 20:24:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDfV-0005US-Qy; Sat, 27 Nov 2004 20:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDZI-0004mK-7T for asrg@megatron.ietf.org; Sat, 27 Nov 2004 20:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06145 for ; Sat, 27 Nov 2004 20:09:32 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDdU-0001un-64 for asrg@ietf.org; Sat, 27 Nov 2004 20:14:21 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYDYr-0007yC-00 for ; Sun, 28 Nov 2004 02:09:09 +0100 Received: from 213.191.80.203 ([213.191.80.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 02:09:09 +0100 Received: from nobody by 213.191.80.203 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 02:09:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 02:08:13 +0100 Organization: Lines: 19 Message-ID: <41A924FD.3997@xyzzy.claranet.de> References: <200411271917.OAA15364@ietf.org> <8fd7f6ff04112712162df0c5ce@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 213.191.80.203 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF] X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit M Z R wrote: > There it goes, POP-before-SMTP (PBS) defeated. Those who are > still sticking to PBS, guess it's about time they switch to > SMTP AUTH. SMTP after POP with enforced submission rights is not really worse than AUTH PLAIN without TLS or AUTH LOGIN. For unknown reasons folks often confuse SMTP AUTH with enforced submission rights. An MSA allowing any MAiL FROM for authenticated users is much worse that SMTP after POP enforcing submission rights. APOP is arguably "better" than an AUTH PLAIN without TLS - in theory the latter isn't allowed, but... > almost nobody uses TLS/SSL to encrypt SMTP traffic. ...exactly. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Nov 27 20:22:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06858 for ; Sat, 27 Nov 2004 20:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYDqB-0002Oz-ST for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 20:27:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDgQ-0005dY-U2; Sat, 27 Nov 2004 20:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDbj-00054k-UE for asrg@megatron.ietf.org; Sat, 27 Nov 2004 20:12:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06201 for ; Sat, 27 Nov 2004 20:12:04 -0500 (EST) Received: from teal.hjp.at ([62.99.236.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYDfv-0001zP-SB for asrg@ietf.org; Sat, 27 Nov 2004 20:16:53 -0500 Received: (qmail 32335 invoked by uid 500); 28 Nov 2004 01:11:07 -0000 Date: Sun, 28 Nov 2004 02:11:07 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: "worm spam" and SPF Message-ID: <20041128011107.GB31981@teal.hjp.at> Mail-Followup-To: asrg@ietf.org References: <20041126111000.GU31887@f-prot.com> <200411270654.iAR6scF14204@panix5.panix.com> <41A91C8C.59BE@xyzzy.claranet.de> Mime-Version: 1.0 In-Reply-To: <41A91C8C.59BE@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802235774==" Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --===============1802235774== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-11-28 01:32:13 +0100, Frank Ellermann wrote: > Seth Breidbart wrote: >=20 > > At this point, strong SPF checking breaks too much stuff > > (especially forwarding). >=20 > It's not "especially forwarding", it's only 251-forwarding to > third parties abusing the original MAIL FROM.=20 You mean section 3.2? The 251 reply is used to tell the sender the correct address, so that the sender can send the next mail directly. I have never seen this, and I would consider it broken under most circumstances (I.e., if I give somebody an email address A which is forwarded to my other address B, I do not want to disclose B to that person). The 551 reply may be useful sometimes. > That was always illegal in STD 10, you had to add the route to the > MAIL FROM. Yes, but that is true for all kinds of relaying (see section 3.6): | In any case, the SMTP adds its own identifier to the reverse-path. I don't know if that requirement of RFC 821 was ever widely implemented. If it was, it was discontinued at least 15 years ago. > RfC 2821 removed the routing from bounces, Yes, because nobody was using it anyway. > and that implicitly obsoleted 251-forwarding.=20 I see no connection between source-routes and forwarding in rfc 821. > It's not SPF breaking stuff, quite the contrary, SPF tries to fix > something broken by 2821. Bye. A source route in the reverse-path isn't any more reliable than Received-headers. It solves nothing without additional requirements (like: "every relay needs to record which mails it forwarded an relay bounces in the opposite direction"), and therefore SPF cannot fix what wasn't broken. hp --=20 _ | Peter J. Holzer | Je h=F6her der Norden, desto weniger wird |_|_) | Sysadmin WSR | =FCberhaupt gesprochen, also auch kein Dialekt. | | | hjp@hjp.at | Hallig Gr=F6de ist fast g=E4nzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBqSWrfZ+RkG8quy0RAimnAJ9g+jTtFtPEfJTB1p5vZtS9H182ygCfRQa3 U+lwk5mrd8I+tklF6gBhkbs= =elWM -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- --===============1802235774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1802235774==-- From asrg-bounces@ietf.org Sat Nov 27 20:40:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07968 for ; Sat, 27 Nov 2004 20:40:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYE7B-00030t-1o for asrg-web-archive@ietf.org; Sat, 27 Nov 2004 20:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDyv-0000Ak-GM; Sat, 27 Nov 2004 20:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYDy5-0008Jm-As for asrg@megatron.ietf.org; Sat, 27 Nov 2004 20:35:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07551 for ; Sat, 27 Nov 2004 20:35:09 -0500 (EST) Received: from www.scconsult.com ([66.73.230.185] helo=toaster.scconsult.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYE2H-0002nw-EL for asrg@ietf.org; Sat, 27 Nov 2004 20:39:58 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id 6C45E3532E7 for ; Sat, 27 Nov 2004 20:34:09 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 27 Nov 2004 20:34:05 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] "worm spam" and SPF Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 At 6:18 PM -0500 11/27/04, Daniel Feenberg wrote: >On Fri, 26 Nov 2004, Bill Cole wrote: > >> At 5:00 AM +0200 11/27/04, Gadi Evron wrote: >> >>As everyone probably knows, there is a pretty large outbreak going >> >>on right now. According to our mail filters at >> >>http://aves.f-prot.com, >> >>10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, >> >>there is a significant number of bounces as well. >> > >> >We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV >> >calls it Sober.I@mm. >> > >> >I agree, bounces are the very evil of the net itself. >> >> >> No, they are not. They are a critically important part of the >> robustness of email. Broad acceptance of the idea that bounces are >> evil will be the last nail in the coffin of email. >> > >Rejection during SMTP processing is a good substitute for delayed DSN >messages. It is not necessary to drop any messages on the floor, which >would, I agree, be a terrific loss. I am aware that this is easier with >some MTAs than others, but the technical reasons for delaying notification >untill after message acceptance are not sufficiently strong to justify the >practice into the future. It isn't a matter of specific MTA's, but of the complexity of internal mail systems behind an external MX. If an external MX is is an entry point for a mail system where you cannot do final delivery synchronously with message acceptance, there will be cases where a later DSN, silent quarantine, or silent dropping are the only options. >For example, it has been argued that there is a security advantage in not >having the user list available to the "outside" MTA, or that there is a >reliability advantage in have the secondary MX at a remote location >without access to the user list, or that anti-spam or anti-virus >processing is so CPU intensive that it needs to be queued for delayed >execution. All of these are cogent, but none are sufficiently powerfull to >justify sending DSNs to possibly forged From addresses. I disagree, but only slightly. There is no excuse for sending DSN's to addresses that you can reasonably expect to be forged, i.e. because you determine the mail to be viral or spam and therefore refuse to deliver it. If you refuse to deliver a message because you have determined that the real sender (a spammer or a piece of malware) is not to be trusted and that the mail is itself untrustworthy, it makes no sense at all to generate a DSN for the message. >It is true that some MTAs make it extremely difficult to reject invalid >users, or spam or virus messages during SMTP processing, but in the >fullness of time they will be fixed or left behind, and MTAs will be >capable of making accept/reject decisions in real time while the >connecting server waits for the final "." in the data step of the SMTP >dialog. This is not an MTA issue at its heart. the core problem is that a lot of mail systems, particularly larger ones that are not structured as simply as most ISP systems, cannot even in principle do all mail delivery synchronously with exterior gateway SMTP acceptance. If there is a finite period where the message has been accepted but has not been finally delivered to whatever point the user eventually picks up their mail from, there will be some cases where the user existed and their mailbox was capable of accepting a message when it was accepted but where at least one of those will not be true when final delivery is tried. Mail systems have been built this way for decades because email usually and Internet email in particular have been designed for store-and-forward operations, not synchronous end-to-end delivery. Redefining that imposes major re-architecture requirements on a lot of large (mostly corporate) mail systems. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 00:37:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25122 for ; Sun, 28 Nov 2004 00:37:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHpH-0003H7-QB for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 00:42:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHcm-0004CH-N3; Sun, 28 Nov 2004 00:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHSd-0002H1-2n for asrg@megatron.ietf.org; Sun, 28 Nov 2004 00:18:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23560 for ; Sun, 28 Nov 2004 00:18:50 -0500 (EST) From: gep2@terabites.com Message-Id: <200411280518.AAA23560@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHWw-0002Rh-Jh for asrg@ietf.org; Sun, 28 Nov 2004 00:23:41 -0500 Date: Sun, 28 Nov 2004 05:18:01 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from WinProxy.anywhere (c-67-162-249-18.client.comcast.net[67.162.249.18]) by comcast.net (rwcrmhc11) with SMTP id <2004112805180101300kvgude>; Sun, 28 Nov 2004 05:18:01 +0000 Received: from 192.168.0.104 by 192.168.0.100 (WinProxy); Sat, 27 Nov 2004 23:17:52 -0600 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] "worm spam" and SPF To: asrg@ietf.org X-Mailer: SPRY Mail Version: 04.00.06.17 X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit >> As everyone probably knows, there is a pretty large outbreak going on > right now. According to our mail filters at http://aves.f-prot.com, > 10.56% of all filtered E-mail contains W32/Sober.J@mm. In addition, > there is a significant number of bounces as well. > We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV calls it Sober.I@mm. > I agree, bounces are the very evil of the net itself. Bouncing "infected" mail makes NO sense. Most of the time, the mail is bounced to a counterfeit/bogus "from" address where it COMPOUNDS the damage done by the worm, either by mailbombing someone who is THEMSELVES a victim, or at least their ISP. I've also had bounces go back to Yahoogroups (a major mailer, to say the least) who then disables MY E-mail address because "their" mail to me "hard bounced". :-(( A-V software, AT A MINIMUM, should NEVER bounced "infected" mail for cases where the recognized virus/worm in the mail being bounced is KNOWN to use counterfeit From: addresses! > Where I'd have to disagree is here: >> * Doing SPF checking will block the vast majority of the worms, but it > will not help with the bounces or the filter alerts. > It may block the vast majority of current worms, but I doubt it would stop the tide for long. VX-ers will find other ways of abusing infected victims.. they might even send out email using the user's own email account and/or email client. Absolutely, and that's precisely why SPF (like the other equally braindead certification/identification schemes) is a non-solution for this problem. Virus/worm authors can (literally overnight) shift to using the real E-mail address belonging to the person whose machine they've infected, and just as quickly all their worm/spam messages will fly through SPF (and similar) domain-certification checks. :-( So we would have spent YEARS arguing over and maybe finally agreeing on and implementing something that literally overnight is rendered useless. (And you know, the spammers love to get the last laugh like that, making everyone else look like the clueless idiots they are). > As long as there are huge drone armies out there, and their likes - I don't see how spam solutions today would really work as people hope. There is ONE solution that virtually eliminates the worm/virus problem. And that is the simple, effective, fine-grained permissions list... where the default is to (by default) not accept messages that: (1) are bigger than some limited size (say 10K-25K), (2) contain attachments, and/or (3) contain HTML. unless the trusted sender of those "enhanced" features has been approved to send those riskier/bulkier E-mail formats by the individual recipient. There could be enhancements to make the grain finer, to discriminate based on TYPE of attachments and classes of HTML tags. For most recipients, their default protections (accept executable attachments and HTML tags from NOBODY) would shield the recipient from virtually ALL e-mail propagation of worms and viruses. It would also effectively prevent URL spoofing, where the link that shows "confirm.citibank.com" actually links unseen to some site like "spoof.youmoron.ro" or the like. We can sit and argue about SPF and other authentication approaches for days, or weeks, or months, or even years, but the FACT of the matter is that until we get the virus/worm/zombie problem solved (and SPF does NOT do that), SPF (and ALL of its ilk) is damned near worthless. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support free and fair US elections! http://stickers.defend-democracy.org 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 00:38:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25171 for ; Sun, 28 Nov 2004 00:38:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHqE-0003IB-Ko for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 00:43:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHdw-0004UO-1T; Sun, 28 Nov 2004 00:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHYF-0003BI-R3 for asrg@megatron.ietf.org; Sun, 28 Nov 2004 00:24:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23836 for ; Sun, 28 Nov 2004 00:24:44 -0500 (EST) From: gep2@terabites.com Message-Id: <200411280524.AAA23836@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHce-0002dy-6J for asrg@ietf.org; Sun, 28 Nov 2004 00:29:35 -0500 Date: Sun, 28 Nov 2004 05:24:01 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from WinProxy.anywhere (c-67-162-249-18.client.comcast.net[67.162.249.18]) by comcast.net (rwcrmhc11) with SMTP id <2004112805240101300l3hbie>; Sun, 28 Nov 2004 05:24:01 +0000 Received: from 192.168.0.104 by 192.168.0.100 (WinProxy); Sat, 27 Nov 2004 23:22:19 -0600 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: RE: [Asrg] "worm spam" and SPF To: asrg@ietf.org X-Mailer: SPRY Mail Version: 04.00.06.17 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit > The worm attack on authentication schemes is a particularly bad one. I have recently joined the list, so I apologize if this has been discussed previously. But consider the following scenario: A new worm come out that uses infected machine's designated servers to send out mail. Say these mail servers have a SPF or DK record and further they enjoy good reputations on the various reputation services (since they mostly send out good mail). The recipient machines do a SPF/DK check, it passes, they lookup the reputation, which checks out too, and deliver the mail bypassing all content-based filtration sub-systems. The recipient systems get infected. The smarter users start reporting the worm to reputation services, who in turn punish the senders. After a while the senders reputation drops so much that they are unable to send out legit mail. Bingo. I've been arguing PRECISELY this point for several years, and Wong (et al) still forge blindly ahead with SPF and other such equally braindead authentication/DNS-based schemes. > This is bit of an extreme scenario, but a plausable one. Once it happens, spammers will adopt it and change the payload (worm + spam). Right, and they can do that literally overnight. SPF and other such schemes SIMPLY DO NOT WORK because they DO NOT SOLVE THE PROBLEM. They only force worms to use "real" return addresses and "approved" servers, but that accomplishes very, very little. Meanwhile, the fine-grained permissions-list solutions which WOULD prove effective and constitute a MAJOR clampdown on viruses/worms/spam get largely ignored. Go figure. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support free and fair US elections! http://stickers.defend-democracy.org 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 01:15:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27355 for ; Sun, 28 Nov 2004 01:15:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYIPy-0004YG-TW for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 01:20:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYIIQ-0002Dd-Iw; Sun, 28 Nov 2004 01:12:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYIGn-0001nr-KD for asrg@megatron.ietf.org; Sun, 28 Nov 2004 01:11:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27077 for ; Sun, 28 Nov 2004 01:10:28 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYIKr-0004PQ-5C for asrg@ietf.org; Sun, 28 Nov 2004 01:15:16 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYIGA-0005lh-00 for ; Sun, 28 Nov 2004 07:10:10 +0100 Received: from 213.191.80.203 ([213.191.80.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 07:10:10 +0100 Received: from nobody by 213.191.80.203 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 07:10:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 07:07:05 +0100 Organization: Lines: 24 Message-ID: <41A96B09.7E4F@xyzzy.claranet.de> References: <200411280524.AAA23836@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 213.191.80.203 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit gep2@terabites.com wrote: > I've been arguing PRECISELY this point for several years, > and Wong (et al) still forge blindly ahead with SPF That would be at most two years if you'd count RMX as the concept, and SPF as its realization. > SPF and other such schemes SIMPLY DO NOT WORK because they > DO NOT SOLVE THE PROBLEM. They only force worms to use > "real" return addresses and "approved" servers, but that > accomplishes very, very little. That's a contradiction. First you say SPF doesn't solve "THE PROBLEM", and then you say that SPF exactly does what it's supposed to do. Apparently your definition of "THE PROBLEM" has nothing to do with SPF. And your "solution" is to get rid of MIME multipart resp. text/html, and mails bigger than 12 KB. Your recipe won't help me against hundreds of bounces and other crap like challenges caused by forged addresses unfortunately. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 01:42:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29480 for ; Sun, 28 Nov 2004 01:42:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYIq9-0005VS-0N for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 01:47:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYIhj-00085J-Jc; Sun, 28 Nov 2004 01:38:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYIgb-0007wE-0K for asrg@megatron.ietf.org; Sun, 28 Nov 2004 01:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29086 for ; Sun, 28 Nov 2004 01:37:26 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7] ident=v1CwRSmRjzM9vgNRzyNAGu1u5rP14QWqGHHOIpoSnsL) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYIkx-0005N0-Mj for asrg@ietf.org; Sun, 28 Nov 2004 01:42:15 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA08589; Sun, 28 Nov 2004 01:37:05 -0500 (EST) From: der Mouse Message-Id: <200411280637.BAA08589@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sun, 28 Nov 2004 01:30:10 -0500 (EST) To: asrg@ietf.org Subject: Re: [Asrg] "worm spam" and SPF In-Reply-To: <20041128000802.POUH7908.mm-ismta4.bizmailsrvcs.net@opwvbrownb> References: <20041128000802.POUH7908.mm-ismta4.bizmailsrvcs.net@opwvbrownb> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit > After consideration and reconsideration I've come to the conclusion > that delayed rejection to hide the user list is much like security > through obfuscation -- it is too easily defeated. I agree - and furthermore, if you defer rejection until after the data, it is approximately as hard to abuse as accept-and-bounce. (It does require a little care with 4xxing RCPTs to preserve protocol conformance while making it nontrivial to game, but that can be done.) Yes, rejecting after data burns bandwidth to carry the body - but accept-and-bounce is even worse. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 09:17:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13760 for ; Sun, 28 Nov 2004 09:17:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYPwq-0000oR-6H for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 09:22:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYPl1-0002hv-1d; Sun, 28 Nov 2004 09:10:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYPgx-00022M-UA for asrg@megatron.ietf.org; Sun, 28 Nov 2004 09:06:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12927 for ; Sun, 28 Nov 2004 09:06:18 -0500 (EST) Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYPlf-0000K4-NG for asrg@ietf.org; Sun, 28 Nov 2004 09:11:12 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.8/8.12.8) with SMTP id iASE5kcb014322 for ; Sun, 28 Nov 2004 09:05:46 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.8/8.12.8) with ESMTP id iASE57nO014288; Sun, 28 Nov 2004 09:05:29 -0500 Date: Sun, 28 Nov 2004 09:05:07 -0500 (EST) From: Daniel Feenberg To: Gadi Evron Subject: Re: [Asrg] "worm spam" and SPF In-Reply-To: <41A917E0.9050902@linuxbox.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 It occurs to me that a site that was unwilling to handle policy rejections during SMTP processing, and hence faced with the choice of returning DSNs to a possibly forged "From" address or dropping them on the floor, does have an intermediate choice. They could return the DSN via the connecting host or the MX for that connecting host. That is, whatever the "From" address, go back to the connecting host to deposit the DSN into the mail stream. In many legitimate cases that host will accept mail for that "From" address, it is very unlikely to accept forged mail unless it is an open relay. There is already a mechanism "source routing" as the basis for implementation. RFCs still require the ability to process source routes for servers, although it is no longer required for clients. In any case, the connecting host doesn't actually have to do anything special. It just sees the "mail rcpt" address and either accepts or rejects the message depending upon its ability to deliver to that user. It is interesting to contemplate how this would play out if a few major players adopted it as a policy. I don't see any feasible response by spammers - this doesn't really affect them, only legitimate mail. Note that while a spammer could adopt forged "from" addresses that would be accepted by his host, it wouldn't help him deliver any spam. As I said, I don't consider this superior to rejection during SMTP processing, but it is an interesting substitute. Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 09:34:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14461 for ; Sun, 28 Nov 2004 09:34:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYQCb-0001Lg-QT for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 09:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYQ5x-0005yN-Be; Sun, 28 Nov 2004 09:32:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYQ5h-0005sR-Gs for asrg@megatron.ietf.org; Sun, 28 Nov 2004 09:31:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14392 for ; Sun, 28 Nov 2004 09:31:47 -0500 (EST) Received: from toaster.scconsult.com ([66.73.230.185]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYQAJ-0001C0-Jd for asrg@ietf.org; Sun, 28 Nov 2004 09:36:40 -0500 Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id 3A7C33583CF for ; Sun, 28 Nov 2004 09:30:00 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 28 Nov 2004 09:29:55 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] "worm spam" and SPF Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 9:05 AM -0500 11/28/04, Daniel Feenberg imposed structure on a stream of electrons, yielding: >It occurs to me that a site that was unwilling to handle policy rejections >during SMTP processing, and hence faced with the choice of returning DSNs >to a possibly forged "From" address or dropping them on the floor, does >have an intermediate choice. They could return the DSN via the connecting >host or the MX for that connecting host. That is, whatever the "From" >address, go back to the connecting host to deposit the DSN into the mail >stream. In many legitimate cases that host will accept mail for that >"From" address, it is very unlikely to accept forged mail unless it is an >open relay. That is so far from anything resembling rational behavior for any mail server that I'm hard pressed to respond to it within the decorum bounds of this mailing list. I'll just say that I think this is an idea that I pray never sees application in the real world. >There is already a mechanism "source routing" as the basis for >implementation. RFCs still require the ability to process source routes >for servers, although it is no longer required for clients. In any case, >the connecting host doesn't actually have to do anything special. It just >sees the "mail rcpt" address and either accepts or rejects the message >depending upon its ability to deliver to that user. I think you might find it useful to read RFC2821 again a bit more carefully. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 12:58:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02020 for ; Sun, 28 Nov 2004 12:58:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYTOK-0000Jk-Of for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 13:03:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYTGm-0002Tp-Cg; Sun, 28 Nov 2004 12:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYTBq-0001cv-9y for asrg@megatron.ietf.org; Sun, 28 Nov 2004 12:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01161 for ; Sun, 28 Nov 2004 12:50:21 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYTGX-0008Pd-Qr for asrg@ietf.org; Sun, 28 Nov 2004 12:55:18 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYTBl-00033m-00 for ; Sun, 28 Nov 2004 18:50:21 +0100 Received: from a077218.dialin.hansenet.de ([213.191.77.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 18:50:21 +0100 Received: from nobody by a077218.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Nov 2004 18:50:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 18:49:24 +0100 Organization: Lines: 18 Message-ID: <41AA0FA4.27A@hamburg.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: a077218.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nobody@xyzzy.claranet.de List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Bill Cole wrote: > That is so far from anything resembling rational behavior for > any mail server that I'm hard pressed to respond to it within > the decorum bounds of this mailing list. If you don't like STD 10 you could try to inform the RfC-editor about your reservations. > I think you might find it useful to read RFC2821 again a bit > more carefully. RfC 2821 is the bible of spammers, forgers, and worm authors, it's a "worst common practice" if there ever was one. Trying to fix a minor problem in STD 10 it got the routing examples completely wrong. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 14:04:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06889 for ; Sun, 28 Nov 2004 14:04:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYUPx-0002TY-J6 for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 14:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYUCS-0005Hr-Ur; Sun, 28 Nov 2004 13:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYUBm-00058B-7n for asrg@megatron.ietf.org; Sun, 28 Nov 2004 13:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06170 for ; Sun, 28 Nov 2004 13:54:23 -0500 (EST) From: gep2@terabites.com Message-Id: <200411281854.NAA06170@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYUGU-00029x-F2 for asrg@ietf.org; Sun, 28 Nov 2004 13:59:18 -0500 Date: Sun, 28 Nov 2004 18:53:49 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from WinProxy.anywhere (c-67-162-249-18.client.comcast.net[67.162.249.18]) by comcast.net (rwcrmhc11) with SMTP id <2004112818534901300l3caae>; Sun, 28 Nov 2004 18:53:49 +0000 Received: from 192.168.0.104 by 192.168.0.100 (WinProxy); Sun, 28 Nov 2004 12:51:52 -0600 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF To: asrg@ietf.org X-Mailer: SPRY Mail Version: 04.00.06.17 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit >gep2@terabites.com wrote: >> I've been arguing PRECISELY this point for several years, > and Wong (et al) still forge blindly ahead with SPF > That would be at most two years if you'd count RMX as the concept, and SPF as its realization. I could go back and find my archived posts on the issue, but ultimately it matters little. In Internet terms, anyhow, it's been quite a while. >> SPF and other such schemes SIMPLY DO NOT WORK because they > DO NOT SOLVE THE PROBLEM. They only force worms to use > "real" return addresses and "approved" servers, but that > accomplishes very, very little. > That's a contradiction. First you say SPF doesn't solve "THE PROBLEM", and then you say that SPF exactly does what it's supposed to do. Apparently your definition of "THE PROBLEM" has nothing to do with SPF. Or, alternatively, the problem SPF "solves" is NOT the spam problem, nor is it the worm problem. It doesn't even mean that E-mail comes legitimately from a trusted person with an authenticated return address. It (arguably) ensures that the machine that sent the mail can be identified as such; but as long as authenticated machines can be infected and recruited to send "authenticated" worm/spam messages, SPF and similar schemes do very little to prevent such things... you're still running along after a constantly moving target, trying to lock the barn door (and there are MILLIONS of them, and new ones being created all the time) after the horse has escaped. And then you have the issue, too, of undoing the DAMAGE that SPF has done, not only to "recommission" the victim's E-mail integrity, but also fixing the many legitimate systems that SPF breaks. > And your "solution" is to get rid of MIME multipart resp. text/html, and mails bigger than 12 KB. No, not at all. The point of the permissions list is that small(ish) plain text messages (without attachments) are QUITE SUFFICIENT for UNEXPECTED initial contact messages from UNFAMILIAR senders. Once the contact has been made, and the recipient trusts the sender, *if* there is going to be an extended correspondence, then the recipient can enable ONLY JUST the type of bulkier/riskier content that they agree that the sender wants and needs to send, and which the recipient trusts the sender not to abuse. It's really a matter of not just WHO the sender is, to THIS recipient, but what mail from them is "expected" to look like. Mail coming "from" that sender but which doesn't look as it normally does (e.g. suddenly it's got Java, or .CPL or .SCR attachments, or decryption, or obscured URLs, or ActiveX or whatever) is BY DEFINITION suspect BECAUSE it doesn't look like what the recipient expects to receive from that sender. It doesn't fit the pattern. (Other mail from the same sender probably DOES look "right" and thus will continue to sail right through, as it should). > Your recipe won't help me against hundreds of bounces... "bounces" containing viruses or worms (for example) WOULD be identified and blocked if they didn't fit the default criteria from that (probably unknown) sender. > ..and other crap like challenges caused by forged addresses unfortunately. It would block what it blocks, and that's set (and changed when necessary) by the recipient. It would virtually eliminate E-mail as a vector for the transmission of worms and viruses. It would make major inroads against phishing attacks in E-mail by making it harder to spoof URLs. With widespread adoption, it would reduce the sheer byte volume of unsolicited spam by forcing spammers to mail it as plain text of limited size, as HTML-burdened spam is generally 3-5x bigger than a plain text equivalent. It doesn't break vanity domains, doesn't break "atypical" send paths (e.g. the cruise ship Internet cafe or the hotel business center or the Internet cafe) and doesn't break mailing lists or other forwarding. Better yet, it is implementable on an individual system basis, provides IMMEDIATE benefits to those using it, requires no worldwide consensus or sweeping changes. Win-win. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support free and fair US elections! http://stickers.defend-democracy.org 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 16:51:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18139 for ; Sun, 28 Nov 2004 16:51:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYX1v-0006Ut-Js for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 16:56:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYWva-0007ym-LD; Sun, 28 Nov 2004 16:49:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYWrb-0007K9-IK for asrg@megatron.ietf.org; Sun, 28 Nov 2004 16:45:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17716 for ; Sun, 28 Nov 2004 16:45:45 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYWwN-0006Oa-8q for asrg@ietf.org; Sun, 28 Nov 2004 16:50:43 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iASLjKqo003484; Sun, 28 Nov 2004 13:45:20 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 28 Nov 2004 13:45:20 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Fridrik Skulason'" , asrg@ietf.org Subject: RE: [Asrg] "worm spam" and SPF] Date: Sun, 28 Nov 2004 13:45:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Returning to Fridrik's original points 1) The bounce messages are unwanted and indiscriminate, therefore they are by my definition spam. 2) If RFC 2821 offends thee, pluck it out. At this point the IETF has had a chance to fix SMTP and failed. I would rather that messages were dumped on the floor than have bounces sent to clearly false addresses. The chance of a false positive on a pattern detecting virus scan in particular is very very small. The amount of iunnecessary concern that is caused by these messages is very large. I think that the reason that companies keep sending this stuff that thy know is hitting an innocent bystander is that they think it's a cute advertsing trick. The fact that it is telling everyone who receives it they are clueless does not sink into the marketting thickos. 3) You can protect yourself against false bounces A better solution would be to deploy BATV or some variant and in effect give yourself the ability to validate your own bounces by adding a validation cookie to the 821 FROM address, the bounce address. This will still leave you with spam from non conformant mail servers. 4) Better would be an out of band form of signalling. The bounce problem is the result of using the email channel for both control and data. It is a poor design which was acceptable in circa 1980 when SMTP emerged as an improvement on the send mail through FTP hack. A useful extension to SPF would be a signal to say 'if you have bounces please report them via this Web Service rather than in channel'. The work going on in INCH could be reused. Phill _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 17:03:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19428 for ; Sun, 28 Nov 2004 17:03:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYXDZ-0006l2-D3 for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 17:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYX0q-0000vD-V9; Sun, 28 Nov 2004 16:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYX0X-0000iB-E1 for asrg@megatron.ietf.org; Sun, 28 Nov 2004 16:55:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18448 for ; Sun, 28 Nov 2004 16:54:59 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYX5F-0006Y4-J2 for asrg@ietf.org; Sun, 28 Nov 2004 16:59:57 -0500 Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iASMKJig013087; Sun, 28 Nov 2004 14:20:19 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iASMKJBS013084; Sun, 28 Nov 2004 14:20:19 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 28 Nov 2004 14:20:19 -0800 (PST) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" Subject: RE: [Asrg] "worm spam" and SPF] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Sun, 28 Nov 2004, Hallam-Baker, Phillip wrote: > report them via this Web Service rather than in channel'. The work going on > in INCH could be reused. What is INCH? -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 18:09:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24567 for ; Sun, 28 Nov 2004 18:09:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYFu-0007v9-PD for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 18:14:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYY5N-00051S-To; Sun, 28 Nov 2004 18:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYY3U-0003dI-Kd for asrg@megatron.ietf.org; Sun, 28 Nov 2004 18:02:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23515 for ; Sun, 28 Nov 2004 18:02:05 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYY8G-0007mP-FL for asrg@ietf.org; Sun, 28 Nov 2004 18:07:05 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYY3R-0002Sb-00 for ; Mon, 29 Nov 2004 00:02:05 +0100 Received: from a077218.dialin.hansenet.de ([213.191.77.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 00:02:05 +0100 Received: from nobody by a077218.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 00:02:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Nov 2004 23:59:25 +0100 Organization: Lines: 61 Message-ID: <41AA584D.132D@xyzzy.claranet.de> References: <200411281854.NAA06170@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: a077218.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit gep2@terabites.com wrote: > Or, alternatively, the problem SPF "solves" is NOT the spam > problem, nor is it the worm problem. Yes, that's true, SPF attacks the problem of forged MAIL FROM addresses and forged HELO domains. It's indirectly related to spam and worms at the moment, like open relays were related to the spam problem some years ago. > as long as authenticated machines can be infected and > recruited to send "authenticated" worm/spam messages, SPF > and similar schemes do very little to prevent such things It allows to find the relevant abuse desk fast, not too shabby. All these weird challenges / out-of-office / vacation mails won't hit innocent bystanders, if many receivers support SPF. "Many" is good enough, spammers and worm authors won't waste their time with something not working at say AOL or behind SA. > undoing the DAMAGE that SPF has done There's no "damage", if you don't like it just don't publish a sender policy. >> your "solution" is to get rid of MIME multipart resp. >> text/html, and mails bigger than 12 KB. > No, not at all. You said so in <200411280518.AAA23560@ietf.org> : | default is to (by default) not accept messages that: | (1) are are bigger than some limited size (say 10K-25K), | (2) contain attachments, and/or (3) contain HTML 12,000 bytes is a limit in my own "popstop" script, but it's within your size limits. > Once the contact has been made, and the recipient trusts the > sender, *if* there is going to be an extended correspondence, > then the recipient can enable ONLY JUST the type of > bulkier/riskier content that they agree Okay, in fact I have "special" addresses (not nobody@xyzzy) where I don't limit the size, and don't look for any TV or UE starting a base64 attachment (poor man's AV, credits to John) But the UBE still sits there in my POP3 mailbox waiting for an over quota or my script. And many of the bounces and all other crap caused by forged addresses were relatively small. > With widespread adoption That's the problem of all FUSSPs. As you see I have no problem to mix different ideas, as far as that's possible for a normal POP3 user without the root password for the MX of his provider. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 18:30:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26276 for ; Sun, 28 Nov 2004 18:30:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYZd-0008DM-Ty for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 18:35:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYO7-0004mH-7x; Sun, 28 Nov 2004 18:23:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYNW-0004gA-5c for asrg@megatron.ietf.org; Sun, 28 Nov 2004 18:22:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25916 for ; Sun, 28 Nov 2004 18:22:47 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYS8-00086t-OZ for Asrg@ietf.org; Sun, 28 Nov 2004 18:27:47 -0500 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iASNMcjo007175 for ; Sun, 28 Nov 2004 15:22:38 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 28 Nov 2004 15:22:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "Asrg (Asrg@ietf.org)" Date: Sun, 28 Nov 2004 15:22:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Asrg] FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jkHCbIESbz X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc I hereby nominate downtownweb.com for the clueless dweeb 2004 awards. C/R systems are in my view obnoxious spam generators at the best of times. When they spam people posting to mailing lists they become utterly unacceptable. -----Original Message----- From: rogb@downtownweb.com [mailto:rogb@downtownweb.com] Sent: Sunday, November 28, 2004 4:55 PM To: pbaker@verisign.com Subject: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu3jkHCbIESbz This is the first time that you've emailed someone at downtownweb.com recently. Please reply to this email to verify that you are a real live person and not a spammer. Simply reply to this email and leave the subject line intact. By doing so you will then be added to your friend's whitelist here. --downtownweb.com's email robot The headers of the email sent from your address are show below: >From asrg-bounces@ietf.org Mon Nov 29 05:54:37 2004 Received: from megatron.ietf.org ([132.151.6.71]:42758) by ang.serverko.net with esmtp (Exim 4.43) id 1CYWzn-0006lP-4Y for rogb@downtownweb.com; Mon, 29 Nov 2004 05:54:36 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYWva-0007ym-S1; Sun, 28 Nov 2004 16:49:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYWrb-0007K9-IK for asrg@megatron.ietf.org; Sun, 28 Nov 2004 16:45:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17716 for ; Sun, 28 Nov 2004 16:45:45 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYWwN-0006Oa-8q for asrg@ietf.org; Sun, 28 Nov 2004 16:50:43 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iASLjKqo003484; Sun, 28 Nov 2004 13:45:20 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 28 Nov 2004 13:45:20 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Fridrik Skulason'" , asrg@ietf.org Subject: RE: [Asrg] "worm spam" and SPF] Date: Sun, 28 Nov 2004 13:45:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Antivirus-Scanner: Clean mail though you should still use an Antivirus _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 18:31:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26455 for ; Sun, 28 Nov 2004 18:31:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYab-0008F2-Fg for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 18:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYUw-0005sS-1E; Sun, 28 Nov 2004 18:30:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYP2-0004pj-5M for asrg@megatron.ietf.org; Sun, 28 Nov 2004 18:24:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25943 for ; Sun, 28 Nov 2004 18:24:21 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYTo-00087w-9Q for asrg@ietf.org; Sun, 28 Nov 2004 18:29:20 -0500 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iASNOH9d007253; Sun, 28 Nov 2004 15:24:21 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 28 Nov 2004 15:24:17 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'william(at)elan.net'" , "Hallam-Baker, Phillip" Subject: RE: [Asrg] "worm spam" and SPF] Date: Sun, 28 Nov 2004 15:24:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Incident handling. Its an IETF WG. The original model was that everyone would report their troubles to CERTs in machine readable form and then the CERTS would respond a few months later. > -----Original Message----- > From: william(at)elan.net [mailto:william@elan.net] > Sent: Sunday, November 28, 2004 5:20 PM > To: Hallam-Baker, Phillip > Cc: asrg@ietf.org > Subject: RE: [Asrg] "worm spam" and SPF] > > > > On Sun, 28 Nov 2004, Hallam-Baker, Phillip wrote: > > > report them via this Web Service rather than in channel'. The work > > going on in INCH could be reused. > > What is INCH? > > -- > William Leibzon > Elan Networks > william@elan.net > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 21:38:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11654 for ; Sun, 28 Nov 2004 21:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbVJ-0003kZ-Kd for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 21:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbO1-0003mq-Gx; Sun, 28 Nov 2004 21:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbCf-0001Wn-Qe for asrg@megatron.ietf.org; Sun, 28 Nov 2004 21:23:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10666 for ; Sun, 28 Nov 2004 21:23:48 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7] ident=WRpwpiSPtQ7AnsQ6LocjsKt6CJnz8x8hCUcm4cwRZ4v) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbHU-0003Uj-6D for asrg@ietf.org; Sun, 28 Nov 2004 21:28:48 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA12256; Sun, 28 Nov 2004 21:23:47 -0500 (EST) From: der Mouse Message-Id: <200411290223.VAA12256@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sun, 28 Nov 2004 21:19:27 -0500 (EST) To: asrg@ietf.org Subject: Re: [Asrg] Re: "worm spam" and SPF In-Reply-To: <41AA0FA4.27A@hamburg.de> References: <41AA0FA4.27A@hamburg.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit >>> [suggestion to send bounces to the host who handed off the mail to >>> you, or its MX] >> That is so far from anything resembling rational behavior for any >> mail server that I'm hard pressed to respond to it within the >> decorum bounds of this mailing list. > If you don't like STD 10 you could try to inform the RfC-editor about > your reservations. If you think STD 10 or RFC 2821 (which obsoleted 821 over three and a half years ago) permits such behaviour, I suspect you need to go reread it. As far as I can tell you are either sending a bounce somewhere other than the envelope-from or you are sending mail to a given address somewhere other than the (possibly implicit) MX for the domain portion of the address (or your own smarthost). I've never seen any standard support for either; if you think you have, I would very much like to see a specific reference. In particular, if you have any reason to think that disliking such behaviour means disliking STD 10, or its superseding document, I want to see a specific reference. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 21:40:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11793 for ; Sun, 28 Nov 2004 21:40:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbXH-0003n3-8B for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 21:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbO4-0003nD-F2; Sun, 28 Nov 2004 21:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbG3-0002H1-FQ for asrg@megatron.ietf.org; Sun, 28 Nov 2004 21:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11000 for ; Sun, 28 Nov 2004 21:27:17 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7] ident=aPo52EajJPPNF27QxP3fBDpwYlKNcg36yYg0b7K7EjT) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbKs-0003ZY-0f for asrg@ietf.org; Sun, 28 Nov 2004 21:32:18 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA12275; Sun, 28 Nov 2004 21:27:17 -0500 (EST) From: der Mouse Message-Id: <200411290227.VAA12275@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sun, 28 Nov 2004 21:24:14 -0500 (EST) To: asrg@ietf.org Subject: Re: [Asrg] Re: "worm spam" and SPF In-Reply-To: <41AA584D.132D@xyzzy.claranet.de> References: <200411281854.NAA06170@ietf.org> <41AA584D.132D@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit >> undoing the DAMAGE that SPF has done > There's no "damage", if you don't like it just don't publish a sender > policy. There is damage, even for a total non-adopter, like me. First, it's drained off a nontrivial amount of effort that could have gone towards developing something more effective. Second, because it breaks bounces, and because some people feel that the appropriate reaction to that is not "don't do that, then" but rather to break bounces even more contrivedly, I've already had one message produce a misfire from my automated filtering because its envelope-from was mangled by SRS (itself a direct consequence of SPF). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 21:50:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12567 for ; Sun, 28 Nov 2004 21:50:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbhR-00040A-Ol for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 21:55:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbU7-0005hZ-LR; Sun, 28 Nov 2004 21:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbPa-0004Gh-43 for asrg@megatron.ietf.org; Sun, 28 Nov 2004 21:37:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11611 for ; Sun, 28 Nov 2004 21:37:08 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7] ident=txlDDuXXCYMux8qcX4XABXGgeaextxjn1lF1Xe4fWWR) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbUO-0003je-Oz for Asrg@ietf.org; Sun, 28 Nov 2004 21:42:09 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA12311; Sun, 28 Nov 2004 21:37:08 -0500 (EST) From: der Mouse Message-Id: <200411290237.VAA12311@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sun, 28 Nov 2004 21:27:24 -0500 (EST) To: Asrg@ietf.org Subject: Re: [Asrg] FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jkHCbIESbz In-Reply-To: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit > I hereby nominate downtownweb.com for the clueless dweeb 2004 awards. I second the nomination. > C/R systems are in my view obnoxious spam generators at the best of > times. When they spam people posting to mailing lists they become > utterly unacceptable. Total agreement. Worse, when I wrote to them to point this out, it appeared they have "protected" their postmaster address with the very same brokenware. In consequence, they are now in my mailer's "remove no earlier than hell freezing over" deny list. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 22:01:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13419 for ; Sun, 28 Nov 2004 22:01:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbsB-0004En-Q8 for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 22:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbk2-0008GR-Tg; Sun, 28 Nov 2004 21:58:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbgD-0007aw-E4 for asrg@megatron.ietf.org; Sun, 28 Nov 2004 21:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12799 for ; Sun, 28 Nov 2004 21:54:19 -0500 (EST) Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYbl1-00044W-1U for asrg@ietf.org; Sun, 28 Nov 2004 21:59:20 -0500 Received: (qmail 23902 invoked by uid 100); 29 Nov 2004 02:54:14 -0000 Date: 29 Nov 2004 02:54:14 -0000 Message-ID: <20041129025414.23901.qmail@xuxa.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] FW: Your email requires verification -- oh, no it doesn't In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit >I hereby nominate downtownweb.com for the clueless dweeb 2004 awards. It's the responsibility of each subscriber to the ASRG lists to configure his or her mail to work correctly. Sending challenges in response to incoming mail is poor practice under any circumstances, and is completely broken in response to mail from lists someone has subscribed to. If I see any C/R challenges sent to the list, I will remove the sender. If anyone on the list gets C/R challenges in response to mail they sent to the list, just forward the challenge to me and I'll remove the guilty party. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 22:19:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15128 for ; Sun, 28 Nov 2004 22:19:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYc8z-0004aG-0x for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 22:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbyG-000281-KC; Sun, 28 Nov 2004 22:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYbsk-0001GD-FZ for asrg@megatron.ietf.org; Sun, 28 Nov 2004 22:07:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14183 for ; Sun, 28 Nov 2004 22:07:16 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYbxW-0004MC-0f for Asrg@ietf.org; Sun, 28 Nov 2004 22:12:17 -0500 Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAT3WfVK021212; Sun, 28 Nov 2004 19:32:41 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAT3Wfke021209; Sun, 28 Nov 2004 19:32:41 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 28 Nov 2004 19:32:41 -0800 (PST) From: "william(at)elan.net" To: der Mouse Subject: Re: [Asrg] FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jkHCbIESbz In-Reply-To: <200411290237.VAA12311@Sparkle.Rodents.Montreal.QC.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Sun, 28 Nov 2004, der Mouse wrote: > > I hereby nominate downtownweb.com for the clueless dweeb 2004 awards. > > I second the nomination. Oh, come on - there are worth examples then that, like take for example those who set their autoreply messages to go to ietf@ietf.org mail list! -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Nov 28 23:44:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23437 for ; Sun, 28 Nov 2004 23:44:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYdTg-0006ah-8w for asrg-web-archive@ietf.org; Sun, 28 Nov 2004 23:49:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdIa-0000fE-4z; Sun, 28 Nov 2004 23:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdET-0007zF-Mm for asrg@megatron.ietf.org; Sun, 28 Nov 2004 23:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21854 for ; Sun, 28 Nov 2004 23:33:46 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYdJH-0006F0-Bk for Asrg@ietf.org; Sun, 28 Nov 2004 23:38:48 -0500 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iAT4Xjiv013337 for ; Sun, 28 Nov 2004 20:33:45 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 28 Nov 2004 20:33:45 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Asrg@ietf.org Subject: RE: [Asrg] FW: Your email requires verification verify#DzSXey5Ib5 bYxjdNkwIJu 3jkHCbIESbz Date: Sun, 28 Nov 2004 20:33:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > From: asrg-bounces@ietf.org [mailto:asrg-bounces@ietf.org] On > Behalf Of william(at)elan.net > On Sun, 28 Nov 2004, der Mouse wrote: > > > > I hereby nominate downtownweb.com for the clueless dweeb 2004 > > > awards. > > > > I second the nomination. > > Oh, come on - there are worth examples then that, like take > for example those who set their autoreply messages to go to > ietf@ietf.org mail list! Which is why I have always wanted a definition of spam that looks at the problem from the user's perspective. If the recipient does not want it and the receiver should have realized that it was not going to be wanted then it should be eliminated if practical. One cause of spam is the bad guys but another cause is all the ad hoc schemes that folk have set up for a variety of purposes that ends up sending folk mail that is simply unnecessary. For example the folk in this newsgroup who used to set their mail servers so that every email sent to them from someone they disagreed with was reported to DCC as spam and then sent a reject note out to them. [Spam and troll in one move]. The anti-virus bounces are another example, vacation notices etc. Its not enough to simply say the fault lies with X for not following the standard. Companies do what they do for good commercial reasons. Why is the standard not being followed? What is the institutional failure? What is the remedy? Phill _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 00:05:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25834 for ; Mon, 29 Nov 2004 00:05:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYdoL-0007HP-OZ for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 00:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdcX-0005R9-Ms; Sun, 28 Nov 2004 23:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYdZm-0004WN-W5 for asrg@megatron.ietf.org; Sun, 28 Nov 2004 23:55:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24895 for ; Sun, 28 Nov 2004 23:55:48 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYdec-0006tD-1b for asrg@ietf.org; Mon, 29 Nov 2004 00:00:50 -0500 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id iAT4tFkL027795; Sun, 28 Nov 2004 20:55:16 -0800 From: Dave Crocker To: John Levine , X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: brandenburg.com Date: Sun, 28 Nov 2004 20:55:13 -0800 Message-ID: <20041128205513.640734@bbprime> In-Reply-To: <20041129025414.23901.qmail@xuxa.iecc.com> Subject: Re: [Asrg] FW: Your email requires verification -- oh, no it doesn't Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id iAT4tFkL027795 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: pbaker@verisign.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable On 29 Nov 2004 02:54:14 -0000, John Levine wrote: >=A0 Sending challenges in >=A0 response to incoming mail is poor practice under any circumstances, >=A0 and is completely broken in response to mail from lists someone has >=A0 subscribed to. I'm feeling pedantic: The recipient of mailing list mail has, as you note, subscribed to the li= st. Therefore they have already satisfied the conconer that challenge/re= sponse schemes purport to address: Is the sender of this message account= able? The answer is yes, because the sender is the operator of the maili= ng list. If one does not approve of the policies that operator has then discuss it= with the operator. It makes no sense to impose one's dissatisfaction up= on the other participants of the list, such as those posting to it. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker =A0a t ... www.brandenburg.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 00:54:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01473 for ; Mon, 29 Nov 2004 00:54:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYeZI-0008S9-Gl for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 00:59:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYeSl-0008LD-2D; Mon, 29 Nov 2004 00:52:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYeNL-0007Bz-Jt for asrg@megatron.ietf.org; Mon, 29 Nov 2004 00:47:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00768 for ; Mon, 29 Nov 2004 00:47:00 -0500 (EST) From: gep2@terabites.com Message-Id: <200411290547.AAA00768@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYeSB-0008G4-Rr for asrg@ietf.org; Mon, 29 Nov 2004 00:52:04 -0500 Date: Mon, 29 Nov 2004 05:46:31 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from WinProxy.anywhere (c-67-162-249-18.client.comcast.net[67.162.249.18]) by comcast.net (rwcrmhc13) with SMTP id <2004112905463101500gvtpte>; Mon, 29 Nov 2004 05:46:31 +0000 Received: from 192.168.0.104 by 192.168.0.100 (WinProxy); Sun, 28 Nov 2004 23:46:12 -0600 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] "worm spam" and SPF To: "Philip J. Koenig" , asrg@ietf.org In-Reply-To: <41AA096E.25965.3D75F3@localhost> X-Mailer: SPRY Mail Version: 04.00.06.17 X-Spam-Score: 0.4 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: gep2@terabites.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit >>> Absolutely, and that's precisely why SPF (like the other equally braindead >> certification/identification schemes) is a non-solution for this problem. >> Virus/worm authors can (literally overnight) shift to using the real E-mail >> address belonging to the person whose machine they've infected, and just as >> quickly all their worm/spam messages will fly through SPF (and similar) >> domain-certification checks. :-( So we would have spent YEARS arguing over and >> maybe finally agreeing on and implementing something that literally overnight is >> rendered useless. (And you know, the spammers love to get the last laugh like >> that, making everyone else look like the clueless idiots they are). >The reason that various forms of malware started using the tactic of >using randomly-found addresses inserted into FROM: headers in the >first place was to make it much more difficult to track down the >infected user/host and/or shutdown/disconnect the infected machine. Well, except that it isn't. All the headers post-insertion presumably point back at the (really) infected machine, or at least to the machine that first accepted the bogus mail. But the traceback, ultimately, isn't all that critical. The important thing is simply that the spam not be delivered to anybody, or that if it IS delivered it's simply not effective. >If malware reversed course in that regard, it would instantly become >vastly easier for anyone to locate/shutdown infected machines again - >even for tech-illiterate people. So I think that tactic shift on the >part of malware authors would be self-limiting. I agree to the extent that ultimately the spammers are going to be put on the defensive, but meanwhile, SPF and the like is NOT the way to solve the spam/worm/virus problem. Other approaches are FAR more effective, better controlled, more targeted, less expensive, faster, and with less deleterious side-effects that harm legitimate mail and legitimate senders. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support free and fair US elections! http://stickers.defend-democracy.org 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 07:54:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15119 for ; Mon, 29 Nov 2004 07:54:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYl7o-0008Il-PY for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 07:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkh7-0001bR-3T; Mon, 29 Nov 2004 07:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkeg-0000WR-5r; Mon, 29 Nov 2004 07:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28761; Mon, 29 Nov 2004 04:07:47 -0500 (EST) Received: from mail83.messagelabs.com ([195.245.231.83]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYhaU-0003dk-7j; Mon, 29 Nov 2004 04:12:51 -0500 X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-9.tower-83.messagelabs.com!1101719231!2729704!1 X-StarScan-Version: 5.4.2; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 26634 invoked from network); 29 Nov 2004 09:07:11 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-9.tower-83.messagelabs.com with SMTP; 29 Nov 2004 09:07:11 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 29 Nov 2004 09:07:11 +0000 Subject: Re: [Asrg] FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jkHCbIESbz To: "william(at)elan.net" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Danny Angus Date: Mon, 29 Nov 2004 09:07:10 +0000 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 29/11/2004 09:07:11 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: der Mouse , Asrg@ietf.org, asrg-bounces@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > autoreply messages to go to ietf@ietf.org mail list! I think theres a need for a simple standard to describe behaviour in response to lists, the Precedence header is good where people implement its use wisely, but I can't find a standad describing the best practice for applying it or reacting to it. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 08:20:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17750 for ; Mon, 29 Nov 2004 08:20:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlWq-0000mV-2Y for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 08:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlJG-0001KC-3w; Mon, 29 Nov 2004 08:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlDV-0000A4-6m for asrg@megatron.ietf.org; Mon, 29 Nov 2004 08:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16155 for ; Mon, 29 Nov 2004 08:05:20 -0500 (EST) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlIP-0000Ke-EP for Asrg@ietf.org; Mon, 29 Nov 2004 08:10:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BAC9626C097; Mon, 29 Nov 2004 14:05:16 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 46E7326C089; Mon, 29 Nov 2004 14:05:15 +0100 (CET) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id iATD5F8q576899; Mon, 29 Nov 2004 14:05:15 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1CE95FF1C; Mon, 29 Nov 2004 14:05:15 +0100 (CET) Date: Mon, 29 Nov 2004 14:05:15 +0100 From: Stephane Bortzmeyer To: Danny Angus Message-ID: <20041129130515.GA29165@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Asrg@ietf.org Subject: [Asrg] Re: FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jk X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Mon, Nov 29, 2004 at 09:07:10AM +0000, Danny Angus wrote a message of 24 lines which said: > > autoreply messages to go to ietf@ietf.org mail list! > > I think theres a need for a simple standard to describe behaviour in > response to lists, the Precedence header is good where people implement its > use wisely, but I can't find a standad describing the best practice for > applying it or reacting to it. RFC 3834 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 09:11:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22988 for ; Mon, 29 Nov 2004 09:11:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYmKQ-000275-AS for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 09:16:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYm72-00039j-Gj; Mon, 29 Nov 2004 09:02:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYm2M-0001zI-06 for asrg@megatron.ietf.org; Mon, 29 Nov 2004 08:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21536 for ; Mon, 29 Nov 2004 08:57:53 -0500 (EST) Received: from mail78.messagelabs.com ([195.245.230.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYm7F-0001kG-NI for Asrg@ietf.org; Mon, 29 Nov 2004 09:02:59 -0500 X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1101736630!5584033!1 X-StarScan-Version: 5.4.2; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 16166 invoked from network); 29 Nov 2004 13:57:11 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-13.tower-78.messagelabs.com with SMTP; 29 Nov 2004 13:57:11 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 29 Nov 2004 13:57:09 +0000 To: Stephane Bortzmeyer X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Danny Angus Date: Mon, 29 Nov 2004 13:57:25 +0000 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 29/11/2004 13:57:09 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Asrg@ietf.org Subject: [Asrg] Re: FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jk X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Ah, I didn't know about this. Good stuff. d. |---------+----------------------------> | | Stephane | | | Bortzmeyer | | | | | | | | | 29/11/2004 01:05 | | | PM | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: Danny Angus | | cc: Asrg@ietf.org | | Subject: Re: FW: Your email requires verification verify#DzSXey5Ib5bYxjdNkwIJu 3jk | >-------------------------------------------------------------------------------------------------------------------------------| On Mon, Nov 29, 2004 at 09:07:10AM +0000, Danny Angus wrote a message of 24 lines which said: > > autoreply messages to go to ietf@ietf.org mail list! > > I think theres a need for a simple standard to describe behaviour in > response to lists, the Precedence header is good where people implement its > use wisely, but I can't find a standad describing the best practice for > applying it or reacting to it. RFC 3834 *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 12:38:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13071 for ; Mon, 29 Nov 2004 12:38:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpZI-00079V-0G for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 12:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpQy-0003zY-7l; Mon, 29 Nov 2004 12:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpJo-00029P-4w for asrg@megatron.ietf.org; Mon, 29 Nov 2004 12:28:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11382 for ; Mon, 29 Nov 2004 12:28:03 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpOf-0006qa-9R for asrg@ietf.org; Mon, 29 Nov 2004 12:33:12 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYpJb-0001FI-00 for ; Mon, 29 Nov 2004 18:27:55 +0100 Received: from c-134-89-114.hh.dial.de.ignite.net ([62.134.89.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 18:27:55 +0100 Received: from nobody by c-134-89-114.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 18:27:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 29 Nov 2004 18:26:22 +0100 Organization: Lines: 35 Message-ID: <41AB5BBE.53BC@xyzzy.claranet.de> References: <200411281854.NAA06170@ietf.org> <41AA584D.132D@xyzzy.claranet.de> <200411290227.VAA12275@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-114.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit der Mouse wrote: [SPF] > First, it's drained off a nontrivial amount of effort that > could have gone towards developing something more effective. For Gordon's idea, some kind of elaborated white listing based on the sender if I got it right, you'll need a way to identify the sender. SPF could help there (of course it's not the only or even best solution, but it's near to a "minimal" solution). And Gordon's idea sounds like Meng's "AGUPI" (assume guilty until proven innocent). Okay, that has nothing to do with SPF. > Second, because it breaks bounces SPF doesn't break bounces, it's an almost desperate attempt to save them. If I'd send a mail to your address, and that is a "traditional forwarder", and the next hop rejects the forward, because you're not allowed to forge my MAIL FROM, then I get a bounce from your forwarder. Nothing broken in this scenario. If it's a "responsible forwarder" the next hop won't reject your forward based on my sender policy. And if something else breaks in this case you own the pieces, it's your mail. > I've already had one message produce a misfire from my > automated filtering because its envelope-from was mangled by > SRS (itself a direct consequence of SPF). Just use another way to forward your mail if SRS confuses your filters, and if modifying your filters is really no option. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 13:26:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16957 for ; Mon, 29 Nov 2004 13:26:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqJf-0008Ak-U2 for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 13:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq7t-0003AQ-1D; Mon, 29 Nov 2004 13:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq77-000336-Jm for asrg@megatron.ietf.org; Mon, 29 Nov 2004 13:19:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16459 for ; Mon, 29 Nov 2004 13:19:02 -0500 (EST) Received: from main.gmane.org ([80.91.229.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqC3-00080y-CT for asrg@ietf.org; Mon, 29 Nov 2004 13:24:12 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYq74-0005LC-00 for ; Mon, 29 Nov 2004 19:19:02 +0100 Received: from c-134-89-114.hh.dial.de.ignite.net ([62.134.89.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 19:19:02 +0100 Received: from nobody by c-134-89-114.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 19:19:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 29 Nov 2004 19:16:16 +0100 Organization: Lines: 49 Message-ID: <41AB6770.1104@xyzzy.claranet.de> References: <41AA0FA4.27A@hamburg.de> <200411290223.VAA12256@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-114.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit der Mouse wrote: > STD 10 or RFC 2821 (which obsoleted 821 over three and a > half years ago) RfC 2821 _wanted_ to obsolete STD 10, describing SMTP as it is today. But obviously there's a problem with today's SMTP, that's why we are here. > As far as I can tell you are either sending a bounce > somewhere other than the envelope-from No, you send it using the Return-Path, as the name says. For the first hop MAIL FROM: you return it to me. If all is okay for this hop it becomes a MAIL FROM <@hop1,me>, and then the Return-Path is <@hop1,me>. Later <@hop2,@hop1,me> etc., essentially the same as bang paths, you can stil see it in all Usenet news articles as Path: header field. hop1 was ready to accept any bounces MAIL FROM <> RCPT TO , hop2 handled any bounces MAIL FROM <> RCPT TO <@hop1,me>, etc. It's completely useless in all "normal" cases today, because "your" side knows where its mailout to reach my MX is, and my MX knows how to find my POP3 mailbox or whatever else. It's also useless if we're both UUCP users, or if we use aliases. But forwarding to a third party was never a "normal" case, it has its own 251 and 551 result codes. In a world where MX do what the name says it's a waste of bandwidth if hop1 has to to send stuff to a completely unrelated hop2. It was a quick and dirty hack to abuse the original MAIL FROM instead of <@hop1,me> in this case, and it fired back with tera bytes of forgeries. SPF puts an end to this abuse. RfC 2821 RIP. > I want to see a specific reference. See the STD 10 quotes in: 5454 was John's answer ("quixotic quest"), where he explains why simply returning to STD 10 isn't good enough. That's of course true, and SPF doesn't try this stunt. Arguably SRS goes in this direction. Bye, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 14:39:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23215 for ; Mon, 29 Nov 2004 14:39:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrRX-0001JH-OA for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 14:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrHU-0006u2-Jk; Mon, 29 Nov 2004 14:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrGa-0006nL-Ng for asrg@megatron.ietf.org; Mon, 29 Nov 2004 14:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22468 for ; Mon, 29 Nov 2004 14:32:55 -0500 (EST) From: gep2@terabites.com Message-Id: <200411291932.OAA22468@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrLW-00018Y-2b for asrg@ietf.org; Mon, 29 Nov 2004 14:38:04 -0500 Date: Mon, 29 Nov 2004 19:32:19 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from WinProxy.anywhere (c-67-162-249-18.client.comcast.net[67.162.249.18]) by comcast.net (rwcrmhc11) with SMTP id <2004112919321901300l7kcoe>; Mon, 29 Nov 2004 19:32:19 +0000 Received: from 192.168.0.104 by 192.168.0.100 (WinProxy); Mon, 29 Nov 2004 13:30:34 -0600 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Asrg] Re: "worm spam" and SPF To: asrg@ietf.org X-Mailer: SPRY Mail Version: 04.00.06.17 X-Spam-Score: 0.4 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit >> Or, alternatively, the problem SPF "solves" is NOT the spam > problem, nor is it the worm problem. > Yes, that's true, SPF attacks the problem of forged MAIL FROM addresses and forged HELO domains. Right, but if that's the ONLY thing it does then it shouldn't be talked about as a cure for spam, since spam DOES NOT HAVE TO USE forged From addresses or forged HELO domains. > ...It's indirectly related to spam and worms at the moment, like open relays were related to the spam problem some years ago. "Indirectly related" is fine, as long as we recognize it ONLY as such. (And as such, I think it gets WAY more discussion and attention than it deserves.) >> as long as authenticated machines can be infected and > recruited to send "authenticated" worm/spam messages, SPF > and similar schemes do very little to prevent such things > It allows to find the relevant abuse desk fast, not too shabby. There are already IP-based ways to do that (at least to the upstream node(s)) based on the Received: headers, along with Traceroutes. The From: address is NOT needed. Especially for "vanity" domains, there's no point in complaining to abuse@getgreatinternetdealz.com anyhow. The spammer knows what they're doing. The place to apply pressure is the upstream node(s). > All these weird challenges / out-of-office / vacation mails won't hit innocent bystanders, if many receivers support SPF. I don't see SPF as the solution for almost ANY questions. > "Many" is good enough, spammers and worm authors won't waste their time with something not working at say AOL or behind SA. The idea of creating a confusing patchwork lattice mesh that the spam would have to work its way through is fine. But SPF is not at all difficult to defeat... you just send the mail using the infected victim's authorizations. >> undoing the DAMAGE that SPF has done > There's no "damage", if you don't like it just don't publish a sender policy. Again, you're ignoring things like discussion group/mailing lists, message digests, and so forth. Anybody who makes the mistake of supporting SPF later finds that they can't send mail using their business E-mail address when they are (say) on a cruise ship vacation or at an Internet cafe in some other country. >>> your "solution" is to get rid of MIME multipart resp. >> text/html, and mails bigger than 12 KB. >> No, not at all. > You said so in <200411280518.AAA23560@ietf.org> : Please don't misread or misrepresent what I said. >| default is to (by default) not accept messages that: | (1) are are bigger than some limited size (say 10K-25K), | (2) contain attachments, and/or (3) contain HTML > 12,000 bytes is a limit in my own "popstop" script, but it's within your size limits. Fine, it matters relatively little what value you set the limit to. The point is that there's little reason to accept "large" messages from people you've never gotten mail from before. Once they've established contact, you can (if you wish) allow them to send you bulkier stuff. >> Once the contact has been made, and the recipient trusts the > sender, *if* there is going to be an extended correspondence, > then the recipient can enable ONLY JUST the type of > bulkier/riskier content that they agree > Okay, in fact I have "special" addresses (not nobody@xyzzy) where I don't limit the size, and don't look for any TV or UE starting a base64 attachment (poor man's AV, credits to John) Sure, but of course an HTML tag that invokes an ActiveX could be just as bad. > But the UBE still sits there in my POP3 mailbox waiting for an over quota or my script. In my case, I pull and process all incoming mail from my POP3 mailboxes every 60 seconds or so. Agreed that network bandwidth would be optimized by doing the blocking higher upstream, but as an ordinary user that's tilting at windmills. Better to just fix the problem for me, and let others come along when they're ready (if ever). (I re-stage the processed mail in a local POP3 server on one of my server machines here, where mailbox space is only limited by the available space on that hard drive). > And many of the bounces and all other crap caused by forged addresses were relatively small. It can cause MAJOR problems if "hard bounces" instigated by spoofed From: addresses interacting with braindead antivirus software cause ALL your Yahoogroups to stop forwarding your mail. :-((( >> With widespread adoption > That's the problem of all FUSSPs. As you see I have no problem to mix different ideas, as far as that's possible for a normal POP3 user without the root password for the MX of his provider. The point about my permissions list approach is that *I* benefit fine, EVEN WITHOUT widespread adoption. Widespread adoption (such that spammers simply stop trying to send HTML-burdened E-mail, or attachments, knowing that the likelihood it will get through is miniscule) both reduces spam byte volume by something like 70-85% *and* makes it far harder for them to get their spam past content filters, since it denies spammers most of their most helpful tricks. But starting from Day One of a permissions list, the permissions list in conjunction with a good antivirus filter should eliminate (in E-mail, at least): 1) virtually all viruses and worms; 2) spams using text-as-image; 3) encrypted spams using Java decryption; 4) obscured and spoofed URLs; 5) malicious scripting; 6) malicious ActiveX; 7) malicious attachments. It's simple, inexpensive, readily implementable, effective, and nearly impossible to evade by technical means. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support free and fair US elections! http://stickers.defend-democracy.org 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 17:21:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19790 for ; Mon, 29 Nov 2004 17:21:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtyn-0000jo-AI for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 17:26:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYteP-0006P2-Nc; Mon, 29 Nov 2004 17:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYsA7-0006OS-HJ for asrg@megatron.ietf.org; Mon, 29 Nov 2004 15:30:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28777 for ; Mon, 29 Nov 2004 15:30:17 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYsF4-0002Ra-PF for Asrg@ietf.org; Mon, 29 Nov 2004 15:35:27 -0500 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iATKUG7W011378; Mon, 29 Nov 2004 12:30:16 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Nov 2004 12:30:16 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Stephane Bortzmeyer'" , Danny Angus Subject: RE: [Asrg] Re: FW: Your email requires verification verify#DzSXey 5Ib5bYxjdNkwIJu 3jk Date: Mon, 29 Nov 2004 12:30:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 > From: [mailto:asrg-bounces@ietf.org] On Behalf Of Stephane Bortzmeyer > On Mon, Nov 29, 2004 at 09:07:10AM +0000, > Danny Angus wrote > a message of 24 lines which said: > > > > autoreply messages to go to ietf@ietf.org mail list! > > > > I think theres a need for a simple standard to describe > behaviour in > > response to lists, the Precedence header is good where people > > implement its use wisely, but I can't find a standad describing the > > best practice for applying it or reacting to it. > > RFC 3834 No good. Why are people not reading it and acting on it? People have to stop blaming implementors for not taking the advice on offer. If you want to change the world then you have the responsibilty for convincing people of the need for change. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Nov 29 18:48:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27654 for ; Mon, 29 Nov 2004 18:48:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYvL6-0002oY-Ri for asrg-web-archive@ietf.org; Mon, 29 Nov 2004 18:53:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYv8g-0004aj-05; Mon, 29 Nov 2004 18:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYv1X-0003CR-Ej for asrg@megatron.ietf.org; Mon, 29 Nov 2004 18:33:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26602 for ; Mon, 29 Nov 2004 18:33:36 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7] ident=WHWd115uBMTknlyLYHY9kXgw0zPHdtW3virVbQzr4YJ) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYv6W-0002Vi-Ut for asrg@ietf.org; Mon, 29 Nov 2004 18:38:49 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA27656; Mon, 29 Nov 2004 18:33:34 -0500 (EST) From: der Mouse Message-Id: <200411292333.SAA27656@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Mon, 29 Nov 2004 18:30:16 -0500 (EST) To: asrg@ietf.org Subject: Re: [Asrg] Re: "worm spam" and SPF In-Reply-To: <41AB5BBE.53BC@xyzzy.claranet.de> References: <200411281854.NAA06170@ietf.org> <41AA584D.132D@xyzzy.claranet.de> <200411290227.VAA12275@Sparkle.Rodents.Montreal.QC.CA> <41AB5BBE.53BC@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit >> Second, because [SPF] breaks bounces This was a braino on my part. I meant "forwarding". >> I've already had one message produce a misfire from my automated >> filtering because its envelope-from was mangled by SRS (itself a >> direct consequence of SPF). > Just use another way to forward your mail if SRS confuses your > filters, and if modifying your filters is really no option. No, you misunderstand. This was damage done by SRS to a message that wasn't being forwarded. Apparently the envelope was SRSed before the message got bounced. (Perhaps the message was being forwarded internally, but it seems to me that shouldn't provoke SRS.) I don't entirely understand _why_ SRS got its paws on the envelope, and it may be fairer to call it an implementation bug, but it certainly wouldn't've happened without SRS, and I thus consider it to at least some extent damage done by SPF. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Nov 30 05:08:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28856 for ; Tue, 30 Nov 2004 05:08:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ50Z-00070y-HL for asrg-web-archive@ietf.org; Tue, 30 Nov 2004 05:13:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ4SM-000672-OR; Tue, 30 Nov 2004 04:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ42o-0002o1-FF for asrg@megatron.ietf.org; Tue, 30 Nov 2004 04:11:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23573 for ; Tue, 30 Nov 2004 04:11:32 -0500 (EST) Received: from mail78.messagelabs.com ([195.245.230.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZ47t-0005vt-8a for Asrg@ietf.org; Tue, 30 Nov 2004 04:16:49 -0500 X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-2.tower-78.messagelabs.com!1101805858!5636503!1 X-StarScan-Version: 5.4.2; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 32208 invoked from network); 30 Nov 2004 09:10:58 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-2.tower-78.messagelabs.com with SMTP; 30 Nov 2004 09:10:58 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Tue, 30 Nov 2004 09:10:57 +0000 Subject: RE: [Asrg] Re: FW: Your email requires verification verify#DzSXey 5Ib5bYxjdNkwIJu 3jk To: "Hallam-Baker, Phillip" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Danny Angus Date: Tue, 30 Nov 2004 09:11:17 +0000 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 30/11/2004 09:10:57 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > > RFC 3834 > No good. > Why are people not reading it and acting on it? Dare I say its because not everyone has heard of it? I'm on the Apache James PMC and I hadn't, however James will now be aware of it and will act on it. I think this is an issue where intelligent people are already doing intelligent things. But we're concerned here with implementors who don't do the sensible thing, and I suspect these same people are less likely to be aware of relevant new standards, and even less likely to quickly become compliant. Time and Awareness will cure this particular ill. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Nov 30 07:14:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10783 for ; Tue, 30 Nov 2004 07:14:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6yn-0001pU-Jo for asrg-web-archive@ietf.org; Tue, 30 Nov 2004 07:19:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6lG-0005Nl-57; Tue, 30 Nov 2004 07:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6i0-00048t-Eo for asrg@megatron.ietf.org; Tue, 30 Nov 2004 07:02:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09916 for ; Tue, 30 Nov 2004 07:02:13 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6n3-0001Yp-1I for asrg@ietf.org; Tue, 30 Nov 2004 07:07:33 -0500 Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAUCRpTJ004077 for ; Tue, 30 Nov 2004 04:27:52 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAUCRpTC004074 for ; Tue, 30 Nov 2004 04:27:51 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 30 Nov 2004 04:27:51 -0800 (PST) From: "william(at)elan.net" To: asrg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sokol.elan.net id iAUCRpTJ004077 X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable Subject: [Asrg] Introducing META Signatures (a unification of DK, IIM, MTA Signatures plus support for linking to S/MIME and PGP) X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: asrg-bounces@ietf.org Errors-To: asrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable This is information on new cryptographic mail signature proposal about which I've just posted at ietf-mailsig. This is a near-copy of that post=20 and if you have interest in talking about this more, I'd suggest it take=20 place on ietf-mailsig list (its possible in the future I'll also create=20 separate list just for META Signatures development, if that happens, I'll= =20 post about in on ASRG during next month). To subscribe to mailsig please see http://www.imc.org/ietf-mailsig/index.html ------------------------------------------------------------------------ After creating the matrix of proposals presented at last MASS Bof (see http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatr= ix.htm) I was surprised to see how much in common various proposals have, in=20 particular for almost every feature there was at least one and usually two or more other proposals that also had that feature done in similar=20 way. So I started to see if and how proposals could be put into one that=20 would allow the signer to decide what features to use and I believe I now= =20 have the beginning of such framework ready to show you.=20 This "unified" proposal's technical details are available for your review= at: http://www.elan.net/~william/emailsecurity/meta_signatures.htm (when reading it I recommend part1 first, then going immediatly to exampl= es in part3 and then if you want more technical info, go through part2) Now below will be somewhat long (for post on public list) as I'll attempt= =20 to briefly describe META Signatures syntax, if you read above webpage=20 you'll find all that info (in better details) there already. ------------------------------------------------------------------------ This signature design involved separation of signature creation in basic=20 components - email body canonicalization and hash creation, choosing what= =20 headers and how are to be included in signature, public key cryptography=20 and actual signature creation, and way algorithm for signature authorizat= ion Then I compared how different proposals do each part and which features=20 they offer. The result is that each part is now represented a separate=20 header which to a large degree made for a more structured system in my vi= ew. First part is creating a hash of email body and it basicly means adding=20 digest header. Those who want, can use good old MD5-Digest which is alrea= dy a standard, but of course MD5 is no longer considered a strong hash and=20 that header can not be used with different canonicalization algorithm,=20 so here is an introduction to new extended digest header: EDigest: v=3D1.0 a=3Dsha1 c=3Dnofws n=3D500 i=3Dsystem1.example.com t=3D1094844765.334354 d=3D"51f0483a89e441e2fc45a12a4303ca217f3461= 7e=3D"=20 In above - "a" is digest algorithm, "c" is canonicalization, "n" is=20 number of characters after canonicalization (this is optional), "t" is=20 timestamp with unique id (also optional) and "d" is actual hash data. In=20 addition to above if somebody wants a digest can also be added for=20 specific MIME part seperately (MIME part is specified by optional "m" tag= ) and that can allow to verify email even if MIME parts get rearranged by=20 some system or some deleted. Now actual signature header no longer needs to worry about email body or=20 canonicalization and represents ONLY signature of the list of headers. Some headers can be duplicated and I already described it before. I've ch= osen=20 "Saved-" prefix for adding duplicated header value and to allow for uniqu= e reference to such headers a unique id can be added right after Saved-, li= ke: Saved-1094844765338603-From: Boogyman As I already mentioned before when this is done with separate headers, it= s possible for subsequent signatures to reference existing "Saved" header=20 instead of making another duplicate. Same also true about EDigest header,= =20 i.e. once one is added if email body has not been modified, then other META signatures can reference that one EDigest header. Now finally comes the META Signature header, which does not include authorization info (this is in separate header) and so it has fairly=20 simple structure: META-Signature: v=3D1.0 a=3Drsa-sha1 s+=3Dexample.com=20 t+=3D1094844765.338603 x+=3D432000 h=3DEdigest,META*,Received*,Original*,Message-ID,Date d=3D"Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMR= F /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3= x zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4=3D" =20 In the above "s" is signer email or domain, "t and "x" are timestamp and=20 expiration like in IIM, "h" is list of headers (like in DK but it has=20 extended syntax) and 'd" is actual signature data. Where you see "+=3D" i= t=20 means the content is added as part of signature data (i.e. like signed=20 attribute in X.509). Also not shown above but possible as optional tags are "e" and "m" which are for exponent and modulus of public key if signer wants it included with the signature. Last part of the puzzle are META-Auth headers which describe how signatur= e is to be authorized/verified. The syntax for them largely comes from MTA Signatures (its called Certificate-Verification-Service there) and basicl= y=20 it desribes verification type name (which as part of it includes IANA ser= vice name) and locator info (something similar to DK's selector). Multiple=20 META-Auth headers can be included for same signature if somebody supports multiple verification types (i.e. somebody could decide to support both DK and IIM at the same time for example), this feature actually may come=20 very usefull for accreditation and reputation. One more interesting note=20 is that I found a way to use those META-Auth headers as a way to link MET= A Signature directly to S/MIME or PGP signatures (in such case locator woul= d point to correct S/MIME pkcs7-signature attachment). Here are some examples of META-Auth headers: META-Auth: s=3Ddomain:txt:dk l=3D_key1._dk t=3D1094844765.338603 META-Auth: s=3Dhttp:KRS l=3D_krs f=3Dkrs_service t=3D1094844765.33= 8603 META-Auth: s=3Dhttp:download:x509:der l=3D_certs f=3Dfilename1.cer = =20 META-Auth: s=3D::pkcs7-signature:s-mime l=3Dpkcs7-attachment-1 =20 I'll note that I'm still working on syntax, in particular possibly replac= ing locator with URL and I also working on more universal syntax for describi= ng authorization algorithm itself, I'll write more about it end of the week. Now for those of you still around, finally here are some examples of how=20 this all looks like. First one is simpler DK-style signature: META-Signature: v=3D1.0 a=3Drsa-sha1 s+=3Dfootball.example.com =20 t+=3D1094844765.338603 x+=3D432000 h=3D*=A0 d=3D"dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiY= zR=3D" META-Auth: s=3Ddomain:txt:dk l=3Dbrisbane._dk EDigest: v=3D1.0 a=3Dsha1 c=3Dsimple t=3D1094844765.334354=20 d=3D"51f0483a89e441e2fc45a12a4303ca217f34617e=3D" Second is example of MTAS-like syntax where some headers are copied and digest is not only for main body but for some mime parts (plus listed are multiple authorization methods): META-Signature: v=3D1.0 a=3Drsa-sha1 i=3Dmta.example.com s+=3Dexample.c= om t+=3D1094844765.334354 x+=3D432000 h=3DMETA-*, EDigest, Saved-*, Received, Date, Message-ID d=3D"Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4=3D" META-Auth: m=3Ddomain:key:email l=3D_key1._pk META-Auth: m=3Dhttp:download:x509:der l=3D_certs f=3Dfilename1.cer =20 EDigest: v=3D1.0 a=3Dsha1 c=3Dnofws n=3D1192 t=3D1094844765.334354 d=3D"51f0483a89e441e2fc45a12a4303ca217f34617e= =3D" EDigest: v=3D1.0 a=3Dsha1 c=3Dnofws n=3D350 m=3Dmime1-text t=3D1094844765.334354 d=3D"4j343ja134ars4390129343ajh124j33sek2424k= e=3D"=A0=A0 EDigest: v=3D1.0 a=3Dsha1 c=3Dnofws n=3D825 m=3Dmime2-html t=3D1094844765.334354 d=3D"9si343ksa43junxm343nxldo43jdruy580jyt0z9= 5pe=3D"=A0=A0 Saved-1094844765338603-From: John Doe =A0 Saved-1094844765338603-Subject: RE: Lunch And last, but not least, is an example is IIM-style (with header inclusio= n=20 syntax in safest way, so that signature would survive header reordering; I personally think chance of that being a serious problem are very low): =A0 META-Signature: v=3D1.0 a=3Drsa-sha1 i=3Diim.example.com s+=3Dexample= .com t+=3D1094844765.334354 x+=3D432000 h=3DMETA-Auth/t=3D1094844765.338603/a, EDigest/t=3D1094844765.33860= 3/a, Saved-1094844765338603-From//a, Saved-1094844765338603-Date//a, Saved-1094844765338603-Subject//a d=3D"Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF /SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4=3D" e=3D"Iw=3D=3D" m=3D"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7= =A0 674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek=3D" META-Auth: s=3Dhttp:KRS l=3D_krs f=3D"krs_service" t=3D1094844765.338= 603 EDigest: v=3D1.0 a=3Dsha1 c=3Dnofws n=3D1192 t=3D1094844765.338603 t=3D1094844765.334354 d=3D"51f0483a89e441e2fc45a12a4303ca217f34617e= =3D" Saved-1094844765338603-From: John Doe =A0 Saved-1094844765338603-Date: Fri, 10 Sep 2004 12:25:51 -0700 (PDT) Saved-1094844765338603-Subject: RE: Lunch The above flexibility and choice of what and how is to be included in=20 the signature is totally on the discretion of the signer. So if signer thinks that if any modifications are done to the message, then the signature should no longer be trusted, then just don't specify number of characters after canonicalization (dont add "n" tag), similarly if you= =20 dont want headers copied - dont do it and reference header directly. One last thing I'd like to note is that by adding hash of body in separat= e EDigest header, it becomes possible to begin to do signature verification= =20 and authorization right after the headers were received, i.e MTA can stil= l be receiving longer email body but may already be in process of getting public key from dns record and can verify that cryptography is valid. The= n after all data is received the remaining detail is to verify that SHA1 hash of EDigest was correct (which BTW can also done while message is still in process of being received). Anyway if you like what you saw above, please feel free to discuss this o= n=20 the list and I welcome all suggestions on how this can be improved furthe= r. I'd like to finish initial design within next month and have implementati= on ready by February (it may/should even be possible to reuse existing DK or= =20 IIM implementation). I also plan to submit all the above as internet draf= ts by next IETF. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg