From iane@sussex.ac.uk Wed Jul 1 03:17:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE803A6A01 for ; Wed, 1 Jul 2009 03:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkXXPkp+fflz for ; Wed, 1 Jul 2009 03:17:18 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 6F4543A6F21 for ; Wed, 1 Jul 2009 03:17:17 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:49392) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM3LXN-000L85-7F for asrg@irtf.org; Wed, 01 Jul 2009 11:17:47 +0100 Date: Wed, 01 Jul 2009 11:17:32 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090630111105.GA12502@gsp.org> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> Originator-Info: login-token=Mulberry:01WD0yrcGeoBKZqoYPxGPLsqUgvrVTB7tjzag=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 10:17:20 -0000 --On 30 June 2009 07:11:05 -0400 Rich Kulawiec wrote: > On Tue, Jun 30, 2009 at 10:55:04AM +0100, Ian Eiloart wrote: >> However, I do believe that people should take SPF records into account >> when deciding whether to generate bounce messages. > > Despite the ostentatious claims made by its originator ("Spam as a > technical problem is solved by SPF"), SPF has no anti-spam value. Given that you don't have a precise definition of spam, that's a pretty strong claim in itself. > Nor should it be used when deciding whether to generate a bounce: > the answer to that is always "no". It's far better to reject (not > to mention far simpler, with any sane MTA) and thus greatly diminish > the possibility of outscatter/backscatter spam. The point of SPF is to authenticate the sending domain. If the IP address is authorised (by the domain owner) to send mail from the sender domain, then bouncing mail into that domain isn't going to be causing backscatter, unless the domain lacks internal controls over message submission. If it does lack those internal controls, then the users of the domain can blame the domain owner. I guess there can also be issues where two distinct domains share the same outbound IP addresses, through an email service provider. In that case, the email service provider is the responsible party that needs to be held to account. They need to ensure either (a) separation of domains by outbound IP address combined with accurate SPF records, or (b) proper implementation of MSA on all the domains that they provide service for. Backscatter is a problem, but bounce messages do have advantages over 5xx error codes when it comes to communicating with the sender. For example, you can't know what the sending MTA is going to do with a 5xx error code - they might just drop it. DSNs were invented for a reason, and it's a shame to lose them entirely - even when you have reason to believe that the return-path (or at least the return-path domain) isn't forged. > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From claudio@telmon.org Wed Jul 1 03:32:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81213A68A1 for ; Wed, 1 Jul 2009 03:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkqLj4pHBvyz for ; Wed, 1 Jul 2009 03:32:28 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 67B953A67F3 for ; Wed, 1 Jul 2009 03:32:28 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+l998Q87rci1; Wed, 01 Jul 2009 12:32:48 +0200 Message-ID: <4A4B3B50.4030705@telmon.org> Date: Wed, 01 Jul 2009 12:32:48 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> <4A44F103.7010608@tana.it> <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> <4A48958D.7020701@tana.it> <4A489A75.7060005@telmon.org> <4A48C3BC.90501@tana.it> In-Reply-To: <4A48C3BC.90501@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 10:32:36 -0000 Alessandro Vesely wrote: > Well, having to collect agreements for data processing from each subject > is one of the most annoying applications of EU privacy directives. It is > as when one says: "May I ask you XYZ?" And the other one replies: "Yes, > you already did!" For email, it is possible to avoid that _that kind_ of > consent requests become entries in the recipient's INBOX. One way to do > so, considering multi-destination delivery a kind of forwarding (see > sec. 3.9 of rfc5321), is being tentatively described at > http://fixforwarding.org/. > Maybe I don't understand. If you manage to setup and agreement, then you have an existing relationship with the sender/forwarder, and this solves most of the problems, it's just a matter on how to "authenticate". If you don't, then everything will start with the sender/forwarder contacting you for permission, and you acting as a consequence. While this may be annoying for the sender, it is a way the receiver can have some control on incoming messages. Also, this forces the sender in being "convincing" in its request, instead of just being aggressive with advertising. The fact is, these procedures are usually discussed from the perspective of companies that must ask for permission (to contact unknown people with their commercial proposals), and not from the perspective of citizens that can deny this permission. But the goal of the directive is to protect the citizens from aggressive commercial practices; while providing a mean to contact people anyway is also a goal, it is a much less critical one. >> But the problem is, spammers won't be that polite, not even in Europe >> with our EU Directive :) So you will need to find a way to enforce >> compliance with this requirement for your address, that is, a way for >> the MTA to know who you authorized... > > It may be enough to provide a convenient way to do it, without enforcing > it with blocking policies. > The main problem I see with this framework, is that it seems to require the cooperation of every step between sender and receiver, and the intermediate steps taking some responsibility for what they are forwarding. Is it because of this that there was some discussion about smtp still being store and forward? However, I still prefer a more end-to-end approach. > While it seems self-evident that spammers are exempted from complying > with anti-abuse message sender common practices, many careful senders > may be classified as spammers according to the MRDW acceptation of the > term spam. "Spammers" of the latter kind are sensible to reputation > concepts and make a good faith effort to comply with common practices, > because they reason that going along with prospects' desires is more > remunerative than loosing their own reputation on questionable deeds. Well, my feeling is that good faith spammers are mostly unaware of good practices, the same way they are unaware of laws. Also, while some technical people may be willing to deal with good practices, marketing people may just count the complaints/sales ratio. And they usually rule ;) -- Claudio Telmon claudio@telmon.org http://www.telmon.org From johnl@iecc.com Wed Jul 1 05:45:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228B828C63F for ; Wed, 1 Jul 2009 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.177 X-Spam-Level: X-Spam-Status: No, score=-19.177 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUIkiyG+hZSg for ; Wed, 1 Jul 2009 05:45:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 33A3928C789 for ; Wed, 1 Jul 2009 05:30:53 -0700 (PDT) Received: (qmail 1311 invoked from network); 1 Jul 2009 12:30:55 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 1 Jul 2009 12:30:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=NpCNWk1sx09SUdgfG9AsJ9Kym9cb2wlu6ZudP8/sDqU=; b=cNUDw479XPTGgwvcDPSJS+W+bNt2tEpViTWPaOlgDQkDHbH5Iq6oBEVxSOxE26Pxq9vc600x87wBQGImdEeqRHPXxMsGW/AVou3zmoNxI/oigurdblj+BOy+I/bh6nmspmzFhBXgD4g3l9VteJnxxP6nPOOkl3Mwf2ZdLVJIHbU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=NpCNWk1sx09SUdgfG9AsJ9Kym9cb2wlu6ZudP8/sDqU=; b=bRKIe+iiKPYeAitJOq7zaogkULPOWLb6Vq6NfG7uqBoFpeonOWwqR6//hH05RvBwkfu+prQNd9tzp5o/UFZ3rjMuGXbdrzc+Xaq7S1RH7ontGPPkN+GOkWS7wjAzv/GE2lVps/dU+VARO8TyI7oChOFt9GaWBY6oAy99vI+kkxU= Date: 1 Jul 2009 12:30:54 -0000 Message-ID: <20090701123054.32980.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 12:45:10 -0000 >Backscatter is a problem, but bounce messages do have advantages over 5xx >error codes when it comes to communicating with the sender. For example, >you can't know what the sending MTA is going to do with a 5xx error code - >they might just drop it. DSNs were invented for a reason, and it's a shame >to lose them entirely - even when you have reason to believe that the >return-path (or at least the return-path domain) isn't forged. I don't think it's a very good idea to try to guess how other people's MTAs might be broken. It's true that some don't pass back 5xx codes properly, but it's equally true that some mangle or discard DSNs. The reason that DSNs were invented is that SMTP is still store and forward, and sometimes you can't tell during the SMTP session whether a delivery will subsequently fail. But if you can tell, which these days is the vast majority of the time, 5xx is cheaper and less likely to cause collateral damage. R's, John From vesely@tana.it Wed Jul 1 05:47:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3FA28C516 for ; Wed, 1 Jul 2009 05:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4PD9T+d3DUR for ; Wed, 1 Jul 2009 05:47:33 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 0F29D28C54F for ; Wed, 1 Jul 2009 05:40:57 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 01 Jul 2009 14:34:16 +0200 id 00000000005DC030.000000004A4B57C8.00004968 Message-ID: <4A4B57C8.2000207@tana.it> Date: Wed, 01 Jul 2009 14:34:16 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 12:47:34 -0000 Steve Atkins wrote: > On Jun 30, 2009, at 12:04 AM, Danny Angus wrote: >> Actually I would have liked to have included *some* definition, but >> because members of this group hold pretty entrenched opinions covering >> most possible definitions I felt that on the one hand it would be >> impossible and on the other hand it would be unnecessary. >> >> I believe that it is unnecessary for two reasons, the first being that >> this group cannot agree a definition, yet operates reasonably >> successfully, and secondly there can be an empirical test for a >> solution, even if there is no agreed definition of spam itself. In that case, the criteria draft should not give a definition at all. Instead, it should mention that proposed techniques may give the definition of the phenomenon they are intended to operate against, if necessary. A warning against incautious use of the term "spam" would be in order, since it is an undefinable term. It may or may not be useful to enumerate some of the existing definitions. > The problem arises when someone, anyone, claims that there is > One True Definition of spam. The fact that that's blatantly false > isn't the problem. That it causes hordes of people to come out of > the woodwork to argue for their One True Definition of spam, causing > yet another rerun of the Thread That Would Not Die is the problem. Agreed. However, the anti-spam endeavor should not have the tones of a religious debate. It's not. One reason why I would have liked to classify objections against a tentative definition is to understand where does that holy war spirit originate from. Is it still strong as in the MARID epoch, or has that lesson been learned? I'm not sure whether those hordes, or the thoughts that trouble them, thwart more than just definitions. (The other reason is that definitions are generally useful. They are not true or false, they define something. They may be good or bad, though. Good definitions provide constructive hints; for example, the U in UBE suggests that a technique might attempt to maintain a register of presupposed solicitations.) > (A problem that's usually best solved by killfiling anyone participating > in that sort of thread). I believe you meant fundamentalists rather than mere participants. I hope I'm not stamping on anyone's feet if I rise these questions. I do so because I can't stand the perpetual failure to effectively counter mail abuse. IMHO, it must be related to some wicked cripples that undermine anti-spam work. New solutions arouse no interest, independently of their technical content. Some bafflingly conclude that spam is a natural fact of life, that cannot be even diminished, and any solution would only alter its delivery mechanisms. Preemptive rebuttal, I don't think it's sane. Marketing may be considered a natural fact of life, if regarded as the commercial facet of Darwinian evolution. However, if direct marketing is considered spam, the "spammers-are-stupid*" entries of Rhyolite's list, hinging on the assumption that spammers won't respect RFCs, may not apply. It will be helpful for newcomers if Danny's paper will have an Introduction that explains the questions I've been tried to address above --lengthily and vaguely, as I don't know the answers myself. Bill mentioned a "dynamic equilibrium" in [1], depicting a chronic syndrome that can only be alleviated by a "really big push". Even if that's not a satisfactory answer, his words help understanding the problem. -- [1 http://www.ietf.org/mail-archive/web/asrg/current/msg15369.html] From iane@sussex.ac.uk Wed Jul 1 06:35:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8302A3A6ABE for ; Wed, 1 Jul 2009 06:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxin-Fg6piZe for ; Wed, 1 Jul 2009 06:35:08 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 817BB3A69DD for ; Wed, 1 Jul 2009 06:35:07 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:52048) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM3V39-000E1N-BC for asrg@irtf.org; Wed, 01 Jul 2009 14:35:33 +0100 Date: Wed, 01 Jul 2009 14:34:43 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <5E322E9DBA384C03215D830F@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <20090701123054.32980.qmail@simone.iecc.com> References: <20090701123054.32980.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01MzsTypycgS90qGcsn2GmsIY9mbM0JJZhqKY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:35:09 -0000 --On 1 July 2009 12:30:54 +0000 John Levine wrote: > But if you can tell, which these > days is the vast majority of the time, 5xx is cheaper and less likely > to cause collateral damage. > Absolutely true, and I certainly don't advocate sending DSNs when you know that its going to cause backscatter - eg, when you get an SPF fail. But, what good reason is there for NOT using a DSN when you get an SPF pass? -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Wed Jul 1 07:31:49 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC8E28C554 for ; Wed, 1 Jul 2009 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFDQb1N41eRu for ; Wed, 1 Jul 2009 07:31:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A115A28C579 for ; Wed, 1 Jul 2009 07:30:33 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 01 Jul 2009 16:20:13 +0200 id 00000000005DC030.000000004A4B709D.000057A8 Message-ID: <4A4B709C.2000109@tana.it> Date: Wed, 01 Jul 2009 16:20:12 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> In-Reply-To: <20090630200150.GL57980@verdi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:31:49 -0000 John Leslie wrote: >> In facts, we don't even have a term for "the accountable party related >> to an IP address". > > Are you sure that's a useful concept? Not at all. However, after noting that per-user accountability in the pgp/smime sense cannot be used for general email, the tendency seems to look after the IP address of the transmitters, much like pinching hackers on the fly is sometimes shown on the movies. > The CSV paradigm is that the operator of a MTA should exercise some > responsibility for what is sends. The HELO string identifies the MTA > (though not necessarily one string exclusively by one MTA), and the > DNS management for that domain-name string states whether that domain > exercises responsibility (and by automatic return of A)ddress RRs on > SRV queries, what IP address(es) that MTA uses). The link from the MTA to its operator is still missing. > While this perhaps comes "close", it's not designating an "accountable > party"; and the IP address is related to the HELO string, not the other > way around. It does _not_ lead to an "accountable party" -- it merely > associates a reference string (the domain name) that we can use as a > query to reputation services. To this end, I'd prefer the use of a domain name. One reason is that large ESP have many MTAs that can be used interchangeably. In addition, the person responsible for an MTA is not always identifiable (in Italy, the mandate to state who are the sysadmins of an MTA is being procrastinated every few months, since November 2008.) By contrast, domain registrants often have whois records pointing to them. >> Rfc5068 >> associates accountability after submission with traceability features >> of the MSA, apparently suggesting that the first relaying thereafter >> is from an IP which is (indirectly) accountable for the message content. > > Actually, > " > " Relaying and delivering employ policies that occur after submission and > " are outside the scope of this document. > > RFC5068 deals with the operation of Mail Submission Agents. I don't agree > it even "suggests" how accountability should follow the message as it > winds its way to the recipient. It does. Notwithstanding the sentence you quoted, there is a "Submission Accountability after Submission" paragraph in section 3.1, saying For a reasonable period of time after submission, the message SHOULD be traceable by the MSA operator to the authenticated identity of the user who sent the message. A similar norm is mandated by anti-terrorism regulations, in the EU at least. That way, accountability could be theoretically traced, _if_ the first submission followed those guidelines. While I can be reasonably sure that the connecting client is not an open relay, after IP based DNSBL, I have no means to know that the site either enforces the submission protocol in general, or did so for at least the messages it is about to relay. Thus, it turns out that if an MTA does mixed MSA and old fashioned port 25 relaying for its clients, its IP cannot convey accountability. From dotzero@gmail.com Wed Jul 1 07:44:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898813A6858 for ; Wed, 1 Jul 2009 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0g8m1V0dqxA for ; Wed, 1 Jul 2009 07:44:36 -0700 (PDT) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by core3.amsl.com (Postfix) with ESMTP id 6D45C3A694A for ; Wed, 1 Jul 2009 07:44:11 -0700 (PDT) Received: by vwj3 with SMTP id 3so400858vwj.15 for ; Wed, 01 Jul 2009 07:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0xvn4k1ELSbEiTwVA/az1qUt4Ob4eMpIvhc69mKEeVw=; b=s38HS+TGDEf8pD7LoFKKUuTdq6MzAHPvKoHqwuJ/gw3N6mpilZVIhhVmmfdxlXv37A B003LHzX3WZhjl5GXEKXsbKzv2lDw80kd94mgkO4HhtAF3Da7fmiIvOD0CGs1JqQn1eF XfxKF6Gp1dCUGiD0vUZ750BK1eoVAuLjN2omA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=k4/Iov0w/XPuKYdEVfBoZZ8XDeIQ7xzAHRp6Ks71t5OAOCcbLu8Zo9XBQIRPi9RNAU y7MmhRUhcjdAk2z/2AHgkUdTjyB/cnl/VKfa2aNJ7R0DHKbiZqEgb6cUjFMrG8sB4sEL kI4uWdbmEc0eLWpKhIp0fbJOeqoNZFDFSXKu8= MIME-Version: 1.0 Received: by 10.220.94.21 with SMTP id x21mr9139918vcm.88.1246459352764; Wed, 01 Jul 2009 07:42:32 -0700 (PDT) In-Reply-To: <4A4B709C.2000109@tana.it> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> Date: Wed, 1 Jul 2009 10:42:32 -0400 Message-ID: <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:44:37 -0000 On Wed, Jul 1, 2009 at 10:20 AM, Alessandro Vesely wrote: > > Thus, it turns out that if an MTA does mixed MSA and old fashioned port 25 > relaying for its clients, its IP cannot convey accountability. > The fact that it cannot (may not?) convey accountability does not mean that it cannot or should not be held accountable for what it emits. From claudio@telmon.org Wed Jul 1 07:45:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12823A6F3B for ; Wed, 1 Jul 2009 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMXXj1X14nPp for ; Wed, 1 Jul 2009 07:45:06 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id A16353A6F38 for ; Wed, 1 Jul 2009 07:45:05 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+a1X5RkwEqfL; Wed, 01 Jul 2009 15:15:52 +0200 Message-ID: <4A4B6188.90708@telmon.org> Date: Wed, 01 Jul 2009 15:15:52 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> <4A4B57C8.2000207@tana.it> In-Reply-To: <4A4B57C8.2000207@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:45:07 -0000 Alessandro Vesely wrote: > (The other reason is that definitions are generally useful. They are not > true or false, they define something. The problem is, trying to define a term that is already in use with many different meanings, often subjective. For most, this is just redefining the term with a different meaning. It's somehow the same problem that GNU has with "free". In that case, someone just decided to define a new term (open source), which spread quickly and is now much better understood. Not that I'm suggesting to define a new term for spam, since the term is already too widespread (and MRDW is horrible :), just to say that the problem may have no solution. > Marketing may be considered a natural fact of > life, if regarded as the commercial facet of Darwinian evolution. Well, everything that is "Darwinian" is subject to competition and, eventually, to extinction :) Extinction is not just a consequence of more competitive species, but also of changes in the environment :) Hopefully -- Claudio Telmon claudio@telmon.org http://www.telmon.org From Jose-Marcio.Martins@mines-paristech.fr Wed Jul 1 07:45:38 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84363A6F3F for ; Wed, 1 Jul 2009 07:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FIL7gBrochH for ; Wed, 1 Jul 2009 07:45:37 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 6E3FD3A68DB for ; Wed, 1 Jul 2009 07:45:37 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n61EiKqX012189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jul 2009 16:44:20 +0200 (MEST) Message-ID: <4A4B76C8.3080602@mines-paristech.fr> Date: Wed, 01 Jul 2009 16:46:32 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> In-Reply-To: <4A4A879D.80008@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A4B7644.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A4B7644.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:45:38 -0000 Claudio Telmon wrote: > Jose-Marcio Martins da Cruz wrote: > > I need some more clarification on this, maybe it's just me not knowing > enough about MTAs internals. As the border MTA receives a RCPT TO for > either of these addresses, it should be able to know if it is a valid > address. In my (very limited) experience, this means that each of these > addresses mut be defined as a valid address, the MTA doesn't have rules > to decide that since jose-marcio.martins_da_cruz is a valid address, > jose-marcio.martins must be valid too. So, if each of these addresses is > individually defined in some list/database accessed by the MTA, then > with the same rules, the related token database should be accessed too. > Should an "automatic aliasing" rule exist, then the same rule could > exist for the token database. Also, if "somewhere" an alias is defined > for an address, then the correspondent database could just be a pointer > to the database of the "main" address. This could even implement "chains > of aliases" as "chains of pointers to token databases". The border MTA surely knows a list of valid addresses, but it may not know, all the time, that all this addresses resolve to the same login - sometimes some addresses are resolved in the final internal servers. But well, you can find some organisations with this kind of thing nowadays. Don't know if this shall be taken into account to design future systems. > I think this is feasible with an appropriate address book manager. > Anyway, the load is for the MUA, not for the MTA, so the number of users > shouldn't matter. Hmmm. If the border MTA accept and the MUA reject by lack of consent, a bounce is generated. -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@mines-paristech.fr From john@jlc.net Wed Jul 1 08:02:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A28B3A6F49 for ; Wed, 1 Jul 2009 08:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2fQ8uKjrXpE for ; Wed, 1 Jul 2009 08:02:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 73BAC28C5B9 for ; Wed, 1 Jul 2009 08:00:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7968733CD2; Wed, 1 Jul 2009 11:00:32 -0400 (EDT) Date: Wed, 1 Jul 2009 11:00:32 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090701150032.GB15652@verdi> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:02:35 -0000 Ian Eiloart wrote: > > The point of SPF is to authenticate the sending domain. I don't believe SPF does any such thing. Domains can publish SPF RRs, but those can't reasonably be said to "authenticate" anything, least of all the "sending domain." > If the IP address is authorised (by the domain owner) to send mail from > the sender domain, That's closer... But I'd argue that no SPF construct "authorizes" sending email. In practice, I think it's quite clear that SPF constructs merely express probabilities. > then bouncing mail into that domain isn't going to be causing backscatter, > unless the domain lacks internal controls over message submission. Of course, rather few domains other than corporate domains with administrators more-than-average familiar with SMTP have reasonable "internal controls over message submission". :^( > If it does lack those internal controls, then the users of the domain > can blame the domain owner. Indeed they can... does that actually accomplish anything? > I guess there can also be issues where two distinct domains share the > same outbound IP addresses, through an email service provider. Indeed, that is common... > In that case, the email service provider is the responsible party that > needs to be held to account. (which, BTW, is what CSV set out to do...) > They need to ensure either (a) separation of domains by outbound IP > address combined with accurate SPF records, Assuming they control either multiple IP addresses _or_ the SPF records is risky. But even if they did, how would this lead to assigning the responsibility correctly? > or (b) proper implementation of MSA on all the domains that they > provide service for. That is at least practial... But how does it lead to assigning the responsibility correctly? -- John Leslie From dotzero@gmail.com Wed Jul 1 08:11:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3FE3A68DD for ; Wed, 1 Jul 2009 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipLCCzfs6STs for ; Wed, 1 Jul 2009 08:11:51 -0700 (PDT) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by core3.amsl.com (Postfix) with ESMTP id 85DA43A67AF for ; Wed, 1 Jul 2009 08:11:51 -0700 (PDT) Received: by vwj3 with SMTP id 3so412721vwj.15 for ; Wed, 01 Jul 2009 08:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5ZD791V9oUCBxqUl+IlzT1zPdTsZnXvbAeEl83/pRgw=; b=DOgadT07PJiGBwwl8Pr+dshTw5JLGVTmWKmVxeFWAaDaRmRwTixbfOpDlB351m4xCe UkbgP3z+8RlHkIWVKOzGBJyN3lhSWKZKSQohEfirQ7Fjn9GUG6xK68wBFLynqCC8I0CD G4UNrY9d00Kx0MRYbu4vj33NOADQF0EZkbXBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=R+3q8XifLFMLHzsV9orPL8o56r24ij6mq7I3VLN6hRsnAklmLdBRRwO5tSHXMJ+xHm 6r+JkqKFQYOloBjf6kRwVa1Fg9O9yjadC6GNsWPjBDtRmZ2RtoCB9AzUP6hY73pb8reh TqoStonzINtlFXxDeGVAYQu7shJNH1ZLgjeYE= MIME-Version: 1.0 Received: by 10.220.45.84 with SMTP id d20mr9115473vcf.90.1246461133074; Wed, 01 Jul 2009 08:12:13 -0700 (PDT) In-Reply-To: <20090701150032.GB15652@verdi> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> Date: Wed, 1 Jul 2009 11:12:13 -0400 Message-ID: <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:11:52 -0000 On Wed, Jul 1, 2009 at 11:00 AM, John Leslie wrote: > > =A0 That's closer... But I'd argue that no SPF construct "authorizes" > sending email. In practice, I think it's quite clear that SPF constructs > merely express probabilities. > What is the probability that you will receive legitimate email originating from ibm.com? ibm.com text =3D "v=3Dspf1 -all" From vesely@tana.it Wed Jul 1 08:29:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A95D3A6F3A for ; Wed, 1 Jul 2009 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STR+Df80qVlp for ; Wed, 1 Jul 2009 08:29:07 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 990BD3A67AD for ; Wed, 1 Jul 2009 08:29:07 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 01 Jul 2009 17:28:16 +0200 id 00000000005DC031.000000004A4B8090.000060BE Message-ID: <4A4B8090.5000507@tana.it> Date: Wed, 01 Jul 2009 17:28:16 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> In-Reply-To: <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:29:08 -0000 Dotzero wrote: >> Thus, it turns out that if an MTA does mixed MSA and old fashioned port 25 >> relaying for its clients, its IP cannot convey accountability. > > The fact that it cannot (may not?) convey accountability does not mean > that it cannot or should not be held accountable for what it emits. I understand the 2nd "it" as referring to the MTA, not the IP address. It doesn't make much difference, since both of them are objects. AFAICS, the point is to hold _someone_ accountable, so that it might be theoretically possible to claim damage, in case. It is like an insurance, and postmasters tend to stipulate it with IP numbers rather than DNS names. Why? From john@jlc.net Wed Jul 1 08:44:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A8A3A67AF for ; Wed, 1 Jul 2009 08:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGOzbyD+UmDt for ; Wed, 1 Jul 2009 08:44:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id AE4333A6F36 for ; Wed, 1 Jul 2009 08:44:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 546AC33CE3; Wed, 1 Jul 2009 11:43:14 -0400 (EDT) Date: Wed, 1 Jul 2009 11:43:14 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090701154314.GC15652@verdi> References: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4B709C.2000109@tana.it> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:44:18 -0000 Alessandro Vesely wrote: > John Leslie wrote: > >> The CSV paradigm is that the operator of a MTA should exercise some >> responsibility for what is sends. The HELO string identifies the MTA >> (though not necessarily one string exclusively by one MTA), and the >> DNS management for that domain-name string states whether that domain >> exercises responsibility (and by automatic return of A)ddress RRs on >> SRV queries, what IP address(es) that MTA uses). > > The link from the MTA to its operator is still missing. CSV doesn't try to enforce any particular link, but that doesn't imply there is none. >> While this perhaps comes "close", it's not designating an "accountable >> party"; and the IP address is related to the HELO string, not the other >> way around. It does _not_ lead to an "accountable party" -- it merely >> associates a reference string (the domain name) that we can use as a >> query to reputation services. > > To this end, I'd prefer the use of a domain name. One reason is that > large ESP have many MTAs that can be used interchangeably. In > addition, the person responsible for an MTA is not always identifiable > (in Italy, the mandate to state who are the sysadmins of an MTA is > being procrastinated every few months, since November 2008.) By > contrast, domain registrants often have whois records pointing to them. I think I'm catching on: you want to link the MTA to a _registered_ domain. You should, IMHO, say so in the I-D: "domain" by itself doesn't convey the idea of "registered domain". >> RFC5068 deals with the operation of Mail Submission Agents. I don't agree >> it even "suggests" how accountability should follow the message as it >> winds its way to the recipient. > > It does. Notwithstanding the sentence you quoted, there is a > "Submission Accountability after Submission" paragraph in section 3.1, > saying > > For a reasonable period of time after submission, the message > SHOULD be traceable by the MSA operator to the authenticated > identity of the user who sent the message. This deals _only_ with logging practices (or whatever magic) of the operators of the Mail Submission Agent -- it implies nothing about MTAs that may relay the message. > A similar norm is mandated by anti-terrorism regulations, in the EU at > least. Indeed, various jurisdictions write laws and regulations. We should allow for them wherever practical, but we can't adopt an international standard to every jurisdiction's laws and regulations. > That way, accountability could be theoretically traced, _if_ the first > submission followed those guidelines. While I can be reasonably sure > that the connecting client is not an open relay, after IP based DNSBL, > I have no means to know that the site either enforces the submission > protocol in general, or did so for at least the messages it is about > to relay. I do not believe that you'll know any better by linking to a registered domain, but YMMV. I will stipulate that in the absence of a reputation service, the _explicit_ link to a registered domain gives a bit more clout to an assumption that the domain registration information is a "responsible party"; but neither domain registrars nor the VHLO draft would enforce much of anything. :^( -- John Leslie From Jose-Marcio.Martins@mines-paristech.fr Wed Jul 1 09:31:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6947728C0F2 for ; Wed, 1 Jul 2009 09:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS1USrEm8QvW for ; Wed, 1 Jul 2009 09:31:08 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 31E8F3A6A66 for ; Wed, 1 Jul 2009 09:31:07 -0700 (PDT) Received: from localhost.localdomain (joe.j-chkmail.org [88.168.143.55]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n61GUThu012922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 18:30:29 +0200 (MEST) Message-ID: <4A4B8FA9.3080905@mines-paristech.fr> Date: Wed, 01 Jul 2009 18:32:41 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Claudio Telmon References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> <4A4B8D9F.9000000@telmon.org> In-Reply-To: <4A4B8D9F.9000000@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A4B8F25.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A4B8F25.000/88.168.143.55/joe.j-chkmail.org/localhost.localdomain/ Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:31:09 -0000 Claudio Telmon wrote: > Jose-Marcio Martins da Cruz wrote: >> Claudio Telmon wrote: > > Surely, but that's not what I mean. Once the address book manager knows > that it must handle a list of (receiver) addresses aliases that will > share the same tokens, it will push those tokens to the MTA, so that the > MTA will have a valid list of tokens for the various aliases and reject > messages as required. This means defining some new protocol between the MTA and MUAs to push these tokens ??? Don't know exactly what/how you're intending with this, but the more complicated you imagine things, the less probable is it to be widely accepted. From claudio@telmon.org Wed Jul 1 09:50:11 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB09628C58D for ; Wed, 1 Jul 2009 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOalSrbvy3P8 for ; Wed, 1 Jul 2009 09:50:11 -0700 (PDT) Received: from slim-2c.inet.it (slim-2c.inet.it [213.92.5.123]) by core3.amsl.com (Postfix) with ESMTP id 79CA128C562 for ; Wed, 1 Jul 2009 09:48:41 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-2c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+FnHsimNSJv2; Wed, 01 Jul 2009 18:48:05 +0200 Message-ID: <4A4B9345.8060705@telmon.org> Date: Wed, 01 Jul 2009 18:48:05 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> <4A4B8D9F.9000000@telmon.org> <4A4B8FA9.3080905@mines-paristech.fr> In-Reply-To: <4A4B8FA9.3080905@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:50:12 -0000 Jose-Marcio Martins da Cruz wrote: > This means defining some new protocol between the MTA and MUAs to push > these tokens ??? > Yes, this is a critical part of the framework since the beginning :) > Don't know exactly what/how you're intending with this, but the more > complicated you imagine things, the less probable is it to be widely > accepted. > I know. However, this is the part of the framework that I see as least critical in terms of acceptance. Both the MUA and the MTA will need some add-on/patch/whatever in order to implement the protocol, so this part of the framework will come "with the patch". While I have a couple of ideas on how this could be accomplished, the MTA token database management issue is one of the two I'm still looking for comments, the other being whether it is true that spam in "small text messages" would be easier/lighter to deal with by antispam tools. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From dotzero@gmail.com Wed Jul 1 09:55:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C558F3A682E for ; Wed, 1 Jul 2009 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3bBbshLJq6N for ; Wed, 1 Jul 2009 09:55:48 -0700 (PDT) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by core3.amsl.com (Postfix) with ESMTP id DE8033A67F6 for ; Wed, 1 Jul 2009 09:55:47 -0700 (PDT) Received: by vwj3 with SMTP id 3so453363vwj.15 for ; Wed, 01 Jul 2009 09:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gQaS8w1Zjfxa6Onwu9ERkT2n39FXWBqA/iuDTntnMA0=; b=xk+UDGkMF6GJc9evStc99To6/Nfh74gXM8jZZeRoTpaXv/dE30fa/KstM+HiphCFwl faWAk4xT80ReOm/QEkjgsVq3sK1wnkCKKjYTUI5+O/SPWrQQhpARZI42/wngqw8fsQ9+ 9bTDGFATm1QYNSVFn43aI/3NlYhxXuHYAGk/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JvYlFNBrZUZQm0wwx9DApO5VkzeAwdRGsDdGZAQB9ALu9PuV5FKnUYyjHeoeL9vo0Y 0sZ8jv+9zDQAvIiVmwu2/1b8tiVMc5XDblVnSNl/iBHp1kZVj+RML8oV6MeMyiaCYLjL AcCEnxmNaB1arH7B6R6R596yNEvEK1sPtHUCM= MIME-Version: 1.0 Received: by 10.220.90.199 with SMTP id j7mr8897123vcm.57.1246467303139; Wed, 01 Jul 2009 09:55:03 -0700 (PDT) In-Reply-To: <4A4B8090.5000507@tana.it> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> <4A4B8090.5000507@tana.it> Date: Wed, 1 Jul 2009 12:55:02 -0400 Message-ID: <7ae58c220907010955u21cfb34n19d85f487e70fc56@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:55:48 -0000 On Wed, Jul 1, 2009 at 11:28 AM, Alessandro Vesely wrote: > Dotzero wrote: >>> >>> Thus, it turns out that if an MTA does mixed MSA and old fashioned port >>> 25 >>> relaying for its clients, its IP cannot convey accountability. >> >> The fact that it cannot (may not?) convey accountability does not mean >> that it cannot or should not be held accountable for what it emits. > > I understand the 2nd "it" as referring to the MTA, not the IP address. It > doesn't make much difference, since both of them are objects. AFAICS, the > point is to hold _someone_ accountable, so that it might be theoretically > possible to claim damage, in case. It is like an insurance, and postmasters > tend to stipulate it with IP numbers rather than DNS names. Why? IP Addresses are used rather than DNS names because it is significantly easier to dump a domain name and use a new one than to dump an IP address (range) and migrate to another unless there are compromised hosts involved. IP Addresses tend to be more trackable and ultimately tied to an ISP (even if that carrier is an upstream). I tend to think less in terms of legal and claiming damage and more along the lines of self help. Drop route (or the milder form of reject SMTP connections) tends to have a significant impact on what one deals with from abusive IP space. I don't necessarily recommend this as the first response but if one does not get a response from an abuse contact..... From claudio@telmon.org Wed Jul 1 10:44:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B78E3A69C5 for ; Wed, 1 Jul 2009 10:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AShhCZmBUvaK for ; Wed, 1 Jul 2009 10:44:13 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id D20573A67F6 for ; Wed, 1 Jul 2009 10:44:12 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+5A2eTQ6sXla; Wed, 01 Jul 2009 18:23:59 +0200 Message-ID: <4A4B8D9F.9000000@telmon.org> Date: Wed, 01 Jul 2009 18:23:59 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> In-Reply-To: <4A4B76C8.3080602@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 17:44:14 -0000 Jose-Marcio Martins da Cruz wrote: > Claudio Telmon wrote: >> Jose-Marcio Martins da Cruz wrote: > >> >> I need some more clarification on this, maybe it's just me not knowing >> enough about MTAs internals. As the border MTA receives a RCPT TO for >> either of these addresses, it should be able to know if it is a valid >> address. In my (very limited) experience, this means that each of these >> addresses mut be defined as a valid address, the MTA doesn't have rules >> to decide that since jose-marcio.martins_da_cruz is a valid address, >> jose-marcio.martins must be valid too. So, if each of these addresses is >> individually defined in some list/database accessed by the MTA, then >> with the same rules, the related token database should be accessed too. >> Should an "automatic aliasing" rule exist, then the same rule could >> exist for the token database. Also, if "somewhere" an alias is defined >> for an address, then the correspondent database could just be a pointer >> to the database of the "main" address. This could even implement "chains >> of aliases" as "chains of pointers to token databases". > > The border MTA surely knows a list of valid addresses, but it may not > know, all the time, that all this addresses resolve to the same login - > sometimes some addresses are resolved in the final internal servers. > > But well, you can find some organisations with this kind of thing > nowadays. Don't know if this shall be taken into account to design > future systems. > >> I think this is feasible with an appropriate address book manager. >> Anyway, the load is for the MUA, not for the MTA, so the number of users >> shouldn't matter. > > Hmmm. If the border MTA accept and the MUA reject by lack of consent, a > bounce is generated. Surely, but that's not what I mean. Once the address book manager knows that it must handle a list of (receiver) addresses aliases that will share the same tokens, it will push those tokens to the MTA, so that the MTA will have a valid list of tokens for the various aliases and reject messages as required. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From vesely@tana.it Wed Jul 1 11:38:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272BE3A6804 for ; Wed, 1 Jul 2009 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64bepyJz8IQ0 for ; Wed, 1 Jul 2009 11:38:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id DE17E3A6A8D for ; Wed, 1 Jul 2009 11:37:16 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 01 Jul 2009 20:37:38 +0200 id 00000000005DC02F.000000004A4BACF2.00007D81 Message-ID: <4A4BACF1.2030609@tana.it> Date: Wed, 01 Jul 2009 20:37:37 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <20090701154314.GC15652@verdi> In-Reply-To: <20090701154314.GC15652@verdi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:38:45 -0000 John Leslie wrote: >> >> [For accountability, I'd use] a domain name. One reason is that >> large ESP have many MTAs that can be used interchangeably. In >> addition, the person responsible for an MTA is not always identifiable >> (in Italy, the mandate to state who are the sysadmins of an MTA is >> being procrastinated every few months, since November 2008.) By >> contrast, domain registrants often have whois records pointing to them. > > I think I'm catching on: you want to link the MTA to a _registered_ > domain. Yup. However, no official registration exists for, say, us.ibm.com or it.ibm.com. The latter two ones happen to have different hostmaster addresses, therefore it would not be correct for them to share the same accountability token "ibm.com". I can only trust the DNS about the legitimacy of such subdomain delegations. OTOH, I don't know from the DNS whether a domain is registered at a reputable registry. > You should, IMHO, say so in the I-D: "domain" by itself doesn't > convey the idea of "registered domain". Thanks, I will. >>> RFC5068 deals with the operation of Mail Submission Agents. I don't agree >>> it even "suggests" how accountability should follow the message as it >>> winds its way to the recipient. >> >> It does. Notwithstanding the sentence you quoted, there is a >> "Submission Accountability after Submission" paragraph in section 3.1, >> saying >> >> For a reasonable period of time after submission, the message >> SHOULD be traceable by the MSA operator to the authenticated >> identity of the user who sent the message. > > This deals _only_ with logging practices (or whatever magic) of the > operators of the Mail Submission Agent -- it implies nothing about > MTAs that may relay the message. I thought "traceable" implied there is some token, such as Message-ID, that is logged on both submission and relay, so that one can retrace the path that a message took. Or would that have been termed "trackable", or whatever, instead? > I do not believe that you'll know any better by linking to a > registered domain, but YMMV. Agreed. If it is neither worse, it can be used interchangeably with IP based info, depending on convenience. From jdfalk-lists@cybernothing.org Wed Jul 1 12:12:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1AC28C130 for ; Wed, 1 Jul 2009 12:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viMaJxcuaZbn for ; Wed, 1 Jul 2009 12:12:20 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id BB53E28C542 for ; Wed, 1 Jul 2009 12:09:12 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n61J9QL9023215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Jul 2009 13:09:28 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n61J9QL9023215 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1246475368; bh=6ZYGFLM+fTjfklQONEcEUoJFjuam/59/WUW/kCd8 B8E=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=mFVBstAsrUmxlbey+occCRHQxhszTksDKygVP 9aTgUuVz3E6ALD63MaZUnSzvjzDdVC1XAf8IfqeD8NWJcbrsOl9lHjUGn3WDHBNKP02 WboTfCONOY/uc30v4G1/rEyq0JAmqt91eIjSa4OTZTBBkHCK+EzgmEjumnPyQ8kyMg0 = Message-ID: <4A4BB460.9020205@cybernothing.org> Date: Wed, 01 Jul 2009 13:09:20 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:12:21 -0000 Steve Atkins wrote: > (A problem that's usually best solved by killfiling anyone participating > in that sort of thread). If we're going to go back to first principles, how 'bout discussing the purpose of the ASRG? I joined thinking the word "research" was in there somewhere, but it's clear there's no research going on -- and none likely to occur. So, what's this group for? Why are we all participating in it? -- J.D. Falk From dotis@mail-abuse.org Wed Jul 1 12:13:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2915428C108 for ; Wed, 1 Jul 2009 12:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmfxtkOgQS8m for ; Wed, 1 Jul 2009 12:13:04 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 96A263A6A8D for ; Wed, 1 Jul 2009 12:12:56 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CBE1BA94439 for ; Wed, 1 Jul 2009 19:13:15 +0000 (UTC) Message-Id: <3F8B6DF0-03CF-4184-BB55-AE30E1E4345A@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 12:13:15 -0700 References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:13:05 -0000 On Jul 1, 2009, at 3:17 AM, Ian Eiloart wrote: > The point of SPF is to authenticate the sending domain. SPF(email-address)->pass provides authorization for Outbound MTAs. The rationale for offering SPF authorization might be to improve message acceptance or DSN rates, as recommended by AOL and MSN for example. It would be risky to conclude SPF(email-address)->pass means other domains did not provide assess to the originator of the message. It is fundamentally wrong to hold the wrong entity accountable. > If the IP address is authorised (by the domain owner) to send mail > from the sender domain, then bouncing mail into that domain isn't > going to be causing backscatter, unless the domain lacks internal > controls over message submission. If it does lack those internal > controls, then the users of the domain can blame the domain owner. SPF(email-address)->fail might only indicate a message had been forwarded. Use of RFC 3464 and minimal DSN content with"multipart/ report" content types should occur irrespective of the SPF results when messages are returned post acceptance. Nor should one assume SPF authorization fairly assigns blame for poor administration of Outbound MTAs. How many ESPs even offer SLAs that ensure domain exclusivity when handling tens of thousands of domains? > I guess there can also be issues where two distinct domains share > the same outbound IP addresses, through an email service provider. > In that case, the email service provider is the responsible party > that needs to be held to account. They need to ensure either (a) > separation of domains by outbound IP address combined with accurate > SPF records, or (b) proper implementation of MSA on all the domains > that they provide service for. Use of verified EHLO IP address information should only be claimed by a _few_ domains over a period of time. Seeing too many likely indicates the presence of a NAT, compromised systems, or both. The domain providing stewardship over access to Outbound MTA should be assessed separately from domains that have purportedly originated the messages. Even a cryptographically strong scheme like DKIM will not mitigate replay abuse, while it does help mitigate phishing. On the other hand, SPF might enable convincing phish whenever SPF(email- address)->pass is assumed to authenticate domain sources. It does not! > Backscatter is a problem, but bounce messages do have advantages > over 5xx error codes when it comes to communicating with the sender. > For example, you can't know what the sending MTA is going to do with > a 5xx error code - they might just drop it. DSNs were invented for a > reason, and it's a shame to lose them entirely - even when you have > reason to believe that the return-path (or at least the return-path > domain) isn't forged. Best practices should reduce DSNs, often by ensuring immediate rejection is enabled where possible. Many of the DSNs from legitimate Inbound MTAs occur as a result of valid users not being known by border MTAs. Those appear to be mostly from poorly integrated hybrid systems protecting an Exchange Server or offering stand-alone inbound filtering services. -Doug From dotis@mail-abuse.org Wed Jul 1 14:43:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB813A68FA for ; Wed, 1 Jul 2009 14:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9FN09hL3i6l for ; Wed, 1 Jul 2009 14:43:19 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 1FB193A6B14 for ; Wed, 1 Jul 2009 14:43:19 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id A212AA9443A for ; Wed, 1 Jul 2009 21:43:40 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A4B709C.2000109@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 14:43:40 -0700 References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:43:19 -0000 On Jul 1, 2009, at 7:20 AM, Alessandro Vesely wrote: > John Leslie wrote: >> The CSV paradigm is that the operator of a MTA should exercise some >> responsibility for what is sends. The HELO string identifies the >> MTA (though not necessarily one string exclusively by one MTA), and >> the DNS management for that domain-name string states whether that >> domain exercises responsibility (and by automatic return of >> A)ddress RRs on SRV queries, what IP address(es) that MTA uses). > > The link from the MTA to its operator is still missing. Disagree. Based on our results, when only a few domains publish an IP addresses of an Outbound MTA, it is rather safe to assume the domains represented by verified EHLO information resolve who is administrating the MTA. When there are many domains, this appears to represent either MTAs operating behind a NAT, or compromised systems; sometimes both. It appears to be rare for legitimate Outbound MTAs to change domain affiliations. From a reputation standpoint, verified EHLO information offers stable identifiers in which to effectively and efficiently manage email abuse. This method should scale since it establishes management hierarchy. > To this end, I'd prefer the use of a domain name. One reason is that > large ESP have many MTAs that can be used interchangeably. In > addition, the person responsible for an MTA is not always > identifiable (in Italy, the mandate to state who are the sysadmins > of an MTA is being procrastinated every few months, since November > 2008.) By contrast, domain registrants often have whois records > pointing to them. While larger ISPs are likely to have a few hundred outbound MTAs, they represent a very small percentage of overall legitimate Outbound MTAs. Larger ISPs likely represent less than a few hundred thousand Outbound MTAs, over several million other legitimate MTAs. A reputation system might replace the existence of CSV records, however initial acceptance and tracking can be improved by the presences of CSV records. Being able to identify legitimate Outbound MTAs reduces the vetting of hundreds of millions of domains associated with Mail From or PRAs, where each domain likely covers massive address lists. Legitimate Outbound MTA domains will resolve to a small set of addresses each. Efforts to combine the addresses used by a domain is counter productive when it comes to resolving problems, or when dealing with initial SMTP connections. When it comes to SMTP, direct relationships involve less overhead which improves efficacy and efficiency to the point of perhaps permitting use of IPv6. -Doug From johnl@iecc.com Wed Jul 1 15:08:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A793A6A4E for ; Wed, 1 Jul 2009 15:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.178 X-Spam-Level: X-Spam-Status: No, score=-19.178 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPwnPUYmqMRn for ; Wed, 1 Jul 2009 15:08:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 346733A6906 for ; Wed, 1 Jul 2009 15:08:24 -0700 (PDT) Received: (qmail 31659 invoked from network); 1 Jul 2009 22:08:45 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 1 Jul 2009 22:08:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=gQVOWweC7o5jMdBGFIHucDYKTnVtRXnipHbnyjf1F0A=; b=Pt81RxcUhd+ZKQopjg4+dwbxYELeOxxRZhqngQ18RdZiyGmWpHZ92N/vUTUJ/hRA72HvPSWjvEMAmZOp/wbRt1B0PiKHOR/wcWYb7O5dwHLucXl3fSLm6yepssAlJrhp98GbJ//dpA1fYoS2jRy5/GKTrJ/mVSBpkkRwO/yFrCs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=gQVOWweC7o5jMdBGFIHucDYKTnVtRXnipHbnyjf1F0A=; b=bSOSTYV5z9PSOj1556xDsAeAshXuLPPK4deQEnixupHBbuvks+2HyBfB5wQIa7qsdv4ChEMjQ4LO0nD74hZM2JtQjstx7TvFNMbsfkxlc+MedB+jZ8rDl3uZx+irjLXyZ3vnnI1WliazKVpD6JyFGyiq8wdCf2CtvVpgc4CP9NE= Date: 1 Jul 2009 22:08:45 -0000 Message-ID: <20090701220845.73063.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <5E322E9DBA384C03215D830F@seana-imac.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:08:25 -0000 >But, what good reason is there for NOT using a DSN when you get an >SPF pass? Why should it do anything different from what it does the other 95% of the time? SPF is far from universal, and a whole lot of SPF lookups end up saying "maybe". R's, John From dotis@mail-abuse.org Wed Jul 1 15:11:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403AA3A6F24 for ; Wed, 1 Jul 2009 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sESt4zhc9c4s for ; Wed, 1 Jul 2009 15:11:07 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 6A9863A68E6 for ; Wed, 1 Jul 2009 15:11:07 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5B0C9A94439 for ; Wed, 1 Jul 2009 22:11:26 +0000 (UTC) Message-Id: <0F6FD8D3-3A40-4BAE-BCA0-A06586DB4655@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <5ec229170906292346o375faf34m273f6499029f333a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 15:11:25 -0700 References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> <5ec229170906292346o375faf34m273f6499029f333a@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:11:08 -0000 On Jun 29, 2009, at 11:46 PM, Danny Angus wrote: > > I'm not sure what this is about.. > >> The draft should drop its current definition of Sender. Spam does >> not just originate from purported RFC 5321 Senders, nor is it safe >> to assume that an MTA authorization referenced by an RFC 5321 >> Sender asserts where a message was initially created and entered. >> Authorization does not provide this >> property. Please carefully review the Sender definition. The RFC 5321 Sender does not indicate or assert where a message originated, or who created message content, be they automated system, group, or individual. This mistaken concept has often been (ab)used by those promoting path registration as a means to authenticate originating domains. Those who advocated path registration as a means to filter email soon found bad actors defeated these filters. Those who expect path registration provides a means to authenticate originating domains will also find bad actors will also demonstrate this concept is also flawed. Few Outbound MTAs ensure exclusive use of a domain. It is also anyone's guess as to whether path registration is in regard to the MAIL command, or the PRA. >> Stronger statements along the lines of scaling might be helpful. >> It seems increasing potential DNS transactions by an order of >> magnitude or more has not been given adequate consideration in some >> anti-spam efforts. :^( > > I think the statements about scaling are clear, do you not? These statements are not strong enough. Email is being heavily abused. Every incremental overhead must be carefully reviewed as to its potential impact. -Doug From iane@sussex.ac.uk Thu Jul 2 02:17:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED89C3A6837 for ; Thu, 2 Jul 2009 02:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZJ-HOIMxG9 for ; Thu, 2 Jul 2009 02:17:45 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id DDB273A6B33 for ; Thu, 2 Jul 2009 02:17:43 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:57966) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5DVI-000B24-4D for asrg@irtf.org; Thu, 02 Jul 2009 10:18:54 +0100 Date: Thu, 02 Jul 2009 10:17:59 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <5CAA4AF19B9260B079C95234@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <20090701220845.73063.qmail@simone.iecc.com> References: <20090701220845.73063.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01wnzfCCvdTW0D6TNqLqI18VJ7KPQAYiWiN+c=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:17:46 -0000 --On 1 July 2009 22:08:45 +0000 John Levine wrote: >> But, what good reason is there for NOT using a DSN when you get an >> SPF pass? > > Why should it do anything different from what it does the other 95% of > the time? SPF is far from universal, and a whole lot of SPF lookups > end up saying "maybe". You've avoided the question. SPF and DKIM are both growing quite rapidly. Some day, you'll get a definite answer for most of your mail. Or, perhaps it'll be some other sender domain authentication technology. So, why should one NOT send a DSN when the domain is authenticated? You said "5xx is cheaper and less likely to cause collateral damage." Well, the cost is minimal, and there's some benefit when we're confident about the sender domain. And, what's the risk collateral damage when the sender domain is authenticated? I guess there's a risk that the authentication mechanism has been compromised - but that's the responsibility of the domain owner, isn't it? > R's, > John > > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 2 02:41:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1623A6C3F for ; Thu, 2 Jul 2009 02:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3-Zbk+3CSfx for ; Thu, 2 Jul 2009 02:41:27 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 60BE028C1F6 for ; Thu, 2 Jul 2009 02:40:09 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:58236) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5EVW-0004DQ-R4 for asrg@irtf.org; Thu, 02 Jul 2009 10:40:45 +0100 Date: Thu, 02 Jul 2009 10:40:25 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <126E753184A13926E471EE27@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <20090701150032.GB15652@verdi> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> Originator-Info: login-token=Mulberry:01lWTtOP7FW53W0UGaAYoI2WCr+9wOkviKCs8=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:41:29 -0000 --On 1 July 2009 11:00:32 -0400 John Leslie wrote: > Ian Eiloart wrote: >> >> The point of SPF is to authenticate the sending domain. > > I don't believe SPF does any such thing. Domains can publish SPF RRs, > but those can't reasonably be said to "authenticate" anything, least of > all the "sending domain." > >> If the IP address is authorised (by the domain owner) to send mail from >> the sender domain, > > That's closer... But I'd argue that no SPF construct "authorizes" > sending email. In practice, I think it's quite clear that SPF constructs > merely express probabilities. OK, so it's authorization rather than authentication. By "probabilities", are you referring to the probability of forwarding, or the use of some unauthorized MSA? Certainly, the latter need to be stamped out in the same way that open relays were. There are other ways to deal with the forwarding problem, and they'll be adopted in time as the value of SPF increases with take up. >> then bouncing mail into that domain isn't going to be causing >> backscatter, unless the domain lacks internal controls over message >> submission. > > Of course, rather few domains other than corporate domains with > administrators more-than-average familiar with SMTP have reasonable > "internal controls over message submission". :^( Yes, but they need to improve. They won't, unless they're held accountable. >> If it does lack those internal controls, then the users of the domain >> can blame the domain owner. > > Indeed they can... does that actually accomplish anything? Yes. Not usually as fast as you'd like. But, companies (email service providers) go out of business if people stop using the service. For commercial users >> I guess there can also be issues where two distinct domains share the >> same outbound IP addresses, through an email service provider. > > Indeed, that is common... > >> In that case, the email service provider is the responsible party that >> needs to be held to account. > > (which, BTW, is what CSV set out to do...) > >> They need to ensure either (a) separation of domains by outbound IP >> address combined with accurate SPF records, > > Assuming they control either multiple IP addresses _or_ the SPF > records is risky. But even if they did, how would this lead to assigning > the responsibility correctly? It prevents cross-domain abuse. When good.example shares IP addresses with bad.example on the outbound MTA, then users of bad.example can forge mail in the domain good.example and get themselves a free ride on the reputation of good.example - thus damaging the reputation of good.example If the two domains have separate outbound IP addresses (very feasible with IPv6) then proper use of SPF can protect them from that abuse. Given that this is all in the control of a single ESP, that ESP can put in place the necessary protection for forwarding. This means that they can safely publish +ve records for a domain's allocted IP addresses, -ve records for the rest of the ESP's IP address space, and (for now) neutral or softfail for the rest of the world. Assignment of responsibility should be to the domain owner, or the email address owner. It doesn't much matter which - they can sort that out themselves. This would be a huge improvement over the current situation, where you can only assign responsibility to an IP address. The main improvement is that non-technical people have some understanding of domains, but no understanding of IP addresses. >> or (b) proper implementation of MSA on all the domains that they >> provide service for. > > That is at least practial... But how does it lead to assigning the > responsibility correctly? The point is that the ESP needs to prevent the sort of cross-domain abuse that I've referred to above. With proper implementation of MSA, they can detect or prevent the cross-domain abuse. That ensures that an SPF pass doesn't result in reputation being assigned to the wrong domain. It also ensures that bounce messages aren't delivered into the wrong domain. > -- > John Leslie > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 2 03:24:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A67F3A67D2 for ; Thu, 2 Jul 2009 03:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9keaIXEmm6iy for ; Thu, 2 Jul 2009 03:24:14 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 633503A6D38 for ; Thu, 2 Jul 2009 03:23:58 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:58795) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5GWD-000IT8-9K for asrg@irtf.org; Thu, 02 Jul 2009 11:24:13 +0100 Date: Thu, 02 Jul 2009 11:23:53 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> Originator-Info: login-token=Mulberry:01HNw9DYU9q3JdSZFviAKPUbCAglReZ38CkUc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:24:17 -0000 --On 1 July 2009 11:12:13 -0400 Dotzero wrote: > On Wed, Jul 1, 2009 at 11:00 AM, John Leslie wrote: >> >> =C2=A0 That's closer... But I'd argue that no SPF construct "authorizes" >> sending email. In practice, I think it's quite clear that SPF constructs >> merely express probabilities. >> > > What is the probability that you will receive legitimate email > originating from ibm.com? > > ibm.com text =3D "v=3Dspf1 -all" Nil. They don't use the domain for outbound email. They use country=20 specific subdomains like @uk.ibm.com. I'm not sure why they publish MX records for @ibm.com - perhaps they have=20 some initial contact addresses @ibm.com, but don't reply using that domain. It's very sensible of them to use the -all spf record, adding a little=20 protection for their brand reputation. Alternatively, this is a massive cock-up and a huge potential=20 embarrassment. I don't think so, though. Our logs from June show no inbound = email (either accepted or rejected) from the @ibm.com domain, but a few dozen emails from @uk.ibm.com and some from the 'be', 'ca', 'us',=20 'jp', 'hu' subdomains of ibm.com. Exercise for the reader: why aren't spammers using the @ibm.com domain? --=20 Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From Jose-Marcio.Martins@mines-paristech.fr Thu Jul 2 03:44:22 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604BC3A683A for ; Thu, 2 Jul 2009 03:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-RIhB7WMDlC for ; Thu, 2 Jul 2009 03:44:21 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 6766F3A67A4 for ; Thu, 2 Jul 2009 03:44:21 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n62AifwS016605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jul 2009 12:44:41 +0200 (MEST) Message-ID: <4A4C901D.3010200@mines-paristech.fr> Date: Thu, 02 Jul 2009 12:46:53 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> <4A4B8D9F.9000000@telmon.org> <4A4B8FA9.3080905@mines-paristech.fr> <4A4B9345.8060705@telmon.org> In-Reply-To: <4A4B9345.8060705@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A4C8F99.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A4C8F99.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:44:22 -0000 Claudio Telmon wrote: > I know. However, this is the part of the framework that I see as least > critical in terms of acceptance. Both the MUA and the MTA will need some > add-on/patch/whatever in order to implement the protocol, so this part > of the framework will come "with the patch". > While I have a couple of ideas on how this could be accomplished, the > MTA token database management issue is one of the two I'm still looking > for comments, the other being whether it is true that spam in "small > text messages" would be easier/lighter to deal with by antispam tools. I'll take a deeper look into this (but I don't have enough time now). I have the feeling that this is part of a larger problem which is how to inform a border SMTP gateway about caracteristics of final addresses in internal mail servers. One example we were talking about is just what are the valid internal addresses which, with your needs for the consent framework, is a sub problem of the larger one. For the problem of checking the validity of internal addresses (e.g.), there are many solutions, but none of them is perfect. Maybe this problem could be taken out of your proposal and handled as a global one. From claudio@telmon.org Thu Jul 2 03:57:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C508A3A6D38 for ; Thu, 2 Jul 2009 03:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lb5p+Kesohh for ; Thu, 2 Jul 2009 03:57:17 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id EDB403A6985 for ; Thu, 2 Jul 2009 03:56:53 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+voFiPUXqq8d; Thu, 02 Jul 2009 12:57:15 +0200 Message-ID: <4A4C928A.1030904@telmon.org> Date: Thu, 02 Jul 2009 12:57:14 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr> <4A4B8D9F.9000000@telmon.org> <4A4B8FA9.3080905@mines-paristech.fr> <4A4B9345.8060705@telmon.org> <4A4C901D.3010200@mines-paristech.fr> In-Reply-To: <4A4C901D.3010200@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:57:17 -0000 Jose-Marcio Martins da Cruz wrote: > I have the feeling that this is part of a larger problem which is how to > inform a border SMTP gateway about caracteristics of final addresses in > internal mail servers. > > One example we were talking about is just what are the valid internal > addresses which, with your needs for the consent framework, is a sub > problem of the larger one. > > For the problem of checking the validity of internal addresses (e.g.), > there are many solutions, but none of them is perfect. > > Maybe this problem could be taken out of your proposal and handled as a > global one. I think you're right, and I actually highlighted this as a "plus" of the proposal. The ability (in my case for the user) to push some simple information to the border MTA (in my case, acceptable tokens) so that messages can be dropped/rejected/accepted earlier, can be very useful IMHO. In this specific case, messages can be rejected, that otherwise the final receiver could otherwise only delete from its mailbox. This should be also what Danny Angus meant in his first message in the thread. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From iane@sussex.ac.uk Thu Jul 2 04:56:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CE63A67AF for ; Thu, 2 Jul 2009 04:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFshiVVQ6FFA for ; Thu, 2 Jul 2009 04:56:24 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 841653A67A4 for ; Thu, 2 Jul 2009 04:56:24 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:59933) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5L7Z-0004U2-JF for asrg@irtf.org; Thu, 02 Jul 2009 12:57:35 +0100 Date: Thu, 02 Jul 2009 12:56:40 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <267CA0589FD05D96B17BFBFE@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <4A4BB460.9020205@cybernothing.org> References: <4A4BB460.9020205@cybernothing.org> Originator-Info: login-token=Mulberry:01x57WvDD/RCEICyoeM8Q6E0kvLRb3FirEPAk=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:56:25 -0000 --On 1 July 2009 13:09:20 -0600 "J.D. Falk" wrote: > Steve Atkins wrote: > >> (A problem that's usually best solved by killfiling anyone participating >> in that sort of thread). > > If we're going to go back to first principles, how 'bout discussing the > purpose of the ASRG? I joined thinking the word "research" was in there > somewhere, but it's clear there's no research going on -- and none likely > to occur. > > So, what's this group for? Why are we all participating in it? I joined because I thought I'd learn about research related to spam. I stay because it turns out to be a good place to discuss issues relating to spam, even though it turns out that there's little actual research. Perhaps there are other fora that might be more suitable. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 2 05:10:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE52E3A6CE3 for ; Thu, 2 Jul 2009 05:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCQyzCwiYQ3D for ; Thu, 2 Jul 2009 05:10:08 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 47E3A3A689D for ; Thu, 2 Jul 2009 05:10:08 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:60100) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5LV1-0008PN-A0 for asrg@irtf.org; Thu, 02 Jul 2009 13:11:25 +0100 Date: Thu, 02 Jul 2009 13:10:29 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A4B8090.5000507@tana.it> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> <4A4B8090.5000507@tana.it> Originator-Info: login-token=Mulberry:01on2hVgveD7vj6vW4DqMV8hTJCPXCsAWjF+g=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:10:09 -0000 --On 1 July 2009 17:28:16 +0200 Alessandro Vesely wrote: > Dotzero wrote: >>> Thus, it turns out that if an MTA does mixed MSA and old fashioned port >>> 25 relaying for its clients, its IP cannot convey accountability. >> >> The fact that it cannot (may not?) convey accountability does not mean >> that it cannot or should not be held accountable for what it emits. > > I understand the 2nd "it" as referring to the MTA, not the IP address. It > doesn't make much difference, since both of them are objects. AFAICS, the > point is to hold _someone_ accountable, so that it might be theoretically > possible to claim damage, in case. It is like an insurance, and > postmasters tend to stipulate it with IP numbers rather than DNS names. > Why? Because there is currently usually no alternative. You can only know the IP address of the sending MTA. It's hard to connect that to a person, or organisation, so the usual thing is to check against a reputation service. With some reason to trust that the domain of the return-path, or in some message header, is not forged, you can go a lot further. You have the email address of the postmaster, and quite likely of the sender. If you don't have the email address of the sender, then that's an issue that needs sorting out within the domain. "Accountability" can be applied in many ways, including: 1) assignment of reputation - in future DNSBLs will be supplemented or even replaced by domain reputation services. 2) freely bouncing undeliverable messages, like we used to do. 3) complaining to the sender, their company, or their postmaster. 4) legal santions, up to and including prison sentences. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 2 05:14:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379AB3A67AF for ; Thu, 2 Jul 2009 05:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpaDK7P4iKU2 for ; Thu, 2 Jul 2009 05:14:11 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id D39723A6C75 for ; Thu, 2 Jul 2009 05:13:49 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:60149) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5M17-0009MK-3Y for asrg@irtf.org; Thu, 02 Jul 2009 13:15:07 +0100 Date: Thu, 02 Jul 2009 13:14:11 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <8A5D3B89E14F6C6143E58D81@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <7ae58c220907010955u21cfb34n19d85f487e70fc56@mail.gmail.com> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> <4A4B8090.5000507@tana.it> <7ae58c220907010955u21cfb34n19d85f487e70fc56@mail.gmail.com> Originator-Info: login-token=Mulberry:01vZp2RSb75Kr+B8qnKcAwD+m4IxKXnyDAMgU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:14:13 -0000 --On 1 July 2009 12:55:02 -0400 Dotzero wrote: > > IP Addresses are used rather than DNS names because it is > significantly easier to dump a domain name and use a new one than to > dump an IP address (range) and migrate to another unless there are > compromised hosts involved. IP Addresses tend to be more trackable and > ultimately tied to an ISP (even if that carrier is an upstream). That depends on what you're using it for. For hard-core spammers, it's easy to do get new domain names. And, they don't seem to have problems getting hold of IP addresses on compromised hosts, either. It's harder to get hold of IP addresses or domains with good reputation. For sloppy marketing people (who also send significant quantities of spam), it's not so easy to do either. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 2 05:17:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAF13A6849 for ; Thu, 2 Jul 2009 05:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7j1X8JpWxaF for ; Thu, 2 Jul 2009 05:17:31 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 4F1A23A689D for ; Thu, 2 Jul 2009 05:17:31 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:60204) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5M7C-000AML-D4 for asrg@irtf.org; Thu, 02 Jul 2009 13:18:48 +0100 Date: Thu, 02 Jul 2009 13:17:53 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A4BACF1.2030609@tana.it> References: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <20090701154314.GC15652@verdi> <4A4BACF1.2030609@tana.it> Originator-Info: login-token=Mulberry:012LdFM0EYs5gZJJmVRN1LLLimPi9mjTvdTSI=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:17:32 -0000 --On 1 July 2009 20:37:37 +0200 Alessandro Vesely wrote: > John Leslie wrote: >>> >>> [For accountability, I'd use] a domain name. One reason is that >>> large ESP have many MTAs that can be used interchangeably. In >>> addition, the person responsible for an MTA is not always identifiable >>> (in Italy, the mandate to state who are the sysadmins of an MTA is >>> being procrastinated every few months, since November 2008.) By >>> contrast, domain registrants often have whois records pointing to them. >> >> I think I'm catching on: you want to link the MTA to a _registered_ >> domain. > > Yup. However, no official registration exists for, say, us.ibm.com or > it.ibm.com. The latter two ones happen to have different hostmaster > addresses, therefore it would not be correct for them to share the same > accountability token "ibm.com". I can only trust the DNS about the > legitimacy of such subdomain delegations. ibm.com isn't an email domain. At least, it's not one they use to send email. They do send email from @us.ibm.com addreses. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From claudio@telmon.org Thu Jul 2 05:45:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1AD3A689D for ; Thu, 2 Jul 2009 05:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USmXMJCq6z1G for ; Thu, 2 Jul 2009 05:45:00 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 0D50B3A6917 for ; Thu, 2 Jul 2009 05:44:59 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+MSUB9gbXw3C; Thu, 02 Jul 2009 14:45:21 +0200 Message-ID: <4A4CABE1.2050001@telmon.org> Date: Thu, 02 Jul 2009 14:45:21 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org> <4A48DFCF.9080305@mines-paristech.fr> <4A48E605.5080507@telmon.org> <4A49E61B.4010307@mines-paristech.fr> In-Reply-To: <4A49E61B.4010307@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Asrg] Shared addresses (was: Re: VPNs vs consent) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:45:01 -0000 Jose-Marcio Martins da Cruz wrote: > Claudio Telmon wrote: >> Jose-Marcio Martins da Cruz wrote: > >> >>>> official contact addresses of companies. >>> In fact, at our domain, few of these kind of adresses aren't protected. >>> Most of them are adresses of the kind "everybody in the engineering >>> department" (addresses which are of internal use only) "butterfly >>> research workgroup" (a closed group working on some particular subject) >>> and so. These are adresses which *are* protected and the concept of >>> consent-enable is materialized by checking if the SMTP client sending >>> messages to is in some known network or if the connection was >>> authenticated. But nothing prevents that this kind of consent should be >>> expanded. Either way, in an organisation like the ours, users couldn't >>> understand that the same consent system used for individual addresses >>> couldn't be used for collective addresses. >> >> This is a very interesting case. I'll have to think at the implications >> of it. > > You got the message ! 8-) So, I think I can give some answers now. There are many many different cases, so I will only deal with the most (IMHO) representative ones, the others should be very similar. The main issues are: - how people are added to the list of correspondents for shared address; - how to send messages to the shared address - how to send answers from the shared address I can see two kinds of "shared addresses": addresses that are forwarded/expanded to a group of actual recipients, and "shared mailboxes" where many people can read messages. In many cases, this second case means that the shared mailbox is accessed through a web interface, and this solves many problems (e.g. tokens stay with the interface/mailbox, whoever uses it). This is the case of many CRM tools. Problems may arise with people accessing a shared mailbox through personal MUAs. With respect to "adding people to the list of correspondents", while the decision about adding people can be complex (unanimity, majority, etc), from a technical perspective, what matters is who is entitled to push tokens to the MTA for that address: whoever can push tokens can add correspondents. There are two main cases which may cause some problems, while some others are very similar. Most cases shouldn't be a problem. 1. "Forwarding style" shared address. Sender A, with a consent-enabled address and not being part of the group, writes to the shared address. The message will carry a valid token to be used in answers. In "mailing list style" addresses, this token wouldn't be forwarded to the group, but this would mean that nobody could send answers, so in this case the token must be forwarded with the message. This is just a matter of configuration of the forwarding agent. B, member of the group, could send answers either from a personal address (providing to A a token for this personal address) or from the shared address. In this last case, B must be able to push a token for the shared address on the MTA. This is consistent: B can use a consent-enabled address as sender only if he can push tokens for that address. All this means that the choice to forward or not to forward tokens must be configurable in forwarding agents. Note that B may already own a personal token for A, due to a personal contact. In this case, B may be required to hold different tokens for the same correspondent. Privacy and anonymity issues are not different from those already discussed in the paper. Note also that all members of the shared address group would share the same tokens for the shared address correspondents, which is consistent with the concept of shared address, but nonetheless reduces the ability to point out how these tokens could have been compromised/exposed by one of these persons. 2. "Shared mailbox style" shared address, accessed through personal MUA. Again, A sends a message to the shared address. Problems may arise if B downloads the message to its MUA and then deletes it from the mailbox, since the other members of the group wouldn't receive the token required to send messages to A. In this case, B should respond with its own personal address as sender, since otherwise other members of the group could be required to deal with subsequent messages, which are from a sender they can not send messages to. This is usually consistent, since other members of the group would miss some of the answers anyway, unless these are sent in Cc: to the shared address. Should B be required to answer from the shared address, then in this very specific case a way to share A's token would be required. Note that since the problem is with A's token, not enabling consent for the shared address won't solve the problem. Note also that the whole problem depends on B deleting the message from the mailbox, so that other members can't access it and collect the token. The same problem may arise with new members of the group accessing the shared address, be it "forwarding" or "shared mailbox" style: they will miss the tokens provided to the address by correspondents before then, so once added to the group they will need to receive a full set of tokens, e.g. within a message confirming their inclusion in the group. As usual, it's up to A to decide if messages conforming the "consent request" constraints, but not carrying tokens, can be delivered, in order to deal with correspondents not implementing the consent framework, including shared addresses. So, all in all, I think that the shared address case can be dealt with in the framework, only some specific cases may require a way to share tokens. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From johnl@iecc.com Thu Jul 2 06:54:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197BE3A6ADA for ; Thu, 2 Jul 2009 06:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.179 X-Spam-Level: X-Spam-Status: No, score=-19.179 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf+4TunUSqg1 for ; Thu, 2 Jul 2009 06:54:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id CD6C73A6C67 for ; Thu, 2 Jul 2009 06:54:04 -0700 (PDT) Received: (qmail 30276 invoked from network); 2 Jul 2009 13:54:10 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Jul 2009 13:54:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=o9ZSB6wTVwPzevFWHpz16pladeFsJcmZSDw4qCKxFbM=; b=RSCLdC/0+qubRo3voh5SF/OrdfX+I9FuVZ1ZKtRg9mle17qAx3MGVLFrIzLKLOXtq6gNrCmeQ+S7yz/IjTIjpE8aoxzFHq2D8wgpplyqZPHq43QTZZ2QwlgOdWOBe6fbr2j0OxBqbQMiBZP3L4s5JjftLXW6LIbE86g+WtNKVrk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=o9ZSB6wTVwPzevFWHpz16pladeFsJcmZSDw4qCKxFbM=; b=iQ5YdxhIN6FDgM3ePo2GhKTz3AAkBjvi8K/C0NF+Bg9fYsGk15xUhyWGZ7UNmUHRjarTeRIJaK+5y7DlxjloXldZNczWnR0KlKR8HVm+vaEVYuo8kBsB2YtSoOy7kiAE614bq3UST9xxhhQRTZywLkj9Pvd8tqCnx5sipOdYbb8= Date: 2 Jul 2009 13:54:09 -0000 Message-ID: <20090702135409.21568.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <5CAA4AF19B9260B079C95234@seana-imac.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 13:54:14 -0000 >> Why should it do anything different from what it does the other 95% of >> the time? SPF is far from universal, and a whole lot of SPF lookups >> end up saying "maybe". > >You've avoided the question. SPF and DKIM are both growing quite rapidly. >Some day, you'll get a definite answer for most of your mail. Or, perhaps >it'll be some other sender domain authentication technology. That may be so at some time in the distant future, but for the forseeable future there will always be a signficant number of maybes. >So, why should one NOT send a DSN when the domain is authenticated? Because rejects work better, and DSNs are a second rate substitute when the recpient system can't tell during the SMTP session that the delivery will fail. You appear to be under the impression that a sender would obtain and use valuable information from a DSN that can't be sent in a rejection, which is completely contrary to my experience. I don't spend an enormous amount of time reading DSNs, but my mailing list software does and all it really wants to know is the address that bounced, which rejections reliably provide. DSNs often give no hint what address the bouncing message was sent to. That's why we have to use kludges like VERP. R's, John From iane@sussex.ac.uk Thu Jul 2 07:10:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F6E3A6906 for ; Thu, 2 Jul 2009 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc2EZoJm-YVo for ; Thu, 2 Jul 2009 07:10:23 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 2DA923A697C for ; Thu, 2 Jul 2009 07:10:23 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:61715) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5RF6-000FSR-1Q for asrg@irtf.org; Thu, 02 Jul 2009 15:11:30 +0100 Date: Thu, 02 Jul 2009 15:10:34 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <20090702135409.21568.qmail@simone.iecc.com> References: <20090702135409.21568.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01KmHEF5PCMnxrzhh5loed1jeKkNnlcY2Hn8w=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:10:24 -0000 --On 2 July 2009 13:54:09 +0000 John Levine wrote: > > You appear to be under the impression that a sender would obtain and > use valuable information from a DSN that can't be sent in a rejection, > which is completely contrary to my experience. I don't spend an > enormous amount of time reading DSNs, but my mailing list software > does and all it really wants to know is the address that bounced, > which rejections reliably provide. DSNs often give no hint what > address the bouncing message was sent to. That's why we have to use > kludges like VERP. I guess rejections are more useful for automated processes, but they're often converted to DSNs anyway. Certainly, our mailing list software only sees DSNs. VERP may be a kludge, but it is a solution. DSNs have the potential to be more useful to humans if they're constructed by the MTA that has more information. In fact, we never reject a message submission because most MUAs display little or nothing of the message. Instead, we accept all authenticated submissions, and generate a DSN if there's something we don't like (except unauthorised sender addresses, of course). DSNs are often hard to understand, especially when the sending MTA is trying to wrap an error message. All too often, they discard the error message and insert completely misleading diagnostics. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From johnl@iecc.com Thu Jul 2 07:13:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508283A6B0F for ; Thu, 2 Jul 2009 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.78 X-Spam-Level: X-Spam-Status: No, score=-18.78 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyHgC6+VuipA for ; Thu, 2 Jul 2009 07:13:28 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 225363A697C for ; Thu, 2 Jul 2009 07:13:28 -0700 (PDT) Received: (qmail 54561 invoked from network); 2 Jul 2009 14:13:50 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Jul 2009 14:13:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=FS7jQHjrpt+fqNFoY+gkPkMZ+pR593hhjMQoCR9ED3k=; b=LPJkW8sQDZVSjsOpOx1e7nAYHrPFCvklTMrbMeaAAQK52wn0ghMD9U07+HCTcfBc1IW3vni5A15Y1UzaFnYB7zqHiJvBr84GDkOCyhIo2t7eHkfIOiHRzCEdShDh2G1c1W3yZvo5dV99pom93sLryhRx6XyDk2X2+L70VHJrMcY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=FS7jQHjrpt+fqNFoY+gkPkMZ+pR593hhjMQoCR9ED3k=; b=nNRcPfmYzxT/XFovNM8bM7KgH5cFHqh446H3DqwbHovapiV4QQulG2j0ivP1s+4S1G8OoRrSxWQ34t27t0+n+IrDhVX0ru0BPlcJDXTmiB5GcoyXilfp6NKzRJ44FvUTxCl1faCr4Rs/SN9YeNTBbA0K92t5t2B/NWsZfuHgIG8= Date: 2 Jul 2009 14:13:49 -0000 Message-ID: <20090702141349.26334.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A4BB460.9020205@cybernothing.org> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:13:29 -0000 >If we're going to go back to first principles, how 'bout discussing >the purpose of the ASRG? I joined thinking the word "research" was >in there somewhere, but it's clear there's no research going on -- >and none likely to occur. As far as I can tell, based on the papers at CEAS, there's precious little spam-related research going on anywhere. If people here were willing to put 1/10 of the work into research that they do into arguing, we might have some actual research. Perhaps I should make it so that whenever you update the wiki (where we are ever so slowly building a taxonomy of anti-spam techniques and even more slowly of spamming techniques) you get a credit that allows you to send one message. R's, John From iane@sussex.ac.uk Thu Jul 2 07:34:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C613A6B1F for ; Thu, 2 Jul 2009 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, MANGLED_SPAM=2.3, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aFnztmDyK7E for ; Thu, 2 Jul 2009 07:34:28 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 9BBFF28C0E2 for ; Thu, 2 Jul 2009 07:34:28 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:62062) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5SJJ-000LS3-3S for asrg@irtf.org; Thu, 02 Jul 2009 15:35:43 +0100 Date: Thu, 02 Jul 2009 15:34:47 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <8F0BE6DC4CF6E559BCEA6207@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <20090702141349.26334.qmail@simone.iecc.com> References: <20090702141349.26334.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01xuyfuC9NDR0HWfMaMhI5YRIrLGTAEikSO1c=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:34:29 -0000 --On 2 July 2009 14:13:49 +0000 John Levine wrote: >> If we're going to go back to first principles, how 'bout discussing >> the purpose of the ASRG? I joined thinking the word "research" was >> in there somewhere, but it's clear there's no research going on -- >> and none likely to occur. > > As far as I can tell, based on the papers at CEAS, there's precious > little spam-related research going on anywhere. > > If people here were willing to put 1/10 of the work into research that > they do into arguing, we might have some actual research. > > Perhaps I should make it so that whenever you update the wiki (where > we are ever so slowly building a taxonomy of anti-spam techniques > and > even more slowly of spamming techniques) "this is a place holder until some real content can be added" lol! > you get a credit that allows > you to send one message. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Thu Jul 2 08:03:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC25B3A680F for ; Thu, 2 Jul 2009 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=1.757, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzi1ktGsi0bt for ; Thu, 2 Jul 2009 08:03:29 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 8325C3A6999 for ; Thu, 2 Jul 2009 08:03:29 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 02 Jul 2009 17:03:51 +0200 id 00000000005DC02F.000000004A4CCC57.0000294C Message-ID: <4A4CCC56.8090804@tana.it> Date: Thu, 02 Jul 2009 17:03:50 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:03:30 -0000 Douglas Otis wrote: > On Jul 1, 2009, at 7:20 AM, Alessandro Vesely wrote: >> John Leslie wrote: >>> The CSV paradigm is that the operator of a MTA should exercise some >>> responsibility for what is sends. The HELO string identifies the MTA >>> (though not necessarily one string exclusively by one MTA), and the >>> DNS management for that domain-name string states whether that domain >>> exercises responsibility (and by automatic return of A)ddress RRs on >>> SRV queries, what IP address(es) that MTA uses). >> >> The link from the MTA to its operator is still missing. > > Disagree. Based on our results, when only a few domains publish an IP > addresses of an Outbound MTA, it is rather safe to assume the domains > represented by verified EHLO information resolve who is administrating > the MTA. In general an MTA provides a FQDN like mta.example.com, and we are unable to say whether it "is a member of" example.com. In addition, the MTA's administrator may be unrelated to example.com's registrant. > When there are many domains, this appears to represent either > MTAs operating behind a NAT, or compromised systems; sometimes both. I don't understand that kind of setup. Multiple MTAs operating behind a NAT have no way to receive mail, so they are only sending SMTP clients. Is inertia the only reason why they don't use an MSA? > It appears to be rare for legitimate Outbound MTAs to change domain > affiliations. From a reputation standpoint, verified EHLO information > offers stable identifiers in which to effectively and efficiently manage > email abuse. It seems that vanity domains don't mind if the MX record points to an MTA in another domain. The intricacies of having CNAMEs near MX settings presumably refrained also from assigning multiple names, one for each vanity domain, to a given MTA. However, some do it. On an SMTP connection, a client says: "Hello mta.example.com", and after I accept that, it goes on with "Mail from:". What does that mean, in terms of accountability? >> To this end, I'd prefer the use of a domain name. This guy is relaying on behalf of someone else. If I had verified the "example.com" possibly registered domain, I would spot it more easily. If example.ORG is a vanity name, i.e. it has the same MX as example.com, I accept it. If not, I wouldn't know who is accountable for the message, so I reject it. In case mta.example.com runs outbound MTA services for third parties, I would hold the originating third party accountable for the message. However, there is no way I can tell that is indeed the case, neither from the IP address nor from the name. I'd need, say, a CSA SRV record from example.ORG saying: "we authorize mta.example.com", _and_ on starting a new session the client shall say: "Hello on behalf of example.ORG: check their CSA settings". No guessing required, then. > While larger ISPs are likely to have a few hundred outbound MTAs, they > represent a very small percentage of overall legitimate Outbound MTAs. However, they transmit lots of messages. > Being able to identify legitimate Outbound MTAs reduces the vetting of > hundreds of millions of domains associated with Mail From or PRAs, where > each domain likely covers massive address lists. Exactly. Those legitimate Outbound MTAs are probably connected to an MSA. When we identify them, we enjoy the advantages deriving from users going through their relevant MSAs, as we recommended, rather than relaying through whatever MTA they have at hands, or directly. > Efforts to combine the addresses used by a domain is counter productive > when it comes to resolving problems, or when dealing with initial SMTP > connections. When it comes to SMTP, direct relationships involve less > overhead which improves efficacy and efficiency to the point of perhaps > permitting use of IPv6. In some cases, names can be handled better than IP numbers. After all, that's why they invented the DNS... From CLEWIS@nortel.com Thu Jul 2 08:05:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6713A6DA1 for ; Thu, 2 Jul 2009 08:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvjE4CxNXmmL for ; Thu, 2 Jul 2009 08:05:43 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2E1B43A6DAB for ; Thu, 2 Jul 2009 08:05:43 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n62F5wd15216 for ; Thu, 2 Jul 2009 15:05:58 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 11:05:43 -0400 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Jul 2009 11:05:42 -0400 Message-ID: <4A4CCCC6.70701@nortel.com> Date: Thu, 2 Jul 2009 11:05:42 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090702135409.21568.qmail@simone.iecc.com> <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 15:05:43.0170 (UTC) FILETIME=[91E36E20:01C9FB26] Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:05:44 -0000 Ian Eiloart wrote: > > --On 2 July 2009 13:54:09 +0000 John Levine wrote: > >> You appear to be under the impression that a sender would obtain and >> use valuable information from a DSN that can't be sent in a rejection, >> which is completely contrary to my experience. I don't spend an >> enormous amount of time reading DSNs, but my mailing list software >> does and all it really wants to know is the address that bounced, >> which rejections reliably provide. DSNs often give no hint what >> address the bouncing message was sent to. That's why we have to use >> kludges like VERP. > > I guess rejections are more useful for automated processes, but they're > often converted to DSNs anyway. Certainly, our mailing list software only > sees DSNs. VERP may be a kludge, but it is a solution. > > DSNs have the potential to be more useful to humans if they're constructed > by the MTA that has more information. You seem to be missing the distinction here. Users (and most automated processes that defer to a MTA to initiate sending) _only_ see DSNs [+]. The question is _who_ constructs the DSN? If it's the MX (or later) of the recipient, (IOW: _recipient_ generated DSNs) you get backscatter. This is bad. It's so bad that it's generally better to blackhole (possibly providing quarantine on the recipient side to find misfires) once the perimeter has accepted the email than to DSN later. If its the sending MTA (the one that does the MX lookup and connect and is reacting to an inline-reject), this is good. Good MTAs can generate quite readable messages if they care to. Even if only to generate a reasonably well-formatted message that explains what the MX MTA actually said in its rejection. I've seen a number of MTAs that do a good job (eg, postfix I think) on formatting DSNs, and others that do an abysmal job (eg, gag, Exchange). > DSNs are often hard to understand, especially when the sending MTA is > trying to wrap an error message. All too often, they discard the error > message and insert completely misleading diagnostics. Eg: Exchange. The work, if any, is to to encourage that sending MTAs generate reasonably readable DSNs from a reject and NOT to discard the text of the rejection. Encouraging DSNs once you're past the MX's acceptance is a very bad idea. [+] The only time a user will directly see an SMTP reject is during the SMTP SUBMIT phase with their own MTA. The only time an application will see a reject "properly" is if it's the application's own SMTP client. From vesely@tana.it Thu Jul 2 08:23:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0DF3A6DB4 for ; Thu, 2 Jul 2009 08:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=2.174, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avtl2PP2V7vG for ; Thu, 2 Jul 2009 08:23:23 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 401523A6B8D for ; Thu, 2 Jul 2009 08:23:23 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 02 Jul 2009 17:23:45 +0200 id 00000000005DC02F.000000004A4CD101.00002F04 Message-ID: <4A4CD100.8090508@tana.it> Date: Thu, 02 Jul 2009 17:23:44 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090702135409.21568.qmail@simone.iecc.com> <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:23:24 -0000 Ian Eiloart wrote: > DSNs have the potential to be more useful to humans if they're > constructed by the MTA that has more information. If that happens after alias expansion, it may disclose sensible information. Some may regard that as being *too* useful. :-/ From steve@blighty.com Thu Jul 2 08:39:22 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF823A6DBF for ; Thu, 2 Jul 2009 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8KY6uOctOCk for ; Thu, 2 Jul 2009 08:39:22 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 0B7013A6D5A for ; Thu, 2 Jul 2009 08:39:22 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id ACB99806D9 for ; Thu, 2 Jul 2009 08:39:25 -0700 (PDT) Message-Id: From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <8A5D3B89E14F6C6143E58D81@seana-imac.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 08:39:38 -0700 References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <7ae58c220907010742h1d273f42m8bb3c02e6b969b1@mail.gmail.com> <4A4B8090.5000507@tana.it> <7ae58c220907010955u21cfb34n19d85f487e70fc56@mail.gmail.com> <8A5D3B89E14F6C6143E58D81@seana-imac.staff.uscs.susx.ac.uk> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:39:22 -0000 On Jul 2, 2009, at 5:14 AM, Ian Eiloart wrote: > > > --On 1 July 2009 12:55:02 -0400 Dotzero wrote: > >> >> IP Addresses are used rather than DNS names because it is >> significantly easier to dump a domain name and use a new one than to >> dump an IP address (range) and migrate to another unless there are >> compromised hosts involved. IP Addresses tend to be more trackable >> and >> ultimately tied to an ISP (even if that carrier is an upstream). > > That depends on what you're using it for. For hard-core spammers, > it's easy to do get new domain names. And, they don't seem to have > problems getting hold of IP addresses on compromised hosts, either. > > It's harder to get hold of IP addresses or domains with good > reputation. Didn't we already point out in this thread why this isn't a problem? Cheers, Steve From johnl@iecc.com Thu Jul 2 08:51:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A024B28C24C for ; Thu, 2 Jul 2009 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.163 X-Spam-Level: X-Spam-Status: No, score=-19.163 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-flmwG9U2+B for ; Thu, 2 Jul 2009 08:50:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 66A6428C248 for ; Thu, 2 Jul 2009 08:50:59 -0700 (PDT) Received: (qmail 61762 invoked from network); 2 Jul 2009 15:51:17 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Jul 2009 15:51:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=1YZA/FUeKpnVc5gKHfWT53E7pClr0Ok8ivLgc4mz27g=; b=Vn1UPMCFyFP44+ykO4eMG5IAKIV7Vlj0NVqCZ8TapV/Id25YKBj/E8GJyuBpQAxUsgwNKk106B3l1s3WPIe2zKwWxl27L54u8aFKnahBlGjlBxtl+RpuWpA6oCKS8c3odSsizXfjUqi3ZU0Em9Od3dMVEdhVHGC+j7dtXRFJ5Lc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=1YZA/FUeKpnVc5gKHfWT53E7pClr0Ok8ivLgc4mz27g=; b=cyOIqCM8l6h7zrcbUHmGfRUysGjqb7FkZyu9j38iUFioipddEqIVGlDVKpXQxejqb6iDEpMQs0P5bt8vCPX4NHxD5BBTtfRmonwKQ/f7hxpNba5F4RhytAoOfeBBXs+HUPOnsyC+ONJDjE3e1+HtPys6vQCijK6JS+CItBS3/YU= Date: 2 Jul 2009 15:51:16 -0000 Message-ID: <20090702155116.53826.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <3E172618F8995D353A6421F8@seana-imac.staff.uscs.susx.ac.uk> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] reject and DSN, was What are the IPs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:51:00 -0000 >DSNs have the potential to be more useful to humans if they're >constructed by the MTA that has more information. ... Well, OK. DSNs have been around for 13 years now. How often do you see one with more useful info that you'd find in a reject notice? And if you expect them to be better in the future, what's going to change in the next 13 years to make that happen? R's, John From asrg3@billmail.scconsult.com Thu Jul 2 09:07:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766FF3A6A41 for ; Thu, 2 Jul 2009 09:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59g-8ShBvK-j for ; Thu, 2 Jul 2009 09:06:59 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 6E7593A6A2C for ; Thu, 2 Jul 2009 09:06:59 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id D27848E3B9B for ; Thu, 2 Jul 2009 12:07:15 -0400 (EDT) Message-ID: <4A4CDB33.9000908@billmail.scconsult.com> Date: Thu, 02 Jul 2009 12:07:15 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:07:00 -0000 Ian Eiloart wrote, On 7/2/09 6:23 AM: > > > --On 1 July 2009 11:12:13 -0400 Dotzero wrote: > >> On Wed, Jul 1, 2009 at 11:00 AM, John Leslie wrote: >>> >>> That's closer... But I'd argue that no SPF construct "authorizes" >>> sending email. In practice, I think it's quite clear that SPF constructs >>> merely express probabilities. >>> >> >> What is the probability that you will receive legitimate email >> originating from ibm.com? >> >> ibm.com text = "v=spf1 -all" > > Nil. They don't use the domain for outbound email. They use country > specific subdomains like @uk.ibm.com. [...] > Exercise for the reader: why aren't spammers using the @ibm.com domain? You provided the answer before the question. Forged sender addresses are predominantly harvested rather than purely invented or recombinantly assembled. Forged sender spam is mostly the product of the blatantly criminal segment of spammers whose target lists are largely harvested from the web, Usenet, and the address books of compromised systems. In a world where there is a detectable fraction of sites making some effort to validate senders to the point of SMTP callbacks, the most economical approach for spammers forging the sender address is to just pull sender addresses from the same list as targets. I see this most clearly in blowback like the bounce AOL sent me this morning. The original spam had been addressed to 'bill@aol.com' with the sender 'bill@scconsult.com'. That's an address I've used in very public ways for 15 years, making it a frequent spam target. 99%+ of the direct spam for it I never see, particularly the flavors using forged senders, but nearly all of the blowback I get for it is from spam aimed at alphabetically nearby targets. From CLEWIS@nortel.com Thu Jul 2 09:27:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D27528C153 for ; Thu, 2 Jul 2009 09:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWyEPtyaMaNy for ; Thu, 2 Jul 2009 09:27:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 98EAB3A6999 for ; Thu, 2 Jul 2009 09:27:40 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n62GQRZ18829 for ; Thu, 2 Jul 2009 16:26:27 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 12:27:58 -0400 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Jul 2009 12:27:58 -0400 Message-ID: <4A4CE00D.3020802@nortel.com> Date: Thu, 2 Jul 2009 12:27:57 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "asrg@irtf.org" References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> <4A4CDB33.9000908@billmail.scconsult.com> In-Reply-To: <4A4CDB33.9000908@billmail.scconsult.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 16:27:58.0781 (UTC) FILETIME=[0FBDE6D0:01C9FB32] Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:27:43 -0000 Bill Cole wrote: > Ian Eiloart wrote, On 7/2/09 6:23 AM: >> Exercise for the reader: why aren't spammers using the @ibm.com domain? > > You provided the answer before the question. Somewhat. Because spammers _are_ using @ibm.com too. I got samples ;-) Anybody saying "spammers don't do X" and "spammers do X" are wrong at least some of the time. Except for the obvious tautology that "spammers spam". > Forged sender addresses are predominantly harvested rather than purely > invented or recombinantly assembled. IOW: the biggest asset spammers have is lists of potential spam victim's email addresses. What better place to get the email addresses to forge as sender than from the exact same list? Is it so hard to imagine that a bot might do this or some variation? 1) Read a bunch of addresses 2) Spam the bunch of addresses, forged with one of the bunch as sender 3) Goto step 1 Various corollaries: - If you get spam, you're probably being forged as sender in other spam. - If they're hitting valid addresses, then there will be blowback _to_ valid addresses. From iane@sussex.ac.uk Thu Jul 2 09:46:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A473A6C01 for ; Thu, 2 Jul 2009 09:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrxIqUmLxIOe for ; Thu, 2 Jul 2009 09:46:41 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id B61363A6D84 for ; Thu, 2 Jul 2009 09:43:54 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:61387) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM5YJO-000H5O-NI for asrg@irtf.org; Thu, 02 Jul 2009 17:45:24 +0100 Date: Thu, 02 Jul 2009 17:44:03 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <99C83E3C60B16E2C2037C7C5@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <4A4CE00D.3020802@nortel.com> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> <4A4CDB33.9000908@billmail.scconsult.com> <4A4CE00D.3020802@nortel.com> Originator-Info: login-token=Mulberry:01T60zx7gOoSyQGocpu9PCIqY6tSVUIbLTxBg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:46:43 -0000 --On 2 July 2009 12:27:57 -0400 Chris Lewis wrote: > Bill Cole wrote: >> Ian Eiloart wrote, On 7/2/09 6:23 AM: > >>> Exercise for the reader: why aren't spammers using the @ibm.com domain? >> >> You provided the answer before the question. > > Somewhat. Because spammers _are_ using @ibm.com too. I got samples ;-) Ok, but it's trivial to reject them after checking SPF. > Anybody saying "spammers don't do X" and "spammers do X" are wrong at > least some of the time. Except for the obvious tautology that "spammers > spam". > >> Forged sender addresses are predominantly harvested rather than purely >> invented or recombinantly assembled. > > IOW: the biggest asset spammers have is lists of potential spam victim's > email addresses. > > What better place to get the email addresses to forge as sender than from > the exact same list? Is it so hard to imagine that a bot might do this > or some variation? > > 1) Read a bunch of addresses > 2) Spam the bunch of addresses, forged with one of the bunch as sender > 3) Goto step 1 > > Various corollaries: > > - If you get spam, you're probably being forged as sender in other spam. > > - If they're hitting valid addresses, then there will be blowback _to_ > valid addresses. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From CLEWIS@nortel.com Thu Jul 2 10:02:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893C53A6B5F for ; Thu, 2 Jul 2009 10:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAD3miqx7hw2 for ; Thu, 2 Jul 2009 10:02:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9E64A3A6890 for ; Thu, 2 Jul 2009 10:02:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n62H1iZ24181 for ; Thu, 2 Jul 2009 17:01:44 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:03:14 -0400 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Jul 2009 13:03:13 -0400 Message-ID: <4A4CE850.60105@nortel.com> Date: Thu, 2 Jul 2009 13:03:12 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> <4A4CDB33.9000908@billmail.scconsult.com> <4A4CE00D.3020802@nortel.com> <99C83E3C60B16E2C2037C7C5@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <99C83E3C60B16E2C2037C7C5@seana-imac.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 17:03:14.0022 (UTC) FILETIME=[FC861060:01C9FB36] Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:02:57 -0000 Ian Eiloart wrote: > > --On 2 July 2009 12:27:57 -0400 Chris Lewis wrote: > >> Bill Cole wrote: >>> Ian Eiloart wrote, On 7/2/09 6:23 AM: >>>> Exercise for the reader: why aren't spammers using the @ibm.com domain? >>> You provided the answer before the question. >> Somewhat. Because spammers _are_ using @ibm.com too. I got samples ;-) > > Ok, but it's trivial to reject them after checking SPF. Don't need to. They're all being rejected by either "no such user" or the spam filter rejects. SPF isn't worth the cycles nor bandwidth (in this environment at least) to catch the rare SPF -all. From CLEWIS@nortel.com Thu Jul 2 10:21:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04F33A6B8F for ; Thu, 2 Jul 2009 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuEtme44+7ZL for ; Thu, 2 Jul 2009 10:21:36 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7D34B28C241 for ; Thu, 2 Jul 2009 10:20:12 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n62HIhZ26387 for ; Thu, 2 Jul 2009 17:18:43 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:20:12 -0400 Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Jul 2009 13:20:11 -0400 Message-ID: <4A4CEC4B.3080004@nortel.com> Date: Thu, 2 Jul 2009 13:20:11 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> <4A4CDB33.9000908@billmail.scconsult.com> <4A4CE00D.3020802@nortel.com> <99C83E3C60B16E2C2037C7C5@seana-imac.staff.uscs.susx.ac.uk> <4A4CE850.60105@nortel.com> In-Reply-To: <4A4CE850.60105@nortel.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 17:20:12.0533 (UTC) FILETIME=[5B9A8250:01C9FB39] Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:21:36 -0000 Lewis, Chris (CAR:W669) wrote: > Ian Eiloart wrote: >> --On 2 July 2009 12:27:57 -0400 Chris Lewis wrote: >> >>> Bill Cole wrote: >>>> Ian Eiloart wrote, On 7/2/09 6:23 AM: >>>>> Exercise for the reader: why aren't spammers using the @ibm.com domain? >>>> You provided the answer before the question. >>> Somewhat. Because spammers _are_ using @ibm.com too. I got samples ;-) >> Ok, but it's trivial to reject them after checking SPF. > > Don't need to. They're all being rejected by either "no such user" or > the spam filter rejects. > > SPF isn't worth the cycles nor bandwidth (in this environment at least) > to catch the rare SPF -all. I should add - _if_ spammers are using the "-all" to screen out bad senders to use, then the mere existance of SPF as a "standard" has some value to push spammers away from forging certain high-value-target domains literally and thus marginally reduce backscatter because of spammer-behaviour-modification. Perhaps. But it doesn't imply that implementing any SPF checking will make any noticeable difference. Indeed, the only concrete numbers I've ever seen about SPF adoption were percentages of domains publishing SPF records due to noises being made by MSN/Hotmail, _not_ checking SPF. Nobody has a handle on how many have actually implemented SPF checking. The only stats I've seen about backscatter volume pre/post SPF publication don't show any compelling reason to believe SPF made any difference. There's no particular reason to believe that it's going to get any better either. We publish, but do not check simply because of the noises that MSN/Hotmail were making. Publishing (and erroneous checking) has probably caused more problems (elsewhere) than it's solved. From asrg3@billmail.scconsult.com Thu Jul 2 10:37:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA2028C1ED for ; Thu, 2 Jul 2009 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWYMNj-SkYqA for ; Thu, 2 Jul 2009 10:37:05 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 59C2928C162 for ; Thu, 2 Jul 2009 10:37:05 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 561428E3D22 for ; Thu, 2 Jul 2009 13:37:17 -0400 (EDT) Message-ID: <4A4CF04A.6010401@billmail.scconsult.com> Date: Thu, 02 Jul 2009 13:37:14 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <20090629120826.GA6823@gsp.org> <4A49CFCC.7040802@tana.it> In-Reply-To: <4A49CFCC.7040802@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:37:06 -0000 Alessandro Vesely wrote, On 6/30/09 4:41 AM: [...] > Thanks for confirming that. My feeling is that we are overloading IP > numbers with an accountability functionality that doesn't belong there. There's a strong reason for this: the immediate client IP is the one fact about *every* MX-driven attempt at message transport that the receiving MTA can know with very high certainty, even when the message is originated by someone who intentionally and maliciously tries to hide his identity. Whether accountability *should* be tied to that one knowable fact is a philosophical question. As a practical matter, there has proven to be little choice. For some years early in the growth of spam, filtering techniques were applied and over time largely discarded or relegated to scoring systems which assumed that spammers would not falsify other elements of mail and its transport that should lead back to the ultimate originator or to someone who can identify and police the originator. Having run out of headers and transport features to check, we've developed new things like SPF and DKIM that are harder to spoof but suffer from inadequate adoption to really fix a large part of the problem, much as the previous transport and content encryption and signing mechanisms have. From asrg3@billmail.scconsult.com Thu Jul 2 10:37:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C8428C1DE for ; Thu, 2 Jul 2009 10:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbeZR6kbKshq for ; Thu, 2 Jul 2009 10:37:14 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 95E8928C0D8 for ; Thu, 2 Jul 2009 10:37:14 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 8A3118E3D23 for ; Thu, 2 Jul 2009 13:37:17 -0400 (EDT) Message-ID: <4A4CF04C.8010908@billmail.scconsult.com> Date: Thu, 02 Jul 2009 13:37:16 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <20090629120826.GA6823@gsp.org> <4A49CFCC.7040802@tana.it> In-Reply-To: <4A49CFCC.7040802@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:37:15 -0000 Alessandro Vesely wrote, On 6/30/09 4:41 AM: [...] > Thanks for confirming that. My feeling is that we are overloading IP > numbers with an accountability functionality that doesn't belong there. There's a strong reason for this: the immediate client IP is the one fact about *every* MX-driven attempt at message transport that the receiving MTA can know with very high certainty, even when the message is originated by someone who intentionally and maliciously tries to hide his identity. Whether accountability *should* be tied to that one knowable fact is a philosophical question. As a practical matter, there has proven to be little choice. For some years early in the growth of spam, filtering techniques were applied and over time largely discarded or relegated to scoring systems which assumed that spammers would not falsify other elements of mail and its transport that should lead back to the ultimate originator or to someone who can identify and police the originator. Having run out of headers and transport features to check, we've developed new things like SPF and DKIM that are harder to spoof but suffer from inadequate adoption to really fix a large part of the problem, much as the previous transport and content encryption and signing mechanisms have. From dotis@mail-abuse.org Thu Jul 2 12:43:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7504B3A6D84 for ; Thu, 2 Jul 2009 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va0Jskomo+1x for ; Thu, 2 Jul 2009 12:43:33 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3F78E3A693F for ; Thu, 2 Jul 2009 12:43:33 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F1676A94448 for ; Thu, 2 Jul 2009 19:43:53 +0000 (UTC) Message-Id: <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A4CCC56.8090804@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 12:43:53 -0700 References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <4A4CCC56.8090804@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:43:34 -0000 On Jul 2, 2009, at 8:03 AM, Alessandro Vesely wrote: > Douglas Otis wrote: >> On Jul 1, 2009, at 7:20 AM, Alessandro Vesely wrote: >>> John Leslie wrote: >>>> The CSV paradigm is that the operator of a MTA should exercise >>>> some responsibility for what is sends. The HELO string identifies >>>> the MTA (though not necessarily one string exclusively by one >>>> MTA), and the DNS management for that domain-name string states >>>> whether that domain exercises responsibility (and by automatic >>>> return of A)ddress RRs on SRV queries, what IP address(es) that >>>> MTA uses). >>> >>> The link from the MTA to its operator is still missing. >> Disagree. Based on our results, when only a few domains publish an >> IP addresses of an Outbound MTA, it is rather safe to assume the >> domains represented by verified EHLO information resolve who is >> administrating the MTA. > > In general an MTA provides a FQDN like mta.example.com, and we are > unable to say whether it "is a member of" example.com. In addition, > the MTA's administrator may be unrelated to example.com's registrant. When the EHLO host name references IP addresses that match the Outbound MTA, this verifies there is a common administration between the FQDN and DNS. CSV ensures this relationship can be established, and also asserts the system is an outbound MTA. >> When there are many domains, this appears to represent either MTAs >> operating behind a NAT, or compromised systems; sometimes both. > > I don't understand that kind of setup. Multiple MTAs operating > behind a NAT have no way to receive mail, so they are only sending > SMTP clients. Is inertia the only reason why they don't use an MSA? Unfortunately, Outbound MTAs behind NATs is more common that it should be, especially in Poland and Brazil. Outbound MTAs can operate behind NATs. Outbound MTAs can be unrelated to where their mail is received. Even so, port 25 of the NAT can be nailed to a host within the NAT's private address space. Outbound MTAs behind a NAT is fairly common in office environments. The presence of multiple EHLO host names within the NATed office environment however appears to be most often due to compromised systems behind the same NAT. >> It appears to be rare for legitimate Outbound MTAs to change domain >> affiliations. From a reputation standpoint, verified EHLO >> information offers stable identifiers in which to effectively and >> efficiently manage email abuse. > > It seems that vanity domains don't mind if the MX record points to > an MTA in another domain. The intricacies of having CNAMEs near MX > settings presumably refrained also from assigning multiple names, > one for each vanity domain, to a given MTA. However, some do it. Don't confuse Outbound MTAs with that of Inbound MTAs. This has nothing to do with MX records. > On an SMTP connection, a client says: "Hello mta.example.com", and > after I accept that, it goes on with "Mail from:". > What does that mean, in terms of accountability? With EHLO mta.example.com and a history of that host name being used by small range of IP addresses, and conversely, the IP address consistently reporting the same host name, then acceptance of messages from this Outbound MTA is likely safe. When the mta.example.com also references a CSA record, there is even further assurance the exchange is not emitted by a compromised system, which currently represents the greatest source for spam. From a reputation perspective, the name and IP address relationships that need to be tracked for Outbound MTAs represent data sets orders of magnitude smaller and dramatically more stable that that represented by MAIL commands or PRAs. Once EHLO relationship can be verified, it should permit safe inclusion of IPv6 addresses. MAIL commands or PRAs do not offer the needed stability nor are these relationships readily verified without potentially burdensome overhead that might be directed to innocent third-parties. >>> To this end, I'd prefer the use of a domain name. > > This guy is relaying on behalf of someone else. If I had verified > the "example.com" possibly registered domain, I would spot it more > easily. If example.ORG is a vanity name, i.e. it has the same MX as > example.com, I accept it. If not, I wouldn't know who is accountable > for the message, so I reject it. Do not confuse Inbound MTAs with Outbound MTAs. Even without the host name having been verified, the host name and IP address information inconsistencies can lead to safe rejections. > In case mta.example.com runs outbound MTA services for third > parties, I would hold the originating third party accountable for > the message. Why not hold the entity offering access to those abusing email accountable? You have no assurance whether third-party domains originated the message, even when the domain offers authorization. This assumes Outbound MTAs ensure both the PRA and MAIL commands are restricted to specific and verified users. While this might be the case, this is not the norm. It would also be foolish to annotate email as having been "authenticated" on the basis of Outbound MTA authorization for the same reason. Large companies place a higher priority on their messages being received than ensuring authorizations do not expose exploits to bad actors. In addition, a growing number of exploits now leverage social networks that convey who recipients trust. Spoofed sources of phish are not necessarily that of large banks or financial institutions. > However, there is no way I can tell that is indeed the case, neither > from the IP address nor from the name. I'd need, say, a CSA SRV > record from example.ORG saying: "we authorize mta.example.com", > _and_ on starting a new session the client shall say: "Hello on > behalf of example.ORG: check their CSA settings". No guessing > required, then. Yes, the CSA record would help, but this EHLO information still offers value. Especially when considering the use of IPv6 where block lists are unlikely to prove effective. >> While larger ISPs are likely to have a few hundred outbound MTAs, >> they represent a very small percentage of overall legitimate >> Outbound MTAs. > > However, they transmit lots of messages. It is still easier to correlate EHLO host names to that of a small set of IP addresses. That is not the case for MAIL commands or PRAs. >> Being able to identify legitimate Outbound MTAs reduces the vetting >> of hundreds of millions of domains associated with Mail From or >> PRAs, where each domain likely covers massive address lists. > > Exactly. Those legitimate Outbound MTAs are probably connected to an > MSA. When we identify them, we enjoy the advantages deriving from > users going through their relevant MSAs, as we recommended, rather > than relaying through whatever MTA they have at hands, or directly. The issue is not whether there is some mapping of users to specific MSAs. In fact, it is not practical to track this type of many to many relationships. The issue is simpler than that. The issue is to simply hold the Outbound MTA accountable for the message sources for whom it grants access. DKIM offers a reliable means to verify where a message originated without impractical and unscalable efforts aimed at registering all authorized paths for MAIL commands or PRAs. DKIM is not about managing spam however. >> Efforts to combine the addresses used by a domain is counter >> productive when it comes to resolving problems, or when dealing >> with initial SMTP connections. When it comes to SMTP, direct >> relationships involve less overhead which improves efficacy and >> efficiency to the point of perhaps permitting use of IPv6. > > In some cases, names can be handled better than IP numbers. After > all, that's why they invented the DNS... While true for EHLO commands, IP addresses associated with MAIL commands or PRAs will normally exceed DNS response limits where truncation will induce failure. The resulting chaining of DNS transactions, along with inclusion of macros found with SPF, failed to properly consider the potential system impact nor what DNSSEC could produce. Verifying a DNS relationship between single hosts and their limited IP address list remains much less problematic and far safer. DNS CIDR notation is specified by RFC 3123. This resource record can still be used to establish email white-list strategies instead of SPF records. APL records exclude potentially problematic macros as well. Since email CIDR records should not be obtained in response to SMTP connections, APL might be chained with a convention for _n._smtp APL, as an alternative publishing location for _smtp APL. When _smtp is truncated, either TCP fallback could be used, or _[0-9]._smtp APL queries might be used to recover from response truncation. -Doug From asrg3@billmail.scconsult.com Thu Jul 2 21:34:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFEA3A6927 for ; Thu, 2 Jul 2009 21:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMemINomRcL0 for ; Thu, 2 Jul 2009 21:34:11 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 8298B3A67EA for ; Thu, 2 Jul 2009 21:33:42 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 226C88E43E8 for ; Fri, 3 Jul 2009 00:33:56 -0400 (EDT) Message-ID: <4A4D8A34.8000106@billmail.scconsult.com> Date: Fri, 03 Jul 2009 00:33:56 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> In-Reply-To: <4A49C1DD.8020205@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 04:34:12 -0000 Alessandro Vesely wrote, On 6/30/09 3:42 AM: > Bill Cole wrote: >> 1. There is no working global mechanism for identifying an accountable >> party (i.e. one who explicitly *accepts* accountability) from an IP >> address, due largely to the political and historical variations in how >> IP addresses have been allocated. > > At a first glance, this may seem a flaw in the rDNS/whois systems. Upon > reconsideration, I realize I have no means to accept accountability for > an IP address of mines, since SPF or CSV/CSA only convey authorization > for using a name. In facts, we don't even have a term for "the > accountable party related to an IP address". See RFC1183, which defines the "Responsible Party" RR type (RP). It states that a RP record can be associated with any node in the DNS hierarchy, and of course in-addr.arpa is part of the DNS hierarchy. RP records are rarely published, and their operational use is even rarer. In my experience, RFC1183 is referenced most frequently as a caution against expecting too much from the RFC process. > Dave's Email Arch mentions an Originator as "accountable for the message > content", but doesn't relate it to an IP address. Rfc5068 associates > accountability after submission with traceability features of the MSA, > apparently suggesting that the first relaying thereafter is from an IP > which is (indirectly) accountable for the message content. Reasoning by > induction on the hops, one may conclude that all relays using a > smarthost are accountable: smarthosts require either IP/firewall > configuration or authentication (assuming they are not open relays.) > Accountability breaks at the MX-driven relay, often referred as "boundary". My reason for citing the IP address is that the IP address of the immediate client is the only fact that a host acting as an MX can trust to any useful degree for every message offered to it. Absent a means of reliably and quickly identifying a responsible party from *any* legitimate client IP, the suggestion that every MUA might be its own MSA is irrelevant. >> Funneling email through MSA systems run by providers that in principle >> have some means of holding their users accountable and are capable of >> at least understanding bad behavior in mail if not always keeping it >> controlled is the best partial workaround we have, and it implies the >> need for domain-level accountability or its equivalent. > > Why is it partial? Because all it does is narrow the population of legitimate MX clients to a set that are more likely to have some responsible party identifiable by some means. Yet at the same time, the responsible party for a outbound mail server handling mail from many ultimate originators may well simultaneously reject full responsibility for spam it transports and refuse to identify the ultimate originator. The best examples of this for me are the big freemail providers, all of whom seem to have shunned the entire notion of accountability. > "Domain-level accountability" is a good approximation. Only in a relative sense. In an absolute sense, it has proven rather poor. All it takes for domain-level accountability to fail is a big enough domain. > However, a > smarthost is not necessarily within the same domain (e.g. ukisp.com is > not even in the same 1st level domain) or the same organization. How > does accountability degrade through indirection? That is, would you > trust an SMTP client the same if it relays on behalf of some other party? Of course not. From danny.angus@gmail.com Fri Jul 3 01:31:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEB73A6C98 for ; Fri, 3 Jul 2009 01:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9iZdomh28Zn for ; Fri, 3 Jul 2009 01:31:33 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D58A728C1D7 for ; Fri, 3 Jul 2009 01:30:03 -0700 (PDT) Received: by fxm9 with SMTP id 9so2064507fxm.7 for ; Fri, 03 Jul 2009 01:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=oyonDHqOAEXurtubowZ8QwyhvxxOcBGx4p1/aEWww3g=; b=Qqz9IwdiG8Vb3Des/hF5P7qKkD18NoTndwvLHxMii21FCNHu2r23IdNI8NZ9fFqzoR zFVKlRXEhIyBOfIBJ57GkJd6NYC1xc79YhSiibCS2UJkcVMMXjYvb6vUOQZ+O0EvpXNg FTD4DPlvXoHidW+KZxTGKPUwxw01W1KVTuhu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RwTnG+9+7SLl/+rxqOTEqzkdrO575J/phUD3v8k+WpMw4LdAsXpRDlR69OaqcmnVtg 9IwyRSvveRGXblYTLpeaN1KLICsaPMMv82t3VxAsN0eeYma/Dm+13F07DKaRBLb3UJ3b t57J3MyE/KAGoigsxh0zapNB0N0iWpM8txDIk= MIME-Version: 1.0 Received: by 10.223.111.71 with SMTP id r7mr650223fap.59.1246609823348; Fri, 03 Jul 2009 01:30:23 -0700 (PDT) In-Reply-To: <4A4B6188.90708@telmon.org> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> <4A4B57C8.2000207@tana.it> <4A4B6188.90708@telmon.org> Date: Fri, 3 Jul 2009 09:30:23 +0100 Message-ID: <5ec229170907030130h45a18b56vb64737be1a892668@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:31:34 -0000 I agree with Alessandro's point, I think the definition section would be more appropriate if it described the problem of definition and encouraged the authors of proposed techniques to describe the scope of their technique, with an optional working definition of the term. It is then up to the adopters of the technique to decide whether or not its effects would alleviate the problems with which they are concerned. I also agree with Claudio in that at an academic level our inability to define the term will automatically make the problem unsolvable because we can't state the problem. However on an empirical view we do know how to recognise a solution, and so we can re-target our definition of a solution to being any technique which can pass agreed empirical tests, and that the definition of the problem then becomes the inverse of the tests for an effective technique, whether or not that can be easily expressed in a succinct form of words. d. From danny.angus@gmail.com Fri Jul 3 01:44:59 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A313A6C0D for ; Fri, 3 Jul 2009 01:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vorQySPqSQqC for ; Fri, 3 Jul 2009 01:44:58 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2645E3A68FD for ; Fri, 3 Jul 2009 01:44:57 -0700 (PDT) Received: by fxm9 with SMTP id 9so2071997fxm.7 for ; Fri, 03 Jul 2009 01:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gGLKo1U1tG9+R5AII5yN98ugYqBdbT2woTIKuWtqQqI=; b=UMhaUa71j5zgfhCe0PXrs3Q33S1IPEEUbqP297e8Flhy3+eOWavVquEoLR3Q+0giqB Zn1xfEy4a84NdQyKwXe3qFqYYhnIWlXKasJIiMr5gQ6Xj+AOQLYZJsdKXYvF73hiyaot wgz29ytyE3ueSONe+Gzw9v+VQnjISutXFU3fM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=sVsIu3/i2u048CksDGR1YGxFPmP+SXtuBx/bW1Aa/huiSNlyKPrEWDEjg+Iw0GmPnN HCPASozdiHOKLugGw1WEiMMNUxVlfxSZ0uODWFiFPS0UpoFcJaQx+2SPWJCCNh2tG2lB wP5eZco+Lzj3qZ+DE6zUWBeVvdhszm8+1RIX0= MIME-Version: 1.0 Received: by 10.223.106.15 with SMTP id v15mr695086fao.15.1246610718333; Fri, 03 Jul 2009 01:45:18 -0700 (PDT) In-Reply-To: <0F6FD8D3-3A40-4BAE-BCA0-A06586DB4655@mail-abuse.org> References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> <5ec229170906292346o375faf34m273f6499029f333a@mail.gmail.com> <0F6FD8D3-3A40-4BAE-BCA0-A06586DB4655@mail-abuse.org> Date: Fri, 3 Jul 2009 09:45:18 +0100 Message-ID: <5ec229170907030145q7c687a97y807168d934127af0@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:44:59 -0000 On Wed, Jul 1, 2009 at 11:11 PM, Douglas Otis wrote: > Please carefully review the Sender definition. Ok. I take your point. The intention was to define a means of achieving the same effect as PRA which is not encumbered by IP, in doing so I think I've grandfathered in all of the weaknesses of PRA. I now think that this is inappropriate in this context, and that the sender definition should define the concept of a responsible originating entity and leave the authors of techniques with the problem of identification should their technique require it. >>> Stronger statements along the lines of scaling might be helpful. =C2=A0= It >>> seems increasing potential DNS transactions by an order of magnitude or= more >>> has not been given adequate consideration in some anti-spam efforts. :^= ( Douglas, I agree with that sentiment. But when you say this: > These statements are not strong enough. =C2=A0Email is being heavily abus= ed. > =C2=A0Every incremental overhead must be carefully reviewed as to its pot= ential > impact. I wonder just how I would strengthen this: " any Proposed Technique MUST NOT achieve its end at the expense of offloading the burden of cost onto External Systems without also passing on any benefit to External Systems." I think that any technique which managed to remove spam, reduce load on the mail transport system and not involve any other components in any new work would be an impossible utopia (or not SMTP!) . Perhaps you could give me an example of wording which would meet your needs= ? d. > > -Doug > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > From danny.angus@gmail.com Fri Jul 3 01:46:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16D728C133 for ; Fri, 3 Jul 2009 01:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEenk2l1Yhnj for ; Fri, 3 Jul 2009 01:46:09 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id EC5013A6BB9 for ; Fri, 3 Jul 2009 01:46:08 -0700 (PDT) Received: by fxm9 with SMTP id 9so2072653fxm.7 for ; Fri, 03 Jul 2009 01:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=K55ifYpvHm3IzylFd6OMm5QPkF1SxvKDtq9W+pGm2DI=; b=HbULqo5elHTTn5GEUNS+aHo1eFW7fDNhNpuX7Io7VfYSCYsY8+qd2/oVmkPyvJA/oM HNl6CFndwHfirL9TmfAv9pPJBorfUIl03Pt5lRkBOm5wb773S7JhYDxIzauRIIPfPDAI wITBh0YX+qCfKp/0a0ZNca1oDJUdNwCef7Li4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=TcJcYcO4eU2rwA8wG/i73HermHU8saJ4EUiuvbR3BT6BF58JMsVK38gXjAla0OR8m/ TwgqnqN5rS3IsyZ+/7/A2BelLeN2zUR1lQ9CTNJaJUK9lg4nZCXTr++SsvgxRidM5hdF 7ArgUKGt3Ev1k+oC8H0Xj+I8FoHJ/KlaJUGX8= MIME-Version: 1.0 Received: by 10.223.111.71 with SMTP id r7mr668245fap.59.1246610790240; Fri, 03 Jul 2009 01:46:30 -0700 (PDT) In-Reply-To: <20090702141349.26334.qmail@simone.iecc.com> References: <4A4BB460.9020205@cybernothing.org> <20090702141349.26334.qmail@simone.iecc.com> Date: Fri, 3 Jul 2009 09:46:30 +0100 Message-ID: <5ec229170907030146k2c9e9efes5b326eb0c3629bd0@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:46:10 -0000 > If people here were willing to put 1/10 of the work into research that they > do into arguing, we might have some actual research. Amen. > Perhaps I should make it so that whenever you update the wiki (where > we are ever so slowly building a taxonomy of anti-spam techniques and > even more slowly of spamming techniques) you get a credit that allows > you to send one message. +1 d. From vesely@tana.it Fri Jul 3 02:10:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B8E3A6A86 for ; Fri, 3 Jul 2009 02:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q48rr1HzTYDe for ; Fri, 3 Jul 2009 02:10:22 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 428B13A6940 for ; Fri, 3 Jul 2009 02:10:21 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 03 Jul 2009 11:10:42 +0200 id 00000000005DC036.000000004A4DCB12.0000525A Message-ID: <4A4DCB11.1000909@tana.it> Date: Fri, 03 Jul 2009 11:10:41 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090702141349.26334.qmail@simone.iecc.com> In-Reply-To: <20090702141349.26334.qmail@simone.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:10:23 -0000 John Levine wrote: > If people here were willing to put 1/10 of the work into research that they > do into arguing, we might have some actual research. By translating arguing into the collective refinement of concepts on this list, and research into the consolidation of any discussion results in the wiki, the above statement may become an operative recipe. > Perhaps I should make it so that whenever you update the wiki (where > we are ever so slowly building a taxonomy of anti-spam techniques and > even more slowly of spamming techniques) you get a credit that allows > you to send one message. The opposite resolution, to grant write access to the wiki to whoever posts one message, might also increase research in the above sense. From iane@sussex.ac.uk Fri Jul 3 02:22:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1876C28C133 for ; Fri, 3 Jul 2009 02:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 988LQsaIV0OY for ; Fri, 3 Jul 2009 02:22:22 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id C725D28C1E4 for ; Fri, 3 Jul 2009 02:22:21 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:57911) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM78QX-000FAS-FK for asrg@irtf.org; Fri, 03 Jul 2009 10:23:21 +0100 Date: Fri, 03 Jul 2009 10:22:21 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <45BAB0F4B7BC2DC23561EAFB@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <4A4CE850.60105@nortel.com> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> <20090701150032.GB15652@verdi> <7ae58c220907010812s6831475fv485aa6a75baddb94@mail.gmail.com> <4A4CDB33.9000908@billmail.scconsult.com> <4A4CE00D.3020802@nortel.com> <99C83E3C60B16E2C2037C7C5@seana-imac.staff.uscs.susx.ac.uk> <4A4CE850.60105@nortel.com> Originator-Info: login-token=Mulberry:01b7VK49gWuEiwIp5F29viKr1W1S1rPdLb5CA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:22:23 -0000 --On 2 July 2009 13:03:12 -0400 Chris Lewis wrote: > Ian Eiloart wrote: >> >> --On 2 July 2009 12:27:57 -0400 Chris Lewis wrote: >> >>> Bill Cole wrote: >>>> Ian Eiloart wrote, On 7/2/09 6:23 AM: >>>>> Exercise for the reader: why aren't spammers using the @ibm.com >>>>> domain? >>>> You provided the answer before the question. >>> Somewhat. Because spammers _are_ using @ibm.com too. I got samples ;-) >> >> Ok, but it's trivial to reject them after checking SPF. > > Don't need to. They're all being rejected by either "no such user" or > the spam filter rejects. > > SPF isn't worth the cycles nor bandwidth (in this environment at least) > to catch the rare SPF -all. There are a few prime domains that publish -all records. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Fri Jul 3 04:48:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9CB3A6CCF for ; Fri, 3 Jul 2009 04:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJWE6GTL79W for ; Fri, 3 Jul 2009 04:48:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9A0713A68EA for ; Fri, 3 Jul 2009 04:48:04 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 03 Jul 2009 13:48:23 +0200 id 00000000005DC031.000000004A4DF007.00006EC3 Message-ID: <4A4DF007.6070909@tana.it> Date: Fri, 03 Jul 2009 13:48:23 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <4A4CCC56.8090804@tana.it> <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> In-Reply-To: <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 11:48:06 -0000 Douglas Otis wrote: >> In general an MTA provides a FQDN like mta.example.com, and we are >> unable to say whether it "is a member of" example.com. In addition, >> the MTA's administrator may be unrelated to example.com's registrant. > > When the EHLO host name references IP addresses that match the Outbound > MTA, this verifies there is a common administration between the FQDN and > DNS. CSV ensures this relationship can be established [...] That is not the case. The hostmasters at example.com can unilaterally delegate mta.example.com the way they wish, with no obligation whatsoever to run a whois service or otherwise publish data about their delegate's admins, if any, let alone taking accountability for what such admins would do. > Outbound MTAs can be unrelated to where their mail is received. > Even so, port 25 of the NAT can be nailed to a host within the NAT's > private address space. Outbound MTAs behind a NAT is fairly common in > office environments. Yeah, I used to suggest that setting myself, since most of (legit) mail traffic is intra-office. They may collect external mail running cron-scheduled POP clients. However, with today's connections and legit mail being a tiny fraction of mail traffic, I see no reason for keeping those servers. I regard them as historical settings, and recommend using SUBMIT+IMAP on secured channels. > With EHLO mta.example.com and a history of that host name [...] > From a reputation perspective, the name and IP address relationships > that need to be tracked for Outbound MTAs represent data sets orders of > magnitude smaller and dramatically more stable that that represented by > MAIL commands or PRAs. However, one year after changing the IP address of my MTA, many MX receivers are not yet up to date. I'll have to manually update that, where possible, taking into account each domain idiosyncrasies. It is so because those name-address relationships are still too many. If you consider only the right hand side (RHS) of MAIL or PRAs, you'll get much smaller figures. >> In case mta.example.com runs outbound MTA services for third parties, >> I would hold the originating third party accountable for the message. > > Why not hold the entity offering access to those abusing email accountable? If they just offer a transport service, I see no reason I should. Vice-versa, if they are accountable, then _they_ are the true MTA, transmitting on behalf of what I called a vanity domain. (This distinction does not have to be static, as example.ORG may send directly in some cases, via example.com in others.) > You have no assurance whether third-party domains originated the > message, even when the domain offers authorization. This assumes > Outbound MTAs ensure both the PRA and MAIL commands are restricted to > specific and verified users. While this might be the case, this is not > the norm. OTOH, if we cannot spot whether an MSA has been used, the advantages of clean transmission remain confined within the first hop. An MTA who accepted to relay on behalf of an authenticated user may be willing to take accountability. The point is that it has no verb to express that will. > It would also be foolish to annotate email as having been > "authenticated" on the basis of Outbound MTA authorization for the same > reason. Large companies place a higher priority on their messages being > received than ensuring authorizations do not expose exploits to bad > actors. If they take accountability, then it's their problem. Their vouchers should take that behavior into account. >> However, there is no way I can tell that is indeed the case, neither >> from the IP address nor from the name. I'd need, say, a CSA SRV record >> from example.ORG saying: "we authorize mta.example.com", _and_ on >> starting a new session the client shall say: "Hello on behalf of >> example.ORG: check their CSA settings". No guessing required, then. > > Yes, the CSA record would help, but this EHLO information still offers > value. Especially when considering the use of IPv6 where block lists > are unlikely to prove effective. I agree EHLO information has some value. In some cases, it may be redundant (e.g. if there is a vouch, or in case of ideal DNS settings.) In most cases, it is not enough, as it doesn't lead to an accountable administrator's name, address, phone number, etc. > The issue is simpler than that. The issue is to simply > hold the Outbound MTA accountable for the message sources for whom it > grants access. DKIM offers a reliable means to verify where a message > originated without impractical and unscalable efforts aimed at > registering all authorized paths for MAIL commands or PRAs. Both Outbound MTAs and DKIM offer no hint about a message's Originator and related accountability issues. For counting, note that the number of DKIM signers potentially exceeds the number of valid RHS domain names, since each mail domain can be a DKIM signer, but a DKIM signer doesn't have to be a mail domain. > DNS CIDR notation is specified by RFC 3123. This resource record can > still be used to establish email white-list strategies instead of SPF > records. APL records exclude potentially problematic macros as well. > Since email CIDR records should not be obtained in response to SMTP > connections, APL might be chained with a convention for _n._smtp APL, as > an alternative publishing location for _smtp APL. When _smtp is > truncated, either TCP fallback could be used, or _[0-9]._smtp APL > queries might be used to recover from response truncation. However well designed, such scheme will thickens the ranks of mail transmitter authentication schemes. All of them are optional, and checking which one may apply requires an increasing amount of DNS transactions, possibly amplified by DNSSEC. That's why VHLO, besides taking the mail domain of the accountable organization, can also take the parameters indicating which authentication method applies. From dotis@mail-abuse.org Fri Jul 3 09:51:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2303A6C6A for ; Fri, 3 Jul 2009 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z4anBkC8YQb for ; Fri, 3 Jul 2009 09:51:46 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id B53F528C16D for ; Fri, 3 Jul 2009 09:51:46 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B2F15A945FA for ; Fri, 3 Jul 2009 16:52:09 +0000 (UTC) Message-Id: <5E797CAD-5510-49F4-A53E-995C5E4BC41E@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A4DF007.6070909@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 3 Jul 2009 09:52:09 -0700 References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <4A4CCC56.8090804@tana.it> <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> <4A4DF007.6070909@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:51:48 -0000 On Jul 3, 2009, at 4:48 AM, Alessandro Vesely wrote: > Douglas Otis wrote: >>> In general an MTA provides a FQDN like mta.example.com, and we are >>> unable to say whether it "is a member of" example.com. In >>> addition, the MTA's administrator may be unrelated to >>> example.com's registrant. >> >> When the EHLO host name references IP addresses that match the >> Outbound MTA, this verifies there is a common administration >> between the FQDN and DNS. CSV ensures this relationship can be >> established [...] > > That is not the case. The hostmasters at example.com can > unilaterally delegate mta.example.com the way they wish, with no > obligation whatsoever to run a whois service or otherwise publish > data about their delegate's admins, if any, let alone taking > accountability for what such admins would do. The goal is to establish stable and fair identifiers. Once a direct DNS relationship with that of a host can be verified, this serves as a identifier controlled by _some_ administrator. Verification of a DNS relationship allows negative host stewardship assessments to be fairly made based upon the identifier. A fair and stable identifier is being sought. Not one that represents some person. Anonymous tokens help avoid claims of individual censorship. The application of host stewardship assessments can allow spam to be effectively and efficaciously managed, and is how accountability can be established. >> Outbound MTAs can be unrelated to where their mail is received. >> Even so, port 25 of the NAT can be nailed to a host within the >> NAT's private address space. Outbound MTAs behind a NAT is fairly >> common in office environments. > > Yeah, I used to suggest that setting myself, since most of (legit) > mail traffic is intra-office. They may collect external mail running > cron-scheduled POP clients. However, with today's connections and > legit mail being a tiny fraction of mail traffic, I see no reason > for keeping those servers. I regard them as historical settings, and > recommend using SUBMIT+IMAP on secured channels. Those with a DS3 serving their office network may expect they have an ability to publicly send email to other domains. >> With EHLO mta.example.com and a history of that host name [...] >> From a reputation perspective, the name and IP address >> relationships that need to be tracked for Outbound MTAs represent >> data sets orders of magnitude smaller and dramatically more stable >> that that represented by MAIL commands or PRAs. > > However, one year after changing the IP address of my MTA, many MX > receivers are not yet up to date. I'll have to manually update that, > where possible, taking into account each domain idiosyncrasies. It > is so because those name-address relationships are still too many. > If you consider only the right hand side (RHS) of MAIL or PRAs, > you'll get much smaller figures. Dependence upon just the domain of MAIL commands or PRAs would be vulnerable to exploitation. Assertions that authorizations offer authentication are not safe. In addition, there are hundreds of millions of MAIL command or PRA domains to be tracked, white there is about two to three orders of magnitude fewer EHLO domains. A mistake made with a MAIL command or PRA domain will create serious and irreconcilable problems for the domain. A mistake made with a EHLO host is both less likely, and will be far less catastrophic since services elsewhere can be sought. In addition to being safer, more accurate, EHLO assessments are more efficacious and effective. There are fewer in which to deal with, and this instills a hierarchy of management that better confronts rampant abuse largely caused by bot- nets. >>> In case mta.example.com runs outbound MTA services for third >>> parties, I would hold the originating third party accountable for >>> the message. >> Why not hold the entity offering access to those abusing email >> accountable? > > If they just offer a transport service, I see no reason I should. > Vice-versa, if they are accountable, then _they_ are the true MTA, > transmitting on behalf of what I called a vanity domain. (This > distinction does not have to be static, as example.ORG may send > directly in some cases, via example.com in others.) Those offering the service should still be assessed upon their stewardship of who is allowed to send messages. When they fail to remove problematic access to their Outbound MTAs, those MTA might become blocked, and their customers will then need to seek service elsewhere. When a MAIL command or PRA domains are blocked for because authorization has been confused with authentication or when spam is spoofing the domain, those affected are left without recourse. Not wanting to track dramatically fewer EHLO host names with that of a small number of IP addresses is poor justification for a potentially injurious practice making guesses about MAIL commands or PRA domains. :^( >> You have no assurance whether third-party domains originated the >> message, even when the domain offers authorization. This assumes >> Outbound MTAs ensure both the PRA and MAIL commands are restricted >> to specific and verified users. While this might be the case, this >> is not the norm. > > OTOH, if we cannot spot whether an MSA has been used, the advantages > of clean transmission remain confined within the first hop. An MTA > who accepted to relay on behalf of an authenticated user may be > willing to take accountability. The point is that it has no verb to > express that will. IMHO, systems used within private or authenticated exchanges is of no concern. It is only the Outbound MTA sending messages to different domains on port 25 without authentication that needs management. Guesses about what might have occurred ahead of the Outbound MTA can be injurious to otherwise innocent domains. >> It would also be foolish to annotate email as having been >> "authenticated" on the basis of Outbound MTA authorization for the >> same reason. Large companies place a higher priority on their >> messages being received than ensuring authorizations do not expose >> exploits to bad actors. > > If they take accountability, then it's their problem. Their vouchers > should take that behavior into account. Vouchers? Taking accountability? Logically extending that concept should then involve significant liabilities for providers that fail to ensure MAIL commands or PRAs are limited to their rightful owners. What RFCs should these providers be following? How does one determine who is the rightful owner, and have you ever seen such agreements, and do you know which standards need to be followed? Is this assurance expressed within your SLA with your provider? Does this agreement specify exclusivity for use of MAIL commands or does it also include PRAs? You are describing a fantasy that may cause injury when believed. We need to hold parachute manufactures liable for their product, and not those using parachutes. >>> However, there is no way I can tell that is indeed the case, >>> neither from the IP address nor from the name. I'd need, say, a >>> CSA SRV record from example.ORG saying: "we authorize >>> mta.example.com", _and_ on starting a new session the client shall >>> say: "Hello on behalf of example.ORG: check their CSA settings". >>> No guessing required, then. >> Yes, the CSA record would help, but this EHLO information still >> offers value. Especially when considering the use of IPv6 where >> block lists are unlikely to prove effective. > > I agree EHLO information has some value. In some cases, it may be > redundant (e.g. if there is a vouch, or in case of ideal DNS > settings.) In most cases, it is not enough, as it doesn't lead to an > accountable administrator's name, address, phone number, etc. It only needs to lead to an identifier that can be fairly and safely blocked while mitigating email abuse. >> The issue is simpler than that. The issue is to simply hold the >> Outbound MTA accountable for the message sources for whom it grants >> access. DKIM offers a reliable means to verify where a message >> originated without impractical and unscalable efforts aimed at >> registering all authorized paths for MAIL commands or PRAs. > > Both Outbound MTAs and DKIM offer no hint about a message's > Originator and related accountability issues. The task of holding individuals accountable needs to be delegated to the Outbound MTA providers. After all, these providers are being compensated, and not their recipients. Expecting recipients to make guesses about who the originators were overlooks the reality that Outbound MTA provider granting access are the _only_ entities able to make this determination. When they haven't or can't, they should be blocked when abuse is being emitted. > For counting, note that the number of DKIM signers potentially > exceeds the number of valid RHS domain names, since each mail domain > can be a DKIM signer, but a DKIM signer doesn't have to be a mail > domain. DKIM is to prevent spoofing. DKIM is not intended to serve as a means to mitigate email abuse. >> DNS CIDR notation is specified by RFC 3123. This resource record >> can still be used to establish email white-list strategies instead >> of SPF records. APL records exclude potentially problematic >> macros as well. Since email CIDR records should not be obtained in >> response to SMTP connections, APL might be chained with a >> convention for _n._smtp APL, as an alternative publishing location >> for _smtp APL. When _smtp is truncated, either TCP fallback could >> be used, or _[0-9]._smtp APL queries might be used to recover from >> response truncation. > > However well designed, such scheme will thickens the ranks of mail > transmitter authentication schemes. All of them are optional, and > checking which one may apply requires an increasing amount of DNS > transactions, possibly amplified by DNSSEC. That's why VHLO, besides > taking the mail domain of the accountable organization, can also > take the parameters indicating which authentication method applies. This alternative for white-listing was mentioned only to suggest safer methods that don't rely upon potentially hazardous scripts. -Doug From mouse@Sparkle.Rodents-Montreal.ORG Fri Jul 3 13:57:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673FF3A6CD2 for ; Fri, 3 Jul 2009 13:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9zAODBKgmHk for ; Fri, 3 Jul 2009 13:57:53 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 5F4F53A6E2D for ; Fri, 3 Jul 2009 13:57:52 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA01431; Fri, 3 Jul 2009 16:57:49 -0400 (EDT) From: der Mouse Message-Id: <200907032057.QAA01431@Sparkle.Rodents-Montreal.ORG> 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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 3 Jul 2009 16:44:17 -0400 (EDT) To: asrg@irtf.org Subject: [Asrg] Something I noticed... X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 20:57:54 -0000 To get back to the research we are supposeldy doing here.... I recently noticed something odd. It could be nothing but a quirk of my mail stream, or it could be something serious spamwatchers know all about but I've missed - but it also might possibly be useful somehow. My mailer does DNSBL checks. One of them, probably the most useful single one, is the Spamhaus Zen list. But I noticed Zen-listed hosts had a tendency to hammer on me despite 100% rejections (not surprising in view of how much spammers, especially botnet-uysing spammers, pay attention to things like SMTP response codes, ie, not at all). So I added a decoration: when a Zen-listed host tries to send me mail, it goes into a router-based blacklist between my SMTP server and the world, for 24 hours (longer if it retries during the 24 hours). This helps keep my logs clean, and that's the major value it holds for me; I'm not under any delusions that anyone is paying any attention. :) But, recently, looking at the plots of my router blacklist size, I noticed some interesting artifacts. On investigating, it turns out that every once in a while (every few days), rather than puttering along at its usual pace of a half-dozen events an hour, the Zen-driven blacklist takes a big spike, jumping by something like 50 or 60 within a couple of minutes. I have speculation about what's behind this, but I'm sure many of you do too (probably the same speculation in a lot of cases). What I'm really writing here for is, anyone have any idea for anything useful I can do with the information? I'll be happy to provide anyone who wants with a feed of the underlying data, though I daresay those serious about this stuff already have such data of their own. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Sat Jul 4 04:26:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED703A6916 for ; Sat, 4 Jul 2009 04:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtobJsG3FYQ5 for ; Sat, 4 Jul 2009 04:26:34 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B0D1F3A690E for ; Sat, 4 Jul 2009 04:26:34 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 04 Jul 2009 13:26:54 +0200 id 00000000005DC031.000000004A4F3C7E.00004984 Message-ID: <4A4F3C7D.9090808@tana.it> Date: Sat, 04 Jul 2009 13:26:53 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Levine References: <20090704093321.48002.qmail@simone.iecc.com> In-Reply-To: <20090704093321.48002.qmail@simone.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] defining the ASRG (was Re: draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 11:26:36 -0000 John Levine wrote: >>The opposite resolution, to grant write access to the wiki to whoever >>posts one message, might also increase research in the above sense. > > OK, I made you an account, login vesely, temporary password ****** Thanks! I've added an "Accountability" section in http://wiki.asrg.sp.am/wiki/Path_validation#Accountability trying to summarize recent discussion. From vesely@tana.it Sat Jul 4 05:08:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5EA3A65A6 for ; Sat, 4 Jul 2009 05:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXERGT7duSuV for ; Sat, 4 Jul 2009 05:08:20 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 59EF63A6359 for ; Sat, 4 Jul 2009 05:08:20 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 04 Jul 2009 14:08:40 +0200 id 00000000005DC02F.000000004A4F4648.00004F30 Message-ID: <4A4F4648.8060308@tana.it> Date: Sat, 04 Jul 2009 14:08:40 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] Visual version of VHLO X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 12:08:21 -0000 This diagram conveys the idea more quickly than reading the I-D: http://www.circleid.com/posts/turn_the_table_on_content_filtering/ From asrg3@billmail.scconsult.com Sat Jul 4 09:05:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB053A69B7 for ; Sat, 4 Jul 2009 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+GERh4EmLjo for ; Sat, 4 Jul 2009 09:05:34 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 114883A6959 for ; Sat, 4 Jul 2009 09:05:33 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id CCA758E5A1F for ; Sat, 4 Jul 2009 12:05:35 -0400 (EDT) Message-ID: <4A4F7DD0.4040404@billmail.scconsult.com> Date: Sat, 04 Jul 2009 12:05:36 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> In-Reply-To: <4A43618A.6000205@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 16:05:35 -0000 Alessandro Vesely wrote, On 6/25/09 7:37 AM: > For example, assume someone trusts Gmail's egress filtering I'll play along. It is certainly possible that for some recipients, the stream of mail from Google's sewer is cleaner than what I see... > and wants to > skip content filtering for mail coming from there. What work is required > to accomplish (and maintain) that task, on typical MTA software? I'm going to assume you don't mind an answer based on a common add-on to common MTA software: SpamAssassin hooked into Sendmail or Postfix via one of the multiple 'milter' packages that will do that. SA can be hooked into other MTA's as well and is a component in some commercially packaged spam-filtering appliances, so I think it is reasonable to consider it "typical" even it is technically is not an integral part of any MTA. This is a situation where SPF is a useful tool. If I want to make sure that SpamAssassin never deems mail from a *@gmail.com address to be spam as long as it gets an affirmative SPF match (i.e. is coming from what Google says are its normal gmail.com outbounds) I would just add this to my local SpamAssassin config: whitelist_from_spf *@gmail.com SPF can handle well the problem of whitelisting the normal outbound paths for a complex mail system that isn't persistently congruent with a set of hosts whose FQDN's share a domain tail or a small number of networks with clean octet boundaries (e.g. a small number of /24 ranges). Most major MTA's can directly define trusted networks based on octet or CIDR notation and trusted domains based on verified client hostnames patterns, so in many cases of simpler sending systems whitelisting does not require SpamAssassin or other SPF-based mechanisms. For complex senders who have complex and dynamic outbound environments, refuse to publish SPF records, but do use DKIM (e.g. Yahoo) there is probably some way to use DKIM as the authentication that a message is coming from a system that you trust. I can't say how easy or hard that would be, since I've never seen enough marginal value in DKIM to bother with it. From peter@denic.de Sun Jul 5 06:56:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D4A3A6BC2 for ; Sun, 5 Jul 2009 06:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ+MTFUkwYoo for ; Sun, 5 Jul 2009 06:56:20 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 1A8DB3A682F for ; Sun, 5 Jul 2009 06:56:19 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MNSCx-0001Fa-Cv; Sun, 05 Jul 2009 15:56:43 +0200 Received: from localhost by x27.adm.denic.de with local id 1MNSCu-0006G5-9X; Sun, 05 Jul 2009 15:56:40 +0200 Date: Sun, 5 Jul 2009 15:56:40 +0200 From: Peter Koch To: Anti-Spam Research Group - IRTF Message-ID: <20090705135640.GA23558@x27.adm.denic.de> Mail-Followup-To: Anti-Spam Research Group - IRTF References: <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <4A4CCC56.8090804@tana.it> <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 13:56:21 -0000 Doug, On Thu, Jul 02, 2009 at 12:43:53PM -0700, Douglas Otis wrote: > When the EHLO host name references IP addresses that match the > Outbound MTA, this verifies there is a common administration between > the FQDN and DNS. the DNS namespace is of very little help when it comes to conclusions about "common administration". See, for example, RFC 5507, section 4: DNS hierarchy neither follows nor implies administrative hierarchy. Because of that, it cannot be assumed that data attached to a node in the DNS tree is valid for the whole subtree. [...] Since I'm sure you were already aware of this, I'm wondering in what way I might have misread your statement. -Peter From vesely@tana.it Mon Jul 6 03:34:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370E328C275 for ; Mon, 6 Jul 2009 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=2.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05VxgqFxoYrl for ; Mon, 6 Jul 2009 03:34:47 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 30E0028C1E6 for ; Mon, 6 Jul 2009 03:34:47 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 06 Jul 2009 12:35:10 +0200 id 00000000005DC031.000000004A51D35E.00005A09 Message-ID: <4A51D35E.70306@tana.it> Date: Mon, 06 Jul 2009 12:35:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: asrg@irtf.org References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> In-Reply-To: <4A4F7DD0.4040404@billmail.scconsult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:34:48 -0000 Bill Cole wrote: >> For example, assume someone trusts Gmail's egress filtering > > I'll play along. It is certainly possible that for some recipients, the > stream of mail from Google's sewer is cleaner than what I see... Upthread, you also wrote that they "have shunned the entire notion of accountability". What do you see? Of course, one cannot compare one of those freemail providers with a private mail domain, operated by skilled staff, where new accounts are added wittingly, used by an elite of cautious people who rarely catch viruses, if ever. In the latter case, you don't have to resort to statistics to measure the quality of messages. The big four, much like connection providers' default mailers, have to operate some kind of surveillance on what their users send. I wonder if they have specific conventions or settings to relay mail from one to another, since that probably accounts for a large chunk of their traffic. >> skip content filtering for mail coming from there. What work is required >> to accomplish (and maintain) that task, on typical MTA software? > > This is a situation where SPF is a useful tool. If I want to make sure > that SpamAssassin never deems mail from a *@gmail.com address to be spam > as long as it gets an affirmative SPF match (i.e. is coming from what > Google says are its normal gmail.com outbounds) I would just add this to > my local SpamAssassin config: > > whitelist_from_spf *@gmail.com That kinds of setting cleverly enable whitelisting by domain. However, compared to the VPN paradigm, that setting is unilateral. At Gmail, they don't now they're whitelisted. > For complex senders who have complex and dynamic outbound > environments, refuse to publish SPF records, but do use DKIM (e.g. > Yahoo) there is probably some way to use DKIM as the authentication that > a message is coming from a system that you trust. I can't say how easy > or hard that would be, since I've never seen enough marginal value in > DKIM to bother with it. Browsing docs[1], it seems that whitelist_from_dkim *@yahoo.com should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one of the three types of whitelist from authentication (whitelist_auth) that SA does. So, if a sender knows that you filter with SA, they may try all of them in turn, blindly. [1 http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_DKIM.html] From dotis@mail-abuse.org Mon Jul 6 12:08:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C6E28C417 for ; Mon, 6 Jul 2009 12:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4imNsQsZZdA for ; Mon, 6 Jul 2009 12:08:23 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 5896A28C429 for ; Mon, 6 Jul 2009 12:08:00 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 89A88A944A8 for ; Mon, 6 Jul 2009 19:00:24 +0000 (UTC) Message-Id: <989960B2-4D25-4F88-8892-0567CF9C18B8@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <20090705135640.GA23558@x27.adm.denic.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 12:00:24 -0700 References: <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> <4A4CCC56.8090804@tana.it> <6C4133DD-CAD2-4FE3-8087-9301B46832F6@mail-abuse.org> <20090705135640.GA23558@x27.adm.denic.de> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:08:24 -0000 On Jul 5, 2009, at 6:56 AM, Peter Koch wrote: > Doug, > > On Thu, Jul 02, 2009 at 12:43:53PM -0700, Douglas Otis wrote: > >> When the EHLO host name references IP addresses that match the >> Outbound MTA, this verifies there is a common administration >> between the FQDN and DNS. > > the DNS namespace is of very little help when it comes to > conclusions about "common administration". See, for example, RFC > 5507, section 4: > > DNS hierarchy neither follows nor implies administrative > hierarchy. Because of that, it cannot be assumed that data > attached to a node in the DNS tree is valid for the whole subtree. > [...] > > Since I'm sure you were already aware of this, I'm wondering in what > way I might have misread your statement. It would appear so. Confirming a host name matches its published IP addresses does not extend either up or down the administrative name tree hierarchy. Address records would be at a specific host name where a relationship with the host name and published address records is being confirmed. The CVS/CSA records authorize _specific_ outbound SMTP servers by its EHLO host name and IP address . (As a transition scheme, a parent domains might assert child domain use of CSA records. Even so, CSA records are required for each specific host name.) This is not whether the host name of "email.sfo.example.com" is within the same administrative control as that of "jon.doe@example.com" email address. Accountability is assigned to a specific outbound MTA host regardless of the MAIL and PRA domains issued. Just as it would be wrong, based upon name alone, to extend administrative domain hierarchy, Outbound MTA authorization referenced from email-address domains will not confirm the originating domain. As such, it would be wrong to assert origination or administrative accountably against higher level domains _or_ authorizing domains for abuse that might not have be within their administrative control. Fairness and equity for administrative stewardship needs to be retained. CSV/CSA retrains fairness when assessing administrative stewardship. Assigning accountability based upon Outbound MTA domain SPF authorization referenced from either the MAIL command or the Purported Responsible Address (PRA) assumes the Outbound MTA has administrative control or that there are mechanisms in place protecting those offering the authorization. There are no current standards nor common SLAs that protect those offering the authorization to their email service providers. Basing acceptance upon Outbound MTA SPF authorization (referenced from MAIL commands or PRA domains) will force domains to accept accountability for actions likely beyond their administrative control. Holding these domains accountable by way of SPF reputation assessments in many cases will be unfair and provide inequitable treatment. Fairness requires those within administrative control are held accountable. -Doug From davidnicol@gmail.com Mon Jul 6 15:42:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816FF3A6DB1 for ; Mon, 6 Jul 2009 15:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLbMaDAVauzi for ; Mon, 6 Jul 2009 15:42:23 -0700 (PDT) Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.221.194]) by core3.amsl.com (Postfix) with ESMTP id B30EF3A6B3D for ; Mon, 6 Jul 2009 15:42:23 -0700 (PDT) Received: by qyk32 with SMTP id 32so1223402qyk.15 for ; Mon, 06 Jul 2009 15:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=yBzIYrhZL2IHdBl1IH6q7T8P4WVIr0x7lRcr5B9G7P0=; b=jet/TBLaJBjKeus1w6FUgT9v4LgFIpbyY/sVWGoQGA/dzKEbpcf6ut4N5VfF4zqZZr wcazCABUbGWd+uqFAEkkxZh3wMJ/IkUFHVinGgR/0MzWbowFdYx0blZIXYMZLLLAYsPp TRtYhKHLmFEwGqYorWfrjnjmMV1HDl6/8hLQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=g6lrcodr21/SyM1c8eHM47rOfrbOdI7OHPXMzDX01SmLt+Cy7M5UGz7/MXlo5r5QrL lKUmkfPvixlJEEAqvY8VNtoD6qjO7uLUms70kbv9YEsseeRnDNGfkVV16zAX+wL9XOZw BbMHX5Md0mOzl2SVjO3+d6x+/9NCPUvRYpuUE= MIME-Version: 1.0 Received: by 10.224.89.81 with SMTP id d17mr5633255qam.372.1246920133334; Mon, 06 Jul 2009 15:42:13 -0700 (PDT) In-Reply-To: <4A4B709C.2000109@tana.it> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> <20090630200150.GL57980@verdi> <4A4B709C.2000109@tana.it> From: David Nicol Date: Mon, 6 Jul 2009 17:41:53 -0500 Message-ID: <934f64a20907061541l6884126cx16755a81b8fb5510@mail.gmail.com> To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:42:24 -0000 On Wed, Jul 1, 2009 at 9:20 AM, Alessandro Vesely wrote: > much like pinching hackers on the fly is sometimes shown on the movies What, and then grab their nuts and squeeze? -- Gaming Edison's ratio by shunning air conditioning doesn't actually work. From asrg3@billmail.scconsult.com Mon Jul 6 20:39:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0558528C3D4 for ; Mon, 6 Jul 2009 20:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewLhu9fL3iKH for ; Mon, 6 Jul 2009 20:39:05 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 5ECEB28C2ED for ; Mon, 6 Jul 2009 20:39:05 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 3BEE68E840B for ; Mon, 6 Jul 2009 23:39:25 -0400 (EDT) Message-ID: <4A52C36D.6040207@billmail.scconsult.com> Date: Mon, 06 Jul 2009 23:39:25 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> In-Reply-To: <4A51D35E.70306@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 03:39:06 -0000 Alessandro Vesely wrote, On 7/6/09 6:35 AM: > Bill Cole wrote: >>> For example, assume someone trusts Gmail's egress filtering >> >> I'll play along. It is certainly possible that for some recipients, >> the stream of mail from Google's sewer is cleaner than what I see... > > Upthread, you also wrote that they "have shunned the entire notion of > accountability". What do you see? The overwhelming majority of mail I am offered by the Gmail outbounds is spam. Google has played games with how they will accept abuse reports, giving the appearance of not really wanting them. > Of course, one cannot compare one of those freemail providers with a > private mail domain, operated by skilled staff, where new accounts are > added wittingly, used by an elite of cautious people who rarely catch > viruses, if ever. In the latter case, you don't have to resort to > statistics to measure the quality of messages. > > The big four, much like connection providers' default mailers, have to > operate some kind of surveillance on what their users send. I wonder if > they have specific conventions or settings to relay mail from one to > another, since that probably accounts for a large chunk of their traffic. Large cheap and free mail providers understand the advantage they get from their scale in not needing to do as well with egress filtering as smaller mixed sources of mail. There is very little risk to them of missing 95% of their outbound spam, as long as they never drop legitimate outbound mail and keep their outbound legitimate mail volume large enough that it is hard for many sites to treat their mail as presumptive spam. >>> skip content filtering for mail coming from there. What work is required >>> to accomplish (and maintain) that task, on typical MTA software? >> >> This is a situation where SPF is a useful tool. If I want to make sure >> that SpamAssassin never deems mail from a *@gmail.com address to be >> spam as long as it gets an affirmative SPF match (i.e. is coming from >> what Google says are its normal gmail.com outbounds) I would just add >> this to my local SpamAssassin config: >> >> whitelist_from_spf *@gmail.com > > That kinds of setting cleverly enable whitelisting by domain. However, > compared to the VPN paradigm, that setting is unilateral. At Gmail, they > don't now they're whitelisted. For the vast majority of receiving sites, they have no significant reason to care. The number of receiving systems whose mail filtering policies matter to large freemail providers is small enough to be managed as a collection of bilateral relationships rather than through public open standards. In my direct experience working on middling corporate mail systems and dealing with people handling much larger cheap/free "consumer" mail systems, I had some tests of whether they cared about how we treated their mail, and saw no sign that they did. At least some don't even seem to care when fairly prominent corporations urge their smaller business partners to avoid their non-free mail service. What they care about in getting their users' mail delivered is the dozen peers to whom they send 80% of their messages and maybe the next score down in size that handle another 15%. It's not rational for them to care about systems with 10k users or less. >> For complex senders who have complex and dynamic outbound >> environments, refuse to publish SPF records, but do use DKIM (e.g. >> Yahoo) there is probably some way to use DKIM as the authentication >> that a message is coming from a system that you trust. I can't say how >> easy or hard that would be, since I've never seen enough marginal >> value in DKIM to bother with it. > > Browsing docs[1], it seems that > > whitelist_from_dkim *@yahoo.com > > should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one of > the three types of whitelist from authentication (whitelist_auth) that > SA does. So, if a sender knows that you filter with SA, they may try all > of them in turn, blindly. DK is obsolete, FWIW. Using SPF to vouch for a SMTP client IP and/or DKIM signatures to make some headers believable is valuable between the big providers because it is useful for them to have some easy basis for trusting each other that is hard to fake. Others who use those tools for domain-wide trusting of the large providers may or may not be acting rationally, depending on the sort of mail they actually see from the large providers. No mail system I've worked on in the past decade has had a mail stream from any major freemail provider that has been less than 50% spam, and that makes any means of domain-wide whitelisting for them hard to rationalize. That said, the general idea of domain-wide whitelisting is widely useful for better-run domains and while many domains for which it makes sense are simple enough to whitelist without SPF or DKIM, it does not hurt to have those tools available. Perversely, they have significantly reduced the marginal value available for any new tools that do slightly different sorts of domain-wide authentication. Put more directly: the practical value of VHLO is reduced by the fact that SPF and DKIM are widely available. From mouse@Sparkle.Rodents-Montreal.ORG Tue Jul 7 00:10:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3293A6D8C for ; Tue, 7 Jul 2009 00:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj0LJ+V7cG9T for ; Tue, 7 Jul 2009 00:10:00 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 85F093A6C44 for ; Tue, 7 Jul 2009 00:09:59 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id DAA15710; Tue, 7 Jul 2009 03:09:23 -0400 (EDT) From: der Mouse Message-Id: <200907070709.DAA15710@Sparkle.Rodents-Montreal.ORG> 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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 7 Jul 2009 03:05:56 -0400 (EDT) To: asrg@irtf.org In-Reply-To: <4A52C36D.6040207@billmail.scconsult.com> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 07:10:01 -0000 > The overwhelming majority of mail I am offered by the Gmail outbounds > is spam. Google has played games with how they will accept abuse > reports, giving the appearance of not really wanting them. Why should they care? > There is very little risk to them of missing 95% of their outbound > spam, as long as they never drop legitimate outbound mail and keep > their outbound legitimate mail volume large enough that it is hard > for many sites to treat their mail as presumptive spam. As long as their big recipients give them a free pass on their spam spewage because of the large number of human shields, I see no reason why it makes any sense for them to care about the spam they emit. Oh, and, as long as no responsibility comes with the resources they are granted authority over, of course, but that's given in today's net. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Tue Jul 7 03:28:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AD83A6E51 for ; Tue, 7 Jul 2009 03:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bzGnuC0TTft for ; Tue, 7 Jul 2009 03:28:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 05C4A3A6924 for ; Tue, 7 Jul 2009 03:28:12 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 07 Jul 2009 12:27:53 +0200 id 00000000005DC031.000000004A532329.00003103 Message-ID: <4A532344.5010509@tana.it> Date: Tue, 07 Jul 2009 12:28:20 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: asrg@irtf.org References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> In-Reply-To: <4A52C36D.6040207@billmail.scconsult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] A Vouch By Feedback proposal (was: VPNs) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:28:29 -0000 Vouch By Feedback could be a useful modification of the Vouch By Reference standard, if it didn't break its installed base. VBF adds a DNS record pointing from the vouched domain to the vouching server email address. It could be an RP RR type, where the address is meant to receive the message/feedback-report (AFR) complaints. Web is-spam buttons direct reports to the ESP, who should forward them to any sender's vouching service. Clients who implement FBLs might send them to the relevant voucher directly. Vouchers, in turn, shall forward reports to the accountable originating ESP. The latter shall ban guilty users from sending for an amount of time proportional to the number of complaints. If the voucher sees complaints against users who should have been banned from sending, it shall suspend its vouching service for the relevant sender. The second difference, the one that breaks compatibility, is that it would be more meaningful if the content of the _vouch TXT RR were a timestamp, rather than the type of message. Rehabilitated ESPs will get a new timestamp. That way, a recipient can quickly discern a long and honorable service from may-be-spammer newbies, and whitelist the former. Bill Cole wrote: > The overwhelming majority of mail I am offered by the Gmail outbounds is > spam. Google has played games with how they will accept abuse reports, > giving the appearance of not really wanting them. I keep hearing differing opinions on that. At least, it should be "benign spam", in the sense that the sender is identifiable, unlike botnets' "malign spam". Benign spam is indeed that kind of social phenomenon that some say about spam in general. It is too easy to give way to the temptation of advertising something that one believes in. Decent or better ESPs can control such phenomenon by educating or mildly punishing their users. Users who sent to honeypots after they bought an illegal Maddress CD should be punished more severely. > In my direct experience working on middling corporate mail systems and > dealing with people handling much larger cheap/free "consumer" mail > systems, I had some tests of whether they cared about how we treated > their mail, and saw no sign that they did. At least some don't even seem > to care when fairly prominent corporations urge their smaller business > partners to avoid their non-free mail service. What they care about in > getting their users' mail delivered is the dozen peers to whom they send > 80% of their messages and maybe the next score down in size that handle > another 15%. It's not rational for them to care about systems with 10k > users or less. By the same argument, middling mail system don't expect that anyone would subscribe to their FBL, even if they offered it prominently on their web sites. As I have such a tiny mail system, nobody would care to spend their time on whitelisting it, even if I could offer any required guarantees (let alone the time to look at them.) Doesn't that affect network neutrality, or even democracy, some way? We can take care of minor mail domains by automating whitelisting and FBL subscriptions. From feenberg@nber.org Tue Jul 7 05:33:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FB43A690E for ; Tue, 7 Jul 2009 05:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14FsQjkLjkUa for ; Tue, 7 Jul 2009 05:33:01 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 22E3F3A67CC for ; Tue, 7 Jul 2009 05:33:00 -0700 (PDT) Received: from nber5.nber.org (nber5.nber.org [66.251.72.75]) by mail2.nber.org (8.14.1/8.13.8) with ESMTP id n67CWB4p070775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 7 Jul 2009 08:32:12 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from nber5.nber.org (localhost [127.0.0.1]) by nber5.nber.org (8.13.7+Sun/8.13.7) with ESMTP id n67CEt9w002516; Tue, 7 Jul 2009 08:14:55 -0400 (EDT) Received: from localhost (feenberg@localhost) by nber5.nber.org (8.13.7+Sun/8.13.8/Submit) with ESMTP id n67CErZI002513; Tue, 7 Jul 2009 08:14:55 -0400 (EDT) X-Authentication-Warning: nber5.nber.org: feenberg owned process doing -bs Date: Tue, 7 Jul 2009 08:14:53 -0400 (EDT) From: Daniel Feenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <4A52C36D.6040207@billmail.scconsult.com> Message-ID: References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20090706 #2202383, check: 20090707 clean Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:33:02 -0000 On Mon, 6 Jul 2009, Bill Cole wrote: > Alessandro Vesely wrote, On 7/6/09 6:35 AM: ... > The overwhelming majority of mail I am offered by the Gmail outbounds is > spam. Google has played games with how they will accept abuse reports, giving > the appearance of not really wanting them. > Are these messages disguised in any way? Just looking at my last week's mail, there are 120 messages with "gmail.com" in the envelope-from. Two of these are spam, or about .2% of my incoming spam. Am I measuring the wrong thing? Or do different users have a different experience of spam? My account has been fairly public for over 15 years, so if an MTA were spewing a significant proportion of the worlds spam, wouldn't I be getting some? Daniel Feenberg From David.Wilson@isode.com Tue Jul 7 06:11:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226403A6E71 for ; Tue, 7 Jul 2009 06:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S32aMlduPcET for ; Tue, 7 Jul 2009 06:11:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 089DC3A6AE6 for ; Tue, 7 Jul 2009 06:11:33 -0700 (PDT) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Tue, 7 Jul 2009 14:06:11 +0100 From: David Wilson To: asrg@irtf.org In-Reply-To: <4A52C36D.6040207@billmail.scconsult.com> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> Organization: Isode Limited Date: Tue, 07 Jul 2009 14:06:10 +0100 Message-Id: <1246971970.3060.110.camel@tardis.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-transfer-encoding: quoted-printable Subject: [Asrg] gmail as source of spam (was VPN) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:11:34 -0000 On Mon, 2009-07-06 at 23:39 -0400, Bill Cole wrote: > The overwhelming majority of mail I am offered by the Gmail outbounds > is spam. Google has played games with how they will accept abuse > reports, giving the appearance of not really wanting them. This is not our experience, so I was surprised, and had a look over the last few days. We get a lot of main allegedly from 'gmail.com', but the vast majority of that is not from gmail.com hosts. As the SPF info has ?all, these get a NEUTRAL SPF status (and the sources mostly don't get past Spamhaus). Not many of the messages which get an SPF PASS from gmail.com are actual spam. And the great majority of the spam are 419 type scams, or other advance fee/financial scams. [There was one rather nice "you've won a lottery" message sent to a honeypot address which informed the recipient that they had won=20 "=A32,500,000 (2 million, 5 hundred Great British Pound Starlings)" That's a lot of rather heavy birds!] I guess that 419 scammers, unlike most spammers, want a reply to their message, so send it from an actual account used by an actual person. A couple of weeks ago, the gmail.com account of someone we deal with was hacked, and used to send spam. We saw a couple of messages, and one had several recipients, which were clearly from that user's address book. So, it was not being used for general spamming, but only to send messages to those likely to have the sender in their address book, and so avoid anti-spam measures, I presume. It is perhaps not surprising that different sites see different patterns. But we do not see the actual google outbound MTAs (as indicated by the SPF info for _spf.google.com) as a significant source of spam. best regards David From jdfalk-lists@cybernothing.org Tue Jul 7 13:13:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B543A6ED6 for ; Tue, 7 Jul 2009 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWe+15LRoqah for ; Tue, 7 Jul 2009 13:13:54 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id DF1113A6EAE for ; Tue, 7 Jul 2009 13:13:42 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n67KDED1017522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Jul 2009 14:13:16 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n67KDED1017522 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1246997596; bh=JsKPeSqOz2HAwnyWQMyTw93S4GUEHte7xnNL+FOn Rdw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JlRMjeb9UaMh cQbyQ0i22cDP8/7DbUwQb0ug3G27yZVY+Y81135m8uWZz7WqLTUc/9MJLIFSDqnzYrI TT+CSsrGPzwBAJSLSkCe7BDS6nMX+Z7zZCaI8ykadhZG3GHpUTTHnNxI1o61oO0xFN2 meC0VRgJnzB5/PAfCZePPeMTQ= Message-ID: <4A53AC55.8030801@cybernothing.org> Date: Tue, 07 Jul 2009 14:13:09 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> In-Reply-To: <4A532344.5010509@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:13:55 -0000 Alessandro Vesely wrote: > Vouch By Feedback could be a useful modification of the Vouch By > Reference standard, if it didn't break its installed base. What installed base? > VBF adds a DNS record pointing from the vouched domain to the vouching > server email address. It could be an RP RR type, where the address is > meant to receive the message/feedback-report (AFR) complaints. Web > is-spam buttons direct reports to the ESP, who should forward them to > any sender's vouching service. Clients who implement FBLs might send > them to the relevant voucher directly. Variations of this theme have been discussed dozens of times, always trying to piggyback on some other technology: SPF (which doesn't make sense), DKIM (which almost makes sense), et cetera. The problem, unfortunately, is that the use cases are unclear. I'd recommend starting by defining those cases -- not merely "I want to send complaints about spam" or "I want to receive complaints so my mail doesn't get blocked," but every possible permutation, end-to-end. It could make for an interesting research project. > Vouchers, in turn, shall forward > reports to the accountable originating ESP. The latter shall ban guilty > users from sending for an amount of time proportional to the number of > complaints. If the voucher sees complaints against users who should have > been banned from sending, it shall suspend its vouching service for the > relevant sender. Here you're getting out of the technology, and into dictating behavior. I wouldn't be surprised if the agreements between message sender, voucher, and message receiver end up looking something like what you describe, but the technology should be agnostic and let those three parties make any agreement they feel is appropriate for their individual situations. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From vesely@tana.it Wed Jul 8 00:54:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440903A6E5F for ; Wed, 8 Jul 2009 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TquQmQC2iPnf for ; Wed, 8 Jul 2009 00:54:13 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6E5FB3A6E16 for ; Wed, 8 Jul 2009 00:53:53 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 08 Jul 2009 09:54:03 +0200 id 00000000005DC036.000000004A54509C.00006034 Message-ID: <4A5450B9.1050306@tana.it> Date: Wed, 08 Jul 2009 09:54:33 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> In-Reply-To: <4A53AC55.8030801@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 07:54:14 -0000 J.D. Falk wrote: >> Vouch By Feedback could be a useful modification of the Vouch By >> Reference standard, if it didn't break its installed base. > > What installed base? For one, MDaemon mail server software uses the advanced email authentication techniques of Vouch By Reference (VBR) and validates and signs messages using DKIM, DK, Sender-ID, and SPF. http://www.mdaemon.co.nz/Products/MDaemon >> VBF adds a DNS record pointing from the vouched domain to the vouching >> server email address. It could be an RP RR type, where the address is >> meant to receive the message/feedback-report (AFR) complaints. Web >> is-spam buttons direct reports to the ESP, who should forward them to >> any sender's vouching service. Clients who implement FBLs might send >> them to the relevant voucher directly. > > Variations of this theme have been discussed dozens of times, always > trying to piggyback on some other technology: SPF (which doesn't make > sense), DKIM (which almost makes sense), et cetera. Basically, it should leverage SUBMIT. While DKIM may sign the From or Sender headers, it doesn't assure that the content of that field has been authenticated, IIRC. Actully, we need a weaker statement: that some of the signed headers has enough information for the originating server(s) to recover the authenticated identity of the submitter. That allows for anonymous sending. > The problem, unfortunately, is that the use cases are unclear. I'd > recommend starting by defining those cases -- not merely "I want to send > complaints about spam" or "I want to receive complaints so my mail > doesn't get blocked," but every possible permutation, end-to-end. Improper use of TIS buttons was discussed some months ago. "I want to ban from sending whoever mailed me this" is the new case for them. >> Vouchers, in turn, shall forward >> reports to the accountable originating ESP. The latter shall ban guilty >> users from sending for an amount of time proportional to the number of >> complaints. If the voucher sees complaints against users who should have >> been banned from sending, it shall suspend its vouching service for the >> relevant sender. > > Here you're getting out of the technology, and into dictating behavior. > I wouldn't be surprised if the agreements between message sender, > voucher, and message receiver end up looking something like what you > describe, but the technology should be agnostic and let those three > parties make any agreement they feel is appropriate for their individual > situations. Agreed. In that respect, a voucher can mandate that behavior even using the existing VBR standard. Only the destination of complaints deserves further standardization. Standard AFR is on its way, isn't it? Dictating behavior should be done by lawmakers, of course. However, they cannot write the standards, and may encounter difficulties even in identifying the items that populate cyberspace. It seems a somewhat tighter cooperation is required in order to sort out an effective anti-spam regulation. From claudio@telmon.org Wed Jul 8 01:48:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27EC3A6DDC for ; Wed, 8 Jul 2009 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H35WtnAzPCZg for ; Wed, 8 Jul 2009 01:48:12 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 927B63A69EB for ; Wed, 8 Jul 2009 01:48:11 -0700 (PDT) Received: from 88-149-251-67.dynamic.ngi.it ([::ffff:88.149.251.67]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.67+N64U65bpu5W; Wed, 08 Jul 2009 10:47:37 +0200 Message-ID: <4A545D29.2010908@telmon.org> Date: Wed, 08 Jul 2009 10:47:37 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090608 Lightning/0.8 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> In-Reply-To: <4A5450B9.1050306@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:48:12 -0000 Alessandro Vesely wrote: > J.D. Falk wrote: ... >> Here you're getting out of the technology, and into dictating >> behavior. I wouldn't be surprised if the agreements between message >> sender, voucher, and message receiver end up looking something like >> what you describe, but the technology should be agnostic and let those >> three parties make any agreement they feel is appropriate for their >> individual situations. > > Agreed. In that respect, a voucher can mandate that behavior even using > the existing VBR standard. Only the destination of complaints deserves > further standardization. Standard AFR is on its way, isn't it? > > Dictating behavior should be done by lawmakers, of course. However, they > cannot write the standards, and may encounter difficulties even in > identifying the items that populate cyberspace. It seems a somewhat > tighter cooperation is required in order to sort out an effective > anti-spam regulation. I think this is a point that needs clarification, but maybe this has already been discussed in some previous thread. Many of the protocols proposed here seem to provide accountability. Accountability is not, per se, an antispam solution. Accountability + some e.g. banning enforcement mechanism can be. Unless enforcement is an automatic and trivial consequence of the protocol, I think that it is appropriate to discuss how it can be achieved and realistic. Otherwise, we could end up with completely useless protocols. I would dare to say that if enforcement were trivial, we wouldn't have botnets, which are already illegal. So I think it was appropriate for Alessandro to describe at least one way the accountability can be used for enforcement, and thus as antispam, since it makes a lot of difference if enforcement is expected to be between ESP and ESP, between an ESP and its customers, between law enforcement agencies and ESPs, or between law enforcement agencies and the citizens. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From mouse@Sparkle.Rodents-Montreal.ORG Wed Jul 8 07:24:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6753A69CA for ; Wed, 8 Jul 2009 07:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.56 X-Spam-Level: X-Spam-Status: No, score=-9.56 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y70w7Nq0kWMT for ; Wed, 8 Jul 2009 07:24:12 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 115DD3A68DE for ; Wed, 8 Jul 2009 07:24:01 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA06850; Wed, 8 Jul 2009 10:23:35 -0400 (EDT) From: der Mouse Message-Id: <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> 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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 8 Jul 2009 10:21:44 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A545D29.2010908@telmon.org> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> <4A545D29.2010908@telmon.org> Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:24:13 -0000 > Accountability is not, per se, an antispam solution. Accountability > + some e.g. banning enforcement mechanism can be. It's not really accountability unless there's an enforcement mechanism, some kind of calling to account. (Calling identifiability "accountability" does not make it that.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From rsk@gsp.org Wed Jul 8 08:09:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24763A6B72 for ; Wed, 8 Jul 2009 08:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60DcHTN3zayT for ; Wed, 8 Jul 2009 08:09:14 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 011EB28C102 for ; Wed, 8 Jul 2009 08:08:53 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.37.dsl.charm.net [207.114.17.37]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n68EHqEd020809 for ; Wed, 8 Jul 2009 10:17:53 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n68ECUdX025145 for ; Wed, 8 Jul 2009 10:12:30 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n68EHlSs003332 for ; Wed, 8 Jul 2009 10:17:47 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n68EHl42003329 for asrg@irtf.org; Wed, 8 Jul 2009 10:17:47 -0400 Date: Wed, 8 Jul 2009 10:17:47 -0400 From: Rich Kulawiec To: asrg@irtf.org Message-ID: <20090708141747.GA2822@gsp.org> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A52C36D.6040207@billmail.scconsult.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:09:14 -0000 On Mon, Jul 06, 2009 at 11:39:25PM -0400, Bill Cole wrote: > The overwhelming majority of mail I am offered by the Gmail outbounds is > spam. Google has played games with how they will accept abuse reports, > giving the appearance of not really wanting them. Fully agreed. > Large cheap and free mail providers understand the advantage they get > from their scale in not needing to do as well with egress filtering as > smaller mixed sources of mail. There is very little risk to them of > missing 95% of their outbound spam, as long as they never drop legitimate > outbound mail and keep their outbound legitimate mail volume large enough > that it is hard for many sites to treat their mail as presumptive spam. And this in a nutshell is why so many "accountability" proposals, while curious/interesting academic exercises, are dead-on-arrival in the real world: these providers are TBTB (too big to block), they know it, and so no matter how many different technologies are deployed which repeatedly tell us what we've already known for years (e.g. "Hotmail sends enormous quantities of spam") nothing useful will happen as a result -- until/unless widespread refusal of traffic comes into play. ---Rsk From asrg3@billmail.scconsult.com Wed Jul 8 08:20:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC803A68DE for ; Wed, 8 Jul 2009 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaGq90Aw82aW for ; Wed, 8 Jul 2009 08:20:34 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 0B11328C124 for ; Wed, 8 Jul 2009 08:20:14 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 383838E9BD0 for ; Wed, 8 Jul 2009 11:20:31 -0400 (EDT) Message-ID: <4A54B941.20808@billmail.scconsult.com> Date: Wed, 08 Jul 2009 11:20:33 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:20:35 -0000 Daniel Feenberg wrote, On 7/7/09 8:14 AM: > > > On Mon, 6 Jul 2009, Bill Cole wrote: > >> Alessandro Vesely wrote, On 7/6/09 6:35 AM: > ... >> The overwhelming majority of mail I am offered by the Gmail outbounds >> is spam. Google has played games with how they will accept abuse >> reports, giving the appearance of not really wanting them. >> > > Are these messages disguised in any way? What do you mean by "any way?" I do not retain most of them beyond the end of the SMTP session in which they are rejected, so I cannot speak to most of their headers. Most have gmail.com in the envelope-from, but some do not. > Just looking at my last week's > mail, there are 120 messages with "gmail.com" in the envelope-from. Two > of these are spam, or about .2% of my incoming spam. Am I measuring the > wrong thing? Yes and no. Note that I didn't say that I get much *volume* from the GMail outbounds, nor that they are the source of a large fraction of the spam that my server is offered, nor that all of the mail I was referring to was aimed at me personally or even to any address that has ever been valid. However, a quick look at the spam that has made it to the point of delivery to my main account on that server tells me that about 20% of it is coming in via the 209.85.128/17 and 74.125/16 machines that match the SPF record for gmail.com. That's only a message or two per week: about half of what is offered by those clients for all valid addresses on that system and about a third of what they offer in total. In the past 40 days, the legitimate mail count for that system from Gmail is exactly 1, but that's artificially high because that one was a test message I sent to myself today to make sure that I was not missing valid messages in my log searches. > Or do different users have a different experience of spam? Is that a serious question? Assuming that it is: yes. The spam experience of different users is not only non-uniform, it is not normally distributed across operationally useful populations like domains or receiving systems. Different users get very different volumes and different distinct types. The addresses that are targeted by huge volumes of completely fraudulent spam from easily-shunned botnets often get little or no spam from the 'snowshoe' spammers who like to claim CAN-SPAM compliance and may be advertising a product that some people willingly buy, and the 419'ers who like to use freemail accounts may hit a completely different set of users. > My account has been fairly public for over 15 years, so if an MTA were > spewing a significant proportion of the worlds spam, wouldn't I be > getting some? I don't believe I said that Google's MTA's were spewing a significant proportion of the world's spam. Unless you consider the various spamming botnets as single entities across all of their nodes, no single entity is the source of a significant proportion of the world's spam. What I did say (based on my own mailbox, my own small mail system with less than a dozen users, and some non-ISP, non-academic mail systems with a few score to a few thousand accounts) is that most of what Google's outbounds offer *to the sorts of systems I work with* is spam. That does not make them special among freemail providers, but freemail providers are an unusual species of SMTP client: continuously mixed ham/spam, majority spam, high total volume, and mixed spam and ham types (many of which are also seen from other types of clients.) This makes them part of the heavy lifting of spam control for receivers. From john@jlc.net Wed Jul 8 08:57:07 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124D13A69B8 for ; Wed, 8 Jul 2009 08:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu6IdlcDa6sx for ; Wed, 8 Jul 2009 08:57:02 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5AA403A6AAA for ; Wed, 8 Jul 2009 08:57:02 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 998C833C26; Wed, 8 Jul 2009 11:57:04 -0400 (EDT) Date: Wed, 8 Jul 2009 11:57:04 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090708155704.GN15652@verdi> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090708141747.GA2822@gsp.org> User-Agent: Mutt/1.4.1i Subject: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:57:07 -0000 Rich Kulawiec wrote: > On Mon, Jul 06, 2009 at 11:39:25PM -0400, Bill Cole wrote: > >> Large cheap and free mail providers understand the advantage they get >> from their scale in not needing to do as well with egress filtering as >> smaller mixed sources of mail. There is very little risk to them of >> missing 95% of their outbound spam, as long as they never drop legitimate >> outbound mail and keep their outbound legitimate mail volume large enough >> that it is hard for many sites to treat their mail as presumptive spam. This is true, but still there is in practice a _large_ variation in percentage of spam spewed by the "large" email providers. > And this in a nutshell is why so many "accountability" proposals, > while curious/interesting academic exercises, are dead-on-arrival in > the real world: these providers are TBTB (too big to block), "Blocking" the whole "domain" is not the only trick in our bag... > they know it, and so no matter how many different technologies are > deployed which repeatedly tell us what we've already known for years > (e.g. "Hotmail sends enormous quantities of spam") nothing useful will > happen as a result -- until/unless widespread refusal of traffic comes > into play. "Hotmail sends enormous quantities of spam" isn't a very useful factlet. Nonetheless, it does allow some email receivers to at least graylist some Hotmail servers if the envelope-from isn't on a whitelist. More useful is something like, "Hotmail MTA #49 is sending more spam than usual right now: more severe graylisting might be called for." Or, your reputation service might say, "We're concentrating our pressure on Hotmail MTA #49 right now: please give it a hard time." The introduction of reputation services creates options for getting the attention of the folks who maintain the MTAs of the large email services. If we insist on a world without reputation services (or ePostage), Rich is correct that only "large" email receivers will be able to make a dent in the practices of "large" email senders. :^( -- John Leslie From CLEWIS@nortel.com Wed Jul 8 11:25:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2683A6868 for ; Wed, 8 Jul 2009 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReR7yQhcPl3Y for ; Wed, 8 Jul 2009 11:25:18 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6E6823A6882 for ; Wed, 8 Jul 2009 11:25:15 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n68IO2S02513 for ; Wed, 8 Jul 2009 18:24:02 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:25:38 -0400 Received: from [47.130.64.150] (47.130.64.150) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 8 Jul 2009 14:25:37 -0400 Message-ID: <4A54E4A0.30309@nortel.com> Date: Wed, 8 Jul 2009 14:25:36 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> In-Reply-To: <20090708155704.GN15652@verdi> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 18:25:38.0538 (UTC) FILETIME=[7E29D4A0:01C9FFF9] Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:25:19 -0000 John Leslie wrote: > More useful is something like, "Hotmail MTA #49 is sending more spam > than usual right now: more severe graylisting might be called for." What good does graylisting do to a real MTA? Unless MTA #49 is sending you enough email that forcing it to requeue causes it problems, it won't do anything useful. We've tended to let our automated defenses "fire where they may". If MTA #49 is sending us so much spam that the defenses fire, they fire, and we don't whitelist. If the problem gets bad enough, we block /24s worth. With MSN and Yahoo, that turns out to work particularly well, because at least with Nigerian floods and their provisioning methods, specific /24s tend to be substantially worse than others. Then we make a big public & private noise. And sometimes things get better. From dotzero@gmail.com Wed Jul 8 12:20:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4BF3A6AC4 for ; Wed, 8 Jul 2009 12:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSOcFqY5CTUz for ; Wed, 8 Jul 2009 12:20:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 8A0CE3A6A70 for ; Wed, 8 Jul 2009 12:20:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so2167416qwd.7 for ; Wed, 08 Jul 2009 12:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XPZfOnrovhMqiGlMmbbBRuE2S07A3b7mFmAqESGds6Y=; b=iki2+ZhOhDxzUoPGX3AutInYmkHPoxNqHbNWnr/ELqfA5HrT4W1CzIUZ3UczNmjUgG b19PM0skZeAXB1Y7rsRfzAYjz3Z644hjhhPow3ip+3TIAP5J755IpxIOTjWHuW8e0bZF wci7MC/JWZT7iNkllamnFNwz5kj1l6DVVXq6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V2JkH49zg6aqki2Qs8LG0RMf+qNHb/I9jD3sK1pZS56kBtCbpS9GrcJuQBJsvsbwah CTf5HOJW/aR3KlyBSNWMZsCp7DqJviNksYp3tub6Da4+b461575zPbzdfu++q1S3K59E AlEipMC/GxrhADctaCfYBB21nc7MO92fj/jbI= MIME-Version: 1.0 Received: by 10.229.84.6 with SMTP id h6mr3785548qcl.19.1247080862406; Wed, 08 Jul 2009 12:21:02 -0700 (PDT) In-Reply-To: <4A54E4A0.30309@nortel.com> References: <20090623213728.1825.qmail@simone.iecc.com> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <4A54E4A0.30309@nortel.com> Date: Wed, 8 Jul 2009 15:21:02 -0400 Message-ID: <7ae58c220907081221l64fc6278u5f97bb3ea71e922f@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 19:20:37 -0000 On Wed, Jul 8, 2009 at 2:25 PM, Chris Lewis wrote: > John Leslie wrote: > >> =A0 More useful is something like, "Hotmail MTA #49 is sending more spam >> than usual right now: more severe graylisting might be called for." > > What good does graylisting do to a real MTA? =A0Unless MTA #49 is sending= you > enough email that forcing it to requeue causes it problems, it won't do > anything useful. > > We've tended to let our automated defenses "fire where they may". =A0If M= TA > #49 is sending us so much spam that the defenses fire, they fire, and we > don't whitelist. > +1 I think whitelisting has value in forcing senders that want to reach certain receivers to engage in certain practices. I don't know that whitelisting buys (or should buy) a sender protection from their own bad practices. I will add a caveat to what Chris says. Some receivers do a really good job of tuning their automatic defenses. Others are not so careful. > If the problem gets bad enough, we block /24s worth. =A0With MSN and Yaho= o, > that turns out to work particularly well, because at least with Nigerian > floods and their provisioning methods, specific /24s tend to be > substantially worse than others. > > Then we make a big public & private noise. =A0And sometimes things get be= tter. > > Sometimes they do. I believe der mouse commented about the big ISPs not caring. I think they do but are having to deal with aggressive attacks abusing their systems. On the other hand, life isn't fair . From CLEWIS@nortel.com Wed Jul 8 14:26:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C475828C10C for ; Wed, 8 Jul 2009 14:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4E5zOYX8+7K for ; Wed, 8 Jul 2009 14:26:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D5C203A6A65 for ; Wed, 8 Jul 2009 14:26:27 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n68LQoX23954 for ; Wed, 8 Jul 2009 21:26:50 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 17:26:49 -0400 Received: from [47.130.64.150] (47.130.64.150) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 8 Jul 2009 17:26:47 -0400 Message-ID: <4A550F16.6060400@nortel.com> Date: Wed, 8 Jul 2009 17:26:46 -0400 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <4A54E4A0.30309@nortel.com> <7ae58c220907081221l64fc6278u5f97bb3ea71e922f@mail.gmail.com> In-Reply-To: <7ae58c220907081221l64fc6278u5f97bb3ea71e922f@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 21:26:49.0051 (UTC) FILETIME=[CD7E7AB0:01CA0012] Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 21:26:29 -0000 Dotzero wrote: > On Wed, Jul 8, 2009 at 2:25 PM, Chris Lewis wrote: >> Then we make a big public & private noise. And sometimes things get better. > Sometimes they do. I believe der mouse commented about the big ISPs > not caring. I think they do but are having to deal with aggressive > attacks abusing their systems. On the other hand, life isn't fair . From experience, the people working with the technology care, but they sometimes can't get management (especially upper) to take it seriously and invest/authorize effort to deal with it. This is particularly apparent with some ISPs where there are several "abusable" services under different management/business units. Some doing fine, others (especially "new" ones) being large-scale abused with _no_ effort to deal with any of it. Nortel's a good size, but yeah, we're still not big enough on our own that "just blocking them" will get noticed [+]. The trick is amplifying your apparent size. PR work. Make public noise where you'll be heard, and getting others (especially moderate voices of infrastructures as large or larger) to at least indicate that they see a significant problem too and/or have implemented/contemplated implementing similar measures. Blog postings. Media reports (got a VP to contact me once). Whatever you can pull off. I'm not so egotistical to think that it was "just me", nor that I was even the first in the campaigns where I've applied this, but most of the times I've made a serious effort along those lines, the problem _has_ gotten better. It can be a longish term effort. Sometimes months, not days. Be patient. It does work often enough to be worth persevering at. Without acting like a loon. In which case it's just a waste. [+] Well, once we were contacted by Yahoo about a /24 blocking - they do listen to their user's complaints. Then I explained why. Got a reluctant/embarrassed "I guess that's best". From iane@sussex.ac.uk Thu Jul 9 02:08:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A133A6C83 for ; Thu, 9 Jul 2009 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enyjNcyjv8M7 for ; Thu, 9 Jul 2009 02:08:22 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id D315F3A6C9A for ; Thu, 9 Jul 2009 02:08:20 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64938) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KMIC4Q-000DLZ-QG for asrg@irtf.org; Thu, 09 Jul 2009 10:10:03 +0100 Date: Thu, 09 Jul 2009 10:08:35 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> <4A545D29.2010908@telmon.org> <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> Originator-Info: login-token=Mulberry:01xup4Di9L5nMHV8xwMhA5X+uBLGKZaCkQO1U=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 09:08:23 -0000 --On 8 July 2009 10:21:44 -0400 der Mouse wrote: >> Accountability is not, per se, an antispam solution. Accountability >> + some e.g. banning enforcement mechanism can be. > > It's not really accountability unless there's an enforcement mechanism, > some kind of calling to account. (Calling identifiability > "accountability" does not make it that.) > True, but we have a variety of sanctions that we can take against spammers, if only we could identify them. Different sanctions require different types of identification, and different levels of confidence in the identification. Knowing the real email address responsible lets us: 1. Contact the owner of a compromised account, and advise them to take action. 2. Contact the account service provider. 3. Blacklist the address. 4. Bounce unwanted email back to the sender. These are all things that we currently can't do for the majority of email. Knowing for sure the owner of the email address responsible gives us access to legal sanctions from small claims courts to imprisonment. Such sanctions are available, and have been used in a variety of jurisdictions. Widespread spoofing probably means its harder to access these sanctions. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jul 9 02:29:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5273A680F for ; Thu, 9 Jul 2009 02:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oN4h+VchiWj for ; Thu, 9 Jul 2009 02:29:49 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id CFA103A6C83 for ; Thu, 9 Jul 2009 02:29:44 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52636) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KMID2H-0006VO-MX for asrg@irtf.org; Thu, 09 Jul 2009 10:30:17 +0100 Date: Thu, 09 Jul 2009 10:30:11 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <60AE6CC05FE080B010A5B4A8@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A54E4A0.30309@nortel.com> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <4A54E4A0.30309@nortel.com> Originator-Info: login-token=Mulberry:01gE/oa+mwVtDBvDzN7HXzxFve5scJxeN19bo=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 09:29:50 -0000 --On 8 July 2009 14:25:36 -0400 Chris Lewis wrote: > John Leslie wrote: > >> More useful is something like, "Hotmail MTA #49 is sending more spam >> than usual right now: more severe graylisting might be called for." > > What good does graylisting do to a real MTA? Unless MTA #49 is sending > you enough email that forcing it to requeue causes it problems, it won't > do anything useful. It represents a cost to the provider for being sloppy about their account management. And, a cost to their users for sticking with an irresponsible provider. It's hard to tell your own users, "we don't accept mail from Hotmail because some of it's spam", but you might get away with "email from Hotmail often takes an hour or two because we need to check that its not spam". And you could, in principle, quarantine a copy of the message during the greylist interval (eg, using Exim's "fakedefer" facility). That message could be compared with others, to give more accurate content based spam scores. You might want to lower your spam threshold if you see several copies to distinct recipients, or even from distinct senders. Or, it could be manually inspected and then rejected next time it is seen. I'd like to have some kind of GUI tool that allowed me to see copies of greylisted messages in quarantine, so I could flag them up for rejection later. In fact, you could even give such a tool to a user - perhaps putting it behind a "this is spam" button! Finally, if the provider is using SPF or DKIM, and you have a match, then you can safely blacklist the sender if you're certain they're spamming. That's the beauty of reliable identification mechanisms - it lets me blacklist sender addresses in the knowledge that I've got the right address. > We've tended to let our automated defenses "fire where they may". If MTA > #49 is sending us so much spam that the defenses fire, they fire, and we > don't whitelist. > > If the problem gets bad enough, we block /24s worth. With MSN and Yahoo, > that turns out to work particularly well, because at least with Nigerian > floods and their provisioning methods, specific /24s tend to be > substantially worse than others. > > Then we make a big public & private noise. And sometimes things get > better. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From rsk@gsp.org Thu Jul 9 04:48:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040FA3A6AD3 for ; Thu, 9 Jul 2009 04:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXs+sdvU4dKK for ; Thu, 9 Jul 2009 04:48:33 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 1391A3A699E for ; Thu, 9 Jul 2009 04:48:32 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.37.dsl.charm.net [207.114.17.37]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n69Bmv2E011864 for ; Thu, 9 Jul 2009 07:48:58 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n69BhW6Y008314 for ; Thu, 9 Jul 2009 07:43:32 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n69BmpTW027102 for ; Thu, 9 Jul 2009 07:48:51 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n69Bmpaw027101 for asrg@irtf.org; Thu, 9 Jul 2009 07:48:51 -0400 Date: Thu, 9 Jul 2009 07:48:51 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090709114851.GB26436@gsp.org> References: <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> <4A545D29.2010908@telmon.org> <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:48:34 -0000 On Thu, Jul 09, 2009 at 10:08:35AM +0100, Ian Eiloart wrote: > Knowing the real email address responsible lets us: > > 1. Contact the owner of a compromised account, and advise them to take > action. If the account's compromised, then the new owner may not permit the former owner to see those communications. Or The former owner is unlikely to believe such reports or take any meaningful action. For example, they may just abandon the compromised account, and open a new one...which will shortly be compromised in the same way. Or The former owner will classify these reports as spam/phishes. Relying on the same end-users who have created the problem to solve it is a 100% pre-failed strategy. > 2. Contact the account service provider. If you can manage to jump through the hoops they've put in place, sure. But automated reporting will misfire, manual reporting doesn't scale, and many account service providers simply don't care. They don't have to: there are few, if any, meaningful consequences to apathy, and as long as they're profitable, few of them care about their responsibilities to the 'net. > 3. Blacklist the address. (I'm presuming you mean email address, not IP address.) Yes, but given that there is an inexhaustible supply of those, this will block the spam that's not coming any more from yesterday's compromised account and do nothing to block the spam that's coming tomorrow from the next compromised account. This is also a 100% pre-failed strategy. (Now, if you're talking about IP address, sure: we have very effective blacklist mechanisms for doing that.) > 4. Bounce unwanted email back to the sender. Unwanted mail should always be rejected, never bounced. Doing the latter not only generates useless traffic but is pretty likely to generate outscatter/backscatter, which is spam. And even if it's correctly delivered, it will do absolutely no good -- see above. ---Rsk Do NOT send me off-list copies of on-list replies: it's rude and wasteful. From rsk@gsp.org Thu Jul 9 05:02:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF9828C1E4 for ; Thu, 9 Jul 2009 05:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWlZ2w0gI52A for ; Thu, 9 Jul 2009 05:02:44 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id BA8CA28C1A3 for ; Thu, 9 Jul 2009 05:02:44 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.37.dsl.charm.net [207.114.17.37]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n69C3BRZ013251 for ; Thu, 9 Jul 2009 08:03:12 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n69BvjVj007649 for ; Thu, 9 Jul 2009 07:57:46 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n69C35Pp027814 for ; Thu, 9 Jul 2009 08:03:05 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n69C35Sd027813 for asrg@irtf.org; Thu, 9 Jul 2009 08:03:05 -0400 Date: Thu, 9 Jul 2009 08:03:05 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090709120305.GC26436@gsp.org> References: <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090708155704.GN15652@verdi> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:02:45 -0000 On Wed, Jul 08, 2009 at 11:57:04AM -0400, John Leslie wrote: > "Hotmail sends enormous quantities of spam" isn't a very useful > factlet. It wasn't intended to be: it's just common knowledge, not a quantitative assessment, and I needed a handy example. > The introduction of reputation services creates options for getting > the attention of the folks who maintain the MTAs of the large email > services. We already have blacklists, which when appropriately used, do that without the need for more elaborate mechanisms. The trick is in the word "appropriate", which has little to do with the criteria used for listing and a lot to do with who uses them and how. > If we insist on a world without reputation services (or ePostage), > Rich is correct that only "large" email receivers will be able to make a > dent in the practices of "large" email senders. Epostage is dead-on-arrival for a number of reasons, including "a hundred million zombies". And any "reputation services", no matter how elaborately constructed, will not make any difference unless they're used "appropriately", in the same way that blacklists are/could be. In other words: we do not need any new mechanisms. We do not need reputation services, or vouching services, or any of the other interesting ideas that have been put forth. We need to use the mechanisms we already have, and have had for some time. The days when we could expect network and system administrators to care about the abuse emanating from their operations because it was clearly their highest responsibility and ethical obligation have been gone for a long time. (Some still do, of course -- and good for them.) The priority now is profit, profit, profit, and thus it is necessary to speak to them in a language they understand. (That is: we need to revoke some of their privileges and thus provide them motivation to do what they're not doing.) We've spent the last 15 years sidestepping that, and we're still doing so. What it comes down to, no matter what the mechanism, is "are you willing to refuse privileges to X even though there may be consequences from your own user community?". If "yes", and if there are a sufficient number of others who feel the same, then it may be possible to affect X's behavior. If "no", then there's no reason for X to expend the time and money required to address the issue. And in the case of some egregious spam sources (e.g. Hotmail), the answer given by many of us is "no" because they're TBTB: the outcry from local users would be too great. I'm certain Hotmail is well aware of this. They know full well they're spewing, and they know equally well that they can get away with it. I'm equally certain they're not the only ones who've made this calculation. Yes, every now and then there's a happy exception: the work that Carl et.al. did at AOL comes to mind immediately. But they *are* exceptions, and they're nearly lost in the deluge. ---Rsk Do NOT send me off-list copies of on-list replies: it's rude and wasteful. From iane@sussex.ac.uk Thu Jul 9 07:36:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB373A6C41 for ; Thu, 9 Jul 2009 07:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFWd5ZovuoPG for ; Thu, 9 Jul 2009 07:36:56 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 93C3D3A683A for ; Thu, 9 Jul 2009 07:36:55 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49896) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KMIRAB-000CHN-QG for asrg@irtf.org; Thu, 09 Jul 2009 15:37:24 +0100 Date: Thu, 09 Jul 2009 15:37:12 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <36B0EA72B852DDA692165C9D@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090709114851.GB26436@gsp.org> References: <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> <4A545D29.2010908@telmon.org> <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> <20090709114851.GB26436@gsp.org> Originator-Info: login-token=Mulberry:01nJi7kQX5KfbdBQ/zCL4PDS4EAhDc6/++EQM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] A Vouch By Feedback proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:36:57 -0000 --On 9 July 2009 07:48:51 -0400 Rich Kulawiec wrote: > On Thu, Jul 09, 2009 at 10:08:35AM +0100, Ian Eiloart wrote: >> Knowing the real email address responsible lets us: >> >> 1. Contact the owner of a compromised account, and advise them to take >> action. Granted, all the following may be true, but we're still better off than the current situation where we have no clue who has sent most emails. > If the account's compromised, then the new owner may not permit > the former owner to see those communications. Well, that's a sure way of getting the attention of the account owner. > Or > > The former owner is unlikely to believe such reports or take any > meaningful action. For example, they may just abandon the compromised > account, and open a new one...which will shortly be compromised in > the same way. Well, if people don't value their accounts, that may be true. In that event, you have to do something else. > Or > > The former owner will classify these reports as spam/phishes. So, blacklist them, or contact their provider. > Relying on the same end-users who have created the problem to solve > it is a 100% pre-failed strategy. Who said we're relying on that. If I'd given you a list of ONE item, then you could level that accusation. >> 2. Contact the account service provider. > > If you can manage to jump through the hoops they've put in place, sure. > But automated reporting will misfire, manual reporting doesn't scale, > and many account service providers simply don't care. They don't > have to: there are few, if any, meaningful consequences to apathy, > and as long as they're profitable, few of them care about their > responsibilities to the 'net. > >> 3. Blacklist the address. > > (I'm presuming you mean email address, not IP address.) > > Yes, but given that there is an inexhaustible supply of those, this will > block the spam that's not coming any more from yesterday's compromised > account and do nothing to block the spam that's coming tomorrow from > the next compromised account. This is also a 100% pre-failed strategy. No, it's not. It makes life harder for the spammer. With reputation services, you can limit the amount of inbound email from addresses that haven't yet acquired good reputation. > (Now, if you're talking about IP address, sure: we have very effective > blacklist mechanisms for doing that.) No, we don't. Witness the fact that 90% of email is still spam. >> 4. Bounce unwanted email back to the sender. > > Unwanted mail should always be rejected, never bounced. Doing the > latter not only generates useless traffic but is pretty likely > to generate outscatter/backscatter, which is spam. And even if > it's correctly delivered, it will do absolutely no good -- see above. Bounces only cause backscatter when you can't rely on the sender address being accurate. When the address is accurate - a compromised account, for example, there are no good arguments left against it. In fact, it'll encourage security of the account. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From john@jlc.net Thu Jul 9 08:27:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D743A6B66 for ; Thu, 9 Jul 2009 08:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwAXk2ftDfiV for ; Thu, 9 Jul 2009 08:27:01 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 755253A684E for ; Thu, 9 Jul 2009 08:27:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7FC6033C67; Thu, 9 Jul 2009 11:27:17 -0400 (EDT) Date: Thu, 9 Jul 2009 11:27:17 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090709152717.GO15652@verdi> References: <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090709120305.GC26436@gsp.org> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:27:03 -0000 Rich Kulawiec wrote: > On Wed, Jul 08, 2009 at 11:57:04AM -0400, John Leslie wrote: > >> The introduction of reputation services creates options for getting >> the attention of the folks who maintain the MTAs of the large email >> services. > > We already have blacklists, Blacklists are, at most, one-bit reputiation services (which nobody would pay "two-bits" for). When I say "reputation service," I mean something with customers that pay for or otherwise subsidize the service. > which when appropriately used, do that without the need for more > elaborate mechanisms. Services naturally evolve, or to use your word, become more elaborate. > The trick is in the word "appropriate", which has little to do with the > criteria used for listing and a lot to do with who uses them and how. Which is why I ask for a "customer" relationship between service and users. >> If we insist on a world without reputation services (or ePostage), >> Rich is correct that only "large" email receivers will be able to >> make a dent in the practices of "large" email senders. > > Epostage is dead-on-arrival for a number of reasons, including "a > hundred million zombies". The reports of its death are highly exaggerated. A hundred million zombies aren't enough to guess strong password encryption (least of all one-time-pad encryption). And the mere fact of trying puts it into a different criminal classification than spamming. Presenting fraudulent ePostage tokens is, well, fraud. Blacklisting an MTA (zombied or otherwise) "during the investigation of fraud" is an unassailable practice. ("It's not _my_ fault that investigation is taking six months!") Making ePostage work is clearly possible in an environment of short token lifetime, encryption of paths it travels, and sufficient logging of failure-to-redeem to support (automated) investigations of fraud. > And any "reputation services", no matter how elaborately constructed, > will not make any difference unless they're used "appropriately", in > the same way that blacklists are/could be. "Appropriate" is in the eye of the beholder -- in this case the persons running the service, who will have customer agreements to limit "inappropriate" use. > In other words: we do not need any new mechanisms. Maybe you don't, but many of us do. > We do not need reputation services, or vouching services, Vouching services are needed to solve scaling problems. They also provide a "reporting" mechanism that can work -- where recipients report abuse to their reputation service, which accumulates enough to justify restrictive actions, and offers to summarize abuse reports to vouching services under contract terms. > or any of the other interesting ideas that have been put forth. We > need to use the mechanisms we already have, and have had for some time. We do use them (or at least the subset individual MTA operators trust, which amounts to pretty much all of them being used for some traffic). > The days when we could expect network and system administrators to > care about the abuse emanating from their operations because it was > clearly their highest responsibility and ethical obligation have been > gone for a long time. Expecting large corporations to "care about" such things is irrational. > (Some still do, of course -- and good for them.) _Many_ individuals running smaller ISPs do care! > The priority now is profit, profit, profit, and thus it is necessary > to speak to them in a language they understand. Aha! You do see the beauty of ePostage... > (That is: we need to revoke some of their privileges and thus provide > them motivation to do what they're not doing.) This has been tried. The result nearly always is that they assign "help-desk-personnel" to explain to their customers that the small ISP is failing to follow the "clearly-explained procedures" laid out on their web page; and that the problem needs to be solved by the small ISP. (Granted, they do "care" about the cost of those help-desk-personnal, but that cost can be controlled by ensuring that customers _never_ get anything more useful than that spiel and increasing the time-on-hold to even get that.) > We've spent the last 15 years sidestepping that, and we're still doing so. We've spent the last 15 years posturing why ePostage can't work and why none of the reputation services are worth the money their customers are (already) paying them. > What it comes down to, no matter what the mechanism, is "are you willing > to refuse privileges to X even though there may be consequences from > your own user community?". That's a balancing act. Small ISPs are willing do deal with "some" amount of consequences. > If "yes", and if there are a sufficient number of others who feel the > same, then it may be possible to affect X's behavior. Unfortunately, in the US at least, it's nearly impossible to reach a "sufficent" percentage without enlisting the cable/telco providers, all of which suffer the "care-less" characteristics of corporations. > If "no", then there's no reason for X to expend the time and money > required to address the issue. Alas, there _is_ one reason -- we'll go out of business if we don't. > And in the case of some egregious spam sources (e.g. Hotmail), the > answer given by many of us is "no" because they're TBTB: the outcry > from local users would be too great. Consider Hotmail: they have _many_ users who direct-marketers would love to reach, and would be happy to pay some ePostage amount to reach -- perhaps as much as ten cents per missive. Now suppose there were a critical-mass of ePostage banks: would Hotmail refuse to take the money? Now suppose that a few of us started asking Hotmail for one-cent ePostage to accept their email during a heavy-Hotmail-spamming period: is it worth it for them to refuse? (They're already running all the software needed to do it; they already have the ePostage account set up; the account is accumulating payments far greater that the "nuisance" amount we're asking; and they have no help-desk-personnel trained to explain why paying out 1% of the ePostage they receive would bankrupt them. > I'm certain Hotmail is well aware of this. They know full well they're > spewing, and they know equally well that they can get away with it. > I'm equally certain they're not the only ones who've made this > calculation. They're certainly not. Are we willing to consider how to tilt the "almighty-dollar" balance to encourage a better behavior? -- John Leslie From vesely@tana.it Thu Jul 9 08:40:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A670B3A6C57 for ; Thu, 9 Jul 2009 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=1.997, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQn3AUGCcqgg for ; Thu, 9 Jul 2009 08:40:05 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B33A43A683A for ; Thu, 9 Jul 2009 08:39:50 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 09 Jul 2009 17:40:17 +0200 id 00000000005DC034.000000004A560F61.00000839 Message-ID: <4A560F61.6020104@tana.it> Date: Thu, 09 Jul 2009 17:40:17 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> In-Reply-To: <20090709120305.GC26436@gsp.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:40:05 -0000 Rich Kulawiec wrote: > In other words: we do not need any new mechanisms. We do not need > reputation services, or vouching services, or any of the other interesting > ideas that have been put forth. We need to use the mechanisms we already > have, and have had for some time. I agree that mechanisms cannot do any good if they are not used. However, to forbid any new mechanism until existing ones won't have taken root may be exceedingly harsh. > The days when we could expect network > and system administrators to care about the abuse emanating from their > operations because it was clearly their highest responsibility and ethical > obligation have been gone for a long time. (Some still do, of course -- > and good for them.) The priority now is profit, profit, profit, and > thus it is necessary to speak to them in a language they understand. If we were able to highlight differences so as to improve competition, that would be understandable in those terms. But that requires a user base that is sensible to those arguments. IMHO, it is not much the gap between profit and ethics --different scale of planning horizon-- as the average user's ability to appreciate the quality of mail services, that has degraded them. Perhaps, we should think of ways to make mechanisms visible to end users? From mouse@Sparkle.Rodents-Montreal.ORG Thu Jul 9 09:04:22 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A664E3A6AA7 for ; Thu, 9 Jul 2009 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.572 X-Spam-Level: X-Spam-Status: No, score=-9.572 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbrLQuSyYjuV for ; Thu, 9 Jul 2009 09:04:21 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 348433A6C6B for ; Thu, 9 Jul 2009 09:04:19 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA25275; Thu, 9 Jul 2009 12:04:28 -0400 (EDT) From: der Mouse Message-Id: <200907091604.MAA25275@Sparkle.Rodents-Montreal.ORG> 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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 9 Jul 2009 11:45:06 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090709152717.GO15652@verdi> References: <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> <20090709152717.GO15652@verdi> Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:04:22 -0000 >>> The introduction of reputation services [...] >> We already have blacklists, > Blacklists are, at most, one-bit reputiation services (which nobody > would pay "two-bits" for). At work (an ISP) we're paying substantially more than two bits for access to a blacklist. We find it worth it. >> Epostage is dead-on-arrival for a number of reasons, including "a >> hundred million zombies". > A hundred million zombies aren't enough to guess strong password > encryption The point is not the zombies attacking the crypto. The point is zombies (ab)using their machines' legitimate owners' epostage. > Making ePostage work is clearly possible in an environment of [...] Quite possibly. Are such environments common enough to matter? I don't think anyone's claiming epostage doesn't have even a niche place. But so far it doesn't seem to have more than that. People keep claiming it does, but the proof (ie, the example) is, so far, lacking. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From schaefer@closedmail.com Thu Jul 9 09:33:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831FD3A6D08 for ; Thu, 9 Jul 2009 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSTt+9DJbFCb for ; Thu, 9 Jul 2009 09:33:11 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id CC15E3A6D0F for ; Thu, 9 Jul 2009 09:33:11 -0700 (PDT) Received: from torch.brasslantern.com ([96.238.220.32]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMI0016GWN33L4K@vms173003.mailsrvcs.net> for asrg@irtf.org; Thu, 09 Jul 2009 11:33:08 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n69GX2ef018786 for ; Thu, 09 Jul 2009 09:33:02 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n69GX2dH018785 for asrg@irtf.org; Thu, 09 Jul 2009 09:33:02 -0700 From: Bart Schaefer Message-id: <090709093302.ZM18784@torch.brasslantern.com> Date: Thu, 09 Jul 2009 09:33:02 -0700 Comments: In reply to John Leslie "Re: [Asrg] Too Big to Block?" (Jul 9, 11:27am) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Anti-Spam Research Group - IRTF MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Asrg] POSTAGE Re: Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:33:12 -0000 Incidentally, the POSTAGE draft expired a couple of weeks ago. Is it worth re-issuing? Anything new to say? I've been following the threads spawned by Claudio Telmon's draft and its intersection with some of the other threads; it appears to me that there is some potential overlap with the POSTAGE draft. For example, Claudio's consent-token header is very similar to a proposal I made for the "tunneling" of postage tokens through forwarding MTAs that don't support the protocol at the SMTP level. That was left out of POSTAGE in the interests of simplicity. From john@jlc.net Thu Jul 9 10:36:07 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D621928C206 for ; Thu, 9 Jul 2009 10:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HmdnXoej7UA for ; Thu, 9 Jul 2009 10:36:07 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1B81528C1F4 for ; Thu, 9 Jul 2009 10:36:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 08E4533CA9; Thu, 9 Jul 2009 13:36:28 -0400 (EDT) Date: Thu, 9 Jul 2009 13:36:28 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090709173627.GP15652@verdi> References: <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> <20090709152717.GO15652@verdi> <200907091604.MAA25275@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907091604.MAA25275@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:36:07 -0000 der Mouse wrote: > >>> Epostage is dead-on-arrival for a number of reasons, including "a >>> hundred million zombies". > >> A hundred million zombies aren't enough to guess strong password >> encryption > > The point is not the zombies attacking the crypto. The point is > zombies (ab)using their machines' legitimate owners' epostage. This is a problem why? >> Making ePostage work is clearly possible in an environment of [...] > > Quite possibly. Are such environments common enough to matter? I can imagine them... Why couldn't they be common? > I don't think anyone's claiming epostage doesn't have even a niche > place. But so far it doesn't seem to have more than that. People keep > claiming it does, but the proof (ie, the example) is, so far, lacking. Hmm... sounds like a good "research" project... -- John Leslie From mouse@Sparkle.Rodents-Montreal.ORG Thu Jul 9 11:21:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3293A6BCB for ; Thu, 9 Jul 2009 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iQEHVT7sOYO for ; Thu, 9 Jul 2009 11:21:42 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 559773A6B7B for ; Thu, 9 Jul 2009 11:21:42 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA26788; Thu, 9 Jul 2009 14:21:52 -0400 (EDT) From: der Mouse Message-Id: <200907091821.OAA26788@Sparkle.Rodents-Montreal.ORG> 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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 9 Jul 2009 13:59:30 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090709173627.GP15652@verdi> References: <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> <20090709152717.GO15652@verdi> <200907091604.MAA25275@Sparkle.Rodents-Montreal.ORG> <20090709173627.GP15652@verdi> Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:21:43 -0000 >> The point is not the zombies attacking the crypto. The point is >> zombies (ab)using their machines' legitimate owners' epostage. > This is a problem why? Because it means epostage won't help: it'll just mean that abused machines' owners pay in yet another way. (If epostage is expensive enough, it may help a little in that it may slightly reduce the compromise rate, but I think more likely it will result in pressure against epostage.) >>> Making ePostage work is clearly possible in an environment of [...] >> Quite possibly. Are such environments common enough to matter? > I can imagine them... Why couldn't they be common? I don't know. But deployed epostage seems to be remarkably rare, so _something_ is preventing its uptake; either your idea of how common such environments are is way high or there's something else preventing deployment despite what appears to be an open-and-shut case in favour. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From john@jlc.net Thu Jul 9 12:20:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFA03A68F6 for ; Thu, 9 Jul 2009 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKXV58vrQIiq for ; Thu, 9 Jul 2009 12:20:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 2FC1C3A63CB for ; Thu, 9 Jul 2009 12:20:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 56DD633CD3; Thu, 9 Jul 2009 15:20:38 -0400 (EDT) Date: Thu, 9 Jul 2009 15:20:38 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090709192038.GR15652@verdi> References: <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org> <20090709152717.GO15652@verdi> <200907091604.MAA25275@Sparkle.Rodents-Montreal.ORG> <20090709173627.GP15652@verdi> <200907091821.OAA26788@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907091821.OAA26788@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:20:21 -0000 der Mouse wrote: > >>> The point is not the zombies attacking the crypto. The point is >>> zombies (ab)using their machines' legitimate owners' epostage. > >> This is a problem why? > > Because it means epostage won't help: it'll just mean that abused > machines' owners pay in yet another way. In the ePostage draft I'm looking for a round-tuit to update, tokens are issued only to "bank" customers, and only on request. If some home user actually sets up such an account, he shouldn't be surprised when that account gets used. (If he chose to put it at risk for more than, say $10, then the bank deserves any hassle they get for not explaining the risk more thoroghly.) In practice, I expect home-user accounts to be rare, and most users to send through an ISP or corporate MTA. Those folks won't be surprised more than once! > (If epostage is expensive enough, it may help a little in that it may > slightly reduce the compromise rate, Although I don't expect that whole path to be much used, _any_ cash penalty will tend to get someone's attention! > but I think more likely it will result in pressure against epostage.) What means "pressure against ePostage"? If you mean simply refusing to pay any under any circumstances, so what? >>>> Making ePostage work is clearly possible in an environment of [...] >>> Quite possibly. Are such environments common enough to matter? >> I can imagine them... Why couldn't they be common? > > I don't know. But deployed epostage seems to be remarkably rare, so > _something_ is preventing its uptake; Uptake must _follow_ actual deployment. My belief is that every deployment which could be classified as ePostage so far has been too expensive, and has created some incentives which are plain _wrong_. (It would help _me_ if folks pointed out where draft-irtf-asrg-postage creates "wrong" incentives.) > either your idea of how common such environments are is way high or > there's something else preventing deployment despite what appears to be > an open-and-shut case in favour. I didn't claim "such environments" are common. Remember, I specified - short token lifetime, - encryption of paths it travels, and - sufficient logging of failure-to-redeem to support (automated) investigations of fraud. Have I missed other ePostage proposals that included all of these? -- John Leslie From johnl@iecc.com Thu Jul 9 17:44:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799FB3A6B1E for ; Thu, 9 Jul 2009 17:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.164 X-Spam-Level: X-Spam-Status: No, score=-19.164 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGQmIdamDE52 for ; Thu, 9 Jul 2009 17:44:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id A65D83A6B71 for ; Thu, 9 Jul 2009 17:43:56 -0700 (PDT) Received: (qmail 40468 invoked from network); 10 Jul 2009 00:44:23 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 10 Jul 2009 00:44:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; olt=johnl@user.iecc.com; bh=dVeC3hIBsIzgS4l5vQSVQ7FP/7Hn96qVfSTsZSFZo1U=; b=L8xuUt1BfpOCvMNhAx5ze/yrJkB8ktJ6n3kzAC2VpjicjJTy3X271hFHHMGFfZZB3q2JznI/NnxtPiG2zZjJIiI90kfLzJ9kIKIU+lLHd9Z2ucC3rwjScQOQp292ryM/NbbPjVK2IW4ckiFCtgTN8Wq09Qnfm0LpMbHfAvRvrls= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0907; bh=dVeC3hIBsIzgS4l5vQSVQ7FP/7Hn96qVfSTsZSFZo1U=; b=uKeZ9LCemDVaCKChkHf3TCna9/GSTjEY7AOu1HnbGStkkktAsd9AFzN4Z0eP+3RfSJgM3pbkVKXZUoD2W3P8Hf8x5I5V3nZbL7lFCm77p6DoECIMiUYrcsjsAIA6MkW3j2+MTGpM1mF52/83LBRMOHuUoTb6UW7Swblhta71cdM= Date: 10 Jul 2009 00:44:23 -0000 Message-ID: <20090710004423.35119.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090709173627.GP15652@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] EPOSTAGE Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 00:44:23 -0000 Please remember the rule about labelling EPOSTAGE messages. >> The point is not the zombies attacking the crypto. The point is >> zombies (ab)using their machines' legitimate owners' epostage. > > This is a problem why? It destroys epostage's credibility to potential users. Please see my white paper. >> Quite possibly. Are such environments common enough to matter? > I can imagine them... Why couldn't they be common? Ahem. I can imagine flying hippopotami, too. >> place. But so far it doesn't seem to have more than that. People keep >> claiming it does, but the proof (ie, the example) is, so far, lacking. > > Hmm... sounds like a good "research" project... Right. Have at it. R's, John From claudio@telmon.org Fri Jul 10 08:48:38 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215A63A6A4B for ; Fri, 10 Jul 2009 08:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUvZndNHR-s4 for ; Fri, 10 Jul 2009 08:48:37 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id EDE413A67CC for ; Fri, 10 Jul 2009 08:48:36 -0700 (PDT) Received: from 88-149-250-19.dynamic.ngi.it ([::ffff:88.149.250.19]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.19+MkxCM1dFCan; Fri, 10 Jul 2009 17:49:04 +0200 Message-ID: <4A5762EE.1020502@telmon.org> Date: Fri, 10 Jul 2009 17:49:02 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090608 Lightning/0.8 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <090709093302.ZM18784@torch.brasslantern.com> In-Reply-To: <090709093302.ZM18784@torch.brasslantern.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] POSTAGE Re: Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:48:38 -0000 Bart Schaefer wrote: > For example, > Claudio's consent-token header is very similar to a proposal I made for > the "tunneling" of postage tokens through forwarding MTAs that don't > support the protocol at the SMTP level. That was left out of POSTAGE > in the interests of simplicity. Is it available somewhere? Thanks -- Claudio Telmon claudio@telmon.org http://www.telmon.org From john@jlc.net Fri Jul 10 10:26:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A9F3A6858 for ; Fri, 10 Jul 2009 10:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE8VBASE85eI for ; Fri, 10 Jul 2009 10:26:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id F04293A67AD for ; Fri, 10 Jul 2009 10:26:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id AE2CF33C7C; Fri, 10 Jul 2009 13:26:49 -0400 (EDT) Date: Fri, 10 Jul 2009 13:26:49 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090710172649.GU15652@verdi> References: <20090709173627.GP15652@verdi> <20090710004423.35119.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090710004423.35119.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] EPOSTAGE Too Big to Block? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:26:31 -0000 John Levine wrote: > >>> The point is not the zombies attacking the crypto. The point is >>> zombies (ab)using their machines' legitimate owners' epostage. >> >> This is a problem why? > > It destroys epostage's credibility to potential users. Remember, the "users" are sending and receiving MTAs. I see little benefit in defining a class of "potential users" that goes beyond the class of current MTA operators. While I grant that FUD can always "destroy credibility", I don't see it as hard to convince current MTA operators that if they give malware access to a "bank" account they shouldn't be surprised when a particular malware empties that account. "Credibility" of a cash-transfer system running on compromised machines isn't a concept I wish to promote... > Please see my white paper. Presumably John means http://www.taugh.com/epostage.pdf which makes a number of excellent points, most of which I quite agree with. For example: ] ] Since a sender can send the same valid stamp to many recipients, a ] recipient who gets a stamp from an unknown sender needs to check to ] see if it has already been used, by asking the issuing bank. ]... ] Most likely the majority of banks will be competently run, but some ] won't, deliberately or inadvertently issuing stamps that they can't ] later cash. ]... ] Usable international e-postage will need a system that lets recipients ] rapidly decide whether they're willing to accept stamps from unknown ] far-away banks. ]... ] If a stamp costs a penny... and 10% of the total stamps presented are ] real (the other 90% being spam), and that the bank's cut on each stamp ] is 10%, the bank has only 1/10 cent to spend to cancel each real stamp ] and 1/100 cent to reject a fake stamp. I believe draft-irtf-asrg-postage sets out to live within those constraints. John continues and elaborates some threats ] ] To send mail without paying postage, one might send spam with fake ] stamps hoping recipients won't check them, send mail with forged ] return addresses that are on recipients' whitelists, send a little ] innocent mail to get recipients to whitelist them followed by a lot ] of spam, set up a fake bank that deliberately issues uncashable ] stamps, or trick a legitimate bank into issuing postage without ] paying for it. ] ] To charge e-postage to third parties. one might sneak spam into other ] people's mailing lists, or use a virus or Trojan horse software that ] sends spam from the third party's computer. These are valid threats, but not in scope of draft-irtf-asrg-postage, IMHO. They seem most appropriate for documents issued by "banks" to their customers. I could go over any of them on request, but I see no reason to try to address all of them in a single email. I expect to reissue draft-irtf-asrg-postage, and I am open to suggestions for improvement, but issues such as those, IMHO, are better treated in a draft on a possible implementaton of an ePostage bank (in progress) or a draft on "best practices" for using an ePostage system (which I'm willing to act as Editor for). -- John Leslie From nwnetworks@dial.pipex.com Mon Jul 20 10:31:02 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD67828C1F7 for ; Mon, 20 Jul 2009 10:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgdPtFrddRpM for ; Mon, 20 Jul 2009 10:30:56 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id EE41728C22C for ; Mon, 20 Jul 2009 10:30:55 -0700 (PDT) X-Trace: 234400602/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.188/None/nwnetworks@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.188 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEALNGZEo+vGS8/2dsb2JhbACDLFqMHsB3CYQDBQ X-IronPort-AV: E=Sophos;i="4.43,235,1246834800"; d="scan'208";a="234400602" X-IP-Direction: IN Received: from 1cust188.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.188]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Jul 2009 18:30:53 +0100 Message-ID: <009301ca0957$66d1a320$0601a8c0@allison> From: "Tom Petch" To: "Anti-Spam Research Group - IRTF" References: <20090709173627.GP15652@verdi><20090710004423.35119.qmail@simone.iecc.com> <20090710172649.GU15652@verdi> Date: Mon, 20 Jul 2009 18:30:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Asrg] archives X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch , Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 17:31:02 -0000 Post cutover, the asrg archives seem to be inaccessible. You requested: http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html and did not find it. Anyone know where they went? Tom Petch From asrg3@billmail.scconsult.com Mon Jul 20 11:25:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FEC3A6886 for ; Mon, 20 Jul 2009 11:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RFl928ZTW1D for ; Mon, 20 Jul 2009 11:24:59 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id EEB053A6956 for ; Mon, 20 Jul 2009 11:24:01 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 4FE1090006A; Mon, 20 Jul 2009 14:22:54 -0400 (EDT) Message-ID: <4A64B5FD.8060001@billmail.scconsult.com> Date: Mon, 20 Jul 2009 14:22:53 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Tom Petch , Anti-Spam Research Group - IRTF References: <20090709173627.GP15652@verdi><20090710004423.35119.qmail@simone.iecc.com> <20090710172649.GU15652@verdi> <009301ca0957$66d1a320$0601a8c0@allison> In-Reply-To: <009301ca0957$66d1a320$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] archives X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 18:25:06 -0000 Tom Petch wrote, On 7/20/09 12:30 PM: > Post cutover, the asrg archives seem to be inaccessible. > > You requested: > http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html > and did not find it. Every message to the list includes the answer in this header: List-Archive: > Anyone know where they went? > > Tom Petch > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg Every message also has that URL in its footer, from which the archives are just a link away. From claudio@telmon.org Mon Jul 20 11:37:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCD83A6A78 for ; Mon, 20 Jul 2009 11:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAytzR32w-7j for ; Mon, 20 Jul 2009 11:37:50 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 532503A6834 for ; Mon, 20 Jul 2009 11:37:50 -0700 (PDT) Received: from 88-149-250-60.dynamic.ngi.it ([::ffff:88.149.250.60]) by slim-4a.inet.it via I-SMTP-5.6.1-561 id ::ffff:88.149.250.60+3WTLh6HbbrD; Mon, 20 Jul 2009 20:26:01 +0200 Message-ID: <4A64B6B8.2050804@telmon.org> Date: Mon, 20 Jul 2009 20:26:00 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090608 Lightning/0.8 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Tom Petch , Anti-Spam Research Group - IRTF References: <20090709173627.GP15652@verdi><20090710004423.35119.qmail@simone.iecc.com> <20090710172649.GU15652@verdi> <009301ca0957$66d1a320$0601a8c0@allison> In-Reply-To: <009301ca0957$66d1a320$0601a8c0@allison> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] archives X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 18:37:57 -0000 Tom Petch wrote: > Post cutover, the asrg archives seem to be inaccessible. > > You requested: > http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html > and did not find it. > > Anyone know where they went? http://www.irtf.org/mail-archive/web/asrg/current/maillist.html -- Claudio Telmon claudio@telmon.org http://www.telmon.org From nwnetworks@dial.pipex.com Wed Jul 22 10:31:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF07C3A696C for ; Wed, 22 Jul 2009 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVWW5WQjtJ7r for ; Wed, 22 Jul 2009 10:31:54 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id C7DD23A6820 for ; Wed, 22 Jul 2009 10:31:53 -0700 (PDT) X-Trace: 269485231/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.223/None/nwnetworks@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.223 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAO/pZko+vGTf/2dsb2JhbACDLIx9xCsJhAUFgT8 X-IronPort-AV: E=Sophos;i="4.43,248,1246834800"; d="scan'208";a="269485231" X-IP-Direction: IN Received: from 1cust223.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.223]) by smtp.pipex.tiscali.co.uk with SMTP; 22 Jul 2009 18:30:19 +0100 Message-ID: <005b01ca0ae9$a59bf680$0601a8c0@allison> From: "Tom Petch" To: "Bill Cole" , "Anti-Spam Research Group - IRTF" References: <20090709173627.GP15652@verdi><20090710004423.35119.qmail@simone.iecc.com> <20090710172649.GU15652@verdi> <009301ca0957$66d1a320$0601a8c0@allison> <4A64B5FD.8060001@billmail.scconsult.com> Date: Wed, 22 Jul 2009 18:29:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Asrg] archives X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch , Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:31:55 -0000 Thanks Bill, Claudio, SM. Yes, the archives are just where you say; I was accessing them from the asrg charter page and failing. I have flagged this to AMS. Tom Petch ----- Original Message ----- From: "Bill Cole" To: "Tom Petch" ; "Anti-Spam Research Group - IRTF" Sent: Monday, July 20, 2009 8:22 PM Subject: Re: [Asrg] archives > Tom Petch wrote, On 7/20/09 12:30 PM: > > Post cutover, the asrg archives seem to be inaccessible. > > > > You requested: > > http://www.ietf.org/mail-archive/working-groups/asrg/current/maillist.html > > and did not find it. > > Every message to the list includes the answer in this header: > > List-Archive: > > > Anyone know where they went? > > > > Tom Petch > > > > _______________________________________________ > > Asrg mailing list > > Asrg@irtf.org > > http://www.irtf.org/mailman/listinfo/asrg > > Every message also has that URL in its footer, from which the archives are > just a link away. From davidnicol@gmail.com Thu Jul 23 23:03:59 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D3528C0F5 for ; Thu, 23 Jul 2009 23:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnI7YSxNk1KN for ; Thu, 23 Jul 2009 23:03:59 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id 0A27628C0D9 for ; Thu, 23 Jul 2009 23:03:56 -0700 (PDT) Received: by yxe10 with SMTP id 10so2384427yxe.15 for ; Thu, 23 Jul 2009 23:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=deWU4w1rpmuzx7WuF2fwknIMzIghfF2QMg4KD6ca+d0=; b=xpV2EOd9LnXMRyjerUOqvam5Tmpef6RxABQ4eJlbb6DPlU9D6NhlsO26nOgtqp4VR7 sYlQnh/i7ZBFNtn2JWTHAFPYDgWa7ntuykfI5yeBw+emAkK6bp+M8InE2WJ99rrgY1A4 u43wy+VNMaRK97BGhG35PTeL9QwUo9MHTDl0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=r26SqANzY0L7cIRXHIyVJyxaEpu26EI82+c23PuA1Mu+L4WqbQ1CfwUjg6/bYCjlBH 42R0onpnNwxOk1iarSTenNUIPds7bbjZhozxKEqL+XkuMku+YWCLaPrLbZUEgRyRXQhf iEgHzAoeTyJt5Scv7h77brggQyjeS2mM2rnpI= MIME-Version: 1.0 Received: by 10.150.146.5 with SMTP id t5mr4683456ybd.223.1248414851067; Thu, 23 Jul 2009 22:54:11 -0700 (PDT) From: David Nicol Date: Fri, 24 Jul 2009 00:53:51 -0500 Message-ID: <934f64a20907232253q444e6b38xfcdee9763e96db2a@mail.gmail.com> To: ASRG Content-Type: multipart/alternative; boundary=000e0cd4887abaf1ac046f6d3b38 Subject: [Asrg] gmail now allegedly includes "unsubscribe" shortcut for well-formatted mailing list traffic X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 06:03:59 -0000 --000e0cd4887abaf1ac046f6d3b38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit http://gmailblog.blogspot.com/2009/07/unsubscribing-made-easy.html -- "The process by which banks create money is so simple that the mind is repelled." -- John Kenneth Galbraith --000e0cd4887abaf1ac046f6d3b38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://gmailblog.blogspot.com/2009/07/unsubscribing-made-easy.html<= /a>


--
"The process by which banks create money is so s= imple that the mind is repelled." -- John Kenneth Galbraith
--000e0cd4887abaf1ac046f6d3b38-- From vesely@tana.it Fri Jul 24 01:05:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29EC28C166 for ; Fri, 24 Jul 2009 01:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKd44Vv5AkBA for ; Fri, 24 Jul 2009 01:05:47 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 2B82528C161 for ; Fri, 24 Jul 2009 01:05:46 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 24 Jul 2009 09:58:30 +0200 id 00000000005DC039.000000004A6969A6.00000A6F Message-ID: <4A6969A6.5040700@tana.it> Date: Fri, 24 Jul 2009 09:58:30 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <934f64a20907232253q444e6b38xfcdee9763e96db2a@mail.gmail.com> In-Reply-To: <934f64a20907232253q444e6b38xfcdee9763e96db2a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] gmail now allegedly includes "unsubscribe" shortcut for well-formatted mailing list traffic X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 08:05:48 -0000 David Nicol wrote: > > http://gmailblog.blogspot.com/2009/07/unsubscribing-made-easy.html While it is obvious that there are 4 possible choices for a "report/unsubscribe" dialog, they only consider 3 of them. The fourth is dealt with in the bottom paragraph on that page: Update (1:50pm): If you want to unsubscribe without reporting the message as spam, click "show details" in the top-right corner of the message, then click "Unsubscribe from this sender." "From this _sender_", the ambiguity of it!