From asrg-bounces@ietf.org Sat Jan 06 16:19:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IsZ-0001nb-QA; Sat, 06 Jan 2007 16:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IsX-0001nT-CH for asrg@ietf.org; Sat, 06 Jan 2007 16:15:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3IsV-0007vu-1z for asrg@ietf.org; Sat, 06 Jan 2007 16:15:01 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3IsL-0001D9-VC for asrg@ietf.org; Sat, 06 Jan 2007 22:14:49 +0100 Received: from du-017a-032.access.de.clara.net ([213.221.75.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 22:14:49 +0100 Received: from nobody by du-017a-032.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 22:14:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sat, 06 Jan 2007 22:11:36 +0100 Organization: Lines: 18 Message-ID: <45A01088.115B@xyzzy.claranet.de> References: <459AF0BD.4060007@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-032.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-smtp@imc.org Subject: [Asrg] Re: [Fwd: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC] X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Tony Hansen wrote on > fyi, this seems relevant to these two lists. Thanks, answered on the general list, forwarding your pointer to the ASRG list. Maybe I simply don't get it, or the I-D proposes to send special NDRs for mails considered as dubious by OPES, and the "special" feature is a way to bypass OPES on behalf of the (alleged) sender in another mail. That would be a convoluted kind of challenge response system, and the discussion of this known 2821 issue in the draft does not justify this net abuse. > http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-security-02.txt Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 17 14:40:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ga5-0000aB-Qp; Wed, 17 Jan 2007 14:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ga4-0000a6-Is for asrg@ietf.org; Wed, 17 Jan 2007 14:36:20 -0500 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7GZz-0000S7-UI for asrg@ietf.org; Wed, 17 Jan 2007 14:36:20 -0500 Received: (qmail 10062 invoked from network); 17 Jan 2007 19:36:04 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 17 Jan 2007 19:36:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Jan 2007 19:36:04 -0000 Date: Wed, 17 Jan 2007 14:36:04 -0500 (EST) From: John L To: Anti Spam Research Group Message-ID: <20070117143433.F56994@simone.iecc.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.3 (----) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [Asrg] Opportunity to get involved in the NSF FIND research program X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org This went out to the IRTF main list. Anyone want to do some actual research? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. Begin forwarded message: > From: David Clark > Date: January 10, 2007 8:08:29 AM PST > To: End to End Interest > Subject: [e2e] Opportunity to get involved in the NSF FIND research > program > > Folks, > Many of you may know that NSF has announced a focus area for > research funding called Future Internet Design, or FIND. The idea behind > FIND is to bring together interested researchers to discuss options for > a future Internet, and to develop integrated proposals for such a > network. > NSF understands that there is lots of interesting, relevant work > that has been funded from sources other than NSF, and there may be folks > who would like to come to the meetings and participate in the process, > on a BYOF (Bring Your Own Funding) basis. You might have funding from a > different NSF program, from another funding agency, or from your > company. Perhaps you are from a different country with its own funding > mechanisms. > However you are funded, if you are interesting in being part of the > intellectual effort, please read the attached announcement, which is an > invitation to send in an informal white paper describing what you are up > to. > If you can conceive of other ways to build bridges between this FIND > program and other research efforts, please send me a message directly. > We are open to other ideas. > > David Clark (for the FIND Planning Committee) > > ---- > > > CALL FOR RESEARCH COLLABORATION ON FUTURE INTERNET ARCHITECTURES > IN PARTNERSHIP WITH THE US NSF FIND PROGRAM > > BACKGROUND > > Much energy has recently crystallized within the international > network research community for developing fresh perspectives on how > to architect a single, coherent, global data network. The > Internet's unquestionable success at embodying one such > architecture has also led over the decades of its operation to > unquestionable difficulties with regard to support for some types > of functionality and sound operation. > > As a reflection of this growing community interest, the U.S. > National Science Foundation has announced a focus area for > networking research called FIND, or Future Internet Design. The > agenda of this focus area is to invite the research community to > take a long-range perspective, and to consider what our global > network of 10 or 15 years should be, and how to build a network > that meets the future requirements. (For further information on the > FIND program, see NSF solicitation 07-507, available at http:// > www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf07507.) The > research funded by FIND aims to contribute to the emergence of one > or more integrated visions of a future network. > > A vital part of this effort concerns fostering collaboration and > consensus-building among researchers working on future global > network architecture. To this end, NSF has created a FIND Planning > Committee, which is working with NSF to organize a series of > meetings among FIND grant recipients structured around activities > to identify and refine overarching concepts for a network of the > future. > > A BROADER COMMUNITY > > NSF recognizes that its efforts at funding research to contribute > to a future global network exists within a broader set of efforts > with similar goals supported by other agencies, industry, and > nations. Accordingly, NSF seeks researchers external to the FIND > program itself?but who share a likeminded vision?to participate in > the collaboration and consensus-building. NSF particularly welcomes > international collaboration?any vision of a future global network > will greatly benefit from global participation. > > To this end, external researchers interested in such participation > are invited to submit short white papers describing themselves and > their work. Based on evaluation of these white papers, a select > number of researchers will be invited to join the FIND meetings and > other events, as overall meeting sizes and logistics permit. > > EXPECTATIONS AND EVALUATION CRITERIA > > Since the efficacy of FIND meetings is in part a function of their > size and coherence, the evaluation of the white papers will focus > on certain criteria that are listed below, along with expectations > regarding what external participation entails. Naturally, > interested parties should take these considerations into account as > they write their white papers, and include information in their > papers sufficient to allow the FIND program to evaluate the aptness > of their participation. > > ? In a few sentences, please describe your research and its > intended impact. When possible, include as an attachment (or a URL) > a longer description, which if you wish can be something prepared > for another purpose (e.g. your original funding proposal or a > publication). It will help to limit the supporting material to 15 > pages or fewer. > > ? Please summarize in the white paper the ways you see your > research as being compatible with the objectives of FIND (the URL > for the FIND solicitation is included above). Research that accords > with the FIND program will generally be based on a long-term vision > of future networking, rather than addressing specific near-term > problems, and framed in terms of how it might contribute to an > overall architecture for a future network. > > ? The FIND meetings have been organized for the benefit of > researchers who have already been funded and are actively pursuing > their research. Research described in white papers should already > be funded. Please describe the means you have available to cover > your FIND-related research: the source of funds, their duration, > and (roughly) the supported level of effort. Unfortunately, NSF > lacks additional funds to financially support your participation in > the meetings, so you must be prepared to cover those costs as well. > If you are planning to submit a FIND research proposal to the > current NeTS solicitation, you should not submit a white paper here > based on that research. Successful FIND grant recipients will > automatically be invited to join the FIND community. > > ? As one of the goals of FIND is to develop an active community of > researchers who over time work increasingly together towards > coherent, overall architectural visions, we aim for external > participants to likewise become significantly engaged. To this end, > you should anticipate (and have resources for) participating in > FIND project meetings in an active, sustained fashion. > > ? Your research must not be encumbered by intellectual property > restrictions that prevent you from fully discussing your work and > its results with the other participants. > > Please try to limit your white paper to 2 pages. Your white paper > (and the supporting research description) will be read by members > of the research community, so do not submit anything that you would > not reveal to your peers. (White papers are not viewed as formal > submissions to NSF.) > > TIMING AND SUBMISSION > > You may submit a white paper at any time during the FIND program. > Before each scheduled FIND PI meeting, the papers on hand will be > reviewed. Meetings are anticipated to occur approximately three > times a year, in March, July/August and November. The next FIND > meeting is scheduled for March 5/6, 2007, and priority in > consideration for that meeting will be given to white papers that > are received by Friday, January 19th, 2007. > > Send your white paper to Darleen Fisher and > Allison Mankin for coordination. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 18 06:47:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VhT-0008O9-HA; Thu, 18 Jan 2007 06:44:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VhS-0008GV-69 for asrg@ietf.org; Thu, 18 Jan 2007 06:44:58 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7VhN-0004FV-V8 for asrg@ietf.org; Thu, 18 Jan 2007 06:44:58 -0500 Received: by an-out-0708.google.com with SMTP id d30so46699and for ; Thu, 18 Jan 2007 03:44:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=rQBiQrjesRKHULY/TzaE9+o1aV9vOoYJ3t/jMCNGTcdfku0b5XxO1nK/U7DIJl6Iql/L4IO7PS78ywqh+5AkGU9Z8PoTbv+cTQRO21pG0C7w/7GDxeJQ4B24s1pxVtsnxVm9YYDJ4evzBhkjkU0VpoRdOfuymaXzriLgWNflBhw= Received: by 10.65.180.7 with SMTP id h7mr701835qbp.1169120686257; Thu, 18 Jan 2007 03:44:46 -0800 (PST) Received: by 10.65.248.6 with HTTP; Thu, 18 Jan 2007 03:44:45 -0800 (PST) Message-ID: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> Date: Thu, 18 Jan 2007 11:44:45 +0000 From: "Danny Angus" To: asrg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 1b21a924f522ef47 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At: http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt You will find a document which outlines an idea I've had for a while. Please give me your comments on this list. The thrust of the document is that while we don't know what the silver bullet solution for spam is we do know some of the characteristics which we expect it to exhibit. We also know that very many ideas are presented on this list which fail to meet one or more of those criteria, this draft is intended to provide a reference which outlines those criteria, and could be used as a partial statement of requirements for a technique to solve the problem of spam. Obviously this is just my own 2c at the moment, so let me know what your opinions are and I'll modify, abandon or replace this as necessary. FYI the abstract reads: "The Internet Research Task Force Anti-Spam Research Group (ASRG) is frequently presented with proposals for techniques for managing spam from authors who wish to elicit an expert critique of their proposals. In many cases proposals fall foul of issues and risks which are well known and understood by members of the ASRG. This Internet Draft is intended to enumerate and explain a number of the more important of the criteria which tend to be applied. This document will then serve as a normative checklist for anyone wishing to present a technique to the ASRG." d. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 18 08:33:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XN2-0002ow-Ej; Thu, 18 Jan 2007 08:32:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XN1-0002oW-6c for asrg@ietf.org; Thu, 18 Jan 2007 08:31:59 -0500 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7XN0-0004Mo-0d for asrg@ietf.org; Thu, 18 Jan 2007 08:31:59 -0500 Received: by nz-out-0506.google.com with SMTP id z6so152271nzd for ; Thu, 18 Jan 2007 05:31:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ammtOh5gU1w2ryINhtqs0nM7OO5ZmNDFR6C3TZQeUN686WJ2AKK3GwFz5TDoGLzLXhjmZyk+Cy3+/YHZucA6X8Sd0arv55+l8OMrjqD5Lxq0IuQ6QxrCXE+gYwh1fLtuDKbMcB6L+QIEFaZBPs4Hxab9wlvj2EV8V/a0LL4OF1w= Received: by 10.65.232.18 with SMTP id j18mr859438qbr.1169127116980; Thu, 18 Jan 2007 05:31:56 -0800 (PST) Received: by 10.65.248.6 with HTTP; Thu, 18 Jan 2007 05:31:56 -0800 (PST) Message-ID: <5ec229170701180531l392e1797ua1a920161bb6ab0e@mail.gmail.com> Date: Thu, 18 Jan 2007 13:31:56 +0000 From: "Danny Angus" To: asrg@ietf.org In-Reply-To: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> X-Google-Sender-Auth: 73f9ac69df9b8bb8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Asrg] Re: Comments: draft-irtf-asrg-criteria-00.txt X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I've put an html version at http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 18 11:12:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZqZ-00054B-5F; Thu, 18 Jan 2007 11:10:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZqY-00053w-8I for asrg@ietf.org; Thu, 18 Jan 2007 11:10:38 -0500 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7ZqV-0000Wz-LE for asrg@ietf.org; Thu, 18 Jan 2007 11:10:38 -0500 Received: (qmail 2747 invoked from network); 18 Jan 2007 16:10:35 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 18 Jan 2007 16:10:35 -0000 Date: 18 Jan 2007 16:10:35 -0000 Message-ID: <20070118161035.62612.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Thank you for moving ahead with this. I've been sitting on it way too long supposed to make comments. I agree that taxonomies to help categorize anti-spam techniques and their success or lack thereof are a good direction for us. In article <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> you write: >At: >http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt > >You will find a document which outlines an idea I've had for a while. >Please give me your comments on this list. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 18 20:50:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ioA-000885-Dr; Thu, 18 Jan 2007 20:44:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7io8-00087z-NE for asrg@ietf.org; Thu, 18 Jan 2007 20:44:44 -0500 Received: from mailout1.igs.net ([216.58.97.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7io7-0003Fx-F4 for asrg@ietf.org; Thu, 18 Jan 2007 20:44:44 -0500 Received: from waltdnes.org (i209-195-115-108.cia.com [209.195.115.108]) by mailout1.igs.net (Postfix) with SMTP id A13C66085 for ; Thu, 18 Jan 2007 20:44:40 -0500 (EST) Received: by waltdnes.org (sSMTP sendmail emulation); Thu, 18 Jan 2007 20:47:02 -0500 From: "Walter Dnes" Date: Thu, 18 Jan 2007 20:47:02 -0500 To: ASRG list Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt Message-ID: <20070119014702.GA14065@waltdnes.org> References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, Jan 18, 2007 at 11:44:45AM +0000, Danny Angus wrote > At: http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt > You will find a document which outlines an idea I've had for a while. > Please give me your comments on this list. > > The thrust of the document is that while we don't know what the silver > bullet solution for spam is we do know some of the characteristics > which we expect it to exhibit. Item number 0) Avoid using "the S word" 1,$s/spam/unwanted email/ Rationale: If you set up a technical definition of spam, some lawyer or wannabee-lawyer *WILL* find a loophole in it. And there are some legal jurisdictions that have defined spam, and allowed explicit exemptions. The result will be a constant battle of technicalities. And calling someone's email "spam" can result in lawsuits by "legitimate bidnizzmen". Simply saying that you don't want certain email, without calling its senders "spammers", is less of a legal risk. In other words, "because I said so" should be sufficient reason for a person to reject email for their inbox. My inbox, my rules. Item number 1) Assume that senders of unwanted email may be hostile, unethical, sleazy lawbreakers who will resort to all means at their disposal to get their unwanted email delivered to their target. If your proposed solution will not work in such an environment, forget about it. -- Walter Dnes In linux /sbin/init is Job #1 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 19 01:11:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7muS-0000wn-Sk; Fri, 19 Jan 2007 01:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7muP-0000wd-Pq for asrg@ietf.org; Fri, 19 Jan 2007 01:07:29 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7muO-0006F3-Hc for asrg@ietf.org; Fri, 19 Jan 2007 01:07:29 -0500 Received: by ug-out-1314.google.com with SMTP id 72so339453ugd for ; Thu, 18 Jan 2007 22:07:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJIfl9t76Pfw+K6G508Kh4zR04c0ZLMJXVFPfyauMKtuByOK6OQY+gWpXwVLXDAFIvdf31h+qTg9Umej834Y1BPLIosJBizLFnJjJfp54W/4DV5N4+F9sKAi72N+xUQVuTPlCd86A+LNDfjgzfDLEaed/WEOzxT0PtDhVjc9QFQ= Received: by 10.78.97.7 with SMTP id u7mr1728363hub.1169186847529; Thu, 18 Jan 2007 22:07:27 -0800 (PST) Received: by 10.78.23.19 with HTTP; Thu, 18 Jan 2007 22:07:27 -0800 (PST) Message-ID: <934f64a20701182207g5e6eb569x30ba282ec1fb2eb9@mail.gmail.com> Date: Fri, 19 Jan 2007 00:07:27 -0600 From: "David Nicol" To: "Walter Dnes" Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <20070119014702.GA14065@waltdnes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <20070119014702.GA14065@waltdnes.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/18/07, Walter Dnes wrote: > My inbox, my rules. also known as "per-recipient configuration" _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 19 04:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qLO-0003t1-7T; Fri, 19 Jan 2007 04:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qLN-0003sW-1N for asrg@ietf.org; Fri, 19 Jan 2007 04:47:33 -0500 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7qLJ-0007E5-5m for asrg@ietf.org; Fri, 19 Jan 2007 04:47:32 -0500 Received: by wr-out-0506.google.com with SMTP id i22so362093wra for ; Fri, 19 Jan 2007 01:47:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VqOdRAFFhu/eXUPsr/yStsT3Ad4nkVFtBIlMVT6H8safMfMy9IsYtHVlA8INcDme5c50fm3YnYOCjr/ua1AoopBzFdgpf/LgLB9bT4k+WD1dsL0j6H8cpNFKGmfcNtD8FD7ZU1JOeCaf3gdEV3kZ6I3eSx+kPjuNuReCVIT7al8= Received: by 10.78.170.6 with SMTP id s6mr1793798hue.1169200047607; Fri, 19 Jan 2007 01:47:27 -0800 (PST) Received: by 10.78.185.5 with HTTP; Fri, 19 Jan 2007 01:47:27 -0800 (PST) Message-ID: <5ec229170701190147sc483849qffa2c1ec4d37e399@mail.gmail.com> Date: Fri, 19 Jan 2007 09:47:27 +0000 From: "Danny Angus" To: asrg@ietf.org Subject: Fwd: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <5ec229170701190144h5020b020tb652e13cc8ad09df@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701181316t7a1e6b39r868320254cbc4be2@mail.gmail.com> <5ec229170701190144h5020b020tb652e13cc8ad09df@mail.gmail.com> X-Google-Sender-Auth: e84f6c4d18fe866b X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org David, On 1/18/07, David Nicol wrote: > okay you got it. Its appreciated > Before looking at it: > One hopes that the criteria therein will be a superset of the issues > enumerated on the "how to tell if you are an anti-spam kook" page > http://www.rhyolite.com/anti-spam/you-might-be.html > > After looking at it: > right off (1.1.1), we're at > http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-4 That's a fair point. I don't think the difference is hugely significant. But I'm not convinced that "bulk" is really a necessary constraint. OTOH I know we've had this discussion before and I have *no* intention of starting it again, god forbid, so I'm prepared to remove "spam" as the headline and replace it with Unwanted Mail throughout the document, of which "unsolicited bulk mail" is certainly part. This also addresses Walter's point about the S word being pejorative but "i said so" being the recipients right. Why Unwanted Mail? Because I think that the value of any solution is in the removal of mail which which we know will be unwanted *before* it reaches its destination, the sooner the better to the point where preventing it from being sent at all is the ultimate. The trick (or implementation detail, left as an exercise for the reader...) is to identify it as unwanted before it gets there. Whether or not it is solicited, bulk or one off, doesn't really change the economics in which resources can surely be put to better use than than the transportation or processing of mail which isn't going to be read. WDYT? > > (2.3.7) on multi-hop transport > http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor31 > seems most debatable; specifically, a model of origniating administrative > domain, all-to-all, receiving administrative domain seems more realistic Whilst I think you're right I shied away from designing any kind of solution, or from making any random assumption about what anyone might want to actually do (If only I could work out how to get someone to pay me to do that!) in the interests of impartiality. I also wanted to weed out proposals that don't permit even local hops. > (2.3.5) avoid centralized solutions > http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor29 > this, also a SHOULD NOT, seems like it would be difficult. Centralization > of things like reputation server registration seems inescapable, just like > central administration of top-level DNS. I wanted to make this a MUST NOT, but I thought that I was probably being too harsh. I think there are problems that can come with centralised resources or central control and want to discourage people from specifying them without clear justification. That and because it will discourage people who think they can set themselves up as the operator to gain influence or money. > > (2.3.3) Don't re-invent identity and trust models > http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor27 > this section could be made stronger by listing the invented ones > that are not to be re-invented. I am not aware of a working multi-faceted > reputation server infrastructure, for instance, beyond the profusion of RBLs. Yeah, reading that section through again now I'm sober ;-) it seems a bit harsh, "don't re-invent" implies that you can invent something, because you can't re-invent something which hasn't been invented at all, but the text seems to claim that everything we'll ever need has already been invented. It's not my place to say so. Perhaps listing the inventions which needn't be re-invented would add clarity. It might also reveal my ignorance, so feel free to list stuff. > All in all, after reading the document, it seems to me a nice draft Thank you. >and > would be coupled well with a BCP document enumerating existing > solutions that answer various parts, or an index of BCPs, or even have > links to the BCPs embedded in it. I refined it by evaluating current practices & products, and past proposals (good and bad) against the conditions and fiddled it to fit my subjective opinion of them, and what I understood to be the consensus of this list. So I think this would be a possibility, and not too controversial either. OTOH It would risk becoming out of date very quickly if the people responsible for products which were listed as wholly or partially non-compliant decided that compliance was important for them, so someone would have to take ownership of either maintaining a list or publishing a regular summary of current good practice. > > Towards a centralized IP-based reputation service: > > If the end result becomes some kind of TOS enforcement standard; that would > be cool; Cool certainly but perhaps some way off yet. d. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Jan 20 16:01:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8NG0-0005Yi-O2; Sat, 20 Jan 2007 15:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8NF8-0005Gy-FL for asrg@ietf.org; Sat, 20 Jan 2007 15:55:18 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8N7J-0001hs-KR for asrg@ietf.org; Sat, 20 Jan 2007 15:47:14 -0500 Received: by nf-out-0910.google.com with SMTP id l36so863514nfa for ; Sat, 20 Jan 2007 12:47:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lXmVT5mTJX+m422vR71FHyjpNrJArfP+jbjVBP5kKOM0UcLGOTACNp+2+Xc7VN/6xLPg4n1vmxDSUAJPnxC9ary9Gtwpekmre4SdBY9lw/yXx8CaqFbLraVXxsHMxkczi1vTD4cm2C2ATdGKrp5d6R5CkIuOsx8MfRsM3gSDaks= Received: by 10.82.113.6 with SMTP id l6mr3202060buc.1169326032072; Sat, 20 Jan 2007 12:47:12 -0800 (PST) Received: by 10.78.185.5 with HTTP; Sat, 20 Jan 2007 12:47:12 -0800 (PST) Message-ID: <5ec229170701201247g111dac82md3311f9a76505ede@mail.gmail.com> Date: Sat, 20 Jan 2007 20:47:12 +0000 From: "Danny Angus" To: "David Nicol" , asrg@ietf.org Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <934f64a20701191038h76a9a123xd4563acd77746e56@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701181316t7a1e6b39r868320254cbc4be2@mail.gmail.com> <5ec229170701190144h5020b020tb652e13cc8ad09df@mail.gmail.com> <5ec229170701190147sc483849qffa2c1ec4d37e399@mail.gmail.com> <934f64a20701191038h76a9a123xd4563acd77746e56@mail.gmail.com> X-Google-Sender-Auth: 178c3dd0d7a08914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/19/07, David Nicol wrote: > So what's to motivate the operators then? Operating a reputatble > reputation server service will require ongoing effort. Let me try to be clearer about this. I'm not stopping anyone from charging to people for any of the services they might choose to offer as part of the implementation of any technique. This para is about discouraging people from making proposals which enshrine a *single* *central* register, and that is because I think it would confer too much power, and might be proposed simply as a licence for the proposer to print money, never mind the practical constraints of setting it up and operating it. IMHO, and it *is* only my opinion, is that it should be possible and would be desirable to establish a technique which allowed multiple providers to co-exist, and those providers' services could either be used singly or combined without a mandated central authority. I said "SHOULD NOT", not "MUST NOT" because I accept that there may well be some proposed techniques which can make a valid and compelling case for a central authority. I can't think of one though. > Set up standards > for interoperability of reputation services and commercial reputation > services could appear, the reputation of the commercial services will > get determined in all the usual reputation determination sources -- > free press, word of mouth, etc. Fine yes, my thoughts exactly, yes. An open market place for services. The document intends to discourage the mandating of a single operator, and disallow the _mandating_ of commercial services. It doesn't _demand_ the provision of free services or the existence of competition. It does, however, attempt to permit them. I'd like to see proposals permit competition, collaboration and the co-existence of free and commercial services, this reflects the nature of the modern internet and current practice in the domain of spam. d. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 08:34:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zF9-0007W2-Tt; Mon, 22 Jan 2007 08:29:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zF8-0007VO-Ln for asrg@ietf.org; Mon, 22 Jan 2007 08:29:50 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8zF4-0002E5-Av for asrg@ietf.org; Mon, 22 Jan 2007 08:29:50 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0MDTb19016030 for ; Mon, 22 Jan 2007 08:29:39 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0MDTami016012; Mon, 22 Jan 2007 08:29:36 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0MDTanE012390; Mon, 22 Jan 2007 08:29:36 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0MDTYWa012387; Mon, 22 Jan 2007 08:29:34 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Mon, 22 Jan 2007 08:29:34 -0500 (EST) From: Daniel Feenberg To: Danny Angus Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> Message-ID: References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, 18 Jan 2007, Danny Angus wrote: > At: > http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.txt > > You will find a document which outlines an idea I've had for a while. > Please give me your comments on this list. > Comments: 1.1.1 I would resist making the definition of spam so receipient dependent. If every receipient gets to make his/her own definition, then it tends to prevent cooperative solutions from looking satisfactory, and the the purpose of the IETF is to facilitate cooperative solutions. For example, if spam has no objective definition, then each user must maintain their own DNSBL, or list of spamassassin regular expressions. I would have thought the purpose of this group was to suggest ways for MTA operators to cooperate to reduce spam - individual solutions don't require the IETF. There are also the cases to consider of ISPs who ignore messages to abuse - does that make the messages spam? I think we should stick with "unsolicited commercial email" as a workable spam definition. 2.2.1 Why the prohibition on the use of non-SMTP protocols? Many legitimate spam reduction techniques use DNS (DNSBLs, DKIM, SPF, etc). While all these techniques have disadvantages, the primary problems do not arise for the use of an alternate protocol for communication of anti-spam information. Or perhaps the section means only that the mail itself should not use another protocol. Then it should say so. I hear so many complaints about the overloading of DNS with other tasks, perhaps I am reading them into this section. Would adding another keyword to the SMTP protocol be allowed? 2.3.1 is worthy of being singled out, however, since so many propsoed solutions fail to allow strangers to communicate, and that is pretty much the chief objection to the majority of proposed techniques. There is a surprising omissions - No mention of the superiority of rejection during the SMTP processing over discarding or delivering to a spam folder. Or did I miss it somewhere? I worry that the point of the draft is to outlaw all spam reduction techniques other than individually created and controlled content analysis. At the very least users need to be able to cooperate or to purchase anti-spam services from unrelated organizations, and without common definitions and inexpensive communication of results, this will be made unnecessarily difficult. Would the author list some common techniques are say if they meet these standards, and if not, where they fail? Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 12:04:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92ZC-0008UU-PG; Mon, 22 Jan 2007 12:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92ZB-0008UO-Co for asrg@ietf.org; Mon, 22 Jan 2007 12:02:45 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92ZA-0003So-3c for asrg@ietf.org; Mon, 22 Jan 2007 12:02:45 -0500 Received: by an-out-0708.google.com with SMTP id d30so433835and for ; Mon, 22 Jan 2007 09:02:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MnHFS0grx5ID+SxlvKWYJDqCu6qjvC87zwSzl9oyK78s1NbSkxRVweJKWKaInv/9ieUKZvd+qjAwbVG6+Uv0mbdNvot1wp7TE+O+iqzjOKOU82Fy3hYdIfS9REU0fwDLjpINQAnoNaSlBoZgN6QK6nFFlrCJ4/IGU1BkAx1IvFE= Received: by 10.49.54.3 with SMTP id g3mr7010631nfk.1169485342904; Mon, 22 Jan 2007 09:02:22 -0800 (PST) Received: by 10.78.23.19 with HTTP; Mon, 22 Jan 2007 09:02:22 -0800 (PST) Message-ID: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> Date: Mon, 22 Jan 2007 11:02:22 -0600 From: "David Nicol" To: "Daniel Feenberg" Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/22/07, Daniel Feenberg wrote: > Comments: Comments on comments: > 1.1.1 I would resist making the definition of spam so receipient > dependent. If every receipient gets to make his/her own definition, then > it tends to prevent cooperative solutions from looking satisfactory, and > the the purpose of the IETF is to facilitate cooperative solutions. For > example, if spam has no objective definition, then each user must maintain > their own DNSBL, or list of spamassassin regular expressions. I would have > thought the purpose of this group was to suggest ways for MTA operators to > cooperate to reduce spam - individual solutions don't require the IETF. > There are also the cases to consider of ISPs who ignore messages to abuse > - does that make the messages spam? I think we should stick with > "unsolicited commercial email" as a workable spam definition. the upside of using a very general definition is that it necessitates a many-sizes- to-fit-everyone system of solutions. > I hear so many complaints > about the overloading of DNS with other tasks in my opinion, DNS is perfect when you want a distributable cached database of information that does not change that often. Name to number mappings fit this, of course, but so do a lot of other kinds of information. I have seen suggestions dismissed as "requiring a trick DNS server" as if that requirement is some kind of unvaultable bar, which it is not. In the event that other data sets get served over DNS infrastructure with some popularity, some system administrators may need to revise their capacity planning documents for faster upgrading of local dns caching hardware. This is not a big deal either. In terms of (1) efficient network use and (2) in-place infrastructure, DNS is very good, and I see no reason not to use it when appropriate. > 2.3.1 is worthy of being singled out, however, since so many propsoed > solutions fail to allow strangers to communicate, and that is pretty much > the chief objection to the majority of proposed techniques. > > There is a surprising omissions - No mention of the superiority of > rejection during the SMTP processing over discarding or delivering to a > spam folder. Or did I miss it somewhere? I think that kind of detail is deliberately left out of the document which is designed to live at a high level immune from implementation details. > I worry that the point of the draft is to outlaw all spam reduction > techniques other than individually created and controlled content > analysis. At the very least users need to be able to cooperate or to > purchase anti-spam services from unrelated organizations, and without > common definitions and inexpensive communication of results, this will be > made unnecessarily difficult. I read the document as a call for better (distributed) interoperable reputation services, possibly violating Zooko's triangle; ergo the document passes the "everyone who looks at it sees something different" test for "work of art." > Would the author list some common techniques are [and] say if they meet > these standards, and if not, where they fail? > > Daniel Feenberg My growing suspicion is that the end result of this committee is going to be current practices enumeration and reccomendations, with a bottom line of "it isn't broken." David Nicol _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 13:53:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H94Gj-0002Of-6d; Mon, 22 Jan 2007 13:51:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H94Gh-0002OU-K7 for asrg@ietf.org; Mon, 22 Jan 2007 13:51:47 -0500 Received: from cl-108.dub-01.ie.sixxs.net ([2001:770:100:6b::2] helo=dogma.boxhost.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H94Gf-0002aj-Gc for asrg@ietf.org; Mon, 22 Jan 2007 13:51:46 -0500 Received: from radish.jmason.org (localhost [127.0.0.1]) by dogma.boxhost.net (Postfix) with ESMTP id 7D5F3310013; Mon, 22 Jan 2007 18:51:29 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 2488F32CDD; Mon, 22 Jan 2007 18:51:26 +0000 (GMT) To: "David Nicol" Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> From: jm@jmason.org (Justin Mason) X-GPG-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 Date: Mon, 22 Jan 2007 18:51:26 +0000 Message-Id: <20070122185126.2488F32CDD@radish.jmason.org> X-Spam-Score: -2.8 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: asrg@ietf.org, Daniel Feenberg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "David Nicol" writes: >On 1/22/07, Daniel Feenberg wrote: >> Comments: > >Comments on comments: > >> 1.1.1 I would resist making the definition of spam so receipient >> dependent. If every receipient gets to make his/her own definition, then >> it tends to prevent cooperative solutions from looking satisfactory, and >> the the purpose of the IETF is to facilitate cooperative solutions. For >> example, if spam has no objective definition, then each user must maintain >> their own DNSBL, or list of spamassassin regular expressions. I would have >> thought the purpose of this group was to suggest ways for MTA operators to >> cooperate to reduce spam - individual solutions don't require the IETF. >> There are also the cases to consider of ISPs who ignore messages to abuse >> - does that make the messages spam? I think we should stick with >> "unsolicited commercial email" as a workable spam definition. > >the upside of using a very general definition is that it necessitates >a many-sizes- >to-fit-everyone system of solutions. For what it's worth, we in SpamAssassin use "unsolicited bulk email" as our definition -- religious spam, for example, is still spam in our book. Defining spam as "email the user does not want" means that you cannot safely filter spam, except with a user-trained classifier (Bayesian-style probabilistic classification for example). It's too subjective, and would outlaw DNSBL usage, as far as I can tell... >> I hear so many complaints >> about the overloading of DNS with other tasks > >in my opinion, DNS is perfect when you want a distributable cached database >of information that does not change that often. Name to number mappings >fit this, of course, but so do a lot of other kinds of information. I have seen >suggestions dismissed as "requiring a trick DNS server" as if that requirement >is some kind of unvaultable bar, which it is not. In the event that other >data sets get served over DNS infrastructure with some popularity, some system >administrators may need to revise their capacity planning documents for >faster upgrading of local dns caching hardware. This is not a big deal either. >In terms of (1) efficient network use and (2) in-place infrastructure, >DNS is very good, >and I see no reason not to use it when appropriate. > > >> 2.3.1 is worthy of being singled out, however, since so many propsoed >> solutions fail to allow strangers to communicate, and that is pretty much >> the chief objection to the majority of proposed techniques. >> >> There is a surprising omissions - No mention of the superiority of >> rejection during the SMTP processing over discarding or delivering to a >> spam folder. Or did I miss it somewhere? > >I think that kind of detail is deliberately left out of the document which >is designed to live at a high level immune from implementation details. > >> I worry that the point of the draft is to outlaw all spam reduction >> techniques other than individually created and controlled content >> analysis. At the very least users need to be able to cooperate or to >> purchase anti-spam services from unrelated organizations, and without >> common definitions and inexpensive communication of results, this will be >> made unnecessarily difficult. > >I read the document as a call for better (distributed) interoperable reputation >services, possibly violating Zooko's triangle; ergo the document passes the >"everyone who looks at it sees something different" test for "work of art." > >> Would the author list some common techniques are [and] say if they meet >> these standards, and if not, where they fail? >> >> Daniel Feenberg > >My growing suspicion is that the end result of this committee is going to >be current practices enumeration and reccomendations, with a bottom line >of "it isn't broken." > >David Nicol --j. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 15:07:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95Q7-0006D8-7M; Mon, 22 Jan 2007 15:05:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95Q6-0006Cv-9K for asrg@ietf.org; Mon, 22 Jan 2007 15:05:34 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95Q3-0006Vq-0p for asrg@ietf.org; Mon, 22 Jan 2007 15:05:34 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1H95Pz-0003n4-00; Mon, 22 Jan 2007 20:05:27 +0000 To: jm@jmason.org, "David Nicol" From: Tony Finch Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <20070122185126.2488F32CDD@radish.jmason.org> References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> Message-Id: Date: Mon, 22 Jan 2007 20:05:27 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: asrg@ietf.org, Daniel Feenberg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org jm@jmason.org (Justin Mason) wrote: > >Defining spam as "email the user does not want" means that you cannot >safely filter spam, except with a user-trained classifier (Bayesian-style >probabilistic classification for example). It's too >subjective, and would outlaw DNSBL usage, as far as I can tell... The unwanted email can be unwanted according to a site-wide policy, too, a bit like the concept of the corporate legal person. Tony. -- f.a.n.finch http://dotat.at/ CROMARTY: NORTHERLY 6 OR 7, BACKING WESTERLY LATER. ROUGH OR VERY ROUGH. WINTRY SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 17:43:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97qm-00088M-KY; Mon, 22 Jan 2007 17:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97ql-000874-Om for asrg@ietf.org; Mon, 22 Jan 2007 17:41:15 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H97qk-0006G1-D8 for asrg@ietf.org; Mon, 22 Jan 2007 17:41:15 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0MMf5jN006055 for ; Mon, 22 Jan 2007 17:41:09 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0MMf5UI006033; Mon, 22 Jan 2007 17:41:05 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0MMf5nE011653; Mon, 22 Jan 2007 17:41:05 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0MMf0LC011648; Mon, 22 Jan 2007 17:41:00 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Mon, 22 Jan 2007 17:41:00 -0500 (EST) From: Daniel Feenberg To: David Nicol Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> Message-ID: References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 22 Jan 2007, David Nicol wrote: > On 1/22/07, Daniel Feenberg wrote: >> Comments: > > Comments on comments: > >> 1.1.1 I would resist making the definition of spam so receipient >> dependent. If every receipient gets to make his/her own definition, then >> it tends to prevent cooperative solutions from looking satisfactory, and >> the the purpose of the IETF is to facilitate cooperative solutions. For >> example, if spam has no objective definition, then each user must maintain >> their own DNSBL, or list of spamassassin regular expressions. I would have >> thought the purpose of this group was to suggest ways for MTA operators to >> cooperate to reduce spam - individual solutions don't require the IETF. >> There are also the cases to consider of ISPs who ignore messages to abuse >> - does that make the messages spam? I think we should stick with >> "unsolicited commercial email" as a workable spam definition. > > the upside of using a very general definition is that it necessitates > a many-sizes- > to-fit-everyone system of solutions. > I had a further thought. Defining spam only as unwanted mail will be a problem for anti-spam activities operating spam traps. By definition the mail received in a spam trap is "wanted" - the purpose of the trap is to learn about the sources of unsolicited commercial email, and incoming mail helps it achieve that purpose. The fact that it is wanted by the trap doesn't make it not spam, spam is unsolicited, not necessarily unwanted. But if the sender can claim that the mail in the trap doesn't meet agreed industry definitions of spam, then the sender can use the RFC to challange the use of those messages as evidence of spamming. Furthermore, since the spammer can hardly be expected to know the mental state of the receipient, it effectively relieves him of any responsibility for spamming at all. While I realize that legal challanges to spamming have been isolated, that is no reason to put such an obstacle in their path. For this and other reasons, I think it very mischevious to change to a personalized definition of spam in a document proposed for offical status. Dan Feenberg ... > > David Nicol > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 17:51:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H980t-00031E-Ew; Mon, 22 Jan 2007 17:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H980r-000319-HX for asrg@ietf.org; Mon, 22 Jan 2007 17:51:41 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H980p-0001Cx-HH for asrg@ietf.org; Mon, 22 Jan 2007 17:51:40 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0MMpYiK009710 for ; Mon, 22 Jan 2007 17:51:35 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0MMpYHP009688; Mon, 22 Jan 2007 17:51:34 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0MMpYnE012799; Mon, 22 Jan 2007 17:51:34 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0MMpTaj012796; Mon, 22 Jan 2007 17:51:34 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Mon, 22 Jan 2007 17:51:29 -0500 (EST) From: Daniel Feenberg To: Justin Mason Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <20070122185126.2488F32CDD@radish.jmason.org> Message-ID: References: <20070122185126.2488F32CDD@radish.jmason.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 22 Jan 2007, Justin Mason wrote: > > "David Nicol" writes: >> On 1/22/07, Daniel Feenberg wrote: >>> Comments: >> >> Comments on comments: >> >>> 1.1.1 I would resist making the definition of spam so receipient >>> dependent. If every receipient gets to make his/her own definition, then >>> it tends to prevent cooperative solutions from looking satisfactory, and >>> the the purpose of the IETF is to facilitate cooperative solutions. For >>> example, if spam has no objective definition, then each user must maintain >>> their own DNSBL, or list of spamassassin regular expressions. I would have >>> thought the purpose of this group was to suggest ways for MTA operators to >>> cooperate to reduce spam - individual solutions don't require the IETF. >>> There are also the cases to consider of ISPs who ignore messages to abuse >>> - does that make the messages spam? I think we should stick with >>> "unsolicited commercial email" as a workable spam definition. >> >> the upside of using a very general definition is that it necessitates >> a many-sizes- >> to-fit-everyone system of solutions. > > For what it's worth, we in SpamAssassin use "unsolicited bulk email" as > our definition -- religious spam, for example, is still spam in our book. I'll accept that as an improvement over "unsolicited commercial email". Daniel Feenberg > > Defining spam as "email the user does not want" means that you cannot > safely filter spam, except with a user-trained classifier (Bayesian-style > probabilistic classification for example). It's too > subjective, and would outlaw DNSBL usage, as far as I can tell... > >>> I hear so many complaints >>> about the overloading of DNS with other tasks >> >> in my opinion, DNS is perfect when you want a distributable cached database >> of information that does not change that often. Name to number mappings >> fit this, of course, but so do a lot of other kinds of information. I have seen >> suggestions dismissed as "requiring a trick DNS server" as if that requirement >> is some kind of unvaultable bar, which it is not. In the event that other >> data sets get served over DNS infrastructure with some popularity, some system >> administrators may need to revise their capacity planning documents for >> faster upgrading of local dns caching hardware. This is not a big deal either. >> In terms of (1) efficient network use and (2) in-place infrastructure, >> DNS is very good, >> and I see no reason not to use it when appropriate. >> >> >>> 2.3.1 is worthy of being singled out, however, since so many propsoed >>> solutions fail to allow strangers to communicate, and that is pretty much >>> the chief objection to the majority of proposed techniques. >>> >>> There is a surprising omissions - No mention of the superiority of >>> rejection during the SMTP processing over discarding or delivering to a >>> spam folder. Or did I miss it somewhere? >> >> I think that kind of detail is deliberately left out of the document which >> is designed to live at a high level immune from implementation details. >> >>> I worry that the point of the draft is to outlaw all spam reduction >>> techniques other than individually created and controlled content >>> analysis. At the very least users need to be able to cooperate or to >>> purchase anti-spam services from unrelated organizations, and without >>> common definitions and inexpensive communication of results, this will be >>> made unnecessarily difficult. >> >> I read the document as a call for better (distributed) interoperable reputation >> services, possibly violating Zooko's triangle; ergo the document passes the >> "everyone who looks at it sees something different" test for "work of art." >> >>> Would the author list some common techniques are [and] say if they meet >>> these standards, and if not, where they fail? >>> >>> Daniel Feenberg >> >> My growing suspicion is that the end result of this committee is going to >> be current practices enumeration and reccomendations, with a bottom line >> of "it isn't broken." >> >> David Nicol > > --j. > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 17:59:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H988U-0007VR-EB; Mon, 22 Jan 2007 17:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H988T-0007VL-7A for asrg@ietf.org; Mon, 22 Jan 2007 17:59:33 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H988Q-0003xt-VF for asrg@ietf.org; Mon, 22 Jan 2007 17:59:33 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1H988P-0007Vh-00; Mon, 22 Jan 2007 22:59:29 +0000 To: feenberg@nber.org, David Nicol From: Tony Finch Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> Message-Id: Date: Mon, 22 Jan 2007 22:59:29 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Daniel Feenberg wrote: > >I had a further thought. Defining spam only as unwanted mail will be a >problem for anti-spam activities operating spam traps. By definition the >mail received in a spam trap is "wanted" - the purpose of the trap is to >learn about the sources of unsolicited commercial email, and incoming mail >helps it achieve that purpose. Actually, what you want is no email to hit the spam trap, because that would indicate that the spammers have stopped. Also, spam is not necessarily commercial so don't call it "UCE" unless the C stands for "criminal". Tony. -- f.a.n.finch http://dotat.at/ BAILEY: NORTHWESTERLY 5 INCREASING 6 TO GALE 8. MODERATE OR ROUGH INCREASING VERY ROUGH. SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 18:24:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98WC-0002KR-5J; Mon, 22 Jan 2007 18:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98WA-0002KM-PH for asrg@ietf.org; Mon, 22 Jan 2007 18:24:02 -0500 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H98W9-0001lz-J7 for asrg@ietf.org; Mon, 22 Jan 2007 18:24:02 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 447EE13A846 for ; Mon, 22 Jan 2007 18:23:56 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l0MNNuV27993; Mon, 22 Jan 2007 18:23:56 -0500 (EST) Date: Mon, 22 Jan 2007 18:23:56 -0500 (EST) Message-Id: <200701222323.l0MNNuV27993@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (message from Daniel Feenberg on Mon, 22 Jan 2007 17:41:00 -0500 (EST)) Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Daniel Feenberg wrote: > I had a further thought. Defining spam only as unwanted mail will be > a problem for anti-spam activities operating spam traps. By > definition the mail received in a spam trap is "wanted" - the > purpose of the trap is to learn about the sources of unsolicited > commercial email, and incoming mail helps it achieve that purpose. No, it isn't. I don't want any mail to be sent to . It gets sent there despite my wishes, so I'm forced to take the effort to blackhole the senders. I'd be happier if no such mail were ever sent. In any case, somebody else claiming that _I_ want something would be invited to demonstrate to a court just how well his telepathy works. But I agree with using "unsolicited" as the key characteristic. Solicitation is based on externally-overservable actions. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 19:13:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99GZ-0006dE-07; Mon, 22 Jan 2007 19:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99GX-0006d5-Br for asrg@ietf.org; Mon, 22 Jan 2007 19:11:57 -0500 Received: from egress3.webmaillogin.com ([216.40.36.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H99GW-0005DV-TY for asrg@ietf.org; Mon, 22 Jan 2007 19:11:57 -0500 Received: by egress3.webmaillogin.com (egress3.webmaillogin.com, from userid 1006) id 4EDFB5B464B; Mon, 22 Jan 2007 19:11:49 -0500 (EST) Received: from webmaillogin.com (fr5.webmaillogin.com [216.40.35.69]) by egress3.webmaillogin.com (egress3.webmaillogin.com) with ESMTP id EC0065B47FB for ; Mon, 22 Jan 2007 19:11:40 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk2.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 60853728 for asrg@ietf.org; Mon, 22 Jan 2007 19:05:50 -0500 From: To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Mon, 22 Jan 2007 18:05:50 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [Asrg] Re: bounces, and anit-spam principles X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Perhaps it's a good time to step back again and take a=20 look at some principles that hopefully we can recognize=20 (and some of these seemed controversial when I first=20 proposed them, but hopefully by now my reasoning is a=20 little more apparent): 1. Spam is any mail the RECIPIENT does not want,=20 regardless of how much the sender wants to send it. 2. Accordingly, the definition of what they do and do not=20 want MUST be such that the RECIPIENT defines it... not the=20 IETF, not the sender's ISP, not the recipient's ISP, nor=20 some governmental body, nor anybody else. 3. Systems which rely on the "reputation" or=20 "certifications" of the (supposed) sender are not very=20 helpful, because a user's machine can be compromised by a=20 worm or virus, or because a purported sender's credentials=20 can be forged. 4. Spammers, regardless of what they claim about not=20 wanting to send unwanted mails, or only sending to=20 "opt-in" addresses, specifically do everything in their=20 power to bypass filters set up by recipients to block=20 mails just like what the spammer wants to send. 5. Most recipients do not really want to have their=20 machine turned into a spambot zombie. 6. Antispam/antiworm approaches based on traditional=20 signatures are not effective in the initial hours of an=20 infection wave, when all worms and viruses are at their=20 most prolific and most dangerous. 7. (And this point is particularly timely given the=20 current discussion here).... it is almost NEVER really=20 helpful to bounce an incoming message which contained a=20 worm or a virus, or even which contains spam, unless you=20 can determine (how??) who the legitimate original true=20 sender really was. For example, one incredibly annoying thing that happens to=20 me every month or so is that Yahoo will stop delivering my=20 Yahooogroups list mails to me, because they got back a=20 "hard bounce" message implicating one of my E-mail=20 addresses. Almost invariably, this hard bounce message=20 got sent out by some idiot mail software which found a=20 worm or virus in an incoming message (and NONE of these=20 infected mails have actually been sent out by ME, of=20 course) and the idiot software decided to send the bounce=20 back to some third party (in my case, Yahoo), which (also=20 not-cleverly) decides that since they got back a=20 (completely bogus!) hard bounce message (and to a message=20 that Yahoo didn't really send, either), they'd better not=20 try to send any more mail to me. :-( The result is that=20 I typically lose anything from a half day's mail to as=20 much as several days' mail from the various Yahoogroups=20 I'm subscribed to. :-(( Whether an E-mail contains spam, or a virus, or just about=20 ANYTHING, the ONLY time it should be rejected is during=20 the time of the original SMTP session when it is coming=20 in... UNLESS the entity generating the bounce can=20 (somehow) be ABSOLUTELY CERTAIN of who the guilty party=20 REALLY is. It's especially outrageous when a bounce message goes out=20 specifying a contained virus which is KNOWN to forge a=20 counterfeit return address...! What is it supposed to=20 accomplish to tell someone, whose system is NOT infected,=20 that some random one else's system is? And then, worse,=20 to couch that as a "hard" bounce, suggesting that no more=20 mail should be sent to the address in question?? (When,=20 in fact, a legitimate mail would presumably sail right=20 through...) Critical aspects of solving the spam problem require that=20 we deny spammers and abusers the techniques they have come=20 to so effectively use to bypass effective content=20 filtering. That includes HTML, text-as-image, ActiveX,=20 scripting (Java etc), and things of that sort. Therefore, as an initial default (which would apply to=20 "unfamiliar" senders) I still insist that mail from=20 unaccepted senders be passed into my Inbox ONLY IF it=20 contains NO HTML, and NO attachments, and does not exceed=20 some specified size (10K, 50K, 100K, 200K, whatever the=20 recipient decides to set as a threshold). Assuming the=20 mail message gets through that initial qualifying=20 gauntlet, then Spam Assassin or whatever other antispam=20 content filter should be able to decide whether it looks=20 reasonable for delivery or not. (And as an additional comment, based on a statement in=20 today's ASRG digest, let me point out that brain-damaged=20 "regular expressions" type pattern matching is IMHO=20 nowhere close to adequate for this kind of good textual=20 spam recognition, and something closer to SNOBOL4 or=20 SPITBOL-type pattern matching is far more appropriate and=20 useful). The (initial filtering!) approach that I believe will work=20 is based on this fine-grained "permissions list" (with a=20 ruleset adjustable on a per-sender basis) which combined=20 with a suitable default behavior denies in one fell swoop=20 nearly all the tricks and subterfuges that spammers use to=20 evade and deceive content filters. All of these DNS-based things based on "sender reputation"=20 and the like are doomed to failure because a well-reputed=20 sender CAN be infected and caused to send out spam. And=20 just because they DO, doesn't mean that the LEGITIMATE=20 mail they might still be sending out ought to now be=20 t-canned. It is FAR more helpful to allow recipient machines to=20 identify that the mail message supposedly coming from a=20 legitimate and familiar sender INDEED 'LOOKS' THE WAY that=20 E-mail from that particular sender is EXPECTED AND ALLOWED=20 to look. And meanwhile, not allowing (by default) incoming E-mail=20 that contains HTML, scripting, attachments and the like=20 unless they are from someone that we TRUST to send such=20 stuff (and have whitelisted) will virtually eliminate=20 E-mail as a transmission vector for worms and viruses. We keep dancing around with these elaborate technical=20 schemes that folks keep claiming will solve (parts of) the=20 problem, but which will predictably not solve it very much=20 or very well. Meanwhile, relatively straightforward=20 approaches (as I'm proposing), and in conjunction with=20 good content filtering, will go a long way towards solving=20 the REAL problems, and still allow receiving (simple,=20 safe) mail from previously unknown "first contact"=20 senders. AMD take a big chunk out of worms and viruses=20 (today's AND tomorrow's!) at the same time. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 19:52:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99tF-0007ma-A7; Mon, 22 Jan 2007 19:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99tD-0007ib-Ko for asrg@ietf.org; Mon, 22 Jan 2007 19:51:55 -0500 Received: from goliath.word-to-the-wise.com ([208.187.80.130] helo=m.wordtothewise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H99pk-00047T-Ns for asrg@ietf.org; Mon, 22 Jan 2007 19:48:22 -0500 Received: from [10.3.2.25] (184.word-to-the-wise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by m.wordtothewise.com (Postfix) with ESMTP id 2F1C71001C for ; Mon, 22 Jan 2007 16:48:13 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Mon, 22 Jan 2007 16:48:08 -0800 To: asrg@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 4:05 PM, wrote: > > Perhaps it's a good time to step back again and take a look at some > principles that hopefully we can recognize (and some of these > seemed controversial when I first proposed them, but hopefully by > now my reasoning is a little more apparent): > > 1. Spam is any mail the RECIPIENT does not want, regardless of how > much the sender wants to send it. Recipients often decide they don't want mail that they've explicitly asked to receive. That does not make it "spam" by any reasonable definition. > 2. Accordingly, the definition of what they do and do not want > MUST be such that the RECIPIENT defines it... not the IETF, not the > sender's ISP, not the recipient's ISP, nor some governmental body, > nor anybody else. If spam is defined solely by the recipient then there is no reasonable standard, and no possible way for a sender to comply with it. So any discussion about "spam" becomes entirely irrelevant. > 3. Systems which rely on the "reputation" or "certifications" of > the (supposed) sender are not very helpful, because a user's > machine can be compromised by a worm or virus, or because a > purported sender's credentials can be forged. Unless implemented pretty badly, credentials cannot realistically be forged. Even if a senders machine is compromised by a virus and is sending out mail with their credentials; it's still them sending out the mail, and those credentials prove the fact - making the credentials continue to be useful even though the mail is not mail you'd really want sent. > 4. Spammers, regardless of what they claim about not wanting to > send unwanted mails, or only sending to "opt-in" addresses, > specifically do everything in their power to bypass filters set up > by recipients to block mails just like what the spammer wants to send. Everybody who sends email in any sort of volume, spammers or not, does everything in their power to bypass filters set up by recipients. That includes senders of squeaky clean closed-loop opt-in with a cherry on top email. It includes ISP postmaster groups, whose smarthosts are used for huge amounts of 1:1 email. > 5. Most recipients do not really want to have their machine turned > into a spambot zombie. Empirical evidence suggests otherwise. Certainly most users are not inclined to use the free security products bundled with their PC or ISP account, let alone spend $20 on a hardware firewall of some sort. At best they're indifferent about it, until they're disconnected by their ISP, and then they're mad at the ISP. > 6. Antispam/antiworm approaches based on traditional signatures > are not effective in the initial hours of an infection wave, when > all worms and viruses are at their most prolific and most dangerous. Not entirely true, despite the empirical evidence for it. Antivirus vendors make their money out of subscriptions, so if their products were to detect new viruses even if the user hadn't paid for a subscription there'd be no reason at all for the users to pay for the subscription, and so no revenue for the antivirus vendor. Because of that they tend implement their products so as to be very specific to each new virus, forcing users to pay for subscriptions, rather than implementing more general solutions. (Personally I've found that a few signatures based on base64 encoded versions of the first few bytes of various win32 executable formats vastly more effective than typical windows antivirus products in preventing infectious payloads arriving via email.) > 7. (And this point is particularly timely given the current > discussion here).... it is almost NEVER really helpful to bounce an > incoming message which contained a worm or a virus, or even which > contains spam, unless you can determine (how??) who the legitimate > original true sender really was. Yup. But again we're back to the whole commercial product problem. Rejection messages sent by antivirus software are both advertising material for the software and reassurance to the purchaser (and subscriber) to the software that it's doing something valuable for them. > All of these DNS-based things based on "sender reputation" and the > like are doomed to failure because a well-reputed sender CAN be > infected and caused to send out spam. No, they can't, for many reasons. One of those is logical - if they send out much spam, they'll no longer have a good reputation. And operationally, legitimate senders do not send email from systems that can be infected by whatever virus-du-jour is going around. The only place this problem can really appear is when the legitimate sender is actually smarthosting for a large consumer userbase. Identifying the sender reliably is the missing link in the current system. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 20:30:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ATF-0007XX-3d; Mon, 22 Jan 2007 20:29:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ATD-0007XM-Vu for asrg@ietf.org; Mon, 22 Jan 2007 20:29:07 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ATA-0003Jo-Js for asrg@ietf.org; Mon, 22 Jan 2007 20:29:07 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0N1T2v27260 for ; Mon, 22 Jan 2007 20:29:02 -0500 (EST) Received: from [47.9.16.68] ([47.9.16.68] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 20:28:32 -0500 Message-ID: <45B564B8.6090306@nortel.com> Date: Mon, 22 Jan 2007 20:28:24 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> In-Reply-To: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 01:28:32.0827 (UTC) FILETIME=[CB7790B0:01C73E8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Nicol wrote: > On 1/22/07, Daniel Feenberg wrote: >> There is a surprising omissions - No mention of the superiority of >> rejection during the SMTP processing over discarding or delivering to a >> spam folder. Or did I miss it somewhere? > > I think that kind of detail is deliberately left out of the document which > is designed to live at a high level immune from implementation details. Avoiding blowback is not a mere implementation detail. Yes, it can be inferred by the remarks about "not impacting others", but given the problem that it does represent in practise suggests that something more explicit needs to be said. At least to the point of "don't bounce spam and viruses". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbVkuJ3FmCyJjHfhAQJg7gQAx81uXMTZCImk8U2KN+4v3ClcQ/lqb4ac O/kDqZBFrjqlozwUZsRzwJ2biBfzdYOJTl222CPzls5S0vHI3HNoaMLBkOSgwCJ7 BEkFBdpyUhaaANnuqy11X2216JK1XuVOwRsD8MwqBssNmXejW3mCxq7UEyDip6YF H2jUGzTV1OA= =Zs7Y -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 21:00:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ax9-00042J-Vo; Mon, 22 Jan 2007 21:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ax8-0003yy-NF for asrg@ietf.org; Mon, 22 Jan 2007 21:00:02 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ax7-0000AB-GS for asrg@ietf.org; Mon, 22 Jan 2007 21:00:02 -0500 Received: from mpls-pop-07.inet.qwest.net (mpls-pop-07.inet.qwest.net [63.231.195.7]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id 2612C53BD08 for ; Tue, 23 Jan 2007 02:00:01 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-07.inet.qwest.net with SMTP; 23 Jan 2007 02:00:01 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Mon, 22 Jan 2007 18:59:59 -0700 To: ASRG list X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 5:48 PM, Steve Atkins wrote: > Identifying the sender reliably is the missing link in the current > system. The missing link is really 2 different problems depending on which side of the link you are on. The receiver can't identify the actual sender and the smarthost can't reliably identify the email as abusive. Providing direct feedback when email is abusive (such as when unsolicited email hits a spamtrap) could bridge the gap and permit the smarthost to take appropriate action to stop the abuse. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 21:10:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9B6c-0000jr-Qo; Mon, 22 Jan 2007 21:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9B6b-0000jm-KC for asrg@ietf.org; Mon, 22 Jan 2007 21:09:49 -0500 Received: from goliath.word-to-the-wise.com ([208.187.80.130] helo=m.wordtothewise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9B6Y-0001rB-Bi for asrg@ietf.org; Mon, 22 Jan 2007 21:09:49 -0500 Received: from [10.3.2.25] (184.word-to-the-wise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by m.wordtothewise.com (Postfix) with ESMTP id D255F10016 for ; Mon, 22 Jan 2007 18:09:40 -0800 (PST) In-Reply-To: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Mon, 22 Jan 2007 18:09:36 -0800 To: ASRG list X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 5:59 PM, Dan Oetting wrote: > > On Jan 22, 2007, at 5:48 PM, Steve Atkins wrote: > >> Identifying the sender reliably is the missing link in the current >> system. > > The missing link is really 2 different problems depending on which > side of the link you are on. The receiver can't identify the actual > sender and the smarthost can't reliably identify the email as > abusive. Providing direct feedback when email is abusive (such as > when unsolicited email hits a spamtrap) could bridge the gap and > permit the smarthost to take appropriate action to stop the abuse. DKIM and ARF between them provide all the protocol-level solution needed for that. DKIM was the missing link I was thinking of. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 21:10:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9B7H-0000xH-9a; Mon, 22 Jan 2007 21:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9B7G-0000xC-Ur for asrg@ietf.org; Mon, 22 Jan 2007 21:10:30 -0500 Received: from goliath.word-to-the-wise.com ([208.187.80.130] helo=m.wordtothewise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9B7E-00027Y-Me for asrg@ietf.org; Mon, 22 Jan 2007 21:10:30 -0500 Received: from [10.3.2.25] (184.word-to-the-wise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by m.wordtothewise.com (Postfix) with ESMTP id 63D2E10016 for ; Mon, 22 Jan 2007 18:10:28 -0800 (PST) In-Reply-To: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Mon, 22 Jan 2007 18:09:36 -0800 To: ASRG list X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 5:59 PM, Dan Oetting wrote: > > On Jan 22, 2007, at 5:48 PM, Steve Atkins wrote: > >> Identifying the sender reliably is the missing link in the current >> system. > > The missing link is really 2 different problems depending on which > side of the link you are on. The receiver can't identify the actual > sender and the smarthost can't reliably identify the email as > abusive. Providing direct feedback when email is abusive (such as > when unsolicited email hits a spamtrap) could bridge the gap and > permit the smarthost to take appropriate action to stop the abuse. DKIM and ARF between them provide all the protocol-level solution needed for that. DKIM was the missing link I was thinking of. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 21:38:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9BWh-0003dV-2d; Mon, 22 Jan 2007 21:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9BWf-0003dN-1C for asrg@ietf.org; Mon, 22 Jan 2007 21:36:45 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9BWa-0006qB-P9 for asrg@ietf.org; Mon, 22 Jan 2007 21:36:45 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1H9BWa-0002aE-00; Tue, 23 Jan 2007 02:36:40 +0000 To: gep2@terabites.com From: Tony Finch Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: References: Message-Id: Date: Tue, 23 Jan 2007 02:36:40 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org wrote: > >2. Accordingly, the definition of what they do and do not >want MUST be such that the RECIPIENT defines it... not the >IETF, not the sender's ISP, not the recipient's ISP, nor >some governmental body, nor anybody else. Most users prefer to delegate this job. It's 10x more efficient to do so. >3. Systems which rely on the "reputation" or >"certifications" of the (supposed) sender are not very >helpful, because a user's machine can be compromised by a >worm or virus, or because a purported sender's credentials >can be forged. I'm quite happy with reputation systems that block email in these situations, because you can't expect to let your machine be compromised without consequences. They also deal with the vast majority of spam very cheaply. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN HEBRIDES: NORTH BACKING NORTHWEST 5 OR 6, OCCASIONALLY 7 LATER. ROUGH INCREASING VERY ROUGH. WINTRY SHOWERS OR RAIN. MODERATE OR GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 21:51:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Bkf-0001sh-TT; Mon, 22 Jan 2007 21:51:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Bke-0001sG-OJ for asrg@ietf.org; Mon, 22 Jan 2007 21:51:12 -0500 Received: from mpls-qmqp-05.inet.qwest.net ([63.231.195.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Bkc-0002CQ-GV for asrg@ietf.org; Mon, 22 Jan 2007 21:51:12 -0500 Received: from mpls-pop-10.inet.qwest.net (mpls-pop-10.inet.qwest.net [63.231.195.10]) by mpls-qmqp-05.inet.qwest.net (Postfix) with QMQP id 1A11662D874; Tue, 23 Jan 2007 02:51:08 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-10.inet.qwest.net with SMTP; 23 Jan 2007 02:51:08 -0000 In-Reply-To: <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Mon, 22 Jan 2007 19:51:05 -0700 To: Steve Atkins X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 7:09 PM, Steve Atkins wrote: > > On Jan 22, 2007, at 5:59 PM, Dan Oetting wrote: > >> >> On Jan 22, 2007, at 5:48 PM, Steve Atkins wrote: >> >>> Identifying the sender reliably is the missing link in the >>> current system. >> >> The missing link is really 2 different problems depending on which >> side of the link you are on. The receiver can't identify the >> actual sender and the smarthost can't reliably identify the email >> as abusive. Providing direct feedback when email is abusive (such >> as when unsolicited email hits a spamtrap) could bridge the gap >> and permit the smarthost to take appropriate action to stop the >> abuse. > > DKIM and ARF between them provide all the protocol-level solution > needed for that. DKIM was the missing link I was thinking of. That works if you don't mind taking the long route. I was thinking of a more direct path of sending a specific response code in the SMTP transaction. A really smart smarthost might be able to then fix the problem before the site gets blacklisted. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 22 23:47:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DX0-0000lZ-V8; Mon, 22 Jan 2007 23:45:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DX0-0000hx-5V for asrg@ietf.org; Mon, 22 Jan 2007 23:45:14 -0500 Received: from egress2.webmaillogin.com ([216.40.36.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9DWy-0004rW-Pt for asrg@ietf.org; Mon, 22 Jan 2007 23:45:14 -0500 Received: by egress2.webmaillogin.com (egress2.webmaillogin.com, from userid 1005) id 1D32D24C49E; Mon, 22 Jan 2007 23:45:06 -0500 (EST) Received: from webmaillogin.com (fr3.webmaillogin.com [216.40.35.67]) by egress2.webmaillogin.com (egress2.webmaillogin.com) with ESMTP id 34E9B24C2D6; Mon, 22 Jan 2007 23:45:05 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk1.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61271956; Mon, 22 Jan 2007 23:45:04 -0500 From: Subject: Re: [Asrg] Re: bounces, and anit-spam principles To: Tony Finch X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Mon, 22 Jan 2007 22:45:04 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 23 Jan 2007 02:36:40 +0000 Tony Finch wrote: > wrote: >> >>2. Accordingly, the definition of what they do and do=20 >>not >>want MUST be such that the RECIPIENT defines it... not=20 >>the >>IETF, not the sender's ISP, not the recipient's ISP, nor >>some governmental body, nor anybody else. >=20 > Most users prefer to delegate this job. It's 10x more=20 >efficient > to do so. I have no idea where you get that statistic, but looks=20 sorta brown to me.... ;-) I would be happy to have someone else adjust some of my=20 spam filters for me, as long as the results are good, but=20 my experience with such things is that they simply aren't=20 as good as they need to be... to the point where I had to=20 simply turn some ISP-provided spam filters off (they were=20 more trouble than they were worth, and mis-categorized too=20 many messages). Another problem with centralized antispam filtering is=20 that spammers get good at tweaking their messages so they=20 manage to get through the widely used filters. It's far=20 harder to do that if individual recipients can set their=20 own message size limits, rejection criteria, and so forth.=20 And of course, finely grained whitelists on a=20 per-recipient/sender pair basis can really only be done by=20 the recipient, since the list of approved senders (and=20 what they are expected to be sending) probably won't be=20 the same for any two recipients. well-written software implementation can reduce the hassle=20 factor of maintaining such finely-grained whitelists to=20 (IMHO) very reasonable levels. >>3. Systems which rely on the "reputation" or >>"certifications" of the (supposed) sender are not very >>helpful, because a user's machine can be compromised by a >>worm or virus, or because a purported sender's=20 >>credentials >>can be forged. >=20 > I'm quite happy with reputation systems that block email > in these situations, because you can't expect to let=20 >your > machine be compromised without consequences.=20 OK, so let's say Aunt Matilda's system gets a virus on it,=20 and starts sending out spam (sooner or later, MOST=20 machines will be infected at least once...!) Now what?=20 Game over? Aunt Matilda never manages to succesfully=20 send another E-mail again as long as she lives? And what about the case where Aunt Matilda's system IS NOT=20 infected, never has been, but where her mail services is=20 impacted (as mine has been) by SOMEONE ELSE's machine=20 being infected, and forging HER return address on the=20 e-mails? (Rather like the bogus way that Yahoo disables=20 valid e-mail addresses for forged mail that OTEHR people=20 have sent?) Clearly SHE doesn't deserve those "consequences", and=20 since there is ABSOLUTELY NOTHING that she could possibly=20 do about that situation, there is ABSOLUTELY NOTHING to be=20 gained by sending "bounce" messages back to her, or=20 otherwise harassing her for something she has NO control=20 over. You're only multiplying the nasty consequences of=20 the spamming or worm infection. > They also=20 >deal > with the vast majority of spam very cheaply. "Cheaply" isn't necessarily "well". We've already=20 discussed how I might occasionally send an E-mail message=20 from an Internet cafe in a resort city, or for that matter=20 onboard a cruise ship. I will still want to use MY=20 personal E-mail address, even though it will not be being=20 sent out by anything remotely like the E-mail servers I=20 would use from my systems here at home. Blocking those=20 messages as "spam" just because they aren't being sent=20 through my habitual mail server (and I may not know in=20 advance whose server that Internet cafe is using) isn't=20 very helpful. We programmers have the saying that "things should be made=20 as simple as possible, BUT NO SIMPLER!" A cheap solution=20 that doesn't work (at all) for a significant number (even=20 though small, percentage wise) of legitimate users isn't a=20 viable or attractive solution, no matter how cheap it=20 might be for those cases where it works. > Tony. Gordon Peterson http://personal.terabites.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:09:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DuE-0004A8-TA; Tue, 23 Jan 2007 00:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DuD-00049t-UJ for asrg@ietf.org; Tue, 23 Jan 2007 00:09:13 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9DuC-0003qJ-Gn for asrg@ietf.org; Tue, 23 Jan 2007 00:09:13 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0N51Gt06229 for ; Tue, 23 Jan 2007 00:01:17 -0500 (EST) Received: from [47.9.16.68] ([47.9.16.68] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 00:08:59 -0500 Message-ID: <45B59867.1000002@nortel.com> Date: Tue, 23 Jan 2007 00:08:55 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 05:08:59.0524 (UTC) FILETIME=[97315C40:01C73EAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gep2@terabites.com wrote: > On Tue, 23 Jan 2007 02:36:40 +0000 > Tony Finch wrote: >> wrote: >>> >>> 2. Accordingly, the definition of what they do and do not >>> want MUST be such that the RECIPIENT defines it... not the >>> IETF, not the sender's ISP, not the recipient's ISP, nor >>> some governmental body, nor anybody else. >> >> Most users prefer to delegate this job. It's 10x more efficient >> to do so. > > I have no idea where you get that statistic, but looks sorta brown to > me.... ;-) > > I would be happy to have someone else adjust some of my spam filters for > me, as long as the results are good, but my experience with such things > is that they simply aren't as good as they need to be... to the point > where I had to simply turn some ISP-provided spam filters off (they were > more trouble than they were worth, and mis-categorized too many messages). > > Another problem with centralized antispam filtering is that spammers get > good at tweaking their messages so they manage to get through the widely > used filters. It's far harder to do that if individual recipients can > set their own message size limits, rejection criteria, and so forth. And > of course, finely grained whitelists on a per-recipient/sender pair > basis can really only be done by the recipient, since the list of > approved senders (and what they are expected to be sending) probably > won't be the same for any two recipients. You would be hard pressed to find _any_ real world environment beyond a trivial size where per-user filter tuning can even remotely approach the effectiveness of a good centralized filtering system. And furthermore, most users simply don't want to waste time tuning filters. They just want the spam to stop. Secondly, who said anything about centralized filtering having to use "widely used filters"? Personal filters are just as prone to do that, or not as prone, as centralized filters. And I can assure you, it's a lot easier getting past Thunderbird or Outlook filtering than our front ends. In non-trivial real world environments, the only way you'd get good filtering with a "recipient tweaks" model is if it was "block everybody not in my whitelist". Which is undesirable in many places. Not the least being that in many cases even: > well-written software implementation can reduce the hassle factor of > maintaining such finely-grained whitelists to (IMHO) very reasonable > levels. ain't easy. Because what are you whitelisting? From addresses? IPs? Which IPs? Sorry, while I appreciate the notion of not letting, say, government decide for me what spam is or isn't, users should be free to decide what filters they want to use. And that will almost always be provider-supplied. And secondly, while some people think a "corporate entity" simply stands in lieu of individual users in a corporate environment, it's not going to be construed that way in the real world. Sorry, nobody but my management gets to decide how we run our filters. >>> 3. Systems which rely on the "reputation" or >>> "certifications" of the (supposed) sender are not very >>> helpful, because a user's machine can be compromised by a >>> worm or virus, or because a purported sender's credentials >>> can be forged. >> >> I'm quite happy with reputation systems that block email >> in these situations, because you can't expect to let your >> machine be compromised without consequences. > > OK, so let's say Aunt Matilda's system gets a virus on it, and starts > sending out spam (sooner or later, MOST machines will be infected at > least once...!) Now what? Game over? Aunt Matilda never manages to > succesfully send another E-mail again as long as she lives? Many systems use timeouts for such detections. > And what about the case where Aunt Matilda's system IS NOT infected, > never has been, but where her mail services is impacted (as mine has > been) by SOMEONE ELSE's machine being infected, and forging HER return > address on the e-mails? Few filtering systems actually work that way. > (Rather like the bogus way that Yahoo disables > valid e-mail addresses for forged mail that OTEHR people have sent?) Are you _sure_ that's what you were seeing? That Yahoo conflates rejections not related at all to a given distribution list? _All_ of the ones I've seen is where yahoogroups have accepted for group distribution messages that the recipient's filtering system rejected. Eg: spam and viruses. Sorry, Yahoogroups doesn't get a free pass to distribute viruses and spam. The fact that that occasionally causes subscriptions to fail is the price you have to pay to protect your users. > "Cheaply" isn't necessarily "well". We've already discussed how I might > occasionally send an E-mail message from an Internet cafe in a resort > city, or for that matter onboard a cruise ship. I will still want to > use MY personal E-mail address, even though it will not be being sent > out by anything remotely like the E-mail servers I would use from my > systems here at home. Blocking those messages as "spam" just because > they aren't being sent through my habitual mail server (and I may not > know in advance whose server that Internet cafe is using) isn't very > helpful. Letting viruses in because they forge your email address isn't very helpful either. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbWYZ53FmCyJjHfhAQIoCAQAwcvS5Z1gTmV4dpiRtD2qsEd/D8L9IpT5 7aVPO2HSgthucvvLt2uMNJu13S8YiCXfb0Z65iFWpH97b3dPvhmH4dIpBvnqsh34 pkEShS+XF6NQWOusKpgziIprLvbij1MpvdaX7/w5Lfz7JDx9zKiy+0xiGI62/fUm 6zhXv/WiJX8= =PXQK -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:23:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9E7c-00024e-ES; Tue, 23 Jan 2007 00:23:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9E7b-00024K-AE for asrg@ietf.org; Tue, 23 Jan 2007 00:23:03 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9E7Z-00013I-Uh for asrg@ietf.org; Tue, 23 Jan 2007 00:23:03 -0500 Received: from [192.168.0.4] (adsl-68-122-32-36.dsl.pltn13.pacbell.net [68.122.32.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0N5MPxd020040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 21:22:26 -0800 Message-ID: <45B59B86.6030003@dcrocker.net> Date: Mon, 22 Jan 2007 21:22:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Finch Subject: Re: [Asrg] Re: bounces, and anit-spam principles References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: gep2@terabites.com, asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Tony Finch wrote: > wrote: >> 2. Accordingly, the definition of what they do and do not >> want MUST be such that the RECIPIENT defines it... not the >> IETF, not the sender's ISP, not the recipient's ISP, nor >> some governmental body, nor anybody else. > > Most users prefer to delegate this job. It's 10x more efficient > to do so. Not to quibble, but I would have guessed several orders of magnitude greater. Probably more. Also, for most of the world's 1+ billion users, I'd have added "effective" to "efficient"... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:27:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EBj-0003jn-I2; Tue, 23 Jan 2007 00:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EBh-0003je-Gf for asrg@ietf.org; Tue, 23 Jan 2007 00:27:17 -0500 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9EBf-0003eV-Ga for asrg@ietf.org; Tue, 23 Jan 2007 00:27:16 -0500 Received: (qmail 9120 invoked from network); 23 Jan 2007 05:27:04 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 23 Jan 2007 05:27:04 -0000 Date: 23 Jan 2007 05:27:04 -0000 Message-ID: <20070123052704.89816.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <45B59867.1000002@nortel.com> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: clewis@nortel.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >> I would be happy to have someone else adjust some of my spam filters for >> me, as long as the results are good, but my experience with such things >> is that they simply aren't as good as they need to be... to the point >> where I had to simply turn some ISP-provided spam filters off (they were >> more trouble than they were worth, and mis-categorized too many messages). There are certainly lots of ISPs with crummy spam filters. But my experience agrees with Chris. When users are asking for knobs and dials on the spam filters, what it really means is that the filters don't work. A couple of years ago I visited a large cable ISP who told me that with their old filters they were getting constant requests for customization, then they installed new filters that worked better and the requests completely stopped. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:30:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EEW-0005Ej-28; Tue, 23 Jan 2007 00:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EEU-0005EI-Du for asrg@ietf.org; Tue, 23 Jan 2007 00:30:10 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9EET-0004C5-61 for asrg@ietf.org; Tue, 23 Jan 2007 00:30:10 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1112664ugd for ; Mon, 22 Jan 2007 21:30:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OhaIwruf4+JvrIY2mFFqOJJJ5wQk6ljeq6eWcNSoY20ZOWaClUBx82wiSCBjRQWgMk6Wv3lBFUGEFJeGlCPK+0k+3sNHDU68jyRgZnCdmL7y7hCEuL5DVOHlNOopZ/sbVY7s6XH9g8LHYW+t2ca2bw8keegdvaPoYaAxePtEQ20= Received: by 10.78.157.8 with SMTP id f8mr127692hue.1169530208181; Mon, 22 Jan 2007 21:30:08 -0800 (PST) Received: by 10.78.23.19 with HTTP; Mon, 22 Jan 2007 21:30:08 -0800 (PST) Message-ID: <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> Date: Mon, 22 Jan 2007 23:30:08 -0600 From: "David Nicol" To: "Chris Lewis" Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <45B564B8.6090306@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <45B564B8.6090306@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/22/07, Chris Lewis wrote: > "don't bounce spam and viruses". okay; here's for the BCP compendium: Rejecting is acceptable. Filing is acceptable. Bouncing is unacceptable. Right? _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:54:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Eb0-0006W4-Qa; Tue, 23 Jan 2007 00:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Eaz-0006Vy-SE for asrg@ietf.org; Tue, 23 Jan 2007 00:53:25 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Eay-0003jS-K4 for asrg@ietf.org; Tue, 23 Jan 2007 00:53:25 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id EE4FC3DCFE0 for ; Tue, 23 Jan 2007 00:53:23 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <45B564B8.6090306@nortel.com> <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Tue, 23 Jan 2007 00:53:20 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 11:30 PM -0600 1/22/07, David Nicol wrote: >On 1/22/07, Chris Lewis wrote: >>"don't bounce spam and viruses". > >okay; here's for the BCP compendium: Rejecting is acceptable. Filing >is acceptable. >Bouncing is unacceptable. Right? Not quite. Bouncing because you've decided that mail fits a class where most mail has a bogus sender (i.e. spam and viruses) is unacceptable. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 00:56:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Edi-0008Dd-Fi; Tue, 23 Jan 2007 00:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Edg-0008DR-G2 for asrg@ietf.org; Tue, 23 Jan 2007 00:56:12 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Edf-0004tn-4x for asrg@ietf.org; Tue, 23 Jan 2007 00:56:12 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0N5mPt07984 for ; Tue, 23 Jan 2007 00:48:26 -0500 (EST) Received: from [47.9.16.68] ([47.9.16.68] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 00:56:08 -0500 Message-ID: <45B5A374.6040508@nortel.com> Date: Tue, 23 Jan 2007 00:56:04 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <45B564B8.6090306@nortel.com> <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> In-Reply-To: <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 05:56:08.0633 (UTC) FILETIME=[2D792290:01C73EB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Nicol wrote: > On 1/22/07, Chris Lewis wrote: >> "don't bounce spam and viruses". > > okay; here's for the BCP compendium: Rejecting is acceptable. Filing > is acceptable. > Bouncing is unacceptable. Right? > You're going to have to define what "filing" means, and perhaps realize that whatever "filing" is isn't mutually exclusive with bounce or reject. I would suggest that silent blackholing (or even quarantining) isn't acceptable, because there's no means of discovering false positives (except out of band - eg: the phone). I'd also suggest that letting the email through with a "spam tag", or sticking in "junk folders", or the like is poor in general - because in reality, the recipients don't look. My personal opinion is that the "gold standard" is reject + quarantine + per-recipient-configurable quarantine notification. Because that's what we do ;-) For the purposes of the BCP, tho, that's way beyond the level of detail I think you're intending - it's changed it into a different question with a far broader scope. First and foremost, this simple message is the one you need to impart: "thou MUST NOT bounce". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbWjdJ3FmCyJjHfhAQKsLQQA7aX9JCJ9n2KuxjFduNB1oM1MDXx+F4qB szvgBy+WfvkVbQz3Nl5SW+bmqw67J86YlmNAwKU4SroscQmmObKrlidY485X3JLy 4TcromKgsIRd+uVKL/wb8C59E18HXtcgVCtT78BrZ4+C9x/VZI2busNBPIASKY9n 8LLnuM/PRKY= =TcVz -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 01:02:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ejq-0002af-Sz; Tue, 23 Jan 2007 01:02:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ejp-0002aV-Iu for asrg@ietf.org; Tue, 23 Jan 2007 01:02:33 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ejn-0005qM-Jv for asrg@ietf.org; Tue, 23 Jan 2007 01:02:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0N62L426919 for ; Tue, 23 Jan 2007 01:02:21 -0500 (EST) Received: from [47.9.16.68] ([47.9.16.68] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 01:02:20 -0500 Message-ID: <45B5A4E9.9050003@nortel.com> Date: Tue, 23 Jan 2007 01:02:17 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <45B564B8.6090306@nortel.com> <934f64a20701222130k43822050gdca30a2727a511ae@mail.gmail.com> <45B5A374.6040508@nortel.com> In-Reply-To: <45B5A374.6040508@nortel.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 06:02:20.0852 (UTC) FILETIME=[0B553F40:01C73EB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Lewis wrote: > First and foremost, this simple message is the one you need to impart: > > "thou MUST NOT bounce". When considering Bill's variation (which I actually prefer, but...), one must realize that you may be wanting to do bounces for things that aren't considered "spam or viruses". Eg: this is technically equivalent to, say, an autoresponder. It would be a mistake, for example, to exclude filtering on an autoresponder address. Indeed, the filtering should be a lot more aggressive and/or use other techniques to avoid responding to things that don't "look right". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbWk6Z3FmCyJjHfhAQJexQP+MZnl1vTJJaEjemdO7wN8IFizqRe/ISr9 ZeO3gwpskY/8HsYm1E9rM9m1dDWpdvrdPAADuZ/eZsusuoKfBZFxVvlgY9mg7thT lmkP5uolcDPVjBN1LByYidGaHVdByXWZKDaxo6a5qK0KzjsQ8VAx9H3cVb4Ok6v7 oXOG2qD4ZPM= =qId5 -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 01:25:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9F5g-0003hK-9t; Tue, 23 Jan 2007 01:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9F5e-0003gj-EA for asrg@ietf.org; Tue, 23 Jan 2007 01:25:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9F5d-00041t-54 for asrg@ietf.org; Tue, 23 Jan 2007 01:25:06 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1118954ugd for ; Mon, 22 Jan 2007 22:25:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ezDNqvfPDi0hu11vl6IpUDYXnKjLj3drY7+5NCYWWlp11Z24Oke0N3gofA3bZALLPqJJJsyTe4gasjWK8YSeSX9LO3+3eC8Tf2gnXS8VxszmTk6WrxTc7YVCQm4QrfLsSajKfAS91RrSaJvoPD8Vf2Vuhu7Rl1UbyFH6TvBtO6E= Received: by 10.78.146.11 with SMTP id t11mr146569hud.1169533502963; Mon, 22 Jan 2007 22:25:02 -0800 (PST) Received: by 10.78.23.19 with HTTP; Mon, 22 Jan 2007 22:25:02 -0800 (PST) Message-ID: <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> Date: Tue, 23 Jan 2007 00:25:02 -0600 From: "David Nicol" To: "Dan Oetting" Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/22/07, Dan Oetting wrote: > That works if you don't mind taking the long route. I was thinking of > a more direct path of sending a specific response code in the SMTP > transaction. A really smart smarthost might be able to then fix the > problem before the site gets blacklisted. > > -- Dan Oetting I for one caught that drift. It wouldn't need to be its own ESMTP keyword, just some specific text following the 550 rejected on policy grounds. Perhaps the word "spam." So, a conformant sending domain, on seeing a /^550 .+spam/i response, would do what exactly? Log the fact? Page a sysadmin? _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 04:04:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HX2-0001j8-7T; Tue, 23 Jan 2007 04:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HX1-0001j0-Jd for asrg@ietf.org; Tue, 23 Jan 2007 04:01:31 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9HX0-0005li-5b for asrg@ietf.org; Tue, 23 Jan 2007 04:01:31 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id D5AF8403A; Tue, 23 Jan 2007 10:01:26 +0100 (CET) Date: Tue, 23 Jan 2007 10:01:26 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles Message-ID: <20070123090126.GB3794@hjp.at> Mail-Followup-To: asrg@ietf.org References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783151564==" Errors-To: asrg-bounces@ietf.org --===============1783151564== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-23 00:25:02 -0600, David Nicol wrote: > On 1/22/07, Dan Oetting wrote: > >That works if you don't mind taking the long route. I was thinking of > >a more direct path of sending a specific response code in the SMTP > >transaction. A really smart smarthost might be able to then fix the > >problem before the site gets blacklisted. >=20 > I for one caught that drift. It wouldn't need to be its own ESMTP > keyword, just some specific text following the 550 rejected on policy > grounds. Perhaps the word "spam." >=20 > So, a conformant sending domain, on seeing a /^550 .+spam/i response, wou= ld > do what exactly? Log the fact? Page a sysadmin? Temporarily block emails from this user and generate a bounce message explaining the policy (it's your user and he has authenticated himself with SMTP AUTH or an equivalent mechanism, so you know who he is). You probably still want to accept mail from the user to your own support mail address, and you probably also want to start with a short (maybe only a few minutes) blocking time and increase that with every offense. If the user mistakenly has sent a mail to a spamtrap he will probably be clean again when he's finished writing his next mail and because of the bounce message he knows that he shouldn't send to that address again. If his machine is a zombie which uses his credentials he will have increasing trouble sending mail until he cleans up his machine.=20 Sounds like a nice scheme to me. Has anybody ever tried that? hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFtc7mfZ+RkG8quy0RAs0OAJ9lMyEnGzYhOjA58UeQ60jU7aDZdACgiNId MfzdGimJkqRsObhe/gGLnGI= =dnk2 -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- --===============1783151564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1783151564==-- From asrg-bounces@ietf.org Tue Jan 23 05:22:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ImA-0006gJ-Dl; Tue, 23 Jan 2007 05:21:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Im9-0006gE-3A for asrg@ietf.org; Tue, 23 Jan 2007 05:21:13 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Im3-0001Yh-2T for asrg@ietf.org; Tue, 23 Jan 2007 05:21:13 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60258) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1H9Ilg-0006dp-Na (Exim 4.63) (return-path ); Tue, 23 Jan 2007 10:20:44 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1H9Ilg-0003F4-93 (Exim 4.54) (return-path ); Tue, 23 Jan 2007 10:20:44 +0000 Date: Tue, 23 Jan 2007 10:20:44 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dcrocker@bbiw.net Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <45B59B86.6030003@dcrocker.net> Message-ID: References: <45B59B86.6030003@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Tony Finch , gep2@terabites.com, asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 22 Jan 2007, Dave Crocker wrote: > Tony Finch wrote: > > > > Most users prefer to delegate this job. It's 10x more efficient > > to do so. > > Not to quibble, but I would have guessed several orders of magnitude > greater. Probably more. Also, for most of the world's 1+ billion users, > I'd have added "effective" to "efficient"... I was thinking in terms of the cost of accepting, storing, and retrieving the user's email before passing it to the MUA filter and only then discovering that 90% of it is spam, as opposed to rejecting it at SMTP time. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: MAINLY NORTHWESTERLY 5 INCREASING 6 TO GALE 8. MODERATE INCREASING ROUGH OR VERY ROUGH. SNOW SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 05:27:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Iry-0000Q2-9e; Tue, 23 Jan 2007 05:27:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Irx-0000Pe-4Q for asrg@ietf.org; Tue, 23 Jan 2007 05:27:13 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Irv-0002tQ-U1 for asrg@ietf.org; Tue, 23 Jan 2007 05:27:13 -0500 Received: by an-out-0708.google.com with SMTP id d30so577544and for ; Tue, 23 Jan 2007 02:27:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pVb0ypg/jb7W+nJwVCnbndWnpeoBymKQC0xZzflg881pYdj/fvprURbM6fq/TFLm4WOb0IYl3bVlYGAZBvZ9AuV+wq5NKK+NtHFcnwnTxFAqPzQxDA7mHoKTTUER6H3NZf+flUnlwmyN6Qxun+12A4a0agEB1rT+mK4iNjhPUHc= Received: by 10.78.204.1 with SMTP id b1mr234842hug.1169548030519; Tue, 23 Jan 2007 02:27:10 -0800 (PST) Received: by 10.78.185.5 with HTTP; Tue, 23 Jan 2007 02:27:10 -0800 (PST) Message-ID: <5ec229170701230227q17bc1eeeq4de9b63f2511f7d8@mail.gmail.com> Date: Tue, 23 Jan 2007 10:27:10 +0000 From: "Danny Angus" To: asrg@ietf.org Subject: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <5ec229170701230226p3a40123evf9c0253e4b57b031@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <5ec229170701230226p3a40123evf9c0253e4b57b031@mail.gmail.com> X-Google-Sender-Auth: 1b68c455b047166c X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/22/07, David Nicol wrote: > possibly violating Zooko's triangle How so? > My growing suspicion is that the end result of this committee is going to > be current practices enumeration and reccomendations, with a bottom line > of "it isn't broken." That's pretty close, but I think it undervalues the excercise. What I hoped to achieve by outlining characteristics which the techniques that have survived share (not all techniques display all characteristics), and by identifying which characteristics the ones which have died out violate was to catalogue a set of requirements which we believe represent the requirements for a complete solution to the problem. Involved in this analysis is an analysis of the entities, which has highlighted one big problem, which is that the ASRG *still* can't agree a definition for spam, and an alignment of those definitions against definitions in the corpus of RFC's which we call "email". In spite of the fact that we may review current practice and arrive at "it isn't broken." I believe we may also arrive at these conclusions:- "it isn't complete", "it is understood", "some aspects are well advanced" and "The scope is clear". If we're lucky we might also get "we know what the gaps are", and if we're smart "we know how to fill them". d. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 05:27:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IsW-0000cM-VA; Tue, 23 Jan 2007 05:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IsW-0000cE-AL for asrg@ietf.org; Tue, 23 Jan 2007 05:27:48 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9IsV-00032J-0s for asrg@ietf.org; Tue, 23 Jan 2007 05:27:48 -0500 Received: by an-out-0708.google.com with SMTP id d30so577675and for ; Tue, 23 Jan 2007 02:27:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=i4cMmDjHQPA+RICO+edNJhBSlJURdBD+Y8ju2WToaUJ2qaXKDEmXqbxOOQBiZQdVX068ULdpv8sznwHGdWg0TKbmNyexZ84F7Fnk5zjmoSkvVn8SaqA1kxWHqrGFFawoaWNBK09wdHgAewYkyafXck65yBJWcY/brR6vSa6Ids0= Received: by 10.78.160.2 with SMTP id i2mr234971hue.1169548065542; Tue, 23 Jan 2007 02:27:45 -0800 (PST) Received: by 10.78.185.5 with HTTP; Tue, 23 Jan 2007 02:27:45 -0800 (PST) Message-ID: <5ec229170701230227y5636f2fai6a0fba18520fd1d4@mail.gmail.com> Date: Tue, 23 Jan 2007 10:27:45 +0000 From: "Danny Angus" To: asrg@ietf.org Subject: Fwd: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <5ec229170701220647s14cb4cdbp3584aa4611ec2f54@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ec229170701180344g6daca36dtdbe5ede8a2db447f@mail.gmail.com> <5ec229170701220647s14cb4cdbp3584aa4611ec2f54@mail.gmail.com> X-Google-Sender-Auth: 3278964037eca9a1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Sorry, this one missed the list.. ---------- Forwarded message ---------- From: Danny Angus Date: Jan 22, 2007 2:47 PM Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt To: Daniel Feenberg Daniel wrote: > 1.1.1 I would resist making the definition of spam so receipient > dependent. If every receipient gets to make his/her own definition, then > it tends to prevent cooperative solutions from looking satisfactory, and > the the purpose of the IETF is to facilitate cooperative solutions. For > example, if spam has no objective definition, then each user must maintain > their own DNSBL, or list of spamassassin regular expressions. I would have > thought the purpose of this group was to suggest ways for MTA operators to > cooperate to reduce spam - individual solutions don't require the IETF. I understand what you're saying, but there are two things I considered relevant, the first is that two individuals might have vastly different opinions on the desirability of any piece of mail. The second one is that if any individual can express their desire not to receive an identifiable class of mail for *any* reason, propagating that criteria into the transport system has the potential for reclaiming bandwith. > There are also the cases to consider of ISPs who ignore messages to abuse > - does that make the messages spam? It makes it "unwanted" and therefore it need not be sent which would potentially save resources. >I think we should stick with > "unsolicited commercial email" as a workable spam definition. I'm happy to try to revise this from that perspective, but I'm not sure how artificial it will look, the only definition which was obviously implied by the rest of the analysis was "unwanted", it may look a bit artificial if the definition is changed. I'll give it a go and maybe present a couple of alternatives. > 2.2.1 Why the prohibition on the use of non-SMTP protocols? ... > Or perhaps the section means only that the mail itself should > not use another protocol. Yes more or less, I actually meant that the process of delivering or not-delivering mail should not require any communication by the sender using anything other than the technology required for email. We've seen suggestions involve logging into web-sites to verify your right to send etc. >Then it should say so. I hear so many complaints > about the overloading of DNS with other tasks, perhaps I am reading them > into this section. Would adding another keyword to the SMTP protocol be > allowed? Absolutely. ... > There is a surprising omissions - No mention of the superiority of > rejection during the SMTP processing over discarding or delivering to a > spam folder. Or did I miss it somewhere? I think so, that whole premis of 2.1 is that the cost of operating should fall with the introduction of the technique. Experience suggests that it would be preferable to abandon processing as soon as possible, but I didn't want to make judgements about how best the cost saving might be achieved, as to do so would be to pre-judge based on an assumption. > I worry that the point of the draft is to outlaw all spam reduction > techniques other than individually created and controlled content > analysis. Not at all, many existing techniques stack up quite well against this, dnsbl's, DK, spf etc etc would all be partial techniques which could affect an overall reduction. I hope that there is scope for choice as to the application of criteria and the point at which they are applied. > At the very least users need to be able to cooperate or to > purchase anti-spam services from unrelated organizations, and without > common definitions and inexpensive communication of results, this will be > made unnecessarily difficult. Agreed, but in that case you are really delegating your right to make the decision by outsourcing it like you might outsource any other aspect. > Would the author list some common techniques are say if they meet these > standards, and if not, where they fail? I will do, but I don't have as much time as I'd like so it may be a day or two. Thanks for your comments. d. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 06:57:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KFN-0001tV-6l; Tue, 23 Jan 2007 06:55:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KFM-0001tP-Ko for asrg@ietf.org; Tue, 23 Jan 2007 06:55:28 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9KFG-0003NH-50 for asrg@ietf.org; Tue, 23 Jan 2007 06:55:28 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39899) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1H9KEn-00068H-1a (Exim 4.63) (return-path ); Tue, 23 Jan 2007 11:54:53 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1H9KEn-00024K-Eq (Exim 4.54) (return-path ); Tue, 23 Jan 2007 11:54:53 +0000 Date: Tue, 23 Jan 2007 11:54:53 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: gep2@terabites.com Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Tony Finch , asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 22 Jan 2007, gep2@terabites.com wrote: > > OK, so let's say Aunt Matilda's system gets a virus on it, and starts sending > out spam (sooner or later, MOST machines will be infected at least once...!) > Now what? Her machine gets quarantined and her ISP helps her (manually or via a special web site) to fix her computer. This is not quite a pipe dream - see http://wesii.econinfosec.org/draft.php?paper_id=47 (You can Google for an HTML version.) > And what about the case where Aunt Matilda's system IS NOT infected, never has > been, but where her mail services is impacted (as mine has been) by SOMEONE > ELSE's machine being infected, and forging HER return address on the e-mails? The blacklists I'm talking about work on IP addresses not email addresses. > > They also deal with the vast majority of spam very cheaply. > > "Cheaply" isn't necessarily "well". It is if you use the right blacklists, e.g. the Spamhaus ones. Tony. -- f.a.n.finch http://dotat.at/ SHANNON: NORTH 6 OR 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH. SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 08:32:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LjR-00059o-5x; Tue, 23 Jan 2007 08:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LjP-00059e-OJ for asrg@ietf.org; Tue, 23 Jan 2007 08:30:35 -0500 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9LjN-0001kh-Fu for asrg@ietf.org; Tue, 23 Jan 2007 08:30:35 -0500 Received: by wr-out-0506.google.com with SMTP id 69so1060007wra for ; Tue, 23 Jan 2007 05:30:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gazw9oL7zKDdXqprRL2ewl6e7AsLPAUBe1F92H6OmlOwsdO0hXf+lvXYkpqCRoJouGXNRYqbV9ahFzb32HJ8tnrSr/tPA4ZFOxh4yq7OVNtol2Xf4Wbzo+5wdMr0MSDOCk8SmUEv0bnF7vEWsAqVLip67/o3UbCYWFN7BliiH04= Received: by 10.78.201.10 with SMTP id y10mr345858huf.1169559032187; Tue, 23 Jan 2007 05:30:32 -0800 (PST) Received: by 10.78.146.18 with HTTP; Tue, 23 Jan 2007 05:30:31 -0800 (PST) Message-ID: <5ec229170701230530g61e841f9u3d868a66bebc1bd5@mail.gmail.com> Date: Tue, 23 Jan 2007 13:30:31 +0000 From: "Danny Angus" To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <20070123090126.GB3794@hjp.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> <20070123090126.GB3794@hjp.at> X-Google-Sender-Auth: 5f22f60a51d53bc3 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/23/07, Peter J. Holzer wrote: > Temporarily block emails from this user and generate a bounce message ... > Sounds like a nice scheme to me. Has anybody ever tried that? I don't know if anyone has tried it, but we discussed a proposal at Apache James some years ago that proposed using a 4xx response to allow recipient MTA's to spend time evaluating (or hand off evaluation of) an mta's or sender's identity (possibly scoring it) before accepting mail from them rather than perform expensive checks in real time. I briefly mentioned it on this list in 2003[1] I believe that this approach is also consistent with rfc2505 para 1.6[2]. The sending MTA would either retry after an agreed delay, or when called with an enhanced ETRN, enhanced to specify allowable MTA's, sender(s) and/or recipient(s) or listed message id's (not the ones in the body, this would have to be a key agreed between MTA's). In the event that the recipient decides not to allow it would return another 4xx with an appropriate reason that might be resolved, or a 5xx with a reason which could not be resolved. The main objection was that some felt the quantity of delayed mail and the reconciliation of it against the allowable patterns would impose a significant unwanted overhead on MTA's. We didn't do any analysis to confirm or refute this. A less crucial objection is that badly behaved sending MTA's wouldn't abide by the rules and even though connections could be broken and 4xx & 5xx re-issued it might not be possible to realise the perceived benefits when challenged by a load of badly behaved spambots. d. [1] http://www1.ietf.org/mail-archive/web/asrg/current/msg06019.html [2] http://www.ietf.org/rfc/rfc2505.txt _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 09:17:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MQI-00012g-D4; Tue, 23 Jan 2007 09:14:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MQH-00012Y-C4 for asrg@ietf.org; Tue, 23 Jan 2007 09:14:53 -0500 Received: from mail1.nber.org ([66.251.72.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9MQC-0008B6-T8 for asrg@ietf.org; Tue, 23 Jan 2007 09:14:53 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0NEEggK019081 for ; Tue, 23 Jan 2007 09:14:42 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0NEEfEk019055; Tue, 23 Jan 2007 09:14:41 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0NEEfnE020037; Tue, 23 Jan 2007 09:14:41 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0NEEUTs020034; Tue, 23 Jan 2007 09:14:30 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 23 Jan 2007 09:14:30 -0500 (EST) From: Daniel Feenberg To: dcrocker@bbiw.net Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <45B59B86.6030003@dcrocker.net> Message-ID: References: <45B59B86.6030003@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Tony Finch , gep2@terabites.com, asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 22 Jan 2007, Dave Crocker wrote: > > > Tony Finch wrote: >> wrote: >>> 2. Accordingly, the definition of what they do and do not >>> want MUST be such that the RECIPIENT defines it... not the >>> IETF, not the sender's ISP, not the recipient's ISP, nor >>> some governmental body, nor anybody else. >> >> Most users prefer to delegate this job. It's 10x more efficient >> to do so. > > > Not to quibble, but I would have guessed several orders of magnitude greater. > > Probably more. > > Also, for most of the world's 1+ billion users, I'd have added "effective" to > "efficient"... > > d/ Among other problems with individually maintained spamblocks is the difficulty in rehabilitating a legitimate address (ip or domain) after it has been widely blocked for prior bad behavior. Forbidding cooperation or delegation is a spammer's trick. Daniel Feenberg > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 11:26:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OS0-0001vv-IT; Tue, 23 Jan 2007 11:24:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ORz-0001vn-J0 for asrg@ietf.org; Tue, 23 Jan 2007 11:24:47 -0500 Received: from egress4.webmaillogin.com ([216.40.36.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ORy-0002FC-6z for asrg@ietf.org; Tue, 23 Jan 2007 11:24:47 -0500 Received: by egress4.webmaillogin.com (egress4.webmaillogin.com, from userid 1005) id 2F5257718B2; Tue, 23 Jan 2007 11:24:36 -0500 (EST) Received: from webmaillogin.com (fr3.webmaillogin.com [216.40.35.67]) by egress4.webmaillogin.com (egress4.webmaillogin.com) with ESMTP id 72938778028; Tue, 23 Jan 2007 11:02:18 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk3.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 4362072; Tue, 23 Jan 2007 10:55:45 -0500 From: Subject: Re: [Asrg] Re: bounces, and anti-spam principles To: Daniel Feenberg ,dcrocker@bbiw.net X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Tue, 23 Jan 2007 09:55:45 -0600 Message-ID: In-Reply-To: References: <45B59B86.6030003@dcrocker.net> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Tony Finch , asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 23 Jan 2007 09:14:30 -0500 (EST) Daniel Feenberg wrote: > On Mon, 22 Jan 2007, Dave Crocker wrote: >> Tony Finch wrote: >>> wrote: >>>> 2. Accordingly, the definition of what they do and do=20 >>>>not >>>> want MUST be such that the RECIPIENT defines it... not=20 >>>>the >>>> IETF, not the sender's ISP, not the recipient's ISP, nor >>>> some governmental body, nor anybody else. [snip] > Among other problems with individually maintained=20 >spamblocks is the difficulty in rehabilitating a=20 >legitimate address (ip or domain) after > it has been widely blocked for prior bad behavior. Absolutely, and that's a good reason why blocking by=20 either IP address or domain name is such a bad solution.=20 A fine-grained whitelist which specifies ALLOWED behavior=20 on a per-sender basis, on the other hand, can easily allow=20 or block messages from a given sender ON A=20 MESSAGE-BY-MESSAGE basis, so that their legitimate=20 messages get delivered but the (zombie) messages being=20 sent by their same (infected)machine, using the same mail=20 servers and same permissions/certifications but which do=20 not look the way that sender's messages are expected to=20 look (by the recipient!) are efficiently and accurately=20 identified and blocked. So "rehabilitation" isn't even an issue. A suitable default set of criteria, combined with a=20 suitable content filter ("Spam Assassin" or similar....=20 which can do a far more accurate job once HTML, scripting,=20 and attachments are not allowed from unknown senders!) can=20 handle the requirements fairly nicely for a large=20 percentage of typical users. So there you have your=20 "centralized criteria" for both the first and second=20 levels of filtering, while still allowing the recipients=20 to open a "narrow and twisty gauntlet" to allow through=20 the other messages that they expect from senders who they=20 know and trust... (and because those individually-set=20 criteria are not known to spammers, they will have a=20 vanishingly small probability of getting such messages=20 delivered). I do agree that it would philosophically be better if=20 there were some way to detect and block such messages=20 earlier in the distribution path, but that's really a=20 discussion for a later date. Ultimately, that might not=20 even be necessary... if the spammers realize that=20 virtually none of their garbage will be delivered, at some=20 point they will either go and do something else, or else=20 just be more direct (virus-author-like) and unabashedly=20 just abuse the network infrastructure without any pretense=20 of expecting E-mails to get through at all, perhaps.=20 Again, that's a discussion for a later time. >Forbidding cooperation or delegation is a spammer's=20 >trick. The "spammers trick" is trying to make sure that everybody=20 uses the same criteria, so they can engineer messages that=20 will slip through the default criteria. You'd better=20 believe that all serious spammers have and use Spam=20 Assassin and other such scanners, and test their intended=20 messages to make sure they stay below the various spam=20 thresholds. Things like Spam Assassin can do a pretty good job, IF=20 they aren't confronted with things like scripting, images=20 (attached or embedded), ActiveX, HTML ruses of various=20 kinds, and similar tricks that evade text-based content=20 detection rules. Y'all can sit back for years in philosophical and=20 theoretical discussions about some elaborate technical=20 "magic bullet" that you think is going to solve the spam=20 problem, but when push comes to shove, what you're=20 eventually going to figure out on this one is that I've=20 been right all along, and that what I'm proposing really=20 IS an effective and practical solution to the problem.=20 (And perhaps THE ONLY good approach). Gordon Peterson http://personal.terabites.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 12:00:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9P0H-0003SN-3I; Tue, 23 Jan 2007 12:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9P0G-0003Rg-4F for asrg@ietf.org; Tue, 23 Jan 2007 12:00:12 -0500 Received: from mpls-qmqp-01.inet.qwest.net ([63.231.195.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9P0D-0001fv-SE for asrg@ietf.org; Tue, 23 Jan 2007 12:00:12 -0500 Received: from mpls-pop-01.inet.qwest.net (mpls-pop-01.inet.qwest.net [63.231.195.1]) by mpls-qmqp-01.inet.qwest.net (Postfix) with QMQP id EDE4A1A9B83 for ; Tue, 23 Jan 2007 17:00:05 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-01.inet.qwest.net with SMTP; 23 Jan 2007 17:00:05 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> <0F06B50A-82DC-49A8-9D95-99CA41593459@qwest.net> <934f64a20701222225t37abcbadhd6bb38eaad3d74b8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <374C1937-A5C9-4153-A2F4-6C1C43DFFA0C@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] Re: bounces, and anit-spam principles Date: Tue, 23 Jan 2007 10:00:05 -0700 To: ASRG list X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 22, 2007, at 11:25 PM, David Nicol wrote: > On 1/22/07, Dan Oetting wrote: >> That works if you don't mind taking the long route. I was thinking of >> a more direct path of sending a specific response code in the SMTP >> transaction. A really smart smarthost might be able to then fix the >> problem before the site gets blacklisted. >> >> -- Dan Oetting > > I for one caught that drift. It wouldn't need to be its own ESMTP > keyword, > just some specific text following the 550 rejected on policy > grounds. Perhaps > the word "spam." > > So, a conformant sending domain, on seeing a /^550 .+spam/i > response, would > do what exactly? Log the fact? Page a sysadmin? Just like most blacklists wouldn't list a site for a single email hitting a spamtrap, the host would not be expected to take action against a user for sending the single email unless there were extenuating circumstances. If the host is on probation or a gray list for currently spamming it may be necessary to throttle the user to prevent escalation to a blacklist. You don't want to reveal the spamtrap address to the user. If the users account has been taken over by a spammer it could wash the address from its lists and then you loose that method of identifying the spamers next identity. These traps should not be used for blacklisting because if they are identified by the spammers they could be abused to generate false listings. The spamtraps should only be revealed between cooperating ISPs. And each trap should only reveal itself to a fraction of the connecting hosts to keep from revealing all the traps to a rogue ISP that joins the group. The response code given to reveal the trap should be an accept code (2xx) so that the text is not passed to the user by default if the smarthost MTA is non-conforming. -- Dan Oetting (sent to the list this time) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 12:21:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PKb-0005Ja-DF; Tue, 23 Jan 2007 12:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PKa-0005JP-BC for asrg@ietf.org; Tue, 23 Jan 2007 12:21:12 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PKY-0006v8-UN for asrg@ietf.org; Tue, 23 Jan 2007 12:21:12 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id 463B35884C7; Tue, 23 Jan 2007 12:21:00 -0500 (EST) Received: from webmaillogin.com (fr3.webmaillogin.com [216.40.35.67]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id 0F22F589CE0; Tue, 23 Jan 2007 12:15:44 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk2.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 60897108; Tue, 23 Jan 2007 11:54:35 -0500 From: Subject: Re: [Asrg] Re: bounces, and anti-spam principles To: Tony Finch X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Tue, 23 Jan 2007 10:54:35 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 23 Jan 2007 11:54:53 +0000 Tony Finch wrote: > On Mon, 22 Jan 2007, gep2@terabites.com wrote: >> >> OK, so let's say Aunt Matilda's system gets a virus on=20 >>it, and starts sending >> out spam (sooner or later, MOST machines will be=20 >>infected at least once...!) >> Now what? >=20 > Her machine gets quarantined and her ISP helps her=20 >(manually or via a > special web site) to fix her computer. This is not quite=20 >a pipe dream - > see http://wesii.econinfosec.org/draft.php?paper_id=3D47 > (You can Google for an HTML version.) I agree that the zombie spambot problem is key (and it=20 might even be the case that ISPs will someday be=20 considered liable for allowing worm/virus messages to be=20 delivered to their customers, given the relative ease of=20 detecting those at their level...). One of the advantages=20 of my approach is that it virtually eliminates the=20 viruses/worms which infect machines and produce these=20 spambot armies (well, at least it virtually eliminates=20 their propagation by E-mail...!) The paper ignores the fact that a lot of spam messages are=20 nearly impossible to detect using scanners, unless you=20 block images and other attachments, scripting, and HTML. Their contention that zombie spambot networks can be dealt=20 with by their ISP help desks is ridiculous, given the=20 scope of the problem and the general incompetence of those=20 help desks. Their so-called "automated" approach strikes=20 me as little more than a nice fantasy, at least in the=20 general case. In any case, I still contend that simplistic blocking by=20 IP address or domain name is a very poor approach, and for=20 a whole variety of reasons. >> And what about the case where Aunt Matilda's system IS=20 >>NOT infected, never has >> been, but where her mail services is impacted (as mine=20 >>has been) by SOMEONE >> ELSE's machine being infected, and forging HER return=20 >>address on the e-mails? >=20 > The blacklists I'm talking about work on IP addresses=20 >not email addresses. Dialup machines, for example (and there are still a lot of=20 those) don't generally have fixed IP addresses. >> > They also deal with the vast majority of spam very=20 >>cheaply. >> >> "Cheaply" isn't necessarily "well". >=20 > It is if you use the right blacklists, e.g. the Spamhaus=20 >ones. I still consider the use of blacklists (either IP or=20 domain name or E-mail address based) as a poor solution,=20 due to the transient nature of dialup IP addresses, and=20 the difficulty of rehabilitating addresses. Also, very=20 large networks of computers (say, an entire large company,=20 or say a campus) operating using NAT could be compromised=20 because just one machine (even a "visiting" portable=20 notebook machine via a wireless connection) sent spam,=20 causing their router's IP address or mail server's IP=20 address to be blacklisted. The problem with blacklists is that it is a wild goose=20 chase... and you're trying to lock the door AFTER the=20 horse has gotten out. The person pulling the wagon (in=20 this case the spammers) can pull it any direction they=20 like, and everyone else is in a crazy keystone-cops-like=20 race from behind. Spammers can (and do) generate an=20 infinite number of bogus E-mail addresses, user names,=20 subject lines, and even message contents. They can=20 eventually infect a large percentage of every machine on=20 the Net, worldwide. The fact that a machine or IP address sent (once, twice,=20 some number of times) spam (at some point in the past) is=20 no guarantee that it will ever (or never!) send spam=20 again. Simply blocking (as a default behavior) attachments and=20 HTML in messages from unfamiliar/untrusted senders (and on=20 a fine-grained basis, such that one can allow say JPGs but=20 block executable attachments, and different levels of HTML=20 too, and on a sender-by-sender basis) goes a LONG, LONG=20 way to stopping E-mail distribution of viruses and worms=20 and trojans (and thus the recruitment of spambot nets),=20 and at the same time is the single biggest step that can=20 be made to allowing SpamAssassin and similar content=20 filters to do their job far more effectively. Gordon Peterson http://personal.terabites.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 12:44:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Pg9-0006ZB-Hw; Tue, 23 Jan 2007 12:43:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Pg8-0006Z5-UN for asrg@ietf.org; Tue, 23 Jan 2007 12:43:28 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9Pg7-0002jY-Gb for asrg@ietf.org; Tue, 23 Jan 2007 12:43:28 -0500 Received: from [192.168.0.4] (adsl-68-122-32-36.dsl.pltn13.pacbell.net [68.122.32.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0NHgeE7028137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 09:42:40 -0800 Message-ID: <45B64905.7030301@dcrocker.net> Date: Tue, 23 Jan 2007 09:42:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Finch Subject: Re: [Asrg] Re: bounces, and anit-spam principles References: <45B59B86.6030003@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Tony Finch wrote: > On Mon, 22 Jan 2007, Dave Crocker wrote: >> Tony Finch wrote: >>> Most users prefer to delegate this job. It's 10x more efficient >>> to do so. >> Not to quibble, but I would have guessed several orders of magnitude >> greater. Probably more. Also, for most of the world's 1+ billion users, >> I'd have added "effective" to "efficient"... > > I was thinking in terms of the cost of accepting, storing, and retrieving > the user's email before passing it to the MUA filter and only then > discovering that 90% of it is spam, as opposed to rejecting it at SMTP > time. Ahh. OK. And, of course, I was thinking in terms of expecting/requiring users to do any abuse-related processing. Human factors, usability, and the like. Yuch. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 13:39:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QXq-0000hG-SM; Tue, 23 Jan 2007 13:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QXo-0000gh-P7 for asrg@ietf.org; Tue, 23 Jan 2007 13:38:56 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9QXn-0003ie-Hp for asrg@ietf.org; Tue, 23 Jan 2007 13:38:56 -0500 Received: from mpls-pop-12.inet.qwest.net (mpls-pop-12.inet.qwest.net [63.231.195.12]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id 0C46C53BDA9 for ; Tue, 23 Jan 2007 18:38:55 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-12.inet.qwest.net with SMTP; 23 Jan 2007 18:38:54 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <129D53E6-5A1E-4D93-AA1E-3DB1109E4BDF@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] Re: bounces, and anti-spam principles Date: Tue, 23 Jan 2007 11:38:54 -0700 To: ASRG list X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.4 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 23, 2007, at 9:54 AM, gep2@terabites.com wrote: > In any case, I still contend that simplistic blocking by IP address > or domain name is a very poor approach, and for a whole variety of > reasons. I will contend that there cannot be a content filter that can reliably separate spam from non spam. Any non-spam message received by one person would be spam if it were sent to 10 million harvested addresses. OTOH, taking the definition of spam as Unsolicited Bulk Email makes detecting a spamming IP address almost trivial. The trick is to stop accepting mail from that IP address only until it has cleaned up. Once the spam is gone there is no need to block the address unless it has proven to be a repeat offender without an effective process for shutting the spammers down. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 14:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RaJ-0000lh-Jl; Tue, 23 Jan 2007 14:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RaI-0000lO-9s for asrg@ietf.org; Tue, 23 Jan 2007 14:45:34 -0500 Received: from mail2.panix.com ([166.84.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RaH-0003p3-3a for asrg@ietf.org; Tue, 23 Jan 2007 14:45:34 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id CD396CACC0 for ; Tue, 23 Jan 2007 14:45:23 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l0NJjNM16803; Tue, 23 Jan 2007 14:45:23 -0500 (EST) Date: Tue, 23 Jan 2007 14:45:23 -0500 (EST) Message-Id: <200701231945.l0NJjNM16803@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (gep2@terabites.com) Subject: Re: [Asrg] Re: bounces, and anti-spam principles References: <45B59B86.6030003@dcrocker.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org wrote: > Absolutely, and that's a good reason why blocking by > either IP address or domain name is such a bad solution. > A fine-grained whitelist which specifies ALLOWED behavior > on a per-sender basis, on the other hand, can easily allow > or block messages from a given sender ON A > MESSAGE-BY-MESSAGE basis, so that their legitimate > messages get delivered but the (zombie) messages being > sent by their same (infected)machine, using the same mail > servers and same permissions/certifications but which do > not look the way that sender's messages are expected to > look (by the recipient!) are efficiently and accurately > identified and blocked. > > So "rehabilitation" isn't even an issue. So the zombie becomes unable to emit spam, but there's no incentive to fix it so it's still available to the botmaster for use as a C&C machine, web/DNS server, and DDoS participant. I'd prefer that it get uninfected. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 14:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RZP-0000XI-Rj; Tue, 23 Jan 2007 14:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RZO-0000XC-QZ for asrg@ietf.org; Tue, 23 Jan 2007 14:44:38 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RZN-0003gB-GU for asrg@ietf.org; Tue, 23 Jan 2007 14:44:38 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0NJiWVx016363 for ; Tue, 23 Jan 2007 14:44:34 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0NJiWO7026426; Tue, 23 Jan 2007 14:44:32 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MeFrom asrg-bounces@ietf.org Tue Jan 23 14:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RaJ-0000lh-Jl; Tue, 23 Jan 2007 14:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RaI-0000lO-9s for asrg@ietf.org; Tue, 23 Jan 2007 14:45:34 -0500 Received: from mail2.panix.com ([166.84.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RaH-0003p3-3a for asrg@ietf.org; Tue, 23 Jan 2007 14:45:34 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id CD396CACC0 for ; Tue, 23 Jan 2007 14:45:23 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l0NJjNM16803; Tue, 23 Jan 2007 14:45:23 -0500 (EST) Date: Tue, 23 Jan 2007 14:45:23 -0500 (EST) Message-Id: <200701231945.l0NJjNM16803@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (gep2@terabites.com) Subject: Re: [Asrg] Re: bounces, and anti-spam principles References: <45B59B86.6030003@dcrocker.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org wrote: > Absolutely, and that's a good reason why blocking by > either IP address or domain name is such a bad solution. > A fine-grained whitelist which specifies ALLOWED behavior > on a per-sender basis, on the other hand, can easily allow > or block messages from a given sender ON A > MESSAGE-BY-MESSAGE basis, so that their legitimate > messages get delivered but the (zombie) messages being > sent by their same (infected)machine, using the same mail > servers and same permissions/certifications but which do > not look the way that sender's messages are expected to > look (by the recipient!) are efficiently and accurately > identified and blocked. > > So "rehabilitation" isn't even an issue. So the zombie becomes unable to emit spam, but there's no incentive to fix it so it's still available to the botmaster for use as a C&C machine, web/DNS server, and DDoS participant. I'd prefer that it get uninfected. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 14:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RZP-0000XI-Rj; Tue, 23 Jan 2007 14:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RZO-0000XC-QZ for asrg@ietf.org; Tue, 23 Jan 2007 14:44:38 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RZN-0003gB-GU for asrg@ietf.org; Tue, 23 Jan 2007 14:44:38 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0NJiWVx016363 for ; Tue, 23 Jan 2007 14:44:34 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0NJiWO7026426; Tue, 23 Jan 2007 14:44:32 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17846.26016.14436.541196@world.std.com> Date: Tue, 23 Jan 2007 14:44:32 -0500 To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <45B59B86.6030003@dcrocker.net> References: <45B59B86.6030003@dcrocker.net> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls5.std.com X-Virus-Scanned: ClamAV 0.88.4/2480/Tue Jan 23 06:21:51 2007 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Speaking as an ISP, what's unrealistic in these utopian end-user filtering only arguments is costs. Suffice it to say that we can add fast, capable mail servers and see them flooded in a matter of hours. Pushing all the filtering to the end-user would make that much worse. Being able to "slam the phone down" on miscreant IP blocks at the accept() or helo is much, much, less processing than going thru the entire SMTP interaction and whatever it takes to pass processing off to an end-user. Put another way, you can have almost unfiltered access and near-perfect spam filtering! Here's how to do it: Get your own link to the backbone. Set up your own mail servers etc. Hire one or more secretaries to pre-screen your email according to rules you have trained them in. It might cost a few thousand a month, but surely in the face of all this expressed urgency about the pitfalls of centralized filtering it's a small price to pay. Anyhow, as the old joke goes, we're not arguing about the principle, we're arguing about the price. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg ssage-ID: <17846.26016.14436.541196@world.std.com> Date: Tue, 23 Jan 2007 14:44:32 -0500 To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <45B59B86.6030003@dcrocker.net> References: <45B59B86.6030003@dcrocker.net> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls5.std.com X-Virus-Scanned: ClamAV 0.88.4/2480/Tue Jan 23 06:21:51 2007 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Speaking as an ISP, what's unrealistic in these utopian end-user filtering only arguments is costs. Suffice it to say that we can add fast, capable mail servers and see them flooded in a matter of hours. Pushing all the filtering to the end-user would make that much worse. Being able to "slam the phone down" on miscreant IP blocks at the accept() or helo is much, much, less processing than going thru the entire SMTP interaction and whatever it takes to pass processing off to an end-user. Put another way, you can have almost unfiltered access and near-perfect spam filtering! Here's how to do it: Get your own link to the backbone. Set up your own mail servers etc. Hire one or more secretaries to pre-screen your email according to rules you have trained them in. It might cost a few thousand a month, but surely in the face of all this expressed urgency about the pitfalls of centralized filtering it's a small price to pay. Anyhow, as the old joke goes, we're not arguing about the principle, we're arguing about the price. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 15:06:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Rtm-0001bN-Q6; Tue, 23 Jan 2007 15:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Rtk-0001bD-GV for asrg@ietf.org; Tue, 23 Jan 2007 15:05:40 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Rtj-00073j-7i for asrg@ietf.org; Tue, 23 Jan 2007 15:05:40 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1169597ugd for ; Tue, 23 Jan 2007 12:05:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fnf1ndGexomQjr4ocfU2KHIK2JAdAsFD5ZlmjmMF9fh+kBEO0gNaGWd3bz1Ma5HVvQaWJj8WBFNDax3k830aR4czuW3HDiXGUTBD296NGGunHL2aN9Tcn798R/21+augDEuxkf9thhCVOR060s/VXR+zrhMiSzQyJ0Blb9y5/Oo= Received: by 10.82.120.15 with SMTP id s15mr314483buc.1169582737523; Tue, 23 Jan 2007 12:05:37 -0800 (PST) Received: by 10.78.23.19 with HTTP; Tue, 23 Jan 2007 12:05:37 -0800 (PST) Message-ID: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> Date: Tue, 23 Jan 2007 14:05:37 -0600 From: "David Nicol" To: "Barry Shein" Subject: Re: [Asrg] Re: bounces, and anit-spam principles In-Reply-To: <17846.26016.14436.541196@world.std.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/23/07, Barry Shein wrote: > Suffice it to say that we can add fast, capable mail servers and see > them flooded in a matter of hours. > > Pushing all the filtering to the end-user would make that much > worse. not the filtering, just the filter configuration. MTA-resident complex content filtering with different per-recipient outcomes is not compatible with recipient enumeration preceding the data block; therefore the DATAFIRST ESMTP proposal I made some months ago. > Being able to "slam the phone down" on miscreant IP blocks at the > accept() or helo is much, much, less processing than going thru the > entire SMTP interaction and whatever it takes to pass processing off > to an end-user. even less is turning them off at the firewall. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 16:20:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9T2y-0000hz-3L; Tue, 23 Jan 2007 16:19:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9T2w-0000hm-Tu for asrg@ietf.org; Tue, 23 Jan 2007 16:19:14 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9T2v-0005CF-Jw for asrg@ietf.org; Tue, 23 Jan 2007 16:19:14 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id B7188403A; Tue, 23 Jan 2007 22:00:57 +0100 (CET) Date: Tue, 23 Jan 2007 22:00:57 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles Message-ID: <20070123210057.GD1712@hjp.at> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946252957==" Errors-To: asrg-bounces@ietf.org --===============0946252957== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fWddYNRDgTk9wQGZ" Content-Disposition: inline --fWddYNRDgTk9wQGZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-23 14:05:37 -0600, David Nicol wrote: > On 1/23/07, Barry Shein wrote: > >Suffice it to say that we can add fast, capable mail servers and see > >them flooded in a matter of hours. > > > >Pushing all the filtering to the end-user would make that much > >worse. >=20 > not the filtering, just the filter configuration. MTA-resident complex > content filtering with different per-recipient outcomes is not compatible > with recipient enumeration preceding the data block; It can still be done. It just needs a bit of trickery with 4xx replies. It's ugly as hell, and it increases mail traffic (and CPU usage for filtering), but it works. > therefore the > DATAFIRST ESMTP proposal I made some months ago. I still like the LMTP model better, but having any method for returning different results for different recipients based on the content would be an improvement. hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --fWddYNRDgTk9wQGZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFtneJfZ+RkG8quy0RAgeHAKCuszjwfZvZIKuwLNhA9X/wraxyUQCeP413 wvpu+mtURr00DpwEy2rynPI= =bU6N -----END PGP SIGNATURE----- --fWddYNRDgTk9wQGZ-- --===============0946252957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0946252957==-- From asrg-bounces@ietf.org Tue Jan 23 16:27:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9TBE-0003NP-6i; Tue, 23 Jan 2007 16:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9TBA-0003N1-RM for asrg@ietf.org; Tue, 23 Jan 2007 16:27:44 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9TB6-0007Tm-JA for asrg@ietf.org; Tue, 23 Jan 2007 16:27:44 -0500 Received: from [207.65.71.19] (pool-72-75-23-100.washdc.east.verizon.net [72.75.23.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 157DF3F313 for ; Tue, 23 Jan 2007 15:27:40 -0600 (CST) Message-ID: <45B67DB0.5070803@ehsco.com> Date: Tue, 23 Jan 2007 16:27:12 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anit-spam principles References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> In-Reply-To: <20070123210057.GD1712@hjp.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/23/2007 4:00 PM, Peter J. Holzer wrote: >>> Pushing all the filtering to the end-user would make that much >>> worse. >> not the filtering, just the filter configuration. MTA-resident complex >> content filtering with different per-recipient outcomes is not compatible >> with recipient enumeration preceding the data block; > > It can still be done. It just needs a bit of trickery with 4xx replies. > It's ugly as hell, and it increases mail traffic (and CPU usage for > filtering), but it works. see http://www.ehsco.com/misc/I-Ds/draft-hall-inline-dsn-01.txt which uses per-recipient codes after the data block (the LMTP model) It's not likely that spammers would use it however -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 17:19:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Tyi-0002EI-FF; Tue, 23 Jan 2007 17:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Tyh-0002Do-3x for asrg@ietf.org; Tue, 23 Jan 2007 17:18:55 -0500 Received: from mailout1.igs.net ([216.58.97.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Tye-0007EE-NA for asrg@ietf.org; Tue, 23 Jan 2007 17:18:55 -0500 Received: from waltdnes.org (i209-195-114-240.cia.com [209.195.114.240]) by mailout1.igs.net (Postfix) with SMTP id 87F78619A for ; Tue, 23 Jan 2007 17:18:41 -0500 (EST) Received: by waltdnes.org (sSMTP sendmail emulation); Tue, 23 Jan 2007 17:21:19 -0500 From: "Walter Dnes" Date: Tue, 23 Jan 2007 17:21:19 -0500 To: ASRG list Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt Message-ID: <20070123222119.GA30684@waltdnes.org> References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122185126.2488F32CDD@radish.jmason.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, Jan 22, 2007 at 06:51:26PM +0000, Justin Mason wrote > Defining spam as "email the user does not want" means that you cannot > safely filter spam, except with a user-trained classifier > (Bayesian-style probabilistic classification for example). No, you're missing the point entirely, although it may be partially my fault for not making it clear enough. Here's a Venn diagram. ______ / ____ \ / / \ \ | | spam | | <<== Unwanted email \ \____/ / \______/ "spam" is a slang word, which is often used to describe *A SUBSET OF* unwanted email. Some legal jurisdictions have legislation that defines spam very narrowly. If you insist on blocking "spam", you *WILL* end up spending a lot of time and money in court cases where... 1) the spammer insists that his spam is "not-spam" because of some technicality. Expect to see lots of legal "is not spam; is so; is not; is so; is not" being billed at lawyers' regular rates. And of course, you can rest assured that the politicians who enact legislation will make exemptions for solicitations for campaign contributions. Any "spam-filters" that block any "not-spam" *WILL* get hit with cease-and-desist orders 2) saying that Joe Blow sends spam is equivalant to calling him a spammer. Watch the defamation (libel/slander) lawsuits fly. However, if you block "unwanted email" rather than "spam"... 1) spammer says "wahhh, wahhh, wahhh, my 'valuable information' is 'not-spam'" and you can enthusiastically agree. The the customer still doesn't want it. "Because I said so" should be sufficient reason. 2) By not labelling unwanted email as "spam", you're not labelling the sender as a spammer. Spammers can still launch frivolous lawsuits, but at least don't give them legal ammo. To summarize, *DON'T LET THE SPAMMERS PICK THE BATTLEFIELD AND SET THE RULES*, because they'll obviously stack the deck in their favour. The best analogy is dealing with telemarketers, close cousins to email spammers. The main rule is to *NEVER* give a reason for saying "No" other than saying "I don't want it; good-bye". A competent (I dislike using the word "good") telemarketer will have been trained to refute just about every logical argument you can come up with to not buy their product. These people are pros; this is their livlihood; they will argue circles around you. Similarly, don't try to define "the S-word" in technical terms. A bunch of geeks sitting at their keyboards are no match for a nit-picking lawyer who was the captain of his class debating team. It's effectively a pro se defense against high-powered lawyers, and the results are very predictable. Don't engage in a battle you can't win. Go with... - our customer says he doesn't want your emails. No, we don't know why he doesn't want your emails. - the customer is always right; end of story. Don't give the spammers' lawyers anything to attack. > It's too subjective, and would outlaw DNSBL usage, as far as I > can tell... Not at all. It does require separate rules for each customer. The following is not a paid commercial, and I am not receiving in financial consideration for making these statements... - I am a customer of clss.net (Aurora Internet) - they have a modified Qmail that generates 550 SMTP-stage rejects (i.e. *NOT* a DSN) based on a customer-configurable control file in the customer's home directory. There are separate rule files for sub-accounts. E.g. I point my domain MX at their server. abuse and postmaster are basically unfiltered compared to this address. - step 1 is to declare a whitelist of emails that I accept unconditionally - I don't want email from residential machines on dynamic IP addresses sending direct-to-MX. So I block based on dynamic IP DNSbls, regexp filter against rDNS, and obviously block email from machines with no rDNS whatsoever. - I don't talk to myself. I don't want email from people who lie in their email, by including "waltdnes.org" in the HELO or return-path. So I block those emails. - I don't want email from certain /8's (RIPE, AFRINIC, LATNIC, and most of APNIC (punch holes for Australia and New Zealand using zz.countries.nerd.dk)), so I block those /8's. - I don't want email from certain countries, so I block them, using country-codes in rDNS and return-path - I don't want email from addresses that are listed by Spamhaus, because I said so. Therefore I use Spamhaus' DNSbl. - etc, etc. Executive summary... - blocking email, because it meets some technical criteria, is easier on the technical side, but introduces legal problems - blocking email, because the customer said so, may be harder technically, but avoids legal problems - any complications on the anti-spam side are outweighed by equivalant complications on the spammers' end. ISPs will have to enable end users to configure their own rules, and everybody's filters and whitelists will be slightly different. Imagine how spammers will feel knowing that each of several million targets for a spam-run has a slightly different defense, that has to be overcome in order to deliver the email. -- Walter Dnes In linux /sbin/init is Job #1 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 23 18:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VPF-00009j-8I; Tue, 23 Jan 2007 18:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VPD-00009Y-Lm for asrg@ietf.org; Tue, 23 Jan 2007 18:50:23 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9VPC-0004hF-Ol for asrg@ietf.org; Tue, 23 Jan 2007 18:50:23 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0NNoHUq013163 for ; Tue, 23 Jan 2007 18:50:17 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0NNoB3G013141; Tue, 23 Jan 2007 18:50:12 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0NNoAnE022924; Tue, 23 Jan 2007 18:50:10 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0NNo4Ud022921; Tue, 23 Jan 2007 18:50:09 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 23 Jan 2007 18:50:04 -0500 (EST) From: Daniel Feenberg To: Walter Dnes Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <20070123222119.GA30684@waltdnes.org> Message-ID: References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> <20070123222119.GA30684@waltdnes.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 23 Jan 2007, Walter Dnes wrote: > On Mon, Jan 22, 2007 at 06:51:26PM +0000, Justin Mason wrote > >> Defining spam as "email the user does not want" means that you cannot >> safely filter spam, except with a user-trained classifier >> (Bayesian-style probabilistic classification for example). > > No, you're missing the point entirely, although it may be partially my > fault for not making it clear enough. Here's a Venn diagram. > ______ > / ____ \ > / / \ \ > | | spam | | <<== Unwanted email > \ \____/ / > \______/ > > > "spam" is a slang word, which is often used to describe *A SUBSET OF* > unwanted email. Some legal jurisdictions have legislation that defines > spam very narrowly. If you insist on blocking "spam", you *WILL* end up > spending a lot of time and money in court cases where... > > 1) the spammer insists that his spam is "not-spam" because of some > technicality. Expect to see lots of legal "is not spam; is so; is not; > is so; is not" being billed at lawyers' regular rates. And of course, > you can rest assured that the politicians who enact legislation will > make exemptions for solicitations for campaign contributions. Any > "spam-filters" that block any "not-spam" *WILL* get hit with > cease-and-desist orders > > 2) saying that Joe Blow sends spam is equivalant to calling him a > spammer. Watch the defamation (libel/slander) lawsuits fly. > > However, if you block "unwanted email" rather than "spam"... > > 1) spammer says "wahhh, wahhh, wahhh, my 'valuable information' is > 'not-spam'" and you can enthusiastically agree. The the customer still > doesn't want it. "Because I said so" should be sufficient reason. > > 2) By not labelling unwanted email as "spam", you're not labelling the > sender as a spammer. Spammers can still launch frivolous lawsuits, but > at least don't give them legal ammo. > > To summarize, *DON'T LET THE SPAMMERS PICK THE BATTLEFIELD AND SET THE > RULES*, because they'll obviously stack the deck in their favour. The > best analogy is dealing with telemarketers, close cousins to email > spammers. The main rule is to *NEVER* give a reason for saying "No" > other than saying "I don't want it; good-bye". A competent (I dislike > using the word "good") telemarketer will have been trained to refute > just about every logical argument you can come up with to not buy their > product. These people are pros; this is their livlihood; they will > argue circles around you. > > Similarly, don't try to define "the S-word" in technical terms. A > bunch of geeks sitting at their keyboards are no match for a nit-picking > lawyer who was the captain of his class debating team. It's effectively > a pro se defense against high-powered lawyers, and the results are very > predictable. Don't engage in a battle you can't win. Go with... > - our customer says he doesn't want your emails. No, we don't know > why he doesn't want your emails. > - the customer is always right; end of story. > Don't give the spammers' lawyers anything to attack. > >> It's too subjective, and would outlaw DNSBL usage, as far as I >> can tell... > > Not at all. It does require separate rules for each customer. The > following is not a paid commercial, and I am not receiving in financial > consideration for making these statements... > > - I am a customer of clss.net (Aurora Internet) > > - they have a modified Qmail that generates 550 SMTP-stage rejects > (i.e. *NOT* a DSN) based on a customer-configurable control file in > the customer's home directory. There are separate rule files for > sub-accounts. E.g. I point my domain MX at their server. abuse and > postmaster are basically unfiltered compared to this address. > > - step 1 is to declare a whitelist of emails that I accept > unconditionally > > - I don't want email from residential machines on dynamic IP addresses > sending direct-to-MX. So I block based on dynamic IP DNSbls, regexp > filter against rDNS, and obviously block email from machines with no > rDNS whatsoever. > > - I don't talk to myself. I don't want email from people who lie in > their email, by including "waltdnes.org" in the HELO or return-path. > So I block those emails. > > - I don't want email from certain /8's (RIPE, AFRINIC, LATNIC, and > most of APNIC (punch holes for Australia and New Zealand using > zz.countries.nerd.dk)), so I block those /8's. > > - I don't want email from certain countries, so I block them, using > country-codes in rDNS and return-path > > - I don't want email from addresses that are listed by Spamhaus, > because I said so. Therefore I use Spamhaus' DNSbl. > > - etc, etc. > > Executive summary... > > - blocking email, because it meets some technical criteria, is easier > on the technical side, but introduces legal problems > > - blocking email, because the customer said so, may be harder > technically, but avoids legal problems > > - any complications on the anti-spam side are outweighed by equivalant > complications on the spammers' end. ISPs will have to enable end > users to configure their own rules, and everybody's filters and > whitelists will be slightly different. Imagine how spammers will > feel knowing that each of several million targets for a spam-run has > a slightly different defense, that has to be overcome in order to > deliver the email. > > -- All I can say is, you are certainly welcome to block any mail you please, and no cooperation from other MTA operators is required, nor is any meeting of the IETF. The only purpose for the IETF involvement is to coordinate cooperative action. Since the IETF is voluntary, the action needs to be of benefit to all participants, and that greatly restricts the field of actions practical for widespread implementation. But it doesn't in any way restrict what you as an individual can do. Since your method requires no cooperation from any other MTA operator, it doesn't require any endorsement from this group. That is fine - it doesn't make your method illegitimate or anything like that. But most users wish for a cooperative anti-spam technique, because they reasonably expect it will work better, and they reasonably expect many other MTA operators to cooperate with them. This has been true in the past - consider the many DNSBLs and other activities against spam. When we kept a list of spamming IP addresses sending to our MTA, we found after 2 weeks that only 1% of the IPs had send more than one message. Our subscription to Spamhaus kills about 65% of incoming messages. That is a victory for cooperation and it makes us think that more cooperation might be better. It is true that cooperative actions attract lawsuits, but that is only because it isn't practical to sue an individual for refusing mail, but it is pratical to sue a corporation for blocking a large number of messages. If Spamhaus changes its name to Unwantedmailhaus, I don't expect that will affect its legal situation. Daniel Feenberg > Walter Dnes In linux /sbin/init is Job #1 > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 06:25:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9gD2-000863-2C; Wed, 24 Jan 2007 06:22:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9gD1-00085C-IR for asrg@ietf.org; Wed, 24 Jan 2007 06:22:31 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9gD0-0005LX-7V for asrg@ietf.org; Wed, 24 Jan 2007 06:22:31 -0500 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0OBMLga029348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 24 Jan 2007 03:22:22 -0800 Subject: Re: [Asrg] Re: bounces, and anit-spam principles From: Douglas Otis To: Steve Atkins In-Reply-To: <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> References: <9B0105A5-008A-464F-90A6-99249EDB997B@qwest.net> <8BE4294E-C21F-4C3B-84DD-A7AE7584A491@blighty.com> Content-Type: text/plain Date: Wed, 24 Jan 2007 03:22:21 -0800 Message-Id: <1169637741.5698.41.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 2007-01-22 at 18:09 -0800, Steve Atkins wrote: > On Jan 22, 2007, at 5:59 PM, Dan Oetting wrote: > > On Jan 22, 2007, at 5:48 PM, Steve Atkins wrote: > > > >> Identifying the sender reliably is the missing link in the current > >> system. > > > > The missing link is really 2 different problems depending on which > > side of the link you are on. The receiver can't identify the actual > > sender and the smarthost can't reliably identify the email as > > abusive. Providing direct feedback when email is abusive (such as > > when unsolicited email hits a spamtrap) could bridge the gap and > > permit the smarthost to take appropriate action to stop the abuse. > > DKIM and ARF between them provide all the protocol-level solution > needed for that. DKIM was the missing link I was thinking of. Problems remain even when DKIM provides a verifiable domain playing some role in sending the message. DKIM excludes the envelope. A message signed by Yahoo! can be replayed. It remains to be seen how effective ARF might be at suppressing abuse of a free account. Looking at the situation with .com, it seems even charging for a service might not offer much of a reduction, due to a high level of fraud. DKIM limitations on indicating on who's behalf the message is signed seems aimed at providing a method to extort use of private keys of customers as a means to avoid receiving the ARF information directly. This does not bode well for DKIM and ARF working together. : ( Perhaps something as simple as an 'mx-' prefix on the SMTP client hostname could be used to indicate compliance with address validation, in addition to a convention where the domain below this label also accepts ARF reports. The prefix also implies the domain's authorization for sending email. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 11:36:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9l3E-0006ol-EJ; Wed, 24 Jan 2007 11:32:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9l3C-0006m4-OG for asrg@ietf.org; Wed, 24 Jan 2007 11:32:42 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9l39-000733-De for asrg@ietf.org; Wed, 24 Jan 2007 11:32:42 -0500 Received: from mpls-pop-12.inet.qwest.net (mpls-pop-12.inet.qwest.net [63.231.195.12]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id CA3B353BEF3 for ; Wed, 24 Jan 2007 16:32:38 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-12.inet.qwest.net with SMTP; 24 Jan 2007 16:32:38 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Anti Spam Research Group From: Dan Oetting Date: Wed, 24 Jan 2007 09:32:37 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Asrg] Mail problem in NY X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Has anyone else seen a mail delivery problem between the US and europe starting a couple of days ago? I traced it to a hop in the NY area that is specifically clobbering large packets on TCP port 25. Looks to me like a mis-configured packet sniffer or an intentional jammer. If spammers are intercepting mail on the backbone the era of passive spamtraps will be over. Or, it might be an experiment to jam content packets and reinject spam in the middle of an email as it flies by on the wire. I hope it's just our own spooks bungling a tap. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 12:51:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9mG4-0005du-5Y; Wed, 24 Jan 2007 12:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9mG2-0005au-Gm for asrg@ietf.org; Wed, 24 Jan 2007 12:50:02 -0500 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9mG1-0006h4-2G for asrg@ietf.org; Wed, 24 Jan 2007 12:50:02 -0500 Received: (qmail 10281 invoked from network); 24 Jan 2007 17:49:53 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 24 Jan 2007 17:49:53 -0000 Date: 24 Jan 2007 17:49:53 -0000 Message-ID: <20070124174953.20334.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Mail problem in NY In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org In article you write: >Has anyone else seen a mail delivery problem between the US and >europe starting a couple of days ago? I traced it to a hop in the NY >area that is specifically clobbering large packets on TCP port 25. >Looks to me like a mis-configured packet sniffer or an intentional >jammer. I'm in New York downstream of Sprint, and haven't seen any unusual problems. This kind of problem is much, much, more likely to be a screwup than intentional sabotage. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 13:11:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ma2-0007xD-NO; Wed, 24 Jan 2007 13:10:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ma1-0007wv-7w for asrg@ietf.org; Wed, 24 Jan 2007 13:10:41 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9mZy-0008L0-Rr for asrg@ietf.org; Wed, 24 Jan 2007 13:10:41 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C3A6A00; Wed, 24 Jan 2007 10:10:36 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0OIAbqI011319 for asrg@ietf.org; Wed, 24 Jan 2007 10:10:37 -0800 (PST) Date: Wed, 24 Jan 2007 10:10:37 -0800 From: Claus Assmann To: asrg@ietf.org Message-ID: <20070124181036.GA27184@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B67DB0.5070803@ehsco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Asrg] Re: per recipient status X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, Jan 23, 2007, Eric A. Hall wrote: > see http://www.ehsco.com/misc/I-Ds/draft-hall-inline-dsn-01.txt which uses > per-recipient codes after the data block (the LMTP model) Are there any intention to make this into an RFC? > It's not likely that spammers would use it however For those you can still use the method of allowing only one recipient per transaction (or at least only recipients with the same anti-spam policies). Any conforming MTA however would not be subject to those restrictions. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 14:39:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nvt-0004gE-HJ; Wed, 24 Jan 2007 14:37:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nvs-0004fy-EA for asrg@ietf.org; Wed, 24 Jan 2007 14:37:20 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nvr-0000iW-6F for asrg@ietf.org; Wed, 24 Jan 2007 14:37:20 -0500 Received: from [207.65.71.19] (pool-72-75-23-100.washdc.east.verizon.net [72.75.23.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id A77243F472 for ; Wed, 24 Jan 2007 13:37:18 -0600 (CST) Message-ID: <45B7B556.3020508@ehsco.com> Date: Wed, 24 Jan 2007 14:36:54 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> In-Reply-To: <20070124181036.GA27184@zardoc.esmtp.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/24/2007 1:10 PM, Claus Assmann wrote: > On Tue, Jan 23, 2007, Eric A. Hall wrote: > >> see http://www.ehsco.com/misc/I-Ds/draft-hall-inline-dsn-01.txt which uses >> per-recipient codes after the data block (the LMTP model) > > Are there any intention to make this into an RFC? I didn't push it (the writeup was a thought experiment more than anything), and there didn't seem to be a lot of interest from the WG either. I imagine somebody would need to implement it in their MTA before it advanced down the standardization track. >> It's not likely that spammers would use it however > > For those you can still use the method of allowing only one recipient > per transaction (or at least only recipients with the same anti-spam > policies). Any conforming MTA however would not be subject to those > restrictions. all true -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 18:32:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rZl-0004iH-Pu; Wed, 24 Jan 2007 18:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rZj-0004g9-IK for asrg@ietf.org; Wed, 24 Jan 2007 18:30:43 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9rZi-0007YM-9j for asrg@ietf.org; Wed, 24 Jan 2007 18:30:43 -0500 Received: by ug-out-1314.google.com with SMTP id 72so272506ugd for ; Wed, 24 Jan 2007 15:30:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WNPVd87ooU9z/c1U9s2fOprItonrcWuO/XYrwPmbyQJPuQu5m04Bz445PskRBp/1QOHZelhtRUH9UOvKnHmQTDSzyOsoLtP4BBuQzrvsqXRhK2GswnRt/ai7u1rUXKAKUokowJ5GZGlu3k+WZeeVeghBVthsrssiHiTn9tDk0rc= Received: by 10.78.158.11 with SMTP id g11mr1123020hue.1169681434387; Wed, 24 Jan 2007 15:30:34 -0800 (PST) Received: by 10.78.23.19 with HTTP; Wed, 24 Jan 2007 15:30:34 -0800 (PST) Message-ID: <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> Date: Wed, 24 Jan 2007 17:30:34 -0600 From: "David Nicol" To: "Eric A. Hall" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <45B7B556.3020508@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/24/07, Eric A. Hall wrote: > either. I imagine somebody would need to implement it in their MTA before > it advanced down the standardization track. the DATAFIRST proposal I made on this mailing list (june 2006) performs the same functions, semanticly, with less intermediate data and shorter times during which individual records would have to be locked. I may get around to implementing it later this year or next; blocked by expression of plan and achieving funding for central sender-pays business concept. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 18:42:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rka-0002Vu-2v; Wed, 24 Jan 2007 18:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rkY-0002Vi-Pz for asrg@ietf.org; Wed, 24 Jan 2007 18:41:54 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9rkW-0002wz-Gm for asrg@ietf.org; Wed, 24 Jan 2007 18:41:54 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C3EB000; Wed, 24 Jan 2007 15:41:51 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0ONfpdQ019499 for asrg@ietf.org; Wed, 24 Jan 2007 15:41:51 -0800 (PST) Date: Wed, 24 Jan 2007 15:41:51 -0800 From: Claus Assmann To: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status Message-ID: <20070124234151.GA3670@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Wed, Jan 24, 2007, David Nicol wrote: > the DATAFIRST proposal I made on this mailing list (june 2006) performs the > same > functions, semanticly, with less intermediate data and shorter times On one of my machines more than 95 per cent of the incoming mails is to unknown recipients. I do not want to receive the message data in that case at all. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 18:46:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rp7-0006Bw-5I; Wed, 24 Jan 2007 18:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9rp6-00069T-Bv for asrg@ietf.org; Wed, 24 Jan 2007 18:46:36 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9rp5-0003VU-5u for asrg@ietf.org; Wed, 24 Jan 2007 18:46:36 -0500 Received: by an-out-0708.google.com with SMTP id d30so168649and for ; Wed, 24 Jan 2007 15:46:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ba+Rjd0I8wpNOLCHEn9WOoq9OgvehWt4chDFTWHADp8lvyXuC3mrWt9UR4+QMRZIIQU1WrS6zxrJ/mLWn5b+0Miq+9BUDZXpCCeKMlj1nRDDmIErW0fmNEToI+5EEdJ+mzwGIaBy7RUHFCGoV8l5ZWOj112h6GY/OJb2R9+Jc5c= Received: by 10.78.171.13 with SMTP id t13mr244017hue.1169682361327; Wed, 24 Jan 2007 15:46:01 -0800 (PST) Received: by 10.78.23.19 with HTTP; Wed, 24 Jan 2007 15:46:01 -0800 (PST) Message-ID: <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> Date: Wed, 24 Jan 2007 17:46:01 -0600 From: "David Nicol" To: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <20070124234151.GA3670@zardoc.esmtp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <20070124234151.GA3670@zardoc.esmtp.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/24/07, Claus Assmann wrote: > On Wed, Jan 24, 2007, David Nicol wrote: > > > the DATAFIRST > On one of my machines more than 95 per cent of the incoming mails > is to unknown recipients. I do not want to receive the message data > in that case at all. good point. thanks. that would have to be fixed first of course; for instance DATAFIRST connections only allowed from reputable peers. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 19:06:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s7X-0007Pi-TH; Wed, 24 Jan 2007 19:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s7X-0007OM-07 for asrg@ietf.org; Wed, 24 Jan 2007 19:05:39 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9s7V-0001kh-QV for asrg@ietf.org; Wed, 24 Jan 2007 19:05:38 -0500 Received: by wr-out-0506.google.com with SMTP id 69so301748wra for ; Wed, 24 Jan 2007 16:05:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L5FT/IN4Eqqu0U9KbgB4HwbvPHjIhbzLreHZe3faYEB87ZLcHX9hzYZJngD2N2TzFUbEa7rT5y5x2Lva9Tn8VVwnW8+r7LE+SQkVdYH9mEb7OYaujiVSoxaHku5ubhYHQqzTNytLo9d7+h7xOiOvjgriGG9lfp1oX0yRvqR2QrM= Received: by 10.90.120.13 with SMTP id s13mr1525732agc.1169683537152; Wed, 24 Jan 2007 16:05:37 -0800 (PST) Received: by 10.64.179.14 with HTTP; Wed, 24 Jan 2007 16:05:37 -0800 (PST) Message-ID: <2d106eb50701241605h2a60d232w17fdcfb4c36c5c4b@mail.gmail.com> Date: Wed, 24 Jan 2007 19:05:37 -0500 From: "Martin Hannigan" To: "David Nicol" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <20070124234151.GA3670@zardoc.esmtp.org> <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/24/07, David Nicol wrote: > On 1/24/07, Claus Assmann wrote: > > On Wed, Jan 24, 2007, David Nicol wrote: > > > > > the DATAFIRST > > > On one of my machines more than 95 per cent of the incoming mails > > is to unknown recipients. I do not want to receive the message data > > in that case at all. > > > good point. thanks. that would have to be fixed first of course; for instance > DATAFIRST connections only allowed from reputable peers. Account lookups already accomplish this. Most spam mechanisms can handle checking for a valid account prior to accepting mail from a source. -M< _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 19:14:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sGE-0005PF-RS; Wed, 24 Jan 2007 19:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sGD-0005P7-E3 for asrg@ietf.org; Wed, 24 Jan 2007 19:14:37 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sGC-0004sk-1e for asrg@ietf.org; Wed, 24 Jan 2007 19:14:37 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l0P0EM1s001042; Wed, 24 Jan 2007 16:14:22 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l0P0EMmF001039; Wed, 24 Jan 2007 16:14:22 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 24 Jan 2007 16:14:22 -0800 (PST) From: "william(at)elan.net" To: David Nicol Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> Message-ID: References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: asrg@ietf.org, "Eric A. Hall" X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Wed, 24 Jan 2007, David Nicol wrote: > On 1/24/07, Eric A. Hall wrote: >> either. I imagine somebody would need to implement it in their MTA before >> it advanced down the standardization track. > > the DATAFIRST proposal I made on this mailing list (june 2006) performs the > same functions, semanticly, with less intermediate data and shorter times Is what you're asking really HEADer data first or entier message data content first? -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 24 22:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9vMU-00027m-Lg; Wed, 24 Jan 2007 22:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9vMT-00027M-A6 for asrg@ietf.org; Wed, 24 Jan 2007 22:33:17 -0500 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9vMR-0006Ih-2w for asrg@ietf.org; Wed, 24 Jan 2007 22:33:17 -0500 Received: by nz-out-0506.google.com with SMTP id z6so352385nzd for ; Wed, 24 Jan 2007 19:33:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TlRlzdblt/ftw35UEqpvWs6fwRDmgiC/oTaeJ58xifq0LbFBe0cobakgDMzzAmhRd4tbgDxt2pjtfqk+1WH1s3mfnCwbKWU1EH/E8AEldLsbGPFsj1H5UWHn0zLx6t6c0zCrmI4q8h09WlQB9gBzuWWwl0ByVlAPRynJOBsXwaI= Received: by 10.65.103.17 with SMTP id f17mr2059734qbm.1169695994626; Wed, 24 Jan 2007 19:33:14 -0800 (PST) Received: by 10.64.179.14 with HTTP; Wed, 24 Jan 2007 19:33:14 -0800 (PST) Message-ID: <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> Date: Wed, 24 Jan 2007 22:33:14 -0500 From: "Martin Hannigan" To: "william(at)elan.net" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: asrg@ietf.org, "Eric A. Hall" X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/24/07, william(at)elan.net wrote: > > On Wed, 24 Jan 2007, David Nicol wrote: > > > On 1/24/07, Eric A. Hall wrote: > >> either. I imagine somebody would need to implement it in their MTA before > >> it advanced down the standardization track. > > > > the DATAFIRST proposal I made on this mailing list (june 2006) performs the > > same functions, semanticly, with less intermediate data and shorter times > > Is what you're asking really HEADer data first or entier message data > content first? Even if, what would benefit "me" at the moment and for the foreseeable future is having more capability to "drop connections" before they start sending - based on recipient, then source. If I can shut down the millions of incorrigable LDAP, DNS, and I/O operations that take place to accept, review, then reject inbound spam, I'd be in the black operationally. If I had to pick a technology priority to pique my interest for '07, that I would consider proposing as a spending item to "make mail better", it would be centered around IP reputation. -M< _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 01:16:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xsM-0006tP-6E; Thu, 25 Jan 2007 01:14:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xsK-0006qn-NR for asrg@ietf.org; Thu, 25 Jan 2007 01:14:20 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9xsG-0002di-Ay for asrg@ietf.org; Thu, 25 Jan 2007 01:14:20 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0P6EEl13059 for ; Thu, 25 Jan 2007 01:14:14 -0500 (EST) Received: from [47.9.16.209] ([47.9.16.209] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 01:14:12 -0500 Message-ID: <45B84AAF.3010204@nortel.com> Date: Thu, 25 Jan 2007 01:14:07 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ASRG list Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> <20070123222119.GA30684@waltdnes.org> In-Reply-To: <20070123222119.GA30684@waltdnes.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 06:14:13.0080 (UTC) FILETIME=[08AE1D80:01C74048] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walter Dnes wrote: > Not at all. It does require separate rules for each customer. The > following is not a paid commercial, and I am not receiving in financial > consideration for making these statements... > > - I am a customer of clss.net (Aurora Internet) > > - they have a modified Qmail that generates 550 SMTP-stage rejects > (i.e. *NOT* a DSN) based on a customer-configurable control file in > the customer's home directory. There are separate rule files for > sub-accounts. E.g. I point my domain MX at their server. abuse and > postmaster are basically unfiltered compared to this address. > > - step 1 is to declare a whitelist of emails that I accept > unconditionally The problem being that out of the 60,000 seats here, perhaps less than 10 of them are able to competently configure a set of rules like what you have. Many of them don't even have a clear notion of the concept of "source IP" is, let alone being able to make reasonable choices of, say, knowing why you'd want to block dynamic IPs or IPs in Korea. Furthermore, and with complete irony, I'll note that the only reason I read this thread is that my very own, personally trained, UA bayesian filtering flung it all in the junk folder! ;-) > Executive summary... > > - blocking email, because it meets some technical criteria, is easier > on the technical side, but introduces legal problems Not for us. Furthermore, the risk of it is being overstated, and I don't think we should be making recommendations based upon what risks we think other people should be allowed to take. > - blocking email, because the customer said so, may be harder > technically, but avoids legal problems > - any complications on the anti-spam side are outweighed by equivalant > complications on the spammers' end. ISPs will have to enable end > users to configure their own rules, and everybody's filters and > whitelists will be slightly different. Imagine how spammers will > feel knowing that each of several million targets for a spam-run has > a slightly different defense, that has to be overcome in order to > deliver the email. We're achieving effectiveness rates in excess of 98% with our "one set of rules" server based defences. My personal account, which receives 400-600 emails/day, has 100 or more spams/day filtered out by the central server solution. I usually go a week or so between spams that get past those central filters - I see _many_ more FPs with my bayesian than I see spam getting through. My personally trained bayesian filtering has an absolutely abysmal track record. On the spam aimed at the false positive handling address, which by design has _no_ filtering, Bayesian has an effectiveness rate of about 50%. Yuck. No amount of personal twiddling, custom rules, explicit pattern matching in my UA is going to make much difference to that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbhKr53FmCyJjHfhAQKRmAP+KaJptICz3wiERazmCpqW/cZUr9BouZX/ xeo8X++4ZrqasqNGoR3O2v42Mj/C5xh26mHcq7Q/Wn+/jOTDpZLMGUOGAyVwiRYr tYXcYsCOuu8hHj0914SKj98nRGeiu1QVQyKOPk5OqJHJA4+hCpY5Lqw86mTVSHqg 9YzFqln7GBM= =jrcv -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 07:35:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3n8-0005Dr-7s; Thu, 25 Jan 2007 07:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3n6-0005DT-Tm for asrg@ietf.org; Thu, 25 Jan 2007 07:33:20 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA3n4-00023s-LK for asrg@ietf.org; Thu, 25 Jan 2007 07:33:20 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HA3n1-0002Nj-00; Thu, 25 Jan 2007 12:33:15 +0000 To: hannigan@gmail.com From: Tony Finch Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> Message-Id: Date: Thu, 25 Jan 2007 12:33:15 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Martin Hannigan" wrote: > >If I had to pick a technology priority to pique my interest for '07, >that I would >consider proposing as a spending item to "make mail better", it would >be centered around IP reputation. DNS blacklists have been around for a decade. Tony. -- f.a.n.finch http://dotat.at/ SOLE: NORTHEAST 6 OR 7 DECREASING 4. VERY ROUGH DECREASING SLIGHT OR MODERATE. SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 10:04:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA67j-0006Jr-Fc; Thu, 25 Jan 2007 10:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA67h-0006Io-DZ for asrg@ietf.org; Thu, 25 Jan 2007 10:02:45 -0500 Received: from paris-2.ensmp.fr ([194.214.158.197] helo=paris.ensmp.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA67g-0000GB-1o for asrg@ietf.org; Thu, 25 Jan 2007 10:02:45 -0500 Received: from [194.214.158.176] (saci.ensmp.fr [194.214.158.176]) by paris.ensmp.fr (8.13.8/8.13.8/JMMC-23/Mar/2006) with ESMTP id l0PF2Z6K028835; Thu, 25 Jan 2007 16:02:36 +0100 (MET) Message-ID: <45B8C68B.6060509@ensmp.fr> Date: Thu, 25 Jan 2007 16:02:35 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Nicol Subject: Re: [Asrg] Re: per recipient status References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <20070124234151.GA3670@zardoc.esmtp.org> <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> In-Reply-To: <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at paris.ensmp.fr with ID 45B8C68B.000 by Joe's j-chkmail (http://j-chkmail dot ensmp dot fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org David Nicol wrote: > On 1/24/07, Claus Assmann wrote: >> On one of my machines more than 95 per cent of the incoming mails >> is to unknown recipients. I do not want to receive the message data >> in that case at all. > > > good point. thanks. that would have to be fixed first of course; for > instance > DATAFIRST connections only allowed from reputable peers. I agree with Claus. Me too, I don't want to receive messages for non existent recipients. A way to fix this may be a negotiation between the server and the client, probably it's the server who shall ask for DATAFIRST. If the server don't want it then the transaction fall down to current mode. My two cents. -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 10:17:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6Lt-0006xA-18; Thu, 25 Jan 2007 10:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6Lr-0006vd-DB for asrg@ietf.org; Thu, 25 Jan 2007 10:17:23 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6Lq-0003qE-2g for asrg@ietf.org; Thu, 25 Jan 2007 10:17:23 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 19DC3403A; Thu, 25 Jan 2007 16:17:16 +0100 (CET) Date: Thu, 25 Jan 2007 16:17:16 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status Message-ID: <20070125151715.GA12259@hjp.at> Mail-Followup-To: asrg@ietf.org References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <20070124234151.GA3670@zardoc.esmtp.org> <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> <45B8C68B.6060509@ensmp.fr> Mime-Version: 1.0 In-Reply-To: <45B8C68B.6060509@ensmp.fr> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1496099784==" Errors-To: asrg-bounces@ietf.org --===============1496099784== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-25 16:02:35 +0100, Jose Marcio Martins da Cruz wrote: > David Nicol wrote: > > On 1/24/07, Claus Assmann wrote: > >> On one of my machines more than 95 per cent of the incoming mails > >> is to unknown recipients. I do not want to receive the message data > >> in that case at all. > >=20 > > good point. thanks. that would have to be fixed first of course; > > for instance DATAFIRST connections only allowed from reputable > > peers. >=20 > I agree with Claus. Me too, I don't want to receive messages for non > existent recipients. >=20 > A way to fix this may be a negotiation between the server and the > client, probably it's the server who shall ask for DATAFIRST. It has to do that anyway in the EHLO reponse. It could advertise DATAFIRST to "reputable" peers only. But I don't think that helps much, because you specifically want it for the less reputable hosts: Where some messages will be accepted by some users but rejected by others. hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFuMn7fZ+RkG8quy0RAgIIAKCQT9HN11LBJego2padRoD3vL4dhACguYI3 Y2WKFKraV5tCgdhUi+sX4iE= =w91c -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- --===============1496099784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1496099784==-- From asrg-bounces@ietf.org Thu Jan 25 11:08:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA77I-0005Bu-EL; Thu, 25 Jan 2007 11:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA77G-00059s-CO for asrg@ietf.org; Thu, 25 Jan 2007 11:06:22 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA77E-0003s5-Tb for asrg@ietf.org; Thu, 25 Jan 2007 11:06:22 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id D827A403A; Thu, 25 Jan 2007 17:06:17 +0100 (CET) Date: Thu, 25 Jan 2007 17:06:17 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: draft-hall-inline-dsn-01 (was: [Asrg] Re: bounces, and anit-spam principles) Message-ID: <20070125160617.GB12259@hjp.at> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> Mime-Version: 1.0 In-Reply-To: <45B67DB0.5070803@ehsco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0807901257==" Errors-To: asrg-bounces@ietf.org --===============0807901257== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-23 16:27:12 -0500, Eric A. Hall wrote: > On 1/23/2007 4:00 PM, Peter J. Holzer wrote: > >> MTA-resident complex content filtering with different per-recipient > >> outcomes is not compatible with recipient enumeration preceding the > >> data block; > >=20 > > It can still be done. It just needs a bit of trickery with 4xx replies. > > It's ugly as hell, and it increases mail traffic (and CPU usage for > > filtering), but it works. >=20 > see http://www.ehsco.com/misc/I-Ds/draft-hall-inline-dsn-01.txt which uses > per-recipient codes after the data block (the LMTP model) I meant "it can be done without extensions to SMTP". With extensions it can be done in a much cleaner way, of course; but that needs support in both the client and the server. A few quibbles about your draft (which I'm tempted to implement in qpsmtpd if someone implements the client side): The name INLINE-DSN doesn't describe well what it does. To me, a DSN is more than an SMTP reply, it's an entire message explaining what happened to the mail, and your extension doesn't send that. Something like DATA-RCPT-RESULT would be more descriptive (not that an SMTP client will care much about the meaning of the bytes it sends). I'm a bit dubious about the use of 3xx status codes. In the other cases where they are used (DATA, SMTP AUTH, ...) they are used to indicate to the client that it should send more data to complete the current command, not that it should send another command. It's a clever way to defer only some recipients until after data, though. Finally a question: How is it determines which of the response codes after DATA corresponds to which recipient? Do they have to be in the same order or do they have to include the recipient address? Your examples show both, but the text isn't clear. hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFuNV5fZ+RkG8quy0RArV5AJ9iQyxsU/8xrNOBk0hdzID904MMRQCggobT FsBlnJ8wV5O82VOC5E6EHFw= =PT3H -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- --===============0807901257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0807901257==-- From asrg-bounces@ietf.org Thu Jan 25 11:20:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Kj-0005vh-0K; Thu, 25 Jan 2007 11:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Ki-0005uJ-GV for asrg@ietf.org; Thu, 25 Jan 2007 11:20:16 -0500 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7Kh-0007jf-8J for asrg@ietf.org; Thu, 25 Jan 2007 11:20:16 -0500 Received: by wr-out-0506.google.com with SMTP id i22so444173wra for ; Thu, 25 Jan 2007 08:20:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q+CGjOmISn34es3/ORbVcHaLYyLbT0ztnlE5W6C+I2GKPq+hg5D3VhLncM3My1WcXoutoGMi0we6Trm6fIoc50Bx7AODu9Xn9Hn8AR0Igq4VSH2NK4E8NYoBpePBp2hrmjOV9rg3kq1IQaGHm/R8TcdQ0/9AFjc30rlkelgm5Nc= Received: by 10.78.18.3 with SMTP id 3mr1691379hur.1169742012710; Thu, 25 Jan 2007 08:20:12 -0800 (PST) Received: by 10.78.23.19 with HTTP; Thu, 25 Jan 2007 08:20:11 -0800 (PST) Message-ID: <934f64a20701250820n3f672c58y3e616d7a11a9ee0e@mail.gmail.com> Date: Thu, 25 Jan 2007 10:20:11 -0600 From: "David Nicol" To: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <20070125151715.GA12259@hjp.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17846.26016.14436.541196@world.std.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <20070124234151.GA3670@zardoc.esmtp.org> <934f64a20701241546o55f2eb17p5d9eb448823dd648@mail.gmail.com> <45B8C68B.6060509@ensmp.fr> <20070125151715.GA12259@hjp.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/07, Peter J. Holzer wrote: > > > good point. thanks. that would have to be fixed first of course; > > > for instance DATAFIRST connections only allowed from reputable > > > peers. > > > > I agree with Claus. Me too, I don't want to receive messages for non > > existent recipients. > > > > A way to fix this may be a negotiation between the server and the > > client, probably it's the server who shall ask for DATAFIRST. > > It has to do that anyway in the EHLO reponse. It could advertise > DATAFIRST to "reputable" peers only. But I don't think that helps much, > because you specifically want it for the less reputable hosts: Where > some messages will be accepted by some users but rejected by others. in the e-postage scenarios driving DATAFIRST, you would want to provide the service only for peers participating in the e-postage system. The advantage over deferred deliviry status reports becomes clear if you are trying to accept or refuse a two-cent e-mail for a million customers whose individual gatekeeper policies have the option of accepting, refusing, or haggling. Instead of trying more than a million times to send the message with one recipient at a time, DATAFIRST provides a shortcut to saying "same data as last time." As such it is not a spam reduction technology in itself, but is an optimization to make an unimplemented e-postage scheme work more smoothly. I brought it back up in response to Eric Hall's 2004 proposal, which has come under discussion again. http://www1.ietf.org/mail-archive/web/asrg/current/msg12808.html was the beginning of the discussion of it, last summer. I guess I've got just a few more months to try to patent that aspect of my particular e-postage scheme in order to woo my angels :) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 12:34:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8QS-0000m7-Nu; Thu, 25 Jan 2007 12:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8QQ-0000m1-Iy for asrg@ietf.org; Thu, 25 Jan 2007 12:30:14 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8QM-00055a-9M for asrg@ietf.org; Thu, 25 Jan 2007 12:30:14 -0500 Received: by ug-out-1314.google.com with SMTP id 72so458916ugd for ; Thu, 25 Jan 2007 09:30:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=shzV2SvoGAZ2Cjuc5FRku4IS0RLHGrgyxhzWSjN5ZmwyZlzq3pt9KVnMn2HrVvMHJhS9vc+8n4+fDjHaB88CS/UsKUFJqeQg4UFnoZJ0OGvcHRqImBi43c9cL8PIcSuWBpaVeiWVC3Ekhi8l5pJwbx4jXGNDCBj1x/mvM1L7UP8= Received: by 10.82.165.1 with SMTP id n1mr1297026bue.1169746208911; Thu, 25 Jan 2007 09:30:08 -0800 (PST) Received: by 10.78.23.19 with HTTP; Thu, 25 Jan 2007 09:30:08 -0800 (PST) Message-ID: <934f64a20701250930w33e7b514hbb0c50f73be7b8ae@mail.gmail.com> Date: Thu, 25 Jan 2007 11:30:08 -0600 From: "David Nicol" To: "Chris Lewis" Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt In-Reply-To: <45B84AAF.3010204@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> <20070123222119.GA30684@waltdnes.org> <45B84AAF.3010204@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/07, Chris Lewis wrote: > My personally trained bayesian filtering has an absolutely abysmal track > record. On the spam aimed at the false positive handling address, which > by design has _no_ filtering, Bayesian has an effectiveness rate of > about 50%. Yuck. No amount of personal twiddling, custom rules, > explicit pattern matching in my UA is going to make much difference to that. I wonder if Paul Graham was being underhanded and evil or merely naive when he claimed that the level of noise allowed to pass through Bayesian filters would be acceptable http://www.paulgraham.com/spam.html _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 13:38:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9Ra-0007qG-5T; Thu, 25 Jan 2007 13:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9RZ-0007qB-FN for asrg@ietf.org; Thu, 25 Jan 2007 13:35:29 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA9RY-00008V-03 for asrg@ietf.org; Thu, 25 Jan 2007 13:35:29 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0PIZPr28001 for ; Thu, 25 Jan 2007 13:35:25 -0500 (EST) Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 13:34:54 -0500 Message-ID: <45B8F84A.3040003@nortel.com> Date: Thu, 25 Jan 2007 13:34:50 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ASRG list Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> <20070123222119.GA30684@waltdnes.org> <45B84AAF.3010204@nortel.com> <934f64a20701250930w33e7b514hbb0c50f73be7b8ae@mail.gmail.com> In-Reply-To: <934f64a20701250930w33e7b514hbb0c50f73be7b8ae@mail.gmail.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 18:34:54.0361 (UTC) FILETIME=[81BF7090:01C740AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Nicol wrote: > On 1/25/07, Chris Lewis wrote: > >> My personally trained bayesian filtering has an absolutely abysmal track >> record. On the spam aimed at the false positive handling address, which >> by design has _no_ filtering, Bayesian has an effectiveness rate of >> about 50%. Yuck. No amount of personal twiddling, custom rules, >> explicit pattern matching in my UA is going to make much difference to >> that. > > I wonder if Paul Graham was being underhanded and evil or merely naive when > he claimed that the level of noise allowed to pass through Bayesian > filters would > be acceptable http://www.paulgraham.com/spam.html I had a long discussion (people bought popcorn to watch the fireworks, but were disappointed ;-) with another of the 2 or 3 "big name" Bayesian proselytizers at a big virus conference some years ago. At the time, I realized one simple truth - the whole thing was based on ridiculously small sample sizes. Eg: < 100 emails/day. I laughingly suggested I'd aim _my_ load at him (3-4 orders of magnitude higher), at which point he visibly winced and got rather quiet ;-) I've also found it rather disconcerting that Graham's (and others) papers about the possibility of fooling Bayes is rather egregiously flagrant arm-waving and sleight-of-hand. In all fairness, the guy I spoke to did say that TBird's Bayes was rather badly (he almost thought _deliberately_) crippled. When I reset Tbird's Bayes training, the filtering actually gets better (except for a short-lived spike in FPs), but then gets worse over time. Explain _that_ ;-) [I have this possibly naive impression that (some?) Bayes classification is vulnerable to "flooding" - smearing/smudging the spammyness/ non-spammyness of words into a vast morass of "not very anything", leading to most computed scores being so close to neutral that Bayes' conservative score thresholding treats it as "I dunno", and lets it thru. Of course, spam with few words (eg: graphical spam) is particularly hard to deal with via Bayes techniques.] He was showing interesting results with his Bayes - it even did a decent job of distinguishing viral binaries from non-virus binaries. But that wouldn't work with per-emit munging. His viral detection appeared to be largely based on making Bayes "score" variable length binary fragments, and noticing the commonality of particular code fragments in malware. But even if it worked as claimed, the vast majority of our users simply aren't interested in training Bayes (or ANYTHING ELSE) to recognize spam. "Dear CEO, senior executives, staff and shareholders, we require you to spend [in some cases VERY expensive] manhours to train/configure your filters". To which I'd get the reply "that's _your_ job, you're obviously not doing it...". I'd fire _myself_ for incompetence ;-) They want spam stopped, _period_. This is as true in the ISP world as it is in the corporate one. Out of a population of 60,000-120,000 users, with more than 10 years of experience, we've had fewer than five people ask to have their filters turned off. All of those changed their minds after I told them how many spams we block for them ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbj4Sp3FmCyJjHfhAQLwNwQA7VORT2x2N0eofJQVu64aEtc5dxKk2oT1 1FDg3kTD3LEloicq2bfYwedoKPljDQz1UCSK/th9q37RHc723a8Woyl5OqlOelqc H/7Dwq+A7e97hpTtkzBEtrl49BhQEOlHrA5P+hTUCKlKcK+vi3drb3350xWjHva5 A7ksGjyNDaY= =Mnn/ -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 14:41:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAQQ-0003S6-6h; Thu, 25 Jan 2007 14:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAQO-0003N9-3X for asrg@ietf.org; Thu, 25 Jan 2007 14:38:20 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAAQK-0007ZT-Q6 for asrg@ietf.org; Thu, 25 Jan 2007 14:38:20 -0500 Received: from [207.65.71.19] (pool-72-75-27-3.washdc.east.verizon.net [72.75.27.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 31C3815727 for ; Thu, 25 Jan 2007 13:38:14 -0600 (CST) Message-ID: <45B9070C.4060806@ehsco.com> Date: Thu, 25 Jan 2007 14:37:48 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> In-Reply-To: <20070125160617.GB12259@hjp.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/2007 11:06 AM, Peter J. Holzer wrote: > A few quibbles about your draft (which I'm tempted to implement in > qpsmtpd if someone implements the client side): > > The name INLINE-DSN doesn't describe well what it does. To me, a DSN > is more than an SMTP reply, it's an entire message explaining what > happened to the mail, and your extension doesn't send that. > Something like DATA-RCPT-RESULT would be more descriptive (not that an > SMTP client will care much about the meaning of the bytes it sends). The name isn't that important to me. I almost called it DEFERRALS (since that's what it does) but I chose the DSN name to try and clarify it a bit. Putting DEFER on the end of MAIL FROM makes some sense too. > I'm a bit dubious about the use of 3xx status codes. In the other cases > where they are used (DATA, SMTP AUTH, ...) they are used to indicate to > the client that it should send more data to complete the current > command, not that it should send another command. Yeah, it usually means "need more input" although there's nothing else that means "I'll tell you later" either. Waiting for the message body to be received probably counts as "need more input" anyway. > Finally a question: How is it determines which of the response codes > after DATA corresponds to which recipient? Do they have to be in the > same order or do they have to include the recipient address? Your > examples show both, but the text isn't clear. Ordering is always preserved in SMTP (even where pipelining is enabled), and text after the code is usually ignored for protocol purposes (usually), so that's presumably what I meant but I'd have to find my brain from 2004 to answer for sure. I suppose I should fix this in the next draft, as well as rename the extensions. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 18:23:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HADsm-0006Vz-KI; Thu, 25 Jan 2007 18:19:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HADsl-0006Rh-DS for asrg@ietf.org; Thu, 25 Jan 2007 18:19:51 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HADsk-00034f-5C for asrg@ietf.org; Thu, 25 Jan 2007 18:19:51 -0500 Received: by an-out-0708.google.com with SMTP id d30so354703and for ; Thu, 25 Jan 2007 15:19:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aEv4zNqyRNx76kDSaFZ10Fj6luoZfFlQZh0GvQAEalAQzefKVFqylKOM7Xm23xx2O145m+Xk0ISH4M73oJDo0tFSBb/U+f5i1cURQqC4qxIEovitRblTpxiZWA0646534BWTWnV1GNeH0WInnRts0/hd8xQUT8JFW4TS+fKnlfc= Received: by 10.65.232.18 with SMTP id j18mr3947287qbr.1169767189477; Thu, 25 Jan 2007 15:19:49 -0800 (PST) Received: by 10.64.179.14 with HTTP; Thu, 25 Jan 2007 15:19:49 -0800 (PST) Message-ID: <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> Date: Thu, 25 Jan 2007 18:19:49 -0500 From: "Martin Hannigan" To: "Tony Finch" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/07, Tony Finch wrote: > "Martin Hannigan" wrote: > > > >If I had to pick a technology priority to pique my interest for '07, > >that I would > >consider proposing as a spending item to "make mail better", it would > >be centered around IP reputation. > > DNS blacklists have been around for a decade. "IP reputation" is a different concept than black list. By tracking the historical behavoir of /32's or larger allocations, we could develop a profile of the behaviors that will eventually establish a baseline for those allocations as "good" "nuetral" or "bad", to keep it kind of simple. A lot of this data is already out there. Take the case of 60 /8 (IIRC). It was allocated to APNIC by IANA and almost immediately spammers began unauthorized advertisements of prefixes high in this block, "politely" staying ahead of the RIR allocations, but using them as "fresh" address space. In a reputation system, those blocks would likely be marked bad since they are unallocated at the RIR level. Since they are allocated out of IANA, they would be legitimate to most RBL's until they were caught in the act, but by the time they are observed, the allocations are swapped. The biggest problem I am having this year, so far, is justifying spending money on anything related to mail that will not be a) very long life and b) really make it better. The more knobs I have, the better, and I think IP reputation is the place to be this year. Account verification before data is "better" in my situation, and technologies to block or drop connections en masse will have more of a likelihood of getting funded internally. The spam conference is coming up in Cambridge. I'm looking forward to it. YMMV. -M< _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 18:54:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEPF-0005KU-18; Thu, 25 Jan 2007 18:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEPE-0005IQ-6T for asrg@ietf.org; Thu, 25 Jan 2007 18:53:24 -0500 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAEP3-0007WR-0i for asrg@ietf.org; Thu, 25 Jan 2007 18:53:24 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41326) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1HAEOp-00075l-VR (Exim 4.63) (return-path ); Thu, 25 Jan 2007 23:52:59 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HAEOp-0004K0-Mk (Exim 4.54) (return-path ); Thu, 25 Jan 2007 23:52:59 +0000 Date: Thu, 25 Jan 2007 23:52:59 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Martin Hannigan Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> Message-ID: References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, 25 Jan 2007, Martin Hannigan wrote: > On 1/25/07, Tony Finch wrote: > > "Martin Hannigan" wrote: > > > > > >If I had to pick a technology priority to pique my interest for '07, > > >that I would > > >consider proposing as a spending item to "make mail better", it would > > >be centered around IP reputation. > > > > DNS blacklists have been around for a decade. > > "IP reputation" is a different concept than black list. In what way? You seem to imply that because reputation is complicated, that necessarily implies a complicated protocol. DNS blacklists individually give you a binary good/bad result for each IP address or domain name, but exactly what they mean by good or bad is subtle and depends on the blacklist, not the protocol. It is wrong to assume that the simplicity of the DNS blacklist protocol means that DNS blacklist semantics are simple. > By tracking the historical behavoir of /32's or larger allocations, we > could develop a profile of the behaviors that will eventually establish > a baseline for those allocations as "good" "nuetral" or "bad", to keep > it kind of simple. A lot of this data is already out there. Yes, blacklists do this already, though they are binary not ternary. > Take the case of 60 /8 (IIRC). It was allocated to APNIC by IANA and > almost immediately spammers began unauthorized advertisements of > prefixes high in this block, "politely" staying ahead of the RIR > allocations, but using them as "fresh" address space. In a reputation > system, those blocks would likely be marked bad since they are > unallocated at the RIR level. Since they are allocated out of IANA, they > would be legitimate to most RBL's until they were caught in the act, but > by the time they are observed, the allocations are swapped. You are assuming that blacklists are necessarily based on post-hoc observation the outgoing email behaviour of IP addresses, and that there are no blacklists that are based on prior information such as allocations and hijacking. However, you are wrong: an old example is the DUL, but for something closer to what you have in mind, have a look at http://www.completewhois.com/bogons/bogons_usage.htm It's worth noting that the existing RHSBL support in MTAs and anti-spam software is good enough to be used for reputation lookups for DKIM. What is difficult is gathering the data to create a blacklist or whitelist for domains in DKIM signatures. This is really hard: it is very difficult to maintain an IP DNSBL that is both effective against spam and has a low false-positive rate, and I expect it to take a long time before there is enough operational experience to do the same for DKIM. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN: NORTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 19:18:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEmV-00064V-9k; Thu, 25 Jan 2007 19:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEmU-00064Q-Gq for asrg@ietf.org; Thu, 25 Jan 2007 19:17:26 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAEmS-0003qY-15 for asrg@ietf.org; Thu, 25 Jan 2007 19:17:26 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l0Q0GbNf014795; Thu, 25 Jan 2007 16:16:37 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l0Q0GbNu014791; Thu, 25 Jan 2007 16:16:37 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 25 Jan 2007 16:16:36 -0800 (PST) From: "william(at)elan.net" To: Martin Hannigan Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> Message-ID: References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Tony Finch , asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, 25 Jan 2007, Martin Hannigan wrote: > On 1/25/07, Tony Finch wrote: >> "Martin Hannigan" wrote: >> > >> >If I had to pick a technology priority to pique my interest for '07, >> >that I would >> >consider proposing as a spending item to "make mail better", it would >> >be centered around IP reputation. >> >> DNS blacklists have been around for a decade. > > > > "IP reputation" is a different concept than black list. Not really. > By tracking the historical behavoir of /32's or larger allocations, we > could develop a profile of the behaviors that will eventually establish > a baseline for those allocations as "good" "nuetral" or "bad", to keep > it kind of simple. A lot of this data is already out there. Blacklists are a form of reputation with single yes/no answer for single type of question. More complex scoring similar or even same as you describe is already in use by some companies spam products internally, they are just not making data available externally in some general protocol (spamcop to a degree does). Others also do sort of ip reputation by locally combining several blacklists & whitelists and calculating score based on that as well as based on bayesean filters. I also at some point did test run with calculating score for an ip and then block based on score for existing spamassasin scores (mixed results due to large number of connections coming from different zombied dsl/cable ips - I need to improve way of generating list of ip blocks & assigning general reputation to it for use with this system). > Take the case of 60 /8 (IIRC). It was allocated to APNIC by IANA and > almost immediately > spammers began unauthorized advertisements of prefixes high in this > block, "politely" staying ahead of the RIR allocations, but using them > as "fresh" address space. In a reputation system, those blocks would > likely be marked bad since they are unallocated > at the RIR level. These are bogon ips and some of us are rejecting them already, see http://www.completewhois.com/bogons/ and blacklist for it is bogons.dnsiplists.completewhois.com. BTW its interesting to note that some did not believe me when I said 3+ years ago that spammers would be doing it and it needs to be dealt with. > Since they are allocated out of IANA, they would be legitimate to most > RBL's until they were caught in the act, but by the time they are > observed, the allocations are swapped. Possible I do not have enough details, but my understanding is that spammer[s] (I actually think its same one) were not staying close enough ahead (need to be within 1-2 days of allocation and RIRs actually do not always do them sequentially), but just taking some (somewhat random) higher-end ip range within unallocated space or doing entire /8. Of course its possible they are even smarter in the last few cases. > The biggest problem I am having this year, so far, is justifying > spending money on anything related to mail that will not be > a) very long life and b) > really make it better. Well, yes... but explain that with current internal technologies "very long life" is still not achievable and you do need to get some improvement to get cleaner inbox. > The more knobs I have, the better, and I think > IP reputation is the place to be this year. Number of folks are slowly working on it but its not really that likely this year would make substantial difference I think. > Account verification before data is "better" in my situation To be able to do apply user policies when making decisions you need to do it after RCPT TO. Using blacklist at the start is good but for most lists (including reputation based ones) it would not be appropriate (i.e. you must for example accept email to postmaster). >, and technologies to block or drop connections en masse will have more > of a likelihood of getting funded internally. Really? The more "en masse" you do the more good mail would be lost and reality is that there appears to be substantial enough difference between users that that doing it "en mass" for ISP or for large enough enterprise is probably not ok. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 20:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGBv-0004h8-4a; Thu, 25 Jan 2007 20:47:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGBu-0004h0-0p for asrg@ietf.org; Thu, 25 Jan 2007 20:47:46 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAGBr-00041X-SB for asrg@ietf.org; Thu, 25 Jan 2007 20:47:45 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id 49CC658915C; Thu, 25 Jan 2007 20:47:39 -0500 (EST) Received: from webmaillogin.com (fr6.webmaillogin.com [216.40.35.70]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id 6956F58A9FC for ; Thu, 25 Jan 2007 20:37:44 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk3.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 4513775 for asrg@ietf.org; Thu, 25 Jan 2007 20:32:11 -0500 From: Subject: Re: [Asrg] Re: bounces, and anti-spam principles To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Thu, 25 Jan 2007 19:32:11 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I'm grouping together responses to several individual=20 points on this thread. [comment #1] >> In any case, I still contend that simplistic blocking by=20 >>IP address =20 >> or domain name is a very poor approach, and for a whole=20 >>variety of =20 >> reasons. > I will contend that there cannot be a content filter=20 >that can =20 > reliably separate spam from non spam.=20 It doesn't NEED to be 100.000% accurate. The bulk of mail most people receive comes from people=20 they are familiar with, and which fits certain patterns.=20 A given sender (mailing list etc) will typically have a=20 signature file, for instance. I know that Aunt Matilda is=20 NOT going to send me an E-mail containing a JavaScript=20 decryption routine, or an ActiveX enclosure. She also is=20 not going to send me an executable attachment. If stuff=20 like that arrives here, it is safe to presume it is NOT=20 from her, no matter what the From: address says (and even=20 if it WAS sent from her computer). If you know what mail from your Yahoogroups AfricanViolets=20 mail looks like, you could for example specify to look for=20 that common content in mail claiming to come from that=20 mailing list. >Any non-spam message received =20 > by one person would be spam if it were sent to 10=20 >million harvested =20 > addresses.=20 Sure, and that's why the recipient knowing the sender is=20 one of the key criteria. Stuff that you might accept from=20 soomeone you know and trust might be spam if someone you'd=20 never heard of sent it to you. It's ABSOLUTELY not enough=20 to test subject/from/IP/domain. > OTOH, taking the definition of spam as=20 >Unsolicited Bulk =20 > Email makes detecting a spamming IP address almost=20 >trivial.=20 I guess that depends on what you call "bulk", and how you=20 propose to detect it. Again, whatever rule you put into=20 effect (on a global-type basis) is going to be dFrom asrg-bounces@ietf.org Thu Jan 25 20:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGBv-0004h8-4a; Thu, 25 Jan 2007 20:47:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGBu-0004h0-0p for asrg@ietf.org; Thu, 25 Jan 2007 20:47:46 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAGBr-00041X-SB for asrg@ietf.org; Thu, 25 Jan 2007 20:47:45 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id 49CC658915C; Thu, 25 Jan 2007 20:47:39 -0500 (EST) Received: from webmaillogin.com (fr6.webmaillogin.com [216.40.35.70]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id 6956F58A9FC for ; Thu, 25 Jan 2007 20:37:44 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk3.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 4513775 for asrg@ietf.org; Thu, 25 Jan 2007 20:32:11 -0500 From: Subject: Re: [Asrg] Re: bounces, and anti-spam principles To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Thu, 25 Jan 2007 19:32:11 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I'm grouping together responses to several individual=20 points on this thread. [comment #1] >> In any case, I still contend that simplistic blocking by=20 >>IP address =20 >> or domain name is a very poor approach, and for a whole=20 >>variety of =20 >> reasons. > I will contend that there cannot be a content filter=20 >that can =20 > reliably separate spam from non spam.=20 It doesn't NEED to be 100.000% accurate. The bulk of mail most people receive comes from people=20 they are familiar with, and which fits certain patterns.=20 A given sender (mailing list etc) will typically have a=20 signature file, for instance. I know that Aunt Matilda is=20 NOT going to send me an E-mail containing a JavaScript=20 decryption routine, or an ActiveX enclosure. She also is=20 not going to send me an executable attachment. If stuff=20 like that arrives here, it is safe to presume it is NOT=20 from her, no matter what the From: address says (and even=20 if it WAS sent from her computer). If you know what mail from your Yahoogroups AfricanViolets=20 mail looks like, you could for example specify to look for=20 that common content in mail claiming to come from that=20 mailing list. >Any non-spam message received =20 > by one person would be spam if it were sent to 10=20 >million harvested =20 > addresses.=20 Sure, and that's why the recipient knowing the sender is=20 one of the key criteria. Stuff that you might accept from=20 soomeone you know and trust might be spam if someone you'd=20 never heard of sent it to you. It's ABSOLUTELY not enough=20 to test subject/from/IP/domain. > OTOH, taking the definition of spam as=20 >Unsolicited Bulk =20 > Email makes detecting a spamming IP address almost=20 >trivial.=20 I guess that depends on what you call "bulk", and how you=20 propose to detect it. Again, whatever rule you put into=20 effect (on a global-type basis) is going to be discovered=20 by spammers and they will engineer their sending patterns=20 to avoid violating it. That's why you need a really=20 narrow and twisty 'gauntlet' they must negotiate, with=20 DIFFERENT RULES for different recipients, where they don't=20 know and basically can not figure out what rules they=20 would have to comply with to get a message through to a=20 particular person. That said, there should be a default set of rules which=20 will get "safe/small" mail through from unknown senders,=20 as long as it doesn't "look like" spam (again,=20 SpamAssassin is not perfect, but it's pretty good once=20 HTML, scripting, and attachment ruses are denied to them=20 for the purpose). > The trick =20 > is to stop accepting mail from that IP address only=20 >until it has =20 > cleaned up.=20 Again, when you have a LOT of users (and possibly MANY=20 servers) behind a NAT router, denying mail from that IP=20 address results in simply too much collateral damage.=20 More to the point, it's a very blunt instrument for the=20 job, and it's relatively simple to do very much better. > Once the spam is gone there is no need to=20 >block the =20 > address unless it has proven to be a repeat offender=20 >without an =20 > effective process for shutting the spammers down. What about when the flow of spam is interleaved with all=20 sorts of good/important traffic as well? [comment #2] > Speaking as an ISP, what's unrealistic in these utopian=20 >end-user > filtering only arguments is costs. >=20 > Suffice it to say that we can add fast, capable mail=20 >servers and see > them flooded in a matter of hours. I'm not saying that end-user spam filtering is the ONLY=20 approach that should be used. On the other hand, it is=20 likely to be the most accurate and least objectionable=20 from a user standpoint. Plus, it is the most likely to=20 reject spam in a way that corresponds with how a USER=20 would decide it's spam. (I will open mail from a friend=20 with the same subject line that I would discard if it came=20 from someone I didn't know...) > Pushing all the filtering to the end-user would make=20 >that much worse. There is a lot of spam which is obvious. That includes=20 messages which contain links to known-spam-promoted Web=20 sites (at least in the absence of contradicting factors,=20 say being from a list discussing spam senders!) It also includes, for example, messages which are=20 identical to messages that some number (dozens?=20 hundreds?) of other recipients at the same ISP have=20 already reported as being "spam". One would think that=20 ISPs could locate and perhaps recategorize identical=20 messages (again, perhaps tempered by a specific recipient=20 rule) which are still queued and have not yet been=20 delivered to their remaining customers. Yahoo, for all their claims, does a pretty fair job of=20 only sequestering spam messages, although an awful lot of=20 obvious spam still curiously slips through their filters. ...and a user should be able to selectively prevent=20 blocking of mail that otherwise would get blocked. But let me state again (and this is part of what made me=20 respond, starting this sub-thread) is that it is virtually=20 NEVER a good idea to send a bounce message=20 after-SMTP-time, because you can't be sure where to send=20 it, and most likely you are just harassing another=20 innocent victim. Far better to just toss the mail. If=20 you are going to alert anybody, it makes more sense to=20 offer the offending mail (tagged accordingly) to the=20 intended recipient so that THEY can make the final=20 decision on what to do with it. > Being able to "slam the phone down" on miscreant IP=20 >blocks at the > accept() or helo is much, much, less processing than=20 >going thru the > entire SMTP interaction and whatever it takes to pass=20 >processing off to an end-user. It's true that it costs less, but it's also true that it=20 blocks a lot of innocent and legitimate mail that might be originating from the same IP address (NAT router?). There=20 could be dozens, hundreds, or even thousands oiscovered=20 by spammers and they will engineer their sending patterns=20 to avoid violating it. That's why you need a really=20 narrow and twisty 'gauntlet' they must negotiate, with=20 DIFFERENT RULES for different recipients, where they don't=20 know and basically can not figure out what rules they=20 would have to comply with to get a message through to a=20 particular person. That said, there should be a default set of rules which=20 will get "safe/small" mail through from unknown senders,=20 as long as it doesn't "look like" spam (again,=20 SpamAssassin is not perfect, but it's pretty good once=20 HTML, scripting, and attachment ruses are denied to them=20 for the purpose). > The trick =20 > is to stop accepting mail from that IP address only=20 >until it has =20 > cleaned up.=20 Again, when you have a LOT of users (and possibly MANY=20 servers) behind a NAT router, denying mail from that IP=20 address results in simply too much collateral damage.=20 More to the point, it's a very blunt instrument for the=20 job, and it's relatively simple to do very much better. > Once the spam is gone there is no need to=20 >block the =20 > address unless it has proven to be a repeat offender=20 >without an =20 > effective process for shutting the spammers down. What about when the flow of spam is interleaved with all=20 sorts of good/important traffic as well? [comment #2] > Speaking as an ISP, what's unrealistic in these utopian=20 >end-user > filtering only arguments is costs. >=20 > Suffice it to say that we can add fast, capable mail=20 >servers and see > them flooded in a matter of hours. I'm not saying that end-user spam filtering is the ONLY=20 approach that should be used. On the other hand, it is=20 likely to be the most accurate and least objectionable=20 from a user standpoint. Plus, it is the most likely to=20 reject spam in a way that corresponds with how a USER=20 would decide it's spam. (I will open mail from a friend=20 with the same subject line that I would discard if it came=20 from someone I didn't know...) > Pushing all the filtering to the end-user would make=20 >that much worse. There is a lot of spam which is obvious. That includes=20 messages which contain links to known-spam-promoted Web=20 sites (at least in the absence of contradicting factors,=20 say being from a list discussing spam senders!) It also includes, for example, messages which are=20 identical to messages that some number (dozens?=20 hundreds?) of other recipients at the same ISP have=20 already reported as being "spam". One would think that=20 ISPs could locate and perhaps recategorize identical=20 messages (again, perhaps tempered by a specific recipient=20 rule) which are still queued and have not yet been=20 delivered to their remaining customers. Yahoo, for all their claims, does a pretty fair job of=20 only sequestering spam messages, although an awful lot of=20 obvious spam still curiously slips through their filters. ...and a user should be able to selectively prevent=20 blocking of mail that otherwise would get blocked. But let me state again (and this is part of what made me=20 respond, starting this sub-thread) is that it is virtually=20 NEVER a good idea to send a bounce message=20 after-SMTP-time, because you can't be sure where to send=20 it, and most likely you are just harassing another=20 innocent victim. Far better to just toss the mail. If=20 you are going to alert anybody, it makes more sense to=20 offer the offending mail (tagged accordingly) to the=20 intended recipient so that THEY can make the final=20 decision on what to do with it. > Being able to "slam the phone down" on miscreant IP=20 >blocks at the > accept() or helo is much, much, less processing than=20 >going thru the > entire SMTP interaction and whatever it takes to pass=20 >processing off to an end-user. It's true that it costs less, but it's also true that it=20 blocks a lot of innocent and legitimate mail that might be originating from the same IP address (NAT router?). There=20 could be dozens, hundreds, or even thousands of innocent=20 users affected. IMHO, such innocent users who found their messages blocked=20 might have legal recourse against SOMEONE... it's simply=20 far too blunt an instrument. > Put another way, you can have almost unfiltered access=20 >and > near-perfect spam filtering! >=20 > Here's how to do it: >=20 > Get your own link to the backbone. >=20 > Set up your own mail servers etc. >=20 > Hire one or more secretaries to pre-screen your email=20 >according to > rules you have trained them in. >=20 > It might cost a few thousand a month, but surely in the=20 >face of all > this expressed urgency about the pitfalls of centralized=20 >filtering > it's a small price to pay. As more and more businesses become dependent on the=20 Internet, and timely delivery of communications, such a=20 cavalier attitude is going to lead to business failures at=20 ISPs who don't realize that this isn't "just a hobby for=20 computer geeks" anymore. [comment #3] >> Absolutely, and that's a good reason why blocking by=20 >> either IP address or domain name is such a bad solution.=20 >> A fine-grained whitelist which specifies ALLOWED=20 >>behavior=20 >> on a per-sender basis, on the other hand, can easily=20 >>allow=20 >> or block messages from a given sender ON A=20 >> MESSAGE-BY-MESSAGE basis, so that their legitimate=20 >> messages get delivered but the (zombie) messages being=20 >> sent by their same (infected)machine, using the same=20 >>mail=20 >> servers and same permissions/certifications but which do=20 >> not look the way that sender's messages are expected to=20 >> look (by the recipient!) are efficiently and accurately=20 >> identified and blocked. >> >> So "rehabilitation" isn't even an issue. >=20 > So the zombie becomes unable to emit spam, but there's=20 >no incentive to > fix it so it's still available to the botmaster for use=20 >as a C&C > machine, web/DNS server, and DDoS participant. I'd=20 >prefer that it get > uninfected. Obviously, that is ideal, but the problem is that after=20 (first!) SMTP time, the (intermediary, or final) recipient=20 doesn't really know who they ought to notify...!=20 Notifying the wrong person, or someone who has no control=20 over the situation, probably does more harm than good. Again, I don't believe it is possible to prevent unwanted=20 mail from being injected into the Internet. What=20 ultimately will stop it is once its likelihood of success=20 is SO small that it's simply not worth attempting it. People don't write viruses for Coleco ADAM computers=20 simply because there are very few of those connected to=20 the Internet. The chances of the author's creation=20 encountering a vulnerable system is simply too low. [comment #4] > "spam" is a slang word, which is often used to describe=20 >*A SUBSET OF* > unwanted email. Some legal jurisdictions have=20 >legislation that defines > spam very narrowly. If you insist on blocking "spam",=20 >you *WILL* end up > spending a lot of time and money in court cases where... >=20 > 1) the spammer insists that his spam is "not-spam"=20 >because of some > technicality. Expect to see lots of legal "is not spam;=20 >is so; is not; > is so; is not" being billed at lawyers' regular rates.=20 > And of course, > you can rest assured that the politicians who enact=20 >legislation will > make exemptions for solicitations for campaign=20 >contributions. Any > "spam-filters" that block any "not-spam" *WILL* get hit=20 >with > cease-and-desist orders That is one further reason why the RECIPIENT should be the=20 person to judge what they are and are not willing to=20 receive, and from who. Senders basically have no legal=20 recourse if somebody chooses to delete that sender's mail=20 from their Inbox, whether they have read it or not. > 2) saying that Joe Blow sends spam is equivalant to=20 >calling him a > spammer. Watch the defamation (libel/slander) lawsuits=20 >fly. There have already been such suits against blacklist=20 management organizations. =20 > However, if you block "unwanted email" rather than=20 >"spam"... >=20 > 1) spammef innocent=20 users affected. IMHO, such innocent users who found their messages blocked=20 might have legal recourse against SOMEONE... it's simply=20 far too blunt an instrument. > Put another way, you can have almost unfiltered access=20 >and > near-perfect spam filtering! >=20 > Here's how to do it: >=20 > Get your own link to the backbone. >=20 > Set up your own mail servers etc. >=20 > Hire one or more secretaries to pre-screen your email=20 >according to > rules you have trained them in. >=20 > It might cost a few thousand a month, but surely in the=20 >face of all > this expressed urgency about the pitfalls of centralized=20 >filtering > it's a small price to pay. As more and more businesses become dependent on the=20 Internet, and timely delivery of communications, such a=20 cavalier attitude is going to lead to business failures at=20 ISPs who don't realize that this isn't "just a hobby for=20 computer geeks" anymore. [comment #3] >> Absolutely, and that's a good reason why blocking by=20 >> either IP address or domain name is such a bad solution.=20 >> A fine-grained whitelist which specifies ALLOWED=20 >>behavior=20 >> on a per-sender basis, on the other hand, can easily=20 >>allow=20 >> or block messages from a given sender ON A=20 >> MESSAGE-BY-MESSAGE basis, so that their legitimate=20 >> messages get delivered but the (zombie) messages being=20 >> sent by their same (infected)machine, using the same=20 >>mail=20 >> servers and same permissions/certifications but which do=20 >> not look the way that sender's messages are expected to=20 >> look (by the recipient!) are efficiently and accurately=20 >> identified and blocked. >> >> So "rehabilitation" isn't even an issue. >=20 > So the zombie becomes unable to emit spam, but there's=20 >no incentive to > fix it so it's still available to the botmaster for use=20 >as a C&C > machine, web/DNS server, and DDoS participant. I'd=20 >prefer that it get > uninfected. Obviously, that is ideal, but the problem is that after=20 (first!) SMTP time, the (intermediary, or final) recipient=20 doesn't really know who they ought to notify...!=20 Notifying the wrong person, or someone who has no control=20 over the situation, probably does more harm than good. Again, I don't believe it is possible to prevent unwanted=20 mail from being injected into the Internet. What=20 ultimately will stop it is once its likelihood of success=20 is SO small that it's simply not worth attempting it. People don't write viruses for Coleco ADAM computers=20 simply because there are very few of those connected to=20 the Internet. The chances of the author's creation=20 encountering a vulnerable system is simply too low. [comment #4] > "spam" is a slang word, which is often used to describe=20 >*A SUBSET OF* > unwanted email. Some legal jurisdictions have=20 >legislation that defines > spam very narrowly. If you insist on blocking "spam",=20 >you *WILL* end up > spending a lot of time and money in court cases where... >=20 > 1) the spammer insists that his spam is "not-spam"=20 >because of some > technicality. Expect to see lots of legal "is not spam;=20 >is so; is not; > is so; is not" being billed at lawyers' regular rates.=20 > And of course, > you can rest assured that the politicians who enact=20 >legislation will > make exemptions for solicitations for campaign=20 >contributions. Any > "spam-filters" that block any "not-spam" *WILL* get hit=20 >with > cease-and-desist orders That is one further reason why the RECIPIENT should be the=20 person to judge what they are and are not willing to=20 receive, and from who. Senders basically have no legal=20 recourse if somebody chooses to delete that sender's mail=20 from their Inbox, whether they have read it or not. > 2) saying that Joe Blow sends spam is equivalant to=20 >calling him a > spammer. Watch the defamation (libel/slander) lawsuits=20 >fly. There have already been such suits against blacklist=20 management organizations. =20 > However, if you block "unwanted email" rather than=20 >"spam"... >=20 > 1) spammer says "wahhh, wahhh, wahhh, my 'valuable=20 >information' is > 'not-spam'" and you can enthusiastically agree. The the=20 >customer still > doesn't want it. "Because I said so" should be=20 >sufficient reason. Right. And the recipient can reasonably set (even=20 completely arbitrary!) rules to determine that they do and=20 don't want delivered to their Inbox. [snip] > Similarly, don't try to define "the S-word" in=20 >technical terms. A > bunch of geeks sitting at their keyboards are no match=20 >for a nit-picking > lawyer who was the captain of his class debating team.=20 > It's effectively > a pro se defense against high-powered lawyers, and the=20 >results are very > predictable. Don't engage in a battle you can't win.=20 > Go with... > - our customer says he doesn't want your emails. No,=20 >we don't know > why he doesn't want your emails. > - the customer is always right; end of story. > Don't give the spammers' lawyers anything to attack. Bingo. > - I am a customer of clss.net (Aurora Internet) >=20 > - they have a modified Qmail that generates 550=20 >SMTP-stage rejects > (i.e. *NOT* a DSN) based on a customer-configurable=20 >control file in > the customer's home directory. There are separate=20 >rule files for > sub-accounts. E.g. I point my domain MX at their=20 >server. abuse and > postmaster are basically unfiltered compared to this=20 >address. >=20 > - step 1 is to declare a whitelist of emails that I=20 >accept > unconditionally That's good, but I basically want finer control than=20 that... I want to be able to open up the window (like the=20 keyway on a lock) to allow the messages in that I expect=20 from each sender. Even a sender that I would accept an=20 executable attachment from, I might refuse a message=20 containing ActiveX or JavaScript. > - I don't want email from residential machines on=20 >dynamic IP addresses > sending direct-to-MX. So I block based on dynamic IP=20 >DNSbls, regexp > filter against rDNS, and obviously block email from=20 >machines with no > rDNS whatsoever. Obviously you can (and should) set the rules however you=20 want, as recipient. I wouldn't want, for example, my=20 ISP(s) forcing those same rules on me. > - I don't talk to myself. I don't want email from=20 >people who lie in > their email, by including "waltdnes.org" in the HELO=20 >or return-path. > So I block those emails. Certainly reasonable! > - I don't want email from certain countries, so I block=20 >them, using > country-codes in rDNS and return-path Also reasonable enough, as long as you are setting those=20 rules for yourself. Personally, I WILL accept=20 (legitimate) mails from just about any country anywhere=20 (including particularly countries I have visited, and=20 that's a list of almost 50 countries). And on my travels,=20 I have sent E-mails from (say) Beijing. I would be=20 annoyed if those E-mails had been blocked just because I=20 happened to have sent them from China. Again, your Inbox, your rules. > Executive summary... >=20 > - blocking email, because it meets some technical=20 >criteria, is easier > on the technical side, but introduces legal problems >=20 > - blocking email, because the customer said so, may be=20 >harder > technically, but avoids legal problems >=20 > - any complications on the anti-spam side are=20 >outweighed by equivalant > complications on the spammers' end. ISPs will have=20 >to enable end > users to configure their own rules, and everybody's=20 >filters and > whitelists will be slightly different. Imagine how=20 >spammers will > feel knowing that each of several million targets for=20 >a spam-run has > a slightly different defense, that has to be overcome=20 >in order to > deliver the email. EXACTLY. But also, knowing that all the classical ruses=20 to avoid spam classification (text as image, embedded=20 links, attachments, scripting, disguised HTML links, etc=20 etc) are a priori denied them.... certainly takes a major=20 bite out of spammers. And only allowingr says "wahhh, wahhh, wahhh, my 'valuable=20 >information' is > 'not-spam'" and you can enthusiastically agree. The the=20 >customer still > doesn't want it. "Because I said so" should be=20 >sufficient reason. Right. And the recipient can reasonably set (even=20 completely arbitrary!) rules to determine that they do and=20 don't want delivered to their Inbox. [snip] > Similarly, don't try to define "the S-word" in=20 >technical terms. A > bunch of geeks sitting at their keyboards are no match=20 >for a nit-picking > lawyer who was the captain of his class debating team.=20 > It's effectively > a pro se defense against high-powered lawyers, and the=20 >results are very > predictable. Don't engage in a battle you can't win.=20 > Go with... > - our customer says he doesn't want your emails. No,=20 >we don't know > why he doesn't want your emails. > - the customer is always right; end of story. > Don't give the spammers' lawyers anything to attack. Bingo. > - I am a customer of clss.net (Aurora Internet) >=20 > - they have a modified Qmail that generates 550=20 >SMTP-stage rejects > (i.e. *NOT* a DSN) based on a customer-configurable=20 >control file in > the customer's home directory. There are separate=20 >rule files for > sub-accounts. E.g. I point my domain MX at their=20 >server. abuse and > postmaster are basically unfiltered compared to this=20 >address. >=20 > - step 1 is to declare a whitelist of emails that I=20 >accept > unconditionally That's good, but I basically want finer control than=20 that... I want to be able to open up the window (like the=20 keyway on a lock) to allow the messages in that I expect=20 from each sender. Even a sender that I would accept an=20 executable attachment from, I might refuse a message=20 containing ActiveX or JavaScript. > - I don't want email from residential machines on=20 >dynamic IP addresses > sending direct-to-MX. So I block based on dynamic IP=20 >DNSbls, regexp > filter against rDNS, and obviously block email from=20 >machines with no > rDNS whatsoever. Obviously you can (and should) set the rules however you=20 want, as recipient. I wouldn't want, for example, my=20 ISP(s) forcing those same rules on me. > - I don't talk to myself. I don't want email from=20 >people who lie in > their email, by including "waltdnes.org" in the HELO=20 >or return-path. > So I block those emails. Certainly reasonable! > - I don't want email from certain countries, so I block=20 >them, using > country-codes in rDNS and return-path Also reasonable enough, as long as you are setting those=20 rules for yourself. Personally, I WILL accept=20 (legitimate) mails from just about any country anywhere=20 (including particularly countries I have visited, and=20 that's a list of almost 50 countries). And on my travels,=20 I have sent E-mails from (say) Beijing. I would be=20 annoyed if those E-mails had been blocked just because I=20 happened to have sent them from China. Again, your Inbox, your rules. > Executive summary... >=20 > - blocking email, because it meets some technical=20 >criteria, is easier > on the technical side, but introduces legal problems >=20 > - blocking email, because the customer said so, may be=20 >harder > technically, but avoids legal problems >=20 > - any complications on the anti-spam side are=20 >outweighed by equivalant > complications on the spammers' end. ISPs will have=20 >to enable end > users to configure their own rules, and everybody's=20 >filters and > whitelists will be slightly different. Imagine how=20 >spammers will > feel knowing that each of several million targets for=20 >a spam-run has > a slightly different defense, that has to be overcome=20 >in order to > deliver the email. EXACTLY. But also, knowing that all the classical ruses=20 to avoid spam classification (text as image, embedded=20 links, attachments, scripting, disguised HTML links, etc=20 etc) are a priori denied them.... certainly takes a major=20 bite out of spammers. And only allowing executable attachments, HTML, and "big"=20 messages from known/trusted senders basically eliminates=20 E-mail as a vector for virus/worm propagation, which takes=20 a big bite out of spambot zombie recruitment. That, all=20 by itself, is a huge improvement in the spam=20 detection/blocking situation. [comment #5] > All I can say is, you are certainly welcome to block any=20 >mail you please,=20 > and no cooperation from other MTA operators is required,=20 >nor is any=20 > meeting of the IETF. The only purpose for the IETF=20 >involvement is to=20 > coordinate cooperative action. Since the IETF is=20 >voluntary, the action=20 > needs to be of benefit to all participants, and that=20 >greatly restricts the=20 > field of actions practical for widespread=20 >implementation. But it doesn't=20 > in any way restrict what you as an individual can do. That's certainly true, and one advantage of fine-grained=20 recipient blocking is that it doesn't require any great=20 worldwide consensus, nor any re-engineering of Internet=20 infrastructure. What WOULD be helpful, though, would be a recognition by=20 the IETF that: a) such fine-grained per-sender by-recipient blocking=20 (and hopefully augmented by subsequent content scanning)=20 is an effective and desirable approach to the problem, and b) in the general case, blocking of all non-whitelisted=20 E-mails containing HTML, scripting (probably covered under=20 HTML... is it possible to put in scripting without HTML?),=20 or attachments is a "best practice". (It is probably a=20 good idea to suggest including a maximum message size,=20 too, as a way of preventing "denial of service" attacks by=20 sending big E-mails to someone which would be expected to=20 fill their E-mail inbox to overflowing, blocking=20 subsequent legitimate E-mails). That would at least provide a direction forward which=20 would make for a huge improvement, avoid the legal issues=20 of blocking e-mails too crudely, and take a big bite out=20 of spambot zombie recruitment. What's more, (as was=20 pointed out by another post), having millions of different=20 target recipient, each with different delivery criteria is=20 a far more daunting challenge to spammers. > Since your method requires no cooperation from any other=20 >MTA operator, it=20 > doesn't require any endorsement from this group.=20 Right, no endoresement is NEEDED, but (like the=20 introduction of the original IBM PC) it would be nice to=20 have it recognized as a useful direction. Spammers are=20 far more likely to be dissuaded from attempting to send=20 HTML-based or attachment-based spam if it is RECOGNIZED=20 that it's unlikely to be delivered, rather than it just=20 disappearing down a black hole somewhere and leaving them=20 believing that it's still a viable technique. > That is fine - it doesn't=20 > make your method illegitimate or anything like that. But=20 >most users wish=20 > for a cooperative anti-spam technique, because they=20 >reasonably expect it=20 > will work better, and they reasonably expect many other=20 >MTA operators to=20 > cooperate with them.=20 And, if that's enough to satisfy them, chances are good=20 that the (cooperative!) "default" case (no HTML, no=20 attachments, messages < some maximum size, and message=20 passed by SpamAssassin or similar) would already=20 constitute a MAJOR improvement over existing spam=20 blocking. The whitelisting capability mostly just gives=20 the recipients the opportunity to tweak things further,=20 opening the keyway to allow more risky mail if they so=20 desire, or to block stuff they don't want that the ISP's=20 default scanning would still let through. > This has been true in the past -=20 >consider the many=20 > DNSBLs and other activities against spam. When we kept a=20 >list of spamming=20 > IP addresses sending to our MTA, we found after 2 weeks=20 >that only 1% of=20 > the IPs had send more than one message. Our subscription=20 >to Spamhaus kills=20 > about 65% of incoming messages. That is a victory for=20 >cooperation and it=20 > makes us think that more co executable attachments, HTML, and "big"=20 messages from known/trusted senders basically eliminates=20 E-mail as a vector for virus/worm propagation, which takes=20 a big bite out of spambot zombie recruitment. That, all=20 by itself, is a huge improvement in the spam=20 detection/blocking situation. [comment #5] > All I can say is, you are certainly welcome to block any=20 >mail you please,=20 > and no cooperation from other MTA operators is required,=20 >nor is any=20 > meeting of the IETF. The only purpose for the IETF=20 >involvement is to=20 > coordinate cooperative action. Since the IETF is=20 >voluntary, the action=20 > needs to be of benefit to all participants, and that=20 >greatly restricts the=20 > field of actions practical for widespread=20 >implementation. But it doesn't=20 > in any way restrict what you as an individual can do. That's certainly true, and one advantage of fine-grained=20 recipient blocking is that it doesn't require any great=20 worldwide consensus, nor any re-engineering of Internet=20 infrastructure. What WOULD be helpful, though, would be a recognition by=20 the IETF that: a) such fine-grained per-sender by-recipient blocking=20 (and hopefully augmented by subsequent content scanning)=20 is an effective and desirable approach to the problem, and b) in the general case, blocking of all non-whitelisted=20 E-mails containing HTML, scripting (probably covered under=20 HTML... is it possible to put in scripting without HTML?),=20 or attachments is a "best practice". (It is probably a=20 good idea to suggest including a maximum message size,=20 too, as a way of preventing "denial of service" attacks by=20 sending big E-mails to someone which would be expected to=20 fill their E-mail inbox to overflowing, blocking=20 subsequent legitimate E-mails). That would at least provide a direction forward which=20 would make for a huge improvement, avoid the legal issues=20 of blocking e-mails too crudely, and take a big bite out=20 of spambot zombie recruitment. What's more, (as was=20 pointed out by another post), having millions of different=20 target recipient, each with different delivery criteria is=20 a far more daunting challenge to spammers. > Since your method requires no cooperation from any other=20 >MTA operator, it=20 > doesn't require any endorsement from this group.=20 Right, no endoresement is NEEDED, but (like the=20 introduction of the original IBM PC) it would be nice to=20 have it recognized as a useful direction. Spammers are=20 far more likely to be dissuaded from attempting to send=20 HTML-based or attachment-based spam if it is RECOGNIZED=20 that it's unlikely to be delivered, rather than it just=20 disappearing down a black hole somewhere and leaving them=20 believing that it's still a viable technique. > That is fine - it doesn't=20 > make your method illegitimate or anything like that. But=20 >most users wish=20 > for a cooperative anti-spam technique, because they=20 >reasonably expect it=20 > will work better, and they reasonably expect many other=20 >MTA operators to=20 > cooperate with them.=20 And, if that's enough to satisfy them, chances are good=20 that the (cooperative!) "default" case (no HTML, no=20 attachments, messages < some maximum size, and message=20 passed by SpamAssassin or similar) would already=20 constitute a MAJOR improvement over existing spam=20 blocking. The whitelisting capability mostly just gives=20 the recipients the opportunity to tweak things further,=20 opening the keyway to allow more risky mail if they so=20 desire, or to block stuff they don't want that the ISP's=20 default scanning would still let through. > This has been true in the past -=20 >consider the many=20 > DNSBLs and other activities against spam. When we kept a=20 >list of spamming=20 > IP addresses sending to our MTA, we found after 2 weeks=20 >that only 1% of=20 > the IPs had send more than one message. Our subscription=20 >to Spamhaus kills=20 > about 65% of incoming messages. That is a victory for=20 >cooperation and it=20 > makes us think that more cooperation might be better. Again, the problem is the degree of collateral damage that=20 IP-based blocking produces. I consider that to be=20 unacceptable, and perhaps creating legal liability. Now,=20 if the USER implements IP-based blocking, that's THEIR=20 choice and I don't believe any court would rule against=20 their right to do that. But an ISP is a very different=20 situation. > It is true that cooperative actions attract lawsuits,=20 >but that is only=20 > because it isn't practical to sue an individual for=20 >refusing mail,=20 Not only is it not practical, but they have the ABSOLUTE=20 right to read or not read anything given to them=20 (certainly at least anything delivered by E-mail!). [comment #6] [how users configure their whitelist rules] > The problem being that out of the 60,000 seats here,=20 >perhaps less than > 10 of them are able to competently configure a set of=20 >rules like what > you have. =20 That's a software implementation issue, not an inherent=20 problem in the approach. I envision a button to click on=20 that simply says "allow E-mails like this from the same=20 sender in the future" and where the software will open the=20 keyway JUST enough to allow that type of message if seen=20 again from that sender. How that recognition is=20 accomplished, whether by something crude like simple=20 GREP-type scanning, or something brain-damaged like RegEx=20 pattern matching, or something still more sophisticated=20 like the pattern matching SNOBOL/SPITBOL offers, or even a=20 different sort of statistical ranking/rating approach like=20 content scanners use... will vary from one implementation=20 to another. The final products will probably use a=20 combination of techniques. > Many of them don't even have a clear notion=20 >of the concept of > "source IP" is, let alone being able to make reasonable=20 >choices of, say, > knowing why you'd want to block dynamic IPs or IPs in=20 >Korea. Again, I consider IP-based blocking to be inherently=20 flawed, to the point where I consider it a dead-end. >Furthermore, and with complete irony, I'll note that the=20 >only reason I > read this thread is that my very own, personally=20 >trained, UA bayesian > filtering flung it all in the junk folder! ;-) :-) Yeah, I admit that I usually at least cast a cursory=20 eyeballing of the Yahoo mail "spam" folder too, rather=20 than just emptying it. Occasionally I -do- find a=20 non-spam message there. (Although that happens seldom, as=20 I almost never give that E-mail address to anybody... It's=20 almost useful as a "personal honeypot" to see what's being=20 spammed out, before going to my more usual E-mail accounts=20 and possibly wondering if that curious E-mail just MIGHT=20 be legitimate). > We're achieving effectiveness rates in excess of 98%=20 >with our "one set > of rules" server based defences. My personal account,=20 >which receives > 400-600 emails/day, has 100 or more spams/day filtered=20 >out by the > central server solution. I usually go a week or so=20 >between spams that > get past those central filters - I see _many_ more FPs=20 >with my bayesian > than I see spam getting through. There will be FPs and spams get through, probably=20 regardless of what filtering technique you use. The=20 important thing is that the RECIPIENT controls that, so=20 they can decide the rule that determines what gets blocked=20 and what gets through. That way they don't have to wonder=20 what SHOULD have been delivered to them and wasn't. > My personally trained bayesian filtering has an=20 >absolutely abysmal track > record. =20 Spammers have gotten good at throwing enough random junk=20 into E-mails to confuse Bayesian filters. > On the spam aimed at the false positive=20 >handling address, which > by design has _no_ filtering, Bayesian has an=20 >effectiveness rate of > about 50%. Yuck. No amount of personal twiddling,=20 >custom rules, > explicit pattern matching in my UA is going to make much=20 >difference to that. Some E-mails are going to get through. But making sure=20 that they aroperation might be better. Again, the problem is the degree of collateral damage that=20 IP-based blocking produces. I consider that to be=20 unacceptable, and perhaps creating legal liability. Now,=20 if the USER implements IP-based blocking, that's THEIR=20 choice and I don't believe any court would rule against=20 their right to do that. But an ISP is a very different=20 situation. > It is true that cooperative actions attract lawsuits,=20 >but that is only=20 > because it isn't practical to sue an individual for=20 >refusing mail,=20 Not only is it not practical, but they have the ABSOLUTE=20 right to read or not read anything given to them=20 (certainly at least anything delivered by E-mail!). [comment #6] [how users configure their whitelist rules] > The problem being that out of the 60,000 seats here,=20 >perhaps less than > 10 of them are able to competently configure a set of=20 >rules like what > you have. =20 That's a software implementation issue, not an inherent=20 problem in the approach. I envision a button to click on=20 that simply says "allow E-mails like this from the same=20 sender in the future" and where the software will open the=20 keyway JUST enough to allow that type of message if seen=20 again from that sender. How that recognition is=20 accomplished, whether by something crude like simple=20 GREP-type scanning, or something brain-damaged like RegEx=20 pattern matching, or something still more sophisticated=20 like the pattern matching SNOBOL/SPITBOL offers, or even a=20 different sort of statistical ranking/rating approach like=20 content scanners use... will vary from one implementation=20 to another. The final products will probably use a=20 combination of techniques. > Many of them don't even have a clear notion=20 >of the concept of > "source IP" is, let alone being able to make reasonable=20 >choices of, say, > knowing why you'd want to block dynamic IPs or IPs in=20 >Korea. Again, I consider IP-based blocking to be inherently=20 flawed, to the point where I consider it a dead-end. >Furthermore, and with complete irony, I'll note that the=20 >only reason I > read this thread is that my very own, personally=20 >trained, UA bayesian > filtering flung it all in the junk folder! ;-) :-) Yeah, I admit that I usually at least cast a cursory=20 eyeballing of the Yahoo mail "spam" folder too, rather=20 than just emptying it. Occasionally I -do- find a=20 non-spam message there. (Although that happens seldom, as=20 I almost never give that E-mail address to anybody... It's=20 almost useful as a "personal honeypot" to see what's being=20 spammed out, before going to my more usual E-mail accounts=20 and possibly wondering if that curious E-mail just MIGHT=20 be legitimate). > We're achieving effectiveness rates in excess of 98%=20 >with our "one set > of rules" server based defences. My personal account,=20 >which receives > 400-600 emails/day, has 100 or more spams/day filtered=20 >out by the > central server solution. I usually go a week or so=20 >between spams that > get past those central filters - I see _many_ more FPs=20 >with my bayesian > than I see spam getting through. There will be FPs and spams get through, probably=20 regardless of what filtering technique you use. The=20 important thing is that the RECIPIENT controls that, so=20 they can decide the rule that determines what gets blocked=20 and what gets through. That way they don't have to wonder=20 what SHOULD have been delivered to them and wasn't. > My personally trained bayesian filtering has an=20 >absolutely abysmal track > record. =20 Spammers have gotten good at throwing enough random junk=20 into E-mails to confuse Bayesian filters. > On the spam aimed at the false positive=20 >handling address, which > by design has _no_ filtering, Bayesian has an=20 >effectiveness rate of > about 50%. Yuck. No amount of personal twiddling,=20 >custom rules, > explicit pattern matching in my UA is going to make much=20 >difference to that. Some E-mails are going to get through. But making sure=20 that they are (a) small, and (b) not "dangerous" at least=20 reduces the impact of those. And meanwhile, giving the recipient the ability to at=20 least not see the SAME kind of stuff over and over again,=20 if they choose to use those features, demonstrates the=20 ISP's trying to give the user the tools to reduce the=20 frustration. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 20:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGE7-0004qp-Pn; Thu, 25 Jan 2007 20:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGE6-0004qh-Fy for asrg@ietf.org; Thu, 25 Jan 2007 20:50:02 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAGE5-0004fy-4M for asrg@ietf.org; Thu, 25 Jan 2007 20:50:02 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0Q1nwN25359 for ; Thu, 25 Jan 2007 20:49:58 -0500 (EST) Received: from [47.9.16.147] ([47.9.16.147] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 20:49:57 -0500 Message-ID: <45B95E3F.6090605@nortel.com> Date: Thu, 25 Jan 2007 20:49:51 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 01:49:57.0779 (UTC) FILETIME=[4898EE30:01C740EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote: > On Thu, 25 Jan 2007, Martin Hannigan wrote: >> By tracking the historical behavoir of /32's or larger allocations, we >> could develop a profile of the behaviors that will eventually establish >> a baseline for those allocations as "good" "nuetral" or "bad", to keep >> it kind of simple. A lot of this data is already out there. > > Yes, blacklists do this already, though they are binary not ternary. That's not necessarily true. Many DNSBLs are already multi-valued (zen.spamhaus.org presently has 6 independent "flags"), and they can be constructed to be more sophisticated with as many as 2^24 values on a single return, and/or being used in scoring. It's simply a matter of deciding on the convention, publishing it, and having admins configure to the intended interpretation (or not :-(. >> ... Since they are e (a) small, and (b) not "dangerous" at least=20 reduces the impact of those. And meanwhile, giving the recipient the ability to at=20 least not see the SAME kind of stuff over and over again,=20 if they choose to use those features, demonstrates the=20 ISP's trying to give the user the tools to reduce the=20 frustration. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 20:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGE7-0004qp-Pn; Thu, 25 Jan 2007 20:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGE6-0004qh-Fy for asrg@ietf.org; Thu, 25 Jan 2007 20:50:02 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAGE5-0004fy-4M for asrg@ietf.org; Thu, 25 Jan 2007 20:50:02 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0Q1nwN25359 for ; Thu, 25 Jan 2007 20:49:58 -0500 (EST) Received: from [47.9.16.147] ([47.9.16.147] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 20:49:57 -0500 Message-ID: <45B95E3F.6090605@nortel.com> Date: Thu, 25 Jan 2007 20:49:51 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 01:49:57.0779 (UTC) FILETIME=[4898EE30:01C740EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote: > On Thu, 25 Jan 2007, Martin Hannigan wrote: >> By tracking the historical behavoir of /32's or larger allocations, we >> could develop a profile of the behaviors that will eventually establish >> a baseline for those allocations as "good" "nuetral" or "bad", to keep >> it kind of simple. A lot of this data is already out there. > > Yes, blacklists do this already, though they are binary not ternary. That's not necessarily true. Many DNSBLs are already multi-valued (zen.spamhaus.org presently has 6 independent "flags"), and they can be constructed to be more sophisticated with as many as 2^24 values on a single return, and/or being used in scoring. It's simply a matter of deciding on the convention, publishing it, and having admins configure to the intended interpretation (or not :-(. >> ... Since they are allocated out of IANA, they >> would be legitimate to most RBL's until they were caught in the act, but >> by the time they are observed, the allocations are swapped. > > You are assuming that blacklists are necessarily based on post-hoc > observation the outgoing email behaviour of IP addresses, and that there > are no blacklists that are based on prior information such as allocations > and hijacking. However, you are wrong: an old example is the DUL, but for > something closer to what you have in mind, have a look at > http://www.completewhois.com/bogons/bogons_usage.htm I was going to mention that... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbleP53FmCyJjHfhAQLqIwP8CC/NdSjLY2AXI0A0B3nTeHG1vrtof/4e +mE3W1WxzlOQKwI5qnI0TfV7ZdVe36ULEBdnBXRZjkGJSjiu173RPJPTWet/kldu kggEa8HNW6XtT5uFCMzMEifrkmDkMM5nV5qIqkBEbewNJ2TNp6yJeX+md+4u1PIJ 0BBS+2joQWM= =wwyo -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg allocated out of IANA, they >> would be legitimate to most RBL's until they were caught in the act, but >> by the time they are observed, the allocations are swapped. > > You are assuming that blacklists are necessarily based on post-hoc > observation the outgoing email behaviour of IP addresses, and that there > are no blacklists that are based on prior information such as allocations > and hijacking. However, you are wrong: an old example is the DUL, but for > something closer to what you have in mind, have a look at > http://www.completewhois.com/bogons/bogons_usage.htm I was going to mention that... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbleP53FmCyJjHfhAQLqIwP8CC/NdSjLY2AXI0A0B3nTeHG1vrtof/4e +mE3W1WxzlOQKwI5qnI0TfV7ZdVe36ULEBdnBXRZjkGJSjiu173RPJPTWet/kldu kggEa8HNW6XtT5uFCMzMEifrkmDkMM5nV5qIqkBEbewNJ2TNp6yJeX+md+4u1PIJ 0BBS+2joQWM= =wwyo -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 21:18:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGeK-00034d-Vf; Thu, 25 Jan 2007 21:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGeJ-00034Y-Ga for asrg@ietf.org; Thu, 25 Jan 2007 21:17:07 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAGeH-0001Pn-6u for asrg@ietf.org; Thu, 25 Jan 2007 21:17:07 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0Q29Iw18663 for ; Thu, 25 Jan 2007 21:09:18 -0500 (EST) Received: from [47.9.16.147] ([47.9.16.147] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:17:01 -0500 Message-ID: <45B96497.5090207@nortel.com> Date: Thu, 25 Jan 2007 21:16:55 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 02:17:02.0263 (UTC) FILETIME=[10DD8470:01C740F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 william(at)elan.net wrote: >> , and technologies to block or drop connections en masse will have more >> of a likelihood of getting funded internally. > > Really? The more "en masse" you do the more good mail would be lost > and reality is that there appears to be substantial enough difference > between users that that doing it "en mass" for ISP or for large enough > enterprise is probably not ok. Most enterprises will have global policies in place that make it totally unnecessary to have _any_ form of per-recipient policy. Our policy is that it's not permitted to spam or harrass our users. Certainly, we allow both senders and recipients to question or challenge our decisions in terms of that policy, but anyone continuing to insist on the ability to receive something that we've reconfirmed to be blockable under the policy is told that they should use their home account. That happens less than once a month. Only one in 10 years has asked for the names of my management. It didn't help them ;-) There are some things that get past the filters, and 3 recipients that have no filtering. But each exemption has a specific corporate business case behind it. Two of those recipients land in my mailbox . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRblkl53FmCyJjHfhAQJ9qAQA7qYJ/1vG2zPbutfg5SHl5Zp3U91CPXAF dyFYxgwC9AAmDOYf1PmiQeDyJl63ph5z0FsC+W9qXrf/q4hPz84lNi/V9NaQghul CAsjpSLdfHbEG1ol1xEUzqu5I9n7T7lTWkSeej7GEWNC8xg1z9E2YEVNjUQnaUqf 3tGIGTSnYzk= =oPp4 -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 22:53:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAI5x-0000pE-Kg; Thu, 25 Jan 2007 22:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAI5w-0000p6-Im for asrg@ietf.org; Thu, 25 Jan 2007 22:49:44 -0500 Received: from mailout1.igs.net ([216.58.97.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAI5v-0008BY-Az for asrg@ietf.org; Thu, 25 Jan 2007 22:49:44 -0500 Received: from waltdnes.org (i209-195-114-240.cia.com [209.195.114.240]) by mailout1.igs.net (Postfix) with SMTP id 746FC59C0 for ; Thu, 25 Jan 2007 22:49:40 -0500 (EST) Received: by waltdnes.org (sSMTP sendmail emulation); Thu, 25 Jan 2007 22:52:25 -0500 From: "Walter Dnes" Date: Thu, 25 Jan 2007 22:52:25 -0500 To: ASRG list Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt Message-ID: <20070126035225.GA2514@waltdnes.org> References: <934f64a20701220902rbbf4004i9a9c322699cecf9c@mail.gmail.com> <20070122185126.2488F32CDD@radish.jmason.org> <20070123222119.GA30684@waltdnes.org> <45B84AAF.3010204@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B84AAF.3010204@nortel.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, Jan 25, 2007 at 01:14:07AM -0500, Chris Lewis wrote > The problem being that out of the 60,000 seats here, perhaps less than > 10 of them are able to competently configure a set of rules like what > you have. Many of them don't even have a clear notion of the concept of > "source IP" is, let alone being able to make reasonable choices of, say, In the case of a corporation, the end-user is *NOT* the customer; the corporation (i.e. higher management) is the real customer. At an ISP, I outsource the POP and SMTP servers to the ISP, because it's too much hassle for me to maintain patched, secure, servers, with big UPS, failover, etc. I chose to maintain my own mailfilters, with the ISP maintaining the physical servers. If 90% of customers choose to outsource unwanted-email-blocking, that's their right. > knowing why you'd want to block dynamic IPs or IPs in Korea. Because the computer guru in the next cubicle at work told me. > Furthermore, and with complete irony, I'll note that the only reason I > read this thread is that my very own, personally trained, UA bayesian > filtering flung it all in the junk folder! ;-) Bayesian filters belong in the junk folder. > We're achieving effectiveness rates in excess of 98% with our "one set > of rules" server based defences. My personal account, which receives > 400-600 emails/day, has 100 or more spams/day filtered out by the > central server solution. I usually go a week or so between spams that > get past those central filters - I see _many_ more FPs with my bayesian > than I see spam getting through. > > My personally trained bayesian filtering has an absolutely abysmal > track record. On the spam aimed at the false positive handling > address, which by design has _no_ filtering, Bayesian has an > effectiveness rate of about 50%. Yuck. No amount of personal > twiddling, custom rules, explicit pattern matching in my UA is going > to make much difference to that. You seem to be mis-reading my message. Nowhere did I praise Bayesian filters. I was talking about different users with different whitelists, adding different DNSbls, blocking different countries and IP address ranges. -- Walter Dnes In linux /sbin/init is Job #1 _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 22:55:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIAW-00048Y-5Y; Thu, 25 Jan 2007 22:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIAU-00048P-OH for asrg@ietf.org; Thu, 25 Jan 2007 22:54:26 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIAT-0000Rw-BM for asrg@ietf.org; Thu, 25 Jan 2007 22:54:26 -0500 Received: by nz-out-0506.google.com with SMTP id z6so660409nzd for ; Thu, 25 Jan 2007 19:54:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OALIayIk56qX7/csy3ywVYnJZFJ4Ltkn50sotts1IIZeJIsjTUskYhGE7a2HFfUk72yWU7B/3sTYvryFtwpIih448qirTBxaLCsGL+hB4RMRit/QYcMNGjfFIn59PEpqXKex4W6iYhPePRsxTV7jrWyN3advfTSKA5lGSn50xK8= Received: by 10.65.254.13 with SMTP id g13mr4281611qbs.1169783664803; Thu, 25 Jan 2007 19:54:24 -0800 (PST) Received: by 10.64.179.14 with HTTP; Thu, 25 Jan 2007 19:54:24 -0800 (PST) Message-ID: <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> Date: Thu, 25 Jan 2007 22:54:24 -0500 From: "Martin Hannigan" To: "william(at)elan.net" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/07, william(at)elan.net wrote: > > On Thu, 25 Jan 2007, Martin Hannigan wrote: [ snip, discussion to digest - thanks ] > > Take the case of 60 /8 (IIRC). It was allocated to APNIC by IANA and > > almost immediately > > spammers began unauthorized advertisements of prefixes high in this > > block, "politely" staying ahead of the RIR allocations, but using them > > as "fresh" address space. In a reputation system, those blocks would > > likely be marked bad since they are unallocated > > at the RIR level. > > These are bogon ips and some of us are rejecting them already, see > http://www.completewhois.com/bogons/ and blacklist for it is They aren't bogons. They've been allocated to the RIR. They are unassigned to ISP's or end users, but are eligible for assignment. "Bogons is the name used to describe ip blocks not allocated by IANA and RIRs to ISPs and organizations plus all other ip blocks that are reserved for private or special use by RFC" Best, Martin _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 23:02:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIHC-000833-SF; Thu, 25 Jan 2007 23:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIHB-00082u-MX for asrg@ietf.org; Thu, 25 Jan 2007 23:01:21 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIH9-0001ik-VE for asrg@ietf.org; Thu, 25 Jan 2007 23:01:21 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0Q41D907988 for ; Thu, 25 Jan 2007 23:01:13 -0500 (EST) Received: from [47.9.16.147] ([47.9.16.147] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 23:01:06 -0500 Message-ID: <45B97CF9.5030909@nortel.com> Date: Thu, 25 Jan 2007 23:00:57 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anti-spam principles References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 04:01:07.0185 (UTC) FILETIME=[9B20FE10:01C740FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gep2@terabites.com wrote: > I'm grouping together responses to several individual points on this > thread. Before trying to reply to this whole thing, you might want to scroll forward to Comment #6. You seem to be assuming various things about how filters have to work that simply aren't the case. You _can_ handle false positives 100% without the recipient controlling the rules or even necessarily know that a false positive has occured. In effect, reducing your false positive level to zero, without any recipient involvement. Our overall system is designed towards _zero_ false positives. In at least one way, we're theoretically (and near effectively) there. With DNSBLs and other techniques. In fact, in most ways we're far more aggressive than other filtering schemes. We can afford to have the filters misfire on legitimate email. Simply because we've paid as much attention to finding out about misfires and remediating them as we've done with filtering itself. What happens after being blocked is just as much part of a well designed filtering strategy as the filters are. > [comment #1] > >>> In any case, I still contend that simplistic blocking by IP address >>> or domain name is a very poor approach, and for a whole variety of >>> reasons. > >> I will contend that there cannot be a content filter that can >> reliably separate spam from non spam. > > It doesn't NEED to be 100.000% accurate. Nor does any other form of filtering then. > The bulk of mail most people receive comes from people they are familiar > with, and which fits certain patterns. A given sender (mailing list etc) > will typically have a signature file, for instance. I know that Aunt > Matilda is NOT going to send me an E-mail containing a JavaScript > decryption routine, or an ActiveX enclosure. She also is not going to > send me an executable attachment. If stuff like that arrives here, it > is safe to presume it is NOT from her, no matter what the From: address > says (and even if it WAS sent from her computer). This does not work in the large scale beyond a limited subset of users. Not everyone has that small a set of correspondents to cope with, and the "new correspondent" issue remains a big problem. > I guess that depends on what you call "bulk", and how you propose to > detect it. Again, whatever rule you put into effect (on a global-type > basis) is going to be discovered by spammers and they will engineer > their sending patterns to avoid violating it. That's why you need a > really narrow and twisty 'gauntlet' they must negotiate, with DIFFERENT > RULES for different recipients, where they don't know and basically can > not figure out what rules they would have to comply with to get a > message through to a particular person. Having had almost 4 years of intimate operational experience with what is probably the most effective single anti-spam filtering method there's been (one specific DNSBL), I can assure you that it is both more reliable in terms of FPs than any content filter I've ever dealt with (we've always run hybrid content+source+other techniques), I can also assure you that its effectiveness is _not_ declining - in fact it's getting better. Is it perfect? No. Does adding other filtering techniques help? Yes. But to claim that it's useless/trivially defeatable/too many FPs/trivial to do better turns out to simply not be the case. >> The trick is to stop accepting mail from that IP address only until >> it has cleaned up. > Again, when you have a LOT of users (and possibly MANY servers) behind a > NAT router, denying mail from that IP address results in simply too much > collateral damage. More to the point, it's a very blunt instrument for > the job, and it's relatively simple to do very much better. So far, there's no indication of the latter being true. Show me a methodology that (a) doesn't abuse innocent third parties and/or (b) requires personal twiddling simply not achievable in the large scale that's better than the CBL (or for that matter Zen), I want to hear about it. >> Once the spam is gone there is no need to block the address unless it >> has proven to be a repeat offender without an effective process for >> shutting the spammers down. > > What about when the flow of spam is interleaved with all sorts of > good/important traffic as well? You make a cost-benefit analysis and/or apply other techniques. Even content. Why the insistance on choosing only one? You don't have to. Effective spam filtering is best done with a hybrid solution. No one technique is complete on its own. > There is a lot of spam which is obvious. That includes messages which > contain links to known-spam-promoted Web sites (at least in the absence > of contradicting factors, say being from a list discussing spam senders!) SURBLs are blacklists too, and can be equally as blunt as a source IP. Or are you contending that the user should be explicitly entering them? With _individual_ spammers using 1000 or more domain names to advertise the same thing, how effective do you think that can be? > It also includes, for example, messages which are identical to messages > that some number (dozens? hundreds?) of other recipients at the same ISP > have already reported as being "spam". Have you done any work with checksumming/hashing spam, ala DCC or Razor? Yes, they're useful. But these days most high volume spammers randomize content such that even highly developed de-hashbusting techniques don't work very reliably. Doesn't even work on graphical spam anymore. > One would think that ISPs could > locate and perhaps recategorize identical messages (again, perhaps > tempered by a specific recipient rule) which are still queued and have > not yet been delivered to their remaining customers. Yes, it will yield some results, but the overall results are highly disappointing. > But let me state again (and this is part of what made me respond, > starting this sub-thread) is that it is virtually NEVER a good idea to > send a bounce message after-SMTP-time, because you can't be sure where > to send it, and most likely you are just harassing another innocent > victim. That's something I'll certainly echo. >> Being able to "slam the phone down" on miscreant IP blocks at the >> accept() or helo is much, much, less processing than going thru the >> entire SMTP interaction and whatever it takes to pass processing off >> to an end-user. > > It's true that it costs less, but it's also true that it blocks a lot of > innocent and legitimate mail that might be > originating from the same IP address (NAT router?). This generally doesn't turn out to be a significant issue in practise. If you spend the time you _should_ be spending to research the DNSBLs (say) you plan on using. > There could be > dozens, hundreds, or even thousands of innocent users affected. There could be, if the DNSBL is built in such a way that it's susceptable to that. But it doesn't have to be. And the good ones aren't in any meaningful way. >> So the zombie becomes unable to emit spam, but there's no incentive to >> fix it so it's still available to the botmaster for use as a C&C >> machine, web/DNS server, and DDoS participant. I'd prefer that it get >> uninfected. > > Obviously, that is ideal, but the problem is that after (first!) SMTP > time, the (intermediary, or final) recipient doesn't really know who > they ought to notify...! Notifying the wrong person, or someone who has > no control over the situation, probably does more harm than good. You don't need to notify out-of-band. Presuming that recipient systems use DNSBLs in an appropriate fashion (inline rejects with pointers to more information), legitimate senders find out that it's blocked and why. That's their notification. With decent DNSBLs, that's sufficient to initiate resolution of the problem. It sure is a lot easier than tweaking Bayes or SpamAssassin (we specifically reject whitelisting email addresses because of the forgery problem) Also, there's a remark somewhere on the CBL web site that impressed me with its simplicity - something to the effect that "we fully expect the vast majority of infected/blocked users _never_ notice that they're listed, because they're using their provider's smart-hosts as they should". If an ISP wants to proactively scan for infected IPs to see about getting them fixed, they can do that too. > [comment #4] I'm skipping this one because it takes too long to comment on ;-) other than: >> Executive summary... >> >> - blocking email, because it meets some technical criteria, is easier >> on the technical side, but introduces legal problems It may, perhaps depending on exactly what the technical criteria _is_ and the rationale for blocking it, but taking risks when the business case/result justifies it, is what people do. You can forestall a lot, for example, by simply saying "it's our policy to reject email from IPs that appear to be dynamic". That says nothing about the spammyness of an individual sender, and if mistaken in "appearance" simply needs to be fixed. Or not. >> - blocking email, because the customer said so, may be harder >> technically, but avoids legal problems The ISP could equally establish a infrastructure where the customer explicitly delegates filtering decisions to the ISP. And the protections in law for ISPs to be held harmless for mistakes in good-faith filtering go a long way to shoot down any attempt even where the customers haven't formally delegated. It ain't easy for a sender to prove bad-faith. An ISP hasn't been sued in ages. >> - any complications on the anti-spam side are outweighed by equivalant >> complications on the spammers' end. ISPs will have to enable end >> users to configure their own rules, and everybody's filters and >> whitelists will be slightly different. Imagine how spammers will >> feel knowing that each of several million targets for a spam-run has >> a slightly different defense, that has to be overcome in order to >> deliver the email. > > EXACTLY. But also, knowing that all the classical ruses to avoid spam > classification (text as image, embedded links, attachments, scripting, > disguised HTML links, etc etc) are a priori denied them.... certainly > takes a major bite out of spammers. It would if you could. How can you tell that an image is text? Blocking spam with embedded links or attachments would probably put us out of business. More likely get me fired. > And only allowing executable attachments, HTML, and "big" messages from > known/trusted senders basically eliminates E-mail as a vector for > virus/worm propagation, "known/trusted" senders by what measure? Explicit listing of them? Well, I can tell you about lots of viral attachments from "known senders". > [comment #5] > That's certainly true, and one advantage of fine-grained recipient > blocking is that it doesn't require any great worldwide consensus, nor > any re-engineering of Internet infrastructure. Nor do DNSBLs ;-) > What WOULD be helpful, though, would be a recognition by the IETF that: > > a) such fine-grained per-sender by-recipient blocking (and hopefully > augmented by subsequent content scanning) is an effective and desirable > approach to the problem, and As I've been saying, that has yet to be established. > b) in the general case, blocking of all non-whitelisted E-mails > containing HTML, scripting (probably covered under HTML... is it > possible to put in scripting without HTML?), or attachments is a "best > practice". (It is probably a good idea to suggest including a maximum > message size, too, as a way of preventing "denial of service" attacks by > sending big E-mails to someone which would be expected to fill their > E-mail inbox to overflowing, blocking subsequent legitimate E-mails). Obviously, you've not had to deal with the legitimate mail traffic of a large corporation. I mention those measures as comic relief at meetings, because it always produces hysterical laughter. It'd shut us down. >> This has been true in the past - consider the many DNSBLs and other >> activities against spam. When we kept a list of spamming IP addresses >> sending to our MTA, we found after 2 weeks that only 1% of the IPs had >> send more than one message. Our subscription to Spamhaus kills about >> 65% of incoming messages. That is a victory for cooperation and it >> makes us think that more cooperation might be better. > Again, the problem is the degree of collateral damage that IP-based > blocking produces. You haven't demonstrated what that degree _is_. By long exposure, I can assure you that the degree is surprisingly low. If you do your homework as you're supposed to. We're receiving 1-2 million emails per day. 80-90% of that is spam. We have less than 10 FPs per month against Spamhaus' sbl-xbl (which is doing about 85% of our filtering). We've arranged things so that the sender finds out if they're blocked, and there's a well established procedure by which they can notify us and we can override listings. If an email is blocked, they contact us, and we forward their email and fix the listing, is it really a FP? No. If every sender correctly interpreted the error message they got and followed through, then there'd be zero FPs. I wish our content filters even remotely approached being _that_ good. > [comment #6] > > [how users configure their whitelist rules] > >> The problem being that out of the 60,000 seats here, perhaps less than >> 10 of them are able to competently configure a set of rules like what >> you have. > > That's a software implementation issue, not an inherent problem in the > approach. I envision a button to click on that simply says "allow > E-mails like this from the same sender in the future" and where the > software will open the keyway JUST enough to allow that type of message > if seen again from that sender. How that recognition is accomplished, > whether by something crude like simple GREP-type scanning, or something > brain-damaged like RegEx pattern matching, or something still more > sophisticated like the pattern matching SNOBOL/SPITBOL offers, or even a > different sort of statistical ranking/rating approach like content > scanners use... will vary from one implementation to another. The final > products will probably use a combination of techniques. I'm sorry, this simply isn't a human interface issue. No amount or technique of per-sender whitelisting comes remotely close to the accuracy of our production filters, entirely aside from the new correspondent issue. You could give our users common filtering software (the reader is already pretty much standardized) with every filtering knob known to man, and perhaps three of our users could approach the effectiveness of the production systems. I'm only including _me_ in that list because it's me who built the production systems... Over a million decision items are being changed every day in our filters. Our users simply don't know effective spam filtering techniques. They push the wrong button, twist the wrong knob, and they're blocking something business critical. Or trusting malicious content with forged credentials. Or simply trusting... My favourite incident was the user who repeatedly insisted that he needed to receive the "important information from the FBI" that was sitting in his quarantine, and the quarantine forwarder refused to forward to his mailbox. Sorry, I said, but as much as you may want to see it, forwarding the virus is a really bad idea ;-) >> Many of them don't even have a clear notion of the concept of >> "source IP" is, let alone being able to make reasonable choices of, say, >> knowing why you'd want to block dynamic IPs or IPs in Korea. > > Again, I consider IP-based blocking to be inherently flawed, to the > point where I consider it a dead-end. It's a remarkably vigorous dead end ;-) >> Furthermore, and with complete irony, I'll note that the only reason I >> read this thread is that my very own, personally trained, UA bayesian >> filtering flung it all in the junk folder! ;-) > > :-) > > Yeah, I admit that I usually at least cast a cursory eyeballing of the > Yahoo mail "spam" folder too, rather than just emptying it. > Occasionally I -do- find a non-spam message there. (Although that > happens seldom, as I almost never give that E-mail address to anybody... > It's almost useful as a "personal honeypot" to see what's being spammed > out, before going to my more usual E-mail accounts and possibly > wondering if that curious E-mail just MIGHT be legitimate). "Almost useful" is the key. When you have users whose spam load ranges from one or 2 per month, to 4000+ per day, you can see that junk folders have only limited usefulness, and not to everyone. Nobody can find legitimate email in a 4000 spams/day feed, now matter how the filters are implemented. Perhaps part of your problem is that you're not seeing the big picture of how you can _use_ DNSBLs or any other filtering technique. Your remarks seem to imply that DNSBLs necessitate no notification anywhere, the email just disappears. Or that filtering in general is that way. On the contrary, ours have never done that. Indeed, without anybody looking at quarantines, without anybody personally twiddling filters, that 4000 spams/day user _does_ get the email that was accidentally blocked. Simply because we do inline rejects with instructions on what to do, and problems get fixed fast and without harm. > >> We're achieving effectiveness rates in excess of 98% with our "one set >> of rules" server based defences. My personal account, which receives >> 400-600 emails/day, has 100 or more spams/day filtered out by the >> central server solution. I usually go a week or so between spams that >> get past those central filters - I see _many_ more FPs with my bayesian >> than I see spam getting through. > > There will be FPs and spams get through, probably regardless of what > filtering technique you use. No "probably" about it. I wrote exactly that almost 10 years ago ;-) The question is how to deal with it. > The important thing is that the RECIPIENT > controls that, so they can decide the rule that determines what gets > blocked and what gets through. That way they don't have to wonder what > SHOULD have been delivered to them and wasn't. But what if you arrange things so that the recipient doesn't have to control the rules, and still doesn't have to wonder? Our false positives are handled usually without the recipient even knowing that something got blocked. > >> My personally trained bayesian filtering has an absolutely abysmal track >> record. > > Spammers have gotten good at throwing enough random junk into E-mails to > confuse Bayesian filters. And sender whitelisting and... >> On the spam aimed at the false positive handling address, which >> by design has _no_ filtering, Bayesian has an effectiveness rate of >> about 50%. Yuck. No amount of personal twiddling, custom rules, >> explicit pattern matching in my UA is going to make much difference to >> that. > > Some E-mails are going to get through. Yes. But 50% is absurd. If I presented that solution to the boss, I'd be looking for another job. > And meanwhile, giving the recipient the ability to at least not see the > SAME kind of stuff over and over again, if they choose to use those > features, demonstrates the ISP's trying to give the user the tools to > reduce the frustration. If you can _detect_ the "SAME kind of stuff" over and over again. Even the best content techniques aren't very good at that anymore. Correctly chosen and utilized DNSBLs do a vastly better job. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbl8+Z3FmCyJjHfhAQJnoQQAx3p41yIzTGB3gPlEIS1bRmfZ36yOcDBf VCl5IeN6UKb9uiO1jtYOp1Zm3xz50QVtdj8XwdDHbG6qMA+eOzRouKvpGwUbu42M MANtwZwqu72IU2PbqQ3V300VsNU4hMaiE2hoqUOdm4tWVQjsPp+dU+BAHuYMpIGE g0/vaqER++8= =cHX0 -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 23:16:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIU4-00067d-0O; Thu, 25 Jan 2007 23:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIU2-000612-D7 for asrg@ietf.org; Thu, 25 Jan 2007 23:14:38 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAITz-00045q-Vh for asrg@ietf.org; Thu, 25 Jan 2007 23:14:38 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l0Q4EV7b020640; Thu, 25 Jan 2007 20:14:31 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l0Q4EVwM020637; Thu, 25 Jan 2007 20:14:31 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 25 Jan 2007 20:14:31 -0800 (PST) From: "william(at)elan.net" To: Martin Hannigan Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> Message-ID: References: <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, 25 Jan 2007, Martin Hannigan wrote: >> These are bogon ips and some of us are rejecting them already, see >> http://www.completewhois.com/bogons/ and blacklist for it is > > They aren't bogons. They've been allocated to the RIR. They are unassigned > to ISP's or end users, but are eligible for assignment. And you quoted definition below under which such blocks would fit since they are not allocated by IANA and RIRs to any ISP or end-user organization/company yet. > "Bogons is the name used to describe ip blocks not allocated by IANA and RIRs > to ISPs and organizations plus all other ip blocks that are reserved > for private or > special use by RFC" Note that for those at ASRG there exist slight difference in ARIN terminology between assigned and allocated blocks. Assignment is considered to be when block is "given" (leased really) to final end-user company where as allocation is when its given to the entity which is ISP or alike and can assign ips to somebody else. So it is said that IANA allocates blocks to RIR and RIRs then allocate blocks to LIRs/ISPs and those then assigns them to end-users. It is also possible for RIR to assign block directly to end-user company if its big enough or small and they qualify under some sort of PI (RIPE term) or micro-allocation/assignment policies. Plus to that large legacy blocks are considered to have been assigned directly from IANA to end-users when RIRs did not exist yet. In addition to that the terms "reallocate" and "reassign" are used although in practice only "reallocate" has meaning when you talk about one ISP that reallocated the block to some other ISP which would be making actual assignment to end-users (since assignment is always final step there can not be "reassignment" although term is also used). In any case, in practice a lot (most) use allocation and assignment terms interchangeably and do not make a distinction - this includes definition of bogons as well (it really means both allocation and/or assignment there). --- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 23:32:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIkN-0006ni-Vf; Thu, 25 Jan 2007 23:31:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIkM-0006nY-H7 for asrg@ietf.org; Thu, 25 Jan 2007 23:31:30 -0500 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIkJ-0008RU-NU for asrg@ietf.org; Thu, 25 Jan 2007 23:31:28 -0500 Received: by nz-out-0506.google.com with SMTP id z6so668330nzd for ; Thu, 25 Jan 2007 20:31:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QoKDTNDXOy1mLKSLbigpMEj/xrzqTHNBkEXxO1o72RNEavGzySE+gm+8owIcg4SF6idW0+lX06QdAmgnwj2JRFPvK9XnFIuRkxbxa37zBHP8NOrPaBSUnSjgOkpA2yecGkuwccrqCpYCasbMqyILdt7IDBCX6kBRqXtzI86CbjA= Received: by 10.64.242.5 with SMTP id p5mr4340584qbh.1169785885208; Thu, 25 Jan 2007 20:31:25 -0800 (PST) Received: by 10.64.179.14 with HTTP; Thu, 25 Jan 2007 20:31:25 -0800 (PST) Message-ID: <2d106eb50701252031y28e302edi72dee979d9b33c97@mail.gmail.com> Date: Thu, 25 Jan 2007 23:31:25 -0500 From: "Martin Hannigan" To: "william(at)elan.net" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/07, william(at)elan.net wrote: > > On Thu, 25 Jan 2007, Martin Hannigan wrote: > > >> These are bogon ips and some of us are rejecting them already, see > >> http://www.completewhois.com/bogons/ and blacklist for it is > > > > They aren't bogons. They've been allocated to the RIR. They are unassigned > > to ISP's or end users, but are eligible for assignment. > > And you quoted definition below under which such blocks would fit > since they are not allocated by IANA and RIRs to any ISP or end-user > organization/company yet. > > > "Bogons is the name used to describe ip blocks not allocated by IANA and RIRs > > to ISPs and organizations plus all other ip blocks that are reserved > > for private or > > special use by RFC" Hmm. Understood. "And". I'm not sure I agree that this is a good definition. I don't use CW so it doesn't affect me directly, but it could. But I'll take that off list. > > Note that for those at ASRG there exist slight difference in ARIN > terminology between assigned and allocated blocks. Assignment is > considered to be when block is "given" (leased really) to final > end-user company where as allocation is when its given to the > entity which is ISP or alike and can assign ips to somebody else. > So it is said that IANA allocates blocks to RIR and RIRs then > allocate blocks to LIRs/ISPs and those then assigns them to > end-users. It is also possible for RIR to assign block directly > to end-user company if its big enough or small and they qualify > under some sort of PI (RIPE term) or micro-allocation/assignment > policies. Plus to that large legacy blocks are considered to have > been assigned directly from IANA to end-users when RIRs did not > exist yet. In addition to that the terms "reallocate" and "reassign" > are used although in practice only "reallocate" has meaning when > you talk about one ISP that reallocated the block to some other > ISP which would be making actual assignment to end-users (since > assignment is always final step there can not be "reassignment" > although term is also used). > > In any case, in practice a lot (most) use allocation and assignment > terms interchangeably and do not make a distinction - this includes > definition of bogons as well (it really means both allocation and/or > assignment there). Good clarification. -M< _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Jan 25 23:54:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJ4K-0001Gf-Kr; Thu, 25 Jan 2007 23:52:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJ4J-0001GZ-51 for asrg@ietf.org; Thu, 25 Jan 2007 23:52:07 -0500 Received: from mail1.panix.com ([166.84.1.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJ4H-0002z6-Ue for asrg@ietf.org; Thu, 25 Jan 2007 23:52:07 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 9352558838 for ; Thu, 25 Jan 2007 23:52:03 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l0Q4q3e00903; Thu, 25 Jan 2007 23:52:03 -0500 (EST) Date: Thu, 25 Jan 2007 23:52:03 -0500 (EST) Message-Id: <200701260452.l0Q4q3e00903@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> (hannigan@gmail.com) Subject: Re: [Asrg] Re: per recipient status References: <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> <2d106eb50701251954y671a4c85pa0065eae745d0de3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Martin Hannigan" wrote: > On 1/25/07, william(at)elan.net wrote: >> These are bogon ips and some of us are rejecting them already, see >> http://www.completewhois.com/bogons/ and blacklist for it is > > They aren't bogons. They've been allocated to the RIR. They are > unassigned to ISP's or end users, but are eligible for assignment. > > "Bogons is the name used to describe ip blocks not allocated by IANA > and RIRs to ISPs and organizations Note: assigned *by IANA and RIRs* *to* *ISPs and organizations*; those blocks have not been assigned by the RIR to anybody, hence bogons. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 03:17:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMDm-0002QQ-Mw; Fri, 26 Jan 2007 03:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMDl-0002QK-GP for asrg@ietf.org; Fri, 26 Jan 2007 03:14:05 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMDj-0005hl-TJ for asrg@ietf.org; Fri, 26 Jan 2007 03:14:05 -0500 Received: from mpls-pop-02.inet.qwest.net (mpls-pop-02.inet.qwest.net [63.231.195.2]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id 82D6853BCBB for ; Fri, 26 Jan 2007 08:14:03 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-02.inet.qwest.net with SMTP; 26 Jan 2007 08:14:03 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Anti Spam Research Group From: Dan Oetting Date: Fri, 26 Jan 2007 01:14:01 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Asrg] Quarantines and block lists X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 25, 2007, at 6:32 PM, gep2@terabites.com wrote: >> OTOH, taking the definition of spam as Unsolicited Bulk Email >> makes detecting a spamming IP address almost trivial. > > I guess that depends on what you call "bulk", and how you propose > to detect it. Again, whatever rule you put into effect (on a > global-type basis) is going to be discovered by spammers and they > will engineer their sending patterns to avoid violating it. [On second thought, I DON'T want to define spam as UBE. Labeling UBE as spam labels the sender as a spammer which carries a negative connotation. I just want to block UBE without calling anyone a spammer and getting sued] Here is my proposal. I'm sure I haven't thought of everything so please tell me where it breaks or how spammers are going to game it. The goal is to stop the majority of the spam while not loosing ANY legitimate email (broken MTAs don't count). This is not intended to replace existing blocklists but to handle the initial onslaught from a spam source until the source can be properly categorized and listed. Proposal #1 is a quarantine for new sources: Connections from unknown source addresses would be initially rejected by returning a temporary error code (4xx) for a probation period. The probation period could be as short as 5 minutes depending on how fast the blocklists can respond. The reject would occur after the recipient list is accepted so the recipients can be checked against local spamtraps and valid user lists. After the probation period, global blocklists would be queried to find the current reputation of the source. Proposals #2 & #3 are for a fast global block advisory and distribution network Any email addressed to a spamtrap would generate a report to a local trap handler. The local trap handler would forward appropriate reports to the regional or global blocklist managers. The blocklist managers would publish advisories based on the reputations and counts of the traps that were hit by the sending IP. If the source is emitting a sufficient volume of spam this happens before the initial probation period expires. DNS is probably a poor choice for distribution of the global fast response block advisories. I think a form of flood distribution through a mesh of peer nodes would be more robust. The distribution would feed local databases that could be queried directly or through a DNS front end. The mesh can handle data from multiple sources and needs no central authority. Proposal #4 is back reporting unsolicited email: If email addressed to certain spamtraps is received from a sender that has registered to accept back reports, accept the mail but return a specific code in the response that the sending MTA can interpret to make a determination if the sender is spamming. Alternatively, the site may register a different protocol to use for the back report. The spamtraps used for back reporting should be different from those reported to global blocklists to prevent disclosing the traps to rogue ISPs that would forward them to spammers. Only some of the traps would be used for back reporting to any given network or host. Proposal #5 is a quarantine while a site is listed in a block advisory. Established sources that get listed in local or global block advisories should have their mail quarantined while the mail is sorted out. The best place to quarantine the mail is on the sending server. It's already queued there and if it is eventually determined that it should be rejected, that can be done with a 5xx on the next delivery attempt instead of sending a bounce. If the sending ISP is on their toes an offending user or host will be shut down quickly and the remaining mail will be delivered when the block advisory is lifted or expires. Local whitelists can be used to allow mail to bypass the quarantine. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 03:36:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMXh-00060I-5j; Fri, 26 Jan 2007 03:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMXf-0005z1-Bh for asrg@ietf.org; Fri, 26 Jan 2007 03:34:39 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMXd-0000MZ-2A for asrg@ietf.org; Fri, 26 Jan 2007 03:34:39 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id EB732589348; Fri, 26 Jan 2007 03:34:28 -0500 (EST) Received: from webmaillogin.com (fr7.webmaillogin.com [216.40.35.71]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id 3ED3C588D7B; Fri, 26 Jan 2007 03:34:21 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk2.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61062693; Fri, 26 Jan 2007 02:53:48 -0500 From: Subject: Re: [Asrg] Re: bounces, and anti-spam principles To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Fri, 26 Jan 2007 01:53:48 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Scan-Signature: 63b5c256db0348fe1b7674f450e856fa X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > Before trying to reply to this whole thing, you might=20 >want to scroll > forward to Comment #6. You seem to be assuming various=20 >things about how > filters have to work that simply aren't the case. We'll get there.... :-) > You _can_ handle false positives 100% without the=20 >recipient controlling > the rules or even necessarily know that a false positive=20 >has occured. In > effect, reducing your false positive level to zero,=20 >without any > recipient involvement. >=20 > Our overall system is designed towards _zero_ false=20 >positives. In at > least one way, we're theoretically (and near=20 >effectively) there. With > DNSBLs and other techniques. Obviously, I'd have to reserve judgement until I've=20 experienced your "zero false positives" idea. Let's just=20 say that I've got a healthy degree of skepticism. > In fact, in most ways we're far more aggressive than=20 >other filtering > schemes. We can afford to have the filters misfire on=20 >legitimate email. >=20 > Simply because we've paid as much attention to finding=20 >out about > misfires and remediating them as we've done with=20 >filtering itself. Certainly making the consequences of questioning a given=20 E-mail "acceptable" from a user standpoint gets you a long=20 way. > What happens after being blocked is just as much part of=20 >a well designed > filtering strategy as the filters are. Agreed. >> [comment #1] >>=20 >>>> In any case, I still contend that simplistic blocking by=20 >>>>IP address=20 >>>> or domain name is a very poor approach, and for a whole=20 >>>>variety of=20 >>>> reasons. >>=20 >>> I will contend that there cannot be a content filter=20 >>>that can=20 >>> reliably separate spam from non spam.=20 >>=20 >> It doesn't NEED to be 100.000% accurate. >=20 > Nor does any other form of filtering then. Right. If the USER considers it okay (and that's to some=20 degree a moving target!) then it's "okay". =20 >> The bulk of mail most people receive comes from people=20 >>they are familiar >> with, and which fits certain patterns. A given sender=20 >>(mailing list etc) >> will typically have a signature file, for instance. I=20 >>know that Aunt >> Matilda is NOT going to send me an E-mail containing a=20 >>JavaScript >> decryption routine, or an ActiveX enclosure. She also=20 >>is not going to >> send me an executable attachment. If stuff like that=20 >>arrives here, it >> is safe to presume it is NOT from her, no matter what=20 >>the From: address >> says (and even if it WAS sent from her computer). >=20 > This does not work in the large scale beyond a limited=20 >subset of users. Why not? > Not everyone has that small a set of correspondents to=20 >cope with, and > the "new correspondent" issue remains a big problem. The total set of correspondents doesn't have to be small.=20 It just needs to have a relatively small number of NEW=20 correspondents that NEED to use "advanced"/riskier=20 features and therefore require whitelisting. Ideally,=20 each such correspondent only requires ONE click (one time)=20 for the user to agree to allowing them to use the more=20 advanced features. That might be done following an=20 initial negotiation E-mail where the sender introduces=20 themself and requests the ability to send more elaborate=20 mails. Introductory E-mails should NOT automatically presume the=20 desire or willingness of the recipient to receive=20 HTML-burdened E-mails. >> I guess that depends on what you call "bulk", and how=20 >>you propose to >> detect it. Again, whatever rule you put into effect (on=20 >>a global-type >> basis) is going to be discovered by spammers and they=20 >>will engineer >> their sending patterns to avoid violating it. That's=20 >>why you need a >> really narrow and twisty 'gauntlet' they must negotiate,=20 >>with DIFFERENT >> RULES for different recipients, where they don't know=20 >>and basically can >> not figure out what rules they would have to comply with=20 >>to get a >> message through to a particular person. >=20 > Having had almost 4 years of intimate operational=20 >experience with what > is probably the most effective single anti-spam=20 >filtering method there's > been (one specific DNSBL), I can assure you that it is=20 >both more > reliable in terms of FPs than any content filter I've=20 >ever dealt with > (we've always run hybrid content+source+other=20 >techniques), I can also > assure you that its effectiveness is _not_ declining -=20 >in fact it's > getting better. The main problem with content filtering is caused by ruses=20 based on HTML and attachments. These techniques serve to=20 obscure the content of the E-mail, and ALL BY THEMSELVES=20 the presence of such content in E-mails (at least in=20 E-mails from unfamiliar senders) can be a priori evidence=20 of hostile intent, or spamming. =20 > Is it perfect? No. Does adding other filtering=20 >techniques help? Yes. > But to claim that it's useless/trivially defeatable/too=20 >many FPs/trivial > to do better turns out to simply not be the case. Certainly there are always special cases/special=20 situations where just about anything can be made to look=20 good. That's like SPF, which is claimed to work well (but=20 ONLY for the subset of the situations that it works for). >>> The trick is to stop accepting mail from that IP=20 >>>address only until >>> it has cleaned up.=20 >=20 >> Again, when you have a LOT of users (and possibly MANY=20 >>servers) behind a >> NAT router, denying mail from that IP address results in=20 >>simply too much >> collateral damage. More to the point, it's a very blunt=20 >>instrument for >> the job, and it's relatively simple to do very much=20 >>better. >=20 > So far, there's no indication of the latter being true.=20 I do note you don't refute my objection on principle. :-) > Show me a > methodology that (a) doesn't abuse innocent third=20 >parties and/or (b) > requires personal twiddling simply not achievable in the=20 >large scale > that's better than the CBL (or for that matter Zen), I=20 >want to hear > about it. I don't consider that ANYBODY has the right to blindly=20 haul off and presume that I'm willing to accept=20 HTML-burdened E-mails from them. So if YOU believe that=20 such a restriction is "abusing innocent third parties"=20 then we already disagree. I also don't agree that my approach requires an=20 unacceptable level of "personal twiddling" although it=20 certainly DOES involve some degree of some recipient=20 involvement, IF its capabilities are to be optimized. If=20 the software is well-designed, I don't believe that it=20 will put off most users, especially if they have fought=20 spam for any length of time before. >>> Once the spam is gone there is no need to block the=20 >>> address unless it >>> has proven to be a repeat offender without an effective=20 >>>process for >>> shutting the spammers down. >>=20 >> What about when the flow of spam is interleaved with all=20 >>sorts of >> good/important traffic as well? >=20 > You make a cost-benefit analysis and/or apply other=20 >techniques. Even > content. >=20 > Why the insistance on choosing only one? You don't have=20 >to. Agreed. I never proposed my fine-grained whitelist all by=20 itself. It works best in conjunction with a good content=20 filter (and in fact greatly improves the efficacy of the=20 content filter). > Effective spam filtering is best done with a hybrid=20 >solution. No one > technique is complete on its own. Agreed. >> There is a lot of spam which is obvious. That includes=20 >>messages which >> contain links to known-spam-promoted Web sites (at least=20 >>in the absence >> of contradicting factors, say being from a list=20 >>discussing spam senders!) >=20 > SURBLs are blacklists too, and can be equally as blunt=20 >as a source IP. > Or are you contending that the user should be explicitly=20 >entering them? I don't really claim either way, but I WILL say that there=20 are a lot fewer valid links to spam-promoted Web sites=20 than there are randomly-generated counterfeit "from"=20 domains and E-mail addresses. > With _individual_ spammers using 1000 or more domain=20 >names to advertise > the same thing, how effective do you think that can be? Again, it's only one of a variety of criteria that can=20 identify spam. It's clear to me, though, that just using=20 From: and Subject: lines are by themselves NOWHERE NEAR=20 adequate, particularly if you want to receive E-mails from=20 previously unfamiliar senders. >> It also includes, for example, messages which are=20 >>identical to messages >> that some number (dozens? hundreds?) of other recipients=20 >>at the same ISP >> have already reported as being "spam". >=20 > Have you done any work with checksumming/hashing spam,=20 >ala DCC or Razor? Not in that context, although I've used them in other=20 contexts... > Yes, they're useful. But these days most high volume=20 >spammers randomize > content such that even highly developed de-hashbusting=20 >techniques don't > work very reliably. Doesn't even work on graphical spam=20 >anymore. That's a good reason to simply make graphical spam no=20 longer viable, by defaulting to not allowing images=20 (whether attached or embedded) from unfamiliar senders. =20 >> One would think that ISPs could >> locate and perhaps recategorize identical messages=20 >>(again, perhaps >> tempered by a specific recipient rule) which are still=20 >>queued and have >> not yet been delivered to their remaining customers. >=20 > Yes, it will yield some results, but the overall results=20 >are highly > disappointing. A lot depends on how big the ISP in question is. Within a=20 company of 15 users, that won't help much. For a big ISP=20 like Google or Yahoo or Hotmail, flushing all remaining=20 similar/identical unread E-mails which have been=20 discovered to be spam (by user reporting, as Yahoo does)=20 can quickly purge them from the Inboxes of other users who=20 haven't yet downloaded or read them. >> But let me state again (and this is part of what made me=20 >>respond, >> starting this sub-thread) is that it is virtually NEVER=20 >>a good idea to >> send a bounce message after-SMTP-time, because you can't=20 >>be sure where >> to send it, and most likely you are just harassing=20 >>another innocent >> victim. >=20 > That's something I'll certainly echo. Thanks... it is VERY frustrating to me to have Yahoo start=20 blocking all my outgoing Groups mail every month or so=20 just because SOME virus-infected mail with a bogus return=20 address gets bounced back to them as a "hard bounce".=20 :-(( Hard bounces should NEVER be sent based on content,=20 especially when you can NOT be sure who to send the hard=20 bounce to. And they should NEVER be sent back based on=20 detection of a virus/worm which is KNOWN to counterfeit=20 return addresses!!! >>> Being able to "slam the phone down" on miscreant IP=20 >>>blocks at the >>> accept() or helo is much, much, less processing than=20 >>>going thru the >>> entire SMTP interaction and whatever it takes to pass=20 >>>processing off >>> to an end-user. >>=20 >> It's true that it costs less, but it's also true that it=20 >>blocks a lot of >> innocent and legitimate mail that might be >> originating from the same IP address (NAT router?). >=20 > This generally doesn't turn out to be a significant=20 >issue in practise. Tell that to the big company that will (eventually) find=20 ALL their outgoing E-mails blocked (possibly for weeks)=20 because of one or more infected systems behind their NAT=20 router. This kind of nonsense could literally put some=20 kinds of companies out of business. > If you spend the time you _should_ be spending to=20 >research the DNSBLs > (say) you plan on using. I would not use that, because I consider IP-based blocking=20 to be ultimately a fatally flawed approach. I don't think it much matters HOW it is done. >> There could be >> dozens, hundreds, or even thousands of innocent users=20 >>affected. >=20 > There could be, if the DNSBL is built in such a way that=20 >it's > susceptable to that. But it doesn't have to be. And=20 >the good ones > aren't in any meaningful way. How can it NOT be, if a given IP address is sending 50%=20 spam and 50% legitimate traffic, all interleaved? Sorry, I don't agree. Even 2% legitimate traffic is too much to block, if that=20 2% is critically important stuff. [incentives to clean up infected machines] >> ...the problem is that after=20 >>(first!) SMTP >> time, the (intermediary, or final) recipient doesn't=20 >>really know who >> they ought to notify...! Notifying the wrong person, or=20 >>someone who has >> no control over the situation, probably does more harm=20 >>than good. >=20 > You don't need to notify out-of-band. Presuming that=20 >recipient systems > use DNSBLs in an appropriate fashion (inline rejects=20 >with pointers to > more information), legitimate senders find out that it's=20 >blocked and > why. That's their notification. =20 Again, I don't consider it acceptable to block good mail=20 because someone ELSE using the same server or gateway is=20 misbehaving. >With decent DNSBLs,=20 >that's sufficient > to initiate resolution of the problem. It sure is a lot=20 >easier than > tweaking Bayes or SpamAssassin (we specifically reject=20 >whitelisting > email addresses because of the forgery problem) I consider a blanket "whitelist" as nowhere near adequate,=20 because too many addresses are opened up. That's why=20 whitelisting must be done on a far more finegrained basis. > Also, there's a remark somewhere on the CBL web site=20 >that impressed me > with its simplicity - something to the effect that "we=20 >fully expect the > vast majority of infected/blocked users _never_ notice=20 >that they're > listed, because they're using their provider's=20 >smart-hosts as they > should". If an ISP wants to proactively scan for=20 >infected IPs to see > about getting them fixed, they can do that too. You presume that spammers can't send out their spam using=20 the legitimate user's "certifications" and "smart hosts"=20 (and their "micropayment account" if pay-per-email were=20 implemented). I don't believe that's an accurate=20 assessment. (Even if they didn't today, they can change=20 their strategy overnight to do so.) >> [comment #4] >=20 > I'm skipping this one because it takes too long to=20 >comment on ;-) other > than: >=20 >>> Executive summary... >>> >>> - blocking email, because it meets some technical=20 >>>criteria, is easier >>> on the technical side, but introduces legal problems >=20 > It may, perhaps depending on exactly what the technical=20 >criteria _is_ > and the rationale for blocking it, but taking risks when=20 >the business > case/result justifies it, is what people do. If you NEED to do that, sure. But I consider it a poor=20 bet if there are better approaches which don't leave you=20 exposed like that. > You can forestall a lot, for example, by simply saying=20 >"it's our policy > to reject email from IPs that appear to be dynamic".=20 > That says nothing > about the spammyness of an individual sender, and if=20 >mistaken in > "appearance" simply needs to be fixed. Or not. Obviously you can set your policy however you like, but=20 when it gets too cavalier, expect angry customers to start=20 bailing. Again, there is good NO reason to do things that way.=20 (IMHO at least). >>> - blocking email, because the customer said so, may be=20 >>>harder >>> technically, but avoids legal problems >=20 > The ISP could equally establish a infrastructure where=20 >the customer > explicitly delegates filtering decisions to the ISP. Sure, but don't be surprised when customers decide they=20 don't like the ISP's decisions, and it wouldn't take much=20 for an unhappy sender to team up with an unhappy recipient=20 customer and sue the ISP. > And the protections in law for ISPs to be held harmless=20 >for mistakes in > good-faith filtering go a long way to shoot down any=20 >attempt even where > the customers haven't formally delegated. It ain't easy=20 >for a sender to > prove bad-faith. An ISP hasn't been sued in ages. I wouldn't want to be the first one to break that record. [snip] >> ....knowing that all the classical ruses=20 >>to avoid spam >> classification (text as image, embedded links,=20 >>attachments, scripting, >> disguised HTML links, etc etc) are a priori denied=20 >>them.... certainly >> takes a major bite out of spammers. >=20 > It would if you could. How can you tell that an image=20 >is text? It doesn't matter. You simply block (by default) ALL=20 images (whether embedded or attached) coming from=20 unfamiliar/first time senders. If they want to send=20 images, they first negotiate that permission with the=20 intended recipient. (And that permission, of course, can=20 be revoked by the recipient if the privilege is abused). > Blocking spam with embedded links or attachments would=20 >probably put us > out of business. More likely get me fired. It will certainly put MANY spammers out of business, and=20 put virtually ALL virus/worm authors out of business... at=20 least as far as E-mail delivery goes. I don't have a problem with a recipient ALLOWING a=20 particular sender to send them that kind of stuff... as=20 long as an introductory E-mail (in plain text) negotiates=20 that permission with the recipient FIRST. And, a given recipient might configure his setup so that=20 he could look at E-mails that would have been blocked, to=20 decide to allow them in the future... or he can just take=20 a hard line and say "only if approved first!" But in any=20 case they could be marked as suspect/blockable to warn the=20 recipient, before they open them. There is NEVER the NEED to send HTML/attachments/scripting=20 to someone in an INTRODUCTORY E-mail. Not until you've=20 established that they are willing and able to receive that=20 kind of content from you. >> And only allowing executable attachments, HTML, and=20 >>"big" messages from >> known/trusted senders basically eliminates E-mail as a=20 >>vector for >> virus/worm propagation, =20 > "known/trusted" senders by what measure? Explicit=20 >listing of them? Sure. Most users will not EVER need to approve ANYBODY to=20 send them executable attachments. ("listing" can be=20 achieved by clicking an "allow this sender to send me=20 content like this in the future" button.) > Well, I can tell you about lots of viral attachments=20 >from "known senders". Absolutely, but MOST users don't need or want to accept=20 EXECUTABLE attachments from ANYBODY (including "known"=20 senders). That's part of why it is a FINE-GRAINED=20 whitelist and not a crude yes-or-no whitelist (which I=20 agree completely is NOT adequate). I might accept JPG=20 attachments from Aunt Gertrude, but it's a safe bet that=20 any EXECUTABLE attachment in an E-mail (claiming to be...)=20 coming from her... well, I wouldn't touch THAT with a=20 ten-foot pole. I really don't understand why that's such a difficult=20 concept for people to grasp. That (VERY!) simple rule can=20 basically eliminate viruses and worms (again, at least by=20 E-mail) virtually overnight, if adopted net-wide. Given that, it seems to me to be professionally=20 IRRESPONSIBLE to NOT implement it. That is the biggest,=20 fastest thing that the IETF could do IMHO to cripple the=20 recruitment of spambot zombie armies. >> [comment #5] >=20 >> That's certainly true, and one advantage of fine-grained=20 >>recipient >> blocking is that it doesn't require any great worldwide=20 >>consensus, nor >> any re-engineering of Internet infrastructure. >=20 > Nor do DNSBLs ;-) Again, I consider (IP-based, at least) blacklists to be=20 unacceptably crude. You're locking the door after the=20 horse has left the barn. A whitelist is better because a=20 first-time spammer is still left facing a locked door. >> What WOULD be helpful, though, would be a recognition by=20 >>the IETF that: >>=20 >> a) such fine-grained per-sender by-recipient blocking=20 >>(and hopefully >> augmented by subsequent content scanning) is an=20 >>effective and desirable >> approach to the problem, and >=20 > As I've been saying, that has yet to be established. I believe in any case that it is (by FAR) the most=20 promising approach. NOT by itself, but in conjunction=20 with content analysis and possibly other techniques. But=20 it is the primary key to make the other techniques more=20 successful. =20 >> b) in the general case, blocking of all non-whitelisted=20 >>E-mails >> containing HTML, scripting (probably covered under=20 >>HTML... is it >> possible to put in scripting without HTML?), or=20 >>attachments is a "best >> practice". (It is probably a good idea to suggest=20 >>including a maximum >> message size, too, as a way of preventing "denial of=20 >>service" attacks by >> sending big E-mails to someone which would be expected=20 >>to fill their >> E-mail inbox to overflowing, blocking subsequent=20 >>legitimate E-mails). >=20 > Obviously, you've not had to deal with the legitimate=20 >mail traffic of a > large corporation. I mention those measures as comic=20 >relief at > meetings, because it always produces hysterical=20 >laughter. It'd shut us > down. Again, I don't consider anybody as having a legitimate=20 need to send HTML or attachments in first-contact E-mails.=20 If they want to send that stuff, then they should=20 negotiate that permission with the intended recipients=20 first. And they should be prepared for some recipients to=20 say "No, thanks, I'd rather receive plain text." If it's a question of offending those who "laugh=20 hysterically" or shutting down spam, I'll opt for shutting=20 down spam. And I believe that others would agree. So if you think that such a rule would shut your company=20 down (given that a user COULD grant you the permission to=20 send them such mails, after a preliminary meeting and=20 negotiating that) then I propose that your company's=20 long-term future is not bright...! I suggest you get them=20 thinking about how your company could adapt to survive in=20 such a more-responsible world. [snip] >> Again, the problem is the degree of collateral damage=20 >>that IP-based >> blocking produces. >=20 > You haven't demonstrated what that degree _is_. By long=20 >exposure, I can > assure you that the degree is surprisingly low. If you=20 >do your homework > as you're supposed to. If you block the mail from a big company's server(s)=20 because one user within that company has an infected=20 computer that's been recruited as a spambot, I don't think=20 it's a great consolation that "gee, we hadn't seen that=20 happen before." Especially if the block thus established=20 causes serious financial harm to said company. > We're receiving 1-2 million emails per day. 80-90% of=20 >that is spam. We > have less than 10 FPs per month against Spamhaus'=20 >sbl-xbl (which is > doing about 85% of our filtering). We've arranged=20 >things so that the > sender finds out if they're blocked, and there's a well=20 >established > procedure by which they can notify us and we can=20 >override listings. >=20 > If an email is blocked, they contact us, and we forward=20 >their email and > fix the listing, is it really a FP? No. >=20 > If every sender correctly interpreted the error message=20 >they got and > followed through, then there'd be zero FPs. Some VERY large ISPs (such as Yahoo) interpret a "hard=20 bounce" message due to an infected E-mail as "this E-mail=20 address is bouncing" and they disable sending all mail to=20 the user involved. Stupid? Yes, of course. But YOU try=20 to convince them to change that policy. They are totally=20 non-responsive. Worse, they only provide the now-disabled user with the=20 SINGLE LINE saying the 5xx bounce reason message... saying=20 what virus was found... thus NO clue as to WHO bounced the=20 mail back, or where else it might have come from. So, of=20 course, this is totally useless. > I wish our content filters even remotely approached=20 >being _that_ good. If you didn't have to contend with HTML (and the various=20 ruses that allows to obscure content), and attachments,=20 they would be FAR more effective. Not allowing HTML from=20 unapproved senders would also negate nearly all pfhishing=20 exploits, since you couldn't have misrepresented links to=20 click on, or buttons that take you to (hidden)=20 disreputable Web sites using (invisibly-)obscured URLs. >> [comment #6] >>=20 >> [how users configure their whitelist rules] >>=20 >>> The problem being that out of the 60,000 seats here,=20 >>>perhaps less than >>> 10 of them are able to competently configure a set of=20 >>>rules like what >>> you have. =20 >>=20 >> That's a software implementation issue, not an inherent=20 >>problem in the >> approach. I envision a button to click on that simply=20 >>says "allow >> E-mails like this from the same sender in the future"=20 >>and where the >> software will open the keyway JUST enough to allow that=20 >>type of message >> if seen again from that sender. How that recognition is=20 >>accomplished, >> whether by something crude like simple GREP-type=20 >>scanning, or something >> brain-damaged like RegEx pattern matching, or something=20 >>still more >> sophisticated like the pattern matching SNOBOL/SPITBOL=20 >>offers, or even a >> different sort of statistical ranking/rating approach=20 >>like content >> scanners use... will vary from one implementation to=20 >>another. The final >> products will probably use a combination of techniques. >=20 > I'm sorry, this simply isn't a human interface issue.=20 > No amount or > technique of per-sender whitelisting comes remotely=20 >close to the > accuracy of our production filters, entirely aside from=20 >the new > correspondent issue. It's not a simple "per sender" whitelist. It is a=20 fine-grained per-sender PERMISSIONS list, which enables=20 some types of HTML tags and SOME types of attachments and=20 SOME other characteristics, on a sender-by-sender basis. I don't believe it is possible to come up with as high an=20 accuracy on ANY "one-size-fits-all" rule, "production" or=20 otherwise. There are some mails which I would accept from=20 familiar senders, where the SAME mail (same content, same=20 subject line) would be spam if it came from anybody else.=20 You simply cannot possibly know who I would accept that=20 mail from, and who I wouldn't, unless I tell you. > You could give our users common filtering software (the=20 >reader is > already pretty much standardized) with every filtering=20 >knob known to > man, and perhaps three of our users could approach the=20 >effectiveness of > the production systems. =20 I'm not suggesting that users have to "roll their own"=20 from ground zero. Agreed that 90% of users will have 90%=20 of their senders operating on the defaults. And your=20 "production systems" can of course be tweaked and upgraded=20 as spammers adopt new techniques. That doesn't in any way demonstrate the lack of value in=20 what I am proposing. > I'm only including _me_ in that=20 >list because > it's me who built the production systems... Over a=20 >million decision > items are being changed every day in our filters. >=20 > Our users simply don't know effective spam filtering=20 >techniques. They > push the wrong button, twist the wrong knob, and they're=20 >blocking > something business critical. Or trusting malicious=20 >content with forged > credentials. Or simply trusting... Agreed that it ought to default to "simple". But the=20 defaults can still be HIGHLY effective. There is VERY little excuse for ANYBODY needing=20 traditional antivirus scanners for incoming E-mail. That=20 kind of garbage ought to be, and can easily enough be,=20 squashed outright by responsible ISPs. > My favourite incident was the user who repeatedly=20 >insisted that he > needed to receive the "important information from the=20 >FBI" that was > sitting in his quarantine, and the quarantine forwarder=20 >refused to > forward to his mailbox. >=20 > Sorry, I said, but as much as you may want to see it,=20 >forwarding the > virus is a really bad idea ;-) Obviously most phishing exploits work by "social=20 engineering" to convince a user to let them in, or to=20 provide them information they shouldn't provide. And some=20 users will always fall for the "Aggie Virus" approaches=20 (like users who forward hoaxes). I think we can agree, however, that by default delivering=20 E-mails to clueless recipients that contains executable=20 attachments is a Really Bad Idea too. The trick is to=20 decide how you can implement that restriction, while still=20 allowing them to be sent in the 0.01% of the cases where=20 the sender expects and trusts and WANTS them from a given=20 sender. I believe that my fine-grained whitelist answers=20 that need, and does it (VERY) well. >> Again, I consider IP-based blocking to be inherently=20 >>flawed, to the >> point where I consider it a dead-end. >=20 > It's a remarkably vigorous dead end ;-) If the only tool you have is a hammer, you'll try to make=20 every problem look like a nail. Popular does NOT mean that it's good. [snip] >> Yeah, I admit that I usually at least cast a cursory=20 >>eyeballing of the >> Yahoo mail "spam" folder too, rather than just emptying=20 >>it.=20 >> Occasionally I -do- find a non-spam message there.=20 >> (Although that >> happens seldom, as I almost never give that E-mail=20 >>address to anybody... >> It's almost useful as a "personal honeypot" to see=20 >>what's being spammed >> out, before going to my more usual E-mail accounts and=20 >>possibly >> wondering if that curious E-mail just MIGHT be=20 >>legitimate). >=20 > "Almost useful" is the key. When you have users whose=20 >spam load ranges > from one or 2 per month, to 4000+ per day, you can see=20 >that junk folders > have only limited usefulness, and not to everyone.=20 Agreed. That's why users need to be able to choose what=20 level of acceptance of the automated filters is most=20 acceptable to them, and what level of time they are=20 willing to devote to "questionable" mail. > Nobody can find > legitimate email in a 4000 spams/day feed, now matter=20 >how the filters are implemented. True enough, but if a person is willing to simply agree=20 that they don't want to see HTML or attachments from=20 unfamiliar senders, that instantly blocks a LOT of the=20 garbage. Simple, and HIGHLY effective. AND it makes the remaining content-based filtering FAR=20 more effective, by blocking stuff like 'text as image'=20 (whether attached or embedded as a link... or even=20 generated by a decrypting script). And again, they can relieve that restriction on a=20 sender-by-sender basis, if they need and want to, based on=20 previous negotiation with such senders. > Perhaps part of your problem is that you're not seeing=20 >the big picture > of how you can _use_ DNSBLs or any other filtering=20 >technique. I've been involved with BBSes and dealing with spam since=20 the pre-Internet days, but please feel free to educate me=20 if you think there's something worthwhile you can teach=20 me. :-) I'm not too old a dog to learn new tricks. > Your remarks seem to imply that DNSBLs necessitate no=20 >notification > anywhere, the email just disappears. Or that filtering=20 >in general is > that way. There are clearly all kinds of ways to deal with=20 "questionable" mail. That's something that is going to=20 depend on how the software is implemented, and what=20 options the recipient selects. There is a lot of room in=20 this area for programmer creativity. > On the contrary, ours have never done that. Indeed,=20 >without anybody > looking at quarantines, without anybody personally=20 >twiddling filters, > that 4000 spams/day user _does_ get the email that was=20 >accidentally > blocked. Simply because we do inline rejects with=20 >instructions on what > to do, and problems get fixed fast and without harm. Some antispam filtering obviously works better than=20 others. IMHO, if you don't have a finegrained permissions list on=20 a per-sender basis, yours COULD work BETTER than it does=20 today. [snip] >> The important thing is that the RECIPIENT >> controls that, so they can decide the rule that=20 >>determines what gets >> blocked and what gets through. That way they don't have=20 >>to wonder what >> SHOULD have been delivered to them and wasn't. >=20 > But what if you arrange things so that the recipient=20 >doesn't have to > control the rules, and still doesn't have to wonder? I think that a per-sender rule can ALWAYS make things=20 better and more accurate. That doesn't negate the value=20 of good pre-sets and defaults. But again, if by default you let executable attachments=20 from unfamiliar senders get delivered (or if you block=20 them for ALL senders) then your software COULD do better. > Our false positives are handled usually without the=20 >recipient even > knowing that something got blocked. OK, so how do you handle them, specifically? >> Spammers have gotten good at throwing enough random junk=20 >>into E-mails to >> confuse Bayesian filters. >=20 > And sender whitelisting and... Again, don't confuse a simple sender-whitelist with a=20 fine-grained per-sender PERMISSIONS list. The difference=20 is absolutely night and day. Even if I allow Aunt Matilda to send me JPGS of her=20 poodle, I don't care how many worms her infected computer=20 sends to me with HER from: address and via HER mail=20 server. My approach will let me see ALL of her real mail,=20 and rapidly and accurately discard all of the worms with=20 executable attachments that her system sends me. It is EASY to do discrimination like that. And if I don't=20 have ANYBODY set to allow them to send me executable=20 attachments, or HTML to use links or scripting for that=20 purpose, then it's hard to see how such a rule can be=20 "confused" or bypassed by a spammer. It's like trying to=20 argue with a vending machine... you don't know until=20 you've put your money in that it's not going to deliver=20 your purchase, and it's absolutely pointless to try to=20 argue with it after the fact. :-) [snip] >> ....giving the recipient the ability to at=20 >>least not see the >> SAME kind of stuff over and over again, if they choose=20 >>to use those >> features, demonstrates the ISP's trying to give the user=20 >>the tools to >> reduce the frustration. >=20 > If you can _detect_ the "SAME kind of stuff" over and=20 >over again. =20 Sometimes that's very simple. For example, even the very=20 limited filtering the Webmail I'm presently using offers=20 allows me the ability to tell it that I don't want to see=20 anything more from "Fifth Third Bank" (in either the From=20 or Subject fields), where I am not a customer. Anything=20 from them is clearly spam. It is frustrating that I can't use a SNOBOL/SPITBOL-like=20 pattern to describe spam rules, but I readily admit that=20 most users would rather not do anything that advanced.=20 (That would CLEARLY however be my 'programming language=20 of choice' to write such a filtering tool, though). Even=20 something relatively brain-damaged like RegEx pattern=20 matching would be an improvement, although still=20 frustrating. > Even the best content techniques aren't very good at that=20 >anymore. Not automatically, no. But if there is something the user=20 considers adequate evidence of spam (say, a subject which=20 contains both the words Penis and Enlarge) then it's=20 satisfying to be able to at least block THAT case once and=20 for all. Lots of cases? Sure, but every new rule at=20 least saves you from seeing THAT one again. Longer-term, more sophisticated rules would work better.=20 But that's why one needs per-sender rules which include=20 not just From and Subject but also content within the=20 E-mail message body too. Or for another example, somehow an E-mail address of=20 "errorstogep...@domain" got on a spammer E-mail targets=20 list. Any E-mail which contains that anywhere in the=20 header is spam, even if it also contains my "good" address=20 elsewhere. > Correctly chosen and utilized DNSBLs do a vastly better=20 >job. They're certainly better than nothing. But again, I don't=20 believe that it's possible to do GOOD blocking, and=20 minimize collateral damage, without per-sender=20 fine-grained whitelisting which also takes into account=20 the body content of the individual E-mail. And as a recipient, it's very frustrating to see dozens or=20 hundreds of similar E-mails continue to slip through an=20 ISP's filters, especially when I can readily define a rule=20 which IMHO adequately identifies them. As a user, I want=20 that ability, and to not continue to subsequently see=20 those E-mails. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 05:24:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOCs-0006Jh-4I; Fri, 26 Jan 2007 05:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOCr-0006Jc-1C for asrg@ietf.org; Fri, 26 Jan 2007 05:21:17 -0500 Received: from cl-108.dub-01.ie.sixxs.net ([2001:770:100:6b::2] helo=dogma.boxhost.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOCp-0005XV-M3 for asrg@ietf.org; Fri, 26 Jan 2007 05:21:17 -0500 Received: from radish.jmason.org (localhost [127.0.0.1]) by dogma.boxhost.net (Postfix) with ESMTP id 1F80F31008B; Fri, 26 Jan 2007 10:21:02 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 2A6F432CE0; Fri, 26 Jan 2007 10:20:48 +0000 (GMT) To: "Chris Lewis" Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <45B95E3F.6090605@nortel.com> From: jm@jmason.org (Justin Mason) X-GPG-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 Date: Fri, 26 Jan 2007 10:20:48 +0000 Message-Id: <20070126102048.2A6F432CE0@radish.jmason.org> X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Chris Lewis writes: > Tony Finch wrote: > > On Thu, 25 Jan 2007, Martin Hannigan wrote: > > >> By tracking the historical behavoir of /32's or larger allocations, we > >> could develop a profile of the behaviors that will eventually establish > >> a baseline for those allocations as "good" "nuetral" or "bad", to keep > >> it kind of simple. A lot of this data is already out there. > > > > Yes, blacklists do this already, though they are binary not ternary. > > That's not necessarily true. Many DNSBLs are already multi-valued > (zen.spamhaus.org presently has 6 independent "flags"), and they can be > constructed to be more sophisticated with as many as 2^24 values on a > single return, and/or being used in scoring. It's simply a matter of > deciding on the convention, publishing it, and having admins configure > to the intended interpretation (or not :-(. Yes -- in fact, IronPort's SenderBase at one point used TXT records, containing a complex encoding of many attributes and ratings. (Maybe they still do.) A few of the commercial anti-spam vendors call this kind of thing a "reputation service". --j. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 06:06:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOto-0004X6-Rr; Fri, 26 Jan 2007 06:05:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOtn-0004X0-Rp for asrg@ietf.org; Fri, 26 Jan 2007 06:05:39 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOtj-0004zw-Jp for asrg@ietf.org; Fri, 26 Jan 2007 06:05:39 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HAOth-0002QD-00; Fri, 26 Jan 2007 11:05:33 +0000 To: clewis@nortel.com From: Tony Finch Subject: Re: [Asrg] Re: per recipient status In-Reply-To: <45B95E3F.6090605@nortel.com> References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> Message-Id: Date: Fri, 26 Jan 2007 11:05:33 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Chris Lewis" wrote: >Tony Finch wrote: >> >> Yes, blacklists do this already, though they are binary not ternary. > >That's not necessarily true. Many DNSBLs are already multi-valued >(zen.spamhaus.org presently has 6 independent "flags"), and they can be >constructed to be more sophisticated with as many as 2^24 values on a >single return, and/or being used in scoring. AFAIK all the multi-value blacklists are combinations of multiple underlying binary blacklists, and exist to reduce the number of DNS lookups needed to do multiple blacklist lookups. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: NORTHEAST 4 OR 5. ROUGH BECOMING MODERATE OR SLIGHT. SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 06:09:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOxM-0006UU-Ut; Fri, 26 Jan 2007 06:09:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOxL-0006UL-9m for asrg@ietf.org; Fri, 26 Jan 2007 06:09:19 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOxE-0005Zc-3N for asrg@ietf.org; Fri, 26 Jan 2007 06:09:19 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAOx2-0007gr-Vi for asrg@ietf.org; Fri, 26 Jan 2007 12:09:01 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 12:09:00 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 12:09:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 12:03:04 +0100 Organization: Lines: 42 Message-ID: <45B9DFE8.7568@xyzzy.claranet.de> References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> <45B95E3F.6090605@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Asrg] ZEN (was: per recipient status) X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Chris Lewis wrote: > Many DNSBLs are already multi-valued (zen.spamhaus.org presently has > 6 independent "flags"), and they can be constructed to be more > sophisticated with as many as 2^24 values on a single return, and/or > being used in scoring. Thanks for info, I still had "sbl-xbl" instead of "zen" in a script. I'd really love it if they'd take the same approach as SURBL (or the former OPM) with sets represented by bits. At the moment they have apparently eight sets (2, 4,5,6,7,8, 10,11) encoded as integers. Using bits 1..8 (127.0.0.2 up to 127.0.1.0) they could get a similar effect, and even indicate if IPs belong to more than one set at the same time. That's what multi.surbl.org does (with 6 sets), and Jeff asked implementors to support at least bits 1..15 for 15 sets. The OPM scheme was also nice, use the 2nd byte for something that's never zero (e.g. a version number for incompatible definitions of the remaining two bytes). That also avoids any potential trouble with a "listed" 127.0.0.1, and supports up to 16 sets (using bit 0 is no problem if the second byte is never zero). > It's simply a matter of deciding on the convention, publishing > it, and having admins configure to the intended interpretation > (or not :-(. For the "or not" part it would be nice to publish the DNSBL draft http://tools.ietf.org/html/draft-irtf-asrg-dnsbl as RFC, but maybe that project still waits for an update of the IRTF RFC publication procedure. >> http://www.completewhois.com/bogons/bogons_usage.htm > I was going to mention that... ...does it work again ? I've recently removed it because it didn't pass the "127.0.0.2 listed" test anymore. For similar reasons I've removed wadb.isipp.com in 2005. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 10:41:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATAP-0008VP-Le; Fri, 26 Jan 2007 10:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATAO-0008VG-Rk for asrg@ietf.org; Fri, 26 Jan 2007 10:39:04 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATAL-00077h-K7 for asrg@ietf.org; Fri, 26 Jan 2007 10:39:04 -0500 Received: from [207.65.71.19] (pool-71-252-106-203.washdc.east.verizon.net [71.252.106.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 3AA1C3F5EA for ; Fri, 26 Jan 2007 09:39:01 -0600 (CST) Message-ID: <45BA207B.9090907@ehsco.com> Date: Fri, 26 Jan 2007 10:38:35 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> In-Reply-To: <45B9070C.4060806@ehsco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/25/2007 2:37 PM, Eric A. Hall wrote: > Ordering is always preserved in SMTP (even where pipelining is enabled), > and text after the code is usually ignored for protocol purposes > (usually), so that's presumably what I meant but I'd have to find my brain > from 2004 to answer for sure. I suppose I should fix this in the next > draft, as well as rename the extensions. I resubmitted the I-D as draft-hall-deferrals-01.txt The SMTP extension and the MAIL FROM command extension are both called DEFERRALS now. There was already a paragraph in section 6.2 about order of response being preserved but I moved it into 6.3. Makes more sense there. When this response code is returned, absolute response codes for each of the recipients which were earlier acknowledged with a 352 response code during the envelope exchange MUST be provided, and must be provided in the order in which they were originally received from the SMTP client. A section head was renamed, but otherwise no other changes were made. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 11:48:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUDH-0003ZY-54; Fri, 26 Jan 2007 11:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUDF-0003ZR-ML for asrg@ietf.org; Fri, 26 Jan 2007 11:46:05 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUDC-0002U7-IS for asrg@ietf.org; Fri, 26 Jan 2007 11:46:04 -0500 Received: from torch.brasslantern.com ([71.116.79.148]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JCH007PTIIRVBY2@vms040.mailsrvcs.net> for asrg@ietf.org; Fri, 26 Jan 2007 10:44:54 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id l0QGinZC016166 for ; Fri, 26 Jan 2007 08:44:50 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id l0QGimcS016165 for asrg@ietf.org; Fri, 26 Jan 2007 08:44:48 -0800 Date: Fri, 26 Jan 2007 08:44:48 -0800 From: Bart Schaefer Subject: HTML-burdened email (Re: [Asrg] Re: bounces, and anti-spam principles) In-reply-to: To: asrg@ietf.org Message-id: <070126084448.ZM16164@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: Comments: In reply to "Re: [Asrg] Re: bounces, and anti-spam principles" (Jan 26, 1:53am) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 26, 1:53am, wrote: } Subject: Re: [Asrg] Re: bounces, and anti-spam principles } } I don't consider that ANYBODY has the right to blindly } haul off and presume that I'm willing to accept } HTML-burdened E-mails from them. You're welcome to take that position, but it doesn't seem to fit with the rest of your argument that what gets accepted should be controlled on a per-user basis. Elsewhere you wrote: } Even 2% legitimate traffic is too much to block, if that } 2% is critically important stuff. How is blocking legitmate email because it contains HTML less wrong than blocking it based on point of origin? } It doesn't matter. You simply block (by default) ALL } images (whether embedded or attached) coming from } unfamiliar/first time senders. If they want to send } images, they first negotiate that permission with the } intended recipient. (And that permission, of course, can } be revoked by the recipient if the privilege is abused). [...] } There is NEVER the NEED to send HTML/attachments/scripting } to someone in an INTRODUCTORY E-mail. Not until you've } established that they are willing and able to receive that } kind of content from you. This presumes a whole lot of effort on the part of the recipient in a variety of circumstances. (1) I'm shopping at a major retailer's website and decide to sign up for their newsletter. What happens if the confirmation message uses HTML content (not uncommon)? But let's presume everyone has bought into your scheme, so a plain text confirmation arrives. I now have to take the additional step of confirming (where? has my email client but updated to include an interface for this?) that I'll accept HTML from the same source in the future. Assuming that the confirmation and the newsletter come from the same source, that is, which also is not always the case. (2) I'm working with an HTML design firm. They're doing a rush job for me, which has to be confirmed on Saturday so it can be turned over to my IT staff to be installed on the company website before Monday morning; but I'm going to be out of town, so I want a copy of the work sent to another address such as a freemail service so I can easily review it. The HTML contains images and scripts, but the design firm has never sent mail to that freemail service before, and I don't know which of their team of designers might be sending the final product. How much effort must I go to up front to be able to tell them they can send me an attachment that I know will reach me? (3) My biggest customer is a giant corporation which requires its employees to use Microsoft Outlook and to attach a vCard-like signature to every email, using a background stationery and having an image of the company's latest logo because they're engaged in a major rebranding initiative. Not surprisingly, they have massive turnover, so the people there who send email to a variety of people at my company changes every several weeks. Who's responsible for upkeep of all of those individual agreements to exhange HTML with each other? _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 12:03:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUTd-0005DJ-Nd; Fri, 26 Jan 2007 12:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUTc-0005DA-Gf for asrg@ietf.org; Fri, 26 Jan 2007 12:03:00 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUTb-0004Wh-2W for asrg@ietf.org; Fri, 26 Jan 2007 12:03:00 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0QH2uE06535 for ; Fri, 26 Jan 2007 12:02:56 -0500 (EST) Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:02:53 -0500 Message-ID: <45BA343A.2000402@nortel.com> Date: Fri, 26 Jan 2007 12:02:50 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] ZEN References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> <45B95E3F.6090605@nortel.com> <45B9DFE8.7568@xyzzy.claranet.de> In-Reply-To: <45B9DFE8.7568@xyzzy.claranet.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 17:02:53.0723 (UTC) FILETIME=[D19AAEB0:01C7416B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Ellermann wrote: > Chris Lewis wrote: > >> Many DNSBLs are already multi-valued (zen.spamhaus.org presently has >> 6 independent "flags"), and they can be constructed to be more >> sophisticated with as many as 2^24 values on a single return, and/or >> being used in scoring. > > Thanks for info, I still had "sbl-xbl" instead of "zen" in a script. > I'd really love it if they'd take the same approach as SURBL (or the > former OPM) with sets represented by bits. At the moment they have > apparently eight sets (2, 4,5,6,7,8, 10,11) encoded as integers. They've mentioned 8, but they're only _using_ 6. 2 are "reserved" ;-) The items for XBL are somewhat in a state of flux, so they're basically telling people that if you trust XBL, you can trust any of the other two values if they become "real". > Using bits 1..8 (127.0.0.2 up to 127.0.1.0) they could get a similar > effect, and even indicate if IPs belong to more than one set at the > same time. That's what multi.surbl.org does (with 6 sets), and Jeff > asked implementors to support at least bits 1..15 for 15 sets. I _used_ to prefer bitmapped DNSBLs, but I've been persuaded (and learned thru personal experience) otherwise. One main reason why they're not using bitmaps is the difficulty in construction. If you use bitmaps, you have to explicitly merge each entry when you build your zone - completely reconstructing the zone file. With big DNSBLs that can be quite time-consuming just to do a hack job. There isn't any freeware code presently available to do that. Spfilter, for example, will die the "out of memory" death if you try to combine, say, CBL and one or two other large DNSBLs, and doesn't have a way to intelligently combine A records anyway (spfilter only merges (part of) the TXT record, but not across ranges). We used to use spfilter. Remembering those days makes me cringe. Was taking over an hour to merge when I finally killed it. In contrast, rbldnsd makes it trivial to merge. Each zone retains its separate identity, as a separate file if you wish. Munging entries is completely optional. rbldnsd simply returns _all_ matching records in a single DNSBL query. By "hack job", I mean that most merging mechanisms (including spfilter) trying to derive a single (eg: bitmapped) entry does not handle nesting at all. Eg: trying to coalesce a /24 PBL entry, a /22 SBL entry, and a /32 XBL entry into a single bitmap is computationally difficult and expensive. This matters both to the DNSBL publisher, and the user of DNSBLs who wishes to use local servers. Like us. We're currently using about 10 DNSBLs (5 of them locally constructed). All of them are combined into local rbldnsd under a single query. Aside from some TXT mangling needed to make FP handling more consistent, and remapping A values so that we have unique values across all subzones, we don't actually have to _look_ at the zone contents when we merge - just tell rbldnsd "publish these dnsbl files". Remember it was simple for OPM to do this, because they only listed /32s, and it was really only one (relatively small) database. You _have_ to handle multiple A records if you want to deal with varying range entries so that you get all hits (scoring for example). In contrast, SORBS, NJABL and Spamhaus (using the combined query naming) all use the multiple A return approach. NJABL (mostly) publishes them as a single file, but the entries are not merged. There have been a few DNSBLs that have had somewhat different return code schemes. Like one which would return an integer "badness" score. And another where you could encode specific questions (beyond just the IP) in the query and get a numeric code back. But they were only experimental. >>> http://www.completewhois.com/bogons/bogons_usage.htm > >> I was going to mention that... > > ...does it work again ? I've recently removed it because it didn't > pass the "127.0.0.2 listed" test anymore. For similar reasons I've > removed wadb.isipp.com in 2005. I stopped using it some time ago because it wasn't yielding much. I should check again. I just turned off SORBSproxy and SORBSsocks (no longer using SORBS at all), so, I can afford to add one ;-) I'll direct you to this comment in the bogons zone file: # This file does not include the following additional iana reserved blocks: # 10.0.0.0 - 10.255.255.255 - reserved for intranet local networks # 127.0.0.0 - 127.255.255.255 - reserved for local loop on each computer # 172.16.0.0 - 172.31.255.255 - reserved for intranet local networks # 192.168.0.0 - 192.168.255.255 - reserved for intranet local networks # 224.0.0.0 - 239.255.255.255 - used for multicast routing In other words, using 127.0.0.2 as a test entry for the bogon list is more than a bit, shall we say, ambiguous. If you use the zone file, you can tell whether it's "working" by the size and datestamp on it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbo0Op3FmCyJjHfhAQLljwQAwYgloKaiwQ74nEu5tcPsefemkh68XgMs XceH21TR2AD1x2/hh5Y5UwZ8pdtSP+QKctPtRrZo4Z7G0yykT14s6PoLHhts3JaL cbxzWKtZPbUaa9jMXK7uZR9Xz7zKtgz6pYzyDO2iyHh/TjEAbpGsuytEg3gRBtG3 WotE+UuSNPA= =AYzj -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 13:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVp7-0008Ar-DG; Fri, 26 Jan 2007 13:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVp6-00089t-31 for asrg@ietf.org; Fri, 26 Jan 2007 13:29:16 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVp4-0008Ei-Ox for asrg@ietf.org; Fri, 26 Jan 2007 13:29:16 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0QILRj01181 for ; Fri, 26 Jan 2007 13:21:27 -0500 (EST) Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:29:12 -0500 Message-ID: <45BA4875.9050509@nortel.com> Date: Fri, 26 Jan 2007 13:29:09 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: per recipient status References: <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070124181036.GA27184@zardoc.esmtp.org> <45B7B556.3020508@ehsco.com> <934f64a20701241530r12cfe0f1sf3e2071a2f2bd5e9@mail.gmail.com> <2d106eb50701241933m43cfd7afxee799a58db412a06@mail.gmail.com> <2d106eb50701251519x39ad513cyab6c91a42a57c761@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 18:29:12.0192 (UTC) FILETIME=[E0365800:01C74177] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote: > "Chris Lewis" wrote: >> Tony Finch wrote: >>> Yes, blacklists do this already, though they are binary not ternary. >> That's not necessarily true. Many DNSBLs are already multi-valued >> (zen.spamhaus.org presently has 6 independent "flags"), and they can be >> constructed to be more sophisticated with as many as 2^24 values on a >> single return, and/or being used in scoring. > > AFAIK all the multi-value blacklists are combinations of multiple > underlying binary blacklists, and exist to reduce the number of > DNS lookups needed to do multiple blacklist lookups. There are exceptions. One of the regional DNSBLs returns (encoded) country codes in the A, rather than answering binary questions like "is this IP in china?". I could build that myself[+]. I have seen experimentations with DNSBLs that return message counts and other non-binary info. Several of my internal DNSBLs are computed from scores. I could just as easily publish the scores themselves rather than a binary "did it exceed the threshold?". The latter is operationally easier for us. Historically, most DNSBLs return binary values (or a set of binary values). But they don't have to, and some don't. Secondly, obviously, you don't have to treat the binary values as individually definitive. SpamAssassin scores DNSBL hits - only block if some combination of DNSBLs are hit. We score DNSBL hits (all but one of them is threshold level scores. The one remaining is a bit pointless at the moment, but we want the hit metrics and we'll add more sub-threshold scoring DNSBLs in future). [+] Come to think about it, I already do. I internally serve up an "asn" zone that contains the ASN, cidr allocation, country, state, owner domain, abuse address as TXT records. It's served as a subdomain via our internal rbldnsd DNSBL servers. It's currently used for composing metrics like "What country, ASN, domain is this crap coming from?", but I could have the filters consulting it, and tell it to, say, nuke particular ASNs, owner domains etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbpIdZ3FmCyJjHfhAQKKsgQA8Kscb0/cc2phOYcLGrFNbJTfODc7kovW SQSkF0nRRx62g6V+rrhD/HRzwPv+HWZ98wEH4iogf6VH5p19TXqNmWB+zbLzkFxI 8jLdC1moUJ64dG1GDeV5LS3PHy6g6BqmKr8Plc/QghuF3Rx38/My0S85MtePGb82 WinjD7W1RSk= =QprP -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Jan 26 23:26:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAf5Q-0004Yx-D0; Fri, 26 Jan 2007 23:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAf5P-0004Yr-T0 for asrg@ietf.org; Fri, 26 Jan 2007 23:22:43 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAf5O-0000Oi-JN for asrg@ietf.org; Fri, 26 Jan 2007 23:22:43 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C52F200; Fri, 26 Jan 2007 20:22:37 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0R4Mb71021851 for asrg@ietf.org; Fri, 26 Jan 2007 20:22:37 -0800 (PST) Date: Fri, 26 Jan 2007 20:22:37 -0800 From: Claus Assmann To: asrg@ietf.org Message-ID: <20070127042237.GA24125@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B9070C.4060806@ehsco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org [[Is this the appropriate list to discuss this topic?]] 1. the name is confusing and the new name isn't very helpful either. Let's call it something like "Delayed-RCPT-Status" (DRS) or "RCPT-Status-After-Dot" (RSAD). 2. This is another confusing part: 6. The End-of-Data Response Codes 6.1. The 352 Response Code 6.2. The 353 Response Code 6.3. The Per-Recipient Response Codes 6.4. The Final Response Code My understanding is: 352 is used for RCPT: 6.1. The 352 Response Code The 352 response code is used by a server to indicate that the mailbox address specified in the associated RCPT TO command ^^^^ 353 is used for end of data. So it should be: 6. Additional RCPT Response Code 6.1. The 352 Response Code 7. The End-of-Data Response Codes 7.1. The 353 Response Code 7.2. The Per-Recipient Response Codes 7.3. The Final Response Code BTW: it probably should be 7. The End of Mail Data Response Codes to match RFC 2821. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Jan 27 12:29:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HArIh-0003mg-Eu; Sat, 27 Jan 2007 12:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HArIg-0003ma-FL for asrg@ietf.org; Sat, 27 Jan 2007 12:25:14 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HArId-00047P-TW for asrg@ietf.org; Sat, 27 Jan 2007 12:25:14 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0RHHI129119 for ; Sat, 27 Jan 2007 12:17:18 -0500 (EST) Received: from [47.9.28.70] ([47.9.28.70] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 12:25:00 -0500 Message-ID: <45BB8AE6.7020307@nortel.com> Date: Sat, 27 Jan 2007 12:24:54 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anti-spam principles References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2007 17:25:01.0019 (UTC) FILETIME=[1325BAB0:01C74238] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gep2@terabites.com wrote: >> Our overall system is designed towards _zero_ false positives. In at >> least one way, we're theoretically (and near effectively) there. With >> DNSBLs and other techniques. > > Obviously, I'd have to reserve judgement until I've experienced your > "zero false positives" idea. Let's just say that I've got a healthy > degree of skepticism. I have 10+ years worth of exposure to this model (I built the thing) with a user population of 60-120K and extreme FP aversion all the way up to the CEO, you're welcome to come visit and I'll demonstrate it for you. It only fails to be "zero false positive" when the legitimate sender fails to read/follow the rejection notice. Which happens a lot more than I'd like, but if the message isn't worth that much to the sender, it's probably not worth doing much about it on our end either. >> Not everyone has that small a set of correspondents to cope with, and >> the "new correspondent" issue remains a big problem. > > The total set of correspondents doesn't have to be small. It just needs > to have a relatively small number of NEW correspondents that NEED to use > "advanced"/riskier features and therefore require whitelisting. The question is how do you even know of the new correspondents, when you're being bombarded with dozens or hundreds of new correspondents per day. It's all well and good, if the spammers aren't forging names, to allow them one bite before you null the sender, but today's reality isn't like that. The "one bite" on sender, or even on url or content, essentially means you have to eat almost all spam. Because spammers mutate their content and senders that much. We're tracking spammers who use in excess of 1000 different domains in urls. Can per-user techniques cope via whitelisting or blacklisting? Not a chance. The only way your techniques can work effectively is if you assume that the recipient is getting very little spam. Well, 50% of our users are being sent almost no spam. But that doesn't help with the guy getting sent 4000/day. Or even the hundreds getting 50 or more. The only way your technique works is if you're one user with a limited variety and volume of spam. But not everybody is in the same situation as you. > Ideally, each such correspondent only requires ONE click (one time) for > the user to agree to allowing them to use the more advanced features. > That might be done following an initial negotiation E-mail where the > sender introduces themself and requests the ability to send more > elaborate mails. You seem to be focussing on only blocking "advanced features". A large percentage of spammers don't use them anyway. If all your spam consists of mutating text-only spam with mutating headers, your technique has no effect. > Introductory E-mails should NOT automatically presume the desire or > willingness of the recipient to receive HTML-burdened E-mails. But if all spam were indistinguishable from "introductory e-mails", where are you then? And indeed, probably most spam isn't distinguishable from some vague notion of "introductory e-mails" by your technique. > The main problem with content filtering is caused by ruses based on HTML > and attachments. These techniques serve to obscure the content of the > E-mail, and ALL BY THEMSELVES the presence of such content in E-mails > (at least in E-mails from unfamiliar senders) can be a priori evidence > of hostile intent, or spamming. If you can _detect_ those ruses. You and I may be able to detect it in on a per-message basis with visual inspection, but computers generally can't, say, identify sentences generated using random words. Try building a filter for hipcrime some day... Plain text. Random headers. No "advanced features". Good luck. Much of the recent evolution in spam content techniques has been to get away from ruses that are detectable as ruses. It used to be a common technique to insert random invalid html tags in spam. Defeatable by simply looking for invalid html tags or meta (eg: tag)/content ratios. But they don't do that anymore, do they? And meta/content ratios can be _extremely_ high in legitimate email (just look at the gunk that outlook produces for simple emails some day). Look for identical gifs? Well, they stopped emitting identical gifs months ago. I had some luck with looking for gif geometry (scan for gif prefixes containing identical image dimensions). That stopped working too. >>> Again, when you have a LOT of users (and possibly MANY servers) behind a >>> NAT router, denying mail from that IP address results in simply too much >>> collateral damage. More to the point, it's a very blunt instrument for >>> the job, and it's relatively simple to do very much better. >> >> So far, there's no indication of the latter being true. > > I do note you don't refute my objection on principle. :-) But in fact, I do. Let's cut to the chase. Your argument about source IP blocking being a blunt instrument is well-taken and true. It _is_ a blunt instrument. So's a sledgehammer. You wouldn't use a sledgehammer to install window trim would you? But a carpenter probably still has and uses a sledgehammer for a different part of the same job of building a house. Your argument assumes that IP-blocking is the ONLY technique being used - - if all you have is IP-blocking, trying to discriminate between good and bad content from a given IP (say an ISPs MTA) doesn't work. Well, yeah, duh ;-) Your argument assumes that the administrator hasn't made any effort to make an intelligent choice on which DNSBL to use - and is hence at the mercy of capricious listings of any old random IP. Well, yeah, if you've chosen to use BLARS, you get what you deserve. Yup both true. But so what? What's to prevent you from doing the intelligent thing and using multiple complementing techniques simultaneously? What's to prevent you from making intelligent choices of _which_ techniques to use? Nothing. The XBL, for example, is _extremely_ reliable at detecting compromised end-user machines. All by itself it will block 70-85% of all spam. By it's very nature it doesn't list real MTAs (eg: ISP smarthosts). It has a false positive rate lower than virtually any content filter. Certainly _way_ lower than any notion of trying to block spam based on detecting "advanced features". Does that work to stop Nigerian 419s coming from Hotmail's mail server? Well, short of blocking them entirely, no. Does the XBL "fire" on the Hotmail mail servers? No. So you add other techniques to the filters that will do it. Does that mean that the XBL is useless? No. Does that mean it has excessive false positives? No. Does that mean that the XBL has excessive false negatives - well, yeah, entirely by itself, yes - but so _what_? Just add more filtering techniques. Do those techniques used for blocking 419s from Hotmail make XBL unnecessary? Because they're not perfect either. Why not let the users choose? How many of your users know what the XBL is? About 5 of mine _might_. I'm not even sure you do. How many of them have spent the manhours needing to learn what knobs do a good job? Less than that. How many of them would do nearly as a good job at it? Probably almost none. It simply doesn't scale. Unless you're a spam geek. My management pays me to be the spam geek, so they don't have to spend hundreds of times as much turning everybody into a spam geek. Even I, with over 10 years of experience in this game, could not do an acceptable job on email landing in my _own_ mailbox using your techniques. We have to resort to the leverage provided by techniques only possible/practical thru server-based, and discussed in places like here and other mailing lists. I'm the only one of our users that is on this list. And most other anti-spam mailing lists. That (mailing lists) is an important technique too. But it obviously doesn't scale to everyone in the company ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbuK5p3FmCyJjHfhAQJBegQA3sC/Mj5pAzJrlyPMYAZteVObtsuvj9Oj jDxYr6sKMJqYkzk32rGkFWzxfpl68s1cDFGBz14qfUmt7TC7z9D0bHA66sZl+Wee TpXQaS5ZIh0ybkWJjdHKIDYqFikfHmQYADOy2XP3NL2iAWkDV1bHAsTjBgQrpfmD tHlS9FJtOYY= =apDB -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Jan 27 13:29:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsHV-0001Rj-Vz; Sat, 27 Jan 2007 13:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAsHU-0001Rd-GV for asrg@ietf.org; Sat, 27 Jan 2007 13:28:04 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAsHP-00089J-Rd for asrg@ietf.org; Sat, 27 Jan 2007 13:28:04 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 7CDEE4039; Sat, 27 Jan 2007 19:27:46 +0100 (CET) Date: Sat, 27 Jan 2007 19:27:46 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: bounces, and anti-spam principles Message-ID: <20070127182746.GC17394@hjp.at> Mail-Followup-To: asrg@ietf.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784095875==" Errors-To: asrg-bounces@ietf.org --===============0784095875== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-25 19:32:11 -0600, gep2@terabites.com wrote: > [comment #6] >=20 > [how users configure their whitelist rules] >=20 > >The problem being that out of the 60,000 seats here, perhaps less > >than 10 of them are able to competently configure a set of rules like > >what you have. =20 >=20 > That's a software implementation issue, not an inherent=20 > problem in the approach. I envision a button to click on=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I guess that's the main reason why your ideas aren't met with wild enthusiasm here. You "envision" that this would be simple to build and to use, but it's not even clear that you have even built a prototype which you use yourself, much less deployed the system for "ordinary users", which aren't quite sure what an "HTML mail" is, and have never heard about an "ActiveX component". > that simply says "allow E-mails like this from the same=20 > sender in the future" and where the software will open the=20 > keyway JUST enough to allow that type of message if seen=20 > again from that sender. So Uncle Bob will see that a mail from Aunt Matilda was blocked because it contained an "executable attachment". Since he wants to get mail from Aunt Matilda (and Aunt Matilda is a nice lady, she wouldn't send him anything bad, would she?) he clicks on "allow E-mails like this from the same sender in the future". Oops! > How that recognition is accomplished, whether by something crude like > simple GREP-type scanning, or something brain-damaged like RegEx > pattern matching, You know what the two middle characters in "grep" stand for, do you? hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --MnLPg7ZWsaic7Fhd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFu5mifZ+RkG8quy0RAj6UAKCJHLN7IwD1F6DgXqCQsWCMUz9eoQCfRvUY /POLCAfmuzs9ck6svzP3Xkg= =rjTS -----END PGP SIGNATURE----- --MnLPg7ZWsaic7Fhd-- --===============0784095875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0784095875==-- From asrg-bounces@ietf.org Sat Jan 27 22:52:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB11M-0002Ab-D1; Sat, 27 Jan 2007 22:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB11K-0002AO-Rz for asrg@ietf.org; Sat, 27 Jan 2007 22:47:58 -0500 Received: from egress4.webmaillogin.com ([216.40.36.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB11I-000839-MZ for asrg@ietf.org; Sat, 27 Jan 2007 22:47:58 -0500 Received: by egress4.webmaillogin.com (egress4.webmaillogin.com, from userid 1005) id 09B2C770878; Sat, 27 Jan 2007 22:47:49 -0500 (EST) Received: from webmaillogin.com (fr5.webmaillogin.com [216.40.35.69]) by egress4.webmaillogin.com (egress4.webmaillogin.com) with ESMTP id C245B771F21 for ; Sat, 27 Jan 2007 22:44:18 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk3.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 4616485 for asrg@ietf.org; Sat, 27 Jan 2007 20:43:23 -0500 From: Subject: Re: [Asrg] Quarantines and block lists To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Sat, 27 Jan 2007 19:43:23 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 34793307b79a1353c9d03ed8a398bb86 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > [On second thought, I DON'T want to define spam as UBE.=20 >Labeling UBE =20 > as spam labels the sender as a spammer which carries a=20 >negative =20 > connotation. I just want to block UBE without calling=20 >anyone a =20 > spammer and getting sued] Again, all these problems are eliminated once you allow=20 the RECIPIENT to determine what they do and don't want to=20 receive and read. I think it's also worth considering a subtle but perhaps=20 important distinction between recommending that the=20 recipient customer delegate the choice(s) to the ISP, as=20 compared to "suggesting" rules that the recipient customer=20 can choose to select (or not). A litigious spammer could still sue an ISP for=20 implementing rules (especially if those rules change after=20 the customer recipient delegates the authority) which=20 disadvantage the spammer. > Here is my proposal. I'm sure I haven't thought of=20 >everything so =20 > please tell me where it breaks or how spammers are going=20 >to game it. =20 > The goal is to stop the majority of the spam while not=20 >loosing ANY =20 > legitimate email (broken MTAs don't count).=20 To begin with, crude IP blocks will ALWAYS lose legitimate=20 mail, because a single IP address can send both legitimate=20 and zombie-generated mail. I propose that NO ISP-based=20 software will be capable of differentiating one from the=20 other... but the recipient possibly will know how to do=20 that, at least for familiar senders. > This is not intended to =20 > replace existing blocklists but to handle the initial=20 >onslaught from =20 > a spam source until the source can be properly=20 >categorized and listed. >=20 >=20 > Proposal #1 is a quarantine for new sources: >=20 > Connections from unknown source addresses would be=20 >initially rejected =20 > by returning a temporary error code (4xx) for a=20 >probation period. The =20 > probation period could be as short as 5 minutes=20 >depending on how fast =20 > the blocklists can respond. The reject would occur after=20 >the =20 > recipient list is accepted so the recipients can be=20 >checked against =20 > local spamtraps and valid user lists. After the=20 >probation period, =20 > global blocklists would be queried to find the current=20 >reputation of =20 > the source. While spamtraps and valid user lists are helpful=20 sometimes, they will not trigger if the spammer is using=20 "fresh" E-mail address lists which are also devoid of=20 spamtrap E-mail addresses. > Proposals #2 & #3 are for a fast global block advisory=20 >and =20 > distribution network >=20 > Any email addressed to a spamtrap would generate a=20 >report to a local =20 > trap handler. The local trap handler would forward=20 >appropriate =20 > reports to the regional or global blocklist managers.=20 >The blocklist =20 > managers would publish advisories based on the=20 >reputations and counts =20 > of the traps that were hit by the sending IP.=20 IP address blocking, again, is simply too crude. A=20 further and more serious problem is that you have=20 basically no way to be 100% sure of who the "sending IP"=20 actually is. For just one example, Yahoogroups send millions of E-mail=20 messages per day, from (doubtless) a large server farm.=20 Different Yahoogroups vary dramatically in terms of how=20 attentively they are moderated. Some are moderated with=20 great care; other groups have been abandoned or stranded=20 by their owners and have been operating on autopilot, some=20 for many years, and many such groups have been=20 'discovered' and are heavily abused by spammers. (Indeed,=20 it seems that many Yahoogroups send very little OTHER than=20 spam). So what IP address(es) do you plan to block? All=20 of Yahoogroups? That's obviously a non-starter. Or let's say that Aunt Gertrude's machine gets infected by=20 a worm, which starts sending out E-mails using Aunt=20 Gertrude's account at the ISP, via the ISP's mail server.=20 Are you going to block everything coming from that mail=20 server? What if it is a VERY large ISP? Obviously, it=20 would have been nice if that ISP's outgoing mail rules had=20 caught the messages, but in this case let's recognize that=20 they didn't. > If the source is =20 > emitting a sufficient volume of spam this happens before=20 >the initial probation period expires. Again, that's part of what I said about spammers=20 engineering their mails so they squeak under whatever=20 threshold is established to trigger spam alarms. That can=20 be done on content, sending rate, or any other=20 generally/widely used criteria. > DNS is probably a poor choice for distribution of the=20 >global fast =20 > response block advisories.=20 Obviously, since a change in status doesn't propagate=20 quickly enough. > I think a form of flood=20 >distribution =20 > through a mesh of peer nodes would be more robust. The=20 >distribution =20 > would feed local databases that could be queried=20 >directly or through =20 > a DNS front end. The mesh can handle data from multiple=20 >sources and =20 > needs no central authority. And how do you propose to prevent worms from targeting and=20 flooding or doing other Denial of Service attacks on that=20 mesh? > Proposal #4 is back reporting unsolicited email: >=20 > If email addressed to certain spamtraps is received from=20 >a sender =20 > that has registered to accept back reports,=20 Original sender? A forwarding sender? An aggregating=20 sender? How does the objecting MTA make sure? > accept the=20 >mail but =20 > return a specific code in the response that the sending=20 >MTA can =20 > interpret to make a determination if the sender is=20 >spamming. =20 > Alternatively, the site may register a different=20 >protocol to use for =20 > the back report. The spamtraps used for back reporting=20 >should be =20 > different from those reported to global blocklists to=20 >prevent =20 > disclosing the traps to rogue ISPs that would forward=20 >them to =20 > spammers. Only some of the traps would be used for back=20 >reporting to =20 > any given network or host. I'm not convinced that returning ANY "spamming!" status to=20 any imagined source is really worthwhile. To begin with,=20 I think that most such reports will be discarded or=20 archived, and just create additional worthless traffic on=20 the Net. Secondly, if the "back reporting" can be=20 misdirected (by counterfeiting E-mail or ISP addresses)=20 then the creative spammer can induce the bounce message=20 MTA to effectively be the "proxy" "sending source" of the=20 spam, tricking it into sending the bounce message to the=20 third party. (I used to get a fair amount of such=20 apparently-intentional bogus bounces... and indeed, I=20 still get a lot of antispam bounces into my "catch-all"=20 E-mail account at a vanity domain, generally resulting=20 from spammers who are counterfeiting randomly generated=20 "From" addresses supposedly within my domain). > Proposal #5 is a quarantine while a site is listed in a=20 >block advisory. >=20 > Established sources that get listed in local or global=20 >block =20 > advisories should have their mail quarantined while the=20 >mail is =20 > sorted out. The best place to quarantine the mail is on=20 >the sending =20 > server. It's already queued there and if it is=20 >eventually determined =20 > that it should be rejected,=20 And on what basis or set of rules do you propose that such=20 determination be made? I will suggest that (at least for=20 some non-obvious cases) that determination could be=20 difficult or even impossible to do accurately. Apart from (as previously noted) the problem of=20 determining after the fact with any real accuracy just who=20 the "sending server" actually is, particularly for=20 multi-hop mail deliveries. It's easy enough to forget=20 that not all E-mail deliveries are simple=20 user->ISP->ISP->user transfers. Vanity domains that provide mail forwarding are just one=20 example of a way that intermediaries enter into a mail=20 delivery chain. Aggregators/forwarders like Yahoogroups=20 are another. > that can be done with a 5xx=20 >on the next =20 > delivery attempt instead of sending a bounce.=20 And what if the next E-mail coming from that IP address is=20 legitimate, non-spam E-mail? > If the sending ISP is =20 > on their toes an offending user or host will be shut=20 >down quickly and =20 > the remaining mail will be delivered when the block=20 >advisory is =20 > lifted or expires.=20 And what happens to their legitimate outgoing mail in the=20 meantime? > Local whitelists can be used to allow=20 >mail to =20 > bypass the quarantine. That's fine, but (again) I believe that traditional,=20 simple "whitelists" are not nearly adequate. I believe=20 that a viable whitelist MUST comprise a recipient/sender=20 pair of addresses, AND additional criteria regarding what=20 the recipient expects to receive from the sender in=20 question. More to the point, once THAT is done, I believe that IP=20 address blocking becomes essentially superfluous (and=20 indeed, COUNTER productive). > -- Dan Oetting [comment #2] > Subject: HTML-burdened email (Re: [Asrg] Re: bounces,=20 >and anti-spam principles) > } I don't consider that ANYBODY has the right to blindly=20 > } haul off and presume that I'm willing to accept=20 > } HTML-burdened E-mails from them. >=20 > You're welcome to take that position, but it doesn't=20 >seem to fit with > the rest of your argument that what gets accepted should=20 >be controlled > on a per-user basis. =20 Yes, it does. Certainly a user COULD configure their default behavior to=20 allow HTML (perhaps a limited 'subset' of HTML) from=20 non-whitelisted senders. I wouldn't consider that=20 anything remotely like a "best practice", and one would=20 hope that the great majority of users would use the=20 recommended defaults if they wanted effective spam (and=20 virus/worm) blocking. Educating the users toward that end=20 would be to the ISP's advantage, obviously. > Elsewhere you wrote: >=20 > } Even 2% legitimate traffic is too much to block, if=20 >that=20 > } 2% is critically important stuff. >=20 > How is blocking legitmate email because it contains HTML=20 >less wrong > than blocking it based on point of origin? 1) You in the general case will have difficulty=20 determining the REAL "point of origin". Whether a message=20 contains HTML or not is far less subjective. 2) If the sender has not previously been in contact with=20 the recipient, they can not be sure that the recipient is=20 capable of handling HTML-burdened E-mail (they might have,=20 for example, a text-only E-mail client). Sending=20 HTML-burdened E-mail BEFORE establishing that the=20 recipient is willing and able to handle it violates every=20 "best practice" for that area. (I have gotten HTML-only=20 mail from senders with "clickable links" to say I want=20 plain-text mail.... which obviously is laughable for the=20 great majority of less-tech-savvy users). 3) Content-based antispam determination can be FAR more=20 efficient and FAR more accurate if all the various=20 HTML-based ruses are simply banned from the get-go. Users=20 who suddenly see a great reduction in spam, pfishing,=20 viruses and worms (and with the explanation of why) are=20 likely to quickly become believers. :-) > } It doesn't matter. You simply block (by default) ALL=20 > } images (whether embedded or attached) coming from=20 > } unfamiliar/first time senders. If they want to send=20 > } images, they first negotiate that permission with the=20 > } intended recipient. (And that permission, of course,=20 >can=20 > } be revoked by the recipient if the privilege is=20 >abused). >=20 > [...] >=20 > } There is NEVER the NEED to send=20 >HTML/attachments/scripting=20 > } to someone in an INTRODUCTORY E-mail. Not until=20 >you've=20 > } established that they are willing and able to receive=20 >that=20 > } kind of content from you. >=20 > This presumes a whole lot of effort on the part of the=20 >recipient in a > variety of circumstances. No. If the software is well-written, the effort required=20 by the recipient is relatively trivial. It could be as simple as NO effort, if (for example) the=20 introductory E-mail from a not-previously-seen sender is=20 NOT marked as spam by the recipient upon reading it (which=20 might enable, for example, a slightly more liberal=20 filtering on subsequent mail from that same sender).=20 Again, that's a detail of the implementation of the=20 client software, where presumably clever programmers can=20 do good things. :-) > (1) I'm shopping at a major retailer's website and=20 >decide to sign up > for their newsletter. What happens if the confirmation=20 >message uses > HTML content (not uncommon)? =20 Obviously, it SHOULD NOT use HTML content, for the simple=20 reason that said retailer CAN NOT be certain that the=20 person asking to be on their newsletter list is able to=20 handle (or WANTS to receive) HTML-burdened mail messages. The first such "welcome to our mailing list" message ought=20 to be sent in plain text, asking for permission to send=20 HTML (or, perhaps better, at the time the user requests to=20 be placed on the mailing list, they should be able to=20 specify HTML or plain text, and with the explicit mention=20 that if the HTML option is chosen, they might need to=20 enable that option from the sender in question). > But let's presume everyone=20 >has bought > into your scheme, so a plain text confirmation arrives.=20 > I now have > to take the additional step of confirming (where? has my=20 >email client > but updated to include an interface for this?)=20 Ideally, yes, the client software ought to include=20 awareness of and support for this capability. I've been=20 trying to talk Microsoft into adding such a capability=20 into both Outlook and Outlook Express, for example. (Who=20 knows whether I've caught the ear of anybody worthwhile=20 with the concept yet, or not). > that I'll=20 >accept HTML > from the same source in the future. =20 Hopefully that's capable. One approach would be for such=20 an "aware" client to pop up a box with a "this is the=20 first time you've gotten E-mail from this sender, what do=20 you want to do with mail from them in the future?" dialog=20 box. There could be a variety of options (discard,=20 forward, redirect, archive, I'll decide later/ask me again=20 for future nonconforming mail from this sender, whatever).=20 There could be different choices for "conforming" versus=20 "nonconforming" messages, perhaps. I don't think we have=20 to design the user interface to that level HERE, in any=20 case. > Assuming that the confirmation > and the newsletter come from the same source, that is,=20 >which also is > not always the case. True, although if that is recognized as important to=20 legitimate mailers, they can certainly correct such=20 questionable behavior. > (2) I'm working with an HTML design firm. They're doing=20 >a rush job > for me, which has to be confirmed on Saturday so it can=20 >be turned over > to my IT staff to be installed on the company website=20 >before Monday > morning; but I'm going to be out of town, so I want a=20 >copy of the work > sent to another address such as a freemail service so I=20 >can easily > review it. =20 1) You can certainly simply have them post their work to=20 a Web site (theirs?) and send you an e-mail with the URL. 2) If you're working with an HTML design firm, obviously=20 you can whitemail their E-mail address to send you HTML. > The HTML contains images and scripts, but=20 >the design firm > has never sent mail to that freemail service before, and=20 >I don't know > which of their team of designers might be sending the=20 >final product. Either ask, or have them post the page to a (private) Web=20 site where you can go and review it. Even if you don't know which specific designer might be=20 sending you the message, nothing in my proposal would=20 prevent (for example) the capability of the software=20 allowing you to whitelist by domain, regardless of what=20 user there sent the mail (you might have a different=20 "catch-all" default permissions list than the per-user=20 permissions list). > How much effort must I go to up front to be able to tell=20 >them they can > send me an attachment that I know will reach me? Again, I don't see a problem here. > (3) My biggest customer is a giant corporation which=20 >requires its > employees to use Microsoft Outlook and to attach a=20 >vCard-like signature > to every email, using a background stationery and having=20 >an image of > the company's latest logo because they're engaged in a=20 >major rebranding > initiative. Not surprisingly, they have massive=20 >turnover, so the > people there who send email to a variety of people at my=20 >company > changes every several weeks. Who's responsible for=20 >upkeep of all of > those individual agreements to exhange HTML with each=20 >other? Again, the recipient could presumably set up a "catch-all"=20 whitelisting which would enable selected E-mail HTML=20 features and selected attachment types from any user at a=20 given company's domain. For example, allow (hell, even=20 REQUIRE) V-card attachments or JPGs for mail from that=20 domain, but (for example) not allowing scripting,=20 executable attachments, or ActiveX. [comment #3] > Subject: Re: [Asrg] Re: bounces, and anti-spam=20 >principles >>> Our overall system is designed towards _zero_ false=20 >>>positives. In at >>> least one way, we're theoretically (and near=20 >>>effectively) there. With >>> DNSBLs and other techniques. >>=20 >> Obviously, I'd have to reserve judgement until I've=20 >>experienced your >> "zero false positives" idea. Let's just say that I've=20 >>got a healthy >> degree of skepticism. >=20 > I have 10+ years worth of exposure to this model (I=20 >built the thing) > with a user population of 60-120K and extreme FP=20 >aversion all the way up > to the CEO, you're welcome to come visit and I'll=20 >demonstrate it for you. >=20 > It only fails to be "zero false positive" when the=20 >legitimate sender > fails to read/follow the rejection notice. Which=20 >happens a lot more > than I'd like, but if the message isn't worth that much=20 >to the sender, > it's probably not worth doing much about it on our end=20 >either. 1) How do you determine who the actual "legitimate=20 sender" is? 2) How do you make sure they receive it? >>> Not everyone has that small a set of correspondents to=20 >>>cope with, and >>> the "new correspondent" issue remains a big problem. >>=20 >> The total set of correspondents doesn't have to be=20 >>small. It just needs >> to have a relatively small number of NEW correspondents=20 >>that NEED to use >> "advanced"/riskier features and therefore require=20 >>whitelisting. >=20 > The question is how do you even know of the new=20 >correspondents, when > you're being bombarded with dozens or hundreds of new=20 >correspondents per > day. To begin with, conforming E-mails from new correspondents=20 (no HTML, no attachments, size within limits, and passed=20 by SpamAssassin or similar) will sail right through. No=20 problem. Presumably each recipient could configure the "what to do=20 with nonconforming e-amils from unknown senders" option as=20 the user wished. Discard mercilessly, allow me to look at=20 the text part, or whatever. > It's all well and good, if the spammers aren't forging=20 >names, to allow > them one bite before you null the sender, but today's=20 >reality isn't like > that. The "one bite" on sender, or even on url or=20 >content, essentially > means you have to eat almost all spam. Because spammers=20 >mutate their > content and senders that much. =20 Absolutely. They generate random From; addresses and=20 random Subject: information (and random other stuff too,=20 like Received: lines indicating bogus original senders).=20 But of course, we here all ought to know that full well. That's why my personal recommendation for "best practice"=20 is to simply block -all- HTML messages from unfamiliar=20 senders, on the idea that they are trying to conceal=20 something, or at the very least are being inconsiderate=20 and clueless enough that I don't want to hear from them. Others might well choose diffeently, of course. > We're tracking spammers=20 >who use in > excess of 1000 different domains in urls. Can per-user=20 >techniques cope > via whitelisting or blacklisting? Not a chance. That's what makes blacklisting not work... there are=20 infinitely many E-mail addresses you need to blacklist. A fine-grained whitelist (and one which allows mail from=20 reasonable but non-whitelisted users) DOES offer a finite=20 task, that can be relatively easily handled. > The only way your techniques can work effectively is if=20 >you assume that > the recipient is getting very little spam. =20 I don't think it's particularly volume-sensitive... other=20 than the fact, of course, that ANY system could=20 conceivably be flooded by a sufficiently determined DoS=20 attack. > Well, 50% of our users are > being sent almost no spam. =20 Your users are very fortunate. Perhaps they haven't had=20 those E-mail addresses for very long, or don't do much=20 with them. > But that doesn't help with=20 >the guy getting > sent 4000/day. Or even the hundreds getting 50 or more. I don't see why my approach won't handle such cases with=20 ease. > The only way your technique works is if you're one user=20 >with a limited > variety and volume of spam. But not everybody is in the=20 >same situation > as you. Again, I don't agree with your conclusion. My proposed=20 default rule and fine-grained whitelisting (combined with=20 SpamAssassin or similar content scanning on the remainder)=20 with have a VERY high efficacy at detecting and dealing=20 with spam. >> Ideally, each such correspondent only requires ONE click=20 >>(one time) for >> the user to agree to allowing them to use the more=20 >>advanced features.=20 >> That might be done following an initial negotiation=20 >>E-mail where the >> sender introduces themself and requests the ability to=20 >>send more >> elaborate mails. >=20 > You seem to be focussing on only blocking "advanced=20 >features". A large > percentage of spammers don't use them anyway. If all=20 >your spam consists > of mutating text-only spam with mutating headers, your=20 >technique has no > effect. That's true, if the SpamAssassin component is unable to=20 make a reasonable determination. On the other hand, mail=20 that has passed the initial fine-grained-whitelist=20 criteria is at least going to be devoid of most of the=20 tricks which make things VERY problematical for the=20 content scanners. Some users COULD choose to ONLY allow E-mail from the=20 whitelisted E-mail addresses, if they decide that is the=20 approach that makes them happiest. (e.g. set the "default=20 maximum size accepted" to zero bytes). >> Introductory E-mails should NOT automatically presume=20 >>the desire or >> willingness of the recipient to receive HTML-burdened=20 >>E-mails. >=20 > But if all spam were indistinguishable from=20 >"introductory e-mails", > where are you then? No worse than at present. And BETTER, since the "no attachment, no HTML" default=20 rule would seriously cripple zombie spambot army=20 recruitment. > And indeed, probably most spam isn't distinguishable=20 >from some vague > notion of "introductory e-mails" by your technique. That at least switches the problem to a relatively simpler=20 problem of improving the antispam content-based=20 detection... i.e. making a better version of SpamAssassin. At least the future SpamAssassin is relieved of nearly all=20 of the nearly impossible cases it is forced to (not?) deal=20 with today. >> The main problem with content filtering is caused by=20 >>ruses based on HTML >> and attachments. These techniques serve to obscure the=20 >>content of the >> E-mail, and ALL BY THEMSELVES the presence of such=20 >>content in E-mails >> (at least in E-mails from unfamiliar senders) can be a=20 >>priori evidence >> of hostile intent, or spamming. >=20 > If you can _detect_ those ruses. =20 Of course. Some of my filtering code I've written, for=20 example, looks for things like "obscured" URLs, or=20 obfuscated IP addresses in URLs. > You and I may be able=20 >to detect it in > on a per-message basis with visual inspection, but=20 >computers generally > can't, say, identify sentences generated using random=20 >words. Try > building a filter for hipcrime some day... Plain text.=20 > Random headers. > No "advanced features". Good luck. You're also faced with things like foreign language=20 E-mails (Chinese, for example). Even using grammar tests,=20 E-mails might have a large amount of bogus=20 respectable-looking content (say, ten jokes followed by=20 the 'payload' spam). Again, at some point you're going to=20 see some spam slide through. I believe my approach would=20 take a BIG bite out of it, though. > Much of the recent evolution in spam content techniques=20 >has been to get > away from ruses that are detectable as ruses. It used=20 >to be a common > technique to insert random invalid html tags in spam.=20 > Defeatable by > simply looking for invalid html tags or meta (eg:=20 >tag)/content ratios. > But they don't do that anymore, do they? =20 I don't know... since the filters I most recently wrote=20 T-canned all that stuff anyhow. But I don't doubt that=20 spammers will eventually mutate to try to avoid schemes=20 that don't work anymore. One of my goals is to HUGELY increase that set. :-) > And=20 >meta/content ratios can be > _extremely_ high in legitimate email (just look at the=20 >gunk that outlook > produces for simple emails some day). Are you talking about HTML? > Look for identical gifs? Well, they stopped emitting=20 >identical gifs > months ago. I'd block ALL mail containing GIFs (or any other kind of=20 attachment) by default, from unknown senders. Such tricks=20 hit a solid brick, impenetrable wall. > I had some luck with looking for gif geometry (scan for=20 >gif prefixes > containing identical image dimensions). That stopped=20 >working too. Yeah, I don't think such schemes have much potential. >>>> Again, when you have a LOT of users (and possibly MANY=20 >>>>servers) behind a >>>> NAT router, denying mail from that IP address results in=20 >>>>simply too much >>>> collateral damage. More to the point, it's a very blunt=20 >>>>instrument for >>>> the job, and it's relatively simple to do very much=20 >>>>better. >>> >>> So far, there's no indication of the latter being true.=20 >>=20 >> I do note you don't refute my objection on principle.=20 >> :-) >=20 > But in fact, I do. >=20 > Let's cut to the chase. Your argument about source IP=20 >blocking being a > blunt instrument is well-taken and true. It _is_ a=20 >blunt instrument. >=20 > So's a sledgehammer. You wouldn't use a sledgehammer to=20 >install window > trim would you? But a carpenter probably still has and=20 >uses a > sledgehammer for a different part of the same job of=20 >building a house. >=20 > Your argument assumes that IP-blocking is the ONLY=20 >technique being used > - - if all you have is IP-blocking, trying to=20 >discriminate between good > and bad content from a given IP (say an ISPs MTA)=20 >doesn't work. >=20 > Well, yeah, duh ;-) >=20 > Your argument assumes that the administrator hasn't made=20 >any effort to > make an intelligent choice on which DNSBL to use - and=20 >is hence at the > mercy of capricious listings of any old random IP. >=20 > Well, yeah, if you've chosen to use BLARS, you get what=20 >you deserve. >=20 > Yup both true. But so what? >=20 > What's to prevent you from doing the intelligent thing=20 >and using > multiple complementing techniques simultaneously?=20 Nothing at all, and in fact that's what I'm proposing. I just happen to believe that IP address reputation is=20 neither necessary nor sufficient (and perhaps not even=20 particularly desirable) as a component in that. > The XBL, for example, is _extremely_ reliable at=20 >detecting compromised > end-user machines. All by itself it will block 70-85%=20 >of all spam. =20 Fine. But it also blocks LEGITIMATE mail coming from=20 those machines, right? > By it's very nature it doesn't list real MTAs (eg: ISP=20 >smarthosts). =20 What if the spam is sent through ths "smarthost"? You=20 might claim that's not being done today, but nothing=20 prevents spammers from doing that. > It has > a false positive rate lower than virtually any content=20 >filter. > Certainly _way_ lower than any notion of trying to block=20 >spam based on > detecting "advanced features". Fine, if you're a believer in IP address filtering, then=20 use that as a component. But I still believe that it's=20 not as good as a better differentiation technique, with=20 less collateral damage. =20 > Why not let the users choose? How many of your users=20 >know what the XBL > is? About 5 of mine _might_. I'm not even sure you do.=20 > How many of > them have spent the manhours needing to learn what knobs=20 >do a good job? I think the nature of 'knobs' given to end users will OF=20 COURSE be different than the type of 'knobs' given to=20 IETF-types. > Less than that. How many of them would do nearly as a=20 >good job at it? Few, IF they were adjusting IETF-type knobs. That's NOT=20 what I'm proposing. > Even I, with over 10 years of experience in this game,=20 >could not do an > acceptable job on email landing in my _own_ mailbox=20 >using your > techniques. =20 I guess a lot depends on what you consider "acceptable",=20 and how good the content scanner is that you have. [comment #4] > Subject: Re: [Asrg] Re: bounces, and anti-spam=20 >principles >> [how users configure their whitelist rules] >>=20 >> >The problem being that out of the 60,000 seats here,=20 >>perhaps less >> >than 10 of them are able to competently configure a set=20 >>of rules like >> >what you have. =20 >>=20 >> That's a software implementation issue, not an inherent=20 >> problem in the approach. I envision a button to click=20 >>on=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I guess that's the main reason why your ideas aren't met=20 >with wild > enthusiasm here. You "envision" that this would be=20 >simple to build and > to use, but it's not even clear that you have even built=20 >a prototype > which you use yourself, much less deployed the system=20 >for "ordinary > users", which aren't quite sure what an "HTML mail" is,=20 >and have never > heard about an "ActiveX component". I've built and have used portions of what I propose.=20 Obviously it will work best if the proposed default rules=20 are widely used. As for "deploying it for ordinary users", I think I could=20 make the same claim regarding all these DNS-based=20 proposals that y'all are so fixated on. Again, good=20 software implementation doesn't have to depend on users=20 understanding those details (but it COULD offer that level=20 of detail, for advanced users who cared). Since I don't=20 work at an ISP, and I'm not being paid to do this stuff,=20 what I build and use myself is more a function of what the=20 effort/payback looks like for ME as an individual user. I don't think where things fall on that particular=20 equation are especially relevant to whether the approach=20 would be a good one for more widespread adoption. :-) >> that simply says "allow E-mails like this from the same=20 >> sender in the future" and where the software will open=20 >>the=20 >> keyway JUST enough to allow that type of message if seen=20 >> again from that sender. >=20 > So Uncle Bob will see that a mail from Aunt Matilda was=20 >blocked because > it contained an "executable attachment". Since he wants=20 >to get mail from > Aunt Matilda (and Aunt Matilda is a nice lady, she=20 >wouldn't send him > anything bad, would she?) he clicks on "allow E-mails=20 >like this from the > same sender in the future". Oops! Presumably he could tell from the rest of the content in=20 the mail message that it really didn't look like E-mail=20 from Aunt Matilda. And clicking on the option could be=20 followed by a suitably dire dialog box, explaining the=20 risks of executable attachments and asking if he is REALLY=20 REALLY sure that the mail in question is REALLY from who=20 it claims to be. It could even suggest that the user call=20 the sender on the phone to verify the legitimacy of the=20 E-mail message, if they are not 100% sure. And, presumably if he later found that his faith was=20 misguided, he ought to be able to later revoke that=20 permission...! >> How that recognition is accomplished, whether by=20 >>something crude like >> simple GREP-type scanning, or something brain-damaged=20 >>like RegEx >> pattern matching, >=20 > You know what the two middle characters in "grep" stand=20 >for, do you? Regular expressions. Which can be used in more elaborate ways than a simple=20 pass with something like GREP normally allows, thus the=20 distinction I tried to (ineffectively, it seems) make. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 02:58:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4td-0002vu-1y; Sun, 28 Jan 2007 02:56:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB4tb-0002vV-II for asrg@ietf.org; Sun, 28 Jan 2007 02:56:15 -0500 Received: from mpls-qmqp-05.inet.qwest.net ([63.231.195.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB4tb-0004oG-0g for asrg@ietf.org; Sun, 28 Jan 2007 02:56:15 -0500 Received: from mpls-pop-15.inet.qwest.net (mpls-pop-15.inet.qwest.net [63.231.195.15]) by mpls-qmqp-05.inet.qwest.net (Postfix) with QMQP id BE3B962D40D for ; Sun, 28 Jan 2007 07:56:14 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-15.inet.qwest.net with SMTP; 28 Jan 2007 07:56:14 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <426040D7-38E8-46E4-8FB0-C338CF1003CA@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] Quarantines and block lists Date: Sun, 28 Jan 2007 00:56:12 -0700 To: Anti Spam Research Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 27, 2007, at 6:43 PM, gep2@terabites.com wrote: >> Here is my proposal. I'm sure I haven't thought of everything so >> please tell me where it breaks or how spammers are going to game >> it. The goal is to stop the majority of the spam while not >> loosing ANY legitimate email (broken MTAs don't count). > > To begin with, crude IP blocks will ALWAYS lose legitimate mail, > because a single IP address can send both legitimate and zombie- > generated mail. I propose that NO ISP-based software will be > capable of differentiating one from the other... but the recipient > possibly will know how to do that, at least for familiar senders. I guess I didn't think to include a definition for "Lost Email". Lost Email is any email that is sent but not presented to the user and does not generate a DSN to the sender. When referring to a receiving system loosing email it is assumed that the sending system is following standard procedures. >> This is not intended to replace existing blocklists but to handle >> the initial onslaught from a spam source until the source can be >> properly categorized and listed. >> Proposal #1 is a quarantine for new sources: >> Connections from unknown source addresses would be initially >> rejected by returning a temporary error code (4xx) for a >> probation period. The probation period could be as short as 5 >> minutes depending on how fast the blocklists can respond. The >> reject would occur after the recipient list is accepted so the >> recipients can be checked against local spamtraps and valid user >> lists. After the probation period, global blocklists would be >> queried to find the current reputation of the source. > > While spamtraps and valid user lists are helpful sometimes, they > will not trigger if the spammer is using "fresh" E-mail address > lists which are also devoid of spamtrap E-mail addresses. Is there evidence that spammers have 100% spamtrap free lists? Where are they getting their addresses from and why can't we seed spamtrap addresses there? It cost almost nothing to try different forms of spamtrap seeding. I'd like to open this part up to all the armchair anti-spammers with a distributed process. The trap submissions could be scored on the basis of their verified spam counts and derated for getting non-spam. >> Proposals #2 & #3 are for a fast global block advisory and >> distribution network >> Any email addressed to a spamtrap would generate a report to a >> local trap handler. The local trap handler would forward >> appropriate reports to the regional or global blocklist managers. >> The blocklist managers would publish advisories based on the >> reputations and counts of the traps that were hit by the sending IP. > > IP address blocking, again, is simply too crude. A further and > more serious problem is that you have basically no way to be 100% > sure of who the "sending IP" actually is. > > For just one example, Yahoogroups That's obviously a non-starter. Yahoogroups is a subscription based service. A valid spamtrap would not be subscribed to any group (unless it was designed to catch spammers harvisting group addresses in which case it would take special precautions to exclude group related emails from the spamtrap reports). > > Or let's say that Aunt Gertrude's machine gets infected by a worm, > which starts sending out E-mails using Aunt Gertrude's account at > the ISP, via the ISP's mail server. Are you going to block > everything coming from that mail server? What if it is a VERY > large ISP? Obviously, it would have been nice if that ISP's > outgoing mail rules had caught the messages, but in this case let's > recognize that they didn't. Spam has to be stopped somewhere. But read the full set of proposals... If a site has never received email from that IP before it would quarantine the first emails from that IP as in proposal #1. The automatic spamtrap network would generate an advisory that the IP is sending UBE. Then depending on the reputation of that IP from all sources the site would choose to a: continue the quarantine, b: accept the email and possibly apply additional filtering or c: reject the email from that IP. >> If the source is emitting a sufficient volume of spam this >> happens before the initial probation period expires. > > Again, that's part of what I said about spammers engineering their > mails so they squeak under whatever threshold is established to > trigger spam alarms. That can be done on content, sending rate, or > any other generally/widely used criteria. So I've forced the spammer to send less spam. This I call progress. >> DNS is probably a poor choice for distribution of the global fast >> response block advisories. > > Obviously, since a change in status doesn't propagate quickly enough. > >> I think a form of flood distribution through a mesh of peer nodes >> would be more robust. The distribution would feed local databases >> that could be queried directly or through a DNS front end. The >> mesh can handle data from multiple sources and needs no central >> authority. > > And how do you propose to prevent worms from targeting and flooding > or doing other Denial of Service attacks on that mesh? What port and IP address is the worm going to target? You won't know unless you've talked with the admin of that node and even then you might have a private port that only you know about. And even if you do manage to take out one node (or a dozen) the mesh survives and routes around the damage. The affected nodes re-negotiate the links with their peers and are back on line in short order. >> Proposal #4 is back reporting unsolicited email: >> If email addressed to certain spamtraps is received from a sender >> that has registered to accept back reports, > > Original sender? A forwarding sender? An aggregating sender? How > does the objecting MTA make sure? That should be "sending MTA". Although an ISP might register an alternate protocol to report suspect email for an entire net block. The registration is primarily to prevent sending reports directly to a spambot. >> accept the mail but return a specific code in the response that >> the sending MTA can interpret to make a determination if the >> sender is spamming. Alternatively, the site may register a >> different protocol to use for the back report. The spamtraps used >> for back reporting should be different from those reported to >> global blocklists to prevent disclosing the traps to rogue ISPs >> that would forward them to spammers. Only some of the traps would >> be used for back reporting to any given network or host. > > I'm not convinced that returning ANY "spamming!" status to any > imagined source is really worthwhile. To begin with, I think that > most such reports will be discarded or archived, and just create > additional worthless traffic on the Net. Secondly, if the "back > reporting" can be misdirected (by counterfeiting E-mail or ISP > addresses) then the creative spammer can induce the bounce message > MTA to effectively be the "proxy" "sending source" of the spam, > tricking it into sending the bounce message to the third party. (I > used to get a fair amount of such apparently-intentional bogus > bounces... and indeed, I still get a lot of antispam bounces into > my "catch-all" E-mail account at a vanity domain, generally > resulting from spammers who are counterfeiting randomly generated > "From" addresses supposedly within my domain). 1. Read in this proposal where I said "registered". 2. Do you know what a response code in SMTP is? 3. I never "bounce" anything. >> Proposal #5 is a quarantine while a site is listed in a block >> advisory. >> Established sources that get listed in local or global block >> advisories should have their mail quarantined while the mail is >> sorted out. The best place to quarantine the mail is on the >> sending server. It's already queued there and if it is eventually >> determined that it should be rejected, > > And on what basis or set of rules do you propose that such > determination be made? I will suggest that (at least for some non- > obvious cases) that determination could be difficult or even > impossible to do accurately. The determination to quarantine email while waiting for additional information to become available or the possibility that the sending site will clean up the spam first should be easy to make. Are you perhaps referring to the rules for implementing proposal #2? > Apart from (as previously noted) the problem of determining after > the fact with any real accuracy just who the "sending server" > actually is, particularly for multi-hop mail deliveries. It's > easy enough to forget that not all E-mail deliveries are simple > user->ISP->ISP->user transfers. First you have the intranet delivery on the sending side user-> (users ISP internal servers) -> Sending MTA Then you have the internet delivery Sending MTA ----> Receiving MTA or Sending MTA ----> (open relay) ---> Receiving MTA And finally the intranet delivery on the receiving side Receiving MTA -> (receiving ISP internal servers) -> destination I am only concerned with the internet delivery. Anything else the ISPs can handle on their own. So all internet email deliveries are simple ISP->ISP transactions. > Vanity domains that provide mail forwarding are just one example of > a way that intermediaries enter into a mail delivery chain. > Aggregators/forwarders like Yahoogroups are another. If the vanity domain allows you to create hundreds or thousands of forwarders to addresses you don't own to make it look like a spammer site it deserves to be blocked. >> that can be done with a 5xx on the next delivery attempt instead >> of sending a bounce. > > And what if the next E-mail coming from that IP address is > legitimate, non-spam E-mail? If the decision is to reject all mail coming from that IP then returning the 5xx response will cause the sending MTA to generate a DSN that will be returned to the legitimate sender. >> If the sending ISP is on their toes an offending user or host >> will be shut down quickly and the remaining mail will be >> delivered when the block advisory is lifted or expires. > > And what happens to their legitimate outgoing mail in the meantime? It sits in the quarantine until the block advisory is lifted and then gets delivered normally. Nothing is lost except for some sleep by the admin on duty for the sending ISP. >> Local whitelists can be used to allow mail to bypass the quarantine. > > That's fine, but (again) I believe that traditional, simple > "whitelists" are not nearly adequate. I believe that a viable > whitelist MUST comprise a recipient/sender pair of addresses, AND > additional criteria regarding what the recipient expects to receive > from the sender in question. > > More to the point, once THAT is done, I believe that IP address > blocking becomes essentially superfluous (and indeed, COUNTER > productive). None of my proposals say "block" anything. I say issue advisories in proposal #2, some users might want that information. I propose quarantining email when it's looking suspicious. The sending ISP knows where the email came from which is something that the receiver cannot know in all cases. If anybody is going to decide that email is spam it is the sending ISP that has the best information to make that decision. Proposal #4 provides the one key piece that the sending ISP doesn't have to determine that their user is sending UBE (aka spam). If you as an ISP are offered these free tools to help control spam emanating from your network are you going to say "no thanks, we'll just send the spam and let everybody else clean it up"? -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 06:36:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8Hl-0007vN-PM; Sun, 28 Jan 2007 06:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8Hk-0007vI-6u for asrg@ietf.org; Sun, 28 Jan 2007 06:33:24 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB8Hg-0006w0-SQ for asrg@ietf.org; Sun, 28 Jan 2007 06:33:24 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 951F74039; Sun, 28 Jan 2007 12:33:19 +0100 (CET) Date: Sun, 28 Jan 2007 12:33:19 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Quarantines and block lists Message-ID: <20070128113319.GA18862@hjp.at> Mail-Followup-To: asrg@ietf.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0025067408==" Errors-To: asrg-bounces@ietf.org --===============0025067408== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-27 19:43:23 -0600, gep2@terabites.com wrote: > To begin with, crude IP blocks will ALWAYS lose legitimate=20 > mail, because a single IP address can send both legitimate=20 > and zombie-generated mail. We've been using the spamhaus dnsbls for several years and I can't remember a single false positive. IP adresses which send legitimate mails are simply not listed there (or if they are, there are so few of them that it's indetectable).=20 It is true that they aren't sufficient, but they reduce spam by quite a bit (they're by far the most frequent reason for a permanent error) with practically zero false positives. I don't know why you insist that they would have to list a single IP address which sends both legitimate and zombie-generated mail. Just look at spamhaus and you can see that this is false. --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFvIn/fZ+RkG8quy0RAn7OAJ4wcEYHcETojLcMxUm0zA0zeHI/2QCdGAFf DCQ5vyDS7+Af4JwXsEn4MeA= =55w8 -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- --===============0025067408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0025067408==-- From asrg-bounces@ietf.org Sun Jan 28 07:08:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8oY-0007Hl-95; Sun, 28 Jan 2007 07:07:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8oX-0007HY-Ht for asrg@ietf.org; Sun, 28 Jan 2007 07:07:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB8oQ-0003gj-7d for asrg@ietf.org; Sun, 28 Jan 2007 07:07:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HB8o9-0006OO-Cq for asrg@ietf.org; Sun, 28 Jan 2007 13:06:53 +0100 Received: from du-042-097.access.de.clara.net ([213.221.65.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 13:06:53 +0100 Received: from nobody by du-042-097.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 13:06:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Jan 2007 13:04:32 +0100 Organization: Lines: 26 Message-ID: <45BC9150.76E0@xyzzy.claranet.de> References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-097.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Claus Assmann wrote: > [[Is this the appropriate list to discuss this topic?]] I expected the SMTP list to be flooded with 2821bis WG charter debates, but in reality nothing happens. > the name is confusing and the new name isn't very helpful either. > Let's call it something like "Delayed-RCPT-Status" (DRS) or > "RCPT-Status-After-Dot" (RSAD). Maybe the complete technique could be simplified: After the server offers "TBD" the client can accept it as "TBD" keyword of MAIL FROM. Then it sends the DATA first, afterwards it sends RCPT TO and gets selective (per mailbox) responses as usual, taking the known DATA into account. The mail is selectively accepted with a 2xx for an RCPT TO. Any command that's not RCPT TO (like MAIL FROM or QUIT) terminates the transmission of this mail. Could "DATA-first mail" (DF) work ? Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 08:53:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBAQu-0004Jj-Gw; Sun, 28 Jan 2007 08:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBAQt-0004Jd-24 for asrg@ietf.org; Sun, 28 Jan 2007 08:50:59 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBAQr-0005FR-8o for asrg@ietf.org; Sun, 28 Jan 2007 08:50:59 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 463894039; Sun, 28 Jan 2007 14:50:56 +0100 (CET) Date: Sun, 28 Jan 2007 14:50:56 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Message-ID: <20070128135056.GB18862@hjp.at> Mail-Followup-To: asrg@ietf.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Subject: [Asrg] Re: HTML-burdened email X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0048152862==" Errors-To: asrg-bounces@ietf.org --===============0048152862== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-27 19:43:23 -0600, gep2@terabites.com wrote: > >Subject: HTML-burdened email (Re: [Asrg] Re: bounces,=20 > >and anti-spam principles) Please don't answer mails from different people in different subthreads in the same mail. Your mails are already too long, and an argument is hard to follow if the answer the content of one mail is in the answer to a different mail. > >(1) I'm shopping at a major retailer's website and decide to sign up > >for their newsletter. What happens if the confirmation message uses > >HTML content (not uncommon)? =20 >=20 > Obviously, it SHOULD NOT use HTML content, But it does. And if you're a small ISP or IT department and your users can't get their newsletter, guess who they'll blame? You or the major retailer? And what's more likely to change? The way you filter mail or the way the major retailer sends their newsletter? You can do that if you're the DoD. The DoD recently banned HTML and they can get away with it, because almost everyone they exchange mail with is more interested in talking to the DoD than the DoD is talking to them. If the DoD doesn't get your mails, that's your problem, not theirs. > for the simple reason that said retailer CAN NOT be certain that the > person asking to be on their newsletter list is able to handle (or > WANTS to receive) HTML-burdened mail messages. He doesn't care. 99% of his prospective customers can handle it, and they will be enticed by the pretty pictures. He can afford to lose 1% (who are probably the more critical customers anyway). > >Assuming that the confirmation and the newsletter come from the same > >source, that is, which also is not always the case. >=20 > True, although if that is recognized as important to=20 > legitimate mailers, they can certainly correct such=20 > questionable behavior. That "questionable behaviour" is pretty much standard, and there are good reasons for it. > >(3) My biggest customer is a giant corporation which requires its > >employees to use Microsoft Outlook and to attach a vCard-like > >signature to every email, using a background stationery and having an > >image of the company's latest logo because they're engaged in a major > >rebranding initiative. Not surprisingly, they have massive turnover, > >so the people there who send email to a variety of people at my > >company changes every several weeks. Who's responsible for upkeep of > >all of those individual agreements to exhange HTML with each other? >=20 > Again, the recipient could presumably set up a "catch-all"=20 > whitelisting which would enable selected E-mail HTML=20 > features and selected attachment types from any user at a=20 > given company's domain. For example, allow (hell, even=20 > REQUIRE) V-card attachments or JPGs for mail from that=20 > domain, but (for example) not allowing scripting,=20 > executable attachments, or ActiveX. Yes, he could. But he doesn't want to. It's not his job to worry about which types of content a certain user (which he not even know) might send to him in the future. > >The only way your techniques can work effectively is if=20 > >you assume that > >the recipient is getting very little spam. =20 >=20 > I don't think it's particularly volume-sensitive... other=20 > than the fact, of course, that ANY system could=20 > conceivably be flooded by a sufficiently determined DoS=20 > attack. It's a DoS attack on the user, not on the system. The user has to look at the mails, decide whether they are legitimate, which of their features he wants to accept from that sender (and whether "that sender" means only that particular address, or the whole domain or something in between). > >Well, 50% of our users are being sent almost no spam. =20 >=20 > Your users are very fortunate. Nope. That's the normal distribution. Many users get almost no spam, many get a an intermediate amount of spam and a few literally drown in spam. > Perhaps they haven't had those E-mail addresses for very long, or > don't do much with them. >=20 > >But that doesn't help with the guy getting sent 4000/day. Or even > >the hundreds getting 50 or more. >=20 > I don't see why my approach won't handle such cases with=20 > ease. That guy has to scan through 4000 messages each day to check if there wasn't one which he did want. Maybe not every day, but at least every time he suspects that a mail might have been blocked. > >>Introductory E-mails should NOT automatically presume the desire or > >>willingness of the recipient to receive HTML-burdened E-mails. > > > >But if all spam were indistinguishable from=20 > >"introductory e-mails", > >where are you then? >=20 > No worse than at present. Depends on what you define as "better" and "worse". You will get less spam (about 50% less, I would guess from looking through my spambox), but you will also get less legitimate mail (I don't know how common HTML mail is on average - that seems to vary a lot).=20 > And BETTER, since the "no attachment, no HTML" default=20 > rule would seriously cripple zombie spambot army=20 > recruitment. Only if it is widely adopted. Which it won't be, because the early adopters will have to deal with severe problems. > >The XBL, for example, is _extremely_ reliable at=20 > >detecting compromised > >end-user machines. All by itself it will block 70-85%=20 > >of all spam. =20 >=20 > Fine. But it also blocks LEGITIMATE mail coming from=20 > those machines, right? There is no legitimate mail coming from those machines. Maybe a message or two for every million messages being blocked. Probably less. > >By it's very nature it doesn't list real MTAs (eg: ISP=20 > >smarthosts). =20 >=20 > What if the spam is sent through ths "smarthost"? You=20 > might claim that's not being done today, but nothing=20 > prevents spammers from doing that. Then there is an ISP to complain to and the ISP knows which of their users has a compromised machine and can do somthing about it. If the ISP doesn't do something about it, he may find that some may refuse to accept mail from him or apply more stringent filters to it. But that doesn't have anything to do with the XBL. You are assuming that IP-based reputation is used in an all-or-nothing way. It isn't. There is more than one list, and just because an IP address is or isn't on a specific list doesn't mean that all mails from this address are rejected or accepted. It is one criterion among many. > >Subject: Re: [Asrg] Re: bounces, and anti-spam=20 > >principles >=20 > >>[how users configure their whitelist rules] > >> > >>>The problem being that out of the 60,000 seats here, perhaps less > >>>than 10 of them are able to competently configure a set of rules > >>>like what you have. =20 > >> > >>That's a software implementation issue, not an inherent=20 > >>problem in the approach. I envision a button to click=20 > >>on=20 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I guess that's the main reason why your ideas aren't met with wild > >enthusiasm here. You "envision" that this would be simple to build > >and to use, but it's not even clear that you have even built a > >prototype which you use yourself, much less deployed the system for > >"ordinary users", which aren't quite sure what an "HTML mail" is, and > >have never heard about an "ActiveX component". >=20 > I've built and have used portions of what I propose.=20 > Obviously it will work best if the proposed default rules=20 > are widely used. >=20 > As for "deploying it for ordinary users", I think I could=20 > make the same claim regarding all these DNS-based=20 > proposals that y'all are so fixated on. No, absolutely not. Apart from not being fixated on "DNS-based proposals" (if anything, I'm fixated on bayesian filtering), I see two very important differences here:=20 1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals". They have been operational for years and their strengths and weaknesses are well-known. 2) The user has absolutely nothing to do with them. I can simply enable them on a system-wide basis and be confident that I will maybe have to deal with one complaint every few years.=20 > Again, good software implementation doesn't have to depend on users > understanding those details I doubt that. In real life users get mails with "advanced features" all the time and if they have to decide whether they can safely enable them they need to understand them. I predict that the average user will either have configured that system to accept anything from anybody within a week or give up on email entirely. > I don't think where things fall on that particular=20 > equation are especially relevant to whether the approach=20 > would be a good one for more widespread adoption. :-) It is irrelevant whether it "would be good". User's simply won't adopt it. Period. It will ask them questions they don't understand twenty times a day, so they will resort to either clicking "yes" all the time or "no" all the time. As a result they won't get the mail they want and they will still get mail they don't want. In addition they will feel dumb because they don't understand all those questions, and they will be angry at the computer (it should handle that stuff without asking stupid questions) and the IT staff or ISP (it's their job to handle that stuff). A week later the system will be shut off again and the poor guy who thought "it would be good" will be fired. > >>that simply says "allow E-mails like this from the same sender in > >>the future" and where the software will open the keyway JUST enough > >>to allow that type of message if seen again from that sender. > > > >So Uncle Bob will see that a mail from Aunt Matilda was blocked > >because it contained an "executable attachment". Since he wants to > >get mail from Aunt Matilda (and Aunt Matilda is a nice lady, she > >wouldn't send him anything bad, would she?) he clicks on "allow > >E-mails like this from the same sender in the future". Oops! >=20 > Presumably he could tell from the rest of the content in=20 > the mail message that it really didn't look like E-mail=20 > from Aunt Matilda. To do that he has to read it. What good is an anti-spam scheme which requires me to read all my spam? hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFvKpAfZ+RkG8quy0RAtG6AJ4tRexAtIecOdt7vDGvlNEL+FbPfACfRWBO JWbc+MfEiKf6MTSjlpFfCU0= =FGWa -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- --===============0048152862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0048152862==-- From asrg-bounces@ietf.org Sun Jan 28 09:01:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBAb3-000153-Qe; Sun, 28 Jan 2007 09:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBAb2-00013v-Mk for asrg@ietf.org; Sun, 28 Jan 2007 09:01:28 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBAb1-00074L-8h for asrg@ietf.org; Sun, 28 Jan 2007 09:01:28 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 8ABAE4039; Sun, 28 Jan 2007 15:01:26 +0100 (CET) Date: Sun, 28 Jan 2007 15:01:26 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070128140126.GC18862@hjp.at> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> Mime-Version: 1.0 In-Reply-To: <45BC9150.76E0@xyzzy.claranet.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1998846070==" Errors-To: asrg-bounces@ietf.org --===============1998846070== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-28 13:04:32 +0100, Frank Ellermann wrote: > Claus Assmann wrote: >=20 > > [[Is this the appropriate list to discuss this topic?]] >=20 > I expected the SMTP list to be flooded with 2821bis WG charter > debates, but in reality nothing happens. >=20 > > the name is confusing and the new name isn't very helpful either. > > Let's call it something like "Delayed-RCPT-Status" (DRS) or > > "RCPT-Status-After-Dot" (RSAD). >=20 > Maybe the complete technique could be simplified: >=20 > After the server offers "TBD" the client can accept it as "TBD" > keyword of MAIL FROM. Then it sends the DATA first, afterwards > it sends RCPT TO and gets selective (per mailbox) responses as > usual, taking the known DATA into account. That's basically David Nicols' DATAFIRST proposal. > The mail is selectively accepted with a 2xx for an RCPT TO. Any > command that's not RCPT TO (like MAIL FROM or QUIT) terminates > the transmission of this mail. >=20 > Could "DATA-first mail" (DF) work ? It could but in reality quite a lot of mail is rejected before it even hits the DATA stage (either because none of the recipients exists or because of checks which don't need the content (DNSBL, greylisting, =2E..). With DATAFIRST all this mail will have to be transferred only to be rejected. I suspect that this will sharply increase the bandwidth requirements. (David proposed to offer DATAFIRST only to trusted senders, which limits its usefulness) hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFvKy2fZ+RkG8quy0RAu1LAJsFKeTgy0+4BDOLGwWjZ8s7VHdVnQCgqDzL BSjD2F316oPTzvK2Nj+fOfE= =af3q -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- --===============1998846070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1998846070==-- From asrg-bounces@ietf.org Sun Jan 28 15:29:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBGah-0001VR-EG; Sun, 28 Jan 2007 15:25:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBGaf-0001VI-K5 for asrg@ietf.org; Sun, 28 Jan 2007 15:25:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBGae-0002FF-A3 for asrg@ietf.org; Sun, 28 Jan 2007 15:25:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBGaP-0002aa-6W for asrg@ietf.org; Sun, 28 Jan 2007 21:25:13 +0100 Received: from du-017-218.access.de.clara.net ([212.82.246.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 21:25:13 +0100 Received: from nobody by du-017-218.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 21:25:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 28 Jan 2007 21:24:33 +0100 Organization: Lines: 34 Message-ID: <45BD0681.6EFC@xyzzy.claranet.de> References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-218.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Peter J. Holzer wrote: > David Nicols' DATAFIRST proposal. [...] >> Could "DATA-first mail" (DF) work ? > It could but in reality quite a lot of mail is rejected before > it even hits the DATA stage (either because none of the recipients > exists or because of checks which don't need the content (DNSBL, > greylisting, ...). Some of the checks (incl. DNSBL and SPF) are possible before RCPT, unless you intend to apply them selectively per receiver. If you want to get RCPT before DATA it's simple, just don't offer "DATAFIRST". A similar idea is Hector's HEAD proposal, splitting DATA into HEAD and BODY somehow, for folks interested to check the "header first" (roughly as with TOP in POP3). Maybe he gave up on it because it won't help with DKIM body hashes. > With DATAFIRST all this mail will have to be transferred only to > be rejected. I suspect that this will sharply increase the bandwidth > requirements. It should be visible in the log files of major site. If they check more than only the size between DATA and dot, otherwise they can't be interested to get "DATAFIRST" anyway. What I didn't like in draft-hall-inline-dsn was the sequence of per recipient responses after DATA matching the sequence of RCPT before DATA. It would be more plausible if it implies PIPELINING. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 17:08:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBIAO-0007NR-PB; Sun, 28 Jan 2007 17:06:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBIAN-0007NH-Nn for asrg@ietf.org; Sun, 28 Jan 2007 17:06:27 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBIAI-0000RZ-1B for asrg@ietf.org; Sun, 28 Jan 2007 17:06:27 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id A91F04039; Sun, 28 Jan 2007 23:06:10 +0100 (CET) Date: Sun, 28 Jan 2007 23:06:10 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070128220610.GE18862@hjp.at> Mail-Followup-To: asrg@ietf.org References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> Mime-Version: 1.0 In-Reply-To: <45BD0681.6EFC@xyzzy.claranet.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645351204==" Errors-To: asrg-bounces@ietf.org --===============0645351204== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tVmo9FyGdCe4F4YN" Content-Disposition: inline --tVmo9FyGdCe4F4YN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-28 21:24:33 +0100, Frank Ellermann wrote: > Peter J. Holzer wrote: > > David Nicols' DATAFIRST proposal. > [...] > >> Could "DATA-first mail" (DF) work ? > =20 > > It could but in reality quite a lot of mail is rejected before > > it even hits the DATA stage (either because none of the recipients > > exists or because of checks which don't need the content (DNSBL, > > greylisting, ...). >=20 > Some of the checks (incl. DNSBL and SPF) are possible before RCPT, But rejecting because the recipient doesn't exist, isn't possible before the recipient is known, and that is the most common cause for permanent failures. > unless you intend to apply them selectively per receiver. In fact I do. SBL-XBL is currently used for all addresses except postmaster, and I plan to enable PBL for a few addresses to test it. I don't check SPF currently (doesn't seem worth it), but if I did I certainly would only do it on a per-recipient basis. Greylisting needs the recipient, and while having a part of the data (especially the message-id) would help, I don't think it would offset the increase in traffic caused by transferring the same message several times and getting a temporary failure each time until the greylisting period is over. > If you want to get RCPT before DATA it's simple, just don't offer > "DATAFIRST". But I want both. I want the ability to reject on a per-recipient basis before I receive the data, and I want the ability to selectively apply content filters for different recipients. > > With DATAFIRST all this mail will have to be transferred only to > > be rejected. I suspect that this will sharply increase the bandwidth > > requirements. >=20 > It should be visible in the log files of major site. If they check=20 > more than only the size between DATA and dot, We are not a major site, but we are running spamassassin between DATA and dot, so we do have a reason to return different responses for different recipients. We are using an ugly hack at the moment (http://www.hjp.at/projekte/qpsmtpd/cf_wrapper/), but I would like something cleaner. (I am fully aware of course that I would need to keep the hack for many years, until INLINE-DSN (or DEFERRAL, or however it is going to be called) is implemented by most of our neighbours) > otherwise they can't be interested to get "DATAFIRST" anyway. I'm not interested in DATAFIRST. I'm interested in returning per-recipient results to DATA. > What I didn't like in draft-hall-inline-dsn was the sequence of > per recipient responses after DATA matching the sequence of RCPT > before DATA. That's what the proposal is about. It allows several return codes for DATA. The exact mechanism might be different (for example, there could be a multiline-response instead of multiple single-line responses, or the return codes can be matched by address instead of order), but these are minor changes. > It would be more plausible if it implies PIPELINING. The proposal suggests that a implementation offering INLINE-DSN also offers PIPELINING, but frankly, I fail to see the connection. hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --tVmo9FyGdCe4F4YN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFvR5SfZ+RkG8quy0RAgBPAJ9vthvOpJOYTaxV6ja+rCr3HwgLOQCgtcCe JB/oGz4/OxxvvlZ1zkzorYc= =Cfl/ -----END PGP SIGNATURE----- --tVmo9FyGdCe4F4YN-- --===============0645351204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0645351204==-- From asrg-bounces@ietf.org Sun Jan 28 17:54:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBItm-00037z-T3; Sun, 28 Jan 2007 17:53:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBItl-00031I-Cm for asrg@ietf.org; Sun, 28 Jan 2007 17:53:21 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBIth-0003Zc-53 for asrg@ietf.org; Sun, 28 Jan 2007 17:53:21 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HBItQ-000820-00; Sun, 28 Jan 2007 22:53:00 +0000 To: ca+asrg@esmtp.org From: Tony Finch Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 In-Reply-To: <20070127042237.GA24125@zardoc.esmtp.org> References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <45B9070C.4060806@ehsco.com> Message-Id: Date: Sun, 28 Jan 2007 22:53:00 +0000 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Claus Assmann wrote: > >1. the name is confusing and the new name isn't very helpful either. >Let's call it something like "Delayed-RCPT-Status" (DRS) or >"RCPT-Status-After-Dot" (RSAD). RCPT-status-after-data would be better - data sent using BTAT or BURL doesn't end with a dot. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: EASTERLY 4 OR 5, OCCASIONALLY 6 IN SOUTHWEST. SLIGHT OR MODERATE. FAIR. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 18:06:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJ69-0000TG-9I; Sun, 28 Jan 2007 18:06:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJ68-0000TB-2U for asrg@ietf.org; Sun, 28 Jan 2007 18:06:08 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJ66-0006h3-Pq for asrg@ietf.org; Sun, 28 Jan 2007 18:06:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBJ5w-0005pl-UC for asrg@ietf.org; Mon, 29 Jan 2007 00:05:56 +0100 Received: from du-017-218.access.de.clara.net ([212.82.246.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 00:05:56 +0100 Received: from nobody by du-017-218.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 00:05:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 29 Jan 2007 00:05:23 +0100 Organization: Lines: 16 Message-ID: <45BD2C33.62E1@xyzzy.claranet.de> References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> <20070128220610.GE18862@hjp.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-218.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Peter J. Holzer wrote: >> It would be more plausible if it implies PIPELINING. > The proposal suggests that a implementation offering INLINE-DSN > also offers PIPELINING, but frankly, I fail to see the connection. Anything else follows the model "one command gets one response", with multi-line responses as worst case. Multiple reponses is a derivation from this model. With PIPELINING the client is at least used to the idea that it somehow must match responses to pending commands. Probably a matter of taste, of course clients are not forced to use it if they don't like it. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 18:15:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJDh-0003mG-0o; Sun, 28 Jan 2007 18:13:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJDf-0003lz-KZ for asrg@ietf.org; Sun, 28 Jan 2007 18:13:56 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJDd-0008SM-91 for asrg@ietf.org; Sun, 28 Jan 2007 18:13:55 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C5C6A00; Sun, 28 Jan 2007 15:13:52 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0SNDqEI017736 for asrg@ietf.org; Sun, 28 Jan 2007 15:13:52 -0800 (PST) Date: Sun, 28 Jan 2007 15:13:52 -0800 From: Claus Assmann To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070128231351.GA127@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> <20070128220610.GE18862@hjp.at> <45BD2C33.62E1@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45BD2C33.62E1@xyzzy.claranet.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, Jan 29, 2007, Frank Ellermann wrote: > Anything else follows the model "one command gets one response", > with multi-line responses as worst case. Multiple reponses is a LMTP doesn't. SMTP clients are most likely able to deal with LMTP too as it's just a "minor" change. In fact, I just implemented this for the SMTP client in my MTA. > derivation from this model. With PIPELINING the client is at > least used to the idea that it somehow must match responses to > pending commands. Probably a matter of taste, of course clients > are not forced to use it if they don't like it. Let's make support for PIPELINING a MUST for this extension too (as it is the case for LMTP). _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 19:16:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKAL-0006GJ-KZ; Sun, 28 Jan 2007 19:14:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKAK-0006DJ-72 for asrg@ietf.org; Sun, 28 Jan 2007 19:14:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBKAI-0005Su-UX for asrg@ietf.org; Sun, 28 Jan 2007 19:14:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBKAA-0005jW-DP for asrg@ietf.org; Mon, 29 Jan 2007 01:14:22 +0100 Received: from du-017-218.access.de.clara.net ([212.82.246.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 01:14:22 +0100 Received: from nobody by du-017-218.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 01:14:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 29 Jan 2007 01:13:56 +0100 Organization: Lines: 7 Message-ID: <45BD3C44.2B66@xyzzy.claranet.de> References: <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> <20070128220610.GE18862@hjp.at> <45BD2C33.62E1@xyzzy.claranet.de> <20070128231351.GA127@zardoc.esmtp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-218.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Claus Assmann wrote: > Let's make support for PIPELINING a MUST for this extension too > (as it is the case for LMTP). +1 (admittedly I never looked into any LMTP code or standard :-) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Jan 28 21:27:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBMBx-0002dL-2c; Sun, 28 Jan 2007 21:24:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBMBw-0002dD-H3 for asrg@ietf.org; Sun, 28 Jan 2007 21:24:20 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBMBv-00020p-79 for asrg@ietf.org; Sun, 28 Jan 2007 21:24:20 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C5DA800; Sun, 28 Jan 2007 18:24:17 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0T2OHlQ017304 for asrg@ietf.org; Sun, 28 Jan 2007 18:24:17 -0800 (PST) Date: Sun, 28 Jan 2007 18:24:17 -0800 From: Claus Assmann To: asrg@ietf.org Message-ID: <20070129022417.GA27308@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B9070C.4060806@ehsco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Wrt section "6.4. The Final Response Code": Why do we need a final reply code? Isn't that code the same as the minimum over the RCPT reply codes (at least wrt the reply code severity)? Hence it is not need to send this reply code as it can be deduced from the existing reply codes. We only get to this stage if there are at least two RCPTs with different reply codes and hence 353 was used as reply for end of mail data. The final reply code is 250 iff at least one of the RCPTs has a 2yz reply code. If none of the RCPTs has a 2yz reply code then the final reply code must be 4yz; it can't be 5yz because it that case all RCPTs would have a 5yz reply code, which means it was useless to return individual reply codes (unless you want to return different 5yz reply codes with different enhanced status codes, however, even then the final reply code is still 5yz and does not contain any additional information). PS: "response code" should be replaced by "reply code" in the draft to match RFC2821. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 00:01:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOZP-0008OA-Cj; Sun, 28 Jan 2007 23:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOZO-0008O5-Ew for asrg@ietf.org; Sun, 28 Jan 2007 23:56:42 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBOZM-0002N9-Vh for asrg@ietf.org; Sun, 28 Jan 2007 23:56:42 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0T4mm615537 for ; Sun, 28 Jan 2007 23:48:48 -0500 (EST) Received: from [47.102.179.33] ([47.102.179.33] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jan 2007 23:56:34 -0500 Message-ID: <45BD7E7E.5070605@nortel.com> Date: Sun, 28 Jan 2007 23:56:30 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: HTML-burdened email References: <20070128135056.GB18862@hjp.at> In-Reply-To: <20070128135056.GB18862@hjp.at> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2007 04:56:34.0401 (UTC) FILETIME=[D98B1D10:01C74361] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter J. Holzer wrote: > On 2007-01-27 19:43:23 -0600, gep2@terabites.com wrote: >>> Well, 50% of our users are being sent almost no spam. >> Your users are very fortunate. > Nope. That's the normal distribution. Many users get almost no spam, > many get a an intermediate amount of spam and a few literally drown in > spam. Indeed. Such a distribution is consistent with everyone I've talked to who have made such measurements. >> Perhaps they haven't had those E-mail addresses for very long, or >> don't do much with them. Some of them have had them for many years and get almost none. Others have had them for a matter of months, and drown. One of the leading causes of getting deluged is being a member of IETF lists.... >>> But that doesn't help with the guy getting sent 4000/day. Or even >>> the hundreds getting 50 or more. >> I don't see why my approach won't handle such cases with >> ease. > That guy has to scan through 4000 messages each day to check if there > wasn't one which he did want. Maybe not every day, but at least every > time he suspects that a mail might have been blocked. It's physically impossible to find one or two legits out of 4000/day. >>>> Introductory E-mails should NOT automatically presume the desire or >>>> willingness of the recipient to receive HTML-burdened E-mails. >>> But if all spam were indistinguishable from >>> "introductory e-mails", >>> where are you then? >> No worse than at present. > > Depends on what you define as "better" and "worse". You will get less > spam (about 50% less, I would guess from looking through my spambox), > but you will also get less legitimate mail (I don't know how common HTML > mail is on average - that seems to vary a lot). It's _very_ high here. Corporate likes their HTML and attachments. >>> The XBL, for example, is _extremely_ reliable at >>> detecting compromised >>> end-user machines. All by itself it will block 70-85% >>> of all spam. >> Fine. But it also blocks LEGITIMATE mail coming from >> those machines, right? > > There is no legitimate mail coming from those machines. Maybe a message > or two for every million messages being blocked. Probably less. We go several days between seeing an XBL FP (out of 1.6M blocked per day). And they're fixed - we whitelist and help the sender get their systems disinfected so they can stay out of the XBL. Email not lost, sender's machine is fixed, less spam hits the Internet. Is that a win-win or what? Like I keep saying, we get higher FPs out of our content filters. Even the extremely obvious - HELO'ing as our domain - we see _legitimate_ (home brew) MTAs doing it. > >>> By it's very nature it doesn't list real MTAs (eg: ISP >>> smarthosts). >> What if the spam is sent through ths "smarthost"? You >> might claim that's not being done today, but nothing >> prevents spammers from doing that. It's harder. And we have a blocking solution for that. You don't have to run ONLY DNSBLs. What's that I keep saying? _Hybrid_ filtering systems. > Then there is an ISP to complain to and the ISP knows which of their > users has a compromised machine and can do somthing about it. If the ISP > doesn't do something about it, he may find that some may refuse to > accept mail from him or apply more stringent filters to it. But that > doesn't have anything to do with the XBL. > > You are assuming that IP-based reputation is used in an all-or-nothing > way. It isn't. There is more than one list, and just because an IP > address is or isn't on a specific list doesn't mean that all mails from > this address are rejected or accepted. It is one criterion among many. He's also assuming that if you're using DNSBLs you're somehow prevented from using other techniques simultaneously. That is simply not the case. > >>> Subject: Re: [Asrg] Re: bounces, and anti-spam >>> principles >>>> [how users configure their whitelist rules] >>>> >>>>> The problem being that out of the 60,000 seats here, perhaps less >>>>> than 10 of them are able to competently configure a set of rules >>>>> like what you have. >>>> That's a software implementation issue, not an inherent >>>> problem in the approach. I envision a button to click >>>> on >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> I guess that's the main reason why your ideas aren't met with wild >>> enthusiasm here. You "envision" that this would be simple to build >>> and to use, but it's not even clear that you have even built a >>> prototype which you use yourself, much less deployed the system for >>> "ordinary users", which aren't quite sure what an "HTML mail" is, and >>> have never heard about an "ActiveX component". >> I've built and have used portions of what I propose. >> Obviously it will work best if the proposed default rules >> are widely used. >> >> As for "deploying it for ordinary users", I think I could >> make the same claim regarding all these DNS-based >> proposals that y'all are so fixated on. > > No, absolutely not. Apart from not being fixated on "DNS-based > proposals" (if anything, I'm fixated on bayesian filtering), I see two > very important differences here: > > 1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals". They have been > operational for years and their strengths and weaknesses are well-known. And default recommendations in many packages. Such as SpamAssassin. > 2) The user has absolutely nothing to do with them. I can simply enable > them on a system-wide basis and be confident that I will maybe have to > deal with one complaint every few years. We have a few more than that, but we fix them. >> Again, good software implementation doesn't have to depend on users >> understanding those details > I doubt that. In real life users get mails with "advanced features" all > the time and if they have to decide whether they can safely enable them > they need to understand them. I predict that the average user will > either have configured that system to accept anything from anybody > within a week or give up on email entirely. If we tried that here, the average user would be screaming at me why their filters weren't working. Or working too well. >>>> that simply says "allow E-mails like this from the same sender in >>>> the future" and where the software will open the keyway JUST enough >>>> to allow that type of message if seen again from that sender. >>> So Uncle Bob will see that a mail from Aunt Matilda was blocked >>> because it contained an "executable attachment". Since he wants to >>> get mail from Aunt Matilda (and Aunt Matilda is a nice lady, she >>> wouldn't send him anything bad, would she?) he clicks on "allow >>> E-mails like this from the same sender in the future". Oops! >> Presumably he could tell from the rest of the content in >> the mail message that it really didn't look like E-mail >> from Aunt Matilda. > > To do that he has to read it. What good is an anti-spam scheme which > requires me to read all my spam? What good is an anti-spam scheme that, after you've seen the one good html email from Aunt Matilda, blindly delivered you the virus her machine sends the next day? Or the spam forged in her name? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb1+fp3FmCyJjHfhAQKKwgQA8HJ9hPhqXQ/thiiwto1vTAwtavArV/0v Z9j0aT3bQxwIOOqJ6wuA8juBlQ6aPstkP9EIU0xY44IEmgGaM8455DAl+o0cczLy P7WZhxV22lgyWT9T1S1CkoZ1Os/iaTMHqmqEAOaewVGYo7ZvIYyni4NLjm1rWmKB VM2cx46rZ/8= =AsP/ -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 04:53:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBT8l-0004ak-6I; Mon, 29 Jan 2007 04:49:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBT8j-0004aa-Rd for asrg@ietf.org; Mon, 29 Jan 2007 04:49:29 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBT8h-0001l7-CT for asrg@ietf.org; Mon, 29 Jan 2007 04:49:29 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 2E1804039; Mon, 29 Jan 2007 10:49:26 +0100 (CET) Date: Mon, 29 Jan 2007 10:49:26 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070129094926.GA24425@hjp.at> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> Mime-Version: 1.0 In-Reply-To: <20070129022417.GA27308@zardoc.esmtp.org> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0215103295==" Errors-To: asrg-bounces@ietf.org --===============0215103295== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-28 18:24:17 -0800, Claus Assmann wrote: > Wrt section "6.4. The Final Response Code": >=20 > Why do we need a final reply code? Isn't that code the same as the > minimum over the RCPT reply codes (at least wrt the reply code > severity)? Hence it is not need to send this reply code as it can > be deduced from the existing reply codes. As I understood it the final response code serves as a "commit" indication. A final 2xx reply means that the server has accepted the message and will try to deliver it to all the recipients which got a 2xx reply individually. If the the server cannot accept the connection, for example, because the queue is full, it can still return a 4xx or 5xx code, although it has earlier returned 2xx codes for some or all recipients.=20 That should make implementing the server a bit easier, as the message has to be queued only after all the recipients are known. Otherwise you either need to queue the message for each recipient indivually or you need to update the list of recipients after the message is already queued. It also may reduce the risk of resending a message which was already accepted because the connection broke down, but I'm not sure that really works: If you send a message to 100 recipients, and the connection breaks after 43 replies, how many will get the message? It might be anything between 43 and 100, because you don't know how many reply codes got lost. With the final reply code, the server only accepted the message after sending *all* of the reply codes. The chance that 57 reply codes were successfully sent from the server's perspective but never reached the client aren't that big, so the client can assume that the server didn't accept the message and resend it with all recipients. (OTOH, especially with long recipient lists and lengthy and possibly fragile content filters, maybe it is more robust to commit for each recipient individually: If the client wants to send to 100 recipients, and the server crashes after the 10th recipient every time, that way the message will get through in 10 transactions. It will never get trough if the server needs to scan the message for all recipients to queue it) hp --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFvcMmfZ+RkG8quy0RAjoaAJ9VSv99UHTw322SkssJtvAZKpJ7PACeMh7+ dk8Sp/8ytWuHZg7BQv+rjfY= =jmvD -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- --===============0215103295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0215103295==-- From asrg-bounces@ietf.org Mon Jan 29 07:40:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVld-00046B-6G; Mon, 29 Jan 2007 07:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVlb-000464-QO for asrg@ietf.org; Mon, 29 Jan 2007 07:37:47 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBVlZ-0002t6-EB for asrg@ietf.org; Mon, 29 Jan 2007 07:37:47 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id 9FA05589148; Mon, 29 Jan 2007 07:37:39 -0500 (EST) Received: from webmaillogin.com (fr3.webmaillogin.com [216.40.35.67]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id D3509589151 for ; Mon, 29 Jan 2007 07:35:07 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk2.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61197849 for asrg@ietf.org; Mon, 29 Jan 2007 04:50:59 -0500 From: Subject: Re: [Asrg] Quarantines and block lists To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Mon, 29 Jan 2007 03:50:59 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: b081eb6a5bf2a87d9780cad244b3c5bd X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org [comment #1] > Subject: Re: [Asrg] Quarantines and block lists > Lost Email is any email that is sent but not presented=20 >to the user =20 > and does not generate a DSN to the sender.=20 The problem is, in the case of spam as in the case of=20 viruses or worms, determining WHO the TRUE sender actually=20 is. It is safe to presume that it often is NOT the person=20 listed in the From: header. Therefore, I think we should note under "good practices"=20 that it is NOT "good practice" to return ANY indication=20 (after the original SMTP-time, and thus it's pretty much=20 limited anyhow to just going back 'one' level) regarding=20 mail blocked either as spam, or mail blocked because it=20 contains worms or viruses. In both cases, I believe we=20 MUST presume that the true sender will not be accurately=20 determinable. To send ANY kind of a bounce message back=20 is likely to create more harm than good, probably just=20 haranguing another innocent third party. Spammers COULD even use the expectation of the generated=20 'bounce' message to reflect the bounce message, along with=20 the copy of the original message, on to the=20 always-intended third party, but this time the E-mail=20 "originating" at the system that bounced it. > When=20 >referring to a =20 > receiving system loosing email it is assumed that the=20 >sending system =20 > is following standard procedures. It is a safe bet that spam and viruses/worms seldom IF=20 EVER "follow standard procedures". >> While spamtraps and valid user lists are helpful=20 >>sometimes, they =20 >> will not trigger if the spammer is using "fresh" E-mail=20 >>address =20 >> lists which are also devoid of spamtrap E-mail=20 >>addresses. >=20 > Is there evidence that spammers have 100% spamtrap free=20 >lists? Where =20 > are they getting their addresses from and why can't we=20 >seed spamtrap =20 > addresses there?=20 Well, I believe that a lot of addresses are harvested from=20 active Yahoogroups and other such mailing lists. Trying=20 to "seed" spamtrap addresses there (via postings) would=20 probably also generate legitimate replies to such posts. Certainly not all spammers use "fresh" and valid lists but=20 IMHO it's poor form to imagine that NONE do. >> IP address blocking, again, is simply too crude. A=20 >>further and =20 >> more serious problem is that you have basically no way=20 >>to be 100% =20 >> sure of who the "sending IP" actually is. >> >> For just one example, Yahoogroups >=20 > That's obviously a non-starter. Yahoogroups is a=20 >subscription based =20 > service. A valid spamtrap would not be subscribed to any=20 >group =20 > (unless it was designed to catch spammers harvisting=20 >group addresses =20 > in which case it would take special precautions to=20 >exclude group =20 > related emails from the spamtrap reports). The point is that NON-spamtrap addresses get mail through=20 Yahoogroups, and where you can't tell much or anything=20 about where the E-mail actually originated. So do you=20 block Yahoogroups servers by IP address? And if you don't do anything about Yahoogroups-forwarded=20 spam, then you're leaving a gaping hole through which a=20 large quantity of spam can be sent. Let's DO agree that it's probably not feasible to do much=20 of anything about spam contained within a "digest" (and we=20 ought to recognize, at least, the problem of antispam=20 contact detection triggering based on one message within=20 an otherwise good digest of messages). But it would be=20 desirable to try to handle effective spam detection for=20 individually forwarded Yahoogroups messages. Again, IP-based detection blocking is nowhere close to=20 viable for such cases. >> Or let's say that Aunt Gertrude's machine gets infected=20 >>by a worm, =20 >> which starts sending out E-mails using Aunt Gertrude's=20 >>account at =20 >> the ISP, via the ISP's mail server. Are you going to=20 >>block =20 >> everything coming from that mail server? What if it is=20 >>a VERY =20 >> large ISP? Obviously, it would have been nice if that=20 >>ISP's =20 >> outgoing mail rules had caught the messages, but in this=20 >>case let's =20 >> recognize that they didn't. >=20 > Spam has to be stopped somewhere. But read the full set=20 >of =20 > proposals... If a site has never received email from=20 >that IP before =20 > it would quarantine the first emails from that IP as in=20 >proposal #1. =20 > The automatic spamtrap network would generate an=20 >advisory that the IP =20 > is sending UBE. Then depending on the reputation of that=20 >IP from all =20 > sources the site would choose to a: continue the=20 >quarantine, b: =20 > accept the email and possibly apply additional filtering=20 >or c: reject =20 > the email from that IP. I know that a lot of folks here seem to have a strong=20 emotional commitment to the basic concept of IP-based=20 blocking, but as unpleasant as it is to accept, that is=20 simply NOT a very good approach. >>> If the source is emitting a sufficient volume of spam=20 >>>this =20 >>> happens before the initial probation period expires. >> >> Again, that's part of what I said about spammers=20 >>engineering their =20 >> mails so they squeak under whatever threshold is=20 >>established to =20 >> trigger spam alarms. That can be done on content,=20 >>sending rate, or =20 >> any other generally/widely used criteria. >=20 > So I've forced the spammer to send less spam. This I=20 >call progress. No, you've only forced them to send it at a lower rate=20 from probably more different locations. ULTIMATELY what convinces them to send less spam is=20 because it becomes unprofitable to do it, because=20 virtually none of it reaches its intended destination. As=20 long as it's profitable to try, they can be expected to=20 continue. That's one reason why it's SO critical to put the kibosh=20 on viruses and worms that recruit the spambot armies...=20 that makes it harder to proxy the spam transmissions and=20 diversify the origin points. Slamming the door on HTML=20 and attachments from unknown senders puts a MAJOR brake on=20 that, literally overnight, and in a way that is very=20 difficult to circumvent in any widespread way. =20 >>> I think a form of flood distribution through a mesh of=20 >>>peer nodes =20 >>> would be more robust. The distribution would feed local=20 >>>databases =20 >>> that could be queried directly or through a DNS front=20 >>>end. The =20 >>> mesh can handle data from multiple sources and needs no=20 >>>central =20 >>> authority. >> >> And how do you propose to prevent worms from targeting=20 >>and flooding =20 >> or doing other Denial of Service attacks on that mesh? >=20 > What port and IP address is the worm going to target?=20 >You won't know =20 > unless you've talked with the admin of that node and=20 >even then you =20 > might have a private port that only you know about. And=20 >even if you =20 > do manage to take out one node (or a dozen) the mesh=20 >survives and =20 > routes around the damage.=20 That depends, of course, on how widespread the 'damage'=20 is. Again, I think that blocking spambot army recruiting=20 is critical to reducing the severity of DoS attacks like=20 this. [snip] >2. Do you know what a response code in SMTP is?=20 Yes. But if the incoming SMTP transaction is coming from=20 an intermediary MTA, existing intermediaries frequently=20 will try to generate a bounce E-mail (to what they (often=20 wrongly) believe was the sender) based on their inability=20 to forward a mail message to its final destination, and=20 that frequently does more harm than good. > 3. I never "bounce" anything. Good, I wish that (at least for spam/worm cases) nobody=20 else did either. > The determination to quarantine email while waiting for=20 >additional =20 > information to become available or the possibility that=20 >the sending =20 > site will clean up the spam first should be easy to=20 >make. Are you =20 > perhaps referring to the rules for implementing proposal=20 >#2? Again, I don't consider IP address (at least not by=20 itself) a good basis for determining what is and is not=20 spam. >> Apart from (as previously noted) the problem of=20 >>determining after =20 >> the fact with any real accuracy just who the "sending=20 >>server" =20 >> actually is, particularly for multi-hop mail deliveries.=20 >> It's =20 >> easy enough to forget that not all E-mail deliveries are=20 >>simple =20 >> user->ISP->ISP->user transfers. >=20 >First you have the intranet delivery on the sending side >=20 > user-> (users ISP internal servers) -> Sending MTA >=20 > Then you have the internet delivery >=20 > Sending MTA ----> Receiving MTA > or > Sending MTA ----> (open relay) ---> Receiving MTA >=20 > And finally the intranet delivery on the receiving side >=20 > Receiving MTA -> (receiving ISP internal servers) ->=20 >destination >=20 > I am only concerned with the internet delivery. Anything=20 >else the =20 > ISPs can handle on their own. So all internet email=20 >deliveries are =20 > simple ISP->ISP transactions. Let me give you an example of why that's overly=20 simplistic. sender -> sender's ISP MTA -> recipient's vanity=20 domain's mail forwarding MTA -> recipient's "real" ISP=20 receiving MTA -> recipient (and of course, there could be multiple such levels of=20 intermediary forwarding, or things like Majordomo servers=20 involved too). >> Vanity domains that provide mail forwarding are just one=20 >>example of =20 >> a way that intermediaries enter into a mail delivery=20 >>chain. =20 >> Aggregators/forwarders like Yahoogroups are another. >=20 > If the vanity domain allows you to create hundreds or=20 >thousands of =20 > forwarders to addresses you don't own to make it look=20 >like a spammer =20 > site it deserves to be blocked. That's not the question. The issue is that it forwards=20 the mail (and let's presume for now that there is only one=20 vanity domain forwarding taking place) to the receipient's=20 ISP's MTA, which doesn't like it for whatever reason and=20 sends back an SMTP rejection. Now, what does the vanity=20 domain mail server do with that? They can't (presumably)=20 send it back to the MTA *they* got the mail from; that=20 SMTP transaction is most likely long over. Generally what=20 happens (unfortunately) is they try to send back the=20 warning as an E-mail message, and that turns out to be a=20 Really Bad Idea. Second point is that if the recipient ISP sees that it got=20 spam or a virus forwarded through the vanity domain=20 forwarding MTA, IP address blocking probably tries to=20 block the vanity domain forwarding agent, because the=20 receiving ISP's MTA can't reliably determine who the=20 original sender was. >>> that can be done with a 5xx on the next delivery=20 >>>attempt instead =20 >>> of sending a bounce. >> >> And what if the next E-mail coming from that IP address=20 >>is =20 >> legitimate, non-spam E-mail? >=20 > If the decision is to reject all mail coming from that=20 >IP=20 (which, again, I will insist is simply NOT practical). > then =20 > returning the 5xx response will cause the sending MTA to=20 >generate a =20 > DSN that will be returned to the legitimate sender. And, again, THEY cannot be 100% sure who that was, once=20 the original SMTP transaction they received is completed.=20 Most typically, they try to send an E-mail back to the=20 From: address, but for spam/virus rejections, that address=20 is almost never valid. >>> If the sending ISP is on their toes an offending user=20 >>>or host =20 >>> will be shut down quickly and the remaining mail will=20 >>>be =20 >>> delivered when the block advisory is lifted or expires. >> >> And what happens to their legitimate outgoing mail in=20 >>the meantime? >=20 > It sits in the quarantine until the block advisory is=20 >lifted and then =20 > gets delivered normally. Nothing is lost except for some=20 >sleep by the =20 > admin on duty for the sending ISP. If the "sending ISP" (or company) is huge, and the spam or=20 virus mail they occasionally send is frequent enough, the=20 result is that they have frequent major delays in mail=20 delivery, or even suffer serious and relatively permanent=20 "e-mail constipation". >>> Local whitelists can be used to allow mail to bypass=20 >>>the quarantine. >> >> That's fine, but (again) I believe that traditional,=20 >>simple =20 >> "whitelists" are not nearly adequate. I believe that a=20 >>viable =20 >> whitelist MUST comprise a recipient/sender pair of=20 >>addresses, AND =20 >> additional criteria regarding what the recipient expects=20 >>to receive =20 >> from the sender in question. >> >> More to the point, once THAT is done, I believe that IP=20 >>address =20 >> blocking becomes essentially superfluous (and indeed,=20 >>COUNTER =20 >> productive). >=20 > None of my proposals say "block" anything. I say issue=20 >advisories in =20 > proposal #2, some users might want that information.=20 I claim that a user (or ISP) who did not actually send the=20 mail that is attributed (wrongly) to them virtually never=20 gets anything of value of receiving a lot of complaints=20 about the counterfeit use of their E-mail address. > I propose =20 > quarantining email when it's looking suspicious. The=20 >sending ISP =20 > knows where the email came from which is something that=20 >the receiver =20 > cannot know in all cases.=20 The sending ISP only knows where it CLAIMS to have come=20 from, much of the time. And nothing absolutely guarantees=20 that that address is even still online. It's one thing to=20 catch a problem during the SMTP transaction, but much more=20 problematical to try to report it back after the fact. > If anybody is going to decide=20 >that email is =20 > spam it is the sending ISP that has the best information=20 >to make that =20 > decision.=20 I disagree. If the ultimate determination about whether=20 the mail is unwanted or not is made by the RECIPIENT (and=20 that's what I believe is the ONLY person who can decide=20 that) then the sending ISP is NOT in the position to=20 decide. > Proposal #4 provides the one key piece that=20 >the sending ISP =20 > doesn't have to determine that their user is sending UBE=20 >(aka spam). >=20 > If you as an ISP are offered these free tools to help=20 >control spam =20 > emanating from your network are you going to say "no=20 >thanks, we'll =20 > just send the spam and let everybody else clean it up"? So what do you propose they do with things that say "this=20 is spam, we won't accept it" that are bogus? That's what=20 I've seen happening here, where Yahoogroups gets a bogus=20 5xx message that mail to "me" hard bounced (because it=20 contained a virus, usually) and as a result, they block=20 ALL mail from getting sent out to me until I realize what=20 happened and manage to reset things. Of course, I have NO=20 control over the problem. (And they don't either,=20 really... but at least they shouldn't consider a mail=20 account hard bouncing just because of the CONTENT of ONE=20 message that 'hard' bounced). [comment #2] > Subject: Re: [Asrg] Quarantines and block lists >> To begin with, crude IP blocks will ALWAYS lose=20 >>legitimate=20 >> mail, because a single IP address can send both=20 >>legitimate=20 >> and zombie-generated mail. >=20 > We've been using the spamhaus dnsbls for several years=20 >and I can't > remember a single false positive. IP adresses which send=20 >legitimate > mails are simply not listed there (or if they are, there=20 >are so few of > them that it's indetectable).=20 You're trying to pretend that a zombie prevents all=20 legitimate mail from being sent out from that same IP=20 address? So that it's a binary "spamming/not spamming"=20 machine? If your argument is that the zombies are not using the=20 commandeered machine's habitual upstream MTA, then I'll=20 claim that spammers could trivially change their approach=20 to do that. Then, IP-based blocking either blocks (or doesn't block)=20 ALL the E-mails originating from that MTA. > It is true that they aren't sufficient, but they reduce=20 >spam by quite a > bit (they're by far the most frequent reason for a=20 >permanent error) with > practically zero false positives. I believe that a good sender/recipient pairing mapping to=20 a fine-grained permissions list is FAR more effective and=20 satisfactory, with FAR less collateral damage to=20 legitimate mail. And besides, it is FAR harder for=20 spammers and viruses/worms to circumvent and evade such a=20 robust restriction. I believe that to be SO effective=20 that IP-based blocking becomes (at least in most cases)=20 superfluous. > I don't know why you insist that they would have to list=20 >a single IP > address which sends both legitimate and zombie-generated=20 >mail. Just look > at spamhaus and you can see that this is false. Are you claiming that both spam and non-spam can't be=20 funnelled through the same IP address? Just one excellent counter-example is a small company that=20 has their inhouse outbound mail server behind a NAT router=20 (this is the case, in fact, for one of my consulting=20 client companies). If one of their other inhouse=20 workstations ends up being infected by a worm, that=20 infected machine could start to send either spam, or virus=20 propagation messages, and those messages will also carry=20 the IP address of the company's NAT router. [comment #3] > Please don't answer mails from different people in=20 >different subthreads > in the same mail. Your mails are already too long, and=20 >an argument is > hard to follow if the answer the content of one mail is=20 >in the answer to > a different mail. I agree that it's suboptimal, but otherwise it is=20 cumbersome to split a large message digest into individual=20 fragments to allow quoting those messages for separate=20 replies. I don't know of any GOOD solution for that problem, but am=20 open to ideas. (Approaches that I otherwise might find=20 practical are limited by the Webmail system I'm presently=20 using). >> >(1) I'm shopping at a major retailer's website and=20 >>decide to sign up >> >for their newsletter. What happens if the confirmation=20 >>message uses >> >HTML content (not uncommon)? =20 >>=20 >> Obviously, it SHOULD NOT use HTML content, >=20 > But it does. And if you're a small ISP or IT department=20 >and your users > can't get their newsletter, guess who they'll blame?=20 Given a choice of controlling spam, or the irresponsible=20 use of HTML being sent to users who might not wish to deal=20 with it, I think that being a little more nuanced and=20 disciplined in the use of HTML is a small price to pay. > You or the major > retailer?=20 To some degree, it's obviously a problem of educating the=20 user of what you're doing, and (more importantly) WHY you=20 are doing it. If enough users make the decision, the 'large retailer'=20 will clearly learn that they have to change their behavior=20 at least slightly. But that's not a bad thing. > And what's more likely to change? The way you=20 >filter mail or > the way the major retailer sends their newsletter? I guess it depends on whether you want to control spam=20 effectively, and how important that is to your users. I happen to think that's pretty important to a large=20 percentage of users. > You can do that if you're the DoD. The DoD recently=20 >banned HTML and they > can get away with it, because almost everyone they=20 >exchange mail with > is more interested in talking to the DoD than the DoD is=20 >talking to > them. If the DoD doesn't get your mails, that's your=20 >problem, not > theirs. I think that as more people become aware of the costs of=20 HTML (bulk, risk, etc), a lot fewer people will be willing=20 to pay the price of it. >> for the simple reason that said retailer CAN NOT be=20 >>certain that the >> person asking to be on their newsletter list is able to=20 >>handle (or >> WANTS to receive) HTML-burdened mail messages. >=20 > He doesn't care. 99% of his prospective customers can=20 >handle it, and > they will be enticed by the pretty pictures. He can=20 >afford to lose 1% > (who are probably the more critical customers anyway). I'm not suggesting that they can't use HTML in (at least=20 the 'pretty' version of) their newsletter. Just that they=20 need to send at least one plain-ASCII-text confirmation=20 mail to the user FIRST, to negotiate the agreement to=20 accept HTML in subsequent E-mail messages. =20 >> >Assuming that the confirmation and the newsletter come=20 >>from the same >> >source, that is, which also is not always the case. >>=20 >> True, although if that is recognized as important to=20 >> legitimate mailers, they can certainly correct such=20 >> questionable behavior. >=20 > That "questionable behaviour" is pretty much standard,=20 >and there are > good reasons for it. Well, there are some "pretty good reasons" for greater=20 discipline. =20 If we are going to get a serious handle on spam, viruses,=20 and worms... then SOMEONE is going to have to change=20 behavior AT LEAST SOMEWHAT. The objective should be to=20 make that process as rational and painless as possible,=20 commensurate with efficacy. >> >(3) My biggest customer is a giant corporation which=20 >>requires its >> >employees to use Microsoft Outlook and to attach a=20 >>vCard-like >> >signature to every email, using a background stationery=20 >>and having an >> >image of the company's latest logo because they're=20 >>engaged in a major >> >rebranding initiative. Not surprisingly, they have=20 >>massive turnover, >> >so the people there who send email to a variety of=20 >>people at my >> >company changes every several weeks. Who's responsible=20 >>for upkeep of >> >all of those individual agreements to exhange HTML with=20 >>each other? >>=20 >> Again, the recipient could presumably set up a=20 >>"catch-all"=20 >> whitelisting which would enable selected E-mail HTML=20 >> features and selected attachment types from any user at=20 >>a=20 >> given company's domain. For example, allow (hell, even=20 >> REQUIRE) V-card attachments or JPGs for mail from that=20 >> domain, but (for example) not allowing scripting,=20 >> executable attachments, or ActiveX. >=20 > Yes, he could. But he doesn't want to.=20 Well, ultimately, it's all about choices, isn't it? You=20 can give people an effective spam filter, or you can allow=20 them to turn it completely off. At least if you OFFER it,=20 they can't then bitch about the spam load they're getting=20 if they CHOSE to not use it. I've had some spam filters at some ISPs that were SO=20 terrible that I turned them off and decided to do the=20 filtering myself instead. But you know the old adage about leading a horse to water. At least this proposal WOULD BE EFFECTIVE (and with less=20 collateral damage than the IP-based solutions that so many=20 folks here seem to like) AND would block nearly all worms=20 and viruses (even new ones) which isn't the case for these=20 IP-based approaches. AND it's not got any huge "gotchas"=20 that force people to turn it off, like so many other=20 basically-unusable filtering schemes are afflicted with. > It's not his job to worry about > which types of content a certain user (which he not even=20 >know) might > send to him in the future. Fair enough. But spam has become annoying enough to=20 enough people by now that I don't think most of them would=20 be terribly averse to helping guide a "smart" filter so it=20 would effectively recognize and block spam... especially=20 if (as they do so) they see an immediate and very=20 noticeable payback for the investment. >> >The only way your techniques can work effectively is if=20 >> >you assume that >> >the recipient is getting very little spam. =20 >>=20 >> I don't think it's particularly volume-sensitive...=20 >>other=20 >> than the fact, of course, that ANY system could=20 >> conceivably be flooded by a sufficiently determined DoS=20 >> attack. >=20 > It's a DoS attack on the user, not on the system. The=20 >user has to look > at the mails, decide whether they are legitimate, which=20 >of their > features he wants to accept from that sender (and=20 >whether "that sender" > means only that particular address, or the whole domain=20 >or something in > between). Again, good software can determine what features need to=20 be accepted to allow "mail like this" to be added to the=20 allowable characteristics for the current sender. Some users will tweak things more precisely than others=20 will. A large subset of users will probably find that the=20 default filtering rules are perfectly acceptable for the=20 great majority of their incoming mail. [users receiving large volumes of mail] >> I don't see why my approach won't handle such cases with=20 >> ease. >=20 > That guy has to scan through 4000 messages each day to=20 >check if there > wasn't one which he did want. Maybe not every day, but=20 >at least every > time he suspects that a mail might have been blocked. To some degree, that's going to be true for ANY filtering=20 scheme. At least he has the mail to look at... if it was=20 blocked by IP address, he can't go look for it, since it's=20 not on his (recipient) system at all. Some people will look for false positives, some won't.=20 Some people will go to the effort to "tune" their filters=20 to the best and most effective degree of accuracy, and=20 others will run with the defaults. That's to be expected. >> >>Introductory E-mails should NOT automatically presume=20 >>the desire or >> >>willingness of the recipient to receive HTML-burdened=20 >>E-mails. >> > >> >But if all spam were indistinguishable from=20 >> >"introductory e-mails", >> >where are you then? >>=20 >> No worse than at present. >=20 > Depends on what you define as "better" and "worse". You=20 >will get less > spam (about 50% less, I would guess from looking through=20 >my spambox), > but you will also get less legitimate mail (I don't know=20 >how common HTML > mail is on average - that seems to vary a lot).=20 Yes, it does. And there's nothing inherently wrong with=20 HTML mail (other than its 3-5x greater bulk) IF you're=20 able and willing to deal with it. But senders ought not=20 to PRESUME that EVERYONE feels that way. >> And BETTER, since the "no attachment, no HTML" default=20 >> rule would seriously cripple zombie spambot army=20 >> recruitment. >=20 > Only if it is widely adopted. Which it won't be, because=20 >the early > adopters will have to deal with severe problems. I don't consider that a fair or accurate statement. Early=20 adopters can phase in the filtering, perhaps by starting=20 with a relatively liberal default rule which is tightened=20 as the whitelist is developed. Again, that's an issue of=20 the implementing software. It doesn't invalidate the=20 principle. >> >The XBL, for example, is _extremely_ reliable at=20 >> >detecting compromised >> >end-user machines. All by itself it will block 70-85%=20 >> >of all spam. =20 >>=20 >> Fine. But it also blocks LEGITIMATE mail coming from=20 >> those machines, right? >=20 > There is no legitimate mail coming from those machines.=20 >Maybe a message > or two for every million messages being blocked.=20 >Probably less. I've already given a case earlier in this message of why=20 that can't be counted on, or at least why we shouldn't=20 base our antispam defenses on such 'lucky behavior' over=20 the long term. I won't repeat that example again here. >> >By it's very nature it doesn't list real MTAs (eg: ISP=20 >> >smarthosts). =20 >>=20 >> What if the spam is sent through ths "smarthost"? You=20 >> might claim that's not being done today, but nothing=20 >> prevents spammers from doing that. >=20 > Then there is an ISP to complain to and the ISP knows=20 >which of their > users has a compromised machine and can do somthing=20 >about it.=20 And that's fine for small ISPs who can call a user=20 (maybe). Bigger ISPs with millions of users (especially=20 where thousands or tens of thousands of their users could=20 be infected) will find that kind of detailed=20 followup/uninfection to be an extremely costly and=20 time-consuming problem. Big dot-com companies (Yahoo, Ebay/paypal, etc) almost=20 universally have terrible customer service if you ever=20 have to talk to a real HUMAN there. And that's not only=20 just demonstrating that they don't CARE... it's a huge=20 problem for them. > If the ISP > doesn't do something about it, he may find that some may=20 >refuse to > accept mail from him or apply more stringent filters to=20 >it. But that > doesn't have anything to do with the XBL. Again, it's a very blunt instrument to do IP-level=20 blocking. We can simply do a LOT better. > You are assuming that IP-based reputation is used in an=20 >all-or-nothing > way. It isn't. There is more than one list, and just=20 >because an IP > address is or isn't on a specific list doesn't mean that=20 >all mails from > this address are rejected or accepted. It is one=20 >criterion among many. I consider that other criteria should carry more weight,=20 then, and IP address carry much less weight. >> >Subject: Re: [Asrg] Re: bounces, and anti-spam=20 >> >principles >>=20 >> >>[how users configure their whitelist rules] >> >> >> >>>The problem being that out of the 60,000 seats here,=20 >>perhaps less >> >>>than 10 of them are able to competently configure a=20 >>set of rules >> >>>like what you have. =20 >> >> >> >>That's a software implementation issue, not an=20 >>inherent=20 >> >>problem in the approach. I envision a button to click=20 >> >>on=20 >> >=20 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >I guess that's the main reason why your ideas aren't=20 >>met with wild >> >enthusiasm here. You "envision" that this would be=20 >>simple to build >> >and to use, but it's not even clear that you have even=20 >>built a >> >prototype which you use yourself, much less deployed=20 >>the system for >> >"ordinary users", which aren't quite sure what an "HTML=20 >>mail" is, and >> >have never heard about an "ActiveX component". >>=20 >> I've built and have used portions of what I propose.=20 >> Obviously it will work best if the proposed default=20 >>rules=20 >> are widely used. >>=20 >> As for "deploying it for ordinary users", I think I=20 >>could=20 >> make the same claim regarding all these DNS-based=20 >> proposals that y'all are so fixated on. >=20 > No, absolutely not. Apart from not being fixated on=20 >"DNS-based > proposals" (if anything, I'm fixated on bayesian=20 >filtering), I see two > very important differences here:=20 >=20 > 1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals".=20 >They have been > operational for years and their strengths and weaknesses=20 >are well-known. Straw man. If existing approaches were satisfactory, then=20 we don't have a problem and we're all wasting our time=20 time. If on the other hand we are going to do things DIFFERENTLY=20 than they have been done before, then we should EXPECT=20 that that new approach hasn't been implemented yet. The fact that it hasn't been fully implemented yet doesn't=20 mean that it's not promising. Lots of things are designed and discussed and debated for=20 a long time before the first working one is actually=20 built. Large passenger aircraft are one example. I probably wouldn't go to the trouble to do a full=20 customer-ready version of such software if it were just=20 only me going to use it. But Airbus wouldn't build the=20 A380 if there were only going to be one of them, just as a=20 Honda Accord wouldn't be practical to design and fully=20 engineer if only one person were going to have one,=20 either. =20 > 2) The user has absolutely nothing to do with them. I=20 >can simply enable > them on a system-wide basis and be confident that I will=20 >maybe have to > deal with one complaint every few years.=20 By the same token, a large group of users will be content=20 with default filtering and default content=20 ("SpamAssassin") filtering. Some will care enough, and=20 choose to tweak those. Many will not. At least the ones=20 who CARE to do so CAN do so. >> Again, good software implementation doesn't have to=20 >>depend on users >> understanding those details >=20 > I doubt that. In real life users get mails with=20 >"advanced features" all > the time and if they have to decide whether they can=20 >safely enable them > they need to understand them.=20 Do you understand how your automatic transmission in your=20 car works? What percentage of drivers do you imagine do? If enabling a relatively more dangerous feature (say,=20 executable attachments), the software presumably should=20 issue some pretty dire-sounding warnings about why the=20 user maybe shouldn't do that... just to counter=20 pfishing-type exploits where they try to convince people=20 to release the safety. (We saw some viruses/spam trying=20 to do that, a few years back, telling users to please=20 enable scripting and telling them how to do it... but I=20 haven't seen any spam like that in quite a while now.). > I predict that the average user will > either have configured that system to accept anything=20 >from anybody > within a week or give up on email entirely. If the software is well-designed, then I'd take on that=20 bet with you. :-) =20 >> I don't think where things fall on that particular=20 >> equation are especially relevant to whether the approach=20 >> would be a good one for more widespread adoption. :-) >=20 > It is irrelevant whether it "would be good". User's=20 >simply won't adopt > it. Period. It will ask them questions they don't=20 >understand twenty > times a day, so they will resort to either clicking=20 >"yes" all the time > or "no" all the time.=20 Again, that depends entirely on how well the=20 human-engineering of the software is done. Some companies=20 traditionally do a bad job of stuff like that, but doesn't=20 mean it can't be done right. > As a result they won't get the=20 >mail they want and > they will still get mail they don't want. In addition=20 >they will feel > dumb because they don't understand all those questions,=20 >and they will be > angry at the computer (it should handle that stuff=20 >without asking stupid > questions) and the IT staff or ISP (it's their job to=20 >handle that > stuff). A week later the system will be shut off again=20 >and the poor guy > who thought "it would be good" will be fired. I'm sure that's what the spammers would wish. But the fact is that it will be MORE effective at blocking=20 spam, nearly 100% effective at blocking worms and viruses=20 (even previously unknown ones that no antivirus program=20 identifies) and still give the user the ability to improve=20 the detection to the degree they wish (or not, if they=20 prefer). Given the major improvement in spam reduction that is=20 possible, the people who OUGHT to be fired are those=20 naysayers who choose to instead pursue costly, compex and=20 elaborate technical schemes which ultimately and=20 predictably CAN NOT solve the problem as well. >> >So Uncle Bob will see that a mail from Aunt Matilda was=20 >>blocked >> >because it contained an "executable attachment". Since=20 >>he wants to >> >get mail from Aunt Matilda (and Aunt Matilda is a nice=20 >>lady, she >> >wouldn't send him anything bad, would she?) he clicks=20 >>on "allow >> >E-mails like this from the same sender in the future".=20 >>Oops! >>=20 >> Presumably he could tell from the rest of the content in=20 >> the mail message that it really didn't look like E-mail=20 >> from Aunt Matilda. >=20 > To do that he has to read it. What good is an anti-spam=20 >scheme which > requires me to read all my spam? Well, to begin with, it will block nearly all HTML and=20 attachment-containing E-mail from people you don't know. I agree that some folks, especially initially, or those=20 who get relatively small amounts of spam, will get a "warm=20 and cozy" feeling by checking their quarantine/block=20 folder to see what was filtered out (at least they CAN,=20 which generally isn't the case in IP-type blocking). As=20 they develop more trust in the system, and get it more=20 tuned, or as they get more spam end up in the reject bin,=20 they'll probably come to trust its judgement and just dump=20 that bin unread more and more often. During the phase-in period, there will be more "training"=20 taking place (both of the software, AND of the users!).=20 That's to be expected. [comment #4] > Subject: Re: [Asrg] Re: HTML-burdened email >> (I don't know=20 >>how common HTML >> mail is on average - that seems to vary a lot).=20 >=20 > It's _very_ high here. Corporate likes their HTML and=20 >attachments. That's fine, and I don't suggest that it never be used. I do think it's impolite (at best) and presumptuous to=20 send HTML E-mail to people without first determining that=20 they are able and willing to accept mail in that format. ESPECIALLY given the numerous ways that HTML hugely=20 facilitates the task of spammers to get past antispam=20 content filtering. Accepting HTML ONLY AFTER negotiation from specific=20 senders strikes me as a very small price to pay if it=20 hugely reduces the spam problem (and it can). Solving the spam problem DOES require some changes. The=20 trick is to make those changes both reasonable, and=20 effective. [snip] >> 1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals".=20 >>They have been >> operational for years and their strengths and weaknesses=20 >>are well-known. >=20 > And default recommendations in many packages. Such as=20 >SpamAssassin. In part, that's because SpamAssassin has a nearly=20 impossible job to do if it has to deal with things like=20 text-as-image (whether attachment or embedded), HTML,=20 ActiveX, and such. Once attachments, scripting, and HTML=20 are excluded, SpamAssassin can be FAR more accurate and=20 effective. So it is understandable that they would suggest IP-based=20 filtering to help for those more difficult cases. It might even be the case that IP-based filtering MIGHT=20 still be a valid component even with a first-stage=20 fine-grained sender-based whitelisting. Although I=20 personally believe that by that point, IP-based filtering=20 will be mostly redundant. >> ...In real life users get mails with=20 >>"advanced features" all >> the time and if they have to decide whether they can=20 >>safely enable them >> they need to understand them. I predict that the average=20 >>user will >> either have configured that system to accept anything=20 >>from anybody >> within a week or give up on email entirely. >=20 > If we tried that here, the average user would be=20 >screaming at me why > their filters weren't working. Or working too well. I do expect that such filtering would be phased in during=20 the initial period, rather than being turned on suddenly=20 and abruptly. > What good is an anti-spam scheme that, after you've seen=20 >the one good > html email from Aunt Matilda, blindly delivered you the=20 >virus her > machine sends the next day? Or the spam forged in her=20 >name? That's why you don't just enable ALL HTML, or NO HTML.=20 Aunt Matilda isn't likely to do scripting, ActiveX, or=20 other elaborate HTML features. She might use fonts,=20 color, boldface, stuff like that. These all-or-nothing=20 whitelists are, indeed, almost useless because they end up=20 getting turned off. It's unlikely that one would EVER allow receiving=20 EXECUTABLE attachments from Aunt Matilda (indeed, most=20 users would never enable receiving executable attachments=20 from ANYBODY, at least if the software is sufficiently=20 dissuasive). The spam forged in Aunt Matilda's name would have to know=20 WHOSE name to forge to get past MY filter, and MOREOVER=20 would have to look "enough" like her mail that it didn't=20 get filtered out (and it's likely not feasible to decide=20 just what those criteria are for a given recipient). It's=20 a very winding, narrow gauntlet the spammers/virus authors=20 would have to navigate through. I believe that most of them won't be able to do that very=20 successfully. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 10:14:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYAv-0005dj-NF; Mon, 29 Jan 2007 10:12:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYAt-0005ck-ME for asrg@ietf.org; Mon, 29 Jan 2007 10:12:03 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYAl-0000Xn-Ul for asrg@ietf.org; Mon, 29 Jan 2007 10:12:03 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0TF47314985 for ; Mon, 29 Jan 2007 10:04:07 -0500 (EST) Received: from [47.9.17.17] ([47.9.17.17] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 10:11:42 -0500 Message-ID: <45BE0EAB.7070907@nortel.com> Date: Mon, 29 Jan 2007 10:11:39 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: Anti Spam Research Group Subject: Re: [Asrg] Quarantines and block lists References: <426040D7-38E8-46E4-8FB0-C338CF1003CA@qwest.net> In-Reply-To: <426040D7-38E8-46E4-8FB0-C338CF1003CA@qwest.net> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2007 15:11:42.0586 (UTC) FILETIME=[C88935A0:01C743B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Oetting wrote: > > On Jan 27, 2007, at 6:43 PM, gep2@terabites.com wrote: > >>> Here is my proposal. I'm sure I haven't thought of everything so >>> please tell me where it breaks or how spammers are going to game it. >>> The goal is to stop the majority of the spam while not loosing ANY >>> legitimate email (broken MTAs don't count). >> >> To begin with, crude IP blocks will ALWAYS lose legitimate mail, >> because a single IP address can send both legitimate and >> zombie-generated mail. I propose that NO ISP-based software will be >> capable of differentiating one from the other... but the recipient >> possibly will know how to do that, at least for familiar senders. > > I guess I didn't think to include a definition for "Lost Email". > > Lost Email is any email that is sent but not presented to the user and > does not generate a DSN to the sender. When referring to a receiving > system loosing email it is assumed that the sending system is following > standard procedures. By that definition, our filters NEVER EVER lose an email. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb4Oq53FmCyJjHfhAQJFAwP+PCnqCM4iOnEPWmh3VoH1hRQw5Mmd2RBV zk4nCPgATRVK3G6AFu4pIOM+wN/MouGGZrSlq2sk8opl7dk7wQ7FzNxJB9vfA6V/ F11XcAKwBVW0BKmmUKaj49bn7jwVE42rTHdex6eg5DabhGINh9W7L1to2iim9PvD 1xAYjWLHLn8= =a0KE -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 10:23:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYLR-0001F0-Ng; Mon, 29 Jan 2007 10:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYLQ-0001Ev-57 for asrg@ietf.org; Mon, 29 Jan 2007 10:22:56 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYLO-0001of-SL for asrg@ietf.org; Mon, 29 Jan 2007 10:22:56 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0TFMqe12642 for ; Mon, 29 Jan 2007 10:22:52 -0500 (EST) Received: from [47.9.17.17] ([47.9.17.17] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 10:22:39 -0500 Message-ID: <45BE113E.5060404@nortel.com> Date: Mon, 29 Jan 2007 10:22:38 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Quarantines and block lists References: <20070128113319.GA18862@hjp.at> In-Reply-To: <20070128113319.GA18862@hjp.at> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2007 15:22:39.0695 (UTC) FILETIME=[503415F0:01C743B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter J. Holzer wrote: > On 2007-01-27 19:43:23 -0600, gep2@terabites.com wrote: >> To begin with, crude IP blocks will ALWAYS lose legitimate >> mail, because a single IP address can send both legitimate >> and zombie-generated mail. > > We've been using the spamhaus dnsbls for several years and I can't > remember a single false positive. IP adresses which send legitimate > mails are simply not listed there (or if they are, there are so few of > them that it's indetectable). > > It is true that they aren't sufficient, but they reduce spam by quite a > bit (they're by far the most frequent reason for a permanent error) with > practically zero false positives. > > I don't know why you insist that they would have to list a single IP > address which sends both legitimate and zombie-generated mail. Just look > at spamhaus and you can see that this is false. He seems to be rather inconsistent in his position: 1) IP blocking _may_ (if you're not careful on what IPs you block) list mixed sources. Yeah, but, the content filtering methodologies he proposes have false positives _too_. Not to mention that the content filtering he's proposing has higher FPs than most DNSBLs. 2) If you use IP blocking, somehow you're magically restricted to ONLY using that one technique (and hence will miss spam from mixed sources). Yet, he uses multiple techniques so that he can catch the things that one technique misses with another technique. Why is he insisting that IP blocking can only be used on its own, when he's using multiple techniques himself? Say, yahoogroups. Why does he feel that someone using DNSBLs is restricted to using DNSBLs to block spam from yahoogroups? Nothing can be further from the truth. DNSBLs are just one of many spam filtering techniques. There's nothing special about them that prevents you from using it in combination with others. Especially if you use it in a scoring methodology like SpamAssassin. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb4RPp3FmCyJjHfhAQIsLwQAkJvu0iGUGLy4qmeob3q8uHdV3x+CM0Gz QpOrsn+a1fMECOSwEBu5zausHhT3rjAB6l06AGKU7QrrbgzJxFHtu0vsMfbR/5As VvzzAADLtCe9GmUKW6GzICZVVD91Nm86QbMtVNwWAr7er3BM5S/Z0Ot2EhkOYRMI Qwf5aRNWZGI= =AGfQ -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 12:05:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZuv-0005Iq-BL; Mon, 29 Jan 2007 12:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZuu-0005Il-BY for asrg@ietf.org; Mon, 29 Jan 2007 12:03:40 -0500 Received: from mpls-qmqp-03.inet.qwest.net ([63.231.195.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZus-0007Rb-Ls for asrg@ietf.org; Mon, 29 Jan 2007 12:03:40 -0500 Received: from mpls-pop-08.inet.qwest.net (mpls-pop-08.inet.qwest.net [63.231.195.8]) by mpls-qmqp-03.inet.qwest.net (Postfix) with QMQP id 8B819621EF4 for ; Mon, 29 Jan 2007 17:03:34 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-08.inet.qwest.net with SMTP; 29 Jan 2007 17:03:34 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <8C635D7C-D729-4C57-A486-A06E42263B49@qwest.net> From: Dan Oetting Subject: Re: [Asrg] Quarantines and block lists Date: Mon, 29 Jan 2007 10:03:33 -0700 To: Anti Spam Research Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067019770==" Errors-To: asrg-bounces@ietf.org --===============2067019770== Content-Type: multipart/alternative; boundary=Apple-Mail-11-656968434 --Apple-Mail-11-656968434 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed On Jan 29, 2007, at 2:50 AM, Gordon wrote: > [comment #1] Your use of digests indicates that you haven't figured out how to use =20= the mail filtering rules within you own mail reader yet you are =20 pushing for user configured spam filtering?!? Try reading the whole =20 post before responding. The answers to your objections are usually in =20= the same post or have already been answered in the same thread. And =20 speaking of threads, I started this thread without references to =20 other threads so my mail reader would collect all the replies =20 together. Your cross posting from other threads is causing the other =20 replies to get commingled with replies to my thread. I've come to the =20= conclusion that digests should be disbanded. You still haven't =20 figured out that to be spam the email must be not just unwanted but =20 UNSOLICITED. If you don't want SPAM=99 don't order it, there are other =20= choices on the menu ("the ham, eggs sausage and SPAM doesn't have =20 much SPAM in it"). Yahoogroups is a subscription based service. The =20 email you get from Yahoogroups is what you ordered and is not spam. =20 If you don't like the content you can cancel your subscription or =20 close your forwarder. The email that Yahoo receives addressed to =20 their groups might be spam. It is up to Yahoo to filter out the spam =20 if they want to attract subscribers to their groups. It is not the =20 job of any other mail system to edit what yahoo sends to it's =20 subscribers. = --Apple-Mail-11-656968434 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
On Jan 29, 2007, = at 2:50 AM, Gordon wrote:

[comment #1]

<I'm just going to = rant>
Your use of = digests indicates that you haven't figured out how to use the mail = filtering rules within you own mail reader yet you are pushing for user = configured spam filtering?!? Try reading the whole post before = responding. The answers to your objections are usually in the same post = or have already been answered in the same thread. And speaking of = threads, I started this thread without references to other threads so my = mail reader would collect all the replies together. Your cross posting = from other threads is causing the other replies to get=A0commingled with = replies to my thread. I've come to the conclusion that=A0digests=A0should = be disbanded. You still haven't figured out that to be spam the email=A0 = must be not just unwanted but UNSOLICITED. If you don't want SPAM=99 = don't order it, there are other choices on the menu ("the ham, eggs = sausage and SPAM doesn't have much SPAM in it"). Yahoogroups is a = subscription based service. The email you get from Yahoogroups is what = you ordered and is not spam. If you don't like the content you can = cancel your subscription or close your forwarder. The email that Yahoo = receives addressed to their groups might be spam. It is up to Yahoo to = filter out the spam if they want to attract subscribers to their groups. = It is not the job of any other mail system to edit what yahoo sends to = it's subscribers.
<end of rant>
= --Apple-Mail-11-656968434-- --===============2067019770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============2067019770==-- From asrg-bounces@ietf.org Mon Jan 29 15:36:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdB6-0000xz-FP; Mon, 29 Jan 2007 15:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdB5-0000xu-3b for asrg@ietf.org; Mon, 29 Jan 2007 15:32:35 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdB2-0003Se-Q5 for asrg@ietf.org; Mon, 29 Jan 2007 15:32:35 -0500 Received: from world.std.com (iguana@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0TKUvfg000589 for ; Mon, 29 Jan 2007 15:30:59 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0TKUGUY025198; Mon, 29 Jan 2007 15:30:16 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17854.22871.423362.95300@world.std.com> Date: Mon, 29 Jan 2007 15:30:15 -0500 To: asrg@ietf.org In-Reply-To: <20070128113319.GA18862@hjp.at> References: <20070128113319.GA18862@hjp.at> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls5.std.com X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Asrg] How about we do something about spam? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Here's an idea. Let's list a few easy to agree with, egregious, spam (let's not quibble the word I'm just talkin' here) methodologies such as zombie bots in broad terms, outline the harm (undermines faith in the internet as surely as counterfeit money does in currency, fraud, etc), call on all govts of the world (kinda like that guy in "The Day The Earth Stood Still") to not only legislate but to actually FUND enforcement of that legislation with some of the usual dire warnings everyone tosses in with such calls to action (if you don't act decisively CHILDREN WILL DIE!) Wrap that up in an RFC and publish it with a bunch of announcements to the press and some fanfare. I mean, c'mon, the internet is a globalized, probably trillion dollar business and spam is a corruption in that business and needs, as one aspect of its eradication, some doors kicked in and front page photos of miscreants being dragged away in shackles and having their lives wrecked for their efforts. Otherwise it's just a technological parlor game. I believe that govts, not all but ya gotta start somewhere, whose job it is to enforce some reasonable civility and ground rules in the business sphere, await some leadership and we could provide it. If nothing else it's more productive than typing in war stories about RBLs which is kinda like trying to focus a light beam by tossing broken shards of a mirror in the air...likely to cause seven years bad luck as well. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 16:50:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBeMq-0006Hb-FI; Mon, 29 Jan 2007 16:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBeMo-0006HK-QV for asrg@ietf.org; Mon, 29 Jan 2007 16:48:46 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBeMn-0000ir-G3 for asrg@ietf.org; Mon, 29 Jan 2007 16:48:46 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0TLmgA9025207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jan 2007 13:48:42 -0800 In-Reply-To: <17854.22871.423362.95300@world.std.com> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Mon, 29 Jan 2007 13:48:48 -0800 To: Barry Shein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 29, 2007, at 12:30 PM, Barry Shein wrote: > If nothing else it's more productive than typing in war stories > about RBLs which is kinda like trying to focus a light beam by > tossing broken shards of a mirror in the air...likely to cause > seven years bad luck as well. The US Federal government allows bulk sending of unsolicited email. While this is spamming, US law permits it. Providers with customers that are bulk sending unsolicited email must rely upon AUPs to be able to exclude this behavior. Other countries ignore egregious behaviors that might also be seen as possible revenue sources. Effective measures may require international agreements. What rules should be adopted to improve behavior on the Internet? With spam establishing the principle, what is left remains a discussion of price. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 17:35:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBf5f-0002Le-G0; Mon, 29 Jan 2007 17:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBf5d-0002JT-Go for asrg@ietf.org; Mon, 29 Jan 2007 17:35:05 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBf5c-0002sG-7R for asrg@ietf.org; Mon, 29 Jan 2007 17:35:05 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1219454ugd for ; Mon, 29 Jan 2007 14:35:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ikexfwFkirnWheNyeCgr3fY2PXDwuw64HFNoQvxMwq2vvRUOIz4jODiOV0YiM4IesTDUqEwJAWk/4qvDNBN5tLAz2RqE3bcIXtCqICpur8LgolMUq767JdbQ6Nr9lPPaH/aRXg89fMXpKbWvRx0Es1DHjcuDjeYCd22maUcOTsU= Received: by 10.82.136.4 with SMTP id j4mr2825173bud.1170110103086; Mon, 29 Jan 2007 14:35:03 -0800 (PST) Received: by 10.78.23.19 with HTTP; Mon, 29 Jan 2007 14:35:02 -0800 (PST) Message-ID: <934f64a20701291435k9de8128qfc78bf00ca76a618@mail.gmail.com> Date: Mon, 29 Jan 2007 16:35:02 -0600 From: "David Nicol" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 In-Reply-To: <20070128220610.GE18862@hjp.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17846.26016.14436.541196@world.std.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> <20070128220610.GE18862@hjp.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/28/07, Peter J. Holzer wrote: > On 2007-01-28 21:24:33 +0100, Frank Ellermann wrote: > > Peter J. Holzer wrote: > > > David Nicol's DATAFIRST proposal. > > [...] > > I'm not interested in DATAFIRST. I'm interested in returning > per-recipient results to DATA. they aren't mutually exclusive. Nobody is saying they are, but someone who does not realize that they aren't might think that they are, and that there is some kind of dispute, where there isn't. > > What I didn't like in draft-hall-inline-dsn was the sequence of > > per recipient responses after DATA matching the sequence of RCPT > > before DATA. > > That's what the proposal is about. It allows several return codes for > DATA. The exact mechanism might be different (for example, there could > be a multiline-response instead of multiple single-line responses, or > the return codes can be matched by address instead of order), but these > are minor changes. the one request, one response model is crucial to SMTP servers -- you can write a smtp server that essentially does smtp_connect; while (accept and fork){ send_smtp("EHLO blah blah blah"); send_smtp(craft_smtp_response(receive_smtp())) while 1; }; and multiple response lines makes that no longer work; or means that the receive_smtp() has to have a lot more data in it than if we are reading a data block or not. so if the ordering is important, maintain it; how about a big response that is a well-defined XML block? _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 17:53:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfMJ-0006Hs-JU; Mon, 29 Jan 2007 17:52:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfMI-0006Hf-HB for asrg@ietf.org; Mon, 29 Jan 2007 17:52:18 -0500 Received: from pcls6.std.com ([192.74.137.146] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfMD-0006lx-RT for asrg@ietf.org; Mon, 29 Jan 2007 17:52:18 -0500 Received: from world.std.com (iguana@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0TMn47P016994; Mon, 29 Jan 2007 17:49:07 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0TMmjGZ025439; Mon, 29 Jan 2007 17:48:45 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17854.31180.793466.939378@world.std.com> Date: Mon, 29 Jan 2007 17:48:44 -0500 To: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls6.std.com X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls6.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: asrg@ietf.org, Barry Shein X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On January 29, 2007 at 13:48 dotis@mail-abuse.org (Douglas Otis) wrote: > The US Federal government allows bulk sending of unsolicited email. To be precise the "US Federal government" allows nothing specifically in this realm. There are activities which are expressly or by implication of law illegal or subject to regulatory or civil limitations. If you know of a US law which says "you can send unsolicited email", other than by implication of the absence of any express prohibition, I would be interested in seeing a reference to that law or similar. That said, much noxious email is sent via computers which have been in effect "hijacked" by use of viruses, trojans and other malicious software. These are often called "zombie botnets", a commonplace term of art which could be more precisely defined, and I referred to them specifically in the email to which you are responding but you elided that phrasing in your response. Creating or exploiting "zombie spambot" behavior is illegal in the US and elsewhere, and has been occasionally prosecuted. The problem, thus far, has been lack of enforcement. > While this is spamming, US law permits it. Providers with customers > that are bulk sending unsolicited email must rely upon AUPs to be > able to exclude this behavior. Other countries ignore egregious > behaviors that might also be seen as possible revenue sources. Such countries might exist, perhaps de facto, but their intention, e.g., for the revenue sources, as you claim, versus a simple lack of prioritization of enforcement activities is unclear. If you know of any country which has expressly stated in a policy, memo, legislation, or other publicly memorialized statement what you claim above I'm sure it would be edifying to this group. I personally know of no such document and as such where you claim the lack of expressed intent, policy, or judgement as intentioned I will claim that same silence as mere negligence and the intent as quite the opposite. Otherwise I have to assume your statement is a purely speculative inference into the /mens rea/ of more than one nation (you use the plural) whom you do not even list. Could you at least provide an even partial list of these nations whose intentions you are relating? Better would be the specifics you base your claims upon. > Effective measures may require international agreements. What rules This is a weak attempt to make the best the enemy of the good. Nations, as a rule, have legal sovereignty over their own citizenry. There is no need for international agreement to enforce a nation's own laws on their own citizens. If a citizen of a country is breaking that nations' laws, such as fraud or electronic trespass, even if the act is not ultimately within that nation, they would have legitimate claim to first juridiction in any criminal, regulatory, or similar matter, generally by exercise of long-arm statutes or limitations thereof. Where there might be exceptions they could be dealt with in the future as a refinement of the proposed action. Thus, making the best the enemy of the good. I reject the proposition that because there might be some case which requires more broad and as yet non-existant powers to prosecute that therefore we must not encourage the prosecution of behaviors which easily fall within the current purview of each nations' sovereignty. That, to repeat, is merely an attempt to make the best the enemy of the good which is a highly undesireable goal. > should be adopted to improve behavior on the Internet? With spam > establishing the principle, what is left remains a discussion of price. Lawful nations recognize a duty to enforce their laws, particularly as they relate to their own citizenry's behavior. The mere existance of unlawful nations does not argue against that point. There is nothing new or unusual about criminal fraud, trespass, vandalism, or similar which may arguably cross international boundaries whether it involves postal, telephony, telegraphy, wire transfer, internet, or other means. My suggestion was simply a suggestion that we produce a document ultimately issued by the IETF urging more effective enforcement of laws as they stand. Whether further refinement would help is a separate matter and unnecessary a priori, even if a desireable goal. Sufficient unlawful behaviors enable "spam", such as zombie botnets, that it would be progress to simply make a public request that the laws (&c) prohibiting those behaviors be better enforced. Absence explicit substantiation of your claims I consider your point of view purely speculative, and not meriting further discussion. But by all means provide detail as suggested. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Jan 29 18:02:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfWD-0000PB-JV; Mon, 29 Jan 2007 18:02:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfWD-0000Ok-1G for asrg@ietf.org; Mon, 29 Jan 2007 18:02:33 -0500 Received: from morbo.e-centre.net ([66.154.82.3] helo=cubert.e-centre.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBfWB-0002GW-K5 for asrg@ietf.org; Mon, 29 Jan 2007 18:02:32 -0500 Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1HBfW4-00080k-F0 for asrg@ietf.org; Mon, 29 Jan 2007 18:02:25 -0500 X-ASG-Debug-ID: 1170111626-29511-53-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from [172.30.1.148] (207.47.33.7.static.nextweb.net [207.47.33.7]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 294A381C249 for ; Mon, 29 Jan 2007 18:00:26 -0500 (EST) Message-ID: <45BE7C8A.30400@nortel.com> Date: Mon, 29 Jan 2007 18:00:26 -0500 From: Chris Lewis User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org X-ASG-Orig-Subj: Re: [Asrg] Quarantines and block lists Subject: Re: [Asrg] Quarantines and block lists References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.69 X-Barracuda-Spam-Status: No, SCORE=0.69 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests=BSF_RULE7568M, MISSING_HEADERS X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.32550 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.19 MISSING_HEADERS Missing To: header 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gep2@terabites.com wrote: > [comment #1] > >> Subject: Re: [Asrg] Quarantines and block lists > >> Lost Email is any email that is sent but not presented to the user >> and does not generate a DSN to the sender. > > The problem is, in the case of spam as in the case of viruses or worms, > determining WHO the TRUE sender actually is. It is safe to presume that > it often is NOT the person listed in the From: header. > > Therefore, I think we should note under "good practices" that it is NOT > "good practice" to return ANY indication (after the original SMTP-time, > and thus it's pretty much limited anyhow to just going back 'one' level) > regarding mail blocked either as spam, or mail blocked because it > contains worms or viruses. In both cases, I believe we MUST presume > that the true sender will not be accurately determinable. To send ANY > kind of a bounce message back is likely to create more harm than good, > probably just haranguing another innocent third party. If you're doing your spam filtering at the front end, and ALWAYS do filter hits as inline rejections, then this isn't an issue. [Yes, there is a small amount of spam going thru "real" MTAs that produce blowback in such a case. But this is so rare these days to not be a concern. We're averaging less than a complaint a year about misdirected NDRs (at 1.6M rejected per day). But obviously, you can't do that in the UA. Therefore, with UA-level filtering, you _cannot_ provide valid feedback to legitimate senders unless you tolerate unacceptable levels of collateral damage. As sender feedback is critical as a counter-FP measure in most environments, you're completely screwed if you insist on UA-level filtering. Sender feedback is fundamentally incompatible with UA-level filtering. > The point is that NON-spamtrap addresses get mail through Yahoogroups, > and where you can't tell much or anything about where the E-mail > actually originated. So do you block Yahoogroups servers by IP address? No, why would you have to? But you can, if you wish, use X-Originating-IP (or analogous headers). > And if you don't do anything about Yahoogroups-forwarded spam, then > you're leaving a gaping hole through which a large quantity of spam can > be sent. Using DNSBLs doesn't require you to "don't do anything about Yahoogroups-forwarded" spam. > Again, IP-based detection blocking is nowhere close to viable for such > cases. So what? > I know that a lot of folks here seem to have a strong emotional > commitment to the basic concept of IP-based blocking, but as unpleasant > as it is to accept, that is simply NOT a very good approach. It's an excellent approach when used correctly. Using it _alone_ and expecting it to work acceptably on _all_ circumstances is not using it correctly. As is any other filtering technique. I have a strong commitment to _effective_ and reliable filtering. DNSBLs provide part of that answer. Other methods provide plug the holes, complement DNSBLS, and deal with things that the DNSBLs can't (or haven't yet) caught. 10 years ago we started with content filters only, and could only do extremely limited amounts of IP-based blocking. As of 2001, that had simply become totally inadequate. These days it's about 90% DNSBL, and 10% content. > That's one reason why it's SO critical to put the kibosh on viruses and > worms that recruit the spambot armies... that makes it harder to proxy > the spam transmissions and diversify the origin points. Slamming the > door on HTML and attachments from unknown senders puts a MAJOR brake on > that, literally overnight, and in a way that is very difficult to > circumvent in any widespread way. a) it really doesn't put the brakes on. Think bare text with the appropriate human engineering and links. b) slamming the doors on html and attachments from even unknown senders has a vastly higher FP rate than anything else with "normal" ISP flows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb58ip3FmCyJjHfhAQKQagQAqFX3ltddAapiJSqGzUzWB7E2I+MUEAfa vyANp7DeYr03B4Riff6SacbUJlOcPts2KtMcVdqXrkVFuMR1IjvE7ZLHZAauhJki FhSlg5BHYHme1fr57KOQDVTw6L4dcGz9R1+PFNc3tKDPz2bnHxLzCClxUhaDrQFp aZKWp9TmcAU= =2q0x -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 00:51:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBloq-0004N5-B3; Tue, 30 Jan 2007 00:46:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlop-0004N0-D7 for asrg@ietf.org; Tue, 30 Jan 2007 00:46:11 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBloo-0000MB-Qy for asrg@ietf.org; Tue, 30 Jan 2007 00:46:11 -0500 Received: from [10.2.165.137] (net-office-sjc.mail-abuse.org [168.61.0.42]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0U5k79v002180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jan 2007 21:46:08 -0800 In-Reply-To: <17854.31180.793466.939378@world.std.com> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Mon, 29 Jan 2007 21:46:11 -0800 To: Barry Shein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 29, 2007, at 2:48 PM, Barry Shein wrote: > On January 29, 2007 at 13:48 dotis@mail-abuse.org (Douglas Otis) > wrote: >> The US Federal government allows bulk sending of unsolicited email. > > To be precise the "US Federal government" allows nothing > specifically in this realm. There are activities which are > expressly or by implication of law illegal or subject to regulatory > or civil limitations. ,--- |CAN-SPAM Act of 2003: |SEC. 3. DEFINITIONS. |(16) SENDER- | (A) IN GENERAL- Except as provided in subparagraph (B), | the term `sender', when used with respect to a commercial | electronic mail message, means a person who initiates | such a message and whose product, service, or Internet | web site is advertised or promoted by the message. | | (B) SEPARATE LINES OF BUSINESS OR DIVISIONS- If an entity | operates through separate lines of business or divisions | and holds itself out to the recipient throughout the | message as that particular line of business or division | rather than as the entity of which such line of business | or division is a part, then the line of business or the | division shall be treated as the sender of such message | for purposes of this Act. |... | (5) INCLUSION OF IDENTIFIER, OPT-OUT, AND PHYSICAL ADDRESS | IN COMMERCIAL ELECTRONIC MAIL- (A) It is unlawful for any | person to initiate the transmission of any commercial | electronic mail message to a protected computer _unless_ | the message provides-- | (i) clear and conspicuous identification that the message | is an advertisement or solicitation; | (ii) clear and conspicuous notice of the opportunity under | paragraph (3) to decline to receive further commercial | electronic mail messages from the sender; and | (iii) a valid physical postal address of the sender. '___ OPT-OUT allows 10 days before messages related to a line of business must stop. Prior to receiving the OPT-OUT request, email-addresses can be exchanged with other entities. Valid domain names, lines of businesses, and physical addresses can change every 10 days and remain within the guidelines of the CAN-SPAM act, even when each spam does obtain an OPT-OUT request. This act is specifically allowing the bulk sending of unsolicited email and demands recipients to stop the abuse which may continue unabated for 10 days. Following that point in time, a new entity can carry forward the abuse. > If you know of a US law which says "you can send unsolicited > email", other than by implication of the absence of any express > prohibition, I would be interested in seeing a reference to that > law or similar. The key word here is "unless". > That said, much noxious email is sent via computers which have been > in effect "hijacked" by use of viruses, trojans and other malicious > software. The same noxious email can be sent in bulk legally from non-hijacked computers. It is hard to know which SMTP clients have been hijacked via malware. > These are often called "zombie botnets", a commonplace term of art > which could be more precisely defined, and I referred to them > specifically in the email to which you are responding but you > elided that phrasing in your response. > > Creating or exploiting "zombie spambot" behavior is illegal in the > US and elsewhere, and has been occasionally prosecuted. The > problem, thus far, has been lack of enforcement. It is much easier to detect when a computer is sending bulk unsolicited emails. The problem is rather simple. When it is legal to send bulk unsolicited bulk email, spamming fails to provide actionable evidence of a crime. >> While this is spamming, US law permits it. Providers with >> customers that are bulk sending unsolicited email must rely upon >> AUPs to be able to exclude this behavior. Other countries ignore >> egregious behaviors that might also be seen as possible revenue >> sources. > > Such countries might exist, perhaps de facto, but their intention, > e.g., for the revenue sources, as you claim, versus a simple lack > of prioritization of enforcement activities is unclear. When one country bombards another and calls the spam traffic legal, this may tend to diminish a level of cooperation in other areas. > If you know of any country which has expressly stated in a policy, > memo, legislation, or other publicly memorialized statement what > you claim above I'm sure it would be edifying to this group. There are several countries that offer an undesirable level of cooperation. One such country is the USA. > I personally know of no such document and as such where you claim > the lack of expressed intent, policy, or judgement as intentioned I > will claim that same silence as mere negligence and the intent as > quite the opposite. Review the CAN-SPAM Act of 2003. > Otherwise I have to assume your statement is a purely speculative > inference into the /mens rea/ of more than one nation (you use the > plural) whom you do not even list. Could you at least provide an > even partial list of these nations whose intentions you are > relating? Better would be the specifics you base your claims upon. One should not point to others, when at least three fingers point back toward yourself. >> Effective measures may require international agreements. > > This is a weak attempt to make the best the enemy of the good. When talking about spam, it is hard to describe a law that permits spam as being even within the realm of being good. > Nations, as a rule, have legal sovereignty over their own > citizenry. There is no need for international agreement to enforce > a nation's own laws on their own citizens. The Internet requires a level of cooperation between different countries, as network related crime easily extends beyond geographic boundaries. > If a citizen of a country is breaking that nations' laws, such as > fraud or electronic trespass, even if the act is not ultimately > within that nation, they would have legitimate claim to first > juridiction in any criminal, regulatory, or similar matter, > generally by exercise of long-arm statutes or limitations thereof. We are not talking about what is illegal, but what is consider legal, but damaging. > Where there might be exceptions they could be dealt with in the > future as a refinement of the proposed action. Thus, making the > best the enemy of the good. What proposed action? This is a problem of _no_ action. > I reject the proposition that because there might be some case > which requires more broad and as yet non-existant powers to > prosecute that therefore we must not encourage the prosecution of > behaviors which easily fall within the current purview of each > nations' sovereignty. Each country is not independent with respect to the Internet. While each router falls within the purview of each owner, cooperation among owners must be sustained for the network to function. > That, to repeat, is merely an attempt to make the best the enemy of > the good which is a highly undesireable goal. I think you mean some ridiculous set of guidelines that prescribe how to send bulk unsolicited email is the enemy of practical protections. There is no practical means to know whether a computer is spamming due to malware. We both agree that BOTs have become a serious problem. Ask good citizens via laws to stop spamming and focus attention on those that continue. >> What rules should be adopted to improve behavior on the Internet? >> With spam establishing the principle, what is left remains a >> discussion of price. > > Lawful nations recognize a duty to enforce their laws, particularly > as they relate to their own citizenry's behavior. The mere > existance of unlawful nations does not argue against that point. The principles of behavior are compromised when resources are abused for unfair, unsafe, and impractical promotion just to make a buck. > There is nothing new or unusual about criminal fraud, trespass, > vandalism, or similar which may arguably cross international > boundaries whether it involves postal, telephony, telegraphy, wire > transfer, internet, or other means. The subject line is about spam. Trespassing and vandalism are clearly poorly considered by the CAN-SPAM Act of 2003. > My suggestion was simply a suggestion that we produce a document > ultimately issued by the IETF urging more effective enforcement of > laws as they stand. These laws must change. One can not start with the premise that spamming is okay provided there is some method to opt-out. > Whether further refinement would help is a separate matter and > unnecessary a priori, even if a desireable goal. Sufficient > unlawful behaviors enable "spam", such as zombie botnets, that it > would be progress to simply make a public request that the laws > (&c) prohibiting those behaviors be better enforced. Knowing what is a due to malware and what is legal can not be determined as long as spamming remains legally sanctioned. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 02:31:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnQU-0004uU-5G; Tue, 30 Jan 2007 02:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnQS-0004u5-Pl for asrg@ietf.org; Tue, 30 Jan 2007 02:29:08 -0500 Received: from pcls6.std.com ([192.74.137.146] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBnQP-0000Ys-TE for asrg@ietf.org; Tue, 30 Jan 2007 02:29:08 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0U7Sv20002608 for ; Tue, 30 Jan 2007 02:28:59 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0U7SvCn010315; Tue, 30 Jan 2007 02:28:57 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17854.62393.356114.929389@world.std.com> Date: Tue, 30 Jan 2007 02:28:57 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls6.std.com X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls6.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I was thinking of something like this (sketchy outline, any use of "spam" is simply short-hand for "Insert Better Term"): Spam (definition) currently comprises over 90% (cite) of email traffic. The enabling technology for the vast majority of spam are botnets (description.) Botnets are particularly problematic because: a) They allow spammers to command far more resources for sending spam than the underlying business activity could ever fund; the resources used are all stolen. Literally hundreds of millions of copies of a message can be sent out for little or no cost to the spammer. b) They allow for address mobility; spam sources can shift between thousands of purloined computers rapidly thus defeating identification of the source of the spam for the purpose of blocking or, where warranted, criminal investigation. c) They are a fundamentally criminal enterprise relying on the injection and exploitation of malicious software into victim computers. Although technological schemes are constantly being developed to counter this trend there are limits to the effectiveness of these schemes without a framework of effective law enforcement. The sheer volume and nature of botnet spamming activity, largely unchallenged legally, presents a problem which even a reasonably effective technological solution can not counter. It is likely that absent these botnets spammers as we know them would be rendered largely impotent. As stated earlier their business model does not allow for the enormous resources we see their activities currently consume. Investigation, apprehension, and conviction of operators and customers of these botnets are few and far between. They operate with little fear of legal consequence currently. We therefore request, as a body whose primary mission is the reliability, integrity, and advancement of the internet, increased law enforcement resources be devoted to providing an effective legal challenge to these botnets as an adjunct to our own technological efforts. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 07:26:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBs12-0003K2-Rw; Tue, 30 Jan 2007 07:23:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBs11-0003Jv-2q for asrg@ietf.org; Tue, 30 Jan 2007 07:23:11 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBs0z-0005YC-QJ for asrg@ietf.org; Tue, 30 Jan 2007 07:23:11 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0UCN5AJ023852 for ; Tue, 30 Jan 2007 07:23:05 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0UCN4RS023830; Tue, 30 Jan 2007 07:23:05 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0UCN4nE013047; Tue, 30 Jan 2007 07:23:04 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0UCN0Om013040; Tue, 30 Jan 2007 07:23:00 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 30 Jan 2007 07:23:00 -0500 (EST) From: Daniel Feenberg To: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: Message-ID: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: asrg@ietf.org, Barry Shein X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 29 Jan 2007, Douglas Otis wrote: > > On Jan 29, 2007, at 2:48 PM, Barry Shein wrote: > >> On January 29, 2007 at 13:48 dotis@mail-abuse.org (Douglas Otis) wrote: >>> The US Federal government allows bulk sending of unsolicited email. >> >> To be precise the "US Federal government" allows nothing specifically in >> this realm. There are activities which are expressly or by implication of >> law illegal or subject to regulatory or civil limitations. > > ,--- > |CAN-SPAM Act of 2003: > |SEC. 3. DEFINITIONS. > |(16) SENDER- > | (A) IN GENERAL- Except as provided in subparagraph (B), > | the term `sender', when used with respect to a commercial > | electronic mail message, means a person who initiates > | such a message and whose product, service, or Internet > | web site is advertised or promoted by the message. > | > | (B) SEPARATE LINES OF BUSINESS OR DIVISIONS- If an entity > | operates through separate lines of business or divisions > | and holds itself out to the recipient throughout the > | message as that particular line of business or division > | rather than as the entity of which such line of business > | or division is a part, then the line of business or the > | division shall be treated as the sender of such message > | for purposes of this Act. > |... > | (5) INCLUSION OF IDENTIFIER, OPT-OUT, AND PHYSICAL ADDRESS > | IN COMMERCIAL ELECTRONIC MAIL- (A) It is unlawful for any > | person to initiate the transmission of any commercial > | electronic mail message to a protected computer _unless_ > | the message provides-- > | (i) clear and conspicuous identification that the message > | is an advertisement or solicitation; > | (ii) clear and conspicuous notice of the opportunity under > | paragraph (3) to decline to receive further commercial > | electronic mail messages from the sender; and > | (iii) a valid physical postal address of the sender. > '___ > While I agree that this provision represents an amazing lack of spine on the part of the congress, it isn't as though I get any spam that conforms to all three of these identifiers. In fact, no more than a couple of percent include even one (usually (i)). So this provision does not yet represent a barrier to anti-spam activity. No doubt if the FTC or DOJ took some action against US based spammers, they would make hast to conform to the law, but that hasn't happened yet. And nothing in the law interferes with private action to reject messages, spam or not. Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 07:35:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsCr-0000Ja-W7; Tue, 30 Jan 2007 07:35:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsCr-0000IC-4n for asrg@ietf.org; Tue, 30 Jan 2007 07:35:25 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBsCo-0000FQ-RC for asrg@ietf.org; Tue, 30 Jan 2007 07:35:25 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0UCZIeN027812 for ; Tue, 30 Jan 2007 07:35:18 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0UCZIrh027794; Tue, 30 Jan 2007 07:35:18 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0UCZHnE014344; Tue, 30 Jan 2007 07:35:17 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0UCZHRM014341; Tue, 30 Jan 2007 07:35:17 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 30 Jan 2007 07:35:17 -0500 (EST) From: Daniel Feenberg To: Barry Shein Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <17854.62393.356114.929389@world.std.com> Message-ID: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 30 Jan 2007, Barry Shein wrote: > > I was thinking of something like this (sketchy outline, any use of > "spam" is simply short-hand for "Insert Better Term"): > > > Spam (definition) currently comprises over 90% (cite) of email > traffic. > > The enabling technology for the vast majority of spam are botnets > (description.) > > Botnets are particularly problematic because: > > a) They allow spammers to command far more resources for sending > spam than the underlying business activity could ever fund; the > resources used are all stolen. Literally hundreds of millions of > copies of a message can be sent out for little or no cost to the > spammer. > > b) They allow for address mobility; spam sources can shift between > thousands of purloined computers rapidly thus defeating > identification of the source of the spam for the purpose of blocking > or, where warranted, criminal investigation. > > c) They are a fundamentally criminal enterprise relying on the > injection and exploitation of malicious software into victim > computers. > ... Isn't the solution to decline ALL mail from obvious pool addresses? I hear the argument that you can't put pool addresses in a DNSBL because next week the bot will have a different address. So put the whole pool in the BDSBL. Again, I hear the argument that a legitimate MTA may get the address next. In our tests last year we didn't find any legitimate correspondes (to us) behind pool addresses. I hesitate to say so, but isn't much of the noise from critics of blocking pool addresses from self=styled political revolutionaries and paedophiles who (mistakenly) think that the FBI won't read mail if it doesn't travel through the ISP MTA? As for the operators who claim that their ISP MTA is slow, can't those handfull of malcontents just get another smarthost? (see http://www.nber.org/sys-admin/smarthost.html ) I'd be willing to do without their messages in the meantime. Looking at my after-Spamhaus connecting MTAs, virtually all are pool addresses, or no reverse name lookup. Do other MTAs get legitimate mail from pool addresses? Spamhaus has just last week started to offer a listing of dynamic addresses, but it is only mildly effective so far. But so far no FPs, either. Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 10:59:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvNM-0001di-B4; Tue, 30 Jan 2007 10:58:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvNL-0001dZ-HV for asrg@ietf.org; Tue, 30 Jan 2007 10:58:27 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvNF-00053U-V4 for asrg@ietf.org; Tue, 30 Jan 2007 10:58:27 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0UFwJ407396 for ; Tue, 30 Jan 2007 10:58:19 -0500 (EST) Received: from [47.9.28.33] ([47.9.28.33] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 10:58:19 -0500 Message-ID: <45BF6B18.2000308@nortel.com> Date: Tue, 30 Jan 2007 10:58:16 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2007 15:58:19.0362 (UTC) FILETIME=[75F51C20:01C74487] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Feenberg wrote: > Isn't the solution to decline ALL mail from obvious pool addresses? I > hear the argument that you can't put pool addresses in a DNSBL because > next week the bot will have a different address. So put the whole pool > in the BDSBL. Again, I hear the argument that a legitimate MTA may get > the address next. In our tests last year we didn't find any legitimate > correspondes (to us) behind pool addresses. I hesitate to say so, but > isn't much of the noise from critics of blocking pool addresses from > self=styled political revolutionaries and paedophiles who (mistakenly) > think that the FBI won't read mail if it doesn't travel through the ISP > MTA? As for the operators who claim that their ISP MTA is slow, can't > those handfull of malcontents just get another smarthost? (see > http://www.nber.org/sys-admin/smarthost.html ) I'd be willing to do > without their messages in the meantime. > > Looking at my after-Spamhaus connecting MTAs, virtually all are pool > addresses, or no reverse name lookup. Do other MTAs get legitimate mail > from pool addresses? Spamhaus has just last week started to offer a > listing of dynamic addresses, but it is only mildly effective so far. > But so far no FPs, either. [Aside: the PBL (Spamhaus's "policy blacklist", which is essentially the same as "pool addresses" was pre-primed with NJABL dynablock and has been growing since. That is _not_ "mildly effective". See http://www.sdsc.edu/~jeff/spam/cbc.html] In the large scale the difficulty is identifying what's a "pool". One effort to determine that in terms of rDNS names is called "Enemies List" (aka "EL") - which is some 15,000 regexes. That's 3 years of accumulated knowledge by the guy who runs it. Many ISPs aren't good at naming of pools and properly renaming them when the machine becomes "non-generic", or placing non-pool in the middle of pools. So there is always a significant problem with non-poolish machines having poolish names. There's a substantial number of providers who don't understand that naming their servers (mail or otherwise) something other than 1.2.4.5.example.com is bad. An effort to RFCize (probably BCP) naming conventions has been going on for quite some time by one "lone crusader", but unfortunately, _even_ on the anti-spam side where they'd really love to see it, it's long been dismissed as foolishly naive and will never happen. EL and PBL/dynablock _work_ rather well. But, don't kid yourself, there are FPs with it. It isn't a solution per-se, perhaps best demonstrated that despite how good they are, the XBL still does better. The problem isn't just pool addresses, much as it isn't just other subsets. Even if it were "the solution", the PBL with something like 5-6 years of accumulated "pool addresses" behind it (from many many sources) should demonstrate that it's no easy task. Pool listings are _frightfully_ expensive in man-hours to maintain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb9rF53FmCyJjHfhAQJdnQP9E/fAOm6BCZcjNuDDWArJMCxfN3xswKJx H4+a95UR576nZGiQRnZJzg8XvnqJw8dcZkv/IMNZSTrw1Oz2IBZqTSQ2NNfSZmCH ZLGNYhY+osN4Lj18lq0ujUsbXVc0qrmp8Iu6AcrBE1fD1qLNSUSwjvdRjDe6jlXK IxvNIqAV3yU= =ywLI -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 10:59:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvLK-00082w-W7; Tue, 30 Jan 2007 10:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvLJ-00082q-Ma for asrg@ietf.org; Tue, 30 Jan 2007 10:56:21 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvLI-0004Um-B6 for asrg@ietf.org; Tue, 30 Jan 2007 10:56:21 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0UFuJJI011830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Jan 2007 07:56:19 -0800 Subject: Re: [Asrg] How about we do something about spam? From: Douglas Otis To: Daniel Feenberg In-Reply-To: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> Content-Type: text/plain Date: Tue, 30 Jan 2007 07:56:19 -0800 Message-Id: <1170172579.3123.37.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: asrg@ietf.org, Barry Shein X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 2007-01-30 at 07:23 -0500, Daniel Feenberg wrote: > > While I agree that this provision represents an amazing lack of spine on > the part of the congress, it isn't as though I get any spam that conforms > to all three of these identifiers. In fact, no more than a couple of > percent include even one (usually (i)). So this provision does not yet > represent a barrier to anti-spam activity. No doubt if the FTC or DOJ took > some action against US based spammers, they would make hast to conform to > the law, but that hasn't happened yet. And nothing in the law interferes > with private action to reject messages, spam or not. The mere fact that a computer is spamming is not automatically a violation of the law that would permit an order to stop. There are some spammers giving the appearance of following these guidelines, in some cases even making it difficult for providers with poor AUP to stop their traffic. Expecting private individuals to ignore this traffic represents a fundamental lack of international cooperation. This act also removes an ability for private citizens to seek compensation. Without official action of enforcement, nothing happens. As there is seldom any financial incentive to take action, spam officially has been made into something that everyone is expected to endure. Attempting to enforce the act will just make it more difficult recognize legitimate messages, but spamming will continue. So why bother? Marking messages, just as with the Do Not Spam list, is another concept that appears to have been dropped from the act as well. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:13:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwVV-0004VZ-Eb; Tue, 30 Jan 2007 12:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwVU-0004VP-AV for asrg@ietf.org; Tue, 30 Jan 2007 12:10:56 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwVT-0003YB-4P for asrg@ietf.org; Tue, 30 Jan 2007 12:10:56 -0500 Received: by wr-out-0506.google.com with SMTP id 55so1694918wri for ; Tue, 30 Jan 2007 09:10:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kpRO/HfUYBInVlNrxbMFIfBcSSBwml8XHD7KvuHIvZ+64ombloPEmKlr8grPCZiVqMMWNF785sNpqYxm/HEXpAFMLGVs+0Odrxg9blh6yDNtgTa4nM+CviIkjDA8eQp/VjJhBUgrAEjQRkYQHG5TG8BHl1zsPI9RrRB2G++0lcQ= Received: by 10.78.185.7 with SMTP id i7mr4821856huf.1170177053657; Tue, 30 Jan 2007 09:10:53 -0800 (PST) Received: by 10.78.23.19 with HTTP; Tue, 30 Jan 2007 09:10:53 -0800 (PST) Message-ID: <934f64a20701300910t1064e77of2e0e3d794cb1f20@mail.gmail.com> Date: Tue, 30 Jan 2007 11:10:53 -0600 From: "David Nicol" To: "anti-spam research group" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Asrg] shipnow X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org i presume that nothing is required of me for thursday's hearing. David _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:39:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwh-0002Bh-SY; Tue, 30 Jan 2007 12:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwf-00028o-7H for asrg@ietf.org; Tue, 30 Jan 2007 12:39:01 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwsn-00030P-TF for asrg@ietf.org; Tue, 30 Jan 2007 12:35:03 -0500 Received: from mpls-pop-02.inet.qwest.net (mpls-pop-02.inet.qwest.net [63.231.195.2]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id 9E53353BD9D for ; Tue, 30 Jan 2007 17:35:01 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-02.inet.qwest.net with SMTP; 30 Jan 2007 17:35:01 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] How about we do something about spam? Date: Tue, 30 Jan 2007 10:34:59 -0700 To: Anti Spam Research Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 30, 2007, at 5:35 AM, Daniel Feenberg wrote: > Isn't the solution to decline ALL mail from obvious pool addresses? Would it help to have a wiki for Asrg? Somewhere that each concept can exist in it's own space spanning time so it doesn't have to be brought up over and over and rehashed with all the same arguments. The wiki would be a useful group resource to list what has been tried and how it succeeded or failed. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:39:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwo-0002Ed-IS; Tue, 30 Jan 2007 12:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwm-0002D6-Tn for asrg@ietf.org; Tue, 30 Jan 2007 12:39:08 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwrz-0002fc-MX for asrg@ietf.org; Tue, 30 Jan 2007 12:34:13 -0500 Received: from [207.65.71.19] (pool-71-252-110-214.washdc.east.verizon.net [71.252.110.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 29E383F8C9 for ; Tue, 30 Jan 2007 11:34:11 -0600 (CST) Message-ID: <45BF8177.8090906@ehsco.com> Date: Tue, 30 Jan 2007 12:33:43 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> In-Reply-To: <20070127042237.GA24125@zardoc.esmtp.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/26/2007 11:22 PM, Claus Assmann wrote: > [[Is this the appropriate list to discuss this topic?]] I would imagine that ietf-smtp@imc.org is the right place to talk about the protocol, particularly if its going to be advocated for standards track, but I'll deal with questions where I find them > 1. the name is confusing and the new name isn't very helpful either. > Let's call it something like "Delayed-RCPT-Status" (DRS) or > "RCPT-Status-After-Dot" (RSAD). deferred-rcpt-responses would be most descriptive but that's a bit greedy given that command-line space is fixed. I don't really care what people call it. Robots will be the 99.9999% use case and they won't care either. Probably some kind of acronym like DRR or whatever would be most efficient as far as that goes. Best outcome I can see here is for a plurality of implementors to request a specific name. Otherwise we are all going to be wanting our pet name so any name is as bad as any other. > 2. This is another confusing part: > > 6. The End-of-Data Response Codes > 6.1. The 352 Response Code > 6.2. The 353 Response Code > 6.3. The Per-Recipient Response Codes > 6.4. The Final Response Code > > My understanding is: > 352 is used for RCPT: > 6.1. The 352 Response Code > > The 352 response code is used by a server to indicate that the > mailbox address specified in the associated RCPT TO command > ^^^^ > > 353 is used for end of data. > > So it should be: > > 6. Additional RCPT Response Code > 6.1. The 352 Response Code > 7. The End-of-Data Response Codes > 7.1. The 353 Response Code > 7.2. The Per-Recipient Response Codes > 7.3. The Final Response Code > > > BTW: it probably should be > 7. The End of Mail Data Response Codes > to match RFC 2821. I changed the section 6 heading in the current draft. The additional breakdown looks reasonable and appropriate so I'll do that in the next edition if there's any real interest in pursuing this further. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:39:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwh-0002B7-CZ; Tue, 30 Jan 2007 12:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwwe-00028o-Sr for asrg@ietf.org; Tue, 30 Jan 2007 12:39:00 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwtB-00032s-Lt for asrg@ietf.org; Tue, 30 Jan 2007 12:35:27 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0UHZKCF030189 for ; Tue, 30 Jan 2007 12:35:21 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0UHZFCu030102; Tue, 30 Jan 2007 12:35:19 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0UHZFnE016598; Tue, 30 Jan 2007 12:35:15 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0UHZAWX016595; Tue, 30 Jan 2007 12:35:14 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 30 Jan 2007 12:35:10 -0500 (EST) From: Daniel Feenberg To: Chris Lewis Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <45BF6B18.2000308@nortel.com> Message-ID: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 30 Jan 2007, Chris Lewis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Feenberg wrote: > >> Isn't the solution to decline ALL mail from obvious pool addresses? I >> hear the argument that you can't put pool addresses in a DNSBL because >> next week the bot will have a different address. So put the whole pool >> in the BDSBL. Again, I hear the argument that a legitimate MTA may get >> the address next. In our tests last year we didn't find any legitimate >> correspondes (to us) behind pool addresses. I hesitate to say so, but >> isn't much of the noise from critics of blocking pool addresses from >> self=styled political revolutionaries and paedophiles who (mistakenly) >> think that the FBI won't read mail if it doesn't travel through the ISP >> MTA? As for the operators who claim that their ISP MTA is slow, can't >> those handfull of malcontents just get another smarthost? (see >> http://www.nber.org/sys-admin/smarthost.html ) I'd be willing to do >> without their messages in the meantime. >> >> Looking at my after-Spamhaus connecting MTAs, virtually all are pool >> addresses, or no reverse name lookup. Do other MTAs get legitimate mail >> from pool addresses? Spamhaus has just last week started to offer a >> listing of dynamic addresses, but it is only mildly effective so far. >> But so far no FPs, either. > > [Aside: the PBL (Spamhaus's "policy blacklist", which is essentially the > same as "pool addresses" was pre-primed with NJABL dynablock and has > been growing since. That is _not_ "mildly effective". See > http://www.sdsc.edu/~jeff/spam/cbc.html] > The addition of the PBL to the sbl-xbl mildly increased the effectiveness of blocking. I agree that the total amount blocked is substantial, but the PBL does not yet contribute much. > In the large scale the difficulty is identifying what's a "pool". One > effort to determine that in terms of rDNS names is called "Enemies List" > (aka "EL") - which is some 15,000 regexes. That's 3 years of > accumulated knowledge by the guy who runs it. > A few dozen of those regexs cover 90% of the total. It would be great to have the rest, but missing a few isn't fatal to the project. > Many ISPs aren't good at naming of pools and properly renaming them when > the machine becomes "non-generic", or placing non-pool in the middle of > pools. So there is always a significant problem with non-poolish > machines having poolish names. There's a substantial number of > providers who don't understand that naming their servers (mail or > otherwise) something other than 1.2.4.5.example.com is bad. > Of course the nicest naming scheme is 1.2.3.4.pool.example.com, and the worst is pool-1-2-3-4.example.com, simply because of the way dns wildcards work. *.pool.example.com is only one line. pool*.example.com is supported by bind (or anything else that I know of). > An effort to RFCize (probably BCP) naming conventions has been going on > for quite some time by one "lone crusader", but unfortunately, _even_ on > the anti-spam side where they'd really love to see it, it's long been > dismissed as foolishly naive and will never happen. > > EL and PBL/dynablock _work_ rather well. But, don't kid yourself, there > are FPs with it. It isn't a solution per-se, perhaps best demonstrated > that despite how good they are, the XBL still does better. > The more MTAs use these tools, the fewer false positives there will be. > The problem isn't just pool addresses, much as it isn't just other subsets. > I don't understand - why is that an argument against solving part of the problem? > Even if it were "the solution", the PBL with something like 5-6 years of > accumulated "pool addresses" behind it (from many many sources) should > demonstrate that it's no easy task. Pool listings are _frightfully_ > expensive in man-hours to maintain. More expensive than fixed sources of spam? The PBL is handicapped by its rule not to list any address without the permission of the ISP. When they drop that rule and it will be quite effective. One has to remember that MAPS killed open relays quite quickly - behavior modification works. The operators of MTAs behind generic addresses are almost all insignificant and can easily adopt a smarthost once they realize they need one. I understand it is hard to make major ISPs kowtow to RFCs. This isn't in that league of difficulty at all. Daniel Feenberg > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3-nr1 (Windows XP) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQCVAwUBRb9rF53FmCyJjHfhAQJdnQP9E/fAOm6BCZcjNuDDWArJMCxfN3xswKJx > H4+a95UR576nZGiQRnZJzg8XvnqJw8dcZkv/IMNZSTrw1Oz2IBZqTSQ2NNfSZmCH > ZLGNYhY+osN4Lj18lq0ujUsbXVc0qrmp8Iu6AcrBE1fD1qLNSUSwjvdRjDe6jlXK > IxvNIqAV3yU= > =ywLI > -----END PGP SIGNATURE----- > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:48:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5v-0007dN-V1; Tue, 30 Jan 2007 12:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5v-0007dD-Dn for asrg@ietf.org; Tue, 30 Jan 2007 12:48:35 -0500 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx5t-0006FJ-32 for asrg@ietf.org; Tue, 30 Jan 2007 12:48:35 -0500 Received: from zardoc.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1.1.0.PreAlpha13.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=OK) id S00000000000C6C2F00; Tue, 30 Jan 2007 09:48:32 -0800 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.4/8.12.10.Beta0/Submit) id l0UHmV44003916 for asrg@ietf.org; Tue, 30 Jan 2007 09:48:32 -0800 (PST) Date: Tue, 30 Jan 2007 09:48:31 -0800 From: Claus Assmann To: asrg@ietf.org Message-ID: <20070130174831.GA24789@zardoc.esmtp.org> Mail-Followup-To: asrg@ietf.org References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BF8177.8090906@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45BF8177.8090906@ehsco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Asrg] Re: draft-hall-inline-dsn-01 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, Jan 30, 2007, Eric A. Hall wrote: > I would imagine that ietf-smtp@imc.org is the right place to talk about If the current participants of this thread agree, we can move the discussion over there. > deferred-rcpt-responses would be most descriptive but that's a bit greedy > given that command-line space is fixed. I don't really care what people > call it. Robots will be the 99.9999% use case and they won't care either. > Probably some kind of acronym like DRR or whatever would be most efficient > as far as that goes. "DRR" is fine, currently I call it "RSAD" in my implementation, but that's trivial to change. > I changed the section 6 heading in the current draft. The additional > breakdown looks reasonable and appropriate so I'll do that in the next > edition if there's any real interest in pursuing this further. I'm interested. I'm currently implementing it in my MTA, and I can implement it in the (still?) most widely used MTA if we get this to an RFC. Please make also the change to require PIPELINING, as LMTP does: 5. Implementation requirements A server implementation MUST implement the PIPELINING [PIPELINING] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:48:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx68-0007pv-IR; Tue, 30 Jan 2007 12:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx66-0007pY-Oe for asrg@ietf.org; Tue, 30 Jan 2007 12:48:46 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx65-0006Lf-HC for asrg@ietf.org; Tue, 30 Jan 2007 12:48:46 -0500 Received: from [207.65.71.19] (pool-71-252-110-214.washdc.east.verizon.net [71.252.110.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 1916F3F8C8 for ; Tue, 30 Jan 2007 11:48:45 -0600 (CST) Message-ID: <45BF84E1.5090709@ehsco.com> Date: Tue, 30 Jan 2007 12:48:17 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> In-Reply-To: <20070129022417.GA27308@zardoc.esmtp.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/28/2007 9:24 PM, Claus Assmann wrote: > Wrt section "6.4. The Final Response Code": > > Why do we need a final reply code? Isn't that code the same as the > minimum over the RCPT reply codes (at least wrt the reply code > severity)? Hence it is not need to send this reply code as it can > be deduced from the existing reply codes. The final code is where the server says that it is taking responsibility for the message. The delayed RCPT codes just report on whether or not the content is acceptable for the associated recipient. It's possible that the recipients will all accept the message, but the server is still unable to accept the message for processing for some reason (server going down, whatever). > PS: "response code" should be replaced by "reply code" in the draft > to match RFC2821. will add that as well as the clarification above to the next draft -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 12:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx8B-0001F6-MI; Tue, 30 Jan 2007 12:50:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx8A-0001F0-QW for asrg@ietf.org; Tue, 30 Jan 2007 12:50:54 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx89-0006ng-JG for asrg@ietf.org; Tue, 30 Jan 2007 12:50:54 -0500 Received: from [207.65.71.19] (pool-71-252-110-214.washdc.east.verizon.net [71.252.110.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 2967423D5A for ; Tue, 30 Jan 2007 11:50:53 -0600 (CST) Message-ID: <45BF8561.60503@ehsco.com> Date: Tue, 30 Jan 2007 12:50:25 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> <20070129094926.GA24425@hjp.at> In-Reply-To: <20070129094926.GA24425@hjp.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/29/2007 4:49 AM, Peter J. Holzer wrote: > It also may reduce the risk of resending a message which was already > accepted because the connection broke down, but I'm not sure that really > works: > > If you send a message to 100 recipients, and the connection breaks after > 43 replies, how many will get the message? Hopefully none of them, since the server was not able to fully accept the message for delivery. It might be worth putting a synchronization marker after the full list of recipients has been acknowledged by the client in order to ensure that both end points are at the same state when final code is issued. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 13:15:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxTl-0001sU-AC; Tue, 30 Jan 2007 13:13:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxTj-0001sL-Vg for asrg@ietf.org; Tue, 30 Jan 2007 13:13:11 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBxTf-0006nD-M8 for asrg@ietf.org; Tue, 30 Jan 2007 13:13:11 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HBxTf-0003J5-00; Tue, 30 Jan 2007 18:13:07 +0000 To: ehall@ehsco.com From: Tony Finch Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 In-Reply-To: <45BF8561.60503@ehsco.com> References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> <20070129094926.GA24425@hjp.at> <20070129094926.GA24425@hjp.at> Message-Id: Date: Tue, 30 Jan 2007 18:13:07 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Eric A. Hall" wrote: >On 1/29/2007 4:49 AM, Peter J. Holzer wrote: > >> It also may reduce the risk of resending a message which was already >> accepted because the connection broke down, but I'm not sure that really >> works: >> If you send a message to 100 recipients, and the connection breaks after >> 43 replies, how many will get the message? > >Hopefully none of them, since the server was not able to fully accept the >message for delivery. >It might be worth putting a synchronization marker after the full list of >recipients has been acknowledged by the client in order to ensure that >both end points are at the same state when final code is issued. Ugh, no, that's horrible for performance. The right solution is: http://www.ietf.org/internet-drafts/draft-fanf-smtp-rfc1845bis-00.txt Tony. -- f.a.n.finch http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: MAINLY NORTHWESTERLY 6 OR 7, OCCASIONALLY GALE 8, BACKING SOUTHWESTERLY 5 FOR A TIME. ROUGH OR VERY ROUGH. SHOWERS THEN RAIN. GOOD BECOMING MODERATE. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 13:27:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxgh-0001GO-32; Tue, 30 Jan 2007 13:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxgf-0001GB-1q for asrg@ietf.org; Tue, 30 Jan 2007 13:26:33 -0500 Received: from adsl-216-102-208-14.dsl.snfc21.pacbell.net ([216.102.208.14] helo=mtcc14.mtcc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBxgd-0002Tl-Ka for asrg@ietf.org; Tue, 30 Jan 2007 13:26:33 -0500 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1352; t=1170181540; x=1171045540; c=relaxed/simple; s=alltheway.kirkwood; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20How=20about=20we=20do=20someth ing=20about=20spam? |Sender:=20 |To:=20Daniel=20Feenberg=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=tvkSmQ91xtjBRMFx8MiY7oskwz/bldAUpM2/ovCmjPw=; b=ZoRqo1BBTw7fy129dP6p9v6r9I1ELmSH6XibCqG6eFROP74sOE/nBLpFsw XE3hh63TNXPo8KN1oUKlQzD8lRSLxDr6qFvup3vTD1BqSG3lbEmqen857b4z ohH5N9c5IJICIIvzFbrhMxm4e1o6mA1kj1SL4wMqkxT7jeAggCDk8=; Received: from [127.0.0.1] (mtcc14.mtcc.com [127.0.0.1]) by mtcc14.mtcc.com (8.13.8/8.13.8) with ESMTP id l0UIPd5i006897; Tue, 30 Jan 2007 10:25:40 -0800 Message-ID: <45BF8DA3.7060204@mtcc.com> Date: Tue, 30 Jan 2007 10:25:39 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-2.fc6 pango-text Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Daniel Feenberg Subject: Re: [Asrg] How about we do something about spam? References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: mtcc14.mtcc.com; header.From=mike@mtcc.com; dkim=pass ( sig from mtcc.com/alltheway.kirkwood verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: asrg@ietf.org, Chris Lewis X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Daniel Feenberg wrote: >> Even if it were "the solution", the PBL with something like 5-6 years of >> accumulated "pool addresses" behind it (from many many sources) should >> demonstrate that it's no easy task. Pool listings are _frightfully_ >> expensive in man-hours to maintain. > One has to remember that MAPS killed open relays quite quickly - > behavior modification works. The operators of MTAs behind generic > addresses are almost all insignificant and can easily adopt a > smarthost once they realize they need one. I understand it is hard to > make major ISPs kowtow to RFCs. This isn't in that league of > difficulty at all. Talk about the law of unintended consequences. This gives an immense amount of control to providers who have many, many built in conflicts. It's not just email that's at stake here, but end user servers/services in general. If we force everybody who would have the audacity to run their own services to go through their local unfriendly ISP, then we might as well rebuild the circuit switched network with its stellar track record of delivering new and innovative services. The ability to route around damage was one of the key innovations of the net. I'd much rather keep that and look for other ways to deal with our problems than reverting back to known dysfunction. Mike _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 13:35:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxod-00042H-4z; Tue, 30 Jan 2007 13:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxob-00042B-H1 for asrg@ietf.org; Tue, 30 Jan 2007 13:34:45 -0500 Received: from goose.ehsco.com ([207.65.203.98] helo=goose.ntrg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBxoa-00064Y-8S for asrg@ietf.org; Tue, 30 Jan 2007 13:34:45 -0500 Received: from [207.65.71.19] (pool-71-252-110-214.washdc.east.verizon.net [71.252.110.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id BD0563034F; Tue, 30 Jan 2007 12:34:43 -0600 (CST) Message-ID: <45BF8FA7.9070508@ehsco.com> Date: Tue, 30 Jan 2007 13:34:15 -0500 From: "Eric A. Hall" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Finch Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 References: <45B59B86.6030003@dcrocker.net> <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> <20070129094926.GA24425@hjp.at> <20070129094926.GA24425@hjp.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1/30/2007 1:13 PM, Tony Finch wrote: > "Eric A. Hall" wrote: >> It might be worth putting a synchronization marker after the full list of >> recipients has been acknowledged by the client in order to ensure that >> both end points are at the same state when final code is issued. > > Ugh, no, that's horrible for performance. The right solution is: > http://www.ietf.org/internet-drafts/draft-fanf-smtp-rfc1845bis-00.txt That's a good idea but your I-D would have to get published as standards-track before it could be linked in as a dependency. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 13:49:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy1T-0002Yv-WE; Tue, 30 Jan 2007 13:48:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy1S-0002Yh-Mc for asrg@ietf.org; Tue, 30 Jan 2007 13:48:02 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBy1Q-0008WR-96 for asrg@ietf.org; Tue, 30 Jan 2007 13:48:02 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0UIeAo24264 for ; Tue, 30 Jan 2007 13:40:11 -0500 (EST) Received: from [47.9.28.9] ([47.9.28.9] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 13:47:57 -0500 Message-ID: <45BF92DA.1090608@nortel.com> Date: Tue, 30 Jan 2007 13:47:54 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2007 18:47:57.0579 (UTC) FILETIME=[28A5C5B0:01C7449F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Feenberg wrote: > On Tue, 30 Jan 2007, Chris Lewis wrote: >> [Aside: the PBL (Spamhaus's "policy blacklist", which is essentially the >> same as "pool addresses" was pre-primed with NJABL dynablock and has >> been growing since. That is _not_ "mildly effective". See >> http://www.sdsc.edu/~jeff/spam/cbc.html] >> > > The addition of the PBL to the sbl-xbl mildly increased the > effectiveness of blocking. I agree that the total amount blocked is > substantial, but the PBL does not yet contribute much. Even incrementally. Check out Makey's stats. Going from 80K -> 100K ain't small potatoes, when you consider that even _before_ that, Spamhaus typically been 70-85%. >> Many ISPs aren't good at naming of pools and properly renaming them when >> the machine becomes "non-generic", or placing non-pool in the middle of >> pools. So there is always a significant problem with non-poolish >> machines having poolish names. There's a substantial number of >> providers who don't understand that naming their servers (mail or >> otherwise) something other than 1.2.4.5.example.com is bad. >> > > Of course the nicest naming scheme is 1.2.3.4.pool.example.com, and the > worst is pool-1-2-3-4.example.com, simply because of the way dns > wildcards work. *.pool.example.com is only one line. pool*.example.com > is supported by bind (or anything else that I know of). When it boils down to it that that sort of difficulty makes little difference to the concept. Even if you had almost "perfect" pool coverage, there's still a _very_ high volume of junk from non-pool areas. >> The problem isn't just pool addresses, much as it isn't just other >> subsets. > I don't understand - why is that an argument against solving part of the > problem? It isn't, only that it's perhaps not as major a contributor to the solution as it may appear to you. >> Even if it were "the solution", the PBL with something like 5-6 years of >> accumulated "pool addresses" behind it (from many many sources) should >> demonstrate that it's no easy task. Pool listings are _frightfully_ >> expensive in man-hours to maintain. > More expensive than fixed sources of spam? The PBL is handicapped by its > rule not to list any address without the permission of the ISP. When > they drop that rule and it will be quite effective. Ah, no. You're missing some important detail about the PBL. Go reread the PBL web pages, and understand the difference between the 127.0.0.10 and 127.0.0.11 returns. > One has to remember that MAPS killed open relays quite quickly - > behavior modification works. The operators of MTAs behind generic > addresses are almost all insignificant and can easily adopt a smarthost > once they realize they need one. I understand it is hard to make major > ISPs kowtow to RFCs. This isn't in that league of difficulty at all. I have a lot of experience behind trying to deal with people on "pools". It's not as simple as you think. Not the least being the vast number of poorly enumerated pools. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb+S2p3FmCyJjHfhAQL1/AQArrIbfoy/r+zl/4+QeEeC3LcfmWebBHR9 khwVH8CEJh94lr3Dr0KViwF4HyVO/dp107b3DEZQmMYcIYM7woOALnq/ladTx7D/ zvGi524PZqiE8a4mAqzcAkWuTk/sInGAbrZbxu/q/PLspyd9ZdJochJga8Tr7kRY Ax/fQaJrSRg= =ZMQX -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 14:37:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBykt-0000uc-Fu; Tue, 30 Jan 2007 14:34:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByks-0000uW-M7 for asrg@ietf.org; Tue, 30 Jan 2007 14:34:58 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBykq-0003Yz-W7 for asrg@ietf.org; Tue, 30 Jan 2007 14:34:58 -0500 Received: from [10.2.165.137] (net-office-sjc.mail-abuse.org [168.61.0.42]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0UJYtXN005929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jan 2007 11:34:56 -0800 In-Reply-To: <45BF8DA3.7060204@mtcc.com> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> <45BF8DA3.7060204@mtcc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BDCC62C-1A71-4D5D-B625-51690FC9F5E9@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Tue, 30 Jan 2007 11:35:03 -0800 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 30, 2007, at 10:25 AM, Michael Thomas wrote: > The ability to route around damage was one of the key innovations > of the net. I'd much rather keep that and look for other ways to > deal with our problems than reverting back to known dysfunction. A great deal of dysfunction and risk is caused by SMTP extensions as well. SPF/Sender-ID is a good example of a protocol that may cause hundreds of DNS transactions relating the bounce, PRA, or a DKIM domain with an SMTP client IP address. (DKIM still allows replay.) Had the SMTP client name been validated, association with _any_ other originating domain within a message could be assured within a single, small, and safe DNS transaction. Obfuscating roles of the client transmitting messages continues with the DKIM protocol. Imposing a limitation on who's behalf the message is signed offers transmitting clients a means to extort private keys from domain owners using the service. This will result in a security disaster when an MTA holding thousands of private keys becomes compromised. Clients transmitting or signing email MUST be identifiable and spam MUST be made illegal. Lack of SMTP client identification and spamming is _directly_ responsible for the spread of much of today's malware! The criminal element has demonstrated individuals can not be easily tracked in today's Internet. Those in the business of transmitting messages should identify their clients and not abuse network resources by allowing bulk unsolicited promotions of any sort. Identifying the client transmitting or signing messages does not mean individuals are being identified or that freedom has been lost. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 14:48:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByxS-0006km-53; Tue, 30 Jan 2007 14:47:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByxR-0006ke-0s for asrg@ietf.org; Tue, 30 Jan 2007 14:47:57 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByxP-00065Y-Gl for asrg@ietf.org; Tue, 30 Jan 2007 14:47:57 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 863404039; Tue, 30 Jan 2007 20:47:38 +0100 (CET) Date: Tue, 30 Jan 2007 20:47:38 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070130194738.GB26664@hjp.at> Mail-Followup-To: asrg@ietf.org References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> <20070129094926.GA24425@hjp.at> <20070129094926.GA24425@hjp.at> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780010248==" Errors-To: asrg-bounces@ietf.org --===============0780010248== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-30 18:13:07 +0000, Tony Finch wrote: > "Eric A. Hall" wrote: > >On 1/29/2007 4:49 AM, Peter J. Holzer wrote: > >> It also may reduce the risk of resending a message which was already > >> accepted because the connection broke down, but I'm not sure that real= ly > >> works: > >> If you send a message to 100 recipients, and the connection breaks aft= er > >> 43 replies, how many will get the message? > > > >Hopefully none of them, since the server was not able to fully accept the > >message for delivery. That's what I understood to be the intention of the final code. If the client receives the final code, it knows the server has taken responsibility for the message and can forget about it (except for recipients with 4xx replies, of course). If it doesn't receive the final code, it must assume that the server hasn't accepted it and must resend it for all recipients. I'm just not sure whether that really reduces the number of duplicate messages. It it conceivable that the server sends the final code before it notices that the connection has been lost. In that case the client will resend the message to all recpients, while otherwise it would resend the message only for those recipients for which it hasn't received a reply code. So the final reply code reduces the probability of duplicated messages, but if they happen, they are sent to more users. I have no idea whether that results in more or less duplicated messages overall. > >It might be worth putting a synchronization marker after the full list of > >recipients has been acknowledged by the client in order to ensure that > >both end points are at the same state when final code is issued. >=20 > Ugh, no, that's horrible for performance. The right solution is: > http://www.ietf.org/internet-drafts/draft-fanf-smtp-rfc1845bis-00.txt That only lets you put checkpoints inside the data. It doesn't let the client specify how many reply codes it received for data (there's no need for that in unextended SMTP). Of course the server could save the reply codes it has already sent and quickly replay those if the client resumes at the end of data, so maybe that doesn't matter. hp PS: I just subscribed to ietf-smtp@imc.org, so as far as I am concerned we can continue the discussion there. --=20 _ | Peter J. Holzer | I know I'd be respectful of a pirate=20 |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall" --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFv6DafZ+RkG8quy0RAiMeAKCdxOqELQIyIBKrEeVxsJuTK9zB8QCeKGp2 V0EPN9Klo5ERrifwSI85Ses= =GFJ7 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- --===============0780010248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0780010248==-- From asrg-bounces@ietf.org Tue Jan 30 15:10:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzIV-0008Ai-P5; Tue, 30 Jan 2007 15:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzIU-0008AK-2k for asrg@ietf.org; Tue, 30 Jan 2007 15:09:42 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzIR-0000kS-PR for asrg@ietf.org; Tue, 30 Jan 2007 15:09:42 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HBzIR-0000pA-00; Tue, 30 Jan 2007 20:09:39 +0000 To: hjp-asrg@hjp.at From: Tony Finch Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 In-Reply-To: <20070130194738.GB26664@hjp.at> References: <17846.26016.14436.541196@world.std.com> <934f64a20701231205m7809b32bv950aaabfcb1c073e@mail.gmail.com> <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070129022417.GA27308@zardoc.esmtp.org> <20070129094926.GA24425@hjp.at> <20070129094926.GA24425@hjp.at> Message-Id: Date: Tue, 30 Jan 2007 20:09:39 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Peter J. Holzer" wrote: >On 2007-01-30 18:13:07 +0000, Tony Finch wrote: >> >> http://www.ietf.org/internet-drafts/draft-fanf-smtp-rfc1845bis-00.txt > >That only lets you put checkpoints inside the data. It doesn't let the >client specify how many reply codes it received for data (there's no >need for that in unextended SMTP). Of course the server could save the >reply codes it has already sent and quickly replay those if the client >resumes at the end of data, so maybe that doesn't matter. Right. The server's replies after data would be handled in a similar way to the envelope before the data. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN HEBRIDES BAILEY: SOUTHWEST 7 TO SEVERE GALE 9, LATER DECREASING 5 OR 6. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 15:16:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzOl-0003w0-Br; Tue, 30 Jan 2007 15:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzOk-0003vv-3N for asrg@ietf.org; Tue, 30 Jan 2007 15:16:10 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzOh-0001az-OE for asrg@ietf.org; Tue, 30 Jan 2007 15:16:10 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l0UKFuem016401 for ; Tue, 30 Jan 2007 15:15:56 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l0UKFte2016379; Tue, 30 Jan 2007 15:15:55 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l0UKFtnE004197; Tue, 30 Jan 2007 15:15:55 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l0UKFo6S004092; Tue, 30 Jan 2007 15:15:50 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Tue, 30 Jan 2007 15:15:50 -0500 (EST) From: Daniel Feenberg To: Michael Thomas Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <45BF8DA3.7060204@mtcc.com> Message-ID: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> <45BF8DA3.7060204@mtcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: asrg@ietf.org, Chris Lewis X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 30 Jan 2007, Michael Thomas wrote: > Daniel Feenberg wrote: >>> Even if it were "the solution", the PBL with something like 5-6 years of >>> accumulated "pool addresses" behind it (from many many sources) should >>> demonstrate that it's no easy task. Pool listings are _frightfully_ >>> expensive in man-hours to maintain. >> One has to remember that MAPS killed open relays quite quickly - behavior >> modification works. The operators of MTAs behind generic addresses are >> almost all insignificant and can easily adopt a smarthost once they realize >> they need one. I understand it is hard to make major ISPs kowtow to RFCs. >> This isn't in that league of difficulty at all. > Talk about the law of unintended consequences. This gives an immense > amount of control to providers who have many, many built in conflicts. It's > not just email that's at stake here, but end user servers/services in > general. > If we force everybody who would have the audacity to run their own services Not everybody, only those with dynamic addresses. and only for port 25, and only when communicating with strangers, and they could use any smarthost that would have them, not just that of their ISP. Dan Feenberg > to go through their local unfriendly ISP, then we might as well rebuild the > circuit switched network with its stellar track record of delivering new and > innovative services. The ability to route around damage was one of the key > innovations of the net. I'd much rather keep that and look for other ways to > deal with our problems than reverting back to known dysfunction. > > Mike > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 15:26:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzXs-0008DD-Ja; Tue, 30 Jan 2007 15:25:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzXq-0008D2-LB for asrg@ietf.org; Tue, 30 Jan 2007 15:25:34 -0500 Received: from zeno.hjp.at ([81.223.91.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzXn-0002oz-4K for asrg@ietf.org; Tue, 30 Jan 2007 15:25:34 -0500 Received: by zeno.hjp.at (Postfix, from userid 1000) id 595C74039; Tue, 30 Jan 2007 21:25:30 +0100 (CET) Date: Tue, 30 Jan 2007 21:25:30 +0100 From: "Peter J. Holzer" To: asrg@ietf.org Subject: Re: [Asrg] Re: draft-hall-inline-dsn-01 Message-ID: <20070130202530.GC26664@hjp.at> Mail-Followup-To: asrg@ietf.org References: <20070123210057.GD1712@hjp.at> <45B67DB0.5070803@ehsco.com> <20070125160617.GB12259@hjp.at> <45B9070C.4060806@ehsco.com> <20070127042237.GA24125@zardoc.esmtp.org> <45BC9150.76E0@xyzzy.claranet.de> <20070128140126.GC18862@hjp.at> <45BD0681.6EFC@xyzzy.claranet.de> <20070128220610.GE18862@hjp.at> <934f64a20701291435k9de8128qfc78bf00ca76a618@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <934f64a20701291435k9de8128qfc78bf00ca76a618@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834272668==" Errors-To: asrg-bounces@ietf.org --===============0834272668== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-01-29 16:35:02 -0600, David Nicol wrote: > On 1/28/07, Peter J. Holzer wrote: > >On 2007-01-28 21:24:33 +0100, Frank Ellermann wrote: > >> Peter J. Holzer wrote: > >> > David Nicol's DATAFIRST proposal. > >> [...] > > > >I'm not interested in DATAFIRST. I'm interested in returning > >per-recipient results to DATA. >=20 > they aren't mutually exclusive. I didn't say they were. DATAFIRST includes the ability to return per-recipient results to DATA. That's what I like about it. Unfortunately it also removes the ability to return per-recipient results before getting DATA, which I don't like. So I prefer Eric's proposal, although it is admittedly more complex. > >> What I didn't like in draft-hall-inline-dsn was the sequence of > >> per recipient responses after DATA matching the sequence of RCPT > >> before DATA. > > > >That's what the proposal is about. It allows several return codes for > >DATA. The exact mechanism might be different (for example, there could > >be a multiline-response instead of multiple single-line responses, or > >the return codes can be matched by address instead of order), but these > >are minor changes. >=20 > the one request, one response model is crucial to SMTP servers -- you > can write a smtp server that essentially does >=20 > smtp_connect; > while (accept and fork){ > send_smtp("EHLO blah blah blah"); > send_smtp(craft_smtp_response(receive_smtp())) while 1; > }; I think you mixed server and client a bit, here. > and multiple response lines makes that no longer work; or means that > the receive_smtp() has to have a lot more data in it than if we are readi= ng > a data block or not. Yep, it gets more complicated. The server's implementation of the data command has to be able to send intermediate reply codes (I think that's how I would implement it in qpsmpd - simply write out the replies for each recipient and return DONE instead of OK/DENY/whatever from the data_post hook; the final reply would then be returned from the queue hook as normal). The client OTOH has to remember how many reply codes it is expecting and match them up with the recipients. > so if the ordering is important, maintain it; how about a big response th= at > is a well-defined XML block? I'm not sure I would want to introduce the complexities of XML into SMTP. When I suggested a single multi-line response earlier in this thread I was more thinking about nesting SMTP responses like this: 250-Message accepted by some recipients. Individual replies follow: 250-250 accepted message. 250-550- rejected message. 250-550 see http://www.example.com/mail-policy/ for details. 250 250 accepted message. 550- rejected message. 550 see http://www.example.com/mail-policy/ for details. 250 ; Tue, 30 Jan 2007 17:53:07 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0UMqs3C013766; Tue, 30 Jan 2007 17:52:54 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17855.52294.729384.356913@world.std.com> Date: Tue, 30 Jan 2007 17:52:54 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <17854.62393.356114.929389@world.std.com> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls6.std.com X-Virus-Scanned: ClamAV 0.88.4/2506/Tue Jan 30 14:50:40 2007 on pcls6.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org To be more specific, I was thinking of an RFC which adds to RFC2635 (FYI00035), FYI00038, and builds on ideas expressed in RFC4686, RFC2505 (BCP00030), and FYI00036 but aimed at trying to delineate where law enforcement (e.g., zombie bot armies) efforts would be important and useful. A published document expressing the need for more law enforcement involvement in certain areas of this problem could help policy makers et al allocate resources appropriately. Put another way, it would be naive to wait for LEOs, policy-makers, regulators, et al, to discover for themselves how they can help. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 18:11:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC27I-0007SD-OQ; Tue, 30 Jan 2007 18:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC27H-0007Ru-Gc for asrg@ietf.org; Tue, 30 Jan 2007 18:10:19 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC27G-0008K9-1k for asrg@ietf.org; Tue, 30 Jan 2007 18:10:19 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0UN9W3t028081 for ; Tue, 30 Jan 2007 18:09:34 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0UN9WfX015308; Tue, 30 Jan 2007 18:09:32 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17855.53291.874061.750696@world.std.com> Date: Tue, 30 Jan 2007 18:09:31 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls5.std.com X-Virus-Scanned: ClamAV 0.88.4/2506/Tue Jan 30 14:50:40 2007 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Besides the reasonable technical problems expressed with identifying pools there's another consideration. Blocking pools as a general rule is a serious retreat and, though it might be stopgap, it's not technological progress. However necessary blocking pools strikes me as, at best, a necessary (and with luck temporary) evil, analogous to telling people to stay out of a public park at night because of the danger of criminal attack. It yields a huge front to the criminals. It sets the stage for the widespread balkanization of the net. Next might be having to pay for accounts with blessed hosts to send email at all to large swaths of other hosts (e.g., fortune 500.) -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 18:12:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC29N-0000yG-9o; Tue, 30 Jan 2007 18:12:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC29M-0000yB-Tz for asrg@ietf.org; Tue, 30 Jan 2007 18:12:28 -0500 Received: from cl-108.dub-01.ie.sixxs.net ([2001:770:100:6b::2] helo=dogma.boxhost.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC29M-0000Uu-Bk for asrg@ietf.org; Tue, 30 Jan 2007 18:12:28 -0500 Received: from radish.jmason.org (localhost [127.0.0.1]) by dogma.boxhost.net (Postfix) with ESMTP id BDF303100F2; Tue, 30 Jan 2007 23:12:22 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id BD72D32CBF; Tue, 30 Jan 2007 23:11:56 +0000 (GMT) To: Barry Shein Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <17855.52294.729384.356913@world.std.com> From: jm@jmason.org (Justin Mason) X-GPG-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 Date: Tue, 30 Jan 2007 23:11:56 +0000 Message-Id: <20070130231156.BD72D32CBF@radish.jmason.org> X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Barry Shein writes: > Put another way, it would be naive to wait for LEOs, policy-makers, > regulators, et al, to discover for themselves how they can help. For what it's worth, LEOs are certainly attending plenty of conferences and private get-togethers that cover these points; APWG, London Action Plan, and probably others, all feature law enforcement. I do believe they're already quite aware, and are working on the problem (although silently and behind closed doors, for some reason, which in my opinion is not a great way to proceed). --j. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 18:14:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Bc-0001d5-3Z; Tue, 30 Jan 2007 18:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Bb-0001cu-4r for asrg@ietf.org; Tue, 30 Jan 2007 18:14:47 -0500 Received: from pcls6.std.com ([192.74.137.146] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2BZ-00017W-Ri for asrg@ietf.org; Tue, 30 Jan 2007 18:14:47 -0500 Received: from world.std.com (sja@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0UNETiC001853 for ; Tue, 30 Jan 2007 18:14:37 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0UNEJ4J015734; Tue, 30 Jan 2007 18:14:19 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17855.53579.581503.566669@world.std.com> Date: Tue, 30 Jan 2007 18:14:19 -0500 To: ASRG Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <8BDCC62C-1A71-4D5D-B625-51690FC9F5E9@mail-abuse.org> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> <45BF8DA3.7060204@mtcc.com> <8BDCC62C-1A71-4D5D-B625-51690FC9F5E9@mail-abuse.org> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls6.std.com X-Virus-Scanned: ClamAV 0.88.4/2506/Tue Jan 30 14:50:40 2007 on pcls6.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On January 30, 2007 at 11:35 dotis@mail-abuse.org (Douglas Otis) wrote: > The criminal element has demonstrated individuals can not be easily > tracked in today's Internet. Gosh, they seem to round them up by the hundreds when child pornography is involved. I think it's more a matter of will than means. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 20:22:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC47f-000558-No; Tue, 30 Jan 2007 20:18:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC47f-00054y-Ak for asrg@ietf.org; Tue, 30 Jan 2007 20:18:51 -0500 Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC47e-0004m1-4Y for asrg@ietf.org; Tue, 30 Jan 2007 20:18:51 -0500 Received: (qmail 3964 invoked from network); 31 Jan 2007 01:18:49 -0000 Received: from mail.iecc.com (208.31.42.99) by mail.iecc.com with QMQP; 31 Jan 2007 01:18:49 -0000 Date: 31 Jan 2007 01:18:50 -0000 Message-ID: <20070131011850.15775.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <20070130231156.BD72D32CBF@radish.jmason.org> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >For what it's worth, LEOs are certainly attending plenty of conferences >and private get-togethers that cover these points; APWG, London Action >Plan, and probably others, all feature law enforcement. Indeed. R's from the MAAWG meeting in San Francisco, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 20:28:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4Gk-00005d-Gu; Tue, 30 Jan 2007 20:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4Gi-0008VC-F1 for asrg@ietf.org; Tue, 30 Jan 2007 20:28:12 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC4Gh-0008Qt-37 for asrg@ietf.org; Tue, 30 Jan 2007 20:28:12 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l0V1S7mg029701; Tue, 30 Jan 2007 17:28:07 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l0V1S7JC029698; Tue, 30 Jan 2007 17:28:07 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 30 Jan 2007 17:28:07 -0800 (PST) From: "william(at)elan.net" To: John Levine Subject: Re: [Asrg] asrg wiki, was How about we do something about spam? In-Reply-To: <20070131011756.15539.qmail@simone.iecc.com> Message-ID: References: <20070131011756.15539.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 31 Jan 2007, John Levine wrote: >> Would it help to have a wiki for Asrg? Somewhere that each concept >> can exist in it's own space spanning time so it doesn't have to be >> brought up over and over and rehashed with all the same arguments. > > I can certainly set one up. To keep the wikispam under control, anyone > who wants to contribute will have to register and confirm an e-mail address. I'm not against it, but wasnt there attempt to do it before for ASRG already that did not produce much results? -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 20:44:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4WO-0000hE-GY; Tue, 30 Jan 2007 20:44:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4WM-0000h6-KY for asrg@ietf.org; Tue, 30 Jan 2007 20:44:22 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC4WK-0004U9-9R for asrg@ietf.org; Tue, 30 Jan 2007 20:44:22 -0500 Received: from [10.2.165.137] (net-office-sjc.mail-abuse.org [168.61.0.42]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0V1iJ5u007947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jan 2007 17:44:19 -0800 In-Reply-To: <17855.53579.581503.566669@world.std.com> References: <20070128113319.GA18862@hjp.at> <17854.22871.423362.95300@world.std.com> <17854.31180.793466.939378@world.std.com> <17854.62393.356114.929389@world.std.com> <45BF6B18.2000308@nortel.com> <45BF8DA3.7060204@mtcc.com> <8BDCC62C-1A71-4D5D-B625-51690FC9F5E9@mail-abuse.org> <17855.53579.581503.566669@world.std.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48E89B4F-939C-4DA0-8C7F-F0F00D520858@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Tue, 30 Jan 2007 17:44:26 -0800 To: Barry Shein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 30, 2007, at 3:14 PM, Barry Shein wrote: > On January 30, 2007 at 11:35 dotis@mail-abuse.org (Douglas Otis) > wrote: >> >> The criminal element has demonstrated individuals can not be >> easily tracked in today's Internet. > > Gosh, they seem to round them up by the hundreds when child > pornography is involved. > > I think it's more a matter of will than means. This is not a forum to discuss how individuals remain anonymous. Those with a larger incentive (and perhaps more likely traced) seem to know the needed steps. Almost any server used to send on port 25 is traceable. Remaining anonymous is arranged prior to the outbound public server, as might be needed for good reasons. Those entities that control the public services should be held accountable when permitting unsolicited bulk email. Those transmitting messages into the public should include a signature clearly acknowledging their role. These signatures should also be permitted to indicate that they were signed for anyone. Signatures should not demand prior arrangements be established by the email-address domain, as is now the case for DKIM. : ( Recipients should not be expected to bear the cost of bulk unsolicited email. There are plenty of appropriate forums on the Internet. Those in the business of publicly transmitting messages should clearly and unambiguously identify themselves. This precludes domain indirection permitted by SPF/Sender-ID scripts, or using someone else's DKIM keys. When there is a problem reported, these entities must receive the reports and take steps to curtail future events. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 22:17:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC5w6-0004Ff-8K; Tue, 30 Jan 2007 22:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC5w4-0004C3-3C for asrg@ietf.org; Tue, 30 Jan 2007 22:15:00 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC5w2-0002z8-OD for asrg@ietf.org; Tue, 30 Jan 2007 22:15:00 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0V3Eur06081 for ; Tue, 30 Jan 2007 22:14:56 -0500 (EST) Received: from [47.9.28.96] ([47.9.28.96] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 22:14:56 -0500 Message-ID: <45C009AE.1080607@nortel.com> Date: Tue, 30 Jan 2007 22:14:54 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? References: <20070130231156.BD72D32CBF@radish.jmason.org> In-Reply-To: <20070130231156.BD72D32CBF@radish.jmason.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 03:14:56.0172 (UTC) FILETIME=[FB8AB6C0:01C744E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justin Mason wrote: > Barry Shein writes: >> Put another way, it would be naive to wait for LEOs, policy-makers, >> regulators, et al, to discover for themselves how they can help. > > For what it's worth, LEOs are certainly attending plenty of conferences > and private get-togethers that cover these points; APWG, London Action > Plan, and probably others, all feature law enforcement. Eg: MAAWG. > I do believe they're already quite aware, and are working on the problem > (although silently and behind closed doors, for some reason, which > in my opinion is not a great way to proceed). Not entirely closed, but you may have to be near the door to know it exists. This is not to suggest that you can sit back and wait, but at least, there is some traction as people are getting a better idea of what they face, begin to learn how to deal with it, and array the right people. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRcAJrZ3FmCyJjHfhAQI1NQP9HORhnZeycAoKQ1T6Vb3gaLvgi0yfloDb RXMGVaYGoFIqyzLadCG/v4Ru1YACK/khS6/cFZVtkWdeTmlqSeqhhC/7AvhXbe7n ukQCuE2TyG/bblFci0zXhfI3b4c+yNhprMnzFP/NBzmh1oUoBom5H3k6vV53KLXp To/Kdke8XFk= =U6L7 -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 23:22:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6vv-0001Ue-4a; Tue, 30 Jan 2007 23:18:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6vt-0001UX-Qo for asrg@ietf.org; Tue, 30 Jan 2007 23:18:53 -0500 Received: from egress5.webmaillogin.com ([216.40.36.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC6vr-0006OV-FY for asrg@ietf.org; Tue, 30 Jan 2007 23:18:53 -0500 Received: by egress5.webmaillogin.com (egress5.webmaillogin.com, from userid 1005) id AF7CE588475; Tue, 30 Jan 2007 23:18:44 -0500 (EST) Received: from webmaillogin.com (fr3.webmaillogin.com [216.40.35.67]) by egress5.webmaillogin.com (egress5.webmaillogin.com) with ESMTP id E4D67588EEA; Tue, 30 Jan 2007 23:18:35 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk1.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61710078; Tue, 30 Jan 2007 23:07:51 -0500 From: Subject: Re: [Asrg] How about we do something about spam? To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Tue, 30 Jan 2007 22:07:51 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org [problem of botnets as spam originators] > Isn't the solution to decline ALL mail from obvious pool=20 >addresses? I hear=20 > the argument that you can't put pool addresses in a=20 >DNSBL because next=20 > week the bot will have a different address. So put the=20 >whole pool in the=20 > BDSBL.=20 The solution to the problem is actually AMAZINGLY=20 simple... I know that a lot of y'all have this fixation on=20 IP-based solutions, but a FAR better solution (rather than=20 attempting to block spam AFTER the botnets are recruited)=20 is to block the virus/worm code-containing E-mail messages=20 BEFORE they infect those computers. And that is really rather easy... you simply block any=20 HTML or attachments (and particularly EXECUTABLE=20 attachments) that isn't coming from a sender that is known=20 and trusted by the recipient TO SEND THEM EXECUTABLE=20 CONTENT. Note that MOST users (probably 98-99%) will not whitelist=20 ANYBODY to send them executable content in E-mails...! The other way that botnets are recruited are by people=20 visiting infectious Web sites, but that is a problem for a=20 different list. > ...This will result=20 >in a security =20 > disaster when an MTA holding thousands of private keys=20 >becomes =20 > compromised. Clients transmitting or signing email MUST=20 >be =20 > identifiable and spam MUST be made illegal. Lack of=20 >SMTP client =20 > identification and spamming is _directly_ responsible=20 >for the spread =20 > of much of today's malware! The fixation on "client identification" (like SPF does)=20 isn't very effective for the simple reason that an=20 infected machine can send spam using all of that machine's=20 certifications and habitual outgoing mail server. Likewise, a person can need to send legitimate mail from=20 an inhabitual location (such as a cruise ship Internet=20 cafe). What IS (much more!) effective is to determine whether an=20 outgoing (/arriving?) mail message LOOKS "LIKE" the mail=20 that the legitimate user of the now-infected machine=20 habitually sends to a given correspondent. Ideally, that=20 "looks like:" rule and criteria would be different for=20 each correspondent recipient. > The criminal element has demonstrated individuals can=20 >not be easily =20 > tracked in today's Internet. Those in the business of=20 >transmitting =20 > messages should identify their clients and not abuse=20 >network =20 > resources by allowing bulk unsolicited promotions of any=20 >sort. =20 What is 'legal' and 'not legal' will depend on from which=20 country the messages originate. "Identifying clients"=20 doesn't accomplish much if a legitimate, honest user finds=20 that their machine has been infected. What do you want to=20 do, sue the previous, also-innocent victim? Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Jan 30 23:45:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7K2-0004YI-Ex; Tue, 30 Jan 2007 23:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7K1-0004YA-R3 for asrg@ietf.org; Tue, 30 Jan 2007 23:43:49 -0500 Received: from mail1.panix.com ([166.84.1.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7Js-0004e3-Mp for asrg@ietf.org; Tue, 30 Jan 2007 23:43:49 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 55E2C5883E for ; Tue, 30 Jan 2007 23:43:36 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l0V4haP03136; Tue, 30 Jan 2007 23:43:36 -0500 (EST) Date: Tue, 30 Jan 2007 23:43:36 -0500 (EST) Message-Id: <200701310443.l0V4haP03136@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (gep2@terabites.com) Subject: Re: [Asrg] How about we do something about spam? References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org wrote: > [problem of botnets as spam originators] > The solution to the problem is actually AMAZINGLY > simple... I know that a lot of y'all have this fixation on > IP-based solutions, but a FAR better solution (rather than > attempting to block spam AFTER the botnets are recruited) > is to block the virus/worm code-containing E-mail messages > BEFORE they infect those computers. > > And that is really rather easy... you simply block any > HTML or attachments (and particularly EXECUTABLE > attachments) that isn't coming from a sender that is known > and trusted by the recipient TO SEND THEM EXECUTABLE > CONTENT. Pray tell, how am _I_ to block the executable content from some dialup luser on level3's machine? All _I_ can do is block his emissions from _my_ machines. > Note that MOST users (probably 98-99%) will not whitelist > ANYBODY to send them executable content in E-mails...! Are you considering .jpg to be executable? > The other way that botnets are recruited are by people > visiting infectious Web sites, but that is a problem for a > different list. But the *spam* emitted by those machines _is_ a problem for this list. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 00:27:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7xX-0000U7-K9; Wed, 31 Jan 2007 00:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7xW-0000U1-Jo for asrg@ietf.org; Wed, 31 Jan 2007 00:24:38 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7xV-0000Br-C0 for asrg@ietf.org; Wed, 31 Jan 2007 00:24:38 -0500 Received: by ug-out-1314.google.com with SMTP id 72so75129ugd for ; Tue, 30 Jan 2007 21:24:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Px5YEKT4dcgYYAA0Z5B0brOISnGB0VKpapkM/YkVO7GOTd2gEkp5gfLASMcDtjVLf8UWqQ1e4VEXHnVuBaOj+n5LR1P4G1zUdpbKTmP5XVIv48rZZp8yaTUFiFsIlhzYOWfkL73sHb4bgS/XLJLqrjAK1Pzpi1asnYwFjOF8Rjo= Received: by 10.78.201.2 with SMTP id y2mr59683huf.1170221076305; Tue, 30 Jan 2007 21:24:36 -0800 (PST) Received: by 10.78.20.9 with HTTP; Tue, 30 Jan 2007 21:24:36 -0800 (PST) Message-ID: <934f64a20701302124y21a7dd3byc5e9b3b54a590cb@mail.gmail.com> Date: Tue, 30 Jan 2007 23:24:36 -0600 From: "David Nicol" To: "anti-spam research group" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Asrg] please disregard message from me sent to asrg list by accident X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org as in subject. My apologies. Can't go trusting "autocomplete" to always do the right thing. I wonder if the fellow who is working on per-correspondent statistical profiles will incorporate flagging for confirmation of outbounds as well that do not match what is normally sent _to_ a peer: that feature might have helped in this case. "Big Dave" Nicol _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 01:16:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC8iz-0007N8-PE; Wed, 31 Jan 2007 01:13:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC8iy-0007Mt-6F for asrg@ietf.org; Wed, 31 Jan 2007 01:13:40 -0500 Received: from mpls-qmqp-02.inet.qwest.net ([63.231.195.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HC8iw-00017D-RL for asrg@ietf.org; Wed, 31 Jan 2007 01:13:40 -0500 Received: from mpls-pop-02.inet.qwest.net (mpls-pop-02.inet.qwest.net [63.231.195.2]) by mpls-qmqp-02.inet.qwest.net (Postfix) with QMQP id 6787053BCDA for ; Wed, 31 Jan 2007 06:13:38 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-02.inet.qwest.net with SMTP; 31 Jan 2007 06:13:38 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] How about we do something about spam? Date: Tue, 30 Jan 2007 23:13:37 -0700 To: Anti Spam Research Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org From: dan_oetting@qwest.net Subject: Re: [Asrg] How about we do something about spam? Date: January 30, 2007 11:11:25 PM MST To: gep2@terabites.com On Jan 30, 2007, at 9:07 PM, gep2@terabites.com wrote: > [problem of botnets as spam originators] > > The solution to the problem is actually AMAZINGLY simple... I know > that a lot of y'all have this fixation on IP-based solutions, but a > FAR better solution (rather than attempting to block spam AFTER the > botnets are recruited) is to block the virus/worm code-containing E- > mail messages BEFORE they infect those computers. > > And that is really rather easy... you simply block any HTML or > attachments (and particularly EXECUTABLE attachments) that isn't > coming from a sender that is known and trusted by the recipient TO > SEND THEM EXECUTABLE CONTENT. At the risk of giving the criminals more ideas, what if there is a stealth virus that watches who you send executable attachments to and every once in a while attaches itself to one of those emails by infecting the application that you are already sending? > Note that MOST users (probably 98-99%) will not whitelist ANYBODY > to send them executable content in E-mails...! From a quick survey, I would say that 90% of the participants on this list don't even consider it a possibility that a silly windows virus in an email attachment could infect their machine. Most of the rest would be adequately protected. Some though may actively seek the viruses so they can disassemble them. But then, this isn't a typical user population. A substantial portion of the net user population are actively exchanging executable files. I even get the occasional executable file from my dad forwarded through a long chain of friends. He complains sometimes about not being able to open them at home but forwards them to his office where they will run. > The other way that botnets are recruited are by people visiting > infectious Web sites, but that is a problem for a different list. There are lots of other vectors for passing malicious code to machines willing to suck it in. But I don't believe in blocking legitimate activity to stop a few criminals that also use that activity. If an ISP can block executable attachments in the "hope" of preventing a users machine from getting infected then they can just as easily unplug that users machine from the net IF it gets infected and starts abusing the net. If an ISP wants to be proactive they could supply anti-virus tools like a Linux installer for their customers. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 09:45:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGfx-0004QU-1j; Wed, 31 Jan 2007 09:43:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGfv-0004QG-6n for asrg@ietf.org; Wed, 31 Jan 2007 09:43:03 -0500 Received: from ns1.nixcartel.com ([66.98.212.93] helo=tin.nixcartel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGfp-0003LN-Qg for asrg@ietf.org; Wed, 31 Jan 2007 09:43:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tin.nixcartel.org (Postfix) with ESMTP id 8FD1B1AC297 for ; Wed, 31 Jan 2007 09:27:56 -0600 (CST) Received: from tin.nixcartel.org ([127.0.0.1]) by localhost (tin.nixcartel.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10173-07 for ; Wed, 31 Jan 2007 09:27:56 -0600 (CST) Received: from dvb.homelinux.org (unknown [210.18.157.242]) by tin.nixcartel.org (Postfix) with ESMTP id 282921AC28F for ; Wed, 31 Jan 2007 09:27:56 -0600 (CST) Received: by dvb.homelinux.org (Postfix, from userid 1000) id 69BFFB1E41; Wed, 31 Jan 2007 20:11:07 +0530 (IST) Date: Wed, 31 Jan 2007 20:11:07 +0530 From: Devdas Bhagat To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? Message-ID: <20070131144107.GA8433@dvb> Mail-Followup-To: asrg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new at example.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devdas Bhagat List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 30/01/07 22:07 -0600, gep2@terabites.com wrote: > The solution to the problem is actually AMAZINGLY > simple... I know that a lot of y'all have this fixation on > IP-based solutions, but a FAR better solution (rather than > attempting to block spam AFTER the botnets are recruited) > is to block the virus/worm code-containing E-mail messages > BEFORE they infect those computers. > Ideally. On the other hand, that option is often not in our hands. > And that is really rather easy... you simply block any > HTML or attachments (and particularly EXECUTABLE > attachments) that isn't coming from a sender that is known > and trusted by the recipient TO SEND THEM EXECUTABLE > CONTENT. > Recipients are very often not in a position to make that judgement. Also, how many of those trojans spread via browser exploits, spyware, or other similar techniques? The email exploit vector is mostly focussing on getting people to visit websites rather than actual distribution of exploit code. Now the idea of suing people who allow their hosts to stay infected is one I like. A few headline making cases and we *might* have results. Devdas Bhagat _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 11:07:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHxs-0008Qo-HG; Wed, 31 Jan 2007 11:05:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHxq-0008Q9-U2 for asrg@ietf.org; Wed, 31 Jan 2007 11:05:38 -0500 Received: from mail.crlf.net ([216.235.14.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHxf-0004NZ-KA for asrg@ietf.org; Wed, 31 Jan 2007 11:05:38 -0500 Received: by mail.crlf.net (Postfix, from userid 1000) id 0146B87075; Wed, 31 Jan 2007 11:05:21 -0500 (EST) Date: Wed, 31 Jan 2007 11:05:21 -0500 From: David Maxwell To: gep2@terabites.com Subject: Re: [Asrg] How about we do something about spam? Message-ID: <20070131160521.GG21178@mail> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: asrg@ietf.org, bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, Jan 30, 2007 at 10:07:51PM -0600, gep2@terabites.com wrote: > [problem of botnets as spam originators] > The solution to the problem is actually AMAZINGLY > simple... I know that a lot of y'all have this fixation on > IP-based solutions, but a FAR better solution (rather than > attempting to block spam AFTER the botnets are recruited) > is to block the virus/worm code-containing E-mail messages > BEFORE they infect those computers. > > And that is really rather easy... you simply block any > HTML or attachments (and particularly EXECUTABLE > attachments) that isn't coming from a sender that is known > and trusted by the recipient TO SEND THEM EXECUTABLE > CONTENT. > > Note that MOST users (probably 98-99%) will not whitelist > ANYBODY to send them executable content in E-mails...! The reason people have a fixation on IP-based, or signature-based identification mechanisms is simple. Without a guarantee of 'identity', you can't whitelist someone. You'll end up adding a whitelist entry which viruses will forge mail from in order to get to your inbox. A whitelist is simply an end-user accredited reputation service. Like all reputation mechanisms, it makes no sense if the entity being queried for can not be proven to be the same as the one being vouched for. -- David Maxwell, david@vex.net|david@maxwell.net --> Although some of you out there might find a microwave oven controlled by a Unix system an attractive idea, controlling a microwave oven is easily accomplished with the smallest of microcontrollers. - Russ Hersch - (Microcontroller primer and FAQ) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 12:37:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJM6-00034f-Lx; Wed, 31 Jan 2007 12:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJM5-00034Z-Tf for asrg@ietf.org; Wed, 31 Jan 2007 12:34:45 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJM4-0001Iz-GG for asrg@ietf.org; Wed, 31 Jan 2007 12:34:45 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l0VHYf4l007836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Jan 2007 09:34:41 -0800 Subject: Re: [Asrg] How about we do something about spam? From: Douglas Otis To: David Maxwell In-Reply-To: <20070131160521.GG21178@mail> References: <20070131160521.GG21178@mail> Content-Type: text/plain Date: Wed, 31 Jan 2007 09:34:41 -0800 Message-Id: <1170264881.3123.89.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: gep2@terabites.com, asrg@ietf.org, bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Wed, 2007-01-31 at 11:05 -0500, David Maxwell wrote: > The reason people have a fixation on IP-based, or signature-based > identification mechanisms is simple. > > Without a guarantee of 'identity', you can't whitelist someone. You'll > end up adding a whitelist entry which viruses will forge mail from in > order to get to your inbox. > > A whitelist is simply an end-user accredited reputation service. Like > all reputation mechanisms, it makes no sense if the entity being queried > for can not be proven to be the same as the one being vouched for. There should be a generalized rule to not automatically process information from unknown sources. Processing includes fetching images, running scripts, validating digital signatures, and verifying IP address authorization (especially when this might require hundreds of transactions). Such a rule will not expose internal handling and minimizes risks associated with DDoS attacks. Only when a _trusted_ source has been verified, should the message be annotated. A recipient's address book could be one method of determining a trusted domain where out-of-band verification techniques can be employed. DKIM can enable opportunistic security once autonomous association is permitted. Autonomous association allows the use of DKIM to scale and to obtain "critical mass". DKIM permits message replay. A message signed by a major ISP can be replayed from any other location. The DKIM signature might prevent false positive detection of phishing attempts, but it would be risky in many cases to use a DKIM signature as a basis of acceptance white-listing. A means to correlate DKIM domains with that of a verified SMTP client could permit DKIM serving as a basis of acceptance. A similar strategy could be used for qualifying DSN. See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 12:41:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJSM-0004Cy-Vu; Wed, 31 Jan 2007 12:41:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJSL-0004Co-Qs for asrg@ietf.org; Wed, 31 Jan 2007 12:41:13 -0500 Received: from egress3.webmaillogin.com ([216.40.36.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJSJ-0003GL-AJ for asrg@ietf.org; Wed, 31 Jan 2007 12:41:13 -0500 Received: by egress3.webmaillogin.com (egress3.webmaillogin.com, from userid 1006) id 832E65B4283; Wed, 31 Jan 2007 12:40:59 -0500 (EST) Received: from webmaillogin.com (fr5.webmaillogin.com [216.40.35.69]) by egress3.webmaillogin.com (egress3.webmaillogin.com) with ESMTP id DD998208199; Wed, 31 Jan 2007 12:39:49 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk1.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61746483; Wed, 31 Jan 2007 12:39:49 -0500 From: Subject: Re: [Asrg] How about we do something about spam? To: David Maxwell X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Wed, 31 Jan 2007 11:39:49 -0600 Message-ID: In-Reply-To: <20070131160521.GG21178@mail> References: <20070131160521.GG21178@mail> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: asrg@ietf.org, bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Wed, 31 Jan 2007 11:05:21 -0500 David Maxwell wrote: > On Tue, Jan 30, 2007 at 10:07:51PM -0600,=20 >gep2@terabites.com wrote: >> [problem of botnets as spam originators] >> The solution to the problem is actually AMAZINGLY=20 >> simple... I know that a lot of y'all have this fixation=20 >>on=20 >> IP-based solutions, but a FAR better solution (rather=20 >>than=20 >> attempting to block spam AFTER the botnets are=20 >>recruited)=20 >> is to block the virus/worm code-containing E-mail=20 >>messages=20 >> BEFORE they infect those computers. >>=20 >> And that is really rather easy... you simply block any=20 >> HTML or attachments (and particularly EXECUTABLE=20 >> attachments) that isn't coming from a sender that is=20 >>known=20 >> and trusted by the recipient TO SEND THEM EXECUTABLE=20 >> CONTENT. >>=20 >> Note that MOST users (probably 98-99%) will not=20 >>whitelist=20 >> ANYBODY to send them executable content in E-mails...! >=20 > The reason people have a fixation on IP-based, or=20 >signature-based > identification mechanisms is simple. >=20 > Without a guarantee of 'identity', you can't whitelist=20 >someone. You'll > end up adding a whitelist entry which viruses will forge=20 >mail from in > order to get to your inbox. Well, it IS likely that desperate spammers would try to=20 forge mail to seem like it comes from widely-trusted=20 senders who recipients are likely to have some kind of=20 whitelist entries for. On the other hand, that still limits spammers and viruses=20 in terms of WHAT they can send, and encourages legitimate=20 senders to not send types of content which are likely to=20 be misused for malicious purposes by forgers. > A whitelist is simply an end-user accredited reputation=20 >service.=20 If it were a simple go/no-go whitelist, yes. The fact of=20 it being a fine-grained whitelist is a horse of a=20 different color, because it also creates a narrow=20 sender-specific keyway through which mail from THAT=20 SPECIFIC sender must fit in order to be accepted. > Like > all reputation mechanisms, it makes no sense if the=20 >entity being queried > for can not be proven to be the same as the one being=20 >vouched for. While that's a valid point, I'll also point out that once=20 an E-mail has gone through an intermediary MTA, (in fact,=20 even BEFORE then) it's hard to be 100% sure where it=20 originally came from in IP address terms, either.=20 Spammers OFTEN forge counterfeit, bogus Received: headers=20 too. So what's to prevent them from forging a Received: header=20 with a trusted-sender IP address? The bottom line is that the best way to decide that an=20 E-mail is legitimate or not is by examining THE TOTALITY=20 of the information available, and that goes well beyond=20 the information in the headers. It includes relating the=20 CONTENT of the mail to what the recipient expects from=20 that sender. If someone got, for example, an e-mail that claimed to be=20 from me but which was all in chinese characters, they=20 would probably quickly conclude that my return address was=20 forged. The fact remains that putting so much effort behind=20 IP-address-based solutions will NEVER yield as good a=20 solution as a solution which includes message content=20 analysis ("SpamAssassin" or similar), ALONG WITH=20 fine-grained, sender-specific rules which robustly deny=20 spammers nearly all the tricks that they use to evade=20 content analysis filtering. And the OTHER major thing we need to do is to come up with=20 a set of "best practice" guidelines (probably based on the=20 "fine grained whitelist" and suitable default rules like=20 I've proposed here) which basically eliminate E-mail as a=20 recruitment mechanism for zombie spambot armies. Forcing=20 spammers to directly use their own machines for spamming=20 would put a MAJOR crimp in their operations, and help make=20 virtually all the other anti-spamming approaches to be a=20 lot more effective. I honestly don't understand why we're even still arguing=20 about this. It's obvious that it makes for a HUGE=20 improvement, and obvious that it can be implemented=20 without having to re-engineer the whole E-mail system or=20 the whole Internet. The biggest area of discussion is that it would=20 (admittedly) be nicer to truncate the unwanted E-mail=20 earlier in the distribution chain. But that's not=20 critical, at least from the end-user position. More to the point is that if we DO implement this at the=20 end-user position, nearly everywhere, spammers simply will=20 give up trying to send E-mail that they KNOW will get=20 through in only such tiny numbers that it simply isn't=20 worth the effort anymore. At THAT point it doesn't matter where we truncate the=20 flow, because the only people still trying are those who=20 are simply trying to play with the infrastructure of the=20 Net, and: 1) there isn't any money to be made doing that; 2) it's about as satisfying as trying to argue with a=20 vending machine that stole your money. So it probably isn't NECESSARY to stop the transit earlier=20 in distribution, if it WILL be stopped SOMEWHERE enroute=20 (even at the end). At least we can offer relief to the great majority of=20 Internet users, and reduce the remaining problem (if there=20 still is one) to something that ISPs and backbone=20 operators can deal with. BTW, that's another reason for my proposal that we limit=20 the maximum size of non-whitelisted E-mails, too... so=20 hopefully the bandwidth used by such residual spam=20 messages will become smaller, as a percentage of total=20 backbone traffic, as legitimate higher-volume traffic=20 (video webcams, high-quality streaming audio, video=20 streaming, etc) become dominant. Hopefully it will also=20 help discourage the spammers possibly shifting to bulkier=20 types of messages which clog inboxes and the limited=20 bandwidth of dialup users. =20 Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 13:15:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJzM-0000SL-La; Wed, 31 Jan 2007 13:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJzL-0000Qp-JP for asrg@ietf.org; Wed, 31 Jan 2007 13:15:19 -0500 Received: from egress4.webmaillogin.com ([216.40.36.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJud-0003DE-Vn for asrg@ietf.org; Wed, 31 Jan 2007 13:10:29 -0500 Received: by egress4.webmaillogin.com (egress4.webmaillogin.com, from userid 1005) id EF7C6771D79; Wed, 31 Jan 2007 13:10:24 -0500 (EST) Received: from webmaillogin.com (fr7.webmaillogin.com [216.40.35.71]) by egress4.webmaillogin.com (egress4.webmaillogin.com) with ESMTP id BD20477204A; Wed, 31 Jan 2007 12:58:39 -0500 (EST) Received: from [76.187.176.198] (account gep2a@terabites.com) by bk1.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 61747457; Wed, 31 Jan 2007 12:54:42 -0500 From: Subject: Re: [Asrg] How about we do something about spam? To: Douglas Otis ,David Maxwell X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Wed, 31 Jan 2007 11:54:42 -0600 Message-ID: In-Reply-To: <1170264881.3123.89.camel@dcore.sonic.net> References: <20070131160521.GG21178@mail> <1170264881.3123.89.camel@dcore.sonic.net> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: asrg@ietf.org, bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > There should be a generalized rule to not automatically=20 >process > information from unknown sources. Processing includes=20 >fetching images, > running scripts, validating digital signatures, and=20 >verifying IP address > authorization (especially when this might require=20 >hundreds of > transactions). Such a rule will not expose internal=20 >handling and > minimizes risks associated with DDoS attacks. >=20 > Only when a _trusted_ source has been verified, should=20 >the message be > annotated. A recipient's address book could be one=20 >method of > determining a trusted domain where out-of-band=20 >verification techniques > can be employed. =20 I certainly agree that a major part of the solution is to=20 not process dangerous E-mail arriving from=20 unfamiliar/untrusted senders. That said, we need to provide a default rule which allows=20 receiving "safe" mail from new, first-time senders=20 (long-lost friends, Customer Service requests from=20 customers, etc), subject to SpamAssassin-like=20 determination that it doesn't "look like" spam. As for DKIM, I don't have strong opinions one way or the=20 other at this point, but continue to remind folks that=20 sometimes people send legitimate E-mail messages from=20 inhabitual locations. This could be a cruise ship=20 Internet cafe, an Internet E-mail sending room in a post=20 office in Beijing, or a "business center" in a hotel. I=20 think it's far more important WHAT IS IN the E-mail than=20 where it "came" from. Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area=20 networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 13:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKXB-000596-3e; Wed, 31 Jan 2007 13:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKXA-000590-LP for asrg@ietf.org; Wed, 31 Jan 2007 13:50:16 -0500 Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCKX9-00089u-FQ for asrg@ietf.org; Wed, 31 Jan 2007 13:50:16 -0500 Received: (qmail 4275 invoked from network); 31 Jan 2007 18:50:13 -0000 Received: from mail.iecc.com (208.31.42.99) by mail.iecc.com with QMQP; 31 Jan 2007 18:50:13 -0000 Date: 31 Jan 2007 18:50:12 -0000 Message-ID: <20070131185012.15685.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] asrg wiki, was How about we do something about spam? In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: william@elan.net X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >> I can certainly set one up. To keep the wikispam under control, anyone >> who wants to contribute will have to register and confirm an e-mail address. > >I'm not against it, but wasnt there attempt to do it before for ASRG >already that did not produce much results? Yup. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 14:58:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLZR-0007hf-6p; Wed, 31 Jan 2007 14:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLZQ-0007ha-03 for asrg@ietf.org; Wed, 31 Jan 2007 14:56:40 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLZM-0001T2-NE for asrg@ietf.org; Wed, 31 Jan 2007 14:56:39 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0VJpvvi000383 for ; Wed, 31 Jan 2007 14:51:59 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0VJpgZs014739; Wed, 31 Jan 2007 14:51:42 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17856.62286.468183.171586@world.std.com> Date: Wed, 31 Jan 2007 14:51:42 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <20070130231156.BD72D32CBF@radish.jmason.org> References: <17855.52294.729384.356913@world.std.com> <20070130231156.BD72D32CBF@radish.jmason.org> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Virus-Scanned: ClamAV 0.88.4/2508/Wed Jan 31 11:42:50 2007 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On January 30, 2007 at 23:11 jm@jmason.org (Justin Mason) wrote: > > Barry Shein writes: > > Put another way, it would be naive to wait for LEOs, policy-makers, > > regulators, et al, to discover for themselves how they can help. > > For what it's worth, LEOs are certainly attending plenty of conferences > and private get-togethers that cover these points; APWG, London Action > Plan, and probably others, all feature law enforcement. I'm not surprised there's some interest, but that's not quite the same as trying to generate the thrust for an Operation Asimov: Kill the misbehaving zombie robots and bust their human masters. That takes money, resources, and drive at a high level, as we've seen US Atty Genl Gonzales' office internet child porn initiatives. Some confirmation from respected sources might help. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 16:54:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNNf-0004vF-G7; Wed, 31 Jan 2007 16:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNNe-0004uw-0M for asrg@ietf.org; Wed, 31 Jan 2007 16:52:38 -0500 Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCNNc-0003Kr-Q9 for asrg@ietf.org; Wed, 31 Jan 2007 16:52:37 -0500 Received: (qmail 21643 invoked from network); 31 Jan 2007 21:52:35 -0000 Received: from mail.iecc.com (208.31.42.99) by mail.iecc.com with QMQP; 31 Jan 2007 21:52:35 -0000 Date: 31 Jan 2007 21:52:35 -0000 Message-ID: <20070131215235.9381.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <17856.62286.468183.171586@world.std.com> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: bzs@world.std.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >Some confirmation from respected sources might help. Well, at this moment, I am sitting in a session at MAAWG where the FTC's lead spam investigator is telling us about his investigation process and he and ISP reps are going over issues like whether they notify customers when they get a subpoena. Also present are the Canadian competition bureau, analogous to the FTC, and I believe I saw some guys from DOJ. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 18:37:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOyZ-0001eU-F7; Wed, 31 Jan 2007 18:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOyY-0001dW-4g for asrg@ietf.org; Wed, 31 Jan 2007 18:34:50 -0500 Received: from pcls6.std.com ([192.74.137.146] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCOyV-0005Sg-N5 for asrg@ietf.org; Wed, 31 Jan 2007 18:34:50 -0500 Received: from world.std.com (sja@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l0VNXCdn006647 for ; Wed, 31 Jan 2007 18:33:14 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l0VNWOPn006258; Wed, 31 Jan 2007 18:32:24 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17857.9992.58654.806936@world.std.com> Date: Wed, 31 Jan 2007 18:32:24 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <20070131215235.9381.qmail@simone.iecc.com> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls6.std.com X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls6.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On January 31, 2007 at 21:52 asrg@johnlevine.com (John Levine) wrote: > >Some confirmation from respected sources might help. > > Well, at this moment, I am sitting in a session at MAAWG where the > FTC's lead spam investigator is telling us about his investigation > process and he and ISP reps are going over issues like whether they > notify customers when they get a subpoena. Also present are the > Canadian competition bureau, analogous to the FTC, and I believe I saw > some guys from DOJ. Well that's of course great but some publicized thrust and focus from the IETF couldn't hurt the thinking of the policymakers who have to actually allocate budgets and other priorities. Is there any disagreement that if we could just snap our fingers and make the zombie botnets disappear (or 90% disappear) that "spam" (and related) wouldn't immediately have all the emotional punch of "off-topic posting", some odd msg you get and delete? Put another way, zombie botnets are the enabling technology of spam (phishing, etc.) Easier said than done I realize, but it's inherently illegal to create and operate zombie botnets, and I don't mean just in the US, most anywhere on the planet. The law enforcement and regulatory agencies of the planet have a lot more resources they can muster than we ever could. Even if we could come up with the FUSSP we'd still probably face enormous hurdles of deployment. Vigorous legal pursuit wouldn't preclude technical efforts in parallel unless of course spam just disappears as a result. There is no other way we know of to send out on the order of one billion emails per day for a cost which even approaches the expected value of those messages and would so successfully evade already commonplace blocking and filtering methods. Does anyone disagree with that? Can't we say that in some very public way? Does anyone doubt that's true? Sometimes I think the problem otherwise insightful technical people have in thinking about spam is wrapping their heads around what it takes to send out O(billion) messages a day from a handful of base sources and we keep retreating to imagining spam as being much like sending this message other than the content and intent. It's not. It's as if I could make this message appear in 100 million mailboxes in the next few hours, despite many efforts to the contrary. I couldn't. You couldn't. It takes a zombie botnet. There are other issues, but I'm focusing on this one as the most egregious and, I hope, easiest to agree on in terms of contribution to the problem and legal/moral unambiguity. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 21:29:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRfB-0000vI-PO; Wed, 31 Jan 2007 21:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRfA-0000v6-Co for asrg@ietf.org; Wed, 31 Jan 2007 21:27:00 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCRf7-0006Xp-Sj for asrg@ietf.org; Wed, 31 Jan 2007 21:27:00 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l112QujU028247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jan 2007 18:26:57 -0800 In-Reply-To: <17857.9992.58654.806936@world.std.com> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Wed, 31 Jan 2007 18:27:06 -0800 To: Barry Shein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 31, 2007, at 3:32 PM, Barry Shein wrote: > > On January 31, 2007 at 21:52 asrg@johnlevine.com (John Levine) wrote: >>> Some confirmation from respected sources might help. >> >> Well, at this moment, I am sitting in a session at MAAWG where the >> FTC's lead spam investigator is telling us about his investigation >> process and he and ISP reps are going over issues like whether >> they notify customers when they get a subpoena. Also present are >> the Canadian competition bureau, analogous to the FTC, and I >> believe I saw some guys from DOJ. > > Well that's of course great but some publicized thrust and focus > from the IETF couldn't hurt the thinking of the policymakers who > have to actually allocate budgets and other priorities. > > Is there any disagreement that if we could just snap our fingers > and make the zombie botnets disappear (or 90% disappear) that > "spam" (and related) wouldn't immediately have all the emotional > punch of "off-topic posting", some odd msg you get and delete? > > Put another way, zombie botnets are the enabling technology of spam > (phishing, etc.) Put another way, legalizing spam enables high infection rates needed to support the existence of Bot-Nets. Malware content within an email message and websites (required to OPT-OUT) provide bad actors ample opportunity to leverage exploits that exist in email or website browsers. The completely absurd stipulations of OPT-OUT is satisfied by a link to a web site of all things. CAN-SPAM mandates victims expose themselves to two very likely modes of infection. Browsers continuously have new and complex features added, where many flaws exist and can be exploited. Bulk messaging with embedded links provides a highly dangerous infection vector. > Easier said than done I realize, but it's inherently illegal to > create and operate zombie botnets, and I don't mean just in the US, > most anywhere on the planet. By making spam illegal, the act of transmitting a high volume of unsolicited messages would then clearly serve as evidence of crime. This would place accountability onto the provider. The efforts behind SPF and DKIM are aimed at passing blame to a hapless customer. Thousand of domains might share an SPF authorized server which is likely to have only a few IP addresses. The identity limitations with DKIM ensures providers will also control their customer's private keys. Who sent and signed the message is _designed_ to remain a mystery. Some mode of accountability. > The law enforcement and regulatory agencies of the planet have a > lot more resources they can muster than we ever could. Providers must acknowledge they are primarily responsible for much of the mess that exists. Providers must be held accountable when any high volume of unsolicited messaging emerges from their networks. > Even if we could come up with the FUSSP we'd still probably face > enormous hurdles of deployment. The first step would be to make spam illegal. Illegal for individuals to send, and for providers to ignore. After all, providers control access. Allow those damaged to seek relief. Making spam illegal would make networks many orders of magnitude safer. > Vigorous legal pursuit wouldn't preclude technical efforts in > parallel unless of course spam just disappears as a result. Twice the technological effort is attempting to pass blame to some likely hapless customer. Make a law that requires providers sign all public messages with their own keys. There should even be laws that prohibit signing with a customer's key. Customers can reference specific keys used on their behalf instead. There should be laws against the use of highly danger authorization schemes, such as SPF/ Sender-ID. Poisoning or destroying DNS is easily accomplish with this loathsome technology. A technology also aimed at side stepping accountability. > There is no other way we know of to send out on the order of one > billion emails per day for a cost which even approaches the > expected value of those messages and would so successfully evade > already commonplace blocking and filtering methods. > > Does anyone disagree with that? Enforcement must make any spam illegal AND hold providers accountable. To ensure enforcement, allow anyone damaged to seek legal relief. > Can't we say that in some very public way? Does anyone doubt that's > true? There are few providers that want to consider their accountability as part of the cost of doing business. No one can afford to clean up the mess being made. Just as was done to control the abuse of fax machines, the same must be done with respect to email. At least with a fax machine, programs were not in jeopardy, just resources. > Sometimes I think the problem otherwise insightful technical people > have in thinking about spam is wrapping their heads around what it > takes to send out O(billion) messages a day from a handful of base > sources and we keep retreating to imagining spam as being much like > sending this message other than the content and intent. > > It's not. Content or intent do not need to be considered. The volume and lack of solicitation provides key differences. The lack of solicitation allows for rather easy methods of enforcement. One grows weary logging trespasses that can only be considered privately as bad. Those making these private assessments remain exposed to civil proceeding as a result. Spam must be illegal to stop it. There are very few legitimate businesses using spam to promote their products, and yet the US Congress has legalized spam. OPT-OUT is a dangerous, impractical, and an immoral excuse. > It's as if I could make this message appear in 100 million > mailboxes in the next few hours, despite many efforts to the contrary. The number of messages does not matter. The number of unsolicited messages does. > I couldn't. You couldn't. Not true. There are some rather large mailing lists where such volumes are possible. Lists enjoying a large number of subscribers are also typically well managed. > It takes a zombie botnet. There are many other techniques. Malware provides many avenues to exploit networks. Make spam illegal to slow the spread of malware. > There are other issues, but I'm focusing on this one as the most > egregious and, I hope, easiest to agree on in terms of contribution > to the problem and legal/moral unambiguity. You seem to have the cart before the horse. In addition to spam, perhaps other rules could be considered regarding system scanning. This again would require that providers take action to block access. Vista comes equipped with what is likely an ideal command and control system for controlling Bot armies. The system must protect from the spread of infection. Prevention is worth a pound of cure. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Jan 31 21:55:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCS5W-0000cs-DN; Wed, 31 Jan 2007 21:54:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCS5U-0000cG-NK for asrg@ietf.org; Wed, 31 Jan 2007 21:54:13 -0500 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCS5T-00081x-EG for asrg@ietf.org; Wed, 31 Jan 2007 21:54:12 -0500 Received: from world.std.com (root@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l112s8ld018585 for ; Wed, 31 Jan 2007 21:54:10 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.12.8) id l112s8XT026251; Wed, 31 Jan 2007 21:54:08 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17857.22096.267216.638009@world.std.com> Date: Wed, 31 Jan 2007 21:54:08 -0500 To: asrg@ietf.org Subject: Re: [Asrg] How about we do something about spam? In-Reply-To: <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> X-Mailer: VM 7.07 under Emacs 21.2.2 X-Spam-Status: No, score=-4.2 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on pcls5.std.com X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on pcls5.std.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org You seem to prefer a technological solution, possibly with some new legislation making "spam" illegal. I have no particular problem with that, in spirit. But I do believe that a more immediate goal of urging law enforcement (et al) to better enforce existing laws (&c) regarding the creation and operation of, e.g., zombie botnets is valuable without in any way detracting from other efforts stated. Put another way, we don't board up all our windows and let burglars run free. We try to make burglary dangerous for burglars. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg