From Francis.Dupont@fdupont.fr Sun May 31 14:44:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EEC3A6FB3 for ; Sun, 31 May 2009 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nguwlmBRwiuS for ; Sun, 31 May 2009 14:44:33 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id C2A833A6FC8 for ; Sun, 31 May 2009 14:44:29 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n4VLiHIs055354; Sun, 31 May 2009 23:44:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200905312144.n4VLiHIs055354@givry.fdupont.fr> From: Francis Dupont To: Masataka Ohta In-reply-to: Your message of Sun, 31 May 2009 08:27:07 +0900. <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> Date: Sun, 31 May 2009 23:44:17 +0200 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 01 Jun 2009 07:30:25 -0700 Cc: Anti-Spam Research Group - IRTF , ietf@ietf.org Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 21:44:33 -0000 In your previous mail you wrote: > => not only this is very arguable (for instance about the resource > exhaustion) but no hop-by-hop/channel security, even something as > strong as TSIG, can provide what we need, i.e., end-to-end/object > security (*). > PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one. => I added it because hop-by-hop and end-to-end can be ambiguous when hops and ends are not defined. In the context of DNS intermediate entities are the caching servers so even I agree your argument is valid it doesn't apply to *this* interpretation of the term end-to-end. Regards Francis.Dupont@fdupont.fr PS: if you'd like to discuss about end-to-end arguments there is a dedicated mailing list at IRTF. If you'd like to continue about the trusted third parties as intermediate entities I believe the thread you initiated is the best place. From huitema@windows.microsoft.com Sat May 30 17:28:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A434A3A684D for ; Sat, 30 May 2009 17:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.576 X-Spam-Level: X-Spam-Status: No, score=-109.576 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKsX7XRyQ9aO for ; Sat, 30 May 2009 17:28:24 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 871CE3A6823 for ; Sat, 30 May 2009 17:28:24 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 30 May 2009 17:29:09 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.582.9; Sat, 30 May 2009 17:29:08 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) with Microsoft SMTP Server (TLS) id 14.0.582.7; Sat, 30 May 2009 17:29:22 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Sat, 30 May 2009 17:29:08 -0700 From: Christian Huitema To: Masataka Ohta , Francis Dupont Date: Sat, 30 May 2009 17:29:21 -0700 Thread-Topic: DNSSEC is NOT secure end to end Thread-Index: Acnhf0YVYXzuOdf1TmmMvuUJhj0vmgABCE+w Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> In-Reply-To: <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 01 Jun 2009 07:30:44 -0700 Cc: "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 07:46:47 -0000 > That is, security of DNSSEC involves third parties and is not end > to end. That is indeed correct. An attacker can build a fake hierarchy of "secure D= NS" assertions and try to get it accepted. The attack can succeed with the = complicity of one of the authorities in the hierarchy. It is a classic "att= ack by a trusted party". Problem is, hop-by-hop security will not protect against an attack by an in= termediate authority. If an intermediate authority has been compromised, it= can just as well insert a fake NS record -- that's not harder than a fake = record signature. Hop-by-hop security will securely connect to the wrong na= me server, to which the wrong NS record points... -- Christian Huitema From dotis@mail-abuse.org Mon Jun 1 15:02:51 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115943A6E14 for ; Mon, 1 Jun 2009 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzyRn2Qu+7M6 for ; Mon, 1 Jun 2009 15:02:49 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id B20B03A6A4F for ; Mon, 1 Jun 2009 15:02:49 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 18239A94439; Mon, 1 Jun 2009 22:02:48 +0000 (UTC) Message-Id: <1EEF65DD-7BE0-45C9-ABF2-3E452E92E157@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <873aal4nw7.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 15:02:47 -0700 References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <4A1A45BA.5030704@swin.edu.au> <3be421270905250718y5d62f6d5odb6f2bebecf418d0@mail.gmail.com> <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org> <200905251603.MAA16221@Sparkle.Rodents-Montreal.ORG> <4A1D64C9.5060505@tana.it> <47BC2197-472E-4615-97D2-F7E42B8F3B7D@mail-abuse.org> <87d49rraqd.fsf@mid.deneb.enyo.de> <892F581E-BCE7-48D2-B6C3-429F56B3A3F5@mail-abuse.org> <873aal4nw7.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.935.3) Cc: asrg@ietf.org Subject: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 22:02:51 -0000 On May 31, 2009, at 2:34 AM, Florian Weimer wrote: > >> On May 29, 2009, at 12:05 PM, Florian Weimer wrote: >> >>> * Douglas Otis: >> >>> Any modification to TCP that bypasses SYN/ACK handshakes for full- >>> duplex data is not TCP. > >> > From the point of view of a compliant connection initiator, it is > hardly distinguishable from a more traditional implementation. When "State-Free" TCP becomes indistinguishable, this similarity creates both security and compatibility issues. >> This approach omits source verification, and therefore is unable to >> mitigate spoofed reflected attacks. > > The packet count would not even be higher than ordinary TCP. If you > send a spoofed SYN to a compliant TCP server, it sends back three to > five SYN+ACKs, until it receives an ACK or an RST. Bandwidth is a > different matter, but that could be addressed by CNAME cookies > (although Cisco's patent may apply to that). TCP TTL first need to expire, freeing up server or firewall resources. Unless normal TCP is disabled, resources will be still stranded by SYN flood attacks, either at the firewall or server. >> The same effect could be achieved using EDNS0 options that extend >> both transaction-ids as well as packet size. > > Not really, EDNS0 is not suitable for communicating support of an > extended query ID. EDNS0 can change both the query and the answer. Transforming the structure of the query allows enhanced transactional IDs. However, until such an option is widely supported, this will only increase DNS latency and overhead. The same would be true when attempting to use otherwise bogus "State-Free" TCP transaction to support DNS. >>> The argument against TCP is not the protocol. It's just that you >>> have to upgrade both authoritative servers and resolvers to make >>> it work well. >> >> Huh? Why suggest radical changes to the TCP protocol, and then, in >> the same breath, say the problem is not the protocol? > > A lot of this has already been tried and proven in the HTTP context. > Claims that "TCP doesn't scale" or that "TCP is vulnerable to DoS > attacks" always sound very hollow to me. DNS handles a fraction of > the requests processed by HTTP and SMTP, and yet it can't be run on > TCP for protocol reasons? Come on. Don't underestimate DNS. Often TCP scales by using load-balancers and/ or a significant distribution of servers. >> Defending against DDoS attack was never a major consideration >> during early TCP or UDP development. Bot-nets weren't the problem >> they are today. Bastardizing TCP, rather than adopting properly >> designed protocols, is unlikely to provide a solutions, but instead >> likely to create new vulnerabilities. > > It's already being done for HTTP, and maybe to a lesser extent, for > SMTP. > > I'm not saying that it make sense to upgrade the DNS infrastructure > so that it can smoothly handle a TCP-centric load. Such a massive > upgrade could be better used to roll out something different. But > TCP itself is not the problem. In fact, experience with DoS attacks > against TCP services means that you've got a portfolio of solutions > to deal with attacks, something that would have yet to be developed > for a hypothetical non-TCP transport. Defensive solutions for TCP can not cope with the attack levels that might be created by a small bot-net. TCP quickly suffers from resource exhaustion. DNS over UDP avoids this propensity. However, the brute strength of DNS over UDP can be leveraged to attack other network infrastructure, and perhaps overwhelm resource capacity. This is especially a concern when an MTA authorization protocol ignores UDP exponential back-off and then prematurely initiates additional transactions. This is made even more destructive when message recipients generate an order of magnitude more transactions transformed by message local-parts directed toward any victim from fully cached DNS records. This provides for free DDoS attacks while spamming. These attacks might also be used to instigate DNS cache poisoning. The ability to poison DNS caches can be dramatically reduced by running DNS over SCTP. SCTP's ability to properly detect abusive sources allows mitigation efforts without causing an unfair loss of service. Neither UDP nor TCP employ the features needed to mitigate these types of attacks. The cost to mitigate TCP attacks quickly run into the millions, whereas DNS remains more robust and is more cost effective. Unfortunately, when adequately deployed, the brute strength of DNS creates its own risks. SCTP can be made robust and can mitigate most cache poisoning exploits ( but using 32 bit SCTP transaction-ID, 16 bit DNS transaction-ID, 16 bit port number, 16 bit stream number, SCTP-AUTH 32 bytes). SCTP can also be secured using TLS over SCTP, S-SCTP, AUTH-SCTP, as well as containing DNSSEC messages. -Doug From dotis@mail-abuse.org Mon Jun 1 15:02:51 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F8D28C0E2 for ; Mon, 1 Jun 2009 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weS70slE5V6X for ; Mon, 1 Jun 2009 15:02:49 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id A85183A69AB for ; Mon, 1 Jun 2009 15:02:49 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 18239A94439; Mon, 1 Jun 2009 22:02:48 +0000 (UTC) Message-Id: <1EEF65DD-7BE0-45C9-ABF2-3E452E92E157@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <873aal4nw7.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 15:02:47 -0700 References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <4A1A45BA.5030704@swin.edu.au> <3be421270905250718y5d62f6d5odb6f2bebecf418d0@mail.gmail.com> <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org> <200905251603.MAA16221@Sparkle.Rodents-Montreal.ORG> <4A1D64C9.5060505@tana.it> <47BC2197-472E-4615-97D2-F7E42B8F3B7D@mail-abuse.org> <87d49rraqd.fsf@mid.deneb.enyo.de> <892F581E-BCE7-48D2-B6C3-429F56B3A3F5@mail-abuse.org> <873aal4nw7.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.935.3) Cc: asrg@ietf.org Subject: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 22:02:51 -0000 On May 31, 2009, at 2:34 AM, Florian Weimer wrote: > >> On May 29, 2009, at 12:05 PM, Florian Weimer wrote: >> >>> * Douglas Otis: >> >>> Any modification to TCP that bypasses SYN/ACK handshakes for full- >>> duplex data is not TCP. > >> > From the point of view of a compliant connection initiator, it is > hardly distinguishable from a more traditional implementation. When "State-Free" TCP becomes indistinguishable, this similarity creates both security and compatibility issues. >> This approach omits source verification, and therefore is unable to >> mitigate spoofed reflected attacks. > > The packet count would not even be higher than ordinary TCP. If you > send a spoofed SYN to a compliant TCP server, it sends back three to > five SYN+ACKs, until it receives an ACK or an RST. Bandwidth is a > different matter, but that could be addressed by CNAME cookies > (although Cisco's patent may apply to that). TCP TTL first need to expire, freeing up server or firewall resources. Unless normal TCP is disabled, resources will be still stranded by SYN flood attacks, either at the firewall or server. >> The same effect could be achieved using EDNS0 options that extend >> both transaction-ids as well as packet size. > > Not really, EDNS0 is not suitable for communicating support of an > extended query ID. EDNS0 can change both the query and the answer. Transforming the structure of the query allows enhanced transactional IDs. However, until such an option is widely supported, this will only increase DNS latency and overhead. The same would be true when attempting to use otherwise bogus "State-Free" TCP transaction to support DNS. >>> The argument against TCP is not the protocol. It's just that you >>> have to upgrade both authoritative servers and resolvers to make >>> it work well. >> >> Huh? Why suggest radical changes to the TCP protocol, and then, in >> the same breath, say the problem is not the protocol? > > A lot of this has already been tried and proven in the HTTP context. > Claims that "TCP doesn't scale" or that "TCP is vulnerable to DoS > attacks" always sound very hollow to me. DNS handles a fraction of > the requests processed by HTTP and SMTP, and yet it can't be run on > TCP for protocol reasons? Come on. Don't underestimate DNS. Often TCP scales by using load-balancers and/ or a significant distribution of servers. >> Defending against DDoS attack was never a major consideration >> during early TCP or UDP development. Bot-nets weren't the problem >> they are today. Bastardizing TCP, rather than adopting properly >> designed protocols, is unlikely to provide a solutions, but instead >> likely to create new vulnerabilities. > > It's already being done for HTTP, and maybe to a lesser extent, for > SMTP. > > I'm not saying that it make sense to upgrade the DNS infrastructure > so that it can smoothly handle a TCP-centric load. Such a massive > upgrade could be better used to roll out something different. But > TCP itself is not the problem. In fact, experience with DoS attacks > against TCP services means that you've got a portfolio of solutions > to deal with attacks, something that would have yet to be developed > for a hypothetical non-TCP transport. Defensive solutions for TCP can not cope with the attack levels that might be created by a small bot-net. TCP quickly suffers from resource exhaustion. DNS over UDP avoids this propensity. However, the brute strength of DNS over UDP can be leveraged to attack other network infrastructure, and perhaps overwhelm resource capacity. This is especially a concern when an MTA authorization protocol ignores UDP exponential back-off and then prematurely initiates additional transactions. This is made even more destructive when message recipients generate an order of magnitude more transactions transformed by message local-parts directed toward any victim from fully cached DNS records. This provides for free DDoS attacks while spamming. These attacks might also be used to instigate DNS cache poisoning. The ability to poison DNS caches can be dramatically reduced by running DNS over SCTP. SCTP's ability to properly detect abusive sources allows mitigation efforts without causing an unfair loss of service. Neither UDP nor TCP employ the features needed to mitigate these types of attacks. The cost to mitigate TCP attacks quickly run into the millions, whereas DNS remains more robust and is more cost effective. Unfortunately, when adequately deployed, the brute strength of DNS creates its own risks. SCTP can be made robust and can mitigate most cache poisoning exploits ( but using 32 bit SCTP transaction-ID, 16 bit DNS transaction-ID, 16 bit port number, 16 bit stream number, SCTP-AUTH 32 bytes). SCTP can also be secured using TLS over SCTP, S-SCTP, AUTH-SCTP, as well as containing DNSSEC messages. -Doug From amir.herzberg@gmail.com Mon Jun 1 23:46:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84C33A68DA for ; Mon, 1 Jun 2009 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dix0wH1oFi5j for ; Mon, 1 Jun 2009 23:46:25 -0700 (PDT) Received: from mail-bw0-f226.google.com (mail-bw0-f226.google.com [209.85.218.226]) by core3.amsl.com (Postfix) with ESMTP id 702143A69C8 for ; Mon, 1 Jun 2009 23:46:24 -0700 (PDT) Received: by bwz26 with SMTP id 26so8129124bwz.7 for ; Mon, 01 Jun 2009 23:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=Oq2tkxqAm6jcQS0M/ftYWkCE3OTJr+nCvICucdbJi3k=; b=An16pkINhJS7J7xfhcQ5doTRp5dKT9HfCP94YdZHtB/3xu+LfqrqBtNHwWz0PFIfsP A7L28uxjo6BkrHo1pkKmyilVyIi6XSy6qfkbiOOkbWK7I1zKD+miBqvR6PZbZIJ+qigS XK6TDXT+NOEfrA6EqA3dcnDXoDQdFU4QAn8JA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=T0qCVukGlyV1JATSkKb1ccBnGqLxOCcBkAm5Y7jWuiXJUiPri8iVlgIUFBmmgQC22Y VxMmU5vpfh+uQ3NSJ5xTe1si+9JuZk/uJ+mkQ47PsT4jRzLm1x0BU2QGxJxUTAQh2pqu qgFRYLHM6QOwc7HyYAOn64gCxxKYDTKQPl2rE= MIME-Version: 1.0 Received: by 10.103.169.18 with SMTP id w18mr3667093muo.101.1243925182328; Mon, 01 Jun 2009 23:46:22 -0700 (PDT) In-Reply-To: <1EEF65DD-7BE0-45C9-ABF2-3E452E92E157@mail-abuse.org> References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org> <200905251603.MAA16221@Sparkle.Rodents-Montreal.ORG> <4A1D64C9.5060505@tana.it> <47BC2197-472E-4615-97D2-F7E42B8F3B7D@mail-abuse.org> <87d49rraqd.fsf@mid.deneb.enyo.de> <892F581E-BCE7-48D2-B6C3-429F56B3A3F5@mail-abuse.org> <873aal4nw7.fsf@mid.deneb.enyo.de> <1EEF65DD-7BE0-45C9-ABF2-3E452E92E157@mail-abuse.org> From: Amir Herzberg Date: Tue, 2 Jun 2009 09:46:02 +0300 Message-ID: <3be421270906012346x38d1c7bctd91118d5068e35d4@mail.gmail.com> To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=001636417e259eb27f046b57e67b Subject: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 06:46:27 -0000 --001636417e259eb27f046b57e67b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jun 2, 2009 at 1:02 AM, Douglas Otis wrote: ... > Defensive solutions for TCP can not cope with the attack levels that might > be created by a small bot-net. TCP quickly suffers from resource > exhaustion. DNS over UDP avoids this propensity. However, the brute > strength of DNS over UDP can be leveraged to attack other network > infrastructure, and perhaps overwhelm resource capacity. This is especially > a concern when an MTA authorization protocol ignores UDP exponential > back-off and then prematurely initiates additional transactions. This is > made even more destructive when message recipients generate an order of > magnitude more transactions transformed by message local-parts directed > toward any victim from fully cached DNS records. This provides for free > DDoS attacks while spamming. These attacks might also be used to instigate > DNS cache poisoning. Right. Furthermore... I think the discussion began, when Doug mentioned the concerns with abuse of SPF validation by receiving MTA/MDA/MUAs (in fact, suggesting I'll expand on this risk, which I mentioned in my review article, but I agree, not in sufficient detail). These abuses involved DDoS as well as DNS poisoning (a la Kaminski). I think it is important to remember that all these solutions discussed later in this thread (DNS-sec, DNS over TCP, DNS over SCTP, etc.), are long-term solutions; i.e., as long as most of the Net continues using DNS over UDP (at least as one or even default option), and not yet adopting DNS-sec, these risks remain- I refer to the risks due to fully RFC compliant SPF validation by MTA/MDAs (and MUAs, although I'm not sure this qualifies as RFC compliant). -- Amir Herzberg Associate Professor, Dept. of Computer Science Bar Ilan University http://AmirHerzberg.com --001636417e259eb27f046b57e67b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 2, 2009 at 1:02 AM,= Douglas Otis <dotis@mail-abuse.org> wrote:
...
Defensive solutions for TCP can = not cope with the attack levels that might be created by a small bot-net. = =A0TCP quickly suffers from resource exhaustion. =A0DNS over UDP avoids thi= s propensity. =A0 However, the brute strength of DNS over UDP can be levera= ged to attack other network infrastructure, and perhaps overwhelm resource = capacity. =A0This is especially a concern when an MTA authorization protoco= l ignores UDP exponential back-off and then prematurely initiates additiona= l transactions. =A0This is made even more destructive when message recipien= ts generate an order of magnitude more transactions transformed by message = local-parts directed toward any victim from fully cached DNS records. =A0Th= is provides for free DDoS attacks while spamming. =A0These attacks might al= so be used to instigate DNS cache poisoning.
=A0
Right. Furthermore... I think the discussion began, when Doug mentione= d the concerns with abuse of SPF validation by receiving MTA/MDA/MUAs (in f= act, suggesting I'll expand on this risk, which I mentioned in my revie= w article, but I=A0agree, not in sufficient detail). These abuses involved = DDoS as well as DNS poisoning (a la Kaminski).
=A0
I think it is important to remember that all these solutions discussed= later in this thread (DNS-sec, DNS over TCP, DNS over SCTP, etc.), are lon= g-term solutions; i.e., as long as most of the Net continues using DNS over= UDP (at least as one or even default option), and not yet adopting DNS-sec= , these risks=A0remain- I refer to the=A0risks=A0due to fully RFC compliant= SPF validation by MTA/MDAs (and MUAs, although I'm not sure this quali= fies as RFC compliant).
--
Amir Herzberg
Associate Professor, Dept. of Computer Science
B= ar Ilan University
http://AmirHerzbe= rg.com
--001636417e259eb27f046b57e67b-- From mohta@necom830.hpcl.titech.ac.jp Tue Jun 2 06:40:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5359B3A6E16 for ; Tue, 2 Jun 2009 06:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiYfDzQFCCkz for ; Tue, 2 Jun 2009 06:40:27 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 17ABC28C260 for ; Tue, 2 Jun 2009 06:39:23 -0700 (PDT) Received: (qmail 87015 invoked from network); 2 Jun 2009 15:09:35 -0000 Received: from bmdk2041.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.16.41) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2009 15:09:35 -0000 Message-ID: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Jun 2009 22:38:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Christian Huitema References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:33:16 -0700 Cc: Francis Dupont , "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 13:40:29 -0000 Christian Huitema wrote: >>That is, security of DNSSEC involves third parties and is not end >>to end. > That is indeed correct. An attacker can build a fake hierarchy of > "secure DNS" assertions and try to get it accepted. The attack can > succeed with the complicity of one of the authorities in the > hierarchy. It is a classic "attack by a trusted party". Yes, the hierarchy has hops. For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones have hops of ".", "jp", "ac.jp", "titech.ac.jp" and "hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. > If an intermediate authority has > been compromised, it can just as well insert a fake NS record -- > that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta From paul@xelerance.com Tue Jun 2 10:21:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44C43A6F92 for ; Tue, 2 Jun 2009 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR5YGwoHqXte for ; Tue, 2 Jun 2009 10:21:42 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C08B53A6F44 for ; Tue, 2 Jun 2009 10:21:42 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 449A4C5A9; Tue, 2 Jun 2009 13:21:42 -0400 (EDT) Date: Tue, 2 Jun 2009 13:21:42 -0400 (EDT) From: Paul Wouters To: Masataka Ohta In-Reply-To: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Message-ID: References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 02 Jun 2009 10:33:30 -0700 Cc: "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:21:43 -0000 On Tue, 2 Jun 2009, Masataka Ohta wrote: > For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones > have hops of ".", "jp", "ac.jp", "titech.ac.jp" and > "hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my > university, and my lab. Though you may have direct relationship > with IANA, JPNIC is the third party for both you and me. > Yes, security of DNSSEC is totally hop by hop. Just as DNS was designed to work. hierarchical. If you want to add additional protection because you don't trust your parents, no one stops you from using a DNSSEC capable resolver that has DNSSEC zones configured directly, without relying on the parent. I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. Hierarchy is the strength of DNS, not its weakness. DNSSEC allows you to specifically bypass the hierarchy for whatever zone you want. The only real question is, how does Masataka Ohta scale? My suspicion is that you don't scale to 50M domains, and that you will be forced to outsource some of that trust. DNSSEC does the outsourcing of trust distributed to the same people who are already responsible for the data you're about to trust. And note that even if you scale to 50M domains, I don't, so don't expect me to setup a trust relationship with you specifically. Paul From rbarnes@bbn.com Tue Jun 2 07:15:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC60C3A6AD3; Tue, 2 Jun 2009 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+a676iX06sd; Tue, 2 Jun 2009 07:15:33 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CEB473A6F43; Tue, 2 Jun 2009 07:14:14 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170] helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MBUkl-0005qa-EK; Tue, 02 Jun 2009 10:14:11 -0400 Message-ID: <4A2533B3.7070804@bbn.com> Date: Tue, 02 Jun 2009 10:14:11 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Masataka Ohta References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> In-Reply-To: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:33:52 -0700 Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 14:15:35 -0000 This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. --Richard Masataka Ohta wrote: > Christian Huitema wrote: > >>> That is, security of DNSSEC involves third parties and is not end >>> to end. > >> That is indeed correct. An attacker can build a fake hierarchy of >> "secure DNS" assertions and try to get it accepted. The attack can >> succeed with the complicity of one of the authorities in the >> hierarchy. It is a classic "attack by a trusted party". > > Yes, the hierarchy has hops. > > For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones > have hops of ".", "jp", "ac.jp", "titech.ac.jp" and > "hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my > university, and my lab. Though you may have direct relationship > with IANA, JPNIC is the third party for both you and me. > >> If an intermediate authority has >> been compromised, it can just as well insert a fake NS record -- >> that's not harder than a fake record signature. > > So, with a compromised hop of an intermediate authority, record > signature on the faked next hop key can be generated. > > Then, with a private key corresponding to the faked next hop key, > record signature on the faked second next hop key can be generated. > > Then, with a private key corresponding to the faked second next > hop key, record signature on the faked third next hop key can be > generated. > > Yes, security of DNSSEC is totally hop by hop. > > Masataka Ohta > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From rbarnes@bbn.com Tue Jun 2 08:41:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026463A69DB; Tue, 2 Jun 2009 08:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0k9GxZtTBSw; Tue, 2 Jun 2009 08:41:31 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3FAD33A69B4; Tue, 2 Jun 2009 08:41:31 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170] helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MBW79-0006xb-F6; Tue, 02 Jun 2009 11:41:23 -0400 Message-ID: <4A254823.9000405@bbn.com> Date: Tue, 02 Jun 2009 11:41:23 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Thierry Moreau References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A2533B3.7070804@bbn.com> <4A25404E.1080601@connotech.com> In-Reply-To: <4A25404E.1080601@connotech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:33:52 -0700 Cc: Masataka Ohta , Christian Huitema , Francis Dupont , "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:41:32 -0000 > I guess what Masataka was referring to is a different source of > variance, i.e. an impersonation of JPNIC's authority over its domain of > control (using a compromised JPNIC's private key). This is still just an extension of the trust you already have in your parent domains. You already have to trust that a parent domain's servers aren't going to be subverted and used to provide false answers. And since the most likely way for a DNSSEC key to get compromised is for it to be stolen (rather than cracked via the public key or signatures), these two levels of trust turn out to be the same. (In fact, a wily attacker would just use his access to the zone to make his changes, rather than having to spoof every client / resolver / cache individually.) There really is very little new here, in terms of the trust that's being placed in zone maintainers. It's just that DNSSEC now allows you to have the maintainers (which you already trust, see above) protect the integrity of records they send to you as they go across the wire. (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; DNSSEC just extends that protection on the *wire*.) --Richard From thierry.moreau@connotech.com Tue Jun 2 07:11:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAD528C1FF for ; Tue, 2 Jun 2009 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcunOP8m5+A9 for ; Tue, 2 Jun 2009 07:11:30 -0700 (PDT) Received: from smtp132.rog.mail.re2.yahoo.com (smtp132.rog.mail.re2.yahoo.com [206.190.53.37]) by core3.amsl.com (Postfix) with SMTP id 6A3B828C17F for ; Tue, 2 Jun 2009 07:11:30 -0700 (PDT) Received: (qmail 379 invoked from network); 2 Jun 2009 14:11:28 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp132.rog.mail.re2.yahoo.com with SMTP; 2 Jun 2009 14:11:28 -0000 X-YMail-OSG: BsMA7wAVM1mrIj1cqDg6g6OSFUExKuB_wOF7LpOPlcXusqwiQCF4R9wIXP1cY080Qw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A253289.3020000@connotech.com> Date: Tue, 02 Jun 2009 09:09:13 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> In-Reply-To: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:34:14 -0700 Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 14:11:32 -0000 Masataka Ohta wrote: > Christian Huitema wrote: > > >>>That is, security of DNSSEC involves third parties and is not end >>>to end. > > >>That is indeed correct. An attacker can build a fake hierarchy of >>"secure DNS" assertions and try to get it accepted. The attack can >>succeed with the complicity of one of the authorities in the >>hierarchy. It is a classic "attack by a trusted party". > > > Yes, the hierarchy has hops. > > For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones > have hops of ".", "jp", "ac.jp", "titech.ac.jp" and > "hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my > university, and my lab. Though you may have direct relationship > with IANA, JPNIC is the third party for both you and me. > This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): For my [end-user administrative units], [chain of CA's] have hops of [CA run by IANA], [CA run by JPNIC], [CA run by my university], and [CA run by my lab]. I don't know what is meant by a direct relationship with IANA. > >>If an intermediate authority has >>been compromised, it can just as well insert a fake NS record -- >>that's not harder than a fake record signature. > > > So, with a compromised hop of an intermediate authority, record > signature on the faked next hop key can be generated. > Exactly the same with a compromised intermediate CA. > Then, with a private key corresponding to the faked next hop key, > record signature on the faked second next hop key can be generated. > Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the compromised CA). > Then, with a private key corresponding to the faked second next > hop key, record signature on the faked third next hop key can be > generated. > Same thing. > Yes, security of DNSSEC is totally hop by hop. > Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Regards, - Thierry Moreau > Masataka Ohta > From thierry.moreau@connotech.com Tue Jun 2 08:10:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC7128C19B for ; Tue, 2 Jun 2009 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj0JkkL7uQuF for ; Tue, 2 Jun 2009 08:10:14 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id DCB2628C0F5 for ; Tue, 2 Jun 2009 08:10:13 -0700 (PDT) Received: (qmail 83463 invoked from network); 2 Jun 2009 15:10:13 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 2 Jun 2009 15:10:13 -0000 X-YMail-OSG: CB9n7ugVM1kW_DZw4NzWQPgWb4HhfZ8jd9rAcfF897xfoDgedOBQg3pTwLlFwnxqow-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A25404E.1080601@connotech.com> Date: Tue, 02 Jun 2009 10:07:58 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Barnes References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A2533B3.7070804@bbn.com> In-Reply-To: <4A2533B3.7070804@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:34:15 -0700 Cc: Masataka Ohta , Christian Huitema , Francis Dupont , "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:10:16 -0000 Richard Barnes wrote: > This debate has nothing to do with the security properties of DNSSEC. > > A basic assumption of the DNS is that what the authoritative server for > zone says is, well, authoritative. The structure of DNS itself entitles > JPNIC to point ac.jp wherever they want; by using a name within the .jp > domain, you are agreeing to act within JPNIC's domain of control. JPNIC > could set up an authoritative server for hpcl.titech.ac.jp completely > independently of you, regardless of DNSSEC, and from the perspective of > the DNS, that would be the right answer. > I guess what Masataka was referring to is a different source of variance, i.e. an impersonation of JPNIC's authority over its domain of control (using a compromised JPNIC's private key). > All DNSSEC does is make the assertions made in the DNS reliable -- it > does nothing to change the locus of control. > Reliable through a chain fo digital signatures. Reliable to the extent an impersonation attack (on the locus of control) does not occur based on a compromised private signature key. > On the other hand, you can certainly use the DNSSEC protocol elements to > do peer-to-peer security, just like you can use private DNS servers, and > just like you can use TLS without trust anchors (i.e., with self-signed > certs). Just hand out the public half of your ZSK to people you want to > be able to verify names within your zone. > Then you reduce the chain of digital signatures to a single one, raising confidence level at the cost of more key management hindrance. Indeed, this thread seems to be another attempt to understand the basic DNSSEC properties. - Thierry > --Richard > From thierry.moreau@connotech.com Tue Jun 2 09:10:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBAF128C274 for ; Tue, 2 Jun 2009 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUygrUOl2ufN for ; Tue, 2 Jun 2009 09:10:51 -0700 (PDT) Received: from smtp116.rog.mail.re2.yahoo.com (smtp116.rog.mail.re2.yahoo.com [68.142.225.232]) by core3.amsl.com (Postfix) with SMTP id C028528C28B for ; Tue, 2 Jun 2009 09:10:49 -0700 (PDT) Received: (qmail 1193 invoked from network); 2 Jun 2009 16:10:49 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp116.rog.mail.re2.yahoo.com with SMTP; 2 Jun 2009 16:10:49 -0000 X-YMail-OSG: pjYVJEcVM1nTWASWd1eKIqCO5lY7smSFGIbNwWTUlFygkjtSkWfTx2nrISh_JeztCg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A254E82.30201@connotech.com> Date: Tue, 02 Jun 2009 11:08:34 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Barnes References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A2 <4A254823.9000405@bbn.com> In-Reply-To: <4A254823.9000405@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 10:34:15 -0700 Cc: Masataka Ohta , Christian Huitema , Francis Dupont , "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:10:52 -0000 Richard Barnes wrote: > > (That is: You already trust the zones above you to maintain the > integrity of the zone on the *server*; > This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. Then, it is legitimate to appraise the overall confidence in the DNSSEC chain of signatures, and to pinpoint the weakest link (e.g. the zone manager having the greatest likelihood of lousy private key protection in place). Indeed, DNS+DNSSEC is no different from plain DNS for those who are satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some uses, it is useful to understand DNSSEC chains of digital signatures. Accesssorily, the zones "above you" means nothing to a relying party that is not validating its own domain. Regards, -- - Thierry Moreau From mohta@necom830.hpcl.titech.ac.jp Tue Jun 2 16:33:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6003A6A12 for ; Tue, 2 Jun 2009 16:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4UwTDeVZMNB for ; Tue, 2 Jun 2009 16:33:15 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 1E7FC3A68E0 for ; Tue, 2 Jun 2009 16:33:15 -0700 (PDT) Received: (qmail 44231 invoked from network); 3 Jun 2009 01:03:36 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 01:03:36 -0000 Message-ID: <4A25B687.7070106@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 08:32:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Thierry Moreau References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A253289.3020000@connotech.com> In-Reply-To: <4A253289.3020000@connotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 23:33:15 -0000 Thierry Moreau wrote: >>>> That is, security of DNSSEC involves third parties and is not end >>>> to end. > This is exactly like a chain of PKI CA's (replacing the path from bottom > to top of zone hierarchy): > Exactly the same with a compromised intermediate CA. > Exactly the same with a private key corresponding to the next > intermediate CA along the chain (i.e. the one certified by the The paper of David Clark says PKI is not secure end to end. Some tried to argue against by saying DNSSEC is so special that it is secure end to end. But, as you can observe, DNSSEC is no special and not secure end to end. > I don't think any DNSSEC expert ever claimed differently. I am the DNSSEC expert and see some people having a lot less expertise than me says DNSSEC secure end to end. They are incorrect or using different terminology on "end to end" not acceptable to the Internet community. Masataka Ohtqa From mohta@necom830.hpcl.titech.ac.jp Tue Jun 2 16:43:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C173B3A69DB for ; Tue, 2 Jun 2009 16:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYzOdg44a-Pr for ; Tue, 2 Jun 2009 16:43:06 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id B13AA3A677C for ; Tue, 2 Jun 2009 16:43:05 -0700 (PDT) Received: (qmail 45297 invoked from network); 3 Jun 2009 01:13:53 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 01:13:53 -0000 Message-ID: <4A25B8EF.70203@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 08:42:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Thierry Moreau References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A2 <4A254823.9000405@bbn.com> <4A254E82.30201@connotech.com> In-Reply-To: <4A254E82.30201@connotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Christian Huitema , Francis Dupont , "ietf@ietf.org" , Richard Barnes , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 23:43:06 -0000 Thierry Moreau wrote: >> (That is: You already trust the zones above you to maintain the >> integrity of the zone on the *server*; > This assumption does not stand universally. For some DNS users/usage, > DNSSEC signature verification will be a must. The discussion implicitly > referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organization. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Tue Jun 2 17:11:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F1F3A6C3F for ; Tue, 2 Jun 2009 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDam+9Yqi5kk for ; Tue, 2 Jun 2009 17:11:23 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 749E23A6AEB for ; Tue, 2 Jun 2009 17:11:23 -0700 (PDT) Received: (qmail 47315 invoked from network); 3 Jun 2009 01:35:31 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 01:35:31 -0000 Message-ID: <4A25BE02.5090901@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 09:04:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Wouters References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: "ietf@ietf.org" , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 00:11:24 -0000 Paul Wouters wrote: > I can't preload 50 million keys. I cannot build trust relations > with 50 millions domains. Just like we could not preload 50 > million nameserver pointers. That is the essential point of the paper of David Clark: These certificates are principal components of essentially all public key schemes, except those that are so small in scale that the users can communicate their public keys to each other one to one, in an ad hoc way that is mutually trustworthy. A credit card brand (VISA, for example) may manage more than 50 million PIN numbers. But, it uses agents to do so. The security of the system depends on not only (cryptographical) security between the brand holder and agents but also social security of the agents. Though 4 digit PIN or 16 bit message ID of DNS is cryptographically not very secure, it is a cryptographical issue of each hop, having nothing to do with social security between hops, introduction of which is inevitable for large infrastructures. Masataka Ohta From marka@isc.org Tue Jun 2 17:47:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0143A6C69 for ; Tue, 2 Jun 2009 17:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuhUrvczIiGp for ; Tue, 2 Jun 2009 17:47:38 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by core3.amsl.com (Postfix) with ESMTP id 2F9FF3A6802 for ; Tue, 2 Jun 2009 17:47:38 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 62997E602F; Wed, 3 Jun 2009 00:47:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n530lVKF084525; Wed, 3 Jun 2009 10:47:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906030047.n530lVKF084525@drugs.dv.isc.org> To: Masataka Ohta From: Mark Andrews In-reply-to: Your message of "Wed, 03 Jun 2009 08:42:39 +0900." <4A25B8EF.70203@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 10:47:31 +1000 Sender: marka@isc.org X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Christian Huitema , Francis Dupont , "ietf@ietf.org" , Thierry Moreau , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 00:47:39 -0000 In message <4A25B8EF.70203@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Thierry Moreau wrote: > > >> (That is: You already trust the zones above you to maintain the > >> integrity of the zone on the *server*; > > > This assumption does not stand universally. For some DNS users/usage, > > DNSSEC signature verification will be a must. The discussion implicitly > > referred to such uses. > > A problem of blindly believing a zone administration is that it is > only as secure as blindly believing an ISP administration. > > Attacking a router of a large ISPs is as easy/difficult as attacking > a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. There is no scalable way to avoid that trust issue. We don't have to trust the router adminstration or caching server administration or authoritative server adminstration. > Moreover, administration of LAN of a local organization (my universty, > for example) is as secure as administration of a zone local to the organizati > on. I've been on plenty of LAN's which I would treat as "hostile". > You can, for example, bribe a personnel or two, against which there > is no cryptographical protection, which means PKI is weakly secure. Which is not a arguement for not doing DNSSEC. Knowing where the risks are is how you do risk management. If you arn't willing to accept some risks then don't connect to the net. > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Tue Jun 2 23:35:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CBE3A6ED5 for ; Tue, 2 Jun 2009 23:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlcr3KQD1BQX for ; Tue, 2 Jun 2009 23:35:27 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id A57913A6E83 for ; Tue, 2 Jun 2009 23:34:53 -0700 (PDT) Received: (qmail 87998 invoked from network); 3 Jun 2009 07:59:03 -0000 Received: from bmdk2253.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.16.253) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 07:59:03 -0000 Message-ID: <4A2617DE.9030709@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 15:27:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mark Andrews References: <200906030047.n530lVKF084525@drugs.dv.isc.org> In-Reply-To: <200906030047.n530lVKF084525@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end (more tutorial than debating) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 06:35:28 -0000 Mark Andrews wrote: >>A problem of blindly believing a zone administration is that it is >>only as secure as blindly believing an ISP administration. >> >>Attacking a router of a large ISPs is as easy/difficult as attacking >>a signature generation mechanism of a large zone. > The difference is we *have* to trust the zone administration. Zone administration involves multiple operations. Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. Masataka Ohta From huitema@windows.microsoft.com Wed Jun 3 00:24:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF143A6AB8 for ; Wed, 3 Jun 2009 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HabK+G3USAYc for ; Wed, 3 Jun 2009 00:24:43 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2FA8B3A68E1 for ; Wed, 3 Jun 2009 00:24:43 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 3 Jun 2009 00:23:44 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.582.9; Wed, 3 Jun 2009 00:23:45 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) with Microsoft SMTP Server (TLS) id 14.0.582.7; Wed, 3 Jun 2009 00:24:01 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Wed, 3 Jun 2009 00:24:00 -0700 From: Christian Huitema To: Thierry Moreau , Masataka Ohta Date: Wed, 3 Jun 2009 00:23:58 -0700 Thread-Topic: DNSSEC is NOT secure end to end Thread-Index: AcnjjCXQXDjnDDNJSPaKCQw2yIM50AASaKow Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A253289.3020000@connotech.com> In-Reply-To: <4A253289.3020000@connotech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: E4QQ Fo31 LasC L0Up P/fS WDC5 c0c+ erOB fsUr jArS pHSa q758 sKz6 xvjn 6yDw 9z8n; 6; YQBzAHIAZwBAAGkAcgB0AGYALgBvAHIAZwA7AGYAcgBhAG4AYwBpAHMALgBkAHUAcABvAG4AdABAAGYAZAB1AHAAbwBuAHQALgBmAHIAOwBpAGUAdABmAEAAaQBlAHQAZgAuAG8AcgBnADsAbQBvAGgAdABhAEAAbgBlAGMAbwBtADgAMwAwAC4AaABwAGMAbAAuAHQAaQB0AGUAYwBoAC4AYQBjAC4AagBwADsAdABoAGkAZQByAHIAeQAuAG0AbwByAGUAYQB1AEAAYwBvAG4AbgBvAHQAZQBjAGgALgBjAG8AbQA7AHYAZQBzAGUAbAB5AEAAdABhAG4AYQAuAGkAdAA=; Sosha1_v1; 7; {A50A8A62-A386-4796-B694-73F32B6478F1}; aAB1AGkAdABlAG0AYQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Tue, 02 Jun 2009 23:04:34 GMT; UgBFADoAIABEAE4AUwBTAEUAQwAgAGkAcwAgAE4ATwBUACAAcwBlAGMAdQByAGUAIABlAG4AZAAgAHQAbwAgAGUAbgBkAA== x-cr-puzzleid: {A50A8A62-A386-4796-B694-73F32B6478F1} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Anti-Spam, Francis Dupont , IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:24:43 -0000 > > Yes, security of DNSSEC is totally hop by hop. > > >=20 > Thus, you imply a definition of hop by hop along digital signature > relationships. Indeed, DNSSEC security is limited to the weakest link > along the chain from the bottom to the top of the DNS hierarchy. Nothing > new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the "attack by a trusted party", there are still hu= ge differences between DNSSEC and "transport-hop-by-transport-hop" security= . Transport based solution, SCTP or TCP, are open to attacks by any party i= n the path between two hops -- NAT routers come to mind. DNSSEC is immune t= o such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additiona= l knowledge. If two domains have an establish relation, their servers can m= emorize the relevant public keys. If a host has a relation with a domain, i= t can memorize that domain's public key. This kind of "peer-to-peer" improv= ement makes the domain-to-domain or host-to-domain DNSSEC service immune to= attacks by nodes higher in the hierarchy. -- Christian Huitema =20 From mohta@necom830.hpcl.titech.ac.jp Wed Jun 3 00:52:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E4B3A6AD2 for ; Wed, 3 Jun 2009 00:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoIv1-8mei-2 for ; Wed, 3 Jun 2009 00:52:57 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id C91633A6AC3 for ; Wed, 3 Jun 2009 00:52:56 -0700 (PDT) Received: (qmail 97166 invoked from network); 3 Jun 2009 09:23:36 -0000 Received: from bmdk3152.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.17.152) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 09:23:36 -0000 Message-ID: <4A262BAD.6040802@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Jun 2009 16:52:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Christian Huitema References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A253289.3020000@connotech.com> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Thierry Moreau , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:52:57 -0000 Christian Huitema wrote: > NAT routers come to mind. DNSSEC > is immune to such attacks, a big advantage in practice. I'm afraid DNSSEC and some NAT interact terribly. > Also, it is actually possible to improve on DNSSEC by introducing > additional knowledge. If two domains have an establish relation, > their servers can memorize the relevant public keys. If a host > has a relation with a domain, it can memorize that domain's > public key. This kind of "peer-to-peer" improvement makes the > domain-to-domain or host-to-domain DNSSEC service immune to > attacks by nodes higher in the hierarchy. Do you know that the paper particularly discusses on revocation? It is written in the paper that: It can happen that a user loses his private key (the value that goes with the given public key) through inadvertence or theft; alternatively, a user may become unworthy in some way relevant to the purpose for which the certificate has been issued. Under such circumstances, the certificate authority (third party) would want to revoke the certificate. How can this be known? Your "improvement" makes the entire system more complex only to introduce new difficulties for revocation. Masataka Ohta From bmanning@ISI.EDU Wed Jun 3 00:56:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE0D3A6BB8; Wed, 3 Jun 2009 00:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5D60Vcvitf4; Wed, 3 Jun 2009 00:56:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 4A8893A6AA6; Wed, 3 Jun 2009 00:56:52 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n537u3AG011785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jun 2009 00:56:04 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n537u2Ba011767; Wed, 3 Jun 2009 00:56:02 -0700 (PDT) Date: Wed, 3 Jun 2009 00:56:02 -0700 From: Bill Manning To: Masataka Ohta Message-ID: <20090603075602.GA3945@boreas.isi.edu> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700 Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:56:53 -0000 On Tue, Jun 02, 2009 at 10:38:28PM +0900, Masataka Ohta wrote: > Christian Huitema wrote: > > >>That is, security of DNSSEC involves third parties and is not end > >>to end. > > > That is indeed correct. An attacker can build a fake hierarchy of > > "secure DNS" assertions and try to get it accepted. The attack can > > succeed with the complicity of one of the authorities in the > > hierarchy. It is a classic "attack by a trusted party". > > Yes, the hierarchy has hops. > > For my domain: "necom830.hpcl.titech.ac.jp", hierarechy of zones > have hops of ".", "jp", "ac.jp", "titech.ac.jp" and > "hpcl.titech.ac.jp". The authority hops are IANA, JPNIC, my > university, and my lab. Though you may have direct relationship > with IANA, JPNIC is the third party for both you and me. > > > If an intermediate authority has > > been compromised, it can just as well insert a fake NS record -- > > that's not harder than a fake record signature. > > So, with a compromised hop of an intermediate authority, record > signature on the faked next hop key can be generated. > > Then, with a private key corresponding to the faked next hop key, > record signature on the faked second next hop key can be generated. > > Then, with a private key corresponding to the faked second next > hop key, record signature on the faked third next hop key can be > generated. > > Yes, security of DNSSEC is totally hop by hop. > > Masataka Ohta i think the distinction here might be characterised by the use of terms: -channel security -data integrity DNSSEC - the signing of the data, provides a means to ensure the accuracy and integrity of the data, the payload. Given the design of the DNS, that data can come from an authoritative source or a cache. there is no expectation that the data will emerge from or through any given path/source. Once the data is received, it is possible to determine if the data is a) intact, and b) untampered with. There is no hop/hop at the transport level cause DNS really doesn't work that way today. Channel Security - hop/hop can be done a couple of different ways. IPsec, TSIG, SIG(0), DNSCurve et.al. From a resolver point of view, this type of security is usually done only one hop away, to the prefered cache or (small) set of authoritative servers. It could be possible, but unweildy to do complete channel security. But to what end? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From David.Wilson@isode.com Wed Jun 3 13:44:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956553A6C9A for ; Wed, 3 Jun 2009 13:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uO+3UCautRZ for ; Wed, 3 Jun 2009 13:44:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7FE813A7066 for ; Wed, 3 Jun 2009 13:43:59 -0700 (PDT) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 3 Jun 2009 21:38:47 +0100 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <4A252B54.6020508@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> Organization: Isode Limited Date: Wed, 03 Jun 2009 21:38:39 +0100 Message-Id: <1244061519.2778.62.camel@bravo.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 20:44:33 -0000 On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote: > Yes, security of DNSSEC is totally hop by hop. I am nervous of adding to this debate (and should it really be on ASRG?) However, I think there is some difference in the way people are using some terms. My understanding of the terms hop-by-hop and end-to-end is this: A data item traverses a number of nodes within a network. (E.g. a UDP datagram moving through an inter-network, or a Email message from its submitting UA via a sequence of MTAs to the recipient's UA). "End-to-end" security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. "Hop-by-hop" security means that you do rely on the trustworthiness of the intermediate nodes and channels. (E.g. CRC provides no defence against deliberate tampering, TLS for email is only as trustworthy as the least trusted intermediate MTA). PKI establishes a "chain of trust" between the signing certificate (i.e. the certificate containing the public key corresponding to the private key used to generate the signature) and your trust anchors (which you choose). This is not really "hop-by-hop" as data is not hopping. Like a real chain, it is only as strong as its weakest link. However, the chain operates in a different 'space' from that used to transfer the data being protected. As far as I understand, the key thing which DNSSEC gives you is data origin authentication (although that by itself without data integrity would be useless). The DNS attacks which were the start of the discussion are all based on the attacker sending false data to the system under attack. Having an effective means for determining from whom data comes is necessary to overcome this kind of attack. best regards David Wilson From mohta@necom830.hpcl.titech.ac.jp Wed Jun 3 20:35:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5AD3A6885 for ; Wed, 3 Jun 2009 20:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5oLOfZUkdyN for ; Wed, 3 Jun 2009 20:35:48 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id D02F53A6828 for ; Wed, 3 Jun 2009 20:35:47 -0700 (PDT) Received: (qmail 6746 invoked from network); 4 Jun 2009 05:06:35 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 4 Jun 2009 05:06:35 -0000 Message-ID: <4A2740E6.3060601@necom830.hpcl.titech.ac.jp> Date: Thu, 04 Jun 2009 12:35:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Bill Manning References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <20090603075602.GA3945@boreas.isi.edu> In-Reply-To: <20090603075602.GA3945@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Francis Dupont , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:35:48 -0000 Bill Manning wrote: > i think the distinction here might be characterised by > the use of terms: > > -channel security Don't try to confuse the terminology. With the terminology of "channel", the paper addresses the issue that security by channels between zones or zone administrators depends on security of intermediate zones and is not end to end. > -data integrity Date integrity is maintained through the channels between zones hop by hop. > DNSSEC - the signing of the data, provides a means to ensure the > accuracy and integrity of the data, the payload. The problem is that the accuracy and integrity of DNSSEC is not cryptographically but socially secure. So is plain old DNS. So, there is no point to deploy DNSSEC. Masataka Ohta From doug.mtview@gmail.com Thu Jun 4 20:32:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AC53A6975 for ; Thu, 4 Jun 2009 20:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUaMBaD6Jv6u for ; Thu, 4 Jun 2009 20:32:11 -0700 (PDT) Received: from mail-pz0-f186.google.com (mail-pz0-f186.google.com [209.85.222.186]) by core3.amsl.com (Postfix) with ESMTP id B1EBB3A67F7 for ; Thu, 4 Jun 2009 20:32:11 -0700 (PDT) Received: by pzk16 with SMTP id 16so837334pzk.15 for ; Thu, 04 Jun 2009 20:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=QERlvAtt3Lc98xkWHAJvAzPMnbJAF+UfU3Q7BCOAwCM=; b=XSFfovRIIXkAR783FLXbbeJEntF3uuZzJK899ZelHflYMmegAm6Qc1rfdUMCB3SsCS 1LHYFZisVu5lTWi5YVL+G7oc1lB2ZsmIA1bB2GDFpe9oin33KhlcWjkW8cIk4jUmXPG2 0G6jshobSKC4BnkncgBK29A2UCnS5fXVNZtaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=VgB37okiZETcsfIEAZxIxMjfr2bmc2F1uOpmbec7qReFlEmHr40caFsM+/fe/QJHAM 41ZeVEMqW0oAA/5mylrh8oPsCNJgXSQSRwcGahoyVpgvTWZpGKsLER43oGaAi5zgcxiU cXuX3eDntf17DfwUN4E33m+mur7U3UfbnzwB4= Received: by 10.114.58.15 with SMTP id g15mr4542013waa.186.1244172733336; Thu, 04 Jun 2009 20:32:13 -0700 (PDT) Received: from SJC-Office-NAT-219.mail-abuse.org (SJC-Office-NAT-219.mail-abuse.org [168.61.10.219]) by mx.google.com with ESMTPS id d20sm12032760waa.12.2009.06.04.20.32.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 20:32:12 -0700 (PDT) Message-Id: <96A485DD-13FD-4966-ADC3-17BB00F6DF14@gmail.com> From: Doug Otis To: Masataka Ohta In-Reply-To: <4A2740E6.3060601@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 20:32:11 -0700 References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <20090603075602.GA3945@boreas.isi.edu> <4A2740E6.3060601@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Fri, 05 Jun 2009 11:31:06 -0700 Cc: Christian Huitema , Francis Dupont , "ietf@ietf.org" , Bill Manning , Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 03:32:12 -0000 On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote: > The problem is that the accuracy and integrity of DNSSEC is not > cryptographically, but socially secure. DNS over UDP is prone to port/transaction-id guessing, where cryptography could play a protective role. The risk of these values being guessed increases whenever NATs reduce port diversity, or operate in a predictable manner. Protocols such as SPF that embed macros into DNS, allow hundreds of transactions to be chained. The entire chain might result from the local-parts of a single email. These transactions can target otherwise uninvolved victims or evil domains. When an evil domain is the target of SPF transactions, attackers can discover the nature of the resolver. Afterwords, with only one transaction targeting the evil domain, and others targeting their victim, the guesswork for injecting poison is reduced, where even ACLs offer no protection. The growing speed of today's Internet makes this an ever growing concern. While DNSSEC might prevent caches from being poisoned, EDNS0 creates new concerns also aggravated by SPF. Since the 512 byte DNS message size did not accommodate RSA signatures, EDNS0 is required to adjust message limits. EDNS0 allows bad actors to further leverage DNS transactions, such as those that might emanate from cached SPF records to initiate more than 20 TXT record transactions when a recipient evaluates a single email. The TXT records might be policy documents not intended for machine consumption or wildcard SPF records enumerating address authorizations for outbound MTAs. The flexibility sought by SPF has created a sizable list of concerns, where caution was often countered with distain for DNS. It might have been better to have specified limits for EDNS0, such as a minimum message size of 1280 and a maximum at 1424, where transactions that don't comply are refused. UDP allows source spoofing, which could allow bad actors a means to create packet fragmentation by incorrectly setting message. If addition, when fragmentation does occur, DNS transactional-ids offer little protection for packet fragments that may contained unsigned information. DNS will need to be become pedantic about confirming information, perhaps also enforcing the use of checksums and message size. While DNSSEC may not require channel security at some point when a trust anchor can be safely found, DNS over UDP remains a brute. When an SPF process sequence prematurely times out, rather than waiting for exponential back-off, SPF simply begins another sequence, ignoring congestion avoidance. SCTP carrying either DNS or DNSEC packets would ensure DNS remains tame despite much of the abuse. Unlike TCP, SCTP does not commit resources without return of a cookie, but can start data exchanges sooner. SCTP can carry simultaneous DNS messages and can can keep a large number of sparse connections per port active. Perhaps recursive resolvers might be more responsive with SCTP than with UDP. Importantly, the source of abusive DNS behavior can be identified and thereby avoided. This is not true for either TCP or UDP. -Doug From paul@xelerance.com Fri Jun 5 10:06:11 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46423A6E1C for ; Fri, 5 Jun 2009 10:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf6HDWGc1sMH for ; Fri, 5 Jun 2009 10:06:06 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6A2303A6E0E for ; Fri, 5 Jun 2009 10:06:06 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 5AEC9C5C7; Fri, 5 Jun 2009 12:44:53 -0400 (EDT) Date: Fri, 5 Jun 2009 12:44:52 -0400 (EDT) From: Paul Wouters To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A253289.3020000@connotech.com> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 05 Jun 2009 11:31:06 -0700 Cc: Anti-Spam@core3.amsl.com, IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:06:11 -0000 On Wed, 3 Jun 2009, Christian Huitema wrote: > Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of "peer-to-peer" improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. How do you handle key changes? How do you determine if the key change is performed by the domain holder or an attacker? There is no reason for such a "leap of faith" caching. In fact, with SSHFP records, we can also nail down that leap of faith for ssh finally :) Paul From doug.mtview@gmail.com Fri Jun 5 11:37:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEC33A6B93 for ; Fri, 5 Jun 2009 11:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOUS2uhoNDdE for ; Fri, 5 Jun 2009 11:37:08 -0700 (PDT) Received: from mail-px0-f197.google.com (mail-px0-f197.google.com [209.85.216.197]) by core3.amsl.com (Postfix) with ESMTP id 0EEF93A6A7F for ; Fri, 5 Jun 2009 11:37:07 -0700 (PDT) Received: by pxi35 with SMTP id 35so125198pxi.15 for ; Fri, 05 Jun 2009 11:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=N1hrXCjvXpCp0L0HPKs4Fz4hMXjIsUZ4QRtqIPTjck8=; b=TRIiseA9knaklQideVs/O6yK3dzrRf6novQAiUJ1m44iPoAdAOuwHYaSdQDnHOfYud oPwzUHPHrfRKiYCAqVVAp83wNkKxD6N2vtaEQ2aNBqrLmtEjXnT4gtwPV23h841dDzSn eLXyjnh6+5C+QRV8y9JAn6V1/hwSAMesnlEiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=pzcgarkI9qpOr/FlX/cly4LriitSjAQr4DymZ6EFJI/00zX6qK2ID9TtZmS1j8Xont 3YgbVt0TOlFO/gVVXz4uMlrhF0jEALQf9tUgO9jEGU1bcKylyQVxvoL6SI2l3jNttSBh KG1/6TNIr98qKJoBaMFLT48SJsR9jSSVeH9yU= Received: by 10.114.13.1 with SMTP id 1mr5891613wam.37.1244227030507; Fri, 05 Jun 2009 11:37:10 -0700 (PDT) Received: from SJC-Office-NAT-219.mail-abuse.org (SJC-Office-NAT-219.mail-abuse.org [168.61.10.219]) by mx.google.com with ESMTPS id k37sm405539waf.7.2009.06.05.11.37.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 11:37:09 -0700 (PDT) Message-Id: <78217C63-8085-43AB-96A8-95FF8BF81F4E@gmail.com> From: Doug Otis To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 11:37:05 -0700 References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <4A253289.3020000@connotech.com> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.935.3) Cc: Masataka Ohta , Francis Dupont , "ietf@ietf.org" , Anti-Spam@core3.amsl.com, Thierry Moreau , IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 18:37:09 -0000 On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote: >>> Yes, security of DNSSEC is totally hop by hop. >> >> Thus, you imply a definition of hop by hop along digital signature >> relationships. Indeed, DNSSEC security is limited to the weakest >> link along the chain from the bottom to the top of the DNS >> hierarchy. Nothing new there. I don't think any DNSSEC expert ever >> claimed differently. > > Even in the presence of the "attack by a trusted party", there are > still huge differences between DNSSEC and "transport-hop-by- > transport-hop" security. Transport based solution, SCTP or TCP, are > open to attacks by any party in the path between two hops -- NAT > routers come to mind. DNSSEC is immune to such attacks, a big > advantage in practice. > > Also, it is actually possible to improve on DNSSEC by introducing > additional knowledge. If two domains have an establish relation, > their servers can memorize the relevant public keys. If a host has a > relation with a domain, it can memorize that domain's public key. > This kind of "peer-to-peer" improvement makes the domain-to-domain > or host-to-domain DNSSEC service immune to attacks by nodes higher > in the hierarchy. Private ad-hoc caching of keys would make DNS fairly fragile. While the trust anchor issue for DNSSEC looms, DNS will remain prone to inadvertently cached unsigned content. Benefits obtained by using DNS over SCTP would be significant protection from out-of-path poisoning, whether information is signed or not. Once DNSSEC is fully implemented and trust anchor issues are resolved, information contained within DNS would not depend upon transport protections. When that might happen remains unknown. However, once DNSSEC becomes widely adopted, the Internet may need protection from UDP/EDNS0 source spoofing. For this, SCTP would offer protection from source spoofing that DNSSEC does not prevent. EDNS0 should also have min/max limits imposed, where packets of a greater size should be handled by SCTP. The brute force strategy that allows DNS over UDP to cope with source spoofing and misuse, also makes DNSSEC over UDP a greater risk. UDP does not lend itself to being moderated or flow controlled, as some suggest. Although TCP permits flow control, TCP is much more vulnerable to resource exhaustion, creating significant costs when defending TCP services compared to those using UDP or SCTP. Reliability, performance and DDoS immunity makes SCTP an attractive solution over TCP. SCTP should perform well as a transport for either DNS or DNSSEC. SCTP would also provide improved security and performance for HTTP as well. :^) -Doug From mohta@necom830.hpcl.titech.ac.jp Fri Jun 5 21:10:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E6E3A6CB0 for ; Fri, 5 Jun 2009 21:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.863 X-Spam-Level: ** X-Spam-Status: No, score=2.863 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-27bndzaohy for ; Fri, 5 Jun 2009 21:10:16 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id BD4D63A6BF3 for ; Fri, 5 Jun 2009 21:10:15 -0700 (PDT) Received: (qmail 60580 invoked from network); 6 Jun 2009 05:41:47 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 6 Jun 2009 05:41:47 -0000 Message-ID: <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> Date: Sat, 06 Jun 2009 13:09:38 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: David Wilson References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> In-Reply-To: <1244061519.2778.62.camel@bravo.isode.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 04:10:16 -0000 David Wilson wrote: > However, I think there is some difference in the way people are using > some terms. According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. > "End-to-end" security means that the security of that data item does not > depend on the trustworthiness of any intermediate node, or channel. According to the terminology of David Clark, certificate authorities are intermediate nodes. If you have different terminology, use it outside of the Internet community but not within. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Sun Jun 7 22:23:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CFC3A6A95 for ; Sun, 7 Jun 2009 22:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znhk-LeDQjwn for ; Sun, 7 Jun 2009 22:23:15 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 240523A6989 for ; Sun, 7 Jun 2009 22:23:15 -0700 (PDT) Received: (qmail 30973 invoked from network); 8 Jun 2009 06:55:13 -0000 Received: from unknown (HELO necom830.hpcl.titech.ac.jp) (202.249.37.19) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2009 06:55:13 -0000 Message-ID: <4A2CA014.8090701@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Jun 2009 14:22:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Phillip Hallam-Baker References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Francis Dupont , ietf@ietf.org, Anti-Spam Research Group - IRTF Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 05:23:16 -0000 Phillip Hallam-Baker wrote: > I was at a dinner with Dave Clarke last week. Those who invoke his > name in these arguments rarely seem to have read his paper on the end > to end principle IN NETWORKING. Which paper is, are you saying, "his paper"? The original one or latter one (published in 2001) which includes discussion on PKI, which I referred in previous mails. As you say "IN NETWORKING", I'm afraid you haven't read his original paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system design" in general and not necessarily "in networking". For example, in the original paper, RISC (Reduced Instruction Set Computer) is given as an example of end to end design. > Depending on your level of abstraction you choose to work at you can > argue that anything is an end. Apparently, he taught you basic points in his original paper but not beyond. It is discussed in the original paper that: Identifying the ends Using the end-to-end argument sometimes requires subtlety of analysis of application requirements. one must use some care to identify the end points to which the argument should be applied. Beyond the original paper, the application of the end to end argument to PKI including DNSSEC is discussed in his latter paper in 2001 with PROPERLY IDENTIFIED "end points". In the paper, certificate authorities are identified to be third parties. With the discussion, there is no point denying "DNSSEC is NOT secure end to end". > It would be nice if the paper was available in unencumbered form. Both of the papers are freely downloadable. The original paper: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The paper in 2001: http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf You should have read both of them to make the dinner more valuable. > Publication in ACM does not help anything but the author's academic > career. I gave a link to the paper in 2001 through ACM because it has DOI, assuming that anyone can use search engines and that all the people who talks about the end to end principle should have read the original paper in advance. Masataka Ohta From David.Wilson@isode.com Mon Jun 8 12:55:42 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0383E3A6E17 for ; Mon, 8 Jun 2009 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUFYRpGwet2F for ; Mon, 8 Jun 2009 12:55:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 861133A6E14 for ; Mon, 8 Jun 2009 12:55:41 -0700 (PDT) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 Jun 2009 20:54:15 +0100 From: David Wilson To: Masataka Ohta In-Reply-To: <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> Organization: Isode Limited Date: Mon, 08 Jun 2009 20:54:09 +0100 Message-Id: <1244490849.2822.21.camel@bravo.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 19:55:42 -0000 On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote: > David Wilson wrote: > > > However, I think there is some difference in the way people are using > > some terms. > > According to the terminology of David Clark, PKI including DNSSEC > is not secure end to end. DNSSEC provides two things. Firstly, it provides the means to digitally sign RRsets. This provides data origin authentication and data integrity. As this operates at the DNS application layer, this is clearly "end to end" within David Clark's terminology. It does not rely on any security services in the lower communication layers (in the way that, for instance, relying on TCP would). This origin authentication and integrity is precisely what is required to avoid the DNS cache poisoning which is the kind of vulnerability which prompted this discussion. This aspect of DNSSEC does not require the use of any PKI. A security aware resolver can obtain by some out-of-band means the public signing key for some "island of security", and choose to trust that key. However, such bilateral arrangements do not scale to the Internet. So, DNSSEC provides a means for an Authentication Chain, to use the specific DNSSEC term. A signed zone can authenticate the key of a child zone. There is a chain here. However, it is of a significantly different character to a communication network. Whether it is "end to end" or not, is for a different discussion. > > > "End-to-end" security means that the security of that data item does not > > depend on the trustworthiness of any intermediate node, or channel. > > According to the terminology of David Clark, certificate authorities > are intermediate nodes. > > If you have different terminology, use it outside of the Internet > community but not within. I get the impression from you that DNSSEC is to be disregarded because it is not "end to end". However, the opinion of "the Internet community" as regards DNSSEC has been made clear in the last few days, given these announcements: http://www.nist.gov/public_affairs/releases/dnssec_060309.html http://pir.org/index.php?db=content/Website&tbl=ORG_Advantage&id=2 http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn If the Internet community agrees with you that DNSSEC is not "end to end", then this does not seem to divert them from implementing it. best regards David From David.Wilson@isode.com Mon Jun 8 13:28:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1FB3A6BFC for ; Mon, 8 Jun 2009 13:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX0GQDkmPGZj for ; Mon, 8 Jun 2009 13:28:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 428753A6B93 for ; Mon, 8 Jun 2009 13:28:54 -0700 (PDT) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 Jun 2009 21:28:58 +0100 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <4A2CA014.8090701@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <4A2CA014.8090701@necom830.hpcl.titech.ac.jp> Organization: Isode Limited Date: Mon, 08 Jun 2009 21:28:57 +0100 Message-Id: <1244492937.2822.56.camel@bravo.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Francis Dupont , Phillip Hallam-Baker , ietf@ietf.org Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 20:28:56 -0000 On Mon, 2009-06-08 at 14:22 +0900, Masataka Ohta wrote: > As you say "IN NETWORKING", I'm afraid you haven't read his original > paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system > design" in general and not necessarily "in networking". For example, > in the original paper, RISC (Reduced Instruction Set Computer) is > given as an example of end to end design. Er, no. The article states: "The arguments that are used in support of reduced instruction set computer (RISC) architecture are similar to end-to-end arguments." I.e. the arguments for end to end are similar to the arguments for RISC. This is not the same as saying that RISC is an example of end to end design. > Both of the papers are freely downloadable. > > The original paper: > > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > > The paper in 2001: > > http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf > > You should have read both of them to make the dinner more valuable. > [Interesting articles, which took me back to discussions 20 years ago as regards connectionless vs. connection oriented networks.] It is clear from both of these that the basic subject is data communication over a communication system. Thus the second article quotes from the first article thus: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communications system. Therefore, providing that questioned function as a feature of the communications systems itself is not possible." So the basic object under consideration here is a "communication system". It is clear from the first article that what is envisaged is a layered model, (c.f. the conclusion). I would not be surprised if this kind of thinking was input to the development of the OSI model for data communications, which does set out to assign to each layer an appropriate function. The basic thesis of the article is that functions concerned with, for instance, security and reliability are best done in the upper layers, even the top (application) layer, as the application cannot rely entirely on the lower layers to "do their stuff". Thus "end to end" is about communication from one application layer to the peer application layer down through the layers at one system, and then up through the layers at the other system. So, I would paraphrase the "end to end design principle" as the "application to application" design principle. I note that in models like the OSI model, only the lowest layer have intermediate systems. (That's why layer 3 is called the network layer). The article in no way implies that it is the existence of intermediate systems which is the deciding factor in the design. "End to end" is not in contrast to "hop by hop". So, applying this to DNSSEC's PKI, this is clearly an application layer security system. The system does not depend upon the security or reliability of any lower layers (or, indeed, intermediate systems). So, it would seem to fit the "end to end design" of this article. The second article is a discussion about how the end-to-end design principle might need to be modified in the light of the realities of the modern Internet. In the present context of DNSSEC, the discussion of trust is important. best regards David From mohta@necom830.hpcl.titech.ac.jp Mon Jun 8 16:55:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B19B3A6991 for ; Mon, 8 Jun 2009 16:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.76 X-Spam-Level: * X-Spam-Status: No, score=1.76 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUa4-y1N5ijc for ; Mon, 8 Jun 2009 16:55:30 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id D2BEA3A6820 for ; Mon, 8 Jun 2009 16:55:29 -0700 (PDT) Received: (qmail 98066 invoked from network); 9 Jun 2009 01:27:46 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 9 Jun 2009 01:27:46 -0000 Message-ID: <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Jun 2009 08:54:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: David Wilson References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> In-Reply-To: <1244490849.2822.21.camel@bravo.isode.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 23:55:31 -0000 David Wilson wrote: >>According to the terminology of David Clark, PKI including DNSSEC >>is not secure end to end. > DNSSEC provides two things. Firstly, it provides the means to digitally > sign RRsets. This provides data origin authentication and data > integrity. The provision is through hops of certificate authorities, which is what is discussed in latter paper of David Clark published in 2001. Read it. > As this operates at the DNS application layer, this is > clearly "end to end" within David Clark's terminology. It does not rely > on any security services in the lower communication layers (in the way > that, for instance, relying on TCP would). If you read the paper, you can find the lower layer of PKI consists of communication with or between certificate authorities. Compromising a certificate authority in the lower communication layer breaks the security of data origin authentication and data integrity. > This origin authentication and integrity is precisely what is required > to avoid the DNS cache poisoning which is the kind of vulnerability > which prompted this discussion. As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. > This aspect of DNSSEC does not require the use of any PKI. Read the 2001 paper on why PKI not end to end and why DNSSEC no exception. The paper explains why scale breaks the end to end property. > I get the impression from you that DNSSEC is to be disregarded because > it is not "end to end". Being "end to end" has practical advantages. See above on how useless DNSSEC is to avoid cache poisoning, which was the motivation to deploy it. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Mon Jun 8 17:23:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E3C3A69F2 for ; Mon, 8 Jun 2009 17:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.743 X-Spam-Level: * X-Spam-Status: No, score=1.743 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXTZ-jWw4pd1 for ; Mon, 8 Jun 2009 17:23:54 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id E69EB3A68A8 for ; Mon, 8 Jun 2009 17:23:53 -0700 (PDT) Received: (qmail 284 invoked from network); 9 Jun 2009 01:56:31 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 9 Jun 2009 01:56:31 -0000 Message-ID: <4A2DAB85.6040500@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Jun 2009 09:23:33 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: David Wilson References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <4A2CA014.8090701@necom830.hpcl.titech.ac.jp> <1244492937.2822.56.camel@bravo.isode.net> In-Reply-To: <1244492937.2822.56.camel@bravo.isode.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Francis Dupont , Phillip Hallam-Baker , Anti-Spam Research Group - IRTF , ietf@ietf.org Subject: [Asrg] RISC is end to end (was Re: DNSSEC is NOT secure end to end) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 00:23:55 -0000 David Wilson wrote: >>As you say "IN NETWORKING", I'm afraid you haven't read his original >>paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system >>design" in general and not necessarily "in networking". For example, >>in the original paper, RISC (Reduced Instruction Set Computer) is >>given as an example of end to end design. > Er, no. The article states: The paper states: any attempt by the computer designer to anticipate the client's requirements for an esoteric feature will probably miss the target slightly and the client will end up reimplementing that feature anyway which is an end to end argument where communication is at high level between computer designers and their clients. > It is clear from both of these that the basic subject is data > communication over a communication system. That is true only with the widest meaning of "communication". However, "IN NETWORKING" by Phillip has a lot narrow meaning and even the original paper says: A version of the end-to-end argument in a non-communication application was developed in the 1950's by system analysts whose responsibility included reading and writing files on large numbers of magnetic tape reels. > So, applying this to DNSSEC's PKI, this is clearly an application layer If you want to draw some conclusion from the 2001 paper, quote text from the paper. There is no point to reiterate it with your subtly modified terminology only to give a subtly modified impression on the content of the paper. > The second article is a discussion about how the end-to-end design > principle might need to be modified in the light of the realities of the > modern Internet. That is an explanation on the motivation to write the paper and the conclusion of the paper is: We argue that the open, general nature of the Net, which derived from the end to end arguments, is a valuable characteristic that encourages innovation, and this flexibility should be preserved. which means the end to end argument is not modified. Instead, the paper, for example, says for regulations to be realistic, they should follow the end to end principle. Masataka Ohta From David.Wilson@isode.com Tue Jun 9 01:05:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9863A6925 for ; Tue, 9 Jun 2009 01:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZniZ4-uFW5u for ; Tue, 9 Jun 2009 01:05:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 396A23A68E1 for ; Tue, 9 Jun 2009 01:05:19 -0700 (PDT) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 9 Jun 2009 09:05:24 +0100 From: David Wilson To: Masataka Ohta In-Reply-To: <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> Organization: Isode Limited Date: Tue, 09 Jun 2009 09:05:15 +0100 Message-Id: <1244534715.2760.51.camel@bravo.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:05:20 -0000 On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: > > DNSSEC provides two things. Firstly, it provides the means to > digitally > > sign RRsets. This provides data origin authentication and data > > integrity. > > The provision is through hops of certificate authorities, As I clearly stated, the actual signing is end to end, and if the receiver has chosen to trust the explicit key used to sign, there is no involvement of PKI. The presence of a valid digital signature is good evidence that the data originated in that form from the owner of the private key corresponding to the public key used for verification. > which is what is discussed in latter paper of David Clark published in > 2001. Read it. I have, and I cannot find any explicit sentence which uses the phrase "hops of certificate authorities". Nor can I find any statement which states anything to the effect "PKI is not end to end and is therefore bad". If these are present, please point them out. He does state "Each interaction is nominally ... but its robustness depends on the larger context composed of the whole sequence." It does state, in effect, "PKI is difficult" (particularly because of the revocation problem) but that is well known. But it also gives me the impression that it says that this kind of thing is necessary, because of the trust issue on the modern Internet. I'm not sure of the reason for your insisting that DNSSEC is not end to end. I must apologise to the Asrg list for continuing this discussion, which seems to have just gone down a pointless semantic hole. From David.Wilson@isode.com Tue Jun 9 01:18:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE053A6E1F for ; Tue, 9 Jun 2009 01:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2n95wWaZYOu for ; Tue, 9 Jun 2009 01:18:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DF8993A6912 for ; Tue, 9 Jun 2009 01:18:26 -0700 (PDT) Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 9 Jun 2009 09:17:01 +0100 From: David Wilson To: Masataka Ohta In-Reply-To: <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> Organization: Isode Limited Date: Tue, 09 Jun 2009 09:17:00 +0100 Message-Id: <1244535420.2760.64.camel@bravo.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:18:27 -0000 On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: > > This origin authentication and integrity is precisely what is > required > > to avoid the DNS cache poisoning which is the kind of vulnerability > > which prompted this discussion. > > As has been discussed in the thread, DNSSEC is NOT a protection > against cache poisoning, because caches poisoned with forged > certificate breaks the security. > I think you need to explain how this happens in detail. For instance, an attacker wishes to poison the cache of some ISP's DNS server for 'example.com.". Currently, it gets the server to request information about example.com from its authoritative server, and sends information that purports to be from that server. It needs to guess some properties of the original request, but there have been and are various features of DNS servers which make this easier than you might think. Without DNSSEC, the attacked DNS resolver simply accepts the information. With DNSSEC, a security aware resolver will want to check the signature. The information is only accepted if the signature checks out, and the key is trusted. If the key is a trust anchor, then the check is complete. If not, then the resolver needs to get the DS RR for example.com from com's DNS server. This information is itself signed with com's signing key. So, it will not accept that unless it verifies. If com's signing key is not a trust anchor, then it will get com's DS RR from the root. Also signed by root, and the root key is probably a trust anchor. If any of this information is not available, or is not signed, then the trust chain is not present, and the original information is not accepted by the security aware resolver. So, perhaps you can explain how an attacker can get a security aware resolver to accept information which will subvert this? I think you have proposed that an attacker might explicitly subvert the chain. In this case it would involve getting the com DNS server to accept a DS RR for example.com. This is altogether harder problem for the attacker, and is of a significantly different character than cache poisoning, as it involves actual changes to the DNS servers, rather than just persuading resolvers to accept incorrect information. But, perhaps this mechanism would better be reported to people other than the asrg. From mohta@necom830.hpcl.titech.ac.jp Tue Jun 9 17:19:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3A13A6B43 for ; Tue, 9 Jun 2009 17:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frWAF-p++n0e for ; Tue, 9 Jun 2009 17:19:00 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 2F2AA3A6B03 for ; Tue, 9 Jun 2009 17:19:00 -0700 (PDT) Received: (qmail 97252 invoked from network); 10 Jun 2009 01:51:41 -0000 Received: from bmdi2056.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (202.221.174.56) by necom830.hpcl.titech.ac.jp with SMTP; 10 Jun 2009 01:51:41 -0000 Message-ID: <4A2EFBCE.5000502@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Jun 2009 09:18:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: David Wilson References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> <1244535420.2760.64.camel@bravo.isode.net> In-Reply-To: <1244535420.2760.64.camel@bravo.isode.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 00:19:00 -0000 David Wilson wrote: >>As has been discussed in the thread, DNSSEC is NOT a protection >>against cache poisoning, because caches poisoned with forged >>certificate breaks the security. > I think you need to explain how this happens in detail. In detail??? See below. > With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Tue Jun 9 17:39:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A763A6AD3 for ; Tue, 9 Jun 2009 17:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDyMA30odL7w for ; Tue, 9 Jun 2009 17:39:44 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 483F93A6916 for ; Tue, 9 Jun 2009 17:39:44 -0700 (PDT) Received: (qmail 98066 invoked from network); 10 Jun 2009 02:12:36 -0000 Received: from bmdi2056.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (202.221.174.56) by necom830.hpcl.titech.ac.jp with SMTP; 10 Jun 2009 02:12:36 -0000 Message-ID: <4A2F00B4.9060300@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Jun 2009 09:39:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: David Wilson References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> <1244534715.2760.51.camel@bravo.isode.net> In-Reply-To: <1244534715.2760.51.camel@bravo.isode.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 00:39:45 -0000 David Wilson wrote: >>The provision is through hops of certificate authorities, > As I clearly stated, As we are discussing on concepts described in two papers, your own statement without proper quotation from the papers does not mean anything. > the actual signing is end to end, The security hole is located not between certificate authorities but within certificate authorities. To quote from the 2001 paper, Transactions based on a wellknown public key can be rather simple two-party interactions that fit well within the end to end paradigm. However, there is a key role for a third party, which is to issue a Public Key Certificate and manage the stock of such certificates; such parties are called certificate authorities. the first sentence roughly corresponds to your statement "the actual signing is end to end", however... And the third parties of certificate authorities constitute a chain, a channel, hops or whatever terminology you might use, which is not end to end. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Wed Jun 10 15:55:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376D33A6B4A for ; Wed, 10 Jun 2009 15:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.713 X-Spam-Level: * X-Spam-Status: No, score=1.713 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFg7a5BW1Mih for ; Wed, 10 Jun 2009 15:55:25 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 3997F3A68AD for ; Wed, 10 Jun 2009 15:55:25 -0700 (PDT) Received: (qmail 67251 invoked from network); 11 Jun 2009 00:28:25 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 11 Jun 2009 00:28:25 -0000 Message-ID: <4A3039BC.1050608@necom830.hpcl.titech.ac.jp> Date: Thu, 11 Jun 2009 07:54:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Andrew Sullivan References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> <1244535420.2760.64.camel@bravo.isode.net> <4A2EFBCE.5000502@necom830.hpcl.titech.ac.jp> <20090610165911.GH33231@shinkuro.com> In-Reply-To: <20090610165911.GH33231@shinkuro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: David Wilson , Anti-Spam Research Group - IRTF , "ietf@ietf.org" Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 22:55:26 -0000 Andrew Sullivan wrote: >>>With DNSSEC, a security aware resolver will want to check the signature. >>Except for glue A. > That's not a vector for attack. Glue is the vector for most, if not all, attacks including Kaminsky's and DNSSEC with forged certificates. > If you are validating data, why would > you not follow the chain to the glue record (secured on each side of > _that_ cut by the DS/DNSKEY pairs) and validate the signature on the > authoritative data you get? Following the chain over a forged certificate to confirm forged data have valid signatures? Or, what if the glue is inside a grand child zone on which no nameservers are responding? When DNSSEC was designed, I pointed out several detailed but fatal problems including that glue can not be secured. The WG had a different fantasy. The WG wasted about 10 years for experimental deployment only to confirm that I have been perfectly correct and the protocol was modified. So, you don't have to waste yet another 10 years only to reconfirm it. Just accept the current DNSSEC protocol: >>>With DNSSEC, a security aware resolver will want to check the signature. >>Except for glue A. which makes DNSSEC as insecure as plain old DNS. Masataka Ohta From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 10 16:24:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8279D3A6987 for ; Wed, 10 Jun 2009 16:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.185 X-Spam-Level: X-Spam-Status: No, score=-9.185 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g09h+HOhfZvS for ; Wed, 10 Jun 2009 16:24:39 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id C69463A6358 for ; Wed, 10 Jun 2009 16:24:38 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id TAA11702; Wed, 10 Jun 2009 19:24:44 -0400 (EDT) From: der Mouse Message-Id: <200906102324.TAA11702@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 10 Jun 2009 19:15:39 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3039BC.1050608@necom830.hpcl.titech.ac.jp> References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> <1244535420.2760.64.camel@bravo.isode.net> <4A2EFBCE.5000502@necom830.hpcl.titech.ac.jp> <20090610165911.GH33231@shinkuro.com> <4A3039BC.1050608@necom830.hpcl.titech.ac.jp> Subject: Re: [Asrg] DNSSEC is NOT secure end to end X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 23:24:44 -0000 >>>> With DNSSEC, a security aware resolver will want to check the >>>> signature. >>> Except for glue A. > which makes DNSSEC as insecure as plain old DNS. Um, I think I disagree. Given a system with many points of compromise and a system with fewer points of compromise, other things being equal, I think it's fair to say the latter is more secure, even if successful compromises lead to approximately equal levels of damage. Is the difference in this case substantial? I don't know; I haven't looked at any of the attacks in enough detail to have more than wild guesses at their difficulties. But I think "as insecure as" is inaccurate, even if the truth is something more like "only marginally more secure than". In particular, domains that do not need glue records are not threatened by this. (Of course, their nameserver address records need securing, or there is a similar attack that could work. But it increases the complexity of the attack at the very least, and once the root zone is signed it will be theoretically possible, at least, to avoid the problem completely.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Thu Jun 11 08:59:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B613A6910 for ; Thu, 11 Jun 2009 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhNWxLKiylvr for ; Thu, 11 Jun 2009 08:59:25 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id F184B3A6848 for ; Thu, 11 Jun 2009 08:59:24 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 11 Jun 2009 17:59:26 +0200 id 00000000005DC031.000000004A3129DE.00005788 Message-ID: <4A3129DE.1040003@tana.it> Date: Thu, 11 Jun 2009 17:59:26 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] Fwd: New Version Notification for draft-vesely-vhlo-02 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:59:26 -0000 I've rewritten the abstract and the intro. Is it now any clearer? -------- Original Message -------- Subject: New Version Notification for draft-vesely-vhlo-02 Date: Wed, 10 Jun 2009 11:26:04 -0700 (PDT) From: IETF I-D Submission Tool To: vesely@tana.it A new version of I-D, draft-vesely-vhlo-02.txt has been successfuly submitted by Alessandro Vesely and posted to the IETF repository. Filename: draft-vesely-vhlo Revision: 02 Title: Verified-Hello SMTP extension Creation_date: 2009-06-10 WG ID: Independent Submission Number_of_pages: 22 Abstract: This memo defines an extension to the SMTP service that provides protocol support for weak authentication of SMTP clients. Weakly authenticated clients enjoy an intermediate level of trust: they have no relying privileges, but can attempt to deliver mail to local users, are whitelisted from some filters, and may receive DSNs as needed. Note that this treatment is what SMTP recommends for all clients. However, most servers operate filters to limit spam, thereby affecting the reliability of the mail forwarding system. Verified- Hello aims at providing standard support for the mechanisms involved, so that they can be managed and branded. The IETF Secretariat. From vesely@tana.it Fri Jun 12 11:28:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26923A6BAE for ; Fri, 12 Jun 2009 11:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, LONGWORDS=1.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDNoemhvBjIB for ; Fri, 12 Jun 2009 11:28:02 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 861993A6B58 for ; Fri, 12 Jun 2009 11:28:02 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 12 Jun 2009 20:28:08 +0200 id 00000000005DC033.000000004A329E38.0000207D Message-ID: <4A329E38.9010609@tana.it> Date: Fri, 12 Jun 2009 20:28:08 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:28:03 -0000 I've only been subscribed to this list for 18 months, so you will forgive me if I haven't yet grasped how it works. I've been receiving spam for much longer than that, and lazily waited for someone to reel off the rules to kill that plague. It never happened. Why? When I subscribed, I thought I'd at least understand that... Understanding this list's dynamics is not easier. As in many lists, messages that start a new thread are relatively rare. I don't have message-per-thread statistics, but usually there are many responses. Some messages get no response; for example, Frank sent a message on Spam Statistics on April 28, and nobody answered, AFAIK. In particular, I'm puzzled as to why I got no answer to my yesterday's message. A previous message by Amir, DNS-based Email Sender Authentication Mechanisms: a Critical Review, had several responses. The subject of my I-D is almost the same, an SMTP extension to manage those authentication mechanisms. However, I had exactly zero response. The same happened for a similar message I sent on May 25. I cannot believe it is by chance. Since it happened twice in a row, there has to be a sound reason. Possible guesses: * Because nobody is interested in the subject. Already ruled out: it is the same subject of Amir's paper (rDNS, SPF, DKIM, and the like.) How come nobody is interested? * Because nobody has the time to retrieve the I-D from the web. Doesn't work, by the same argument nobody would have read Amir's paper. * Because it is poorly written. Well, my English is not that good, but used to be readable. Also, at first I thought an I-D's introduction should only give a hint at interpreting the behavior described in the rest of the text, in order to let readers draw the consequences more freely. Now I've changed it to describe the use model. I admit that's confusing, but not to the point of not discussing it: in facts, I've discussed it with a handful of people already, but never on a list. Hm... _that_'s puzzling. * Because it is written by me. Naah... paranoid. * Because nobody is interested in yet another anti-spam tool. I could understand that. But this does not explain why everyone resisted to the temptation of telling me why I'm an asshole. * Because someone wrote privately to everyone banning public answers. Unbelievable, paranoid, I don't think would ever have worked as intended. * Because vhlo is not endorsed by John. Not really. John himself told me to write to the list. Possibly, he did not answer because he wanted to see if anybody _else_ was interested. * Because it is not endorsed by the IESG. Uh? What is the IESG? * Because the referred paper is an I-D. Hmm... this list has been discussing I-Ds before. However, it may be that a public message about an I-D would have be classified as rough dissension and thereby commit the IETF to do something with it, such as assigning it a "dead" state. I'm not much into the standardization process, but such a rule would seem too bureaucratically silly to be operative. Yet, it happens every time. I bet I can reproduce that behavior consistently, look at this: "Hey, I've written take 3". See any response? No. So, why? FWIW, and for your convenience, I paste below the original text that inspired the title of this rant. Hello darkness my old friend, I've come to talk with you again Because a vision softly creeping left it's seeds while I was sleeping And the vision that was planted in my brain still remains, within the sounds of silence In restless dreams I walked alone, narrow streets of cobblestone 'neath the halo of a streetlamp I turned my collar to the cold and damp when my eyes were stabbed by the flash of a neon light split the night... and touched the sound of silence And in the naked light I saw ten thousand people maybe more people talking without speaking people hearing without listening people writing songs that voices never share noone dare, disturb the sound of silence Fools said I you do not know, silence like a cancer grows, hear my words that I might teach you take my arms that I might reach you but my words, like silent raindrops fell... and echoed the will of silence And the people bowed and prayed, to the neon god they made And the sign flashed out its warning in the words that it was forming And the sign said, "The words of the prophets are written on the subway walls, and tenement halls and whisper the sounds of silence. From dotzero@gmail.com Fri Jun 12 11:46:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B723A677C for ; Fri, 12 Jun 2009 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnLrtDx-ongw for ; Fri, 12 Jun 2009 11:46:47 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 600223A6C0C for ; Fri, 12 Jun 2009 11:46:47 -0700 (PDT) Received: by qyk33 with SMTP id 33so3129548qyk.15 for ; Fri, 12 Jun 2009 11:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=dHN2P10e+JCBWu+eQAiZLqsrVLZbFNjbwS1a+mCfdIw=; b=cSjYdtadRhYvvIuHjb8ueIflaRh1aoC4hr/R8292gB6kD61wdbgFR3NEBco3cELQfY TJKgQ6ndhUXvWLlyAX412oiiYE7UMSoM6kiGfKFWPz8VnluAk22fhz2V9WHB0XZBcSdv kCFW/DSfVQW9IINxlAoxUU+myQ5XUHNbrhcw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=l0taACrFHc8VuKJkvmHVaeR5RylYlZz+JHn78R0/U5X4Ta5J0aB10MPbr0paVOrrjl mjdHeKn3dWPjkDUewpjXIJhsYCqaDaExz5XCPOMFAwIfBq97GfH1ZVvN5h23hQ0F95Cj dv1o4bKe1+1LlPw2bxKt+fYYeGM5lhll0oOR8= MIME-Version: 1.0 Received: by 10.220.100.5 with SMTP id w5mr3725848vcn.62.1244832415058; Fri, 12 Jun 2009 11:46:55 -0700 (PDT) In-Reply-To: <4A329E38.9010609@tana.it> References: <4A329E38.9010609@tana.it> Date: Fri, 12 Jun 2009 14:46:54 -0400 Message-ID: <7ae58c220906121146u6770beb1q215c500b646e6427@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:46:48 -0000 My guess is "need more patience grasshopper". I didn't respond to your post because I haven't read your draft yet (light reading for the weekend?) although it is on my to-do list. I've read your posts on other lists and you seem a reasonable person so I do plan on taking the time to read the draft. Some of us have day jobs that have to take a priority to reading and responding. Lastly, the level of discussion on ASRG hasn't gotten me overly excited overall in quite some time so I don't always pay as close attention to the flow of posts as I might on some other lists. On Fri, Jun 12, 2009 at 2:28 PM, Alessandro Vesely wrote: > I've only been subscribed to this list for 18 months, so you will forgive me > if I haven't yet grasped how it works. I've been receiving spam for much > longer than that, and lazily waited for someone to reel off the rules to > kill that plague. It never happened. Why? When I subscribed, I thought I'd > at least understand that... > > Understanding this list's dynamics is not easier. As in many lists, messages > that start a new thread are relatively rare. I don't have message-per-thread > statistics, but usually there are many responses. Some messages get no > response; for example, Frank sent a message on Spam Statistics on April 28, > and nobody answered, AFAIK. > > In particular, I'm puzzled as to why I got no answer to my yesterday's > message. A previous message by Amir, DNS-based Email Sender Authentication > Mechanisms: a Critical Review, had several responses. The subject of my I-D > is almost the same, an SMTP extension to manage those authentication > mechanisms. However, I had exactly zero response. The same happened for a > similar message I sent on May 25. I cannot believe it is by chance. Since it > happened twice in a row, there has to be a sound reason. > > Possible guesses: > > * Because nobody is interested in the subject. > Already ruled out: it is the same subject of Amir's paper (rDNS, SPF, DKIM, > and the like.) How come nobody is interested? > > * Because nobody has the time to retrieve the I-D from the web. > Doesn't work, by the same argument nobody would have read Amir's paper. > > * Because it is poorly written. > Well, my English is not that good, but used to be readable. Also, at first I > thought an I-D's introduction should only give a hint at interpreting the > behavior described in the rest of the text, in order to let readers draw the > consequences more freely. Now I've changed it to describe the use model. I > admit that's confusing, but not to the point of not discussing it: in facts, > I've discussed it with a handful of people already, but never on a list. > Hm... _that_'s puzzling. > > * Because it is written by me. > Naah... paranoid. > > * Because nobody is interested in yet another anti-spam tool. > I could understand that. But this does not explain why everyone resisted to > the temptation of telling me why I'm an asshole. > > * Because someone wrote privately to everyone banning public answers. > Unbelievable, paranoid, I don't think would ever have worked as intended. > > * Because vhlo is not endorsed by John. > Not really. John himself told me to write to the list. Possibly, he did not > answer because he wanted to see if anybody _else_ was interested. > > * Because it is not endorsed by the IESG. > Uh? What is the IESG? > > * Because the referred paper is an I-D. > Hmm... this list has been discussing I-Ds before. However, it may be that a > public message about an I-D would have be classified as rough dissension and > thereby commit the IETF to do something with it, such as assigning it a > "dead" state. I'm not much into the standardization process, but such a rule > would seem too bureaucratically silly to be operative. > > > Yet, it happens every time. I bet I can reproduce that behavior > consistently, look at this: "Hey, I've written take 3". See any response? > No. So, why? > > FWIW, and for your convenience, I paste below the original text that > inspired the title of this rant. > > > Hello darkness my old friend, > I've come to talk with you again > Because a vision softly creeping > left it's seeds while I was sleeping > And the vision that was planted in my brain > still remains, within the sounds of silence > > In restless dreams I walked alone, > narrow streets of cobblestone > 'neath the halo of a streetlamp > I turned my collar to the cold and damp > when my eyes were stabbed by the flash of a neon light > split the night... and touched the sound of silence > > And in the naked light I saw > ten thousand people maybe more > people talking without speaking > people hearing without listening > people writing songs that voices never share > noone dare, disturb the sound of silence > > Fools said I you do not know, > silence like a cancer grows, > hear my words that I might teach you > take my arms that I might reach you > but my words, like silent raindrops fell... > and echoed the will of silence > > And the people bowed and prayed, > to the neon god they made > And the sign flashed out its warning > in the words that it was forming > And the sign said, "The words of the prophets > are written on the subway walls, and tenement halls > and whisper the sounds of silence. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > From prussell@nd.edu Fri Jun 12 11:55:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B5428C19C for ; Fri, 12 Jun 2009 11:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 854smbL6CK27 for ; Fri, 12 Jun 2009 11:55:45 -0700 (PDT) Received: from mx-p2.cc.nd.edu (mx-p2.cc.nd.edu [129.74.250.58]) by core3.amsl.com (Postfix) with ESMTP id B5E603A677C for ; Fri, 12 Jun 2009 11:55:45 -0700 (PDT) Received: from mta-1.cc.nd.edu (mta-1.cc.nd.edu [129.74.250.35]) by mx-p2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5CIvkxr006895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Jun 2009 14:57:46 -0400 Received: from [172.19.226.111] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5CItpCc016614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jun 2009 14:55:52 -0400 (EDT) Message-ID: <4A32A4B7.3080407@nd.edu> Date: Fri, 12 Jun 2009 14:55:51 -0400 From: Paul Russell User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> In-Reply-To: <4A329E38.9010609@tana.it> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.35 X-ND-MTA-Date: Fri, 12 Jun 2009 14:57:47 EDT Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:55:46 -0000 On 6/12/2009 14:28, Alessandro Vesely wrote: > > Yet, it happens every time. I bet I can reproduce that behavior > consistently, look at this: "Hey, I've written take 3". See any > response? No. So, why? > Priorities; the summary you posted piqued my interest, but I have not yet had time to read the full document. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame From iane@sussex.ac.uk Mon Jun 15 02:14:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF5B3A6914 for ; Mon, 15 Jun 2009 02:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1D3c6XcgBdt for ; Mon, 15 Jun 2009 02:14:02 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id B0C8A3A6767 for ; Mon, 15 Jun 2009 02:13:59 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51492) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KL9W9P-000KON-F2 for asrg@irtf.org; Mon, 15 Jun 2009 10:13:01 +0100 Date: Mon, 15 Jun 2009 10:12:59 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A329E38.9010609@tana.it> References: <4A329E38.9010609@tana.it> Originator-Info: login-token=Mulberry:01/CWgxmWGDis9kvQoaEtvmhM5Yp3BIF9LcZA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 09:14:03 -0000 --On 12 June 2009 20:28:08 +0200 Alessandro Vesely wrote: > I've only been subscribed to this list for 18 months, so you will forgive > me if I haven't yet grasped how it works. I've been receiving spam for > much longer than that, and lazily waited for someone to reel off the > rules to kill that plague. It never happened. Why? When I subscribed, I > thought I'd at least understand that... Can I suggest that a URL for the draft might be useful? > > Understanding this list's dynamics is not easier. As in many lists, > messages that start a new thread are relatively rare. I don't have > message-per-thread statistics, but usually there are many responses. Some > messages get no response; for example, Frank sent a message on Spam > Statistics on April 28, and nobody answered, AFAIK. > > In particular, I'm puzzled as to why I got no answer to my yesterday's > message. A previous message by Amir, DNS-based Email Sender > Authentication Mechanisms: a Critical Review, had several responses. The > subject of my I-D is almost the same, an SMTP extension to manage those > authentication mechanisms. However, I had exactly zero response. The same > happened for a similar message I sent on May 25. I cannot believe it is > by chance. Since it happened twice in a row, there has to be a sound > reason. > > Possible guesses: > > * Because nobody is interested in the subject. > Already ruled out: it is the same subject of Amir's paper (rDNS, SPF, > DKIM, and the like.) How come nobody is interested? > > * Because nobody has the time to retrieve the I-D from the web. > Doesn't work, by the same argument nobody would have read Amir's paper. > > * Because it is poorly written. > Well, my English is not that good, but used to be readable. Also, at > first I thought an I-D's introduction should only give a hint at > interpreting the behavior described in the rest of the text, in order to > let readers draw the consequences more freely. Now I've changed it to > describe the use model. I admit that's confusing, but not to the point of > not discussing it: in facts, I've discussed it with a handful of people > already, but never on a list. Hm... _that_'s puzzling. > > * Because it is written by me. > Naah... paranoid. > > * Because nobody is interested in yet another anti-spam tool. > I could understand that. But this does not explain why everyone resisted > to the temptation of telling me why I'm an asshole. > > * Because someone wrote privately to everyone banning public answers. > Unbelievable, paranoid, I don't think would ever have worked as intended. > > * Because vhlo is not endorsed by John. > Not really. John himself told me to write to the list. Possibly, he did > not answer because he wanted to see if anybody _else_ was interested. > > * Because it is not endorsed by the IESG. > Uh? What is the IESG? > > * Because the referred paper is an I-D. > Hmm... this list has been discussing I-Ds before. However, it may be that > a public message about an I-D would have be classified as rough > dissension and thereby commit the IETF to do something with it, such as > assigning it a "dead" state. I'm not much into the standardization > process, but such a rule would seem too bureaucratically silly to be > operative. > > > Yet, it happens every time. I bet I can reproduce that behavior > consistently, look at this: "Hey, I've written take 3". See any response? > No. So, why? > > FWIW, and for your convenience, I paste below the original text that > inspired the title of this rant. > > > Hello darkness my old friend, > I've come to talk with you again > Because a vision softly creeping > left it's seeds while I was sleeping > And the vision that was planted in my brain > still remains, within the sounds of silence > > In restless dreams I walked alone, > narrow streets of cobblestone > 'neath the halo of a streetlamp > I turned my collar to the cold and damp > when my eyes were stabbed by the flash of a neon light > split the night... and touched the sound of silence > > And in the naked light I saw > ten thousand people maybe more > people talking without speaking > people hearing without listening > people writing songs that voices never share > noone dare, disturb the sound of silence > > Fools said I you do not know, > silence like a cancer grows, > hear my words that I might teach you > take my arms that I might reach you > but my words, like silent raindrops fell... > and echoed the will of silence > > And the people bowed and prayed, > to the neon god they made > And the sign flashed out its warning > in the words that it was forming > And the sign said, "The words of the prophets > are written on the subway walls, and tenement halls > and whisper the sounds of silence. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From mike@schadone.com Mon Jun 15 11:10:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E66B3A6CF8 for ; Mon, 15 Jun 2009 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB1Etx1zYS7i for ; Mon, 15 Jun 2009 11:10:11 -0700 (PDT) Received: from k2smtpout05-01.prod.mesa1.secureserver.net (k2smtpout05-01.prod.mesa1.secureserver.net [64.202.189.56]) by core3.amsl.com (Postfix) with SMTP id 080733A6CE7 for ; Mon, 15 Jun 2009 11:10:07 -0700 (PDT) Received: (qmail 29496 invoked from network); 15 Jun 2009 18:10:16 -0000 Received: from unknown (HELO XPERHOST.XPERCOMM.NET) (216.69.177.57) by k2smtpout05-01.prod.mesa1.secureserver.net (64.202.189.56) with ESMTP; 15 Jun 2009 18:10:16 -0000 Received: from d-66-212-214-214.cpe.metrocast.net [66.212.214.214] by XPERHOST.XPERCOMM.NET with SMTP; Mon, 15 Jun 2009 11:09:30 -0700 Message-ID: <4A368E60.7000606@schadone.com> Date: Mon, 15 Jun 2009 14:09:36 -0400 From: Mike Schadone User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> In-Reply-To: <4A329E38.9010609@tana.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] [OT] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:10:12 -0000 Alessandro, It may have something to do with your messages being filtered into the SPAM folder. I have been lurking in this group for a few years trying to keep abreast of the technology. Of those that post to the list, you (unfortunately) are the only one who gets sent to the SPAM folder, automatically, might I add (this is not by my design). Perhaps others who might be interested in what you have to say are finding your messages mixed in with the trash also? Michael Schadone Alessandro Vesely wrote: > I've only been subscribed to this list for 18 months, so you will > forgive me if I haven't yet grasped how it works. I've been receiving > spam for much longer than that, and lazily waited for someone to reel > off the rules to kill that plague. It never happened. Why? When I > subscribed, I thought I'd at least understand that... > > Understanding this list's dynamics is not easier. As in many lists, > messages that start a new thread are relatively rare. I don't have > message-per-thread statistics, but usually there are many responses. > Some messages get no response; for example, Frank sent a message on Spam > Statistics on April 28, and nobody answered, AFAIK. > > In particular, I'm puzzled as to why I got no answer to my yesterday's > message. A previous message by Amir, DNS-based Email Sender > Authentication Mechanisms: a Critical Review, had several responses. The > subject of my I-D is almost the same, an SMTP extension to manage those > authentication mechanisms. However, I had exactly zero response. The > same happened for a similar message I sent on May 25. I cannot believe > it is by chance. Since it happened twice in a row, there has to be a > sound reason. > > Possible guesses: > From asrg3@billmail.scconsult.com Mon Jun 15 11:17:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAACE3A6D05 for ; Mon, 15 Jun 2009 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXYYhnFvueFh for ; Mon, 15 Jun 2009 11:17:45 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 467B03A69ED for ; Mon, 15 Jun 2009 11:17:45 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 9D2AC8D3F10 for ; Mon, 15 Jun 2009 14:17:51 -0400 (EDT) Message-ID: <4A36904E.8040908@billmail.scconsult.com> Date: Mon, 15 Jun 2009 14:17:50 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> In-Reply-To: <4A329E38.9010609@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:17:46 -0000 Alessandro Vesely wrote, On 6/12/09 2:28 PM: > I've only been subscribed to this list for 18 months, so you will > forgive me if I haven't yet grasped how it works. I've been receiving > spam for much longer than that, and lazily waited for someone to reel > off the rules to kill that plague. It never happened. Why? When I > subscribed, I thought I'd at least understand that... Different people (and mail systems) have different spam problems. Many people have come up with "good enough" solutions for their own spam problems, but they are no all the same solutions. The idea that there is or could be one solution that works for everyone has largely fallen into disrepute because all of the attempts at it have fallen far short of the goal. Unfortunately, many of the de facto best current practices are completely unsuited for technical standardization. I don't think anyone wants to see any sort of RFC that recommends using any specific DNSBL, but for many people running mail systems of a wide variety the use of the Spamhaus Zen DNSBL is their most effective single anti-spam tactic. Recommending the shunning of specific whole countries certainly does not belong in anything that anyone might see as a "standard" but as a matter of practicality, many mail systems do so to great benefit and at no tangible cost. Because spam is fundamentally a social problem rather than a technical problem, the technical approaches to fixing it are all imperfect, many subsets are subject to "arms race" problems, and the only generalizable solution is that everyone running a mail system should apply a mix of tactics suited to their spam and their non-spam (based on the locally relevant definition of "spam") and pay attention to how those tactics work *for them* rather than seek to locally deploy some global solution. > Understanding this list's dynamics is not easier. As in many lists, > messages that start a new thread are relatively rare. I don't have > message-per-thread statistics, but usually there are many responses. > Some messages get no response; for example, Frank sent a message on Spam > Statistics on April 28, and nobody answered, AFAIK. There's not much in that case to answer about. He provided a link to a site that provides interesting stats for one vendor's customers, but a lot of us understand well that such stats are not particularly useful globally. > In particular, I'm puzzled as to why I got no answer to my yesterday's > message. A previous message by Amir, DNS-based Email Sender > Authentication Mechanisms: a Critical Review, had several responses. You should keep in mind that the short-term level of response here to an idea is going to be somewhat inversely related to how well it is reasoned and presented. I think if you look at the nature of the early responses to that post you will find that the first day was dominated by people complaining about the manner of presentation. > The > subject of my I-D is almost the same, an SMTP extension to manage those > authentication mechanisms. However, I had exactly zero response. The > same happened for a similar message I sent on May 25. I cannot believe > it is by chance. Since it happened twice in a row, there has to be a > sound reason. I thought Logical Positivism was a dead school of philosophy, but it seems not... :) > Possible guesses: > > * Because nobody is interested in the subject. > Already ruled out: it is the same subject of Amir's paper (rDNS, SPF, > DKIM, and the like.) How come nobody is interested? It's not the same. It's an actual new idea rather than a rehash/critique of existing tools. Many people here have already thought about (and in some cases used) the various MARID tactics. It does not take a lot of new thought to throw the same old rocks at their pet targets, but it does require new careful thought to discuss a new idea. > * Because nobody has the time to retrieve the I-D from the web. > Doesn't work, by the same argument nobody would have read Amir's paper. His takes less effort to form an opinion on. I also think that the difference in media is important. An I-D is presumably intended as a step towards a RFC, and people here ought to understand that public discussions of I-D's should be done carefully. Your proposal is complex enough that making a careful analysis takes real effort. A casual scan of the document doesn't yield obvious fatal flaws, nor does it provide any instant 'AHA!' response of how the VHLO mechanism would provide a clear fix for a major problem. That results in it seeming like a low-yield chore to go through 23 pages of details to figure out whether this idea is sound and useful. Maybe improving sections 1.1-1.3 to more directly and concisely define the problem VHLO is meant to address would encourage more attention. If I understand it correctly, the problem VHLO is trying to address is that sending and receiving sides may not always agree on which name(s) to use in application of which DNS-based authentication and authorization schemes and how strongly the results of those schemes should be interpreted as the name owner vouching for the non-spam quality of the messages involved. This tends to force receivers into complex scoring of their DNS-based and content-based filtering, making deliverability for legitimate senders highly uncertain and opaque. If I understand it correctly, you are proposing that VHLO be used to address that problem by providing a way for a SMTP sending system to provide the names, schemes, and strengths that should be used for all messages in a particular VHLO session. This allows receivers to layer DNS-based mechanisms as absolute criteria ahead of expensive and fuzzy content filters, instead of using them (as is common in tools like SpamAssassin) as scored criteria in a large collection of other similarly imperfect scored criteria. Of course, I may just be projecting my own ideas about spam control onto a very quick scan of your draft in full attention-deficit mode, and I don't have any opinion on whether the mechanical details you define will do the job that I think you want done. More telling: I'm not convinced that any new technical approach to spam control has any chance of widespread adoption or even careful attention. The jungle of existing tactics combined with a drop in user expectations has resulted in a circumstance where the demand for better mail service is not enough to get significant new technical approaches deployed. From vesely@tana.it Tue Jun 16 05:19:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344AB3A6D54 for ; Tue, 16 Jun 2009 05:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pwqOBAWz+JD for ; Tue, 16 Jun 2009 05:19:48 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6E0E13A682E for ; Tue, 16 Jun 2009 05:19:48 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 16 Jun 2009 13:28:19 +0200 id 00000000005DC031.000000004A3781D3.00001DF8 Message-ID: <4A3781D4.3020303@tana.it> Date: Tue, 16 Jun 2009 13:28:20 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> In-Reply-To: <4A36904E.8040908@billmail.scconsult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 12:19:50 -0000 Bill Cole wrote: > Different people (and mail systems) have different spam problems. I tend to understand that as different classes of spam. For an example, consider a creditor of mines who solicits payment by sending me reminders. Assume I'm not going to pay and I just discard them. If, by chance, they end up in the spam folder, would I be willing to train my Bayesian filter to avoid that? Probably no. And, are those reminders spam? In some acceptation of the term, yes. Thus, a fax or a registered letter is better than email... > Many people have come up with "good enough" solutions for their own > spam problems, but they are no all the same solutions. The idea that > there is or could be one solution that works for everyone has largely > fallen into disrepute because all of the attempts at it have fallen far > short of the goal. Unfortunately, many of the de facto best current > practices are completely unsuited for technical standardization. I don't > think anyone wants to see any sort of RFC that recommends using any > specific DNSBL, but for many people running mail systems of a wide > variety the use of the Spamhaus Zen DNSBL is their most effective single > anti-spam tactic. Recommending the shunning of specific whole countries > certainly does not belong in anything that anyone might see as a > "standard" but as a matter of practicality, many mail systems do so to > great benefit and at no tangible cost. I don't see why such techniques are not amenable to standardization. Actually, there is a couple of DNSBL drafts that are slowly moving forward. It should be possible for my SMTP server to accept mail only from, say, an office opposite with whom I do most business, and shunning all the rest except, say, Gmail, thereby relying on their filtering. There's nothing wrong with that, except for technical problems that make it difficult to set it up properly. > Because spam is fundamentally a social problem rather than a technical > problem, the technical approaches to fixing it are all imperfect, many > subsets are subject to "arms race" problems, and the only generalizable > solution is that everyone running a mail system should apply a mix of > tactics suited to their spam and their non-spam (based on the locally > relevant definition of "spam") and pay attention to how those tactics > work *for them* rather than seek to locally deploy some global solution. Yes, that's the conclusion I also reached. Spam is a universal plague and we must live with it. It is indecent to egoistically take oneself away from it. Therefore, solutions to get rid of spam are not wanted, not even discussed. BTW, discussion implies that someone will try to also get rid of direct marketing, in the bargain. So, let's keep all of it, even the inadmissible zombie-generated spam. >> In particular, I'm puzzled as to why I got no answer to my yesterday's >> message. A previous message by Amir, DNS-based Email Sender >> Authentication Mechanisms: a Critical Review, had several responses. > > You should keep in mind that the short-term level of response here to an > idea is going to be somewhat inversely related to how well it is > reasoned and presented. I think if you look at the nature of the early > responses to that post you will find that the first day was dominated by > people complaining about the manner of presentation. Someone suggested I should also have posted an URL. Those are just practical issues. >> * Because nobody is interested in the subject. >> Already ruled out: it is the same subject of Amir's paper (rDNS, SPF, >> DKIM, and the like.) How come nobody is interested? > > It's not the same. It's an actual new idea rather than a rehash/critique > of existing tools. Many people here have already thought about (and in > some cases used) the various MARID tactics. It does not take a lot of > new thought to throw the same old rocks at their pet targets, but it > does require new careful thought to discuss a new idea. That's partially correct. OTOH, it is just a mashup of those same existing tools, providing a framework for letting senders know. > I also think that the difference in media is important. An I-D is > presumably intended as a step towards a RFC, and people here ought to > understand that public discussions of I-D's should be done carefully. Being an I-D _and_ a proposed solution emphasize each other, conflicting with the universal plague requirement above. However, it is also important to reach some form of agreed failure diagnosis. Question 12 in http://asrg.sp.am/about/faq.shtml is just too generic. > Your proposal is complex enough that making a careful analysis takes > real effort. A casual scan of the document doesn't yield obvious fatal > flaws, nor does it provide any instant 'AHA!' response of how the VHLO > mechanism would provide a clear fix for a major problem. That results in > it seeming like a low-yield chore to go through 23 pages of details to > figure out whether this idea is sound and useful. Maybe improving > sections 1.1-1.3 to more directly and concisely define the problem VHLO > is meant to address would encourage more attention. That's what I've been trying to do in the last two rounds. Any explicit hint? > If I understand it correctly, the problem VHLO is trying to address is > that sending and receiving sides may not always agree on which name(s) > to use in application of which DNS-based authentication and > authorization schemes and how strongly the results of those schemes > should be interpreted as the name owner vouching for the non-spam > quality of the messages involved. This tends to force receivers into > complex scoring of their DNS-based and content-based filtering, making > deliverability for legitimate senders highly uncertain and opaque. Yes, the overall idea is simply to allow whitelisted ("first-class"?) delivery for senders who ask for it, and are eligible. Eligibility criteria already exists, based on those DNS techniques. VHLO is mainly meant for those servers who already implement various forms of whitelisting. For example, Spamhaus lookup, when used to reject, usually gives a clear response as to why rejection occurred, both to end user and log files. However, DNSBLs used for scoring, as well as positive listings and vouching, that lead a server to accept messages with suspicion, is highly uncertain and opaque, as you say. > If I understand it correctly, you are proposing that VHLO be used to > address that problem by providing a way for a SMTP sending system to > provide the names, schemes, and strengths that should be used for all > messages in a particular VHLO session. This allows receivers to layer > DNS-based mechanisms as absolute criteria ahead of expensive and fuzzy > content filters, instead of using them (as is common in tools like > SpamAssassin) as scored criteria in a large collection of other > similarly imperfect scored criteria. Correct. And also feedback, without which a sender cannot know which vouching services would provide which benefits. > Of course, I may just be projecting my own ideas about spam control onto > a very quick scan of your draft in full attention-deficit mode, and I > don't have any opinion on whether the mechanical details you define will > do the job that I think you want done. Some mechanical details may need to be amended/discussed, in case. > More telling: I'm not convinced that any new technical approach to spam > control has any chance of widespread adoption or even careful attention. > The jungle of existing tactics combined with a drop in user expectations > has resulted in a circumstance where the demand for better mail service > is not enough to get significant new technical approaches deployed. Great! I cannot tell it better than that. It obviously implies that email is going to die out. Newcomers don't perceive it as something new and exciting, but rather as an obsolete communication system used predominantly by elder people, generally left in a state of regrettable neglect. From fm-lists@espace.net Tue Jun 16 06:00:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA1F3A689E for ; Tue, 16 Jun 2009 06:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNzn0ENpHi0a for ; Tue, 16 Jun 2009 06:00:39 -0700 (PDT) Received: from espace.net (mail.espace.net [217.151.104.194]) by core3.amsl.com (Postfix) with ESMTP id AF7A03A6D70 for ; Tue, 16 Jun 2009 06:00:39 -0700 (PDT) Received: from 210.forthview.net (217.151.104.210) by espace.net with ESMTP (EIMS X 3.3.9) for ; Tue, 16 Jun 2009 14:00:00 +0100 Message-Id: <7B1BD89E-0D5A-4AE1-AED1-02C5DB5453A7@espace.net> From: Fearghas McKay To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3781D4.3020303@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 13:59:58 +0100 References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:00:40 -0000 On 16 Jun 2009, at 12:28, Alessandro Vesely wrote: > Someone suggested I should also have posted an URL. Those are just > practical issues. Yes a practical issue if you want people to comment on your Draft - make it easy for them to grab it and read it, otherwise it will disappear into the 'waiting for time to search for it, download and then review it' pool of things to do. f From mouse@Sparkle.Rodents-Montreal.ORG Tue Jun 16 06:22:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C563A6B59 for ; Tue, 16 Jun 2009 06:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.386 X-Spam-Level: X-Spam-Status: No, score=-9.386 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ykLOBhV1uqe for ; Tue, 16 Jun 2009 06:22:53 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 921AF3A6A7D for ; Tue, 16 Jun 2009 06:22:53 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA26149; Tue, 16 Jun 2009 09:01:54 -0400 (EDT) From: der Mouse Message-Id: <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 16 Jun 2009 08:47:51 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3781D4.3020303@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:22:54 -0000 >> Because spam is fundamentally a social problem rather than a >> technical problem, [...] > Yes, that's the conclusion I also reached. Spam is a universal > plague and we must live with it. Not quite. There are walled-garden approaches to email that are basically spam-free, because they have the accountability the open Internet lacks. > Someone suggested I should also have posted an URL. Those are just > practical issues. Perhaps, but they are very relevant when addressing the question of "why did my note generate no traffic?". Every additional barrier that makes it harder - even a little harder - for people will reduce the response. Speaking personally, for example, I have often ignored documents provided as PDFs where I would not have ignored the same content as a text file, because reading PDFs is substantially more complicated and unpleasant for me than reading text files. Other people will have other reasons to respond to _this_ mail rather than _that_ one - practical issues, yes, but still relevant. >> I'm not convinced that any new technical approach to spam control >> has any chance of widespread adoption or even careful attention. >> The jungle of existing tactics combined with [...] > [That] obviously implies that email is going to die out. It's not obvious to me. Can you spell it out for me how you get from Bill's lack of conviction - okay, let's make it easy and assume Bill is right: from the lack of widespread adoption or attention to new technical antispam techniques - to email dying out? > Newcomers don't perceive it as something new and exciting, but rather > as an obsolete communication system used predominantly by elder > people, generally left in a state of regrettable neglect. Honestly, this is one of the few things that could save email. If enough of the net.population deserts it for newer and shinier commuications media, spammers will perceive a lack of value in it and start leaving it alone, making it usable again for us (FVO "us" approximating "people who didn't desert it", which I expect would include most/all of the people I for one care about exchanging email with anyway). Do I expect that to happen? Not really. But neither do I see it dying out. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From iane@sussex.ac.uk Tue Jun 16 07:22:58 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3885A3A6A2F for ; Tue, 16 Jun 2009 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei9Rbo6z6dlq for ; Tue, 16 Jun 2009 07:22:57 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 371B63A6845 for ; Tue, 16 Jun 2009 07:22:57 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:65182) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLC58F-0000JC-6K for asrg@irtf.org; Tue, 16 Jun 2009 15:21:51 +0100 Date: Tue, 16 Jun 2009 15:21:05 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <19F5E9FF50D8F6854F278DA0@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> Originator-Info: login-token=Mulberry:01NktbQZ+syaZ3uK+jonGpwM60nMN8m5lxq7Y=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:22:58 -0000 --On 16 June 2009 08:47:51 -0400 der Mouse wrote: > Not quite. There are walled-garden approaches to email that are > basically spam-free, because they have the accountability the open > Internet lacks. Agreed. What efforts are being made to introduce that accountability to email? -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From sm@resistor.net Tue Jun 16 07:32:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3DA3A6B7C for ; Tue, 16 Jun 2009 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_SPAM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+poFXLS5dFD for ; Tue, 16 Jun 2009 07:32:49 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 661A03A69C4 for ; Tue, 16 Jun 2009 07:32:49 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n5GE93No025155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 07:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1245161351; x=1245247751; bh=3XjAKRGVRl9AhytVTcGdrWOzPMk4uwc3OpAHLR6XI1c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Fm3Ns5udLIICwvmtbUKbdrPa3QVo94JDMsKzuoprd3+lLGMLjIFUQL4Nb7mn1y4W+ U2btNAkcvYj2sbiOzOe52ens1OMbnpPnJHxWRMdnXWT8Ik167tPjh7ID20G3wk/NZm DO3gRXUoyhWe/eW4hQo4vumBULxtnkKp+uHOLSOY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=U6tCJbgxVINfOtCgoiBqz2XuWeXwk7rG57+hr/PXgrYLP2BNMLLCLzB7j0dnpAxFf 5+CYP4EuvKxnz4h0/awLdX5oQmPmIXRQpjPw+LWuJwt9wSxBcfmuSR0TJLcxLqcptUS IUxDfefVffaL73Vn/j9i1KciILFXR4mmGoo3Syw= Message-Id: <6.2.5.6.2.20090616060804.02e285c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Jun 2009 06:53:57 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <4A3781D4.3020303@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:32:50 -0000 At 04:28 16-06-2009, Alessandro Vesely wrote: >I tend to understand that as different classes of spam. For an >example, consider a creditor of mines who solicits payment by >sending me reminders. Assume I'm not going to pay and I just discard >them. If, by chance, they end up in the spam folder, would I be >willing to train my Bayesian filter to avoid that? Probably no. And, >are those reminders spam? In some acceptation of the term, yes. >Thus, a fax or a registered letter is better than email... "different spam problems" does not mean different classes of spam. Look at it in terms of user-base and mail traffic. You also have to understand that the problem is not linear, i.e. the amount of spam is proportional to the user-base. If you want to consider these reminders as spam, you have the right to do so. It's unlikely that all creditors will resort to sending a registered letter or a fax because of that. As you were complaining about the soundness of silence, let's see how you would have reacted if nobody answered the message you posted. :-) >I don't see why such techniques are not amenable to standardization. >Actually, there is a couple of DNSBL drafts that are slowly moving forward. Documents from the ASRG (IRTF) and the IETF fall in different streams. Within the IETF, standardization has a different meaning. >Yes, that's the conclusion I also reached. Spam is a universal >plague and we must live with it. It is indecent to egoistically take >oneself away from it. Therefore, solutions to get rid of spam are >not wanted, not even discussed. BTW, discussion implies that The different solutions are discussed but it's difficult to reach an agreement on them. >Being an I-D _and_ a proposed solution emphasize each other, >conflicting with the universal plague requirement above. However, it >is also important to reach some form of agreed failure diagnosis. >Question 12 in http://asrg.sp.am/about/faq.shtml is just too generic. Maybe there's a cultural problem. The answer to question 12 provides sound advice on what you could do before submitting a proposal. Regards, -sm From mouse@Sparkle.Rodents-Montreal.ORG Tue Jun 16 07:45:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F103A6B3A for ; Tue, 16 Jun 2009 07:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.506 X-Spam-Level: X-Spam-Status: No, score=-9.506 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yixpKf7j5ccg for ; Tue, 16 Jun 2009 07:45:33 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 362AA3A6B6A for ; Tue, 16 Jun 2009 07:45:33 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA26668; Tue, 16 Jun 2009 10:43:14 -0400 (EDT) From: der Mouse Message-Id: <200906161443.KAA26668@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 16 Jun 2009 10:32:34 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <19F5E9FF50D8F6854F278DA0@lewes.staff.uscs.susx.ac.uk> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <19F5E9FF50D8F6854F278DA0@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:45:34 -0000 >> Not quite. There are walled-garden approaches to email that are >> basically spam-free, because they have the accountability the open >> Internet lacks. > Agreed. What efforts are being made to introduce that accountability > to email? Few-to-none, as far as I can tell, outside of the walled gardens. Part of the problem is that for any-to-any email, the cooperation of the sending site is required to push responsibility back onto the sending user, too many sending sites refuse to, and the failure to impose responsibility along with authority granted goes clear to the top of Internet governance. This is in large part why I'm getting out of active abuse fighting: as long as the mismatch between authority and responsibility is so close to total at the upper levels of Internet governance, I believe anti-abuse efforts at the lower levels are almost entirely just rearranging the deck chairs on the Titanic - at best they're delaying the inevitable. I can't really put my heart into an endeavour that I believe is futile and doomed and not something I enjoy doing for its own sake. Even if I'm wrong about its being futile and doomed, that's still how it feels to me. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Tue Jun 16 08:10:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358D93A6D86 for ; Tue, 16 Jun 2009 08:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL3cJWyqF6wW for ; Tue, 16 Jun 2009 08:10:29 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 41D903A6D91 for ; Tue, 16 Jun 2009 08:10:29 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 16 Jun 2009 16:55:24 +0200 id 00000000005DC031.000000004A37B25C.00003BC8 Message-ID: <4A37B25C.8010904@tana.it> Date: Tue, 16 Jun 2009 16:55:24 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:10:30 -0000 der Mouse wrote: >>> I'm not convinced that any new technical approach to spam control >>> has any chance of widespread adoption or even careful attention. >>> The jungle of existing tactics combined with [...] >> [That] obviously implies that email is going to die out. > > It's not obvious to me. Can you spell it out for me how you get from > Bill's lack of conviction - okay, let's make it easy and assume Bill is > right: from the lack of widespread adoption or attention to new > technical antispam techniques - to email dying out? Because it is not reliable. Why would you spend your time and intelligence writing text that will end up in some spam folder without ever being read? >> Newcomers don't perceive it as something new and exciting, but rather >> as an obsolete communication system used predominantly by elder >> people, generally left in a state of regrettable neglect. > > Honestly, this is one of the few things that could save email. If > enough of the net.population deserts it for newer and shinier > communications media, spammers will perceive a lack of value in it and > start leaving it alone, making it usable again for us That's an interesting assertion. I think spammers love their honeypots, some of which possibly even pay a visit to their spamvertized sites. How will spammers perceive a lack of value? Their instigators are not looking for the most effective channel, they are looking for the cheapest. They might very well be the last ones to leave, who knows. At any rate, I'd very much avoid such experiment: It is the worst anti-spam approach I've ever heard. > (FVO "us" > approximating "people who didn't desert it", which I expect would > include most/all of the people I for one care about exchanging email > with anyway). You must be at least 47, then. Correct? ;-) > Do I expect that to happen? Not really. But neither do I see it dying > out. Do you perceive migration toward giant ESPs as the premise for newer/shinier media? The global walled-garden is just a step away. Nowadays businesses are too much concerned about costs, but what will happen when they will be wanting to pay a small amount for acceptable reliability? (Microsoft has been looking after that since their first MAPI release...) From mouse@Sparkle.Rodents-Montreal.ORG Tue Jun 16 09:05:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F623A695F for ; Tue, 16 Jun 2009 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.586 X-Spam-Level: X-Spam-Status: No, score=-9.586 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXuVEf3jbPNP for ; Tue, 16 Jun 2009 09:04:58 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id C7A0C3A68A0 for ; Tue, 16 Jun 2009 09:04:57 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA27224; Tue, 16 Jun 2009 12:04:35 -0400 (EDT) From: der Mouse Message-Id: <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 16 Jun 2009 11:33:39 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A37B25C.8010904@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:05:00 -0000 >> Can you spell it out for me how you get from Bill's lack of >> conviction - okay, let's make it easy and assume Bill is right: from >> the lack of widespread adoption or attention to new technical >> antispam techniques - to email dying out? > Because it is not reliable. Why would you spend your time and > intelligence writing text that will end up in some spam folder > without ever being read? _Will_ end up there? Without _ever_ being read? I wouldn't, of course. But that's not what we have. I participate in a lot of mailing lists, and I daresay some fraction of what I write gets ignored by some fraction of its potential readers - some of it because of misfiling by spamfilters, some of it because people have decided I'm not worth listening to, whatever. But as long as those fractions stay small enough, the readership is high enough that I don't consider the time and effort wasted. Mail does not need perfect - or even very good - reliability in order to be useful. When I first started using email, it could take a week to get mail from Montreal to California, with a chance that sometimes approached even that it would get lost on the way. This didn't deter lots of people, including me, from using it anyway. >>> Newcomers don't perceive [email] as something new and exciting, but >>> rather as an obsolete communication system [...] >> Honestly, this is one of the few things that could save email. If >> enough of the net.population deserts it for newer and shinier >> communications media, spammers will perceive a lack of value in it >> and start leaving it alone, making it usable again for us [...] > That's an interesting assertion. I think spammers love their > honeypots, some of which possibly even pay a visit to their > spamvertized sites. How will spammers perceive a lack of value? Low ROI. A honeypot can "visit" a malware drive-by installer all day, and if it doesn't result in another bot joining the botnet, it holds no value for the bot herder. Of course, not all spam is about recruiting botnets members, but similar remarks apply to all forms of spam: if it doesn't produce the desired effect, it will stop being used, whether that effect is people falling for phishing scams, people falling for 419 scams, new botnet hosts, customers for knockoff software copies, customers for "cheap meds", whatever. > Their instigators are not looking for the most effective channel, > they are looking for the cheapest. The cheapest - in terms of effect for resources invested. ROI. A spammers-only email system will provide zero-to-negative ROI. > They might very well be the last ones to leave, who knows. Could be. I did say "could save email", not "would save email". :) > At any rate, I'd very much avoid such experiment: It is the worst > anti-spam approach I've ever heard. Oh, I'm not proposing it as "let's do this in order to save email". If it happens at all, it will happen because most of the net sees email as not worth saving. (I find amusing irony in the idea that that it might prove to be be email being seen as not worth saving that saves it.) >> (FVO "us" approximating "people who didn't desert it", which I >> expect would include most/all of the people I for one care about >> exchanging email with anyway). > You must be at least 47, then. Correct? ;-) No, actually, I'm not. (Where did you get that figure? I'm curious.) >> Do I expect that to happen? Not really. But neither do I see >> [email] dying out. > Do you perceive migration toward giant ESPs as the premise for > newer/shinier media? Not premise for, exactly, but I see it as related, in that it's part of the current flood towards shiny interfaces and never mind whether the content has any value; it's new! and shiny! so it must be good. > The global walled-garden is just a step away. Perhaps. I see no sign of it, though, at least not as I sketched it; the few entities that are coming close to being global walled gardens for email (gmail being the first one that comes to my mind) are not, as far as I can tell, bothering to impose the responsibility on senders that was a premise for the walled gardens I described being any more spam-free than today's net. > Nowadays businesses are too much concerned about costs, but what will > happen when they will be wanting to pay a small amount for acceptable > reliability? I don't know. I don't even have guesses; it depends on too many other factors which you haven't specified (many of which, I suspect, nobody currently has more than guesses for either). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From asrg3@billmail.scconsult.com Tue Jun 16 10:21:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85683A6A61 for ; Tue, 16 Jun 2009 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAXK9TuWWRmT for ; Tue, 16 Jun 2009 10:21:18 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 2E84A3A6DA1 for ; Tue, 16 Jun 2009 10:21:18 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id D50118D4DA1 for ; Tue, 16 Jun 2009 13:21:20 -0400 (EDT) Message-ID: <4A37D490.3030900@billmail.scconsult.com> Date: Tue, 16 Jun 2009 13:21:20 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> In-Reply-To: <4A3781D4.3020303@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:21:19 -0000 Alessandro Vesely wrote, On 6/16/09 7:28 AM: > Bill Cole wrote: >> Different people (and mail systems) have different spam problems. > > I tend to understand that as different classes of spam. For an example, > consider a creditor of mines who solicits payment by sending me > reminders. Assume I'm not going to pay and I just discard them. If, by > chance, they end up in the spam folder, would I be willing to train my > Bayesian filter to avoid that? Probably no. And, are those reminders > spam? In some acceptation of the term, yes. Thus, a fax or a registered > letter is better than email... It goes beyond that sort of edge case of defining spam as "mail I don't like". There are envelope characteristics that exist in distinct types of mail that are mostly seen by different sets of receiving systems, such as messages with more than 10 recipients. For microdomains and mass-market mail providers, such mail is almost always archetypal spam: sent without any prior relationship to addresses harvested from the net or bought from a harvester. For many businesses, such mail is almost entirely legitimate mail from existing business partners: service providers, suppliers, etc. On different mail systems, the same low-cost rule may correlate well to the spam/non-spam classification, *but in opposite directions.* >> Many people have come up with "good enough" solutions for their own >> spam problems, but they are no all the same solutions. The idea that >> there is or could be one solution that works for everyone has largely >> fallen into disrepute because all of the attempts at it have fallen >> far short of the goal. Unfortunately, many of the de facto best >> current practices are completely unsuited for technical >> standardization. I don't think anyone wants to see any sort of RFC >> that recommends using any specific DNSBL, but for many people running >> mail systems of a wide variety the use of the Spamhaus Zen DNSBL is >> their most effective single anti-spam tactic. Recommending the >> shunning of specific whole countries certainly does not belong in >> anything that anyone might see as a "standard" but as a matter of >> practicality, many mail systems do so to great benefit and at no >> tangible cost. > > I don't see why such techniques are not amenable to standardization. > Actually, there is a couple of DNSBL drafts that are slowly moving forward. Which are good efforts, but they don't actually tell readers which DNSBL's are highly effective and which are dangerous to their mail. Or which might be both. For the overwhelming majority of mail systems, the most effective, cost-effective, and safe tool to shun spam is the Spamhaus Zen list, but it would be a very bad idea for any RFC to say that. Similarly, there are very safe, cheap, and effective ways to stop spam before DATA based on rDNS and HELO names that could never pass muster for an RFC. > It should be possible for my SMTP server to accept mail only from, say, > an office opposite with whom I do most business, and shunning all the > rest except, say, Gmail, thereby relying on their filtering. There's > nothing wrong with that, except for technical problems that make it > difficult to set it up properly. No RFC will (or should) ever recommend such an approach. That is not because such an approach will never be the best one for any system, but because it is not a widely deployable solution and it relies upon a characteristic of the mail world that may well be transient. >> Because spam is fundamentally a social problem rather than a technical >> problem, the technical approaches to fixing it are all imperfect, many >> subsets are subject to "arms race" problems, and the only >> generalizable solution is that everyone running a mail system should >> apply a mix of tactics suited to their spam and their non-spam (based >> on the locally relevant definition of "spam") and pay attention to how >> those tactics work *for them* rather than seek to locally deploy some >> global solution. > > Yes, that's the conclusion I also reached. Spam is a universal plague > and we must live with it. It is indecent to egoistically take oneself > away from it. Therefore, solutions to get rid of spam are not wanted, > not even discussed. BTW, discussion implies that someone will try to > also get rid of direct marketing, in the bargain. So, let's keep all of > it, even the inadmissible zombie-generated spam. I disagree. :) I think you are misunderstanding my point. The existing tools are good enough that most mail system operators can put together some set of them to assure that a large majority of their users see spam rarely and have very little legitimate mail blocked, while the non-zero level of errors in both directions have made users more acclimated to and forgiving of such imperfections. This has raised the bar significantly for new technical approaches, which will not even get attention unless they are very good, very low-cost, and very easy to deploy. [...] >> Your proposal is complex enough that making a careful analysis takes >> real effort. A casual scan of the document doesn't yield obvious fatal >> flaws, nor does it provide any instant 'AHA!' response of how the VHLO >> mechanism would provide a clear fix for a major problem. That results >> in it seeming like a low-yield chore to go through 23 pages of details >> to figure out whether this idea is sound and useful. Maybe improving >> sections 1.1-1.3 to more directly and concisely define the problem >> VHLO is meant to address would encourage more attention. > > That's what I've been trying to do in the last two rounds. Any explicit > hint? Replace the tutorial on mail filtering fundamentals with a concise problem definition and concise explanation of how VHLO provides a solution. [...] >> More telling: I'm not convinced that any new technical approach to >> spam control has any chance of widespread adoption or even careful >> attention. The jungle of existing tactics combined with a drop in user >> expectations has resulted in a circumstance where the demand for >> better mail service is not enough to get significant new technical >> approaches deployed. > > Great! I cannot tell it better than that. It obviously implies that > email is going to die out. Not at all. I just don't expect that it will every be like 1993 again. I think we've reached something like a dynamic equilibrium over the past few years, and it will take a really big push to change that. There are many mail systems out there shunning 97%+ of all messages while delivering less than a spam per week per user and stopping less than one legitimate message per year per user. 5 years ago, that sort of accuracy took an anti-spam craftsman tending a garden of homegrown tools (and customizations of open tools) with users screaming bloody murder over every error. Today you can buy it in a box or as a service, and the users are largely resigned to the fact that sometimes mail goes missing and sometimes they get solicited for dubious drugs and money-making schemes. Perversely, users have also become shockingly dependent on Internet email, and expect it to do things that they never would have asked back before mail administrators evolved into a breed of artful destroyers of most mail. > Newcomers don't perceive it as something new > and exciting, but rather as an obsolete communication system used > predominantly by elder people, generally left in a state of regrettable > neglect. That perception is IMHO largely shaped by the fact that the newest of newcomers are people who do not actually operate as autonomous adults. From vesely@tana.it Tue Jun 16 10:34:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8B13A6DA3 for ; Tue, 16 Jun 2009 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ0iEkeN9eJ4 for ; Tue, 16 Jun 2009 10:34:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1586D3A6D8B for ; Tue, 16 Jun 2009 10:34:18 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 16 Jun 2009 19:34:21 +0200 id 00000000005DC030.000000004A37D79D.00005654 Message-ID: <4A37D79D.90508@tana.it> Date: Tue, 16 Jun 2009 19:34:21 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> In-Reply-To: <6.2.5.6.2.20090616060804.02e285c8@resistor.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:34:20 -0000 SM wrote: > At 04:28 16-06-2009, Alessandro Vesely wrote: >> I tend to understand that as different classes of spam. For an >> example, consider a creditor of mines who solicits payment by sending >> me reminders. > > "different spam problems" does not mean different classes of spam. It should, at least in terms of the causal states that originate those problems. By its own nature, a spam message is unlikely to be a singleton. > If you want to consider these reminders as spam, you have the right to > do so. Yes, but everybody else has the right to consider me a fool for that. What unacceptably affects reliability is that I could claim I never received them since they ended up in the spam folder. > It's unlikely that all creditors will resort to sending a > registered letter or a fax because of that. They'll eventually have to, if they get no acknowledge. >> I don't see why such techniques are not amenable to standardization. >> Actually, there is a couple of DNSBL drafts that are slowly moving >> forward. > > Documents from the ASRG (IRTF) and the IETF fall in different streams. > Within the IETF, standardization has a different meaning. The "net effect" is influencing software development and its default configurations. Not to say that compliance suites bear no interest, but the differences among standardization meanings are not enforced. >> Yes, that's the conclusion I also reached. Spam is a universal plague >> and we must live with it. It is indecent to egoistically take oneself >> away from it. Therefore, solutions to get rid of spam are not wanted, >> not even discussed. > > The different solutions are discussed but it's difficult to reach an > agreement on them. Perhaps, reaching an understanding is even more important. >> [It] is also important to reach some form of agreed failure diagnosis. >> Question 12 in http://asrg.sp.am/about/faq.shtml is just too generic. > > Maybe there's a cultural problem. The answer to question 12 provides > sound advice on what you could do before submitting a proposal. Hm... sound? Vernon's list is not really helpful, except for trying and discourage potential submitters. Reviewing all relevant RFCs is a good advice, except that RFCs don't mention why they failed to be effective anti-spam solutions. From mouse@Sparkle.Rodents-Montreal.ORG Tue Jun 16 10:41:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EB928C1A5 for ; Tue, 16 Jun 2009 10:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.494 X-Spam-Level: X-Spam-Status: No, score=-8.494 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiHW4dybMYnU for ; Tue, 16 Jun 2009 10:41:07 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 2CB6328C1A7 for ; Tue, 16 Jun 2009 10:41:07 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA27908; Tue, 16 Jun 2009 13:40:41 -0400 (EDT) From: der Mouse Message-Id: <200906161740.NAA27908@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 16 Jun 2009 13:38:32 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A37D79D.90508@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:41:08 -0000 >>> Question 12 in http://asrg.sp.am/about/faq.shtml >> The answer to question 12 provides sound advice on what you could do >> before submitting a proposal. > Hm... sound? Yes. > Vernon's list is not really helpful, except for trying and discourage > potential submitters. You're reading it too literally. The "sound advice" is not present overtly; it could perhaps be phrased "make sure you're not falling into any of these traps if you want to be taken seriously rather than eliciting just pointing and laughing". /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From d.wall@computer.org Tue Jun 16 10:55:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CF43A6AA6 for ; Tue, 16 Jun 2009 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjbDwj1skK6M for ; Tue, 16 Jun 2009 10:55:15 -0700 (PDT) Received: from smtp145.iad.emailsrvr.com (smtp145.iad.emailsrvr.com [207.97.245.145]) by core3.amsl.com (Postfix) with ESMTP id 3B55F3A6807 for ; Tue, 16 Jun 2009 10:55:15 -0700 (PDT) Received: from relay24.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id DEC091B4088 for ; Tue, 16 Jun 2009 13:55:25 -0400 (EDT) Received: by relay24.relay.iad.mlsrvr.com (Authenticated sender: david.wall-AT-yozons.com) with ESMTPSA id A0F861B4076 for ; Tue, 16 Jun 2009 13:55:25 -0400 (EDT) Message-ID: <4A37DC8D.7070309@computer.org> Date: Tue, 16 Jun 2009 10:55:25 -0700 From: David Wall User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> In-Reply-To: <4A37D79D.90508@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:55:16 -0000 > Yes, but everybody else has the right to consider me a fool for that. > What unacceptably affects reliability is that I could claim I never > received them since they ended up in the spam folder. I am sure the law varies around the world, but in the U.S., aside from a few specific areas like turning off utilities, evictions and court orders, the sender is presumed to have complied with their requirements to notify you if other agreements allow for electronic communications and they made a good faith effort to send to your last known email address. Most such agreements put it on you to ensure your current email is on file and that you obviously agree to accept such email from them. The fact that you missed it, didn't read it, your spouse or child deleted it or it was spam filtered will be irrelevant. The same goes for old fashioned postal mail -- it doesn't affect their legal standing for sending you the notice even if you claim the mailman lost it, your mailbox was hit by thieves, your spouse/kids tossed it, etc. When absolute reliability is required, most will use services (email/web-based or postal or even hand-delivered) that require a signature, ID check or other the like. Web tools often have "return-receipts" that work when you read it after logging in for example, and the old "you've been served" works well for various legal issues. David From asrg3@billmail.scconsult.com Tue Jun 16 11:55:04 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7993A6BC0 for ; Tue, 16 Jun 2009 11:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVWBlWIUdNjf for ; Tue, 16 Jun 2009 11:55:04 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id F284F3A6BC8 for ; Tue, 16 Jun 2009 11:55:03 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id BDB488D4EF3 for ; Tue, 16 Jun 2009 14:55:08 -0400 (EDT) Message-ID: <4A37EA8C.2090304@billmail.scconsult.com> Date: Tue, 16 Jun 2009 14:55:08 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <19F5E9FF50D8F6854F278DA0@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <19F5E9FF50D8F6854F278DA0@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:55:05 -0000 Ian Eiloart wrote, On 6/16/09 10:21 AM: > > > --On 16 June 2009 08:47:51 -0400 der Mouse > wrote: > >> Not quite. There are walled-garden approaches to email that are >> basically spam-free, because they have the accountability the open >> Internet lacks. > > Agreed. What efforts are being made to introduce that accountability to > email? I believe that successful (on their own terms) demo projects exist in China, Iran, Cuba, and North Korea. More seriously: the trend over the past 20 years has been to *reduce* structured accountability on the Internet. Anyone who wants to only accept mail that they can be certain is from identifiable and/or trusted senders can do so now, using mature open standards that have multiple interoperable implementations including free software. AOL, CompuServe, Prodigy, The Source, Delphi, MCIMail, and just about every entity that ever received a classful allocation of address space enforced accountability on their users. More recently, the PGP user community and PGP Inc., Netscape, Microsoft, Thawte, and Verisign have all made their own valiant attempts to spread the use of tools that would support widespread user-level accountability for email. All major MTA's implement mandatory TLS encryption for transport and submission, mandatory authentication for transport and submission, and mandatory strict X.509 certificate verification, yet most also warn against using any of those except for encryption and authentication for submission and opportunistic encryption for transport without demanding cert verification. Most users of classical (i.e. POP/IMAP/MAPI/SMTP) MUA's use ones that can support message-level digital signatures and encryption, but the use of those capabilities for general Internet email is rare. Figuring out a way to get the tools for online accountability into essentially universal use without a pre-existing adjunct authoritarian polity and without creating the tools for rapid creation of a new authoritarian polity would be a very interesting and challenging research goal. I think it is outside of IRTF scope. From sm@resistor.net Tue Jun 16 11:57:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C421E28C18F for ; Tue, 16 Jun 2009 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4skAYSahYTw for ; Tue, 16 Jun 2009 11:57:10 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id F36CA3A6DA1 for ; Tue, 16 Jun 2009 11:57:09 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n5GIuVLC010952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 11:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1245178599; x=1245264999; bh=nUj+1oyDizuH0UrDub7wqmnGYp/hXHj59Ob/HfE1axU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=AHkYVhfBjLMrYf5aq0HQrY7fRZZcleo117gz3+IMGiHeLFYF4Q6sDaMmXlXJzhiVf dOI14nFcF183VJrLbVqfDDyU0+mhsGVehdhHkgOHOjuCZfxBiYzJ214ZfL7be8cPEa If7Dfl3ia1T0uIKGh74nwqeookBYBoF2aWnoCXyY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=26roDuFyeHIgnLTBm9qMlPFrPDKs1ee17xHTv895m1kibIhNw6YP5xCgFhi2agNba hm6cEyUk7QUm2UIxjFACnFmOpqK6zu/KQHksyR4qwPSbWZrxzwVw6/H5TGL7LBhPN2J DkiEtyrufIu3gu3h2SjQR/hcygLLmakByWXcNQ4= Message-Id: <6.2.5.6.2.20090616110623.02f10840@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Jun 2009 11:56:04 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <4A37D79D.90508@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:57:10 -0000 At 10:34 16-06-2009, Alessandro Vesely wrote: >Yes, but everybody else has the right to consider me a fool for >that. What unacceptably affects reliability is that I could claim I >never received them since they ended up in the spam folder. You should read the terms of service before making such claims. >They'll eventually have to, if they get no acknowledge. It's cheaper to discontinue the service for that user. >Hm... sound? Vernon's list is not really helpful, except for trying >and discourage potential submitters. Reviewing all relevant RFCs is >a good advice, except that RFCs don't mention why they failed to be >effective anti-spam solutions. The point is that before submitting a new proposal, you should read previous proposals and figure out why they failed to be effective. You can then avoid making the same mistakes. Regards, -sm From sethb@panix.com Tue Jun 16 12:34:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07243A6A91 for ; Tue, 16 Jun 2009 12:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxJ3eJUUWod3 for ; Tue, 16 Jun 2009 12:34:08 -0700 (PDT) Received: from l2mail1.panix.com (l2mail1.panix.com [166.84.1.75]) by core3.amsl.com (Postfix) with ESMTP id 04ED23A6A49 for ; Tue, 16 Jun 2009 12:34:07 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by l2mail1.panix.com (Postfix) with ESMTP id 2225A12B for ; Tue, 16 Jun 2009 15:33:06 -0400 (EDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id E233E38EAE for ; Tue, 16 Jun 2009 15:32:35 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id D6BA224221; Tue, 16 Jun 2009 15:32:35 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A37D79D.90508@tana.it> (message from Alessandro Vesely on Tue, 16 Jun 2009 19:34:21 +0200) References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> Message-Id: <20090616193235.D6BA224221@panix5.panix.com> Date: Tue, 16 Jun 2009 15:32:35 -0400 (EDT) Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:34:08 -0000 Alessandro Vesely wrote: > SM wrote: > What unacceptably affects reliability is that I could claim I never > received them since they ended up in the spam folder. You could claim you never received them because you want to claim that, independent of reality. >> It's unlikely that all creditors will resort to sending a >> registered letter or a fax because of that. > > They'll eventually have to, if they get no acknowledge. Courts very seldom accept email as sufficient notifications. (When they do, it's typically from them to lawyers practicing in that court, where the lawyer is told in advance that email from the court had better be acted upon.) Bill aren't sent certified snailmail now. Seth From franck@avonsys.com Tue Jun 16 15:20:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFF928C1D8 for ; Tue, 16 Jun 2009 15:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UBmXMzIp3vg for ; Tue, 16 Jun 2009 15:20:14 -0700 (PDT) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 9D8C028C123 for ; Tue, 16 Jun 2009 15:20:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 1763864F8594 for ; Wed, 17 Jun 2009 10:20:50 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-+I3+Okul2S for ; Wed, 17 Jun 2009 10:20:44 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 9BC9164F8593 for ; Wed, 17 Jun 2009 10:20:44 +1200 (FJT) Date: Wed, 17 Jun 2009 10:20:44 +1200 (FJT) From: Franck Martin To: asrg@irtf.org Message-ID: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> In-Reply-To: <4515812.1851245190668283.JavaMail.franck@iphone-4.genius.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_127_12935820.1245190785747" X-Originating-IP: [64.244.66.2] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1593_Mac) Subject: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 22:20:15 -0000 ------=_Part_127_12935820.1245190785747 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I recently encountered the following question/problems. I have a mail server and one of my users complains he is not receiving emails from a domain. How do I find if I have blocked the domain from sending to my server. Meaning, knowing the domain name of the sender, how do I find the IPs from where the mail could be sent from. It seems that SPF is the only tool to provide that answer? In another related problem, which is linked to IPv6 and RBL. Buidling an IPv6 RBL could lead to a huge database. Sure you can alleviate by using "wildcards", but why not use the reverse DNS resolution to add a TXT record associated to the IP to indicate the IP is the one of a mail server? So any IP that does not have this record would be blocked for SMTP. As IPv6 is not used for SMTP (or barely), this could be made mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on port 25 because we know the the etwork range of the MUA or the alternative is to use the new mail submit port. ------=_Part_127_12935820.1245190785747 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >I recently encountered the following question/problems.

I have a ma= il server and one of my users complains he is not receiving emails from a d= omain. How do I find if I have blocked the domain from sending to my server= . Meaning, knowing the domain name of the sender, how do I find the IPs fro= m where the mail could be sent from. It seems that SPF is the only tool to = provide that answer?

In another related problem, which is linked to = IPv6 and RBL. Buidling an IPv6 RBL could lead to a huge database. Sure you = can alleviate by using "wildcards", but why not use the reverse DNS resolut= ion to add a TXT record associated to the IP to indicate the IP is the one = of a mail server? So any IP that does not have this record would be blocked= for SMTP. As IPv6 is not used for SMTP (or barely), this could be made man= datory for IPv6 and optional for IPv4. An MUA could talk to an MTA on port = 25 because we know the the etwork range of the MUA or the alternative is to= use the new mail submit port.
------=_Part_127_12935820.1245190785747-- From johnl@iecc.com Tue Jun 16 15:55:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1321A3A6C17 for ; Tue, 16 Jun 2009 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opY3qk6tnvtI for ; Tue, 16 Jun 2009 15:55:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id CE97E3A693E for ; Tue, 16 Jun 2009 15:55:38 -0700 (PDT) Received: (qmail 16336 invoked from network); 16 Jun 2009 22:55:49 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 16 Jun 2009 22:55:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=3tJ0GSbj7fqoKQ0iOtP4e3cYwa3mfKbZtwDjHeToz2Q=; b=T2eZv1R18nJ0xNWnk0iatonrChp8nO010H4b5KKaUlOtz+SnfLGvQ40Bg5wHZRk5tzYfEweg+D3jV1G76Q3JM74zWA8eDXwz15G/kmk1v0vbi6QNRVeHqHvNbxORtq7s7gf9oaY2+Luaqsg2TbqNzl902l4B6jfNpWTaWKbj0Q0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=3tJ0GSbj7fqoKQ0iOtP4e3cYwa3mfKbZtwDjHeToz2Q=; b=UF/6SDaZ+gP6gR6cVzYkV22eVIOZjXXzvm7AEPjlh563+BCYMXV1DgOQ+iSlRlyW37a3xAqKV+mFN9MWQIQL20abSTvr4kR7gJzLr/laUCCrwBS+FmXXm4bLaYk6qqQG6/w1/QJ+mUDLX+aXWdrBwLhrJP+nweg3iBLiiNChZIY= Date: 16 Jun 2009 22:55:43 -0000 Message-ID: <20090616225543.11524.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 22:55:40 -0000 >How do I find if I have blocked the domain from sending to my server. Meaning, knowing the >domain name of the sender, how do I find the IPs from where the mail could be sent from. It >seems that SPF is the only tool to provide that answer? Unless you have previous mail from the domain, I would agree SPF is your best bet. >In another related problem, which is linked to IPv6 and RBL. Buidling an IPv6 RBL could lead >to a huge database. Sure you can alleviate by using "wildcards", but why not use the reverse >DNS resolution to add a TXT record associated to the IP to indicate the IP is the one of a >mail server? So any IP that does not have this record would be blocked for SMTP. We've had a variety of proposals to identify mail client hosts. See http://mipassoc.org/csv/ R's, John From sm@resistor.net Tue Jun 16 16:02:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2253D3A6C7A for ; Tue, 16 Jun 2009 16:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QlRAK6EZwFN for ; Tue, 16 Jun 2009 16:02:23 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 3CF1B3A6C6B for ; Tue, 16 Jun 2009 16:02:23 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n5GN2PtY007639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 16:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1245193353; x=1245279753; bh=4NU92sAg2ljRuVu58ZtxzA6zFvzKh4qCe+D+Qf2qlh0=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=zsmmLCUAxNUJaQ9oYRItRibzuIfGxE0evlCfKWYBdtr0682p4Ci+Q3thZdJigYhIn 6OydQeY83PJt6jxqlweZSbdQ6wWqqZRc7pkzGba9GqoZeohar14efKf38ob8ovn5lR k1Ppx6Gimfsrk8nVsDUSJsbZsY5jhaqJ6waLfS/U= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=TNX3HXwq/ADcwjoZ1TusxVgz80329h/iyYy1DEwxG/SzrNjj7JXXfOetBMwVC0e+2 7Ka1x4hCk4pmTYBVJy9qAMHABVl9CgmkhvuFjpVnpFa22nxn+JL1bIp5tQyDuA7Fi2P BmP8L+G0/5VcJmTwwNK4SJpUEfNggVGT7BJA5yo= Message-Id: <6.2.5.6.2.20090616153651.02ec61e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Jun 2009 16:01:25 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.l ocal> References: <4515812.1851245190668283.JavaMail.franck@iphone-4.genius.local> <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 23:02:24 -0000 At 15:20 16-06-2009, Franck Martin wrote: >I have a mail server and one of my users complains he is not >receiving emails from a domain. How do I find if I have blocked the >domain from sending to my server. Meaning, knowing the domain name >of the sender, how do I find the IPs from where the mail could be >sent from. It seems that SPF is the only tool to provide that answer? You can use the mail log to track down whether you blocked the domain. The information might not be available if you are blocking by IP address. You could also contact the postmaster at the other end. Regards, -sm From jjohnson@jdmc.org Tue Jun 16 16:03:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B05F3A6C17 for ; Tue, 16 Jun 2009 16:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7HF9Y11MVdf for ; Tue, 16 Jun 2009 16:03:30 -0700 (PDT) Received: from secure.jdmc.org (secure.jdmc.org [164.58.70.160]) by core3.amsl.com (Postfix) with ESMTP id C19283A6AA8 for ; Tue, 16 Jun 2009 16:03:29 -0700 (PDT) Received: from mail (mithril@localhost) by secure.jdmc.org with ESMTP id n5GN3eZ74063 for ; Tue, 16 Jun 2009 18:03:40 -0500 (CDT) (envelope-from jjohnson@jdmc.org) Received: from mail.jdmc.org (mail [164.58.70.150]) by secure.jdmc.org ([164.58.70.161]); 16 Jun 2009 18:03:40 -0500 (CDT) Received: (qmail 15684 invoked by uid 509); 16 Jun 2009 17:56:20 -0500 Received: from 164.58.70.130 by mail.jdmc.org (envelope-from , uid 508) with qmail-scanner-1.24-st-qms (clamdscan: 0.88.2/1480. spamassassin: 3.1.1. perlscan: 1.24-st-qms. Clear:RC:0(164.58.70.130):SA:0(-4.8/5.0):. Processed in 0.579026 secs); 16 Jun 2009 22:56:20 -0000 Received: from gatore.jdmc.org (HELO ?192.168.3.212?) (jjohnson@jdmc.org@164.58.70.130) by mail.jdmc.org with SMTP; 16 Jun 2009 17:56:20 -0500 X-Enigmail-Version: 0.95.7 References: <20090616225543.11524.qmail@simone.iecc.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090302) X-Antivirus-MYDOMAIN: 1.24-st-qms (Clear:RC:0(164.58.70.130):SA:0(-4.8/5.0):. Processed in 0.579026 secs Process 15674) X-Antivirus-MYDOMAIN-Mail-From: jjohnson@jdmc.org via mail.jdmc.org From: "John Johnson" To: "Anti-Spam Research Group - IRTF" Date: Tue, 16 Jun 2009 18:03:34 -0500 Message-ID: <4A3824C6.8080103@jdmc.org> In-Reply-To: <20090616225543.11524.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7BIT Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 23:03:30 -0000 John Levine wrote: >> How do I find if I have blocked the domain from sending to my server. Meaning, knowing the >> domain name of the sender, how do I find the IPs from where the mail could be sent from. It >> seems that SPF is the only tool to provide that answer? >> > > Unless you have previous mail from the domain, I would agree SPF is your best bet. > I would also add that if your e-mail is important, having good logging on your server of when the domain or ip was blocked can help speed up rectifying the problem. Yes, it's after the block occurred - but so was the complaint. From feenberg@nber.org Tue Jun 16 16:24:41 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12EC3A6C77 for ; Tue, 16 Jun 2009 16:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6b23QKfDc5H for ; Tue, 16 Jun 2009 16:24:40 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id BF79D28C0F6 for ; Tue, 16 Jun 2009 16:24:40 -0700 (PDT) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.1/8.13.8) with ESMTP id n5GNOUcU028549 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 16 Jun 2009 19:24:31 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.7+Sun/8.12.10) with ESMTP id n5GNHwWV004991; Tue, 16 Jun 2009 19:17:58 -0400 (EDT) Received: from localhost (feenberg@localhost) by nber6.nber.org (8.13.7+Sun/8.13.7/Submit) with ESMTP id n5GNHfF1004988; Tue, 16 Jun 2009 19:17:42 -0400 (EDT) X-Authentication-Warning: nber6.nber.org: feenberg owned process doing -bs Date: Tue, 16 Jun 2009 19:17:41 -0400 (EDT) From: Daniel Feenberg To: Franck Martin In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Message-ID: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20090616 #2127394, check: 20090616 clean Cc: asrg@irtf.org Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 23:24:41 -0000 On Wed, 17 Jun 2009, Franck Martin wrote: > I recently encountered the following question/problems. > > I have a mail server and one of my users complains he is not receiving > emails from a domain. How do I find if I have blocked the domain from > sending to my server. Meaning, knowing the domain name of the sender, > how do I find the IPs from where the mail could be sent from. It seems > that SPF is the only tool to provide that answer? > > In another related problem, which is linked to IPv6 and RBL. Buidling an > IPv6 RBL could lead to a huge database. Sure you can alleviate by using > "wildcards", but why not use the reverse DNS resolution to add a TXT > record associated to the IP to indicate the IP is the one of a mail > server? So any IP that does not have this record would be blocked for > SMTP. As IPv6 is not used for SMTP (or barely), this could be made > mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on > port 25 because we know the the etwork range of the MUA or the > alternative is to use the new mail submit port. I predict that no significant amount of mail ever originates from IPV6. Because it would be impossible to maintain a DNSBL for IPV6, I expect that enough sites will decline all IPV6 mail that it won't pay to send from it. Consider that because a spammer could (spoof) a different IPV6 address for every message, even a different 48 bit block for every messages, MTAs will be left with only content analysis for spam blocking. I don't expect IPV4s will ever be so scarce that enough MTAs will start using them out of necessity - ISPs will give each customer 4 IPV4 addresses with their million address IPV6 range, and customers will use those 4 addresses for the things that really need IPV4 - such as internet facing MTAs. Consider also the difficulty facing the first IPV6 only MTA. It's connectivity will be very low, even compared to the worst possible allocation of a former spammer block in IPV4. It is one thing to put up a little used IPV6 web site - there isn't much of a penalty for adding IPV6 to IPV4. And eventually some special purpose websites will be IPV6 only, those that know their clients are IPV6 only. But there isn't any point in a public-facing IPV6 MTA without an IPV4 alternative. And since the IPV4 alternative can serve the IPV6 clients just as well, it will never be very usefull to add IPV6 support. This is a prediction, not a prescription. Daniel Feenberg > From dotis@mail-abuse.org Tue Jun 16 17:24:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDD33A6AEE for ; Tue, 16 Jun 2009 17:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyDbr1IXo1MV for ; Tue, 16 Jun 2009 17:24:05 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 681BC3A696F for ; Tue, 16 Jun 2009 17:23:54 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 86A8DA94439 for ; Wed, 17 Jun 2009 00:24:04 +0000 (UTC) Message-Id: <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <20090616225543.11524.qmail@simone.iecc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 17:24:03 -0700 References: <20090616225543.11524.qmail@simone.iecc.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 00:24:06 -0000 On Jun 16, 2009, at 3:55 PM, John Levine wrote: >> How do I find if I have blocked the domain from sending to my >> server. Meaning, knowing the domain name of the sender, how do I >> find the IPs from where the mail could be sent from. It seems that >> SPF is the only tool to provide that answer? > > Unless you have previous mail from the domain, I would agree SPF is > your best bet. This is not your only bet. Many SPF records include the term MX and, when not found, even default to using MX/24. >> In another related problem, which is linked to IPv6 and RBL. >> Buidling an IPv6 RBL could lead to a huge database. Sure you can >> alleviate by using "wildcards", but why not use the reverse DNS >> resolution to add a TXT record associated to the IP to indicate the >> IP is the one of a mail server? So any IP that does not have this >> record would be blocked for SMTP. > > We've had a variety of proposals to identify mail client hosts. See http://mipassoc.org/csv/ The CSV effort proved most providers do not want their MTAs identified as belonging to them, even when it could improve email acceptance. This might be especially true now after their support staff has been reduced. Reverse DNS is already causing a large amount of resources to be wasted by the shabby state of the reverse name space. Incorrectly configured RFC 2317 delegation, and many non-functional servers are causing MTAs to rapidly become resource limited when making reverse checks. In addition, when your customers conduct business with Asia, they may not be happy to find email is being lost as a result of geographic differences of opinion about the role that reverse DNS might play with email. IMHO, all outbound MTAs should be required to return CVS records for their EHLO name and offer MX records for their inbound. A mandate that required MX (inbound) or CVS (outbound) records would greatly help in identifying non-abusive email sources against a backdrop of hundreds of millions of bot-net controlled drones spewing email. Systems may soon use ACLs as a means to white-list safe MTAs. Perhaps the world is a few years from having to go to that extreme. -Doug From lyndon@orthanc.ca Tue Jun 16 19:31:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824513A6880 for ; Tue, 16 Jun 2009 19:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4jbDcNBDkXK for ; Tue, 16 Jun 2009 19:31:32 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id 8B0B43A687A for ; Tue, 16 Jun 2009 19:31:32 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n5H2SZQV026368 for ; Tue, 16 Jun 2009 20:31:41 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1245205901; bh=mY7NGN4unBGJfYDIOUZpImJvM5XylPUN1mn7oBU/NJ8=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=N6bT4A6MtKZA4Gh1ezMv1uft+ViHbQcDl15pPCo0gtbxx8cs5vEaJGhjD1f7EpuN5 ubMTYlxaiqKPHhAbqg3yuIlXSt07K+QH4VFNLEw6/Z9ixE9oGyyBoPCbDX+PiLlt99 K+810TNUctQfhs3FGGB2C1nsuyWiQCNuMrlhxXpAdU/kOJu4fLZOqXaO0o+rJA5Soi a+uuYGr3VXjUk2RPAGA3TaOBLKppaNiIDrbqlFqTJVs+a3zK488cXsd1U3j5RaJXPN fSqAyrZZQbaijd8eGYelJ8usI7SMDNGqPKr7M0qiHE9Xr1dscPIDFGg2ummP1K9umb kisX/gCHOPbEA== From: Lyndon Nerenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> Content-Type: text/plain Date: Tue, 16 Jun 2009 19:55:45 -0600 Message-Id: <1245203745.93720.748.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 02:31:36 -0000 On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: > IMHO, all outbound MTAs should be required to return CVS records for > their EHLO name and offer MX records for their inbound. Doug, are you sure that's what you meant to say? The sentence is a bit ambiguous. Are you really saying any host that sends mail (is an SMTP client) MUST also host an listed SMTP server? --lyndon From asrg3@billmail.scconsult.com Tue Jun 16 20:27:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1533A6D6C for ; Tue, 16 Jun 2009 20:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1QYTYfIyXxL for ; Tue, 16 Jun 2009 20:27:17 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 830583A6D62 for ; Tue, 16 Jun 2009 20:27:17 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 7AAD98D551C for ; Tue, 16 Jun 2009 23:27:28 -0400 (EDT) Message-ID: <4A38629F.5040506@billmail.scconsult.com> Date: Tue, 16 Jun 2009 23:27:27 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> In-Reply-To: <1245203745.93720.748.camel@legolas.orthanc.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:27:21 -0000 Lyndon Nerenberg wrote, On 6/16/09 9:55 PM: > On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >> IMHO, all outbound MTAs should be required to return CVS records for >> their EHLO name and offer MX records for their inbound. > > Doug, are you sure that's what you meant to say? The sentence is a bit > ambiguous. Are you really saying any host that sends mail (is an SMTP > client) MUST also host an listed SMTP server? I can't testify to what he meant, but I think what he is actually saying is that if you have a machine that says "EHLO some.name" then there should be both a MX record for some.name and a SRV record for _client._smtp.some.name (i.e. a CSV/CSA record). That doesn't mean requiring inbound SMTP on every outbound, it means requiring an affirmation in DNS that a name can be used in EHLO by a particular IP address and a way to get mail to the responsible party for the machine(s) using that name in EHLO. This is an admirable goal. A weaker goal would be to get people running non-spamming mail servers to follow the existing accepted standard of using a valid resolvable FQDN in EHLO. From franck@avonsys.com Tue Jun 16 20:32:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610228C0D9 for ; Tue, 16 Jun 2009 20:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPBXE9PA3N7Y for ; Tue, 16 Jun 2009 20:32:24 -0700 (PDT) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 7115D3A6C89 for ; Tue, 16 Jun 2009 20:32:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 6124A64F8594 for ; Wed, 17 Jun 2009 15:33:26 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8K7ko8vjB2p for ; Wed, 17 Jun 2009 15:33:22 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 8E0A064F8593 for ; Wed, 17 Jun 2009 15:33:22 +1200 (FJT) Date: Wed, 17 Jun 2009 15:33:22 +1200 (FJT) From: Franck Martin To: asrg@irtf.org Message-ID: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <4A38629F.5040506@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.191.195.55] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1593_Mac) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:32:25 -0000 Knowing that mail servers are not deployed on IPv6, what would it take to make all these requirements mandatory for IPv6 and start with a better infrastructure than on IPv4? ----- Original Message ----- From: "Bill Cole" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg] What are the IPs that sends mail for a domain? Lyndon Nerenberg wrote, On 6/16/09 9:55 PM: > On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >> IMHO, all outbound MTAs should be required to return CVS records for >> their EHLO name and offer MX records for their inbound. > > Doug, are you sure that's what you meant to say? The sentence is a bit > ambiguous. Are you really saying any host that sends mail (is an SMTP > client) MUST also host an listed SMTP server? I can't testify to what he meant, but I think what he is actually saying is that if you have a machine that says "EHLO some.name" then there should be both a MX record for some.name and a SRV record for _client._smtp.some.name (i.e. a CSV/CSA record). That doesn't mean requiring inbound SMTP on every outbound, it means requiring an affirmation in DNS that a name can be used in EHLO by a particular IP address and a way to get mail to the responsible party for the machine(s) using that name in EHLO. This is an admirable goal. A weaker goal would be to get people running non-spamming mail servers to follow the existing accepted standard of using a valid resolvable FQDN in EHLO. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From asrg3@billmail.scconsult.com Tue Jun 16 20:36:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766123A68B0 for ; Tue, 16 Jun 2009 20:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLRVXZa5mGul for ; Tue, 16 Jun 2009 20:36:26 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 82BED3A6778 for ; Tue, 16 Jun 2009 20:36:26 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id DE7608D5549 for ; Tue, 16 Jun 2009 23:36:37 -0400 (EDT) Message-ID: <4A3864C5.1050006@billmail.scconsult.com> Date: Tue, 16 Jun 2009 23:36:37 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:36:27 -0000 Franck Martin wrote, On 6/16/09 6:20 PM: > I recently encountered the following question/problems. > > I have a mail server and one of my users complains he is not receiving > emails from a domain. How do I find if I have blocked the domain from > sending to my server. Meaning, knowing the domain name of the sender, > how do I find the IPs from where the mail could be sent from. There is no reliable way to do so. > It seems > that SPF is the only tool to provide that answer? Only partially. SPF cannot be considered reliable, since not all domains publish records and some publish inaccurate records. There have been other proposed approaches that may have some deployment: CSV/CSA: http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html DRIP: http://tools.ietf.org/html/draft-brand-drip-02 > In another related problem, which is linked to IPv6 and RBL. Buidling an > IPv6 RBL could lead to a huge database. Sure you can alleviate by using > "wildcards", but why not use the reverse DNS resolution to add a TXT > record associated to the IP to indicate the IP is the one of a mail > server? So any IP that does not have this record would be blocked for > SMTP. As IPv6 is not used for SMTP (or barely), this could be made > mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on > port 25 because we know the the etwork range of the MUA or the > alternative is to use the new mail submit port. Similar proposals have been made before, and I'm pretty sure one such has been made on this list although I can't find proof of that at present. There's always some degree of resistance to putting information into the reverse zone because it is frequently under different control than related forward zones and can be a chore to get set or changed. There are also concerns about loading up new sorts of records into the reverse zone because it is a simpler tree that has traditionally had light query volume, and the existing systems may not be prepared to handle an extra query down the reverse tree for every SMTP connection. That said, I think that adding DNS records that map specific network addresses to their legitimate behaviors in a generalized model would be a positive advance. From mouse@Sparkle.Rodents-Montreal.ORG Tue Jun 16 21:01:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E723A6B99 for ; Tue, 16 Jun 2009 21:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.543 X-Spam-Level: X-Spam-Status: No, score=-9.543 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7-dEmClw4f6 for ; Tue, 16 Jun 2009 21:01:45 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 2027C3A6A32 for ; Tue, 16 Jun 2009 21:01:45 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id AAA03646; Wed, 17 Jun 2009 00:01:40 -0400 (EDT) From: der Mouse Message-Id: <200906170401.AAA03646@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 16 Jun 2009 23:58:27 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> References: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:01:46 -0000 > Knowing that mail servers are not deployed on IPv6, They're not? Mine has been for years. netbsd.org's MX host is v6-reachable and I think it has been for years too. freebsd.org's ditto. And two of icann.org's five MX hosts are v6-reachable too and probably have been for quite a while. Where did you get the idea mailservers aren't deployed on v6? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From franck@avonsys.com Tue Jun 16 21:27:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794F228C186 for ; Tue, 16 Jun 2009 21:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLQf12U5lUCa for ; Tue, 16 Jun 2009 21:27:13 -0700 (PDT) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 5F01928C185 for ; Tue, 16 Jun 2009 21:27:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 23B2964F8594 for ; Wed, 17 Jun 2009 16:28:09 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJFsWTah-XPD for ; Wed, 17 Jun 2009 16:27:59 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id F1A7964F8593 for ; Wed, 17 Jun 2009 16:27:58 +1200 (FJT) Date: Wed, 17 Jun 2009 16:27:58 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <311325.1971245212816674.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <200906170401.AAA03646@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.191.195.55] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1593_Mac) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:27:14 -0000 well, I have still enough fingers to count them.... ----- Original Message ----- From: "der Mouse" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 16 June, 2009 8:58:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg] What are the IPs that sends mail for a domain? > Knowing that mail servers are not deployed on IPv6, They're not? Mine has been for years. netbsd.org's MX host is v6-reachable and I think it has been for years too. freebsd.org's ditto. And two of icann.org's five MX hosts are v6-reachable too and probably have been for quite a while. Where did you get the idea mailservers aren't deployed on v6? From asrg3@billmail.scconsult.com Tue Jun 16 22:13:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FE13A6BC1 for ; Tue, 16 Jun 2009 22:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R84BbyAWdZFO for ; Tue, 16 Jun 2009 22:13:51 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 7D87B3A6A53 for ; Tue, 16 Jun 2009 22:13:51 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 9EB848D55F0 for ; Wed, 17 Jun 2009 01:14:02 -0400 (EDT) Message-ID: <4A387B9A.2040800@billmail.scconsult.com> Date: Wed, 17 Jun 2009 01:14:02 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 05:13:52 -0000 Franck Martin wrote, On 6/16/09 11:33 PM: > Knowing that mail servers are not deployed on IPv6, what would it take to > make all these requirements mandatory for IPv6 and start with a better > infrastructure than on IPv4? How do you make anything mandatory on the net? RFC 821 is one of a handful of Internet Standards, and it is violated routinely by spammers and non-spammers for no better reason than that they never bothered to read it. That is possible because the major MTA's are functional when misconfigured (e.g. with a bogus name for EHLO/HELO use) and by default tolerate clients which violate standards. The only way anything can be functionally mandatory for email transport is if major MTA's will not work unless configured to comply and by default will not interoperate with clients that do not comply. RFC's are great, but they do not enforce themselves. If the big freemail providers and sites running Sendmail, Exchange, and Postfix generally accept mail from non-compliant clients, there will be a lot of non-compliant clients. To make good behavior mandatory, bad behavior has to break with enough frequency that it's easier to comply than negotiate exemptions. > ----- Original Message ----- From: "Bill > Cole" To: "Anti-Spam Research Group - > IRTF" Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00 > Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg] > What are the IPs that sends mail for a domain? > > Lyndon Nerenberg wrote, On 6/16/09 9:55 PM: >> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >>> IMHO, all outbound MTAs should be required to return CVS records for >>> their EHLO name and offer MX records for their inbound. >> Doug, are you sure that's what you meant to say? The sentence is a bit >> ambiguous. Are you really saying any host that sends mail (is an SMTP >> client) MUST also host an listed SMTP server? > > I can't testify to what he meant, but I think what he is actually saying > is that if you have a machine that says "EHLO some.name" then there > should be both a MX record for some.name and a SRV record for > _client._smtp.some.name (i.e. a CSV/CSA record). > > That doesn't mean requiring inbound SMTP on every outbound, it means > requiring an affirmation in DNS that a name can be used in EHLO by a > particular IP address and a way to get mail to the responsible party for > the machine(s) using that name in EHLO. This is an admirable goal. A > weaker goal would be to get people running non-spamming mail servers to > follow the existing accepted standard of using a valid resolvable FQDN in > EHLO. > > > _______________________________________________ Asrg mailing list > Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg > _______________________________________________ Asrg mailing list > Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From franck@avonsys.com Tue Jun 16 22:27:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0E73A6BEA for ; Tue, 16 Jun 2009 22:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ3+duZqCvau for ; Tue, 16 Jun 2009 22:27:06 -0700 (PDT) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 4E4B63A6BC1 for ; Tue, 16 Jun 2009 22:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 35F5264F8594 for ; Wed, 17 Jun 2009 17:27:59 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSzGQyCaqpJe for ; Wed, 17 Jun 2009 17:27:53 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 10ABE64F8593 for ; Wed, 17 Jun 2009 17:27:53 +1200 (FJT) Date: Wed, 17 Jun 2009 17:27:52 +1200 (FJT) From: Franck Martin To: asrg@irtf.org Message-ID: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <4A387B9A.2040800@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.191.195.55] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1593_Mac) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 05:27:12 -0000 Sure, it is the the be strict in what you send, lenient in what you receive. If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be negotiated, then no one will follow. We could say something like all emails on IPv6 must have a DKIM signature, have RDNS helo, etc... as there is not much of an implementation with IPv6, there is a chance for these practices to be adopted from day one... ----- Original Message ----- From: "Bill Cole" To: "Anti-Spam Research Group - IRTF" Sent: Tuesday, 16 June, 2009 10:14:02 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg] What are the IPs that sends mail for a domain? Franck Martin wrote, On 6/16/09 11:33 PM: > Knowing that mail servers are not deployed on IPv6, what would it take to > make all these requirements mandatory for IPv6 and start with a better > infrastructure than on IPv4? How do you make anything mandatory on the net? RFC 821 is one of a handful of Internet Standards, and it is violated routinely by spammers and non-spammers for no better reason than that they never bothered to read it. That is possible because the major MTA's are functional when misconfigured (e.g. with a bogus name for EHLO/HELO use) and by default tolerate clients which violate standards. The only way anything can be functionally mandatory for email transport is if major MTA's will not work unless configured to comply and by default will not interoperate with clients that do not comply. RFC's are great, but they do not enforce themselves. If the big freemail providers and sites running Sendmail, Exchange, and Postfix generally accept mail from non-compliant clients, there will be a lot of non-compliant clients. To make good behavior mandatory, bad behavior has to break with enough frequency that it's easier to comply than negotiate exemptions. From johnl@iecc.com Wed Jun 17 01:51:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDE93A6A9A for ; Wed, 17 Jun 2009 01:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov+LX9ucHKkT for ; Wed, 17 Jun 2009 01:51:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 260CF3A6949 for ; Wed, 17 Jun 2009 01:51:13 -0700 (PDT) Received: (qmail 1580 invoked from network); 17 Jun 2009 08:51:07 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 17 Jun 2009 08:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=gZEShy7rqEs1Hxr/hTnhCgHj2rZkx5ZXYV30D1sWmXY=; b=G1Zmtv2sQQ6hJSdq82lkhPZAPxBAF8zC5PB0fouW5Hu0UV2ZFYx4Tg7q1jAt7hLRom7gMbvZqoftXiOJ8O1CQZfJbC2SU/unhfXX1AI2zoXfF6hLpg1Im6+LaPkBAlqmmjJDryv2VjQDMy0i0e7iAlc9KB96uLcWm0fcj0hkRgI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=gZEShy7rqEs1Hxr/hTnhCgHj2rZkx5ZXYV30D1sWmXY=; b=KbTEJOAmk9C1aNK9NDlzt5mjpBIV2zMHFgvvLbsTjkl++TCQ3rtIqM/hkxUIU5Z8uRd6/f5NLdLG25vtG7hN4SVtmsKkXIqxCFJE7Oa8fHGkUQaG2JDUPV8ZLvxbWWtixaKYoZ/eokbVLFXuyh2lAgEbW0L/ItMga0zFe+8fYfY= Date: 17 Jun 2009 08:51:06 -0000 Message-ID: <20090617085106.2213.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 08:51:14 -0000 >If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be >negotiated, then no one will follow. The IETF is amazingly resistant to making v6 SMTP different from v4 SMTP in any way. In particular, I suggested that they not have a rule for fallback to AAAA in the absence of MX. The rationale is straightforward: most hosts with AAAA (and indeed A) records are not mail servers, people need to add new DNS records anyway for v6 so the incremental effort to install MX records is quite small, and it'll make mail more reliable by making it easier to tell when a domain doesn't receive mail. They all said too late, there are already a handful of v6 mail hosts. Sigh. R's, John From vesely@tana.it Wed Jun 17 02:18:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA49628C1FB for ; Wed, 17 Jun 2009 02:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6wfdty2xjz8 for ; Wed, 17 Jun 2009 02:17:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6F96828C1DF for ; Wed, 17 Jun 2009 02:17:58 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 11:18:08 +0200 id 00000000005DC031.000000004A38B4D0.000048F8 Message-ID: <4A38B4D0.2090305@tana.it> Date: Wed, 17 Jun 2009 11:18:08 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:18:00 -0000 der Mouse wrote: > Mail does not need perfect - or even very good - reliability in order > to be useful. When I first started using email, it could take a week > to get mail from Montreal to California, with a chance that sometimes > approached even that it would get lost on the way. This didn't deter > lots of people, including me, from using it anyway. You were pioneers, and obviously expected that whatever steps were needed to amend reliability would have been taken. In exchange for what are we giving up reliability now? >>> (FVO "us" approximating "people who didn't desert it", which I >>> expect would include most/all of the people I for one care about >>> exchanging email with anyway). >> You must be at least 47, then. Correct? ;-) > > No, actually, I'm not. (Where did you get that figure? I'm curious.) Just a guess based on http://www.apa.org/monitor/oct07/email.html and averaging on your correspondents... >> The global walled-garden is just a step away. > > Perhaps. I see no sign of it, though, at least not as I sketched it; > the few entities that are coming close to being global walled gardens > for email (gmail being the first one that comes to my mind) are not, as > far as I can tell, bothering to impose the responsibility on senders > that was a premise for the walled gardens I described being any more > spam-free than today's net. The point of responsibility deserves more insight. I mention it in the I-D, but only generically. What I'd mean is that you should be able to reach the author of a message that has been delivered to you; or, to allow anonymous posting, you should be able to reach the author's postmaster, list moderator, or similar type, who is able to reach the author, possibly indirectly, and that might disclose that information according to existing agreements, local laws, the site's policies, et cetera. Of course, an author's reputation may be affected that way. A site reputation should then result from the average reputation of the authors using that site, and a site may have a policy that allows them to push out unwanted authors. I'm not aware of liability implications, though. From vesely@tana.it Wed Jun 17 03:13:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581213A6E2B for ; Wed, 17 Jun 2009 03:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh2R8yDt-PdI for ; Wed, 17 Jun 2009 03:13:34 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id F11A23A6C73 for ; Wed, 17 Jun 2009 03:13:33 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 12:12:52 +0200 id 00000000005DC031.000000004A38C1A4.0000508F Message-ID: <4A38C1A4.6020504@tana.it> Date: Wed, 17 Jun 2009 12:12:52 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <4A37D490.3030900@billmail.scconsult.com> In-Reply-To: <4A37D490.3030900@billmail.scconsult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:13:35 -0000 Bill Cole wrote: >> I don't see why [DNS] techniques are not amenable to standardization. >> Actually, there is a couple of DNSBL drafts that are slowly moving >> forward. > > Which are good efforts, but they don't actually tell readers which > DNSBL's are highly effective and which are dangerous to their mail. Or > which might be both. For the overwhelming majority of mail systems, the > most effective, cost-effective, and safe tool to shun spam is the > Spamhaus Zen list, but it would be a very bad idea for any RFC to say > that. Similarly, there are very safe, cheap, and effective ways to stop > spam before DATA based on rDNS and HELO names that could never pass > muster for an RFC. I agree an RFC should not mention an existing organization, unless it has an official role (e.g. IANA.) Spamhaus or Google may be considered institutions, but have no official role. However, an RFC can describe a technique and generically refer to "existing organizations" that offer a well defined service. As for feedback and name spreading, it should be noted that DNSBLs suffer of all the logical traps implicit in negative characterizations. A site may learn their IP(s) are blacklisted and seek support on how to be removed. Compare that with whitelisting, where a site may learn their mail is not whitelisted because they are not vouched. Obviously, the kind of support, choice, and any involved payment, have very different flavors. >> It should be possible for my SMTP server to accept mail only from, say, >> an office opposite with whom I do most business, and shunning all the >> rest except, say, Gmail, thereby relying on their filtering. There's >> nothing wrong with that, except for technical problems that make it >> difficult to set it up properly. > > No RFC will (or should) ever recommend such an approach. Why not? It is not much different from setting Gmail as an MX, except that senders have to use a submission agent to relay that way. Au contraire, I don't think the RFCs should describe a protocol whose effectiveness depends on fuzzy filtering, unless they also describe the latter. > That is not because such an approach will never be the best one for any > system, but because it is not a widely deployable solution and it relies > upon a characteristic of the mail world that may well be transient. The world itself is transient. And, IMHO, giant ESPs are here to stay. > I think you are misunderstanding my point. The existing tools are good > enough that most mail system operators can put together some set of them > to assure that a large majority of their users see spam rarely and have > very little legitimate mail blocked, while the non-zero level of errors > in both directions have made users more acclimated to and forgiving of > such imperfections. I see. However, I don't want to be unable to explain to a user the nature of such imperfections. In addition, that is complicate and indeterministic enough to make setting up a new MTA server a daunting task. > This has raised the bar significantly for new > technical approaches, which will not even get attention unless they are > very good, very low-cost, and very easy to deploy. Fine. > [...] > Replace the tutorial on mail filtering fundamentals with a concise > problem definition and concise explanation of how VHLO provides a solution. Good point, thanks. Actually, I have expanded that first subsection in order to make it clear the point on content filtering. I'll look at how to reduce it. >> It obviously implies that email is going to die out. > > Not at all. I just don't expect that it will every be like 1993 again. That's how it should be. > I think we've reached something like a dynamic equilibrium over the past > few years, and it will take a really big push to change that. There are > many mail systems out there shunning 97%+ of all messages while > delivering less than a spam per week per user and stopping less than one > legitimate message per year per user. 5 years ago, that sort of accuracy > took an anti-spam craftsman tending a garden of homegrown tools (and > customizations of open tools) with users screaming bloody murder over > every error. Today you can buy it in a box or as a service, and the > users are largely resigned to the fact that sometimes mail goes missing > and sometimes they get solicited for dubious drugs and money-making > schemes. Perversely, users have also become shockingly dependent on > Internet email, and expect it to do things that they never would have > asked back before mail administrators evolved into a breed of artful > destroyers of most mail. There have also been some legal actions in the last 5 years, that possibly helped. Notwithstanding your figures, I don't want to install a fuzzy mail destroyer on my server, as I don't know how it operates. For example, how can it discern a photo that I forward via email from a cell phone from an image promoting cheap meds? My concept of reliability is different. Missing one legitimate message per user per year is much more transient than the ESP market, and would not explain why spam is perceived to be a problem at all. Is it me? I don't think that a system that forces operators to apply that sort of mechanisms can be considered good. If it is, I think an RFC should say that. Finally, I see no relation between features that users ask and spam filtering. Rather, realizing the unreliability of what they've become dependent on should push them toward alternative solutions. From iane@sussex.ac.uk Wed Jun 17 03:18:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADFB3A6E2A for ; Wed, 17 Jun 2009 03:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtYiyaHUP1E8 for ; Wed, 17 Jun 2009 03:18:23 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 82E1A3A6BA1 for ; Wed, 17 Jun 2009 03:18:23 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60657) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDOM0-000JCI-LD for asrg@irtf.org; Wed, 17 Jun 2009 11:18:00 +0100 Date: Wed, 17 Jun 2009 11:17:09 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <47BC2704E48807F1EA2995D1@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A38B4D0.2090305@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> Originator-Info: login-token=Mulberry:01Kl8ndJPAldlrzHvWloWd1JrnkNdIzo2Fn8o=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:18:25 -0000 --On 17 June 2009 11:18:08 +0200 Alessandro Vesely wrote: > der Mouse wrote: >> Mail does not need perfect - or even very good - reliability in order >> to be useful. When I first started using email, it could take a week >> to get mail from Montreal to California, with a chance that sometimes >> approached even that it would get lost on the way. This didn't deter >> lots of people, including me, from using it anyway. > > You were pioneers, and obviously expected that whatever steps were needed > to amend reliability would have been taken. Good question. "Mail does not need...very good...reliability" does strike me as quite complacent. Sure, email is still useful for lots of things, but the spam problem doesn't just hit reliability. It also hits costs, usability, trustworthyness, and speed of delivery. > In exchange for what are we giving up reliability now? Nothing much. We need to have a clear path to a world where you can trust that sender addresses aren't spoofed. Then we can begin to build reputation services around tokens that end users understand (email addresses), instead of tokens that they don't understand (IP addresses). The path is long, but it needs to be walked. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:45:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BDD3A6E2E for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWUrh1kytRr4 for ; Wed, 17 Jun 2009 03:45:30 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 2BF633A6BDD for ; Wed, 17 Jun 2009 03:45:30 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60924) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDP5T-000MF4-BR for asrg@irtf.org; Wed, 17 Jun 2009 11:29:53 +0100 Date: Wed, 17 Jun 2009 11:29:01 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> Originator-Info: login-token=Mulberry:010E6fDTmvDXIRu/NvPHRDwxKANsbAZzN0Rbk=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:45:31 -0000 --On 16 June 2009 17:24:03 -0700 Douglas Otis wrote: > > The CSV effort proved most providers do not want their MTAs identified as > belonging to them, even when it could improve email acceptance. This > might be especially true now after their support staff has been reduced. It'll probably depend on how much difference it makes to email acceptance. The harder it is to deliver email without some assurance that the sender isn't spoofed, the better. > Reverse DNS is already causing a large amount of resources to be wasted > by the shabby state of the reverse name space. Incorrectly configured > RFC 2317 delegation, and many non-functional servers are causing MTAs to > rapidly become resource limited when making reverse checks. In > addition, when your customers conduct business with Asia, they may not be > happy to find email is being lost as a result of geographic differences > of opinion about the role that reverse DNS might play with email. > > IMHO, all outbound MTAs should be required to return CVS records for > their EHLO name and offer MX records for their inbound. A mandate that > required MX (inbound) or CVS (outbound) records would greatly help in > identifying non-abusive email sources against a backdrop of hundreds of > millions of bot-net controlled drones spewing email. Systems may soon > use ACLs as a means to white-list safe MTAs. Perhaps the world is a few > years from having to go to that extreme. It's not a binary thing, though. > -Doug -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:45:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A443A6E2E for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoF2eeQlOQha for ; Wed, 17 Jun 2009 03:45:30 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A7E043A69CE for ; Wed, 17 Jun 2009 03:45:30 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:61239) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDPXA-0003QB-8M for asrg@irtf.org; Wed, 17 Jun 2009 11:46:22 +0100 Date: Wed, 17 Jun 2009 11:45:30 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090617085106.2213.qmail@simone.iecc.com> References: <20090617085106.2213.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01XwPKr8hkOBSgcB4RyynSeD0ixXvrCcIp1G4=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:45:32 -0000 --On 17 June 2009 08:51:06 +0000 John Levine wrote: >> If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be >> negotiated, then no one will follow. > > The IETF is amazingly resistant to making v6 SMTP different from v4 SMTP > in any way. > > In particular, I suggested that they not have a rule for fallback to > AAAA in the absence of MX. The rationale is straightforward: most > hosts with AAAA (and indeed A) records are not mail servers, people > need to add new DNS records anyway for v6 so the incremental effort to > install MX records is quite small, and it'll make mail more reliable > by making it easier to tell when a domain doesn't receive mail. They > all said too late, there are already a handful of v6 mail hosts. > Sigh. But, do they have MX records? If yes, there's not a problem. Do you receive any email from them? If no, there's not a problem. If a good chunk of the world implemented the rule that you've suggested (perhaps "*.ac.uk" or "*.gov" domains, or just gmail), then we'd be in a good place. It might not be too late for some leadership initiative to actually make a difference outside the IETF. > > R's, > John > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:45:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791DA3A6E2F for ; Wed, 17 Jun 2009 03:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9KLgTP3OImO for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 196783A6E2C for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:61163) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDPOA-0002DT-EP for asrg@irtf.org; Wed, 17 Jun 2009 11:40:58 +0100 Date: Wed, 17 Jun 2009 11:40:06 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: asrg@irtf.org Message-ID: <4F1048B2056979F365961B93@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A387B9A.2040800@billmail.scconsult.com> References: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> <4A387B9A.2040800@billmail.scconsult.com> Originator-Info: login-token=Mulberry:01MGpul5nL3Pxx18L5nJCj3+EKluKP8ZOQpdU=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:45:32 -0000 --On 17 June 2009 01:14:02 -0400 Bill Cole wrote: > Franck Martin wrote, On 6/16/09 11:33 PM: >> Knowing that mail servers are not deployed on IPv6, what would it take to >> make all these requirements mandatory for IPv6 and start with a better >> infrastructure than on IPv4? > > How do you make anything mandatory on the net? > > RFC 821 is one of a handful of Internet Standards, and it is violated > routinely by spammers and non-spammers for no better reason than that > they never bothered to read it. Well, parts of it are. The rest is mandatory for the purely practical reason that you can't deliver email without obeying those parts. For example, to send email to someone, it IS mandatory to give their email address in a RCPT command. How do you make other parts mandatory? Well, it's a long and arduous task, but the steps look like this: 1. make sure that the bulk of client MTA's behave correctly 2. start basing reputation scores on failure to respect the standard this can take several forms: refusal to whitelist non-compliant senders, incrementing spam scores, rejecting mail As the deliverability of non-compliant email drops, the proportion of senders complying will increase. A virtuous circle takes us to a world where everybody is compliant. Eventually, even the spammers comply. So, it's just an arms race in some cases, but in other cases we may have regained some real value. For example, if respecting SPF were universal (with fixes for forwarding), then backscatter would not be a problem. > That is possible because the major MTA's > are functional when misconfigured (e.g. with a bogus name for EHLO/HELO > use) and by default tolerate clients which violate standards. > > The only way anything can be functionally mandatory for email transport > is if major MTA's will not work unless configured to comply and by > default will not interoperate with clients that do not comply. RFC's are > great, but they do not enforce themselves. If the big freemail providers > and sites running Sendmail, Exchange, and Postfix generally accept mail > from non-compliant clients, there will be a lot of non-compliant clients. > To make good behavior mandatory, bad behavior has to break with enough > frequency that it's easier to comply than negotiate exemptions. > > >> ----- Original Message ----- From: "Bill >> Cole" To: "Anti-Spam Research Group - >> IRTF" Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT +01:00 >> Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg] >> What are the IPs that sends mail for a domain? >> >> Lyndon Nerenberg wrote, On 6/16/09 9:55 PM: >>> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >>>> IMHO, all outbound MTAs should be required to return CVS records for >>>> their EHLO name and offer MX records for their inbound. >>> Doug, are you sure that's what you meant to say? The sentence is a bit >>> ambiguous. Are you really saying any host that sends mail (is an SMTP >>> client) MUST also host an listed SMTP server? >> >> I can't testify to what he meant, but I think what he is actually saying >> is that if you have a machine that says "EHLO some.name" then there >> should be both a MX record for some.name and a SRV record for >> _client._smtp.some.name (i.e. a CSV/CSA record). >> >> That doesn't mean requiring inbound SMTP on every outbound, it means >> requiring an affirmation in DNS that a name can be used in EHLO by a >> particular IP address and a way to get mail to the responsible party for >> the machine(s) using that name in EHLO. This is an admirable goal. A >> weaker goal would be to get people running non-spamming mail servers to >> follow the existing accepted standard of using a valid resolvable FQDN in >> EHLO. >> >> >> _______________________________________________ Asrg mailing list >> Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg >> _______________________________________________ Asrg mailing list >> Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:45:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBAB3A6E2F for ; Wed, 17 Jun 2009 03:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5gDaNcRmR-F for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id B44E83A6BDD for ; Wed, 17 Jun 2009 03:45:31 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60781) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDOUV-000KJM-9T for asrg@irtf.org; Wed, 17 Jun 2009 11:23:19 +0100 Date: Wed, 17 Jun 2009 11:22:27 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <56EA24C8EBF22F3C536EBC56@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A37DC8D.7070309@computer.org> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> <4A37DC8D.7070309@computer.org> Originator-Info: login-token=Mulberry:01speZAhv4B2fzBO1kHr0lDAx1GA+6XBW9JwI=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:45:32 -0000 --On 16 June 2009 10:55:25 -0700 David Wall wrote: >> Yes, but everybody else has the right to consider me a fool for that. >> What unacceptably affects reliability is that I could claim I never >> received them since they ended up in the spam folder. > > I am sure the law varies around the world, but in the U.S., aside from a > few specific areas like turning off utilities, evictions and court > orders, the sender is presumed to have complied with their requirements > to notify you if other agreements allow for electronic communications and > they made a good faith effort to send to your last known email address. In the UK, there's case law saying that a notification of legal arbitration proceedings (in accordance with a contract) was deemed served because the recipient's email server accepted the email. So here, your on much safer ground if you reject an email than if you accept it but don't read it. > Most such agreements put it on you to ensure your current email is on > file and that you obviously agree to accept such email from them. > > The fact that you missed it, didn't read it, your spouse or child deleted > it or it was spam filtered will be irrelevant. The same goes for old > fashioned postal mail -- it doesn't affect their legal standing for > sending you the notice even if you claim the mailman lost it, your > mailbox was hit by thieves, your spouse/kids tossed it, etc. > > When absolute reliability is required, most will use services > (email/web-based or postal or even hand-delivered) that require a > signature, ID check or other the like. Web tools often have > "return-receipts" that work when you read it after logging in for > example, and the old "you've been served" works well for various legal > issues. > > David > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:49:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBF628C228 for ; Wed, 17 Jun 2009 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86px1qrmHcQ5 for ; Wed, 17 Jun 2009 03:49:05 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 47DE33A69CE for ; Wed, 17 Jun 2009 03:48:48 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:61330) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDQ2T-00053C-9H; Wed, 17 Jun 2009 11:49:41 +0100 Date: Wed, 17 Jun 2009 11:48:49 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF , Franck Martin Message-ID: <40FCC017A8BB493554FAC60B@lewes.staff.uscs.susx.ac.uk> In-Reply-To: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Originator-Info: login-token=Mulberry:010NWbuDk2CR0RQu8aPPtDSg4rNk28EjP7RUA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:49:06 -0000 --On 16 June 2009 19:17:41 -0400 Daniel Feenberg wrote: > > I predict that no significant amount of mail ever originates from IPV6. > Because it would be impossible to maintain a DNSBL for IPV6, I expect > that enough sites will decline all IPV6 mail that it won't pay to send > from it. > Consider that because a spammer could (spoof) a different IPV6 address > for every message, even a different 48 bit block for every messages, MTAs > will be left with only content analysis for spam blocking. Which is why reputation services need to be based on sender domains, not IP addresses. Users can then whitelist as required, and use of IP addresses/domains without good positive reputation won't work very well. The advantage of IPV6, of course, is that you'll never have to share an IP address with someone with poor reputation. > I don't expect > IPV4s will ever be so scarce that enough MTAs will start using them out > of necessity - ISPs will give each customer 4 IPV4 addresses with their > million address IPV6 range, and customers will use those 4 addresses for > the things that really need IPV4 - such as internet facing MTAs. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Wed Jun 17 03:56:38 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6E128C213 for ; Wed, 17 Jun 2009 03:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9xtIexNYIOA for ; Wed, 17 Jun 2009 03:56:37 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id C48E828C212 for ; Wed, 17 Jun 2009 03:56:37 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:61512) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLDQEU-000AV3-4Z for asrg@irtf.org; Wed, 17 Jun 2009 11:56:54 +0100 Date: Wed, 17 Jun 2009 11:56:48 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: asrg@irtf.org Message-ID: Originator-Info: login-token=Mulberry:01/h4Uj2d/gvQ/i2jxakRxk4cCZJY16WFEc4k=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:56:39 -0000 --On 16 June 2009 14:55:08 -0400 Bill Cole wrote: > > Figuring out a way to get the tools for online accountability into > essentially universal use without a pre-existing adjunct authoritarian > polity and without creating the tools for rapid creation of a new > authoritarian polity would be a very interesting and challenging research > goal. I think it is outside of IRTF scope. Surely it's the only way forward, even if it's a long road. Accountability doesn't have to go all the way back to the sender - it can rest with domain and host admins. At the moment, IP reputation services are quite mature, but they're not really usable - you can't ask email recipients to list IP addresses that they trust. Domain reputation services aren't usable because, in the absence of widespread adoption of technologies that -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Wed Jun 17 04:04:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EE73A6E2C for ; Wed, 17 Jun 2009 04:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRbppIxvJNuM for ; Wed, 17 Jun 2009 04:04:29 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 61B4628C1B1 for ; Wed, 17 Jun 2009 04:04:29 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 13:04:16 +0200 id 00000000005DC031.000000004A38CDB0.000057A4 Message-ID: <4A38CDAF.5050503@tana.it> Date: Wed, 17 Jun 2009 13:04:15 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> <200906161740.NAA27908@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906161740.NAA27908@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 11:04:30 -0000 der Mouse wrote: >> Vernon's list is not really helpful, except for trying and discourage >> potential submitters. > > You're reading it too literally. The "sound advice" is not present > overtly; it could perhaps be phrased "make sure you're not falling into > any of these traps if you want to be taken seriously rather than > eliciting just pointing and laughing". Although some of those traps aim at sounding out technical skills of spam-killer wannabes, many of them indulge in psychological, social, or economical aspects of their personality. Does that mean anti-spam is a sort of psychological task? A technical specification shouldn't be immersed in that sort of endeavors: it should just provide just means. Given a fair basis, it is unconceivable that a few individuals can subvert the world's order. (Well, once we've learned how to do that, we should apply it to politics as well :-) From dotzero@gmail.com Wed Jun 17 05:25:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02A23A6DDB for ; Wed, 17 Jun 2009 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdODryBPZrD6 for ; Wed, 17 Jun 2009 05:25:18 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 803883A69B2 for ; Wed, 17 Jun 2009 05:25:18 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so122854qwe.7 for ; Wed, 17 Jun 2009 05:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZSDA17pmKwtuvx/FyFCXIEYbeMD5rpIZ3JgI7FQW52A=; b=j9MTZsIAagMyRBpww/Dd+mdpwjqIPfAHJPTVlkSuHMz6ZpKdQClJCHu+UVcrJIlmcz WjMG6tgeVjRC4vaGb91MHM7psVe4m/2BYfdMV/yf7Gnb3TYb4fKKWTIPTx6N3KsQ+e7O yI2XSJwjJu/KIU/+VXMSQpIYRZtv7Q37IpVvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JFaADtX4pcNT9YDx6ztstYxTl/IDaedfYK5NeePkcShBFMobvgGd/J7mqCT7Ak4T/3 1BwJQQ5pI+zXGBIku9fAulX/y6UCB1jz+JVbhpBauCEF8eHUqS+rvywzP5xkPPGMF7qz UO6VUYeTC+wxln6/ejXvEp1GeMknB6tMz5UHI= MIME-Version: 1.0 Received: by 10.220.46.20 with SMTP id h20mr35894vcf.55.1245241529004; Wed, 17 Jun 2009 05:25:29 -0700 (PDT) In-Reply-To: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> References: <4515812.1851245190668283.JavaMail.franck@iphone-4.genius.local> <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Date: Wed, 17 Jun 2009 08:25:28 -0400 Message-ID: <7ae58c220906170525s32c0e9f8p7c42f97e34cc0524@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:25:20 -0000 On Tue, Jun 16, 2009 at 6:20 PM, Franck Martin wrote: > I recently encountered the following question/problems. > > I have a mail server and one of my users complains he is not receiving > emails from a domain. How do I find if I have blocked the domain from > sending to my server. Meaning, knowing the domain name of the sender, how do > I find the IPs from where the mail could be sent from. It seems that SPF is > the only tool to provide that answer? > One approach that might help you is to go to senderscore.org (from ReturnPath). Register for a free account and then enter in the domain name. For example, when I enter in avonsys.com it shows me that there is one IP address sending mail for that domain - 76.203.192.33 with a hostname of adsl-76-203-192-33.dsl.rcsntx.sbcglobal.net. Hope this helps. > In another related problem, which is linked to IPv6 and RBL. Buidling an > IPv6 RBL could lead to a huge database. Sure you can alleviate by using > "wildcards", but why not use the reverse DNS resolution to add a TXT record > associated to the IP to indicate the IP is the one of a mail server? So any > IP that does not have this record would be blocked for SMTP. As IPv6 is not > used for SMTP (or barely), this could be made mandatory for IPv6 and > optional for IPv4. An MUA could talk to an MTA on port 25 because we know > the the etwork range of the MUA or the alternative is to use the new mail > submit port. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > > From vesely@tana.it Wed Jun 17 05:53:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1A73A6E50 for ; Wed, 17 Jun 2009 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWEZXqMMAIUY for ; Wed, 17 Jun 2009 05:53:17 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id AC8953A6C44 for ; Wed, 17 Jun 2009 05:53:17 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 14:53:20 +0200 id 00000000005DC031.000000004A38E740.00006550 Message-ID: <4A38E740.6040801@tana.it> Date: Wed, 17 Jun 2009 14:53:20 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> <4A37DC8D.7070309@computer.org> In-Reply-To: <4A37DC8D.7070309@computer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:53:18 -0000 David Wall wrote: >> What unacceptably affects reliability is that I could claim I never >> received them since they ended up in the spam folder. > > I am sure the law varies around the world, but in the U.S., aside from a > few specific areas like turning off utilities, evictions and court > orders, the sender is presumed to have complied with their requirements > to notify you if other agreements allow for electronic communications > and they made a good faith effort to send to your last known email > address. Most such agreements put it on you to ensure your current > email is on file and that you obviously agree to accept such email from > them. Good faith is enough when it works most of the times. However, that may change if users routinely classify direct marketing as spam, because of the possibly similar phraseology. > When absolute reliability is required, most will use services > (email/web-based or postal or even hand-delivered) that require a > signature, ID check or other the like. Web tools often have > "return-receipts" that work when you read it after logging in for > example, and the old "you've been served" works well for various legal > issues. Yeah, the Italian government made provisions for sending that by email as well. That originated because the Italian laws extensively prescribe to use registered mail, possibly with return receipt, especially in the Public Administration, where it became a visible cost after the privatization of postal services. An English description of the mechanism they conceived is available on the IETF as draft-gennai-smime-cnipa-pec. It has legal standing in Italy. Of course, it cannot cope with user agents unexpectedly moving messages to the Junk folder... From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 06:24:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671B03A693F for ; Wed, 17 Jun 2009 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.592 X-Spam-Level: X-Spam-Status: No, score=-9.592 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVLJnVv5dfQk for ; Wed, 17 Jun 2009 06:24:04 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 24B8328C270 for ; Wed, 17 Jun 2009 06:23:49 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA17626; Wed, 17 Jun 2009 09:23:50 -0400 (EDT) From: der Mouse Message-Id: <200906171323.JAA17626@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 09:22:41 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A38CDAF.5050503@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> <200906161740.NAA27908@Sparkle.Rodents-Montreal.ORG> <4A38CDAF.5050503@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:24:05 -0000 > Although some of those traps aim at sounding out technical skills of > spam-killer wannabes, many of them indulge in psychological, social, > or economical aspects of their personality. Does that mean anti-spam > is a sort of psychological task? The technical aspect of it isn't. But presenting it to the world in a way that leads to it being taken seriously is, at least in part. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From sethb@panix.com Wed Jun 17 06:24:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9793A6C8B for ; Wed, 17 Jun 2009 06:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvZ-dblbxLW2 for ; Wed, 17 Jun 2009 06:24:26 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 574393A693F for ; Wed, 17 Jun 2009 06:24:26 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id A612839055 for ; Wed, 17 Jun 2009 09:24:18 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id 92DBF24232; Wed, 17 Jun 2009 09:24:18 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: (message from Daniel Feenberg on Tue, 16 Jun 2009 19:17:41 -0400 (EDT)) References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> Message-Id: <20090617132418.92DBF24232@panix5.panix.com> Date: Wed, 17 Jun 2009 09:24:18 -0400 (EDT) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:24:27 -0000 Daniel Feenberg wrote: > I predict that no significant amount of mail ever originates from > IPV6. Because it would be impossible to maintain a DNSBL for IPV6, But a DNSWL would be just as easy as IPV4. So all it would take is half a dozen of the largest senders and receivers (google, microsoft, outblaze, aol, etc.) to use IPV6 among themselves and your statement would already be wrong. Then, if they set up a method to allow others to tentatively whitelist IPV6 addresses, they could switch to more draconian blocking/checking of IPV4 space over time. Seth From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 06:30:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FF528C254 for ; Wed, 17 Jun 2009 06:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.632 X-Spam-Level: X-Spam-Status: No, score=-9.632 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uG-AAC-AAsi for ; Wed, 17 Jun 2009 06:30:15 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id EBBAF3A6C42 for ; Wed, 17 Jun 2009 06:30:14 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA17682; Wed, 17 Jun 2009 09:30:20 -0400 (EDT) From: der Mouse Message-Id: <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 09:24:07 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A38B4D0.2090305@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:30:17 -0000 >> When I first started using email, it could take a week to get mail >> from Montreal to California, with a chance that sometimes approached >> even that it would get lost on the way. This didn't deter lots of >> people, including me, from using it anyway. > You were pioneers, and obviously expected that whatever steps were > needed to amend reliability would have been taken. Not really; we - well, I at least - did not have any expectation that "they" would necessarily "fix" reliability. I as a node admin did what I could to prevent our system from being part of the precipitate, and did have an expectation that others would do likewise - but I also knew enough about ways we could silently lose mail that I accepted unreliability as just a fact of email life. (And I still do - it's just that the level of unreliability is lower.) > In exchange for what are we giving up reliability now? Usability. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Wed Jun 17 06:32:58 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACC43A6B07 for ; Wed, 17 Jun 2009 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXrcZjSz+GDw for ; Wed, 17 Jun 2009 06:32:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id AF4463A693F for ; Wed, 17 Jun 2009 06:32:57 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 15:33:08 +0200 id 00000000005DC031.000000004A38F094.00006B8F Message-ID: <4A38F094.1000005@tana.it> Date: Wed, 17 Jun 2009 15:33:08 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> <4A38629F.5040506@billmail.scconsult.com> In-Reply-To: <4A38629F.5040506@billmail.scconsult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:32:58 -0000 Bill Cole wrote: > Lyndon Nerenberg wrote, On 6/16/09 9:55 PM: >> On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >>> IMHO, all outbound MTAs should be required to return CVS records for >>> their EHLO name and offer MX records for their inbound. >> >> Doug, are you sure that's what you meant to say? The sentence is a bit >> ambiguous. Are you really saying any host that sends mail (is an SMTP >> client) MUST also host an listed SMTP server? > > I can't testify to what he meant, but I think what he is actually saying > is that if you have a machine that says "EHLO some.name" then there > should be both a MX record for some.name and a SRV record for > _client._smtp.some.name (i.e. a CSV/CSA record). However, the standard requires that it says "EHLO host-at.some.name". It is a seemingly simple task to drop the leftmost label(s) so as to obtain the mail domain, but doing that properly requires a zone cut algorithm that most servers miss. > That doesn't mean requiring inbound SMTP on every outbound, it means > requiring an affirmation in DNS that a name can be used in EHLO by a > particular IP address and a way to get mail to the responsible party for > the machine(s) using that name in EHLO. This is an admirable goal. A > weaker goal would be to get people running non-spamming mail servers to > follow the existing accepted standard of using a valid resolvable FQDN > in EHLO. If we have a weaker goal and an admirable one, we're better off if they don't conflict with each other. We cannot ask for a domain name after EHLO, except for tiny ESPs whose domain name, host name, and IP address are the same thing. If we need the domain name, we can either mandate the zone cut algorithm, or use a different verb than EHLO. From vesely@tana.it Wed Jun 17 06:54:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6426C3A6C93 for ; Wed, 17 Jun 2009 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBJ9BomvtQrh for ; Wed, 17 Jun 2009 06:54:22 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D89163A69CD for ; Wed, 17 Jun 2009 06:54:21 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 15:52:56 +0200 id 00000000005DC031.000000004A38F538.00006E6B Message-ID: <4A38F537.6030809@tana.it> Date: Wed, 17 Jun 2009 15:52:55 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <47BC2704E48807F1EA2995D1@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <47BC2704E48807F1EA2995D1@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:54:27 -0000 Ian Eiloart wrote: > "Mail does not need...very good...reliability" does > strike me as quite complacent. Sure, email is still useful for lots of > things, but the spam problem doesn't just hit reliability. It also hits > costs, usability, trustworthyness, and speed of delivery. 100% agreed. >> In exchange for what are we giving up reliability now? > > Nothing much. We need to have a clear path to a world where you can > trust that sender addresses aren't spoofed. Then we can begin to build > reputation services around tokens that end users understand (email > addresses), instead of tokens that they don't understand (IP addresses). IMHO, that trust can only originate from the mail domain. Cryptographic techniques (dkim, smime, pgp) may be used to ensure tokens have not been tampered with, but we need to know what domain is sending the mail. Unfortunately, whois records are inadequate; that's why we'll need reputation services. From prussell@nd.edu Wed Jun 17 06:59:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78C93A6E62 for ; Wed, 17 Jun 2009 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU1vOtvg42mD for ; Wed, 17 Jun 2009 06:59:36 -0700 (PDT) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id D94D63A6989 for ; Wed, 17 Jun 2009 06:59:35 -0700 (PDT) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5HDth5X022887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jun 2009 09:55:44 -0400 Received: from [172.19.226.102] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5HDx3Y8014149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jun 2009 09:59:14 -0400 (EDT) Message-ID: <4A38F6A7.6090700@nd.edu> Date: Wed, 17 Jun 2009 09:59:03 -0400 From: Paul Russell User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Wed, 17 Jun 2009 09:55:54 EDT Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:59:36 -0000 On 6/17/2009 01:27, Franck Martin wrote: > Sure, it is the the be strict in what you send, lenient in what you receive. The first part of that has always been a good idea. The second part may have been workable ten years ago, but on today's Internet, exercising leniency in what you accept will get you flooded with all sorts of traffic that you neither want nor need. Ten years ago, we accepted inbound mail from systems with missing or mismatched DNS information and from systems which used a non-resolvable hostname as their HELO/EHLO name. Today, we reject all mail from these systems. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame From macfisherman@gmail.com Wed Jun 17 07:28:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E91428C289 for ; Wed, 17 Jun 2009 07:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ReACEHXavKR for ; Wed, 17 Jun 2009 07:28:02 -0700 (PDT) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 9EE243A68DF for ; Wed, 17 Jun 2009 07:27:56 -0700 (PDT) Received: by ewy7 with SMTP id 7so456372ewy.7 for ; Wed, 17 Jun 2009 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=y/duVMMeUX/zhi6VHw2CpOidRWwkjyYyAvtdSp/Ysok=; b=sZrtb0rHA+/nNiWn3j54tLd3M2kMZzDW5YJtL/4QpcBmYZz2iCzi8/8yA6CcVA3yoF 4Hm3+4TJ+eicB/BeddnCZ9efQXkVvOtK5t8HzAvBdhVth0u2oKJuVmLiRf5hlQkpV1fY i201g9SowFC1Kt4PgT0FVivjZ/fUIvIY1Beew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xJYM9RppWDEHN6+ov2zeDeJqOXa0D8uqLrIfoi0AWGDcfIxQmgyeDHHUGQPpQ4MTM/ ceVjgJLfZFgsMk8GkEACzOa3WhyfbIaVEVrMBPiHpGk2QXDR0SA1+WkvpK2tAP4tp8WH h/lrvkUD7NGvr2k43fvPx21vMF1Os/g+ToNB8= MIME-Version: 1.0 Received: by 10.210.129.19 with SMTP id b19mr2974158ebd.30.1245248887022; Wed, 17 Jun 2009 07:28:07 -0700 (PDT) In-Reply-To: References: <20090617085106.2213.qmail@simone.iecc.com> Date: Wed, 17 Jun 2009 10:28:06 -0400 Message-ID: <45ae90370906170728g10ef9f87ud5e53ae213ee3e4@mail.gmail.com> From: Jeff Macdonald To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:28:11 -0000 On Wed, Jun 17, 2009 at 6:45 AM, Ian Eiloart wrote: > It might not be too late for some leadership initiative to > actually make a difference outside the IETF. +1 -- Jeff Macdonald Ayer, MA From vesely@tana.it Wed Jun 17 07:42:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A2A28C292 for ; Wed, 17 Jun 2009 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urRkej9WY36g for ; Wed, 17 Jun 2009 07:42:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 058DB28C289 for ; Wed, 17 Jun 2009 07:42:49 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 16:41:24 +0200 id 00000000005DC030.000000004A390094.00007577 Message-ID: <4A390094.3080800@tana.it> Date: Wed, 17 Jun 2009 16:41:24 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:42:50 -0000 der Mouse wrote: > I as a node admin did what I could to prevent our system from being > part of the precipitate, and did have an expectation that others would > do likewise - but I also knew enough about ways we could silently lose > mail that I accepted unreliability as just a fact of email life. If you're talking about hardware faults, unreliability is just a fact of life, tout court. At least, SMTP specifications allowed to tell whose fault it was. It is different when we talk about specifications that are unreliable by design. SMTP specifications are the same, in a relative way, but the people who use them are not. >> In exchange for what are we giving up reliability now? > > Usability. Why would email be less usable if it implied some sort of responsibility on the sender's side? From steve@blighty.com Wed Jun 17 08:10:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FE93A6E35 for ; Wed, 17 Jun 2009 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d09vmxMvluIp for ; Wed, 17 Jun 2009 08:10:44 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 156853A6BC5 for ; Wed, 17 Jun 2009 08:10:44 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id D95B28061F for ; Wed, 17 Jun 2009 07:59:43 -0700 (PDT) Message-Id: <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 07:59:54 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:10:45 -0000 On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote: > Because it would be impossible to maintain a DNSBL for IPV6, I keep hearing people say this, but I've not seen any clear justification for it. It seems to me to be no more difficult to run a blacklist for IPv6 addresses than IPv4 addresses (neither is easy, but the details of the address representation don't seem to make more than minor differences). Can you expand on why you think it's the case, or point me at some discussion of it? Cheers, Steve From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 08:17:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1709E3A6DF8 for ; Wed, 17 Jun 2009 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.664 X-Spam-Level: X-Spam-Status: No, score=-9.664 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwxlncUvfkiI for ; Wed, 17 Jun 2009 08:17:43 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id E486F3A685E for ; Wed, 17 Jun 2009 08:17:42 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA18188; Wed, 17 Jun 2009 11:17:49 -0400 (EDT) From: der Mouse Message-Id: <200906171517.LAA18188@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 11:03:47 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A38F094.1000005@tana.it> References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> <4A38629F.5040506@billmail.scconsult.com> <4A38F094.1000005@tana.it> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:17:44 -0000 >> [...] I think what he is actually saying is that if you have a >> machine that says "EHLO some.name" then there should be both a MX >> record for some.name and a SRV record for _client._smtp.some.name >> (i.e. a CSV/CSA record). > However, the standard requires that it says "EHLO host-at.some.name". Not quite. It requires that the HELO/EHLO argument be a valid name for the SMTP client host. The presence or absence of any DNS zone cuts in the vicinity is completely irrelevant. > It is a seemingly simple task to drop the leftmost label(s) so as to > obtain the mail domain, but doing that properly requires a zone cut > algorithm that most servers miss. ...and which is wrong anyway. The division of DNS names into "hosts" and "domains" is purely a human one. Dropping the first label from a DNS name in an attempt to get "the domain" for it is, at best, a rough heuristic. Looking up the DNS tree for zone cuts also is nothing more than a heuristic. It's not even clear to me that there *is* a "_the_ domain". What's "the domain" for (to invent an example) mail.research.tjw.ibm.com? There plausibly could be as many zone cuts as there are dots, there, and I could argue for picking any of them as "the domain" for email responsibility purposes (well, possibly excepting the TLD, but even that is just a heuristic, likely to break soon). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From feenberg@nber.org Wed Jun 17 08:24:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FD728C105 for ; Wed, 17 Jun 2009 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkNBIeu2W4UJ for ; Wed, 17 Jun 2009 08:24:08 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id DB40E28C289 for ; Wed, 17 Jun 2009 08:23:54 -0700 (PDT) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.1/8.13.8) with ESMTP id n5HFO0aM006486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 17 Jun 2009 11:24:00 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.7+Sun/8.12.10) with ESMTP id n5HFHPrO029473; Wed, 17 Jun 2009 11:17:26 -0400 (EDT) Received: from localhost (feenberg@localhost) by nber6.nber.org (8.13.7+Sun/8.13.7/Submit) with ESMTP id n5HFHOP3029461; Wed, 17 Jun 2009 11:17:25 -0400 (EDT) X-Authentication-Warning: nber6.nber.org: feenberg owned process doing -bs Date: Wed, 17 Jun 2009 11:17:24 -0400 (EDT) From: Daniel Feenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> Message-ID: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20090617 #2130901, check: 20090617 clean Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:24:09 -0000 On Wed, 17 Jun 2009, Steve Atkins wrote: > > On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote: >> Because it would be impossible to maintain a DNSBL for IPV6, > > I keep hearing people say this, but I've not seen any clear justification for > it. It seems to me to be no more difficult to run a blacklist for IPv6 > addresses than IPv4 addresses (neither is easy, but the details of the > address representation don't seem to make more than minor differences). > > Can you expand on why you think it's the case, or point me at some discussion > of it? Of course a spammer could reuse an IPV6 address, and then a DNSBL could catch subsequent spam from that address. But there isn't any need to reuse IPV6 addresses - they are nearly infinite in number, each customer is assigned billions by default and there is no real need for the spammer to restrict himself to his officially listed addresses. IPV4 DNSBL work, even though they are "listing badness" because IPV4 address space is finite. That means that "listing badness" isn't really different from "listing goodness". But if badness is infinite, then listing bad addresses won't be effective. Note that my argument that MTAs with only IPV6 won't be established is not contradicted by the existence of MTAs with IPV6 and IPV4 connectivity. Nor does it really depend on the difficulties with DNSBLs, although that is an additional obstacle. The major obstacle is the limited connectivity that an IPV6 only MTA would have. Daniel Feenberg > > Cheers, > Steve > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 08:24:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16DF28C296 for ; Wed, 17 Jun 2009 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.691 X-Spam-Level: X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPDbo1LLuLDj for ; Wed, 17 Jun 2009 08:24:39 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 939F328C284 for ; Wed, 17 Jun 2009 08:24:39 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA18251; Wed, 17 Jun 2009 11:24:50 -0400 (EDT) From: der Mouse Message-Id: <200906171524.LAA18251@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 11:19:30 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:24:40 -0000 >> Because it would be impossible to maintain a DNSBL for IPV6, > Can you expand on why you think it's the case, or point me at some > discussion of it? I haven't claimed that, but I think the idea is that the size of the v6 address space, and the amount of address space that even a tiny customer gets, make it useless to try to identify and block bad-actor addresses, because they'll just dodge to unblocked addresses. There is some truth to this, but it's not that simple. DNSBLs like the CBL, where the assignee of the IP address is not actively malicious and thus won't be ducking out from under the listing, will be unaffected. There are doubtless some DNSBLs which will be unable to do anything useful in v6, but there are others that will simply start listing /64s or /48s or some such. It will change things, definitely. But to say it will be impossible to maintain a DNSBL is an overstatement. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From steve@blighty.com Wed Jun 17 08:35:07 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B15B3A6932 for ; Wed, 17 Jun 2009 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spETU2qyuqDg for ; Wed, 17 Jun 2009 08:35:06 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 67FC13A685E for ; Wed, 17 Jun 2009 08:35:06 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id B38F04F83C9 for ; Wed, 17 Jun 2009 08:35:04 -0700 (PDT) Message-Id: <2CCD8D69-9E16-4FCA-B71A-6D9037BAF712@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:35:17 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:35:07 -0000 On Jun 17, 2009, at 8:17 AM, Daniel Feenberg wrote: > > > On Wed, 17 Jun 2009, Steve Atkins wrote: > >> >> On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote: >>> Because it would be impossible to maintain a DNSBL for IPV6, >> >> I keep hearing people say this, but I've not seen any clear >> justification for it. It seems to me to be no more difficult to run >> a blacklist for IPv6 addresses than IPv4 addresses (neither is >> easy, but the details of the address representation don't seem to >> make more than minor differences). >> >> Can you expand on why you think it's the case, or point me at some >> discussion of it? > > Of course a spammer could reuse an IPV6 address, and then a DNSBL > could catch subsequent spam from that address. But there isn't any > need to reuse IPV6 addresses - they are nearly infinite in number, > each customer is assigned billions by default and there is no real > need for the spammer to restrict himself to his officially listed > addresses. Which is why you'd list the /64 or /48 in most cases. That's not difficult to do, even with bind, and is easy to manage with any decent database backend. > > IPV4 DNSBL work, even though they are "listing badness" because IPV4 > address space is finite. That means that "listing badness" isn't > really different from "listing goodness". But if badness is > infinite, then listing bad addresses won't be effective. I don't think that reasoning really holds water, there. IPv6 space is also finite. There'd need to be minor operational changes to support it, and there are a couple of naive approaches currently used in IPv4 that would fail dismally in IPv6 without some changes, but nothing particularly difficult. If anything, reduction in use of NATs might make some sorts of blacklist more accurate and effective in IPv6 space than in IPv4. > Note that my argument that MTAs with only IPV6 won't be established > is not contradicted by the existence of MTAs with IPV6 and IPV4 > connectivity. Nor does it really depend on the difficulties with > DNSBLs, although that is an additional obstacle. The major obstacle > is the limited connectivity that an IPV6 only MTA would have. Cheers, Steve From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 08:37:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD10B3A6C3C for ; Wed, 17 Jun 2009 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.714 X-Spam-Level: X-Spam-Status: No, score=-9.714 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msu+9hOTbCHk for ; Wed, 17 Jun 2009 08:37:23 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id A50663A6A7A for ; Wed, 17 Jun 2009 08:37:22 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA18321; Wed, 17 Jun 2009 11:37:33 -0400 (EDT) From: der Mouse Message-Id: <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 11:25:19 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A390094.3080800@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> <4A390094.3080800@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:37:23 -0000 >> [In bygone days, when mail took a week to cross the continent,] I as >> a node admin did what I could to prevent our system from being part >> of the precipitate, and did have an expectation that others would do >> likewise - but I also knew enough about ways we could silently lose >> mail that I accepted unreliability as just a fact of email life. > If you're talking about hardware faults, unreliability is just a fact > of life, tout court. At least, SMTP specifications allowed to tell > whose fault it was. The SMTP specifications were irrelevant. This was the UUCP age. >>> In exchange for what are we giving up reliability now? >> Usability. > Why would email be less usable if it implied some sort of > responsibility on the sender's side? I'm not sure what you mean here. When you ask "[i]n exchange for what are we giving up reliability now?", I read this as "in the transition currently underway, involving a decrease in reliability, what benefit are we getting in exchange?". I don't see any way that sender responsibility is relevant to that question; my answer is simply "preservation of usability", or, perhaps more accurately, "taking a small usability loss rather than a disastrous one". The transition in which we gave up sender responsibility is long past, was quite protracted (roughly, I'd say, Sep 1993 through Oct 1998), and was largely unrecognized at the time (and thus the question of benefits gained in return did not arise). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From dotzero@gmail.com Wed Jun 17 08:40:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67133A6E72 for ; Wed, 17 Jun 2009 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJtVIPTNGeut for ; Wed, 17 Jun 2009 08:40:08 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id F3B363A6D65 for ; Wed, 17 Jun 2009 08:40:07 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so196060qwe.7 for ; Wed, 17 Jun 2009 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XypONQ9leTGnxnnIfeeLmcrWyFTm3jnAzaTcJbU/sHI=; b=QKUIYeSu0IMJpeM8fPsQe43cLM9MI6/b6toxE3fzfHmTr1ZNVBT+uU1owB3MlfUz/s OLCvHAFW51lAzyzMlymv+G7/SPyG+TWK3dR/7udS9cEYooSii7M0/rZeofquYYMThzvn a1gitys2wurtBtS2vronrC0EO46i7nftUMan8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=u1C1brpdo/RitMgGMMVxG6uPgRMjFa4M+SZPm5iQBTUSK+8AC/Sea8KITxAH0EnFFO fEf9G72FpJxVCLrY7FhdcVGwqrvDpYWzFnSRzThDmBN6OGVsUj9Y/dTauYjtzY4pRrwS pToc96jdR6cXdvxsFXJL+dKBttNrtqhPXLrSU= MIME-Version: 1.0 Received: by 10.220.77.84 with SMTP id f20mr362154vck.109.1245253218141; Wed, 17 Jun 2009 08:40:18 -0700 (PDT) In-Reply-To: <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> <4A390094.3080800@tana.it> <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> Date: Wed, 17 Jun 2009 11:40:18 -0400 Message-ID: <7ae58c220906170840l2a19b162r294c892e63a3ee81@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:40:08 -0000 On Wed, Jun 17, 2009 at 11:25 AM, der Mouse wro= te: >>> [In bygone days, when mail took a week to cross the continent,] I as >>> a node admin did what I could to prevent our system from being part >>> of the precipitate, and did have an expectation that others would do >>> likewise - but I also knew enough about ways we could silently lose >>> mail that I accepted unreliability as just a fact of email life. >> If you're talking about hardware faults, unreliability is just a fact >> of life, tout court. =A0At least, SMTP specifications allowed to tell >> whose fault it was. > > The SMTP specifications were irrelevant. =A0This was the UUCP age. > And the crowd starts chanting "Bring back bang paths!" From lyndon@orthanc.ca Wed Jun 17 09:21:41 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB2F3A6E89 for ; Wed, 17 Jun 2009 09:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkZaz2XV+RPw for ; Wed, 17 Jun 2009 09:21:41 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id E88293A6E47 for ; Wed, 17 Jun 2009 09:21:40 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n5HGLNAc036170 for ; Wed, 17 Jun 2009 10:21:27 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1245255688; bh=rEys40ttkAtM5JtEUoYM9W+tOVqSSm5pV5TC+cLG8rY=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=aTxjaGLUhS6zYKVH+Nza7lkLAGcY/exHe/M9+ZxwS6oOD/QB4XxhBF61zMjWxh6xC mLyC2WytihA6+Ln6O2dHF524eHlMKy+nd5UndRrbut42oMLDDzEACF0bdPRCeQrWc5 GwOzijNlpTw0dH/07kECVS/oh3+pV4Nx0GyR3pQf9JxU9Vx4N21OrU2QuGKBBJ6Wmz 6wfyU8E94dTZKnPCiFC7XFln2iXcCa95vK+qeONqkvMdg0pftg2QVx8twAstoKysAK W+37VYczHylTg0k0t3/hP71BfQF4Tbc4o3Ey6yNQmJs4SfDKop6oxtlpW6xPLN2xDo esW+ztoLqBVdQ== From: Lyndon Nerenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <4A38F6A7.6090700@nd.edu> References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> <4A38F6A7.6090700@nd.edu> Content-Type: text/plain Date: Wed, 17 Jun 2009 10:21:17 -0600 Message-Id: <1245255678.1310.4.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:21:42 -0000 On Wed, 2009-06-17 at 09:59 -0400, Paul Russell wrote: > > Sure, it is the the be strict in what you send, lenient in what you > receive. > > The first part of that has always been a good idea. The second part > may have > been workable ten years ago, but on today's Internet, exercising > leniency in > what you accept will get you flooded with all sorts of traffic that > you neither > want nor need. "... be lenient in what you receive" *never* meant you should accept and attempt to second-guess the intent of anything in violation of the applicable protocol spec. It meant "don't tip over and die when presented with crap." I.e., fail gracefully. This was very important on things like the IMPs when the protocols and their implementations were immature. It's still important today, but only when interpreted with its original meaning and intent. --lyndon From vesely@tana.it Wed Jun 17 09:50:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16E13A6B80 for ; Wed, 17 Jun 2009 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq5j9fkWg2wE for ; Wed, 17 Jun 2009 09:50:43 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B39C63A68B5 for ; Wed, 17 Jun 2009 09:50:43 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 18:50:44 +0200 id 00000000005DC02F.000000004A391EE4.000009BC Message-ID: <4A391EE4.9010109@tana.it> Date: Wed, 17 Jun 2009 18:50:44 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> <4A38629F.5040506@billmail.scconsult.com> <4A38F094.1000005@tana.it> <200906171517.LAA18188@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906171517.LAA18188@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:50:45 -0000 der Mouse wrote: >> However, the standard requires that it says "EHLO host-at.some.name". > > Not quite. It requires that the HELO/EHLO argument be a valid name for > the SMTP client host. The presence or absence of any DNS zone cuts in > the vicinity is completely irrelevant. Isn't the FQDN for a host the host name "dot" the domain name? >> It is a seemingly simple task to drop the leftmost label(s) so as to >> obtain the mail domain, but doing that properly requires a zone cut >> algorithm that most servers miss. > > ...and which is wrong anyway. The division of DNS names into "hosts" > and "domains" is purely a human one. Dropping the first label from a > DNS name in an attempt to get "the domain" for it is, at best, a rough > heuristic. Looking up the DNS tree for zone cuts also is nothing more > than a heuristic. The host gets its name after some buddy edits the zone file. Which zone file? The domain's one. Yes, it is human, heuristic, and error prone. (I never seriously meant to actually implement a zone cut algorithm in MTA servers in order to derive domain names. However, that was an early hypothesis for the SPF check algorithm, as an alternative to requiring SPF records for each possible helo name.) > It's not even clear to me that there *is* a "_the_ domain". What's > "the domain" for (to invent an example) mail.research.tjw.ibm.com? If research.tjw.ibm.com had an MX, it would be a good candidate. Otherwise... elementary my dear Watson. Is that worse than Bayesian guesses? > There plausibly could be as many zone cuts as there are dots, there, > and I could argue for picking any of them as "the domain" for email > responsibility purposes (well, possibly excepting the TLD, but even > that is just a heuristic, likely to break soon). Yeah, John recently wrote something about .va sporting an MX (John Levine, not john.vatican.va) while 2nd level co.uk has none. It is much better if the domain is plainly told by the client rather than badly guessed by the server. E.g. "VHLO domain.name". From dotis@mail-abuse.org Wed Jun 17 10:26:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C083A6E8D for ; Wed, 17 Jun 2009 10:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCBOXXFcfr1Y for ; Wed, 17 Jun 2009 10:26:17 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 949163A6BBC for ; Wed, 17 Jun 2009 10:26:17 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id E45B2A94439 for ; Wed, 17 Jun 2009 17:25:49 +0000 (UTC) Message-Id: <9B8DE3C5-5882-42E9-B400-A123C038EA4B@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <1245203745.93720.748.camel@legolas.orthanc.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 10:25:49 -0700 References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:26:19 -0000 On Jun 16, 2009, at 6:55 PM, Lyndon Nerenberg wrote: > On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote: >> IMHO, all outbound MTAs should be required to return CVS records >> for their EHLO name and offer MX records for their inbound. > > Doug, are you sure that's what you meant to say? The sentence is a > bit ambiguous. Are you really saying any host that sends mail (is an > SMTP client) MUST also host an listed SMTP server? You are right. This should have been pubic MTAs, meaning those that send email using port 25 without authentication. All other sources should be restricted in some fashion, perhaps by ACLs or authentications. -Doug From vesely@tana.it Wed Jun 17 10:42:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B3A28C0F0 for ; Wed, 17 Jun 2009 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPsv120rgfVK for ; Wed, 17 Jun 2009 10:42:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 010AF3A67AC for ; Wed, 17 Jun 2009 10:42:04 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 19:41:10 +0200 id 00000000005DC031.000000004A392AB6.000010E7 Message-ID: <4A392AB6.1000306@tana.it> Date: Wed, 17 Jun 2009 19:41:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> <4A390094.3080800@tana.it> <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:42:05 -0000 der Mouse wrote: >>>> In exchange for what are we giving up reliability now? >>> Usability. >> Why would email be less usable if it implied some sort of >> responsibility on the sender's side? > > The transition in which we gave up sender responsibility is long past, > was quite protracted (roughly, I'd say, Sep 1993 through Oct 1998), and > was largely unrecognized at the time (and thus the question of benefits > gained in return did not arise). Would you expand a little more on that, please? I don't follow it. From jdfalk-lists@cybernothing.org Wed Jun 17 10:52:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4563A6BD8 for ; Wed, 17 Jun 2009 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLLljI2z3YG9 for ; Wed, 17 Jun 2009 10:52:47 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id EDE6E3A6C71 for ; Wed, 17 Jun 2009 10:52:46 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n5HHqtA9011780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Jun 2009 11:52:57 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n5HHqtA9011780 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1245261177; bh=g0EZAKMX3o1eTbs1xMamJrygTGj+P30ax2ZDce5t Pug=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NGlnmsenvnrC tKHNLL1CdPuqIXGwL5gt/tBT4UwSp6Yp2s1hc0PdOEI5Dw7I90RysFflmJHwzWSnYlp GBkcgZG8gPJioln6VcajWc87PNvwIbkrIzAk7avVthWZcvS02ub/zDJVaFZzMRuEChb f/2NYr1eUXp2cqSLpn1CCoPeI= Message-ID: <4A392D72.3080708@cybernothing.org> Date: Wed, 17 Jun 2009 11:52:50 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4515812.1851245190668283.JavaMail.franck@iphone-4.genius.local> <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <7ae58c220906170525s32c0e9f8p7c42f97e34cc0524@mail.gmail.com> In-Reply-To: <7ae58c220906170525s32c0e9f8p7c42f97e34cc0524@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:52:48 -0000 Dotzero wrote: > One approach that might help you is to go to senderscore.org (from > ReturnPath). Register for a free account and then enter in the domain > name. For example, when I enter in avonsys.com it shows me that there > is one IP address sending mail for that domain - 76.203.192.33 with a > hostname of adsl-76-203-192-33.dsl.rcsntx.sbcglobal.net. That list is based on what we've observed recently in our data network, collating delivery logs from a whole bunch of ISPs and other sources. Since it's aggregating multiple views, we tend to see more than a single site would. (You can look up some data without registering, but not all. Either way, it's still free.) -- J.D. Falk Return Path Inc http://www.returnpath.net/ From johnl@iecc.com Wed Jun 17 10:53:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65EC3A6EA7 for ; Wed, 17 Jun 2009 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3JPCAZselzD for ; Wed, 17 Jun 2009 10:53:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 779853A6E9B for ; Wed, 17 Jun 2009 10:53:23 -0700 (PDT) Received: (qmail 19977 invoked from network); 17 Jun 2009 17:53:33 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 17 Jun 2009 17:53:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=vB9cY0IuTw50ksSe70JEX6+DMMspGSLLy9vjZtkvkjs=; b=eHb/AmlGwTVoBC+7xeDFlAw20Sq1glVhshRjl99+cU2iirHWr2JrA/DluYIGbCDBllB2zoT2kpolZ81sExh5vz9IKQvFQMX4x/egCHiIcUUJWAQGWPEhowXU8hpHsr/mVOsBAkkV4IaDAOo65LI/I/4HQqRUSF5il9DnlhkWYps= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=vB9cY0IuTw50ksSe70JEX6+DMMspGSLLy9vjZtkvkjs=; b=A0frU2zTL1QZc4nzKdQQrL1SOBAfz2GF8GOxn9zw3IcNa6j3y2RyUYNVZfpApppH4e/Pp5ea+/OJjGPskduGBr+i88mj7iXLPk7GB/ZhZsUhTMLrEQQkBYPhY3KaZxNBtD/fg3S6BbHlhNHNRnUk0pv3AWyvmVLaJ1jW9HiW0ew= Date: 17 Jun 2009 17:53:32 -0000 Message-ID: <20090617175332.5169.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A391EE4.9010109@tana.it> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:53:24 -0000 >Isn't the FQDN for a host the host name "dot" the domain name? The FQDN for a host is the host's FQDN. As we've all noted, there's lots of heuristics to guess domain names, none of which work. R's, John From johnl@iecc.com Wed Jun 17 10:55:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2633A6E47 for ; Wed, 17 Jun 2009 10:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUnXyuQPcS9I for ; Wed, 17 Jun 2009 10:55:26 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 873BE3A6E9A for ; Wed, 17 Jun 2009 10:55:26 -0700 (PDT) Received: (qmail 21756 invoked from network); 17 Jun 2009 17:55:34 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 17 Jun 2009 17:55:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=sXOIwYDZSEzKB17CjLFoEjxuhzic6pHf26eaH6P2eCU=; b=DA2PcGw0VWm+G2ddQp+BevaYUXAkcrJu/WgprVIikoyRWQqRocUVZjhHi90j6f3eXhmsGE6JKrznaIjNuxnn+sglV5mAUNMp3C/1f10U8rn2hct0Y7XLPXkYHHa5ME55DXGTlNgBSDtVX5OwX8cAlK9HE6E3dHQQ9Ef3X7Q2hNw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=sXOIwYDZSEzKB17CjLFoEjxuhzic6pHf26eaH6P2eCU=; b=g0DLU1cyq1btV2jUaxO8DTuDGCtuhuvTWu7LSwUyGzRGwAR4g3jYBxt9JBRiFCuBTVO4+VUX+9Z8j1Z0MIt31+bi4FUDoY0DPurmScIJB+gzertS6udvyfD5XU71mwGRPse6g89xhlbonccM7ySSmtAZHirfwWAoyBJxNfSZe5g= Date: 17 Jun 2009 17:55:34 -0000 Message-ID: <20090617175534.5222.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:55:27 -0000 >I predict that no significant amount of mail ever originates from IPV6. >Because it would be impossible to maintain a DNSBL for IPV6 Why? I expect that v6 DNSBLs will list /64s by default, which makes them roughly analogous to v4 DNSBLs. I also doubt that it is a very good idea to assume that DNSBLs will always be the way that people do reputation management. R's, John From dotzero@gmail.com Wed Jun 17 10:59:47 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9223A6C71 for ; Wed, 17 Jun 2009 10:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST+kIKuJMQg0 for ; Wed, 17 Jun 2009 10:59:46 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id C973B3A6E99 for ; Wed, 17 Jun 2009 10:59:45 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so250170qwe.7 for ; Wed, 17 Jun 2009 10:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IptT82MTmEicZYdiQy+3uEGil+RkA6lU/WTdJIRTyWE=; b=MkoqSEDt6N/1v8+gTQ6WztPPHk3eNAESbhM4W7eTHV06u6m9U1SWlHF15j2nwuTrBU VIWMoakUf9h7EVEzbm20huSf+f8lsOP8/RKyANDfValxXF7vDJzLhiYDPTzArJEXBvo3 310P26pN5lpfloxr1esmHtVZWExOAdqI83yXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vAIdgTGH3c69uDxYm9ZtXUVpip37AK0b6hCw33U35jgfchvgGfsEPZgzQYcYLOSIWn hzPgiVT/LfyRqXmB0GHdD94wybqe2g0/xT094yBrx41opaapukLvpKjngGy9giu33dyc 5AeqOzb+CnpKYrsCl48ufoRrbgIlxNs8QHVJE= MIME-Version: 1.0 Received: by 10.220.75.9 with SMTP id w9mr613510vcj.82.1245261594015; Wed, 17 Jun 2009 10:59:54 -0700 (PDT) In-Reply-To: <4A392D72.3080708@cybernothing.org> References: <4515812.1851245190668283.JavaMail.franck@iphone-4.genius.local> <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <7ae58c220906170525s32c0e9f8p7c42f97e34cc0524@mail.gmail.com> <4A392D72.3080708@cybernothing.org> Date: Wed, 17 Jun 2009 13:59:53 -0400 Message-ID: <7ae58c220906171059m2d374946m567dd9f8ebb2e09f@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:59:47 -0000 On Wed, Jun 17, 2009 at 1:52 PM, J.D. Falk w= rote: > Dotzero wrote: > >> One approach that might help you is to go to senderscore.org (from >> ReturnPath). Register for a free account and then enter in the domain >> name. For example, when I enter in avonsys.com it shows me that there >> is one IP address sending mail for that domain - 76.203.192.33 with a >> hostname of adsl-76-203-192-33.dsl.rcsntx.sbcglobal.net. > > That list is based on what we've observed recently in our data network, > collating delivery logs from a whole bunch of ISPs and other sources. =A0= Since > it's aggregating multiple views, we tend to see more than a single site > would. > > (You can look up some data without registering, but not all. =A0Either wa= y, > it's still free.) > The reason I said to register is that the information available to non-registered users would not have helped answer the question he posed. From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 11:24:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE33E3A6955 for ; Wed, 17 Jun 2009 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.734 X-Spam-Level: X-Spam-Status: No, score=-9.734 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WEK+miFXMKv for ; Wed, 17 Jun 2009 11:24:07 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id A610928C282 for ; Wed, 17 Jun 2009 11:23:54 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA19238; Wed, 17 Jun 2009 14:24:06 -0400 (EDT) From: der Mouse Message-Id: <200906171824.OAA19238@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 14:14:32 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A391EE4.9010109@tana.it> References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <1245203745.93720.748.camel@legolas.orthanc.ca> <4A38629F.5040506@billmail.scconsult.com> <4A38F094.1000005@tana.it> <200906171517.LAA18188@Sparkle.Rodents-Montreal.ORG> <4A391EE4.9010109@tana.it> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:24:08 -0000 >> [SMTP] requires that the HELO/EHLO argument be a valid name for the >> SMTP client host. > Isn't the FQDN for a host the host name "dot" the domain name? Only if you define "host name" and "domain name" that way. It would be logically consistent to do so (though somewhat confusing, because "host name" and "domain name" are already in wide use to mean other things). Defining them that way is really just giving names to a heuristic. The "domain name" determined that way will be what you want for a substantial fraction of your mail clients, but by no means all (well, unless you have a remarkably unusual mail stream). > The host gets its name after some buddy edits the zone file. Which > zone file? The domain's one. That amounts to defining a host's "domain name" to be the next zone cut at-or-above it in the DNS hierarchy. That's a consistent definition, and useful as a heuristic, but will fail in enough cases it's no better than that. (Fail meaning give you something other than what you want.) Actually, it amounts to that for most hosts; for glue nameservers, the "which zone file" heuristic gives a different domain than the "next zone cut" one. But neither one is better than a heuristic. (Glue nameservers usually aren't mailservers for mid- to large-size sites, but for small private sites, it's not uncommon for everything to be on the same machine.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 11:33:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B833828C141 for ; Wed, 17 Jun 2009 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.751 X-Spam-Level: X-Spam-Status: No, score=-9.751 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MxB+1Vx-bXk for ; Wed, 17 Jun 2009 11:33:48 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 5533D3A6E7B for ; Wed, 17 Jun 2009 11:33:38 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA19281; Wed, 17 Jun 2009 14:33:49 -0400 (EDT) From: der Mouse Message-Id: <200906171833.OAA19281@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 14:24:13 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A392AB6.1000306@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> <4A390094.3080800@tana.it> <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> <4A392AB6.1000306@tana.it> Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:33:48 -0000 >> The transition in which we gave up sender responsibility is long >> past, was quite protracted (roughly, I'd say, Sep 1993 through Oct >> 1998), and was largely unrecognized at the time (and thus the >> question of benefits gained in return did not arise). > Would you expand a little more on that, please? I don't follow it. I picked those months as the September that never ended for the beginning and Jon Postel's death for the end. The former started the flood that turned the net from a responsible place populated (entirely, or close enough that that's an operation approximation) by people who shared a smooth-running net as a common goal into what we have today, where such people are an idealistic, tiny, and largely impotent minority. The latter is as close as I've found to a watershed event for the transition from Internet governance with a well-run net as the primary motivation at the top of the pyramid to Internet governance with profit as the primary motivation at the top of the pyramid. (Yes, I'm convinced the latter is basically what we have today. I've heard of at least one TLD suggestion being turned down because the proposed rules for it wouldn't allow large numbers of domain registrations - which was actually the whole point, but because there wasn't a high-profit business model behind it it was rejected. This also explains, though not excuses, the mismatch between authority and responsibility; offering authority without responsibility draws lots more customers.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From dotis@mail-abuse.org Wed Jun 17 17:18:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7BE3A6ECF for ; Wed, 17 Jun 2009 17:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cMNJz-XCr-p for ; Wed, 17 Jun 2009 17:18:28 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 14D573A6EAD for ; Wed, 17 Jun 2009 17:18:28 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id ED0FDA94439 for ; Thu, 18 Jun 2009 00:18:32 +0000 (UTC) Message-Id: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 17:18:32 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 00:18:30 -0000 On Jun 17, 2009, at 7:59 AM, Steve Atkins wrote: > On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote: > >> Because it would be impossible to maintain a DNSBL for IPV6, > > I keep hearing people say this, but I've not seen any clear > justification for it. It seems to me to be no more difficult to run > a blacklist for IPv6 addresses than IPv4 addresses (neither is easy, > but the details of the address representation don't seem to make > more than minor differences). > > Can you expand on why you think it's the case, or point me at some > discussion of it? Factors that make managing an IPv6 block-listing service fairly impractical go beyond 96 additional address bits. The term impractical is used because, with enough money, anything is possible. 1) Publishing behavior based address lists require evidence collection in the event of disputes, and this does not scale well. (expensive) 2) IPv6 to IPv4 and IPv6 to IPv6 NATs obfuscates who might be involved. (problematic) 3) Reverse DNS scanning does not scale well. (slow) 4) Diverse and rapidly expanding address space allows bad-actor's activity to stay ahead of the massive amounts of IP address related information publishing. (futile) 5) An extremely low cost for IP addresses allows bad actors to persist at sporadic use for many years. (futile) The collection of evidence is often constrained by the related identifier, such as the IP address. Unfortunately, IPv6 allows a new IP address to be used for each message sent. Some countries already place thousands of MTAs behind carrier grade NATs. Any scheme that concludes the use or abuse of an IP address indicates which individual originated a message makes it ill-equipped to deal with today's evolving network environment. Block-listing must soon be replaced by acceptance-listing. Things like CSV would permit a means to consolidate the sources managed by acceptance-lists, where reputation could be based upon MTA domains, rather than a vast array of IP address or the domains controlled by their customers. With email so heavily abused, attempting to acquire and process the ten to two hundred SPF transactions per message is not possible at today's magnitude of abuse per legitimate message. SPFs use of macros and exists functions requires a process done in conjunction with message acceptance, while at the same time placing DNS itself in peril. Any strategy that attempts to place the customers of an email provider responsible simply does not scale as an abuse deterrent. Management efforts can be reduced a million fold when directly holding the immediate outbound public MTA accountable, rather than attempting to shift accountability toward one of a provider's many users, which is the real (and admitted) motivation behind SPF/Sender-ID/A-R. This Nast cartoon depicts the situation fairly well by changing the question to asking who is responsible for email's dire situation and having the men in the circle represent that of the providers. http://en.wikipedia.org/wiki/File:Tammany_Ring,_Nast.jpg Pushing responsibility to the edge does not work, and email provides ample evidence. This nonsense is putting the Internet itself in peril. -Doug From mouse@Sparkle.Rodents-Montreal.ORG Wed Jun 17 18:05:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1523A69E3 for ; Wed, 17 Jun 2009 18:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.779 X-Spam-Level: X-Spam-Status: No, score=-9.779 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMsat4W9gaWG for ; Wed, 17 Jun 2009 18:05:07 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id E741E3A67D4 for ; Wed, 17 Jun 2009 18:05:06 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA21834; Wed, 17 Jun 2009 21:05:04 -0400 (EDT) From: der Mouse Message-Id: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 17 Jun 2009 20:51:13 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 01:05:08 -0000 > Factors that make managing an IPv6 block-listing service fairly > impractical go beyond 96 additional address bits. > 1) Publishing behavior based address lists require evidence > collection in the event of disputes, and this does not scale well. > (expensive) I can't see why v6 versus v4 makes any difference at all to this. > 2) IPv6 to IPv4 and IPv6 to IPv6 NATs obfuscates who might be > involved. (problematic) I can't see why this is any worse than the v4-to-v4 NATs the net is already full of. > 3) Reverse DNS scanning does not scale well. (slow) True. DNSBLs that depend on rDNS scanning may die. There are plenty of DNSBLs, including some of the most useful, that do not. > 4) Diverse and rapidly expanding address space allows bad-actor's > activity to stay ahead of the massive amounts of IP address related > information publishing. (futile) I see no real difference here between a v4 list that lists at the /32 level and a v6 list that lists at the /48 (or maybe even /64) level. > 5) An extremely low cost for IP addresses allows bad actors to > persist at sporadic use for many years. (futile) And this differs from v4...how? > The collection of evidence is often constrained by the related > identifier, such as the IP address. Unfortunately, IPv6 allows a new > IP address to be used for each message sent. So, collect evidence at the /64, or even /48, level, rather than at the individual address level. Even to the extent that these problems are real, they are theoretical. It certainly behooves us to think about them ahead of time, but absent experience demonstrating that they are more than potential, I don't see them as a reason to give up on v6 DNSBLs without even trying. > Pushing responsibility to the edge does not work, and email provides > ample evidence. It's not that doing that has been tried and found wanting; rather, it has not been tried. (Actually, it has been tried in a limited way; there are pieces of the net that _do_ push responsibility to the end user. Oddly enough, they are basically nonexistent as far as abuse emitters go; what evidence I see indicates that it _does_ work.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From vesely@tana.it Wed Jun 17 22:40:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350EB3A6A3A for ; Wed, 17 Jun 2009 22:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQOZ6MZhyEnc for ; Wed, 17 Jun 2009 22:40:20 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 555C93A6A00 for ; Wed, 17 Jun 2009 22:40:20 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 18 Jun 2009 07:40:28 +0200 id 00000000005DC031.000000004A39D34C.00006357 Message-ID: <4A39D34D.3050403@tana.it> Date: Thu, 18 Jun 2009 07:40:29 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <200906161301.JAA26149@Sparkle.Rodents-Montreal.ORG> <4A37B25C.8010904@tana.it> <200906161604.MAA27224@Sparkle.Rodents-Montreal.ORG> <4A38B4D0.2090305@tana.it> <200906171330.JAA17682@Sparkle.Rodents-Montreal.ORG> <4A390094.3080800@tana.it> <200906171537.LAA18321@Sparkle.Rodents-Montreal.ORG> <4A392AB6.1000306@tana.it> <200906171833.OAA19281@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906171833.OAA19281@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 05:40:21 -0000 der Mouse wrote: >>> The transition in which we gave up sender responsibility is long >>> past, was quite protracted (roughly, I'd say, Sep 1993 through Oct >>> 1998), and was largely unrecognized at the time (and thus the >>> question of benefits gained in return did not arise). >> Would you expand a little more on that, please? I don't follow it. > > I picked those months as the September that never ended for the > beginning and Jon Postel's death for the end. > > The former started the flood that turned the net from a responsible > place populated (entirely, or close enough that that's an operation > approximation) by people who shared a smooth-running net as a common > goal into what we have today, where such people are an idealistic, > tiny, and largely impotent minority. > > The latter is as close as I've found to a watershed event for the > transition from Internet governance with a well-run net as the primary > motivation at the top of the pyramid to Internet governance with profit > as the primary motivation at the top of the pyramid. (Yes, I'm > convinced the latter is basically what we have today. I've heard of at > least one TLD suggestion being turned down because the proposed rules > for it wouldn't allow large numbers of domain registrations - which was > actually the whole point, but because there wasn't a high-profit > business model behind it it was rejected. This also explains, though > not excuses, the mismatch between authority and responsibility; > offering authority without responsibility draws lots more customers.) Thanks for sharing that. We need to overcome that syndrome for something larger than just the Internet. The profit (greedy) model makes us blind, as it implies concentrating on short-term objectives rather than considering long term strategies. From iane@sussex.ac.uk Thu Jun 18 02:21:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B513A6CA5 for ; Thu, 18 Jun 2009 02:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hRAqUPlioqg for ; Thu, 18 Jun 2009 02:21:56 -0700 (PDT) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 2BBAA3A68E4 for ; Thu, 18 Jun 2009 02:21:56 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63982) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLFGQN-0003Y6-AU for asrg@irtf.org; Thu, 18 Jun 2009 10:23:11 +0100 Date: Thu, 18 Jun 2009 10:22:05 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <4569059E533E8FDD917513E3@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A38CDAF.5050503@tana.it> References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <6.2.5.6.2.20090616060804.02e285c8@resistor.net> <4A37D79D.90508@tana.it> <200906161740.NAA27908@Sparkle.Rodents-Montreal.ORG> <4A38CDAF.5050503@tana.it> Originator-Info: login-token=Mulberry:019I1Qy13uvjA1+qQtYLNnAsM+WgVxJVezafg=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:21:57 -0000 --On 17 June 2009 13:04:15 +0200 Alessandro Vesely wrote: > der Mouse wrote: >>> Vernon's list is not really helpful, except for trying and discourage >>> potential submitters. >> >> You're reading it too literally. The "sound advice" is not present >> overtly; it could perhaps be phrased "make sure you're not falling into >> any of these traps if you want to be taken seriously rather than >> eliciting just pointing and laughing". > > Although some of those traps aim at sounding out technical skills of > spam-killer wannabes, many of them indulge in psychological, social, or > economical aspects of their personality. Does that mean anti-spam is a > sort of psychological task? Absolutely it is. You have to understand several pychological issues: 1. What motivates people to send spam. 2. Why people don't like receiving spam. 3. Who people want to communicate with. 4. How people interact with their mail - what's an easy spam reporting mechanism, for example. 5. How to persuade administrators and their managers to adopt sustainable* solutions. *sustainable solutions: ones with high costs for spammers, and bearable costs for the rest of us. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Thu Jun 18 02:39:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4D23A6C9F for ; Thu, 18 Jun 2009 02:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkxM4LAZACga for ; Thu, 18 Jun 2009 02:39:39 -0700 (PDT) Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 3C8DD3A6CAB for ; Thu, 18 Jun 2009 02:39:39 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64375) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLFHK6-00096N-R4 for asrg@irtf.org; Thu, 18 Jun 2009 10:40:55 +0100 Date: Thu, 18 Jun 2009 10:39:48 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <2886F0CCE51E030268144878@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090617175534.5222.qmail@simone.iecc.com> References: <20090617175534.5222.qmail@simone.iecc.com> Originator-Info: login-token=Mulberry:01N0zBaKCtL814uRXKo3KqwTTbncTiwppyrLc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:39:40 -0000 Oddly, most of this thread isn't really relevant to the subject line. The reason for asking the question is that we don't currently have widely published SPF records. If we did, then we wouldn't need IP address reputation for either IPV4 or IPV6. We'd just need the answer to two questions: 1. Does that IP address have permission to emit mail from the sender domain? 2. Do I want email from that sender? If the sender doesn't have a good reputation, perhaps the domain does? If the reputation is neutral, I'll take a good look at the content and the delivery rate. Even the above isn't relevant to the OP, who just wanted to diagnose a delivery failure - but that is likely to have been a symptom of some anti-spam measure that wasn't domain reputation related. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From dotis@mail-abuse.org Thu Jun 18 12:00:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B29C28C45C for ; Thu, 18 Jun 2009 12:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIiVAjl30MLp for ; Thu, 18 Jun 2009 12:00:23 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id E26C028C4D9 for ; Thu, 18 Jun 2009 12:00:12 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 80E5FA94439 for ; Thu, 18 Jun 2009 19:00:25 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 12:00:25 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:00:24 -0000 On Jun 17, 2009, at 5:51 PM, der Mouse wrote: >> Factors that make managing an IPv6 block-listing service fairly >> impractical go beyond 96 additional address bits. >> >> 1) Publishing behavior based address lists require evidence >> collection in the event of disputes, and this does not scale well. >> (expensive) > > I can't see why v6 versus v4 makes any difference at all to this. You have concluded that resolution of an IPv6 address reputation can safely ignore portions of the address. Assuming the lower bits don't matter (64 bits of interface or 16 bits of site level identifiers, which will in some cases), that still leaves 53 or 37 bits of unicast address space in which to contend. This also represents a space likely to evolve as routes become consolidated. In an effort to constrain zone growth and to thwart address hopping, IPv4 addresses may have been consolidated into CIDRs that don't cross route announcements when the majority of addresses abuse email. This might then result in a CIDR of /30 that contains a single IP address where evidence had not been collected. Invariably, the user of that one IP address will complain and request removal. Imagine who might be affected when CIDR consolidation goes from groups of of 256 or 4096 to groups of 18x10^18 or 1.2x10^24 based upon the evidence of a single IP address? In addition, the collection of IP address related evidence must be retained and reviewed. IPv6's increased range ensures a greater workload for review and a much greater need for storage. This increase will entail a sizable expenditure. >> 2) IPv6 to IPv4 and IPv6 to IPv6 NATs obfuscates who might be >> involved. (problematic) > > I can't see why this is any worse than the v4-to-v4 NATs the net is > already full of. It is not as common to find carrier grade NATs. Excluding these sources has already become problematic in a few countries, and will only get worse. >> 3) Reverse DNS scanning does not scale well. (slow) > > True. DNSBLs that depend on rDNS scanning may die. There are > plenty of DNSBLs, including some of the most useful, that do not. A reactive system that list addresses as abused and then automatically expire provides bad-actors two advantages: a) bad-actors can avoid effective blocking by rapidly moving both source and target. b) professional bad-actors can quickly identify the location of spam traps. >> 4) Diverse and rapidly expanding address space allows bad-actor's >> activity to stay ahead of the massive amounts of IP address related >> information publishing. (futile) > > I see no real difference here between a v4 list that lists at the / > 32 level and a v6 list that lists at the /48 (or maybe even /64) > level. It already takes minutes to build zones and distribute information. Making zones larger increases processing and transfer time which already erodes effectiveness. >> 5) An extremely low cost for IP addresses allows bad actors to >> persist at sporadic use for many years. (futile) > > And this differs from v4...how? It is fairly common to see abusive activity cycle through a range of addresses for one day every few weeks. With IPv6, the addresses being abused could then cycle through a range for 1 minute every decade. What policy deal effectively with that strategy? >> The collection of evidence is often constrained by the related >> identifier, such as the IP address. Unfortunately, IPv6 allows a >> new IP address to be used for each message sent. > > So, collect evidence at the /64, or even /48, level, rather than at > the individual address level. > > Even to the extent that these problems are real, they are > theoretical. It certainly behooves us to think about them ahead of > time, but absent experience demonstrating that they are more than > potential, I don't see them as a reason to give up on v6 DNSBLs > without even trying. It seems insane to repeatedly do the same thing and then expect different results each time. IPv4 is already approaching the majority of all the addresses being blocked. It will not be long for this to transition into only listing IP addresses registered as outbound mail servers. The registration process might be as simple as having both an MX and CSV record published. >> Pushing responsibility to the edge does not work, and email >> provides ample evidence. > > It's not that doing that has been tried and found wanting; rather, > it has not been tried. Have you heard of SPF? SPF represents a strategy to shift MTA accountability onto the domains of their customers (the preverbal edge). This scheme may entail a maximum of 10 or 11 SPF record transactions, which may then include 10 transactions per contained MX target. For each legitimate message, there is typically at least 20 abusive messages (which also publish SPF records). So the potential of 10 to 200 additional SPF transactions (when Sender-ID is included) should be multiplied by 20, where the 200 transactions becomes 4000 per legitimate message. The ratio of legitimate to abusive is getting worse. At what point does one admit that SPF, when used as designed, does not scale, that it imperils the integrity of DNS, and that it imperils the viability of SMTP. If nothing else, SPF/Sender-ID has been responsible for delaying more scalable and safer solutions. Just as you can't ask lenders using securitization to dodge lending accountability how they might be held accountable, you can't ask a group of large providers this question either and expect a reasonable answer. The system needs to hold providers directly accountable. That is what CSV attempted, where publishing too many such records or using too many EHLOs should also be considered abusive. > (Actually, it has been tried in a limited way; there are pieces of > the net that _do_ push responsibility to the end user. Oddly > enough, they are basically nonexistent as far as abuse emitters go; > what evidence I see indicates that it _does_ work.) Can you provide some specifics? -Doug From mouse@Sparkle.Rodents-Montreal.ORG Thu Jun 18 13:44:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1B43A6A8D for ; Thu, 18 Jun 2009 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.801 X-Spam-Level: X-Spam-Status: No, score=-9.801 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME4ySE6++vsI for ; Thu, 18 Jun 2009 13:44:07 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 77FD13A6A4B for ; Thu, 18 Jun 2009 13:44:07 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA05200; Thu, 18 Jun 2009 16:44:03 -0400 (EDT) From: der Mouse Message-Id: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 18 Jun 2009 15:19:24 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 20:44:08 -0000 > IPv4 is already approaching the majority of all the addresses being > blocked. Well...not all that closely, at least not by people who care about their mail. The Spamhaus Zen list, arguably one of the most useful, best run, and least fringe of DNSBLs, currently lists slightly over 521 million addresses, a touch under 1/8th of the IPv4 space. Removing the PBL component - meaning, just bad actors (for SBL-XBL defintiions of "bad"), not including addresses whose providers say they're not supposed to be sending mail but which haven't necessarily been observed doing so - brings this down to between 11 and 12 million addresses, which is tiny; it's between 1/4 and 1/3 of 1% of IPv4 space. >>> Pushing responsibility to the edge does not work, and email >>> provides ample evidence. >> It's not that doing that has been tried and found wanting; rather, >> it has not been tried. > Have you heard of SPF? Yes. It flopped, no? If it had been widely adopted, I might have to decide whether I think it constitutes "pushing responsibility to the edge". But I don't. >> (Actually, it has been tried in a limited way; there are pieces of >> the net that _do_ push responsibility to the end user. Oddly >> enough, they are basically nonexistent as far as abuse emitters go; >> what evidence I see indicates that it _does_ work.) > Can you provide some specifics? I worked for McGill (a university in Montreal) for most of my career, some 15 years, about 10 of those as postmaster for one of the labs there. Certainly we, and to the extent that I saw it the rest of the University, imposed responsibility on end users. I am currently working for Openface Internet, an ISP in Montreal. While it's done very differently (the provider/user relationships are vastly different in the two contexts), we too push responsibility for the user of the address space we grant our customers to those customers. Neither of these were completely abuse-free. But nobody their size is - heck, even my house /28 once emitted some misbehaviour for a few minutes, when someone asked my help getting a machine cleaned up and I made a mistake with filtering - and I've seen no reason to think they were/are even slightly above the background noise. (If anyone has evidence to the contrary for Openface, please tell me; I'll certainly get it into the hands of our abuse handlers, and can track the issue. For McGill, I'm less able to act since I no longer work there, but it hasn't been so long I don't still know people.) Yes, they're tiny fractions of the net. Openface has a /19 and a /20. McGill had two /16s - I don't know what they have now. That doesn't invalidate my point. Other places, where similar policies and enforcement exist (or have existed), have exhibited similarly low abuse-emitter profiles in my experience. Other Montreal universities. RCN while Afterburner was abuse lead there - that was during a period when I made a point of complaining about every spam that got through to me, spending hours a day writing spam complaints, and I had all of _one_ occasion to write to RCN, which drew prompt and effective response. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From rsk@gsp.org Thu Jun 18 13:46:28 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541DB28C164 for ; Thu, 18 Jun 2009 13:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnPgcWuxXnna for ; Thu, 18 Jun 2009 13:46:27 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 386F428C155 for ; Thu, 18 Jun 2009 13:46:27 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5IKkdwS027921 for ; Thu, 18 Jun 2009 16:46:39 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5IKgM4R016931 for ; Thu, 18 Jun 2009 16:42:22 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5IKkXNX013009 for ; Thu, 18 Jun 2009 16:46:33 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5IKkXpc013008 for asrg@irtf.org; Thu, 18 Jun 2009 16:46:33 -0400 Date: Thu, 18 Jun 2009 16:46:33 -0400 From: Rich Kulawiec To: asrg@irtf.org Message-ID: <20090618204633.GB12663@gsp.org> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4A3864C5.1050006@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3864C5.1050006@billmail.scconsult.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 20:46:28 -0000 On Tue, Jun 16, 2009 at 11:36:37PM -0400, Bill Cole wrote: > That said, I think that adding DNS records that map specific network > addresses to their legitimate behaviors in a generalized model would be a > positive advance. +1. For instance, I (semi-seriously, semi-facetiously) proposed "XM" records some years ago, whose value would be 0 or 1: hosts with 1 send SMTP traffic, hosts with 0 don't. Thus every MX's behavior could be to reject all port 25 SMTP connections from hosts with XM=0. There a lot of problems with this idea, and if memory serves, both Dave Crocker and John Levine pointed them out at the time. But I think that perhaps it's time to revisit the general concept and see if it could be made to work for (as Bill said) "legitimate behaviors in a generalized model". This would not only allow us to address SMTP abuse, but (for example) zombie hosting of DNS and HTTP servers. ---Rsk From rsk@gsp.org Thu Jun 18 13:47:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B587C28C154 for ; Thu, 18 Jun 2009 13:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRUV+L0OrVUk for ; Thu, 18 Jun 2009 13:47:06 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id C90F73A6A7F for ; Thu, 18 Jun 2009 13:47:05 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5IKlHcP006848 for ; Thu, 18 Jun 2009 16:47:18 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5IKh0jc006431 for ; Thu, 18 Jun 2009 16:43:00 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5IKlBHZ013427 for ; Thu, 18 Jun 2009 16:47:11 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5IKlB0d013426 for asrg@irtf.org; Thu, 18 Jun 2009 16:47:11 -0400 Date: Thu, 18 Jun 2009 16:47:11 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090618204711.GC12663@gsp.org> References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> <4A38F6A7.6090700@nd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A38F6A7.6090700@nd.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 20:47:06 -0000 On Wed, Jun 17, 2009 at 09:59:03AM -0400, Paul Russell wrote: > The first part of that has always been a good idea. The second part may have > been workable ten years ago, but on today's Internet, exercising leniency in > what you accept will get you flooded with all sorts of traffic that you neither > want nor need. I strongly agree with Paul on this point. I'd *like* to be lenient about what I permit systems to receive, but circumstances dictate otherwise. We no longer have an Internet where good behavior is the norm and where system/network operators make that their primary goal; we have an Internet where abuse is the norm and most system/network operators not only don't care about good behavior, but have the audacity to complain when anyone points out that they're not exhibiting it. ---Rsk From feenberg@nber.org Thu Jun 18 14:29:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602C43A67E1 for ; Thu, 18 Jun 2009 14:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3K9PRCdACDg for ; Thu, 18 Jun 2009 14:29:05 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id B926E3A6BAE for ; Thu, 18 Jun 2009 14:28:44 -0700 (PDT) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.1/8.13.8) with ESMTP id n5ILSqEZ068798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 18 Jun 2009 17:28:53 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.7+Sun/8.12.10) with ESMTP id n5ILMGaJ024574; Thu, 18 Jun 2009 17:22:16 -0400 (EDT) Received: from localhost (feenberg@localhost) by nber6.nber.org (8.13.7+Sun/8.13.7/Submit) with ESMTP id n5ILMGre024571; Thu, 18 Jun 2009 17:22:16 -0400 (EDT) X-Authentication-Warning: nber6.nber.org: feenberg owned process doing -bs Date: Thu, 18 Jun 2009 17:22:16 -0400 (EDT) From: Daniel Feenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <20090618204633.GB12663@gsp.org> Message-ID: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4A3864C5.1050006@billmail.scconsult.com> <20090618204633.GB12663@gsp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20090618 #2134094, check: 20090618 clean Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:29:06 -0000 On Thu, 18 Jun 2009, Rich Kulawiec wrote: > On Tue, Jun 16, 2009 at 11:36:37PM -0400, Bill Cole wrote: >> That said, I think that adding DNS records that map specific network >> addresses to their legitimate behaviors in a generalized model would be a >> positive advance. > > +1. For instance, I (semi-seriously, semi-facetiously) proposed "XM" > records some years ago, whose value would be 0 or 1: hosts with 1 send > SMTP traffic, hosts with 0 don't. Thus every MX's behavior could be > to reject all port 25 SMTP connections from hosts with XM=0. > > There a lot of problems with this idea, and if memory serves, both > Dave Crocker and John Levine pointed them out at the time. But I think Are there problems that would extend beyond the problems of traders in improper material who don't want their material sitting in queues on the ISP MTA? This is usually dressed up as "The FBI is after me for my advanced political views" or "My ISP is an evil monopolist", but are there problems for other users of email? I would also add that the "end to end" principle, however much it applies to voluntary associations between endpoints, can hardly be applied to the SMTP protocol, where complete strangers are expected to interact. Sites will always be cautious of strangers, and asking that SMTP senders be vouched for by their DNS providor is a very small concession indeed. Furthermore, the "endpoint" in the "end-to-end" principle is a host, not a user, so it is perfectly within the principle to is a host IP address as a discrimination device. Daniel Feenberg From johnl@iecc.com Thu Jun 18 14:42:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8554928C0FF for ; Thu, 18 Jun 2009 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o54AbG2vOnfj for ; Thu, 18 Jun 2009 14:42:12 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 5C3863A6874 for ; Thu, 18 Jun 2009 14:42:12 -0700 (PDT) Received: (qmail 57074 invoked from network); 18 Jun 2009 21:42:22 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Jun 2009 21:42:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=0n20KUee13HlxN4aarry6vMKXG/UJnyoRVMLz520b0g=; b=TV+mwDT9Ak7SvemdmtdxENgK4a9GNW8m/Ycq/l1uNsg43DVp0Pyw05oKbnIfpxhXUakoCBIAfREfWCwcqzc/PqCM+plkh5s1n7gpV6ONWAT+BJKr9nuXS9dRlCtN0agc7XvuMZvWvsa615EkSF1wxTHcusQNGow49MFQqS5sJpM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=0n20KUee13HlxN4aarry6vMKXG/UJnyoRVMLz520b0g=; b=l45X0UelJd/Dr4vQwg/90vb9OQGFw7F2YlArIPCKY1G4e6MzkXpE+QM3O3HoY0PBi085BglfnpZTls/7gCgVi7T4xytI0BoCIjXhVzhldYu+v0bw21tLKY1lUFEIRmFuYxIX2a1fe0j7wo/Ggi71G45fybPXZrMX4A6KjWsiTxc= Date: 18 Jun 2009 21:42:21 -0000 Message-ID: <20090618214221.9359.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:42:13 -0000 >> [ marking valid SMTP client hosts ] >> There a lot of problems with this idea, and if memory serves, both >> Dave Crocker and John Levine pointed them out at the time. But I think > >Are there problems that would extend beyond the problems of traders in >improper material who don't want their material sitting in queues on the >ISP MTA? The problems were technical, putting records other than PTR in the rDNS zone. That's why Dave and I came up with CSV. Pretty please, read http://www.mipassoc.org/csv/ if you want to continue this discussion. R's, John From mouse@Sparkle.Rodents-Montreal.ORG Thu Jun 18 15:00:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7B73A6AE1 for ; Thu, 18 Jun 2009 15:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrl+YGB-8ZO3 for ; Thu, 18 Jun 2009 15:00:38 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id EF73A3A67F4 for ; Thu, 18 Jun 2009 15:00:37 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA05569; Thu, 18 Jun 2009 18:00:50 -0400 (EDT) From: der Mouse Message-Id: <200906182200.SAA05569@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 18 Jun 2009 17:57:03 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090618214221.9359.qmail@simone.iecc.com> References: <20090618214221.9359.qmail@simone.iecc.com> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 22:00:39 -0000 > The problems were technical, putting records other than PTR in the > rDNS zone. That's why Dave and I came up with CSV. > Pretty please, read http://www.mipassoc.org/csv/ if you want to > continue this discussion. Offhand, I don't see anything there that explains what's wrong with putting records other than PTR under an rDNS zone. Certainly _some_ non-PTR record types cause no problems, such as CNAME and zone cut administrative records like SOA and NS. In short, I don't see what's wrong with XM from a technical standpoint. What am I missing? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From dotis@mail-abuse.org Thu Jun 18 16:01:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607963A6911 for ; Thu, 18 Jun 2009 16:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUzFV+-RYo-j for ; Thu, 18 Jun 2009 16:01:24 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 936913A68FB for ; Thu, 18 Jun 2009 16:01:24 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 416C6A94439 for ; Thu, 18 Jun 2009 23:01:37 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 16:01:36 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 23:01:25 -0000 On Jun 18, 2009, at 12:19 PM, der Mouse wrote: >> Have you heard of SPF? > > Yes. It flopped, no? If it had been widely adopted, I might have > to decide whether I think it constitutes "pushing responsibility to > the edge". But I don't. The answer to this question depends upon who is asked. MTA vendors are further enabling use of this practice, often only offering an impression of security. Avoiding accountability remains the siren song luring large providers. >>> (Actually, it has been tried in a limited way; there are pieces of >>> the net that _do_ push responsibility to the end user. Oddly >>> enough, they are basically nonexistent as far as abuse emitters >>> go; what evidence I see indicates that it _does_ work.) >> >> Can you provide some specifics? > > I worked for McGill (a university in Montreal) for most of my > career, some 15 years, about 10 of those as postmaster for one of > the labs there. Certainly we, and to the extent that I saw it the > rest of the University, imposed responsibility on end users. This control is "out-of-band" from the abused protocol, and not the result of all recipients of the protocol resolving possible identities of each of university users. > I am currently working for Openface Internet, an ISP in Montreal. > While it's done very differently (the provider/user relationships > are vastly different in the two contexts), we too push > responsibility for the user of the address space we grant our > customers to those customers. The point attempted was to ensure providers are held accountable for their stewardship at handling abuse. Schemes that pass accountability onto what might be feckless domain owners are inherently evil. With SPF/Sender-ID, providers take the persona of their purported customer's domain. Those describing SPF often erroneously suggest MTA authorization provides evidence a message originated from those providing the authorization. Providers regulating their users is not what is being advocated by those promoting SPF/Sender-ID and advocating moving accountability to the edge. Their desire is to have end recipients conducting many transactions to reveal an authorization, but not the one transaction that could have revealed the identity of the provider. As such, providers can remain lax in their stewardship, and the end-point victim is expected to preform an ever growing number of transactions as the quantity of junk emails rise. Providers MUST be held _directly_ accountable. The financial debacle occurred when lenders avoided accountability by securitizing their service. Avoidance of accountability provides evidence of regulation failure. While service providers may advocate various schemes to avoid accountability, such schemes are doomed. When they create innocent victims, they are evil. -Doug From dotis@mail-abuse.org Thu Jun 18 16:28:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5743A6827 for ; Thu, 18 Jun 2009 16:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osM3hkztIrnB for ; Thu, 18 Jun 2009 16:28:23 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 712F53A6826 for ; Thu, 18 Jun 2009 16:28:23 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 53618A94439 for ; Thu, 18 Jun 2009 23:28:36 +0000 (UTC) Message-Id: <35EDB426-2A98-4CC0-AB99-F382D9BDE974@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <20090618214221.9359.qmail@simone.iecc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 16:28:35 -0700 References: <20090618214221.9359.qmail@simone.iecc.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 23:28:24 -0000 On Jun 18, 2009, at 2:42 PM, John Levine wrote: > > The problems were technical, putting records other than PTR in the > rDNS zone. That's why Dave and I came up with CSV. Resolution failures while attempting to obtain a reverse DNS record consumes a fair amount of server resources due to the high levels of abuse. -Doug From mouse@Sparkle.Rodents-Montreal.ORG Thu Jun 18 18:49:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF3C3A67E6 for ; Thu, 18 Jun 2009 18:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.819 X-Spam-Level: X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sWpWd7g49ad for ; Thu, 18 Jun 2009 18:49:51 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 6FD2B3A67D7 for ; Thu, 18 Jun 2009 18:49:51 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA06902; Thu, 18 Jun 2009 21:49:43 -0400 (EDT) From: der Mouse Message-Id: <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 18 Jun 2009 21:29:09 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 01:49:52 -0000 >>>> (Actually, it has been tried in a limited way; there are pieces of >>>> the net that _do_ push responsibility to the end user. Oddly >>>> enough, they are basically nonexistent as far as abuse emitters >>>> go; what evidence I see indicates that it _does_ work.) >>> Can you provide some specifics? >> I worked for McGill [...] > This control is "out-of-band" from the abused protocol, and not the > result of all recipients of the protocol resolving possible > identities of each of university users. Both true. So? Responsibility, in the sense of accountability for (potential) abuse, is a meatspace thing, not amentable to being part of a network protocol, so at least _some_ of this must be done out-of-band with respect to the protocol. > Schemes that pass accountability onto what might be feckless domain > owners are inherently evil. I disagree, _provided_ accountability is actually passed on. What you appear to be thinking of is not accountability but mere identification (albeit moderately strong identification). That there is no real accountability is the major fundamental problem I see with today's Internet: domain holders are not accountable to their registrar or, in most cases, TLD admins for what they do with their domains; address space assignees are not accountable to their RIRs for what they do with their address space (except for the most trivial adminstrative aspects, such as how thorougly they're using the space assigned, and even that not very much); email address holders on the top few webmail systems are not held accountable by the webmail provider for how they use their accounts. Schemes that pass accountability on would be good. So far, I haven't seen any; the most I've seen is schemes that provide strong enough authentication to make it possible to construct systems that pass accountability on. Nobody ever seems to take the additional step of actually doing so. (Well, except on a trivial scale, such as my personal blocking of Yahoo, imposing a penalty for - ie, holding them to account for - the abuses they don't rein in.) > Providers MUST be held _directly_ accountable. Right. But until this is fixed at the top, I see little hope it will happen in the lower levels, except sporadically. (The places that do do it are exceptional, and, in the cases where I'm in a position to know why they do it, they do it not because they are held accountable by whoever assigned the resources to them but because they are ethical enough to feel a compulsion to do what's right even when they're _not_ overtly held accountable. While this mindset is common enough for us to have words for it, it is not nearly common enough to save the net from the disasters that governmental disconnect between authority and responsibility leads to.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From asrg3@billmail.scconsult.com Thu Jun 18 19:43:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152DB3A67A1 for ; Thu, 18 Jun 2009 19:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnRNBqSgcbNs for ; Thu, 18 Jun 2009 19:43:24 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id C16E73A6765 for ; Thu, 18 Jun 2009 19:43:23 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 1984F8D73DD for ; Thu, 18 Jun 2009 22:43:34 -0400 (EDT) Message-ID: <4A3AFB54.9020909@billmail.scconsult.com> Date: Thu, 18 Jun 2009 22:43:32 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> In-Reply-To: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 02:43:25 -0000 Franck Martin wrote, On 6/17/09 1:27 AM: > Sure, it is the the be strict in what you send, lenient in what you > receive. Yes, and with all due respect to Jon Postel, that principle is better suited to the Internet of the 1980's than it is to the Internet today. When there were a small number of ultimate authorities who put a de facto ceiling on leniency and the net was treated as a carefully watched experiment rather than as a production utility, > If we don't specify some RFC/BCP to specify how SMTP over IPv6 should be > negotiated, then no one will follow. > > We could say something like all emails on IPv6 must have a DKIM > signature, have RDNS helo, etc... as there is not much of an > implementation with IPv6, there is a chance for these practices to be > adopted from day one... As John pointed out, "Day One" is in the past and the IETF is hostile *as a matter of principle* to defining application layers differently for IPv6. I don't think that principle is wrong. Also, I can't think of many examples of RFC's successfully performing the role you describe of leading a significant change in practice rather than describing what is already widely being done to good effect. Put more directly: if you want something to end up as de facto mandatory and have a chance of ending up in an RFC, you have to start by getting it enforced by many working production systems. > ----- Original Message ----- > From: "Bill Cole" > To: "Anti-Spam Research Group - IRTF" > Sent: Tuesday, 16 June, 2009 10:14:02 PM GMT +01:00 > Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: [Asrg] What are the IPs that sends mail for a domain? > > Franck Martin wrote, On 6/16/09 11:33 PM: >> Knowing that mail servers are not deployed on IPv6, what would it take >> to make all these requirements mandatory for IPv6 and start with a >> better infrastructure than on IPv4? > > How do you make anything mandatory on the net? > > RFC 821 is one of a handful of Internet Standards, and it is violated > routinely by spammers and non-spammers for no better reason than that > they never bothered to read it. That is possible because the major MTA's > are functional when misconfigured (e.g. with a bogus name for EHLO/HELO > use) and by default tolerate clients which violate standards. > > The only way anything can be functionally mandatory for email transport > is if major MTA's will not work unless configured to comply and by > default will not interoperate with clients that do not comply. RFC's are > great, but they do not enforce themselves. If the big freemail providers > and sites running Sendmail, Exchange, and Postfix generally accept mail > from non-compliant clients, there will be a lot of non-compliant clients. > To make good behavior mandatory, bad behavior has to break with enough > frequency that it's easier to comply than negotiate exemptions. > > _______________________________________________ Asrg mailing list > Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From vesely@tana.it Thu Jun 18 23:41:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E699E3A682B for ; Thu, 18 Jun 2009 23:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NwmKp-iMA4O for ; Thu, 18 Jun 2009 23:41:37 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id ECAC13A6810 for ; Thu, 18 Jun 2009 23:41:36 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 19 Jun 2009 08:41:43 +0200 id 00000000005DC030.000000004A3B3328.00001D75 Message-ID: <4A3B3335.6040507@tana.it> Date: Fri, 19 Jun 2009 08:41:57 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 06:41:38 -0000 der Mouse wrote: > Responsibility, in the sense of accountability for (potential) abuse, > is a meatspace thing, not amentable to being part of a network > protocol, so at least _some_ of this must be done out-of-band with > respect to the protocol. On thefreedictionary I read Synonyms: responsible, answerable, liable, accountable, amenable These adjectives share the meaning obliged to answer, as for one's actions, to an authority that may impose a penalty for failure. Because the IETF cannot even enforce protocol compliance, addressing responsibility implies identifying an authority that has the power of imposing some kind of penalty. >> Providers MUST be held _directly_ accountable. > > Right. But until this is fixed at the top, I see little hope it will > happen in the lower levels, except sporadically. (The places that do > do it are exceptional, and, in the cases where I'm in a position to > know why they do it, they do it not because they are held accountable > by whoever assigned the resources to them but because they are ethical > enough to feel a compulsion to do what's right even when they're _not_ > overtly held accountable. While this mindset is common enough for us > to have words for it, it is not nearly common enough to save the net > from the disasters that governmental disconnect between authority and > responsibility leads to.) I think we can safely withdraw the naive picture where carriers act as authorities, and forget about the possibility that anything will be eventually "fixed at the top", except for possible devout beliefs. On this Earth, ethical mindsets are still powerful intellectual tools that bring visions and may allow to plan for decades. Although such planning usually results in optimization of revenues in the long run, uncertainty about the future wreaks those greedy and short-sighted behaviors that currently are the norm. To cope with that, protocols need to introduce ad-hoc authorities whenever responsibility is required. For mail, those may involve DNSBLs, CAs, VBR vouchers, and similar kinds of independent organizations. We are already relying on them, unofficially. For increased cooperation, we better make that explicit. From iane@sussex.ac.uk Fri Jun 19 01:19:11 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76E93A6906 for ; Fri, 19 Jun 2009 01:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Euq5blS4AaBI for ; Fri, 19 Jun 2009 01:19:10 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id AFD353A67F0 for ; Fri, 19 Jun 2009 01:19:10 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54739) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLH8I2-000981-QF for asrg@irtf.org; Fri, 19 Jun 2009 09:20:26 +0100 Date: Fri, 19 Jun 2009 09:19:22 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: asrg@irtf.org Message-ID: <73B9CA3D486A5AE87C18AD17@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A3AFB54.9020909@billmail.scconsult.com> References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> <4A3AFB54.9020909@billmail.scconsult.com> Originator-Info: login-token=Mulberry:01ZwwLbNBtedGoeV/O0zLagX7fzYQsxsoy3Hc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:19:11 -0000 --On 18 June 2009 22:43:32 -0400 Bill Cole wrote: > > I don't think that principle is wrong. Also, I can't think of many > examples of RFC's successfully performing the role you describe of > leading a significant change in practice rather than describing what is > already widely being done to good effect. Which is why I said it has to be done the other way around. Some organisation with a significant email user base needs to take a lead on this. It could be a large ISP, a large webmail provider, a government, or some other body. It has to be done before the situation gets out of hand, though. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Fri Jun 19 01:52:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB8C3A6B16 for ; Fri, 19 Jun 2009 01:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l01KGzgakZfD for ; Fri, 19 Jun 2009 01:52:08 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A0D103A67F0 for ; Fri, 19 Jun 2009 01:52:08 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56176) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLHA0X-000J39-4R for asrg@irtf.org; Fri, 19 Jun 2009 09:53:21 +0100 Date: Fri, 19 Jun 2009 09:52:16 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <543E228707C23A181637F512@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> Originator-Info: login-token=Mulberry:01wYzFqirtMw8C+RkMLbI0ATgdJwTmBCSyNvc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:52:09 -0000 --On 18 June 2009 15:19:24 -0400 der Mouse =20 wrote: >> Have you heard of SPF? > > Yes. It flopped, no? If it had been widely adopted, I might have to > decide whether I think it constitutes "pushing responsibility to the > edge". But I don't. > No, it hasn't flopped. It just hasn't reached critical mass yet. has some interesting stuff, including=20 reports by Microsoft of their experience of SenderID, from Google of their=20 positive experience with SPF and DKIM. These surveys show the rate of growth of SPF record publication: 2005 - not measured 2006 - 6% of 1,756,827 zones with at least one working nameserver published = SPF records 2007 - 12.6% of 2,053,150 '' 2008 - 16.72% of 1,000,000 '' Google's conclusion: "Reputation based upon the authenticated = sender=E2=80=99s=20 domain works well for us. Spammers are easily identi=EF=AC=81ed, as are = good=20 senders. Only a few senders end up in the grey area in between, and for=20 these we still have the traditional statistical filtering methods for=20 classification. It is not without a few problems though, but we think they=20 are small enough that they can be worked out eventually. We think=20 reputation systems can work well for others too, and we hope to see more=20 senders authenticating and observing good sending practices because of it." They're referring to a combination of SPF (good for early decisions, based=20 on recipient preferences) and DKIM (protects forwarded email). --=20 Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Fri Jun 19 01:55:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6783A68F8 for ; Fri, 19 Jun 2009 01:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+1WzWyT6zZQ for ; Fri, 19 Jun 2009 01:55:00 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 293233A67F0 for ; Fri, 19 Jun 2009 01:55:00 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56260) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLHA5T-000JVO-2M for asrg@irtf.org; Fri, 19 Jun 2009 09:56:17 +0100 Date: Fri, 19 Jun 2009 09:55:12 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3B3335.6040507@tana.it> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3B3335.6040507@tana.it> Originator-Info: login-token=Mulberry:01iBKVzfFzAzLJf+kv9Dj7hwhA7oq2J+s4/X0=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:55:01 -0000 --On 19 June 2009 08:41:57 +0200 Alessandro Vesely wrote: > der Mouse wrote: >> Responsibility, in the sense of accountability for (potential) abuse, >> is a meatspace thing, not amentable to being part of a network >> protocol, so at least _some_ of this must be done out-of-band with >> respect to the protocol. > > On thefreedictionary I read > Synonyms: responsible, answerable, liable, accountable, amenable > These adjectives share the meaning obliged to answer, as for one's > actions, to an authority that may impose a penalty for failure. > > Because the IETF cannot even enforce protocol compliance, addressing > responsibility implies identifying an authority that has the power of > imposing some kind of penalty. It's our respective governments, and such international law as they agree to. As an internet community, we must work towards forcing people to authenticate senders - by making it harder and harder for unauthenticated mail to get delivered. Once we know who's sending the email, they can be held to account by (a) reputation services, and (b) the law. >>> Providers MUST be held _directly_ accountable. >> >> Right. But until this is fixed at the top, I see little hope it will >> happen in the lower levels, except sporadically. (The places that do >> do it are exceptional, and, in the cases where I'm in a position to >> know why they do it, they do it not because they are held accountable >> by whoever assigned the resources to them but because they are ethical >> enough to feel a compulsion to do what's right even when they're _not_ >> overtly held accountable. While this mindset is common enough for us >> to have words for it, it is not nearly common enough to save the net >> from the disasters that governmental disconnect between authority and >> responsibility leads to.) > > I think we can safely withdraw the naive picture where carriers act as > authorities, and forget about the possibility that anything will be > eventually "fixed at the top", except for possible devout beliefs. On > this Earth, ethical mindsets are still powerful intellectual tools that > bring visions and may allow to plan for decades. Although such planning > usually results in optimization of revenues in the long run, uncertainty > about the future wreaks those greedy and short-sighted behaviors that > currently are the norm. > > To cope with that, protocols need to introduce ad-hoc authorities > whenever responsibility is required. For mail, those may involve DNSBLs, > CAs, VBR vouchers, and similar kinds of independent organizations. We are > already relying on them, unofficially. For increased cooperation, we > better make that explicit. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From johnl@iecc.com Fri Jun 19 02:43:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D09B3A6A81 for ; Fri, 19 Jun 2009 02:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMyuuvlyqw2z for ; Fri, 19 Jun 2009 02:43:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 286083A6890 for ; Fri, 19 Jun 2009 02:43:15 -0700 (PDT) Received: (qmail 41105 invoked from network); 19 Jun 2009 09:43:27 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Jun 2009 09:43:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=YEcsUhgAujlLJoMmUc8tqb2lLGp8hRMmz8xT8kqicfQ=; b=jPBa/V7MkE823MQ6LJ3TrpHB5riPMbKgLUTJp7hTZwoz+8qwlBRyFk2ivuwjDVFNgvNN5ILlejw4D/cM/eUatql3ZFlS3oX0ve+2kAb9tFdFNHa1yI32IjM/l5HoHnDeHDokP2B94zKFVrtJ8pqonqPMh6XCFuZWvFB7TaZpid0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=YEcsUhgAujlLJoMmUc8tqb2lLGp8hRMmz8xT8kqicfQ=; b=SvGDeJWPV9A5HSQaZ8uXgDe9yvZxKsp4m01JBXE2bmAdX2tbSC8EBVRxbrM3Hi2ZQ9TfUaTjkYRWAX1yCGHuND2i7/eealO6xNTA8JhEAXTL7tkwf67l1N+vFXSNxw/U24XRPWdDCqzVRPF+r0ZXO9lDTak1/+dbGMjcjke9Goc= Date: 19 Jun 2009 09:43:26 -0000 Message-ID: <20090619094326.2370.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <200906182200.SAA05569@Sparkle.Rodents-Montreal.ORG> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 09:43:18 -0000 >Offhand, I don't see anything there that explains what's wrong with >putting records other than PTR under an rDNS zone. Certainly _some_ >non-PTR record types cause no problems, such as CNAME and zone cut >administrative records like SOA and NS. In short, I don't see what's >wrong with XM from a technical standpoint. What am I missing? As I recall, it was about systems that "know" that there'll never be anything but PTR, zone cuts, and maybe CNAME in the rDNS. In theory it could be fixed, but as we know the difference betweeen theory and practice is greater in practice than it is in theory. R's, John From johnl@iecc.com Fri Jun 19 03:05:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8F53A6B8F for ; Fri, 19 Jun 2009 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XHXs5yPgSsz for ; Fri, 19 Jun 2009 03:05:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 2D8813A6AD1 for ; Fri, 19 Jun 2009 03:05:52 -0700 (PDT) Received: (qmail 61844 invoked from network); 19 Jun 2009 10:06:04 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Jun 2009 10:06:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=HoIQlJM1x0ZxsjUH9xHC73teQvRlHmWGNS8Q23D9hsg=; b=H7RTIPUTF3hAXQKJaHRuX4BYgDlH9pPPN9n28zilYXzt5xsoI/wueuTKkfwLDE7mrFBY0jFcyzXGb0TgdE/nKXqFbrPqUJ5s41zIC0Fpvz5ctq4cVtV88pmhBTkGpnLzDJt3bCTObiKaNnhDuwowiBmhw08Hvp2grwp4jUYV9ok= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=HoIQlJM1x0ZxsjUH9xHC73teQvRlHmWGNS8Q23D9hsg=; b=U0ZZrrhZLhJw5owHglvmyw+OP+hqtE3tiOq2W1vNAxs8e5v+TG0DZk+H0kgFvJgZDyUwwr0FpDJ2R6X2D3SNxVC5Vxjrxv2a/ioQHk8EZwO2j225OnpKtCbIBwjw93HGsK1jTHzWTZxLXaTa8kkZzJmKPr2UUUtcDIBtOg98X00= Date: 19 Jun 2009 10:06:04 -0000 Message-ID: <20090619100604.2572.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A3B3335.6040507@tana.it> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: [Asrg] Proposed corollary to Godwin's law X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 10:05:53 -0000 >On thefreedictionary I read > Synonyms: responsible, answerable, liable, accountable, amenable > These adjectives share the meaning obliged to answer, as for one's > actions, to an authority that may impose a penalty for failure. I think that as soon as you start quoting the dictionary, you've lost the argument. In any technical field, one needs jargon as a shorthand to refer to agreed concepts. Some jargon words are made up (byte), but most are normal words used in new ways (parser). When you start quoting the dictionary, you're arguing that some word has only its conventional meaning, which is generally not true for any word used in a technical context. Words like responsible, accredit, certify, are evolving into jargon, but we haven't yet come to consensus on what if any jargon meaning they have. The dictionary doesn't help, so leave it out of this discussion, please. R's, John From vesely@tana.it Fri Jun 19 03:54:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA393A6B49 for ; Fri, 19 Jun 2009 03:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiz6DvdgUNqk for ; Fri, 19 Jun 2009 03:54:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 0406C3A6A05 for ; Fri, 19 Jun 2009 03:54:08 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 19 Jun 2009 12:54:17 +0200 id 00000000005DC030.000000004A3B6E59.00003984 Message-ID: <4A3B6E59.5010002@tana.it> Date: Fri, 19 Jun 2009 12:54:17 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090617175332.5169.qmail@simone.iecc.com> In-Reply-To: <20090617175332.5169.qmail@simone.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 10:54:10 -0000 John Levine wrote: >>Isn't the FQDN for a host the host name "dot" the domain name? > > The FQDN for a host is the host's FQDN. As we've all noted, there's > lots of heuristics to guess domain names, none of which work. What about the other way around: given a domain and an IP address, can we say whether the IP address "is a member of" the domain? Vhlo mentions the following three ways to determine that, without apparently resorting to heuristics. I'm wondering how sound it is to rely on those, or similar, techniques. * rDNS returns a name whose right part matches the domain name, * an MX record for the domain mentions a host with the given IP, * the IP address passes the SPF check for that domain. From David.Wilson@isode.com Fri Jun 19 04:14:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DC63A69B9 for ; Fri, 19 Jun 2009 04:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi3b5P5RKdBI for ; Fri, 19 Jun 2009 04:14:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 236FD3A6A64 for ; Fri, 19 Jun 2009 04:14:08 -0700 (PDT) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Fri, 19 Jun 2009 12:14:20 +0100 From: David Wilson To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3B6E59.5010002@tana.it> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> Organization: Isode Limited Date: Fri, 19 Jun 2009 12:14:20 +0100 Message-Id: <1245410060.2952.21.camel@tardis.isode.net> X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 11:14:09 -0000 On Fri, 2009-06-19 at 12:54 +0200, Alessandro Vesely wrote: > > The FQDN for a host is the host's FQDN. As we've all noted, there's > > lots of heuristics to guess domain names, none of which work. > > What about the other way around: given a domain and an IP address, can > we say whether the IP address "is a member of" the domain? I would ask: what do you mean by 'domain' in this context? (The term domain is probably one of the most over-used terms.) In the context of email addresses, the domain is the part of the address to the right of the '@'. I'm not sure if there is a definition for 'domain' as it applies to hosts and their domain names (fully or partly qualified). There is a local (to a resolver) definition for searching which can convert a PQDN to a FQDN, but that is not global data. There is, of course, the zone in which the FQDN is defined for use in the DNS. regards David From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 19 05:33:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5A43A6879 for ; Fri, 19 Jun 2009 05:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.826 X-Spam-Level: X-Spam-Status: No, score=-9.826 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvydgBdVOYcC for ; Fri, 19 Jun 2009 05:33:51 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 4FB3A3A6800 for ; Fri, 19 Jun 2009 05:33:51 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA16882; Fri, 19 Jun 2009 08:33:48 -0400 (EDT) From: der Mouse Message-Id: <200906191233.IAA16882@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 19 Jun 2009 08:17:25 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3B6E59.5010002@tana.it> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:33:52 -0000 >> The FQDN for a host is the host's FQDN. As we've all noted, there's >> lots of heuristics to guess domain names, none of which work. > What about the other way around: given a domain and an IP address, > can we say whether the IP address "is a member of" the domain? We can. We can also say the IP address and the domain live on the same shelf in the supermarket, too; I'm not convinced either is a more meaningful or useful statement than the other. > Vhlo mentions the following three ways to determine that, without > apparently resorting to heuristics. I'm wondering how sound it is to > rely on those, or similar, techniques. If any of them results in a definition of "member of" that turns out to be useful for whatever purpose you have in mind, sure. I'm not sure any of them does, but I'm also unclear on why you'd want this sort of association between addresses and domains, so that doesn't mean much. > * rDNS returns a name whose right part matches the domain name, > * an MX record for the domain mentions a host with the given IP, > * the IP address passes the SPF check for that domain. One that's based on something designed for mail flowing to the domain; one ditto for mail flowing from the domain; one that's based on something not designed for mail at all. Offhand, I'd guess that which one is most appropriate depends on whether you're concerned with mail flowing to the domain, mail flowing from the domain, or something other than mail. The things you list might be "without apparently resorting to heuristics", and in a sense that's true, in that each one is well-defined and has a mechanically testable definition. But that doesn't keep them from being heuristics, depending on what you're using them for. Using MX records for anything other than determining what host to connect to to deliver mail is, at best, a heuristic. As is each of the others, when used for anything other than its respective purpose. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 19 05:40:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1953A68B6 for ; Fri, 19 Jun 2009 05:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.833 X-Spam-Level: X-Spam-Status: No, score=-9.833 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF7fJep-BC9n for ; Fri, 19 Jun 2009 05:40:15 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 48A5E3A689B for ; Fri, 19 Jun 2009 05:40:15 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA16959; Fri, 19 Jun 2009 08:40:28 -0400 (EDT) From: der Mouse Message-Id: <200906191240.IAA16959@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 19 Jun 2009 08:36:47 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090619094326.2370.qmail@simone.iecc.com> References: <20090619094326.2370.qmail@simone.iecc.com> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:40:16 -0000 >> In short, I don't see what's wrong with XM from a technical >> standpoint. What am I missing? > As I recall, it was about systems that "know" that there'll never be > anything but PTR, zone cuts, and maybe CNAME in the rDNS. But why does that make it useless for people whose systems _don't_ make stupid assumptions like that? Would it be such a bad thing to need a non-broken DNS server to take advantage of a new feature? Or am I still missing something? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From jdfalk-lists@cybernothing.org Fri Jun 19 10:24:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AC43A6837 for ; Fri, 19 Jun 2009 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koXPTvaYriVe for ; Fri, 19 Jun 2009 10:24:05 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 76C3A3A68D9 for ; Fri, 19 Jun 2009 10:23:37 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n5JHNlo9022471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Jun 2009 11:23:49 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n5JHNlo9022471 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1245432229; bh=9NGVcDNYQO0h++22Nn6aXEbYEHtSUkn1AX4k8ReE C7o=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=P/zf9iTRUTd0 h3PrHA8nfaOUV0hQDSFKmjU5vVg/FIHlgQDcQRJjpHtqaOmsSVaTCPdV5rAwMt3sgu8 5q0m1+DU8hpgun9TzZm2fEFuUENYkVGrZHvdxx9nx+MzSimzOh305UmjIwMe5KvlmRK ivIl8MF/xGcBsYaMpYxng/ypI= Message-ID: <4A3BC99E.8000008@cybernothing.org> Date: Fri, 19 Jun 2009 11:23:42 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> <4A3AFB54.9020909@billmail.scconsult.com> <73B9CA3D486A5AE87C18AD17@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <73B9CA3D486A5AE87C18AD17@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:24:07 -0000 Ian Eiloart wrote: > Which is why I said it has to be done the other way around. Some > organisation with a significant email user base needs to take a lead on > this. It could be a large ISP, a large webmail provider, a government, > or some other body. It has to be done before the situation gets out of > hand, though. If the ASRG were to publish some research showing that this is a good idea, it'd go a long way towards convincing one of those organizations you mentioned to consider implementing it. -- J.D. Falk From rsk@gsp.org Fri Jun 19 10:54:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37FD3A6A61 for ; Fri, 19 Jun 2009 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyw9zGoptGlH for ; Fri, 19 Jun 2009 10:54:11 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 037A13A6A58 for ; Fri, 19 Jun 2009 10:54:10 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5JHsMRn015697 for ; Fri, 19 Jun 2009 13:54:23 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5JHo1Ft009832 for ; Fri, 19 Jun 2009 13:50:02 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5JHsGuo021689 for ; Fri, 19 Jun 2009 13:54:16 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5JHsGvg021688 for asrg@irtf.org; Fri, 19 Jun 2009 13:54:16 -0400 Date: Fri, 19 Jun 2009 13:54:16 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090619175416.GA21653@gsp.org> References: <20090618214221.9359.qmail@simone.iecc.com> <200906182200.SAA05569@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906182200.SAA05569@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:54:12 -0000 On Thu, Jun 18, 2009 at 05:57:03PM -0400, der Mouse wrote: > > The problems were technical, putting records other than PTR in the > > rDNS zone. That's why Dave and I came up with CSV. > > > Pretty please, read http://www.mipassoc.org/csv/ if you want to > > continue this discussion. > > Offhand, I don't see anything there that explains what's wrong with > putting records other than PTR under an rDNS zone. Certainly _some_ > non-PTR record types cause no problems, such as CNAME and zone cut > administrative records like SOA and NS. In short, I don't see what's > wrong with XM from a technical standpoint. What am I missing? Let me see if I can find the archives of that discussion and produce a synopsis. (I don't want to misrepresent what John and/or Dave said about it at the time.) Meanwhile, let me say something about the intent -- as I had it in mind when I brought it up. I did so at the time that we were being increasingly faced with zombie-originated spam, and were looking for ways to make it stop, since clearly the irresponsible network operators hosting all those zombies didn't treat it as an emergency requiring a whatever-it-takes committment. (And most of them still don't, and yet have the audacity to whine when they find their entire networks blacklisted out of exasperation that even given YEARS to solve this urgent problem...they still haven't.) Anyway, the point was not to make any assertion about who might be sending mail or what domains it might be from or what might be in it: just "this host sends mail or it doesn't". Leaving XM=0 for acres and acres of network space and checking for it on MX's would have the effect of stopping zombie-direct-to-MX spam. Of course it does nothing for zombie-relayed-through-local-mail-system spam and nothing for all the other nastiness zombies do: it was intended as a band-aid, no more. Now...were I to advance this today (which I probably wouldn't given that CSV is around) I'd suggest that it be done with forward DNS, not reverse, and that it be checked IFF matching forward and reverse DNS exist. (Because if either doesn't exist or they don't match, that's enough to reject on already.) Anyway, let me go fish for the discussion-at-the-time and see if I can't explain why my idea wasn't and probably still isn't a very good one. ---Rsk From dotis@mail-abuse.org Fri Jun 19 11:30:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E423A6ACB for ; Fri, 19 Jun 2009 11:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8xbKY4DlEQJ for ; Fri, 19 Jun 2009 11:30:02 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 1CE243A6ACA for ; Fri, 19 Jun 2009 11:30:02 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 54CD0A94439 for ; Fri, 19 Jun 2009 18:30:13 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 11:30:13 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 18:30:03 -0000 On Jun 18, 2009, at 6:29 PM, der Mouse wrote: >>> I worked for McGill [...] >> >> This control is "out-of-band" from the abused protocol, and not the >> result of all recipients of the protocol resolving possible >> identities of each of university users. > > Both true. So? SMTP is heavily abused, and soon IPv6 is about to become a necessity. To remain practical, connectivity must be based upon _immediate_ and _stable_ evidence of legitimate email operation, and not upon any number of authorization transactions. Each additional transaction to support an authorization scheme will be multiplied by the typical number of attempts made by abusive senders. This means providers need to exclude problematic users, and not become a task pushed toward recipients. Such pushing is not practical and often leads to unfortunate mistakes. > Responsibility, in the sense of accountability for (potential) > abuse, is a meatspace thing, not amentable to being part of a > network protocol, so at least _some_ of this must be done out-of- > band with respect to the protocol. IMHO, 99% of exclusionary practices must be handled out-of-band for SMTP. >> Schemes that pass accountability onto what might be feckless domain >> owners are inherently evil. > > I disagree, _provided_ accountability is actually passed on. The fact that a trusting and naive user had their domain authorize a provider just to have their email accepted, does not mean other messages emitted might not be mistaken as also belonging to that user's domain. Should providers check for SPF or Sender-ID compliance? How many SLA include this requirement? When the "passing- on" is based upon receptions at spam traps, acceptance reliance based on "authorization" is likely to downgrade acceptance of the domain, especially when A-R headers exclude the IP address of the provider. Will providers really care the wrong entity had been blamed? > What you appear to be thinking of is not accountability but mere > identification (albeit moderately strong identification). Moderately strong? Without knowing the IP address of the provider, it would be extremely foolish to conclude any level of identification assurance, especially "moderately strong". > [...] email address holders on the top few webmail systems are not > held accountable by the webmail provider for how they use their > accounts. Exactly. > Schemes that pass accountability on would be good. CSV would be a good starting point. >> Providers MUST be held _directly_ accountable. > > Right. But until this is fixed at the top, I see little hope it > will happen in the lower levels, except sporadically. Fixing this problem is likely to become an imperative. SPF is worse than wrong. It does not offer a safe form of identification, as wrongly advertised, and puts DNS and SMTP at risk. Those advocating acceptance based on just the DKIM domain clearly expect to combine valid signature with SPF authorization passing. This is not how the DKIM/SPF combination has been being advertised to work together. Email is almost certain to become even more unreliable and more expensive to operate. :^( > (The places that do do it are exceptional, and, in the cases where > I'm in a position to know why they do it, they do it not because > they are held accountable by whoever assigned the resources to them > but because they are ethical enough to feel a compulsion to do > what's right even when they're _not_ overtly held accountable. > While this mindset is common enough for us to have words for it, it > is not nearly common enough to save the net from the disasters that > governmental disconnect between authority and responsibility leads > to.) One might hope they'll do the right thing out of self preservation. Backing schemes that advantage their size only makes problems worse. -Doug From davidnicol@gmail.com Fri Jun 19 19:28:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20AF3A6C26 for ; Fri, 19 Jun 2009 19:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8QDAim7yPAB for ; Fri, 19 Jun 2009 19:28:33 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id D5F103A67DD for ; Fri, 19 Jun 2009 19:28:32 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 2so994055ywt.37 for ; Fri, 19 Jun 2009 19:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=+7gA1OL1Lbp1hpNp75gMm7uEkYB93JXoyRrVAaLKU/8=; b=MHPfpChjg5qC7DFWxzJc6bLUiXNsZgRG9SVomyDN0giCLwckiHilKtxHutyXd9KGNr bAQs/HsYxz54v5nyCjQZBRDE4MBCZFk60RAxYfGaevGwg1CFL3b46NUqOIecytx+hDwU QPUJ94A5yi2sn7BiOKUnrZ12dxDd9MKphMxrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=U8MLVjo2En8EAfq7KgVuXhV1iU8Cd5lKAsG6Nd15Bz8+620JVwHBw18PeL0g5TRJPf k2dL8czGVpgtp35sznjtpZZFS/Dl0LeXH3W3s8jhDLnRkB1kHYMOp4grLR7KyDPuYWiW OKBLo+Yhtz/kuY2cdf33vzVysS5Bx8C4IqBac= MIME-Version: 1.0 Received: by 10.150.152.3 with SMTP id z3mr6991310ybd.112.1245464924635; Fri, 19 Jun 2009 19:28:44 -0700 (PDT) In-Reply-To: <4A329E38.9010609@tana.it> References: <4A329E38.9010609@tana.it> From: David Nicol Date: Fri, 19 Jun 2009 21:28:24 -0500 Message-ID: <934f64a20906191928l334d7529l9108efbc013540fe@mail.gmail.com> To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=000e0cd3f8ac69c250046cbe6672 Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 02:28:33 -0000 --000e0cd3f8ac69c250046cbe6672 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Fri, Jun 12, 2009 at 1:28 PM, Alessandro Vesely wrote: > > > In particular, I'm puzzled as to why I got no answer to my yesterday's > message. Sounds like a classic case of "Warnock's Dilemma." You got no response to a posting on a technical discussion mailing list, and you are searching for an interpretation. Brian Warnock, on one of the perl 6 language archicture discussion mailing lists in 2000, described the situation well when he complained that he could not tell if (A) his proposal was such a stinker that it was beneath reply and everyone was too polite to point this out or (B) his proposal was so brilliant that nothing remained to be said on the subject. -- between myriad opposing forces --000e0cd3f8ac69c250046cbe6672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 12, 2009 at 1:28 PM, Alessan= dro Vesely <vesely@t= ana.it> wrote:

In particular, I'm puzzled as to why I got no answer to my yesterday= 9;s message.


Sounds like a classic case of "= Warnock's Dilemma."

You got no response to a posting on a t= echnical discussion mailing list, and you are searching for an interpretati= on.=C2=A0 Brian Warnock, on one of the perl 6 language archicture discussio= n mailing lists in 2000, described the situation well when he complained th= at he could not tell if (A) his proposal was such a stinker that it was ben= eath reply and everyone was too polite to point this out or (B) his proposa= l was so brilliant that nothing remained to be said on the subject.


--
between myriad opposing forces
--000e0cd3f8ac69c250046cbe6672-- From vesely@tana.it Sat Jun 20 12:20:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE923A6B60 for ; Sat, 20 Jun 2009 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYGeB4-W1WNF for ; Sat, 20 Jun 2009 12:20:08 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 761673A6A41 for ; Sat, 20 Jun 2009 12:20:08 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 20 Jun 2009 21:20:15 +0200 id 00000000005DC031.000000004A3D366F.00001F44 Message-ID: <4A3D366E.2020304@tana.it> Date: Sat, 20 Jun 2009 21:20:14 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 19:20:09 -0000 Douglas Otis wrote: > SMTP is heavily abused, and soon IPv6 is about to become a necessity. > To remain practical, connectivity must be based upon _immediate_ and > _stable_ evidence of legitimate email operation, and not upon any number > of authorization transactions. Each additional transaction to support > an authorization scheme will be multiplied by the typical number of > attempts made by abusive senders. This means providers need to exclude > problematic users, and not become a task pushed toward recipients. Such > pushing is not practical and often leads to unfortunate mistakes. What do you mean by "problematic users"? Providers of residential cables, WiMAX, and similar connections could block or redirect port 25, just like most universities and companies do. They used to do it, as long as they provided mailboxes as a bonus and ISP and ESP were synonyms. Submission port 587 is not yet universally employed, and some customer may not accept to be unable to reach their favorite server's ports 25 or 465. "Blocking port 25 except for a set of servers used for submission" is not something that can be easily defined and maintained by ISPs, IMHO. OTOH, sender identification by domain could also be a way to attribute responsibility. Strictly speaking, it is not necessary to use a domain in order to send as an SMTP client. However, in practice one needs an email address to do any legitimate use of SMTP, and hence a domain is required. >>> Schemes that pass accountability onto what might be feckless domain >>> owners are inherently evil. >> >> I disagree, _provided_ accountability is actually passed on. +1 > The fact that a trusting and naive user had their domain authorize a > provider just to have their email accepted, does not mean other messages > emitted might not be mistaken as also belonging to that user's domain. > Should providers check for SPF or Sender-ID compliance? How many SLA > include this requirement? When the "passing-on" is based upon > receptions at spam traps, acceptance reliance based on "authorization" > is likely to downgrade acceptance of the domain, especially when A-R > headers exclude the IP address of the provider. Will providers really > care the wrong entity had been blamed? You can never know whether that domain's owners are really so foolish to trust a criminal provider, rather than participating accessories. Assuming their bad faith, one should downgrade acceptance of their domain. >> What you appear to be thinking of is not accountability but mere >> identification (albeit moderately strong identification). > > Moderately strong? Without knowing the IP address of the provider, it > would be extremely foolish to conclude any level of identification > assurance, especially "moderately strong". IMHO, the domain registrants (resulting from whois records) provide an identification that is comparable in strength, but finer in granularity. From franck@avonsys.com Sat Jun 20 14:32:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752A73A6AB4 for ; Sat, 20 Jun 2009 14:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmXOmwDi1yWu for ; Sat, 20 Jun 2009 14:32:51 -0700 (PDT) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id F23963A6B44 for ; Sat, 20 Jun 2009 14:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 5626064F8598 for ; Sun, 21 Jun 2009 09:33:33 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYwELDjLtmB4 for ; Sun, 21 Jun 2009 09:33:27 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 29B0364F8597 for ; Sun, 21 Jun 2009 09:33:27 +1200 (FJT) Date: Sun, 21 Jun 2009 09:33:27 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <15942168.11245533549248.JavaMail.franck@somehost-4.sv2.equinix.net> In-Reply-To: <4A3D366E.2020304@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.191.195.4] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1593_Mac) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 21:32:52 -0000 ----- "Alessandro Vesely" wrote: > Douglas Otis wrote: > > SMTP is heavily abused, and soon IPv6 is about to become a > necessity. > > To remain practical, connectivity must be based upon _immediate_ and > > > _stable_ evidence of legitimate email operation, and not upon any > number > > of authorization transactions. Each additional transaction to > support > > an authorization scheme will be multiplied by the typical number of > > > attempts made by abusive senders. This means providers need to > exclude > > problematic users, and not become a task pushed toward recipients. > Such > > pushing is not practical and often leads to unfortunate mistakes. > > What do you mean by "problematic users"? Providers of residential > cables, WiMAX, and similar connections could block or redirect port > 25, just like most universities and companies do. They used to do it, > > as long as they provided mailboxes as a bonus and ISP and ESP were > synonyms. Submission port 587 is not yet universally employed, and > some customer may not accept to be unable to reach their favorite > server's ports 25 or 465. "Blocking port 25 except for a set of > servers used for submission" is not something that can be easily > defined and maintained by ISPs, IMHO. > yes I'm not sure that blocking port 25 will ever be possible. I think less and less people want their mailbox tied up to an ISP, this is why they get a mailbox on yahoo, google, etc... So these services requires you usualy to connect via port 25 and authenticate, but that means for the ISP to let port 25 open. Blocking port 25 and letting port smtps/465 open to allow users to still submit email is better, but just a temporaray measures until botnet use smtps to submit. The only think I see in this system, is to identify IPs of mail servers via an out of band process. Like a record in the DNS. To avoid DDNS (the ability of the compromised machine to push a record in the DNS), it should be in the Reverse DNS or in a subdomain. Now a receiving MTA would be able to use this filter, either the sending MTA authenticate (MUA) or the sending MTA is recorded as a MTA in the DNS. Now this cannot be enabled overnight, but a spamassassin filter could give a negative score if the sending MTA is DNS recorded. From steve@blighty.com Sat Jun 20 14:47:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8A03A6CF1 for ; Sat, 20 Jun 2009 14:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n28YOXdt898o for ; Sat, 20 Jun 2009 14:47:31 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id DAB833A6801 for ; Sat, 20 Jun 2009 14:47:31 -0700 (PDT) Received: from [192.168.1.64] (75-25-136-172.lightspeed.plalca.sbcglobal.net [75.25.136.172]) by m.wordtothewise.com (Postfix) with ESMTP id 918E580678 for ; Sat, 20 Jun 2009 14:47:31 -0700 (PDT) Message-Id: <5943DAE6-6121-43F3-A152-732C3728EF48@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <15942168.11245533549248.JavaMail.franck@somehost-4.sv2.equinix.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 14:47:43 -0700 References: <15942168.11245533549248.JavaMail.franck@somehost-4.sv2.equinix.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 21:47:32 -0000 On Jun 20, 2009, at 2:33 PM, Franck Martin wrote: > > ----- "Alessandro Vesely" wrote: >> >> What do you mean by "problematic users"? Providers of residential >> cables, WiMAX, and similar connections could block or redirect port >> 25, just like most universities and companies do. They used to do it, >> >> as long as they provided mailboxes as a bonus and ISP and ESP were >> synonyms. Submission port 587 is not yet universally employed, and >> some customer may not accept to be unable to reach their favorite >> server's ports 25 or 465. "Blocking port 25 except for a set of >> servers used for submission" is not something that can be easily >> defined and maintained by ISPs, IMHO. >> > > yes I'm not sure that blocking port 25 will ever be possible. I > think less and less people want their mailbox tied up to an ISP, > this is why they get a mailbox on yahoo, google, etc... So these > services requires you usualy to connect via port 25 and authenticate, Nope, port 587. > but that means for the ISP to let port 25 open. Blocking port 25 and > letting port smtps/465 open to allow users to still submit email is > better, but just a temporaray measures until botnet use smtps to > submit. You're conflating two quite different things here, SMTP submission and SMTP delivery. Blocking port 25 outbound (and ideally, inbound) allows an ISP to prevent their customers from delivering email directly to recipient MXes. It does not prevent their customers from using third-party smarthosts at all, as everyone who is intentionally running a third party smarthost is listening on port 587. Bots using port 587 (not 465, that's mostly obsolete) to submit mail is a wholly different issue. A bot doing that needs credentials to do so (a username and password) and misuse of those credentials will lead to them being revoked. Cheers, Steve From davidnicol@gmail.com Sat Jun 20 16:06:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35873A6831 for ; Sat, 20 Jun 2009 16:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0laByj4S3ck for ; Sat, 20 Jun 2009 16:06:16 -0700 (PDT) Received: from mail-yx0-f198.google.com (mail-yx0-f198.google.com [209.85.210.198]) by core3.amsl.com (Postfix) with ESMTP id CCC903A67B2 for ; Sat, 20 Jun 2009 16:06:15 -0700 (PDT) Received: by yxe36 with SMTP id 36so3566059yxe.15 for ; Sat, 20 Jun 2009 16:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=sf4eo1kMTCC4LVtDDOB74YzZecQzJHfdOi7C3KwZx+w=; b=eGt87cmRO7UlvJqeqeScV/bwnCDfTJYZSk12dfBWMXB8YEExs3h6fIS7/NnydGRcdl qa+E4SSrsjwxTEGqhyZ+rC+z/botkYyGwdp1WI5H9SysBRdCSJFziDCwJEqC9lsfNvyC yFCJU2P31579Kt5b2t5nuIZGKvjdSMH2kd+e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=XYlVpiRLJvm/yg1f8GNArzU9aLZ+wyKfpcDA6D1DCx4++BQoVloMn+RpErfwA3JBYD /lFwHtiwPZNicpkIY05OTLTZXqwAnfz6EHTG/vLevrgQQQ+SgWBiT5+CFvTefZq2Bd8c 3mzWYZObHN6cOjUajPD6ZLLofEsDCUM07NQNE= MIME-Version: 1.0 Received: by 10.150.152.3 with SMTP id z3mr8435101ybd.90.1245539188137; Sat, 20 Jun 2009 16:06:28 -0700 (PDT) In-Reply-To: <4A3D366E.2020304@tana.it> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> From: David Nicol Date: Sat, 20 Jun 2009 18:06:08 -0500 Message-ID: <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 23:06:16 -0000 On Sat, Jun 20, 2009 at 2:20 PM, Alessandro Vesely wrote: > However, in practice one needs an email address to do any legitimate use of > SMTP, and hence a domain is required. There isn't any technical reason why MUA software can't do its own delivery with today's technology. The whole concept of "outbound MTA" seems like a throwback. With the exception of delivery delays, but having a MUA attempt its own delivery and then switch to the smarthost on connection or other temporary failure wouldn't require any inspiration. As if web-service MUAs are going to fade away, which is doubtful. -- "Of course you don't find it puzzling, YOU WROTE IT!" -- Michael G. Schwern From steve@blighty.com Sat Jun 20 16:22:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32383A67F3 for ; Sat, 20 Jun 2009 16:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8tLUbahrLC4 for ; Sat, 20 Jun 2009 16:22:24 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id C83523A67B2 for ; Sat, 20 Jun 2009 16:22:24 -0700 (PDT) Received: from [192.168.1.64] (75-25-136-172.lightspeed.plalca.sbcglobal.net [75.25.136.172]) by m.wordtothewise.com (Postfix) with ESMTP id CC78680871 for ; Sat, 20 Jun 2009 16:22:25 -0700 (PDT) Message-Id: <1C9AD69B-684C-4A1D-8719-F9B0113E5F6D@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 16:22:37 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 23:22:25 -0000 On Jun 20, 2009, at 4:06 PM, David Nicol wrote: > On Sat, Jun 20, 2009 at 2:20 PM, Alessandro Vesely > wrote: >> However, in practice one needs an email address to do any >> legitimate use of >> SMTP, and hence a domain is required. > > There isn't any technical reason why MUA software can't do its own > delivery with today's technology. The whole concept of "outbound MTA" > seems like a throwback. With the exception of delivery delays, but > having a MUA attempt its own delivery and then switch to the smarthost > on connection or other temporary failure wouldn't require any > inspiration. Just a terminology / architecture comment... It'd be perfectly possible to build a mail client that behaved that way (and people have, I think), or setup a system that works in that way using existing components (and many people do). But I'd claim that that mail client is then behaving as both an MUA and an MTA (and probably an MSA too). It's useful to draw a distinction between the architectural roles, even when the roles are performed by the same executable. http://www.bbiw.net/specifications/draft-crocker-email-arch-14.html is worth a read, ideally with a drink close to hand, for lots of terminology discussion. Cheers, Steve From prussell@nd.edu Sat Jun 20 19:36:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8C53A6901 for ; Sat, 20 Jun 2009 19:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2YxKD2ZQjBW for ; Sat, 20 Jun 2009 19:36:45 -0700 (PDT) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id 93C2F3A685B for ; Sat, 20 Jun 2009 19:36:45 -0700 (PDT) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5L2XItI025009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 20 Jun 2009 22:33:19 -0400 Received: from [172.19.226.74] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5L2aqNp023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Jun 2009 22:36:53 -0400 (EDT) Message-ID: <4A3D9CC4.10303@nd.edu> Date: Sat, 20 Jun 2009 22:36:52 -0400 From: Paul Russell User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <15942168.11245533549248.JavaMail.franck@somehost-4.sv2.equinix.net> In-Reply-To: <15942168.11245533549248.JavaMail.franck@somehost-4.sv2.equinix.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Sat, 20 Jun 2009 22:33:19 EDT Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 02:36:46 -0000 On 6/20/2009 17:33, Franck Martin wrote: > yes I'm not sure that blocking port 25 will ever be possible. I think less and > less people want their mailbox tied up to an ISP, this is why they get a > mailbox on yahoo, google, etc... So these services requires you usualy to > connect via port 25 and authenticate, but that means for the ISP to let port > 25 open. Blocking port 25 and letting port smtps/465 open to allow users to > still submit email is better, but just a temporaray measures until botnet use > smtps to submit. Gmail supports secure authenticated message submission via port 587. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame From vesely@tana.it Sat Jun 20 23:10:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DC43A69B6 for ; Sat, 20 Jun 2009 23:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlZzyh8YZEAw for ; Sat, 20 Jun 2009 23:10:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C2D4C3A695B for ; Sat, 20 Jun 2009 23:10:56 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sun, 21 Jun 2009 08:11:10 +0200 id 00000000005DC031.000000004A3DCEFE.000061CC Message-ID: <4A3DCEFE.7060706@tana.it> Date: Sun, 21 Jun 2009 08:11:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> In-Reply-To: <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 06:10:57 -0000 David Nicol wrote: > On Sat, Jun 20, 2009 at 2:20 PM, Alessandro Vesely wrote: >> However, in practice one needs an email address to do any legitimate use of >> SMTP, and hence a domain is required. > > There isn't any technical reason why MUA software can't do its own > delivery with today's technology. The whole concept of "outbound MTA" > seems like a throwback. I'd agree that the reasons why we needed outbound MTAs then, and why we need'em now are completely different. However, I'd still call the current reason "technical"; in facts, its origin is likely related with overcoming the former reason. > With the exception of delivery delays, but > having a MUA attempt its own delivery and then switch to the smarthost > on connection or other temporary failure wouldn't require any > inspiration. (W.r.t. Steve's terminology / architecture comment, I understand "MUA" above as a conceptually personal host, e.g. a laptop running mutt and exim.) Being suspicious about their ESPs, those users may prefer to deliver directly whenever possible. That is the only reason I see for attempting a direct delivery first, and it is a largely suboptimal solution anyway (e.g. it provides no reliable storage for sent messages.) Some people even run MTAs on dynamically assigned IPs. At any rate, they use an email address featuring a domain (that they possibly own.) That is the domain we should use to work out responsibility. > As if web-service MUAs are going to fade away, which is doubtful. They won't go away, but they are fine, since they require proper authentication. They relay via submission servers that possibly run on the same host or LAN. From claudio@telmon.org Sun Jun 21 02:25:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5967C3A69DF for ; Sun, 21 Jun 2009 02:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzQKqDAuJ6dN for ; Sun, 21 Jun 2009 02:25:26 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 989813A67E9 for ; Sun, 21 Jun 2009 02:25:25 -0700 (PDT) Received: from 88-149-251-103.dynamic.ngi.it ([::ffff:88.149.251.103]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.103+GEShw9161o; Sun, 21 Jun 2009 11:25:38 +0200 Message-ID: <4A3DFC91.2090506@telmon.org> Date: Sun, 21 Jun 2009 11:25:37 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: asrg@irtf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 09:25:27 -0000 Dear Sirs, I've developed a proposal for an extension to the SMTP protocol that should provide to address owners the ability to express consent to delivery of messages in their mailboxes. While it is not the Ultimate Solution to the Spam Problem, and strictly speaking it is not even an antispam solution, it could help reducing spam. I already discussed my proposal with some researchers, which judged it positively, but which didn't have a very specific competence. I think that my proposal could be of some interest for the ASRG community, and I'm looking for comments and advise. The paper is in html and pdf at http://www.telmon.org/consent/smtp-consent-1.1.html and http://www.telmon.org/consent/smtp-consent-1.1.pdf The paper is quite long, as I tried to anticipate most of the implementation and deployment issues, but the idea is quite simple and not really new, since it is very similar to "ham passwords". If you just want to see what it's all about, you could just read the "Introduction" and "General overview of the framework" sections, and maybe the "Deployment of the framework" section at the end of the document. Thanks in advance for any comments or suggestions you can provide me. Sincerely, - Claudio Telmon -- Claudio Telmon claudio@telmon.org http://www.telmon.org From dotis@mail-abuse.org Sun Jun 21 23:34:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340E03A6A4C for ; Sun, 21 Jun 2009 23:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LbmC3E5bTQC for ; Sun, 21 Jun 2009 23:34:09 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 326F83A6A28 for ; Sun, 21 Jun 2009 23:34:09 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F2D26A94439 for ; Mon, 22 Jun 2009 06:34:19 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3D366E.2020304@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 21 Jun 2009 23:34:16 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 06:34:10 -0000 On Jun 20, 2009, at 12:20 PM, Alessandro Vesely wrote: > Douglas Otis wrote: >> SMTP is heavily abused, and soon IPv6 is about to become a >> necessity. To remain practical, connectivity must be based upon >> _immediate_ and _stable_ evidence of legitimate email operation, >> and not upon any number of authorization transactions. Each >> additional transaction to support an authorization scheme will be >> multiplied by the typical number of attempts made by abusive >> senders. This means providers need to exclude problematic users, >> and not become a task pushed toward recipients. Such pushing is >> not practical and often leads to unfortunate mistakes. > > What do you mean by "problematic users"? Providers of residential > cables, WiMAX, and similar connections could block or redirect port > 25, just like most universities and companies do. They used to do > it, as long as they provided mailboxes as a bonus and ISP and ESP > were synonyms. Submission port 587 is not yet universally employed, > and some customer may not accept to be unable to reach their > favorite server's ports 25 or 465. "Blocking port 25 except for a > set of servers used for submission" is not something that can be > easily defined and maintained by ISPs, IMHO. Each recipient will likely attempt to accept either none or some amount of public email based upon normal profiles. To remain on the safe size typical profiling, this requires the output issued by bad actors be mitigated in some fashion. This might be done by using rate limiting combined with disabling accounts faster than bad actors can re-subscribe. Funny how little anti-spam efforts concentrate on account setup. Things like Open-ID might help in this area, for example. > OTOH, sender identification by domain could also be a way to > attribute responsibility. Strictly speaking, it is not necessary to > use a domain in order to send as an SMTP client. However, in > practice one needs an email address to do any legitimate use of > SMTP, and hence a domain is required. Technically speaking, a domain is not required for SMTP. CSV was to offer a DNS record type that explicitly declared a host as being an outbound MTA. This would not in itself prevent abuse, but would help to determine which compromised systems might be sending email and resolving which domain is administrating the MTA. SPF does not work well at resolving a domain that should be held accountable for a few reasons- a) risks high and impractical transaction overheads at attempts to indirectly reference the customers of a provider. b) may not qualify any specific IP address for a positive result. c) Mail From or PRA references do not resolve which domain administered the MTA or actually sent the message. d) holds customers of a provider accountable for the provider's stewardship without any solid evidence of their involvement. >>>> Schemes that pass accountability onto what might be feckless >>>> domain owners are inherently evil. >>> >>> I disagree, _provided_ accountability is actually passed on. > > +1 There should be greater concern accountability is correctly applied. >> The fact that a trusting and naive user had their domain authorize >> a provider just to have their email accepted, does not mean other >> messages emitted might not be mistaken as also belonging to that >> user's domain. Should providers check for SPF or Sender-ID >> compliance? How many SLA include this requirement? When the >> "passing-on" is based upon receptions at spam traps, acceptance >> reliance based on "authorization" is likely to downgrade acceptance >> of the domain, especially when A-R headers exclude the IP address >> of the provider. Will providers really care the wrong entity had >> been blamed? > > You can never know whether that domain's owners are really so > foolish to trust a criminal provider, rather than participating > accessories. Assuming their bad faith, one should downgrade > acceptance of their domain. Who said providers need to be criminal for naive users to be harmed by SPF? A recipient may check PRAs, where providers may check Mail- Froms. Once a user's domain reputation is damaged due to receiver error, how can reputations be restored and then protected? When asked in the past, those customers are advised to obtain their own IP address. >>> What you appear to be thinking of is not accountability but mere >>> identification (albeit moderately strong identification). >> Moderately strong? Without knowing the IP address of the provider, >> it would be extremely foolish to conclude any level of >> identification assurance, especially "moderately strong". > > IMHO, the domain registrants (resulting from whois records) provide > an identification that is comparable in strength, but finer in > granularity. It is wrong to hold someone accountable for authorizing a provider once authorization becomes a requisite for acceptance. Users are thereby extorted into assuming risks well beyond their control. Instead, providers should be held accountable by requiring CSV records with a limited number of EHLO host names over time. This approach better defends receiving MTAs from abuse with lower overhead, and better controls DNS related exploits that threaten the entire Internet. -Doug From vesely@tana.it Mon Jun 22 02:29:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF4C3A6A5F for ; Mon, 22 Jun 2009 02:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbQfn4E19Nue for ; Mon, 22 Jun 2009 02:29:01 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 23BA73A6828 for ; Mon, 22 Jun 2009 02:29:00 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 22 Jun 2009 11:29:13 +0200 id 00000000005DC036.000000004A3F4EE9.000016CF Message-ID: <4A3F4EE9.7030105@tana.it> Date: Mon, 22 Jun 2009 11:29:13 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it> <4A37D490.3030900@billmail.scconsult.com> <4A38C1A4.6020504@tana.it> In-Reply-To: <4A38C1A4.6020504@tana.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Soundness of silence X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 09:29:01 -0000 I wrote: > Bill Cole wrote: >> Replace the tutorial on mail filtering fundamentals with a concise >> problem definition and concise explanation of how VHLO provides a >> solution. > > Good point, thanks. Actually, I have expanded that first subsection in > order to make it clear the point on content filtering. I'll look at how > to reduce it. And I did it. The intro seems to me rather clear and smooth, now. Is it really? http://tools.ietf.org/html/draft-vesely-vhlo-04#section-1 From iane@sussex.ac.uk Mon Jun 22 02:57:04 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15F43A680C for ; Mon, 22 Jun 2009 02:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAhTKNjyJa0U for ; Mon, 22 Jun 2009 02:57:03 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 761353A659C for ; Mon, 22 Jun 2009 02:57:02 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52825) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLMX0Y-000E32-OY for asrg@irtf.org; Mon, 22 Jun 2009 10:58:10 +0100 Date: Mon, 22 Jun 2009 10:57:04 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <93C7DCD53D28C50DA30C005D@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A3BC99E.8000008@cybernothing.org> References: <10520166.1991245216397431.JavaMail.franck@somehost-55.sv2.equinix.net> <4A3AFB54.9020909@billmail.scconsult.com> <73B9CA3D486A5AE87C18AD17@lewes.staff.uscs.susx.ac.uk> <4A3BC99E.8000008@cybernothing.org> Originator-Info: login-token=Mulberry:01n2yYwgjNBifg2ewkC5IS4Qs1BeS5HAKSFNc=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 09:57:04 -0000 --On 19 June 2009 11:23:42 -0600 "J.D. Falk" wrote: > Ian Eiloart wrote: > >> Which is why I said it has to be done the other way around. Some >> organisation with a significant email user base needs to take a lead on >> this. It could be a large ISP, a large webmail provider, a government, >> or some other body. It has to be done before the situation gets out of >> hand, though. > > If the ASRG were to publish some research showing that this is a good > idea, it'd go a long way towards convincing one of those organizations > you mentioned to consider implementing it. So, to demonstrate that it's a good idea, we need to show: 1. That there's lots of spam on the Internet, people don't like it, and it costs lots of time and money. 2. The spam is hard to identify, because there's no traceability. People like to whitelist or blacklist sender email address or sender email domains, but they're too easy to spoof because of the lack of traceability. 3. It would be nice to require traceability for new mailers, but it's hard to know which are new. 4. Except that IPv6 mailers are new, or recently deployed. 5. People with recently deployed IPv6 mailers are likely to have the ability to implement traceability. 6. The cost to the community of requiring traceability for IPv6 email servers would be low. 7. The reward would be that a whole class of easily identified new servers would have the traceability required. 8. When deploying IPv6 to customers, ISPs would have to take no special measures to prevent customer machines from emitting spam. They'd be secure(ish) by default. Oh, and we have to figure out what form of traceability we're looking for. Let's start off with this list for a suggestion: 1. Reverse DNS records for the sender's IP address. 2. SPF or DKIM passes for the sender's IP address. 3. Strict checks on EHLO string. And, for an IPv6 hosts receiving email, there must be an MX record. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 22 03:39:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB01528C110 for ; Mon, 22 Jun 2009 03:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tgGiafYUHqN for ; Mon, 22 Jun 2009 03:39:25 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id BAE0A28C0E8 for ; Mon, 22 Jun 2009 03:39:25 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54074) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLMYZW-0004GJ-B6 for asrg@irtf.org; Mon, 22 Jun 2009 11:40:44 +0100 Date: Mon, 22 Jun 2009 11:39:38 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3B6E59.5010002@tana.it> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> Originator-Info: login-token=Mulberry:01SXWuvrLWHCOK4gIgtZu86iExr+3PGKybvuA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:39:26 -0000 --On 19 June 2009 12:54:17 +0200 Alessandro Vesely wrote: > John Levine wrote: >>> Isn't the FQDN for a host the host name "dot" the domain name? >> >> The FQDN for a host is the host's FQDN. As we've all noted, there's >> lots of heuristics to guess domain names, none of which work. > > What about the other way around: given a domain and an IP address, can we > say whether the IP address "is a member of" the domain? "is a member of" isn't a useful description of relationships between IP addresses and domain names. You can say that an IP address "is a member of" a netblock. You can say that a domain name "is a subdomain" of another domain, and could regard that as a "membership" relation. The DNS is used to express relationships between IP addresses and domain names, but there are many types of relationship - like MX records, A records. "is a member of" sounds like it might mean "is owned by" or "is assigned to", but IP addresses are assigned to real world organisations, not domain names. There's no necessary relationship when sending SMTP, unfortunately. You could check whether the IP address and the domain name were assigned to the same organisation, but that often won't be possible. > > Vhlo mentions the following three ways to determine that, without > apparently resorting to heuristics. I'm wondering how sound it is to rely > on those, or similar, techniques. > > * rDNS returns a name whose right part matches the domain name, > * an MX record for the domain mentions a host with the given IP, > * the IP address passes the SPF check for that domain. > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 22 03:40:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E911A3A6A16 for ; Mon, 22 Jun 2009 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxtiGdv9iHAh for ; Mon, 22 Jun 2009 03:40:46 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 1960C3A69B8 for ; Mon, 22 Jun 2009 03:40:46 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54091) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLMZ27-0004TG-2Y for asrg@irtf.org; Mon, 22 Jun 2009 11:42:07 +0100 Date: Mon, 22 Jun 2009 11:41:00 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <69977D6317767832F6388A06@lewes.staff.uscs.susx.ac.uk> In-Reply-To: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> Originator-Info: login-token=Mulberry:01hlcsxe+4mirHxIAn8n35zJ847M9NH+l9+8I=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:40:47 -0000 --On 19 June 2009 11:30:13 -0700 Douglas Otis wrote: > MTP is heavily abused, and soon IPv6 is about to become a necessity. To > remain practical, connectivity must be based upon _immediate_ and > _stable_ evidence of legitimate email operation, and not upon any number > of authorization transactions. Each additional transaction to support an > authorization scheme will be multiplied by the typical number of attempts > made by abusive senders. Except that results can be cached. > This means providers need to exclude > problematic users, and not become a task pushed toward recipients. Such > pushing is not practical and often leads to unfortunate mistakes. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 22 03:45:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852E33A69B8 for ; Mon, 22 Jun 2009 03:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq9fWupj2btD for ; Mon, 22 Jun 2009 03:45:20 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id BA8683A6825 for ; Mon, 22 Jun 2009 03:45:20 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:54166) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLMZ9T-00066Y-IZ for asrg@irtf.org; Mon, 22 Jun 2009 11:46:41 +0100 Date: Mon, 22 Jun 2009 11:45:35 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3D366E.2020304@tana.it> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> Originator-Info: login-token=Mulberry:01jaiRTPYJ/7HOFeWu+c4AHQS/8yCypvDOAhM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:45:21 -0000 --On 20 June 2009 21:20:14 +0200 Alessandro Vesely wrote: > Submission port 587 is not yet universally employed No, but widely enough that we've not had any complaints. It's even the default port used by some MUAs now - like Apple's "Mail.app" and the iPhone. Blocking port 25 will encourage deployment of port 587. In my view, network operators should assume now that email service providers DO provide port 587, unless they have an overwhelming business case to do otherwise. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Mon Jun 22 03:57:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42483A6960 for ; Mon, 22 Jun 2009 03:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PN4fLDPyL1Y for ; Mon, 22 Jun 2009 03:57:52 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 66F023A67F6 for ; Mon, 22 Jun 2009 03:57:52 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 22 Jun 2009 12:58:07 +0200 id 00000000005DC030.000000004A3F63BF.00002435 Message-ID: <4A3F63BE.1030303@tana.it> Date: Mon, 22 Jun 2009 12:58:06 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:57:53 -0000 Douglas Otis wrote: > Each recipient will likely attempt to accept either none or some amount > of public email based upon normal profiles. To remain on the safe size > typical profiling, this requires the output issued by bad actors be > mitigated in some fashion. This might be done by using rate limiting > combined with disabling accounts faster than bad actors can > re-subscribe. Funny how little anti-spam efforts concentrate on account > setup. Things like Open-ID might help in this area, for example. Hm... residential accounts with asymmetric rates already complain about latency. For example, I've been setting a number of extensions to deliver to the Sent folder, so as to allow to save sent mail by Bcc rather than copying, for clients that allow it, in order to save time in case of large attachments. As for forcefully disabling accounts, one needs a legal authority to break a commercial agreement. For some reasons, they tend to move quicker for child porn than spammers. Last time I talked about spam to our postal police, the first thing he said has been "me too". Since we lack police resources for snatches and rapes, I felt arrogant asking them to go after my spammer, and gave up. I don't follow how OpenId would help. >> OTOH, sender identification by domain could also be a way to attribute >> responsibility. Strictly speaking, it is not necessary to use a domain >> in order to send as an SMTP client. However, in practice one needs an >> email address to do any legitimate use of SMTP, and hence a domain is >> required. > > CSV was to offer a DNS record type that explicitly declared a host as being > an outbound MTA. This would not in itself prevent abuse, but would help to > determine which compromised systems might be sending email and resolving > which domain is administrating the MTA. It didn't help retrieving the responsible domain, though. Furthermore, it didn't do ranges, thus making it laborious to deny sending to a bunch of hosts. In addition, CSA spec curiously had a "MAY" for an non-authorized host with a non-ignored target resulting in weight 0. However, _client._smtp.domain-name records authorizing various targets would be almost equivalent to setting SPF, or MX heuristics. (I'll possibly add that to the next vhlo draft.) > SPF does not work well at resolving a domain that should be held > accountable for a few reasons- One reason is that it works the other way around: given the domain, authenticate an IP address as a mail transmitter (thus implicitly authorizing it to send mail). > a) risks high and impractical transaction overheads at attempts to > indirectly reference the customers of a provider. I agree it is more complicated than the average users need. Presumably, the spec is so for being usable in a wider number of cases. 10 lookups, however, seems reasonable to me. > b) may not qualify any specific IP address for a positive result. Yes, especially if not used. > c) Mail From or PRA references do not resolve which domain administered > the MTA or actually sent the message. AFAIK, all discussions eventually reach the conclusion that the receiving server does not know which domain administers the client MTA. FWIW the old ietf-marid-csv-csa asserts that The SMTP [RFC2821] [RFC0821] protocol permits a client to declare its affiliation, by asserting a domain name in the HELO or EHLO announcement. which is wrong. EHLO only allows it to declare its identity. Declaring the affiliation is VHLO's raison d'être. At any rate, forwarding -when MAIL FROM and PRA differ- requires a framework different from SMTP to administer legitimate use of third parties' email addresses. Classic mailing lists (as this one) comply with various privacy laws, but most direct marketing lists and users' .forward files don't. > d) holds customers of a provider accountable for the provider's > stewardship without any solid evidence of their involvement. See below (at Why do you so often mention authorizing a provider?) > Who said providers need to be criminal for naive users to be harmed by > SPF? A recipient may check PRAs, where providers may check Mail-Froms. Formally, SPF only recommends to check MAIL FROM. Any other use of the underlying mechanism is just heuristics. > Once a user's domain reputation is damaged due to receiver error, how > can reputations be restored and then protected? That has nothing to do with SPF. People getting mad about stopping spam will invent _any_ rule. I get a score 1.245 for HOST_EQ_IT in Fred's Header rules, even if the .it ccTLD never had an SPF record. (Concentration camps are further down that road.) > When asked in the past, > those customers are advised to obtain their own IP address. If responsibility were attributed correctly, this wouldn't be needed any more. Of course, if I had an address @spammer, I'd have to share their fate, but my address is my choice. >>> [...] Without knowing the IP address of the provider, >>> it would be extremely foolish to conclude any level of identification >>> assurance, especially "moderately strong". >> >> IMHO, the domain registrants (resulting from whois records) provide an >> identification that is comparable in strength, but finer in granularity. > > It is wrong to hold someone accountable for authorizing a provider once > authorization becomes a requisite for acceptance. Users are thereby > extorted into assuming risks well beyond their control. Why do you so often mention authorizing a provider? ISP and ESP are two different activities, although didn't use to. If I use a vanity address I have to trust an ESP who provides that service and set MX and SPF RRs accordingly. The ESP may or may not be my connection provider. The risk is related with choosing the ESP correctly, so that trust is well put. That trust is not different for users of an existing domain, who don't control the domain, but have to trust its admins. > Instead, providers should be held accountable by requiring CSV records > with a limited number of EHLO host names over time. But the targets of those records need an address too. What's the difference between writing an IP number in an SPF rather than an A RR? > This approach better defends receiving MTAs from abuse with lower > overhead, and better controls DNS related exploits that threaten the > entire Internet. All of them rely on DNS, and some posts in that "DNS over SCTP" thread showed that various people think just of http when they figure out "typical" DNS usage... :-( From mouse@Sparkle.Rodents-Montreal.ORG Mon Jun 22 04:28:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F174D3A6B3E for ; Mon, 22 Jun 2009 04:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.26 X-Spam-Level: X-Spam-Status: No, score=-8.26 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiNVlPBlLsl5 for ; Mon, 22 Jun 2009 04:28:13 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 5C64A3A6DD8 for ; Mon, 22 Jun 2009 04:28:06 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA20457; Mon, 22 Jun 2009 07:28:03 -0400 (EDT) From: der Mouse Message-Id: <200906221128.HAA20457@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 22 Jun 2009 07:20:46 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3F63BE.1030303@tana.it> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <4A3F63BE.1030303@tana.it> Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:28:15 -0000 > As for forcefully disabling accounts, one needs a legal authority to > break a commercial agreement. Maybe that's why ISP/client contracts - at least in my admittedly limited experience - permit the ISP to terminate service for any reason whatever and be liable for, at most, the last billing period's charges: to permit them the latitude to cut off abusers without having to go through the legal system first. (Of course, taking advantage of that frivolously is an excellent way to lose their customer base, and I'm sure they know it.) > For some reasons, they tend to move quicker for child porn than > spammers. Last time I talked about spam to our postal police, the > first thing he said has been "me too". Since we lack police > resources for snatches and rapes, I felt arrogant asking them to go > after my spammer, and gave up. If your legal system does not provide for private right of action against spammers, it needs fixing, and this is exactly why. It also points up part of why depending on meatspace law to deal with net offenses is a bad idea. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From iane@sussex.ac.uk Mon Jun 22 05:01:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBEE3A6B27 for ; Mon, 22 Jun 2009 05:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnfi8+8h66GT for ; Mon, 22 Jun 2009 05:01:18 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 8557D3A69B9 for ; Mon, 22 Jun 2009 05:01:18 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50099) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLN2S5-00065V-CQ for asrg@irtf.org; Mon, 22 Jun 2009 13:02:29 +0100 Date: Mon, 22 Jun 2009 13:01:22 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: Originator-Info: login-token=Mulberry:01dpHGZd/yNMq3/hrH4rfpBjnY3Annv9m36/w=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:01:19 -0000 --On 21 June 2009 09:33:27 +1200 Franck Martin wrote: > > yes I'm not sure that blocking port 25 will ever be possible. I think > less and less people want their mailbox tied up to an ISP, this is why > they get a mailbox on yahoo, google, etc... So these services requires > you usuallyusualy to connect via port 25 and authenticate, but that means for > the ISP to let port 25 open. No, they don't. Both allow you to use port 587, as do AOL and Hotmail telnet smtp.mail.yahoo.com 587 Trying 69.147.102.58... Connected to smtp.plus.mail.fy4.b.yahoo.com. Escape character is '^]'. 220 smtp113.plus.mail.re1.yahoo.com ESMTP quit 221 smtp113.plus.mail.re1.yahoo.com telnet smtp.gmail.com 587 Trying 74.125.79.111... Connected to gmail-smtp-msa.l.google.com. Escape character is '^]'. 220 mx.google.com ESMTP 10sm139741eyd.17 quit 221 2.0.0 closing connection 10sm139741eyd.17 Can anyone find a large commercial ESP that offers authenticated smtp on port 25, but not 587? Please read rfc 4409. Port 465 is still in use to support some clients, but should be discouraged because it's allocated for some other purpose. > Blocking port 25 and letting port smtps/465 > open to allow users to still submit email is better, but just a > temporaray measures until botnet use smtps to submit. Even then, it's still better. Even if you don't get to identify the botnet owner, you get to identify the owner of the compromised host - who also has some responsibility for the spam. And, you're routing the spam through an email service provider who has a contractual relationship with the owner or operator of the compromised host. > The only think I see in this system, is to identify IPs of mail servers > via an out of band process. Like a record in the DNS. To avoid DDNS (the > ability of the compromised machine to push a record in the DNS), it > should be in the Reverse DNS or in a subdomain. > > Now a receiving MTA would be able to use this filter, either the sending > MTA authenticate (MUA) or the sending MTA is recorded as a MTA in the > DNS. Now this cannot be enabled overnight, but a spamassassin filter > could give a negative score if the sending MTA is DNS recorded. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From gep2@terabites.com Mon Jun 22 05:19:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B859928C1BA for ; Mon, 22 Jun 2009 05:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqUokW8NQ9Fn for ; Mon, 22 Jun 2009 05:19:05 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by core3.amsl.com (Postfix) with ESMTP id EFFAC28C159 for ; Mon, 22 Jun 2009 05:18:50 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 8D02BDEAB46 for ; Mon, 22 Jun 2009 12:19:05 +0000 (UTC) X-Session-Marker: 6765703261407465726162697465732E636F6D X-Filterd-Recvd-Size: 9266 Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2009 12:19:04 +0000 (UTC) Message-ID: <4A3F76B8.2030409@terabites.com> Date: Mon, 22 Jun 2009 07:19:04 -0500 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:19:06 -0000 And the circle goes round and round. Periodically, I feel it necessary to point out some of the serious flaws in all of these IP-based "authentication" type schemes. The first one has been pointed out, but perhaps not strongly enough. IT IS STUPID AND COUNTERPRODUCTIVE TO BOUNCE NOTICE OF NON-DELIVERY TO RECOGNIZED SPAM E-MAILS. It can double OR TRIPLE the bandwidth wasted by the original spam, in part because (at least in the case of spam which has been relayed one or more times) it is problematical to know WHO to send the bounce message to. In my personal mailboxes I have (way) more than 50,000 archived bounceback messages to e-mails which I have never sent... just because they have a (forged, and generally invalid) From: address that is supposedly in one of my domains. Since I haven't sent these messages (neither intentionally, nor by irresponsible management of my systems here) there is NOTHING I can do to prevent such messages. Meanwhile, the handling of the (worthless) bounce messages multiply by perhaps several times the bandwidth wasted due to the original spam. Barracuda spam blocking systems are particularly irresponsible by apparently not explaining to their users WHY bouncing spam back to the sender is a Bad Idea, resulting in their (even less clever) users often apparently leaving that option set. Also let me reiterate (as was pointed out) that sending inquiry messages to try to authenticate a valid mail agent LIKEWISE multiplies the bandwidth already wasted by the original spam. I believe that ultimately, the best way to deal with spam (okay, we're talking principle here, not necessarily given existing, insufficiently clever mail clients) is to simply deliver the spam to the recipient's system, and let their system decide which mail is wanted, and which is not, and to either simply delete or archive somewhere the mail which the recipient user's rules determine is not wanted. I do not consider a bounceback message to be necessary or even desirable if a message is found to be spam/virus/phishing ... in part because you cannot reliably determine who the original, legitimate sender is (even if there IS one) to send the bounceback message to. Furthermore, and I've mentioned this before, my domains that I use for my e-mail (including terabites.com) generally are handled by my domain provider, although if I am away from home (say, at an Internet cafe, perhaps onboard a cruise ship or airport kiosk or at a public library somewhere, to name several examples) I (a) still want to use my own From: address for reply or posting permission purposes, even though (b) I might not have ANY say at all regarding what outgoing mail server(s) are used for mail submitted from the location that I happen to be sending from. The fact that I am sending outgoing mail though an unfamiliar and inhabitual location doesn't mean that it's not legitimate, and I'm certainly not going to switch my "From" address for such messages to some other "From" address just because it matches somehow the mail server that I happen to be sending through. The fact that it's easier, or cheaper, or otherwise "more efficient" to do antispam blocking using some halfassed, braindead scheme which doesn't work reliably or well for (even some admittedly small) legitimate mail transmissions doesn't make that the right solution. Another situation is where an accounting system at one of my consulting clients generates and sends electronic invoices, EFT notices, price updates, etc to their customers. For these cases, it is VERY helpful for their own inhouse outgoing LAN mail server (which maybe doesn't try to handle incoming mail at all) is going to try to send outgoing mails... if for no other reason than to have a local, inhouse log that evidences the delivery of the e-mail not just to a relay somewhere, but actually to (usually) the mail server associated with the destination indicated for the e-mail message. It is FAR less useful to only have the company's SMTP logs evidence to the delivery to an upstream ISP's outgoing mail server. Yet another case is where a traveling salesperson connects via a prospect's WiFi connection during a sales call visit on-site to his customer, and where that host's corporate network policy blocks sending of port 25 messages other than to/through that company's own outgoing SMTP server. The same situation occurs when a private individual is on holiday visiting (or staying with) a relative whose internet connection is provided by a different provider. Again, sometimes legitimate mail must be routed through an inhabitual outgoing mail server. Anyhow, these braindead schemes about trying to decide whether a mail server is or is not supposed to be sending mail for a given return address, or blocking all mail being forwarded by a widely shared mail relay (based on its IP address) just because ONE of the (even tens or hundreds of thousands of) users of that same relay happened to get infected, is just insane. It's not sufficient that the scheme initially looks appealing because it works "much" of the time. I still believe that a far better and more worthwhile direction for spam blocking involves a combination of tools, probably much of it performed at the receiving end, involving a finely grained discrimination tailored to familiar versus unfamiliar (to the recipient) e-mail senders. This is not unlike the way locks work... they generally provide a series of grooves, chamfers and cuts (to the key BLANK!) which prevent the vast majority of presented keys from even being inserted INTO the lock, before the pins of the lock do the final determination based on how the individual key has been cut. In the case of E-mail, the corresponding policy could screen incoming e-mail messages based upon the characteristics _expected_ in e-mail coming from specific individual (familiar) senders (this is not unlike the technique that an intelligent human reader would use, when they open an e-mail claiming to come from a company or friend and the e-mail upon opening not looking "right" based on what we would expect that company or friend to be sending. An example is cases where companies like Grouply manage to convince naive users to provide Grouply with the user's e-mail credentials, and where Grouply then uses the user's e-mail identity to send Grouply's spam... and when the recipient opens the message, it clearly doesn't look like an e-mail that Aunt Martha typically sends). E-mail coming from unfamiliar correspondents can be held to a (even much) higher-than-usual standard regarding the ground rules for what is acceptable and what is not. As a recipient, for example, I would be willing to state that I don't want mail containing HTML or attachments (or more than, say, 50K or 100K) from unfamiliar senders. That would block (and in a robust way!) misrepresented HTML links (a key part of most phishing exploits), malicious scripting, ActiveX exploits, infectious attachments, and the like. It's also noteworthy that such a policy blocks in one fell swoop nearly all the ruses and tricks that spammers use to try to evade (SpamAssassin-like) antispam content filtering... meaning that such filters suddenly become a great deal more effective and reliable. It seems best if such filtering is largely done at the recipient user's end, and preferably in conjunction with their mail software... so that if they are looking for an expected e-mail message, and find it in their spam folder, they can have (say) a simple dialog box pop up that offers the user to "allow mail like this in the future from this sender." It makes it a significantly harder challenge for spammers and abusers to evade antispam protections when they don't even know what criteria are used by specific recipients, or what From addresses those recipients might have "cut their (individual) keyway" to accept. (And again, note that this is NOT just a simple 'whitelist' scheme... since it will accept mail coming from unfamiliar senders, it only just holds such senders to a particularly strict standard for what can, and must not be, contained in the e-mails those unfamiliar senders send out.) -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking From vesely@tana.it Mon Jun 22 05:35:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D6728C169 for ; Mon, 22 Jun 2009 05:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvfO1FRl+a+g for ; Mon, 22 Jun 2009 05:35:45 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 26A983A6846 for ; Mon, 22 Jun 2009 05:35:44 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 22 Jun 2009 14:35:57 +0200 id 00000000005DC033.000000004A3F7AAD.0000326A Message-ID: <4A3F7AAC.8030402@tana.it> Date: Mon, 22 Jun 2009 14:35:56 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:35:46 -0000 Ian Eiloart wrote: > --On 19 June 2009 12:54:17 +0200 Alessandro Vesely wrote: >> What about the other way around: given a domain and an IP address, can we >> say whether the IP address "is a member of" the domain? > [...] > The DNS is used to express relationships between IP addresses and domain > names, but there are many types of relationship - like MX records, A > records. A records. MX bear no IP address. Other records may hold an IP address, e.g. TXT, thus providing possibly weaker relationships. > "is a member of" sounds like it might mean "is owned by" or "is > assigned to", but IP addresses are assigned to real world organisations, > not domain names. You're right, the admins of a domain may put whatever A records in their zone files. I have to add that I get the domain name _from_ the given IP. In that case, if I'm able to find a record in the domain's zone that confirms that relationship, can I safely deduce that the membership relation holds? > There's no necessary relationship when sending SMTP, unfortunately. Agreed. But why do you say "unfortunately"? Do you mean that it would always be preferable to attribute responsibility based on the IP delegation hierarchy, rather than on the names' one, or have we always tried to go the former way just because the IP address of the remote host is easier to obtain? From johnl@iecc.com Mon Jun 22 05:51:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8CC28C1DA for ; Mon, 22 Jun 2009 05:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFRDIDv0-eMC for ; Mon, 22 Jun 2009 05:51:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id DC56428C1D9 for ; Mon, 22 Jun 2009 05:51:10 -0700 (PDT) Received: (qmail 19601 invoked from network); 22 Jun 2009 12:51:25 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 22 Jun 2009 12:51:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=0JkAN32f8kP/gEVbu4kUKc98Y6TocgV4rEzaZ+Ml6tc=; b=IijWVi5bBUxOPslF2KKD21knbgWPsA1cxh9kA9u84vC0NWVQy89MORZWr6yhvo0r4J1U1S53re/f3SPVCUwuQAQxNZb0SBM7XR+CAfG1CJBZw1p+yyrxHspItb5H30fNGm+/dnSY6SWAU98RDDiHpkA9yWyJyGHv+Rs8xUc6/Cg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=0JkAN32f8kP/gEVbu4kUKc98Y6TocgV4rEzaZ+Ml6tc=; b=AJg/bfic8PpI7XY8yC6SZJZVu6kGA3oKNUVY+/vPUUbhlQDJQgPCJesoE4nKttSOvoQk4CkZ0U5Y96JceEc6S1Cu9GOQ1hQnnFGDE6P4WT6GL61NYukj4X1iTjFQwbTt+UL2GzQxrHerCBbvXn0z4piJpNlWkb/EF2DVYLJ989Q= Date: 22 Jun 2009 12:51:24 -0000 Message-ID: <20090622125124.2497.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A3F76B8.2030409@terabites.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:51:12 -0000 In article <4A3F76B8.2030409@terabites.com> you write: >And the circle goes round and round. My, we have a lot of dead horses here. >The first one has been pointed out, but perhaps not strongly enough. IT IS >STUPID AND COUNTERPRODUCTIVE TO BOUNCE NOTICE OF NON-DELIVERY TO RECOGNIZED SPAM Yes, we know. It's been best practice for years to reject mail you're not planning to deliver, not bounce it. There are, of course, a lot of dusty MTAs still doing worst practices, but our ability to fix them is limited. >Also let me reiterate (as was pointed out) that sending inquiry >messages to try to authenticate a valid mail agent LIKEWISE >multiplies the bandwidth already wasted by the original spam. Callbacks are widely discredited other than among a few small filtering vendors who think they're the secret sauce to keep the users paying. I routinely block all connections from hosts where I see C/R callbacks, and I doubt I'm the only one. >connection during a sales call visit on-site to his customer, and where that >host's corporate network policy blocks sending of port 25 messages other than >to/through that company's own outgoing SMTP server. It's been best practice for a decade to use SUBMIT or a tunnel back to your own host to send mail. These days it's just laziness to do anything else. As someone else asked a few minutes ago, are there any significant mail systems that still don't provide SUBMIT? >E-mail coming from unfamiliar correspondents can be held to a (even much) >higher-than-usual standard regarding the ground rules for what is >acceptable and what is not. Yes, that's why we've been working on mail authentication a la DKIM for several years, to allow us to recognize known senders reliably. R's, John From johnl@iecc.com Mon Jun 22 05:52:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2A528C1DD for ; Mon, 22 Jun 2009 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxMRqO+kDvbV for ; Mon, 22 Jun 2009 05:52:28 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 7F96F28C1C7 for ; Mon, 22 Jun 2009 05:52:28 -0700 (PDT) Received: (qmail 21051 invoked from network); 22 Jun 2009 12:52:42 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 22 Jun 2009 12:52:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=R7Gilkp9PWS6i1RITJTlGYzmseeCkBcHM2UxOqMQgBY=; b=D+twMncPrzOa7C3c8eAltWCMkFn+8gAEzmqD3iqzvlr2Igm58tuFJ3XZQfm9TAGQfKUuXQoglz/StMOQFmy5f8uIIsxXNWZryK4jXzOn9FIbrMbsKvoFpEuYAdGBhbzn62UmdabFtsQMqR2TWxTKpzlBwNbvfj+UTfRm3WeXPnk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=R7Gilkp9PWS6i1RITJTlGYzmseeCkBcHM2UxOqMQgBY=; b=AbCdWijwTmH5edCQCQfyAkrRTOzbiCon2NyYgfwGJBEPZYpJxfxuHxhMnjBEow5+FoJBncaDkY+OmLPzqtIV9/+eOQf3G/KC+H7y8qG8AGAM1rVf9YzYneL07/QplPtlDb0dGXbR3VqFccmgSU+sLThE7ew7Lx9zB0PT0PEwG/U= Date: 22 Jun 2009 12:52:41 -0000 Message-ID: <20090622125241.2518.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A3B6E59.5010002@tana.it> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:52:29 -0000 >What about the other way around: given a domain and an IP address, can >we say whether the IP address "is a member of" the domain? In a word, no. SPF is the best effort we have along those lines, and for reasons I hope I don't have to reiterate, it's far from adequate. R's, John From vesely@tana.it Mon Jun 22 06:55:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020FB3A6862 for ; Mon, 22 Jun 2009 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+b15VtcXUuV for ; Mon, 22 Jun 2009 06:55:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C64213A6882 for ; Mon, 22 Jun 2009 06:55:53 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 22 Jun 2009 15:56:05 +0200 id 00000000005DC02F.000000004A3F8D75.00003BDA Message-ID: <4A3F8D74.700@tana.it> Date: Mon, 22 Jun 2009 15:56:04 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3F76B8.2030409@terabites.com> In-Reply-To: <4A3F76B8.2030409@terabites.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 13:55:55 -0000 Gordon Peterson wrote: > I believe that ultimately, the best way to deal with spam (okay, we're > talking principle here, not necessarily given existing, insufficiently > clever mail clients) is to simply deliver the spam to the recipient's > system, and let their system decide which mail is wanted, and which is > not, and to either simply delete or archive somewhere the mail which the > recipient user's rules determine is not wanted. I do not consider a > bounceback message to be necessary or even desirable if a message is > found to be spam/virus/phishing ... in part because you cannot reliably > determine who the original, legitimate sender is (even if there IS one) > to send the bounceback message to. Except that you cannot reliably determine whether a message is spam. Machines do not understand human language. They make spam/ham decisions based on indeterministic criteria. Why do we run journaled file system on RAID drives when we would want to kill random files for the sake of spam abatement? > [...] I (a) still want to use my own > From: address for reply or posting permission purposes, even though (b) > I might not have ANY say at all regarding what outgoing mail server(s) > are used [...] > > The fact that it's easier, or cheaper, or otherwise "more efficient" to > do antispam blocking using some halfassed, braindead scheme which > doesn't work reliably or well for (even some admittedly small) > legitimate mail transmissions doesn't make that the right solution. The difference between content filtering and however braindead authentication schemes is that the latter ones are deterministic, rather than easier, or cheaper, or otherwise "more efficient". Deterministic results mean that messages sent correctly are delivered independently of their content, uniformly. IMHO, the correct way to go is to have a (weak) authentication scheme that works well enough for most relevant cases, and at the same time keep the existing system as a compatibility option for the cases where it doesn't work. If you want to use prehistoric appliances deploying obsolete mail transmission methods that have historically proven to be vulnerable to spammers, you have to accept that your mail will be handled via compatibility options, including unreliable spam filtering. If you expect your From: address to be treated specially, be aware that any spammer can use it just like you do (and wait until spammers decide to relate recipients to the From: addresses that they whitelist.) Anything that is capable to deterministically recognize that you are really you, is an authentication scheme. > Another situation is where an accounting system at one of my consulting > clients generates and sends electronic invoices, EFT notices, price > updates, etc to their customers. For these cases, it is VERY helpful > for their own inhouse outgoing LAN mail server (which maybe doesn't try > to handle incoming mail at all) is going to try to send outgoing > mails... if for no other reason than to have a local, inhouse log that > evidences the delivery of the e-mail not just to a relay somewhere, but > actually to (usually) the mail server associated with the destination > indicated for the e-mail message. How come you consider that log line reliable, given that it doesn't tell you whether the corresponding message has been "simply deleted or archive somewhere"? > Yet another case is where a traveling salesperson connects via a > prospect's WiFi connection during a sales call visit on-site to his > customer, and where that host's corporate network policy blocks sending > of port 25 messages other than to/through that company's own outgoing > SMTP server. Try port 587. > I still believe that a far better and more worthwhile direction for spam > blocking involves a combination of tools, probably much of it performed > at the receiving end, involving a finely grained discrimination tailored > to familiar versus unfamiliar (to the recipient) e-mail senders. This > is not unlike the way locks work... they generally provide a series of > grooves, chamfers and cuts (to the key BLANK!) which prevent the vast > majority of presented keys from even being inserted INTO the lock, > before the pins of the lock do the final determination based on how the > individual key has been cut. Except that you want external unknown people to be able to contact you by email (otherwise you could just use an unofficial port different than 25 and relay mail privately within your closed group.) It would be also appreciable if newcomers could open brand new ESP shops and run their SMTP servers without having to spend years learning the intricacies of finely grained discrimination tools. As those tools evolve, desperately seeking new ways to find needles in the growing haystack of spam, users experience more and more malfunctions. If you dig into the actual rules and data that your filters base their decisions upon, you may get surprised. From iane@sussex.ac.uk Mon Jun 22 06:58:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9953A6DB9 for ; Mon, 22 Jun 2009 06:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8J8ftji8PV1 for ; Mon, 22 Jun 2009 06:58:31 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id EA4D03A6862 for ; Mon, 22 Jun 2009 06:58:30 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51324) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLN87N-000BYN-DG for asrg@irtf.org; Mon, 22 Jun 2009 14:59:47 +0100 Date: Mon, 22 Jun 2009 14:59:01 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3F7AAC.8030402@tana.it> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> <4A3F7AAC.8030402@tana.it> Originator-Info: login-token=Mulberry:01edirteI5GRq6Rf8X5f7sTR4o31DMD9z+7kM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 13:58:31 -0000 --On 22 June 2009 14:35:56 +0200 Alessandro Vesely wrote: > Ian Eiloart wrote: >> --On 19 June 2009 12:54:17 +0200 Alessandro Vesely >> wrote: >>> What about the other way around: given a domain and an IP address, can >>> we say whether the IP address "is a member of" the domain? >> [...] >> The DNS is used to express relationships between IP addresses and domain >> names, but there are many types of relationship - like MX records, A >> records. > > A records. MX bear no IP address. Other records may hold an IP address, > e.g. TXT, thus providing possibly weaker relationships. > >> "is a member of" sounds like it might mean "is owned by" or "is >> assigned to", but IP addresses are assigned to real world organisations, >> not domain names. > > You're right, the admins of a domain may put whatever A records in their > zone files. I have to add that I get the domain name _from_ the given IP. > In that case, if I'm able to find a record in the domain's zone that > confirms that relationship, can I safely deduce that the membership > relation holds? > >> There's no necessary relationship when sending SMTP, unfortunately. > > Agreed. But why do you say "unfortunately"? Do you mean that it would > always be preferable to attribute responsibility based on the IP > delegation hierarchy, rather than on the names' one, or have we always > tried to go the former way just because the IP address of the remote host > is easier to obtain? We use IP address reputation services because there's nothing else we can use, in the absence of some way to authenticate the sender address. Of course, those mechanisms exist and are widely deployed but not universally, or even by a majority of domains. When they become so, we'll no doubt see domain based reputation services, and even address based reputation services being used as much as IP address reputation services are. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 22 07:11:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5AB3A6AE7 for ; Mon, 22 Jun 2009 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDldCfidg5Jz for ; Mon, 22 Jun 2009 07:11:54 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 46D0A3A6945 for ; Mon, 22 Jun 2009 07:11:54 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51442) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLN8U4-000FC4-4U for asrg@irtf.org; Mon, 22 Jun 2009 15:13:16 +0100 Date: Mon, 22 Jun 2009 15:12:08 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> In-Reply-To: References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> Originator-Info: login-token=Mulberry:01xAsQiS1sfu4FeGTrMDE3gIP8KoMx4ycxOXY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:11:55 -0000 --On 21 June 2009 23:34:16 -0700 Douglas Otis wrote: > > On Jun 20, 2009, at 12:20 PM, Alessandro Vesely wrote: > ... >> OTOH, sender identification by domain could also be a way to >> attribute responsibility. Strictly speaking, it is not necessary to >> use a domain in order to send as an SMTP client. However, in >> practice one needs an email address to do any legitimate use of >> SMTP, and hence a domain is required. > > Technically speaking, a domain is not required for SMTP. CSV was to > offer a DNS record type that explicitly declared a host as being an > outbound MTA. This would not in itself prevent abuse, but would help to > determine which compromised systems might be sending email and resolving > which domain is administrating the MTA. > > SPF does not work well at resolving a domain that should be held > accountable for a few reasons- > > a) risks high and impractical transaction overheads at attempts to > indirectly reference the customers of a provider. Er, we already have ridiculous transaction overheads for email. Anything that stopped spam would reduce the transaction overheads for legitimate email by up to ten fold. > b) may not qualify any specific IP address for a positive result. I'm not sure what that phrase means. If it means that some lookups result in softfail or neutral results, then that actually doesn't matter much. The passes and the fails still get us useful information. Anything else just puts us back where we were before. > c) Mail From or PRA references do not resolve which domain administered > the MTA or actually sent the message. It doesn't matter. If the domain owner devolves responsibility to the IP address owner, then the mail is effectively from the domain owner, and they can be held responsible for their email. Reputation services, and the law can be applied as appropriate. > d) holds customers of a provider accountable for the provider's > stewardship without any solid evidence of their involvement. Please expand, I don't understand this either. >>>>> Schemes that pass accountability onto what might be feckless >>>>> domain owners are inherently evil. >>>> >>>> I disagree, _provided_ accountability is actually passed on. >> >> +1 > > There should be greater concern accountability is correctly applied. > If the domain owners are feckless, then apply sanctions. Accountability HAS to lie with domain owners if you want to establish reputation services based on domain names, and most people do want to do that. If the domain owner is found to be feckless, then reputation sanctions should be applied. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 22 07:16:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA09C28C1BE for ; Mon, 22 Jun 2009 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL5vgtOrgYMl for ; Mon, 22 Jun 2009 07:16:04 -0700 (PDT) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 6AB223A67F2 for ; Mon, 22 Jun 2009 07:16:04 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51503) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLN912-000GBK-BV for asrg@irtf.org; Mon, 22 Jun 2009 15:17:26 +0100 Date: Mon, 22 Jun 2009 15:16:19 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3F76B8.2030409@terabites.com> References: <4A3F76B8.2030409@terabites.com> Originator-Info: login-token=Mulberry:01MNXN6Jk2O01xQiFKnPujSkBblk3uQpP7pUA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:16:06 -0000 --On 22 June 2009 07:19:04 -0500 Gordon Peterson wrote: > And the circle goes round and round. > > Periodically, I feel it necessary to point out some of the serious flaws > in all of these IP-based "authentication" type schemes. > > The first one has been pointed out, but perhaps not strongly enough. IT > IS STUPID AND COUNTERPRODUCTIVE TO BOUNCE NOTICE OF NON-DELIVERY TO > RECOGNIZED SPAM E-MAILS. It can double OR TRIPLE the bandwidth wasted by > the original spam, in part because (at least in the case of spam which > has been relayed one or more times) it is problematical to know WHO to > send the bounce message to. > > In my personal mailboxes I have (way) more than 50,000 archived > bounceback messages to e-mails which I have never sent... just because > they have a (forged, and generally invalid) From: address that is > supposedly in one of my domains. > > Since I haven't sent these messages (neither intentionally, nor by > irresponsible management of my systems here) there is NOTHING I can do to > prevent such messages. There is, actually. If you publish SPF records with a strong -all, then recipients can easily decide to reject (not bounce) messages. Add DKIM signatures, and they'll be able to tell when someone has forwarded your legitimate email. > Meanwhile, the handling of the (worthless) bounce > messages multiply by perhaps several times the bandwidth wasted due to > the original spam. > > Barracuda spam blocking systems are particularly irresponsible by > apparently not explaining to their users WHY bouncing spam back to the > sender is a Bad Idea, resulting in their (even less clever) users often > apparently leaving that option set. > > Also let me reiterate (as was pointed out) that sending inquiry messages > to try to authenticate a valid mail agent LIKEWISE multiplies the > bandwidth already wasted by the original spam. > > I believe that ultimately, the best way to deal with spam (okay, we're > talking principle here, not necessarily given existing, insufficiently > clever mail clients) is to simply deliver the spam to the recipient's > system, and let their system decide which mail is wanted, and which is > not, and to either simply delete or archive somewhere the mail which the > recipient user's rules determine is not wanted. I do not consider a > bounceback message to be necessary or even desirable if a message is > found to be spam/virus/phishing ... in part because you cannot reliably > determine who the original, legitimate sender is (even if there IS one) > to send the bounceback message to. > > Furthermore, and I've mentioned this before, my domains that I use for my > e-mail (including terabites.com) generally are handled by my domain > provider, although if I am away from home (say, at an Internet cafe, > perhaps onboard a cruise ship or airport kiosk or at a public library > somewhere, to name several examples) I (a) still want to use my own From: > address for reply or posting permission purposes, even though (b) I might > not have ANY say at all regarding what outgoing mail server(s) are used > for mail submitted from the location that I happen to be sending from. > The fact that I am sending outgoing mail though an unfamiliar and > inhabitual location doesn't mean that it's not legitimate, and I'm > certainly not going to switch my "From" address for such messages to some > other "From" address just because it matches somehow the mail server that > I happen to be sending through. > > The fact that it's easier, or cheaper, or otherwise "more efficient" to > do antispam blocking using some halfassed, braindead scheme which doesn't > work reliably or well for (even some admittedly small) legitimate mail > transmissions doesn't make that the right solution. > > Another situation is where an accounting system at one of my consulting > clients generates and sends electronic invoices, EFT notices, price > updates, etc to their customers. For these cases, it is VERY helpful for > their own inhouse outgoing LAN mail server (which maybe doesn't try to > handle incoming mail at all) is going to try to send outgoing mails... if > for no other reason than to have a local, inhouse log that evidences the > delivery of the e-mail not just to a relay somewhere, but actually to > (usually) the mail server associated with the destination indicated for > the e-mail message. It is FAR less useful to only have the company's > SMTP logs evidence to the delivery to an upstream ISP's outgoing mail > server. > > Yet another case is where a traveling salesperson connects via a > prospect's WiFi connection during a sales call visit on-site to his > customer, and where that host's corporate network policy blocks sending > of port 25 messages other than to/through that company's own outgoing > SMTP server. The same situation occurs when a private individual is on > holiday visiting (or staying with) a relative whose internet connection > is provided by a different provider. Again, sometimes legitimate mail > must be routed through an inhabitual outgoing mail server. > > Anyhow, these braindead schemes about trying to decide whether a mail > server is or is not supposed to be sending mail for a given return > address, or blocking all mail being forwarded by a widely shared mail > relay (based on its IP address) just because ONE of the (even tens or > hundreds of thousands of) users of that same relay happened to get > infected, is just insane. It's not sufficient that the scheme initially > looks appealing because it works "much" of the time. > > I still believe that a far better and more worthwhile direction for spam > blocking involves a combination of tools, probably much of it performed > at the receiving end, involving a finely grained discrimination tailored > to familiar versus unfamiliar (to the recipient) e-mail senders. This is > not unlike the way locks work... they generally provide a series of > grooves, chamfers and cuts (to the key BLANK!) which prevent the vast > majority of presented keys from even being inserted INTO the lock, before > the pins of the lock do the final determination based on how the > individual key has been cut. > > In the case of E-mail, the corresponding policy could screen incoming > e-mail messages based upon the characteristics _expected_ in e-mail > coming from specific individual (familiar) senders (this is not unlike > the technique that an intelligent human reader would use, when they open > an e-mail claiming to come from a company or friend and the e-mail upon > opening not looking "right" based on what we would expect that company or > friend to be sending. An example is cases where companies like Grouply > manage to convince naive users to provide Grouply with the user's e-mail > credentials, and where Grouply then uses the user's e-mail identity to > send Grouply's spam... and when the recipient opens the message, it > clearly doesn't look like an e-mail that Aunt Martha typically sends). > > E-mail coming from unfamiliar correspondents can be held to a (even much) > higher-than-usual standard regarding the ground rules for what is > acceptable and what is not. As a recipient, for example, I would be > willing to state that I don't want mail containing HTML or attachments > (or more than, say, 50K or 100K) from unfamiliar senders. That would > block (and in a robust way!) misrepresented HTML links (a key part of > most phishing exploits), malicious scripting, ActiveX exploits, > infectious attachments, and the like. It's also noteworthy that such a > policy blocks in one fell swoop nearly all the ruses and tricks that > spammers use to try to evade (SpamAssassin-like) antispam content > filtering... meaning that such filters suddenly become a great deal more > effective and reliable. > > It seems best if such filtering is largely done at the recipient user's > end, and preferably in conjunction with their mail software... so that if > they are looking for an expected e-mail message, and find it in their > spam folder, they can have (say) a simple dialog box pop up that offers > the user to "allow mail like this in the future from this sender." > > It makes it a significantly harder challenge for spammers and abusers to > evade antispam protections when they don't even know what criteria are > used by specific recipients, or what From addresses those recipients > might have "cut their (individual) keyway" to accept. (And again, note > that this is NOT just a simple 'whitelist' scheme... since it will accept > mail coming from unfamiliar senders, it only just holds such senders to a > particularly strict standard for what can, and must not be, contained in > the e-mails those unfamiliar senders send out.) -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Mon Jun 22 07:54:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75233A6CEA for ; Mon, 22 Jun 2009 07:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs63FftpXEnU for ; Mon, 22 Jun 2009 07:54:24 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A7C8C3A6C3A for ; Mon, 22 Jun 2009 07:54:24 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 22 Jun 2009 16:54:36 +0200 id 00000000005DC031.000000004A3F9B2C.00004326 Message-ID: <4A3F9B2B.8020603@tana.it> Date: Mon, 22 Jun 2009 16:54:35 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> In-Reply-To: <4A3DFC91.2090506@telmon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:54:25 -0000 Claudio, I've skimmed part of your paper, and I think your framework has a problem in the transition to consent-enabled mailboxes: When users switch their mailboxes to consent-enabled, they lose the ability to receive any message from consent-unaware senders, including friends, business contacts, mailing lists, banks and similar notification services, reminders, cell phones, etcetera. Most of them will end up having a second mailbox which is not consent-enabled, or functionally similar arrangement, resulting in two streams of messages. They'll have to watch both streams and will find wanted and unwanted messages in each one. (Well, the consent-enabled stream will have to wait for spammers to become aware of the X-Consent-request header to get much unwanted stuff.) Since any other action will be performed as usual, there will be no visible advantage resulting from the framework. That state of affairs will never be an incentive for widespread adoption, and, on the other hand, without widespread adoption the framework will always require that disappointing stream doubling. -------- Original Message -------- Subject: [Asrg] request for review for a non FUSSP proposal Date: Sun, 21 Jun 2009 11:25:37 +0200 From: Claudio Telmon Reply-To: Anti-Spam Research Group - IRTF To: asrg@irtf.org Dear Sirs, I've developed a proposal for an extension to the SMTP protocol that should provide to address owners the ability to express consent to delivery of messages in their mailboxes. While it is not the Ultimate Solution to the Spam Problem, and strictly speaking it is not even an antispam solution, it could help reducing spam. I already discussed my proposal with some researchers, which judged it positively, but which didn't have a very specific competence. I think that my proposal could be of some interest for the ASRG community, and I'm looking for comments and advise. The paper is in html and pdf at http://www.telmon.org/consent/smtp-consent-1.1.html and http://www.telmon.org/consent/smtp-consent-1.1.pdf The paper is quite long, as I tried to anticipate most of the implementation and deployment issues, but the idea is quite simple and not really new, since it is very similar to "ham passwords". If you just want to see what it's all about, you could just read the "Introduction" and "General overview of the framework" sections, and maybe the "Deployment of the framework" section at the end of the document. Thanks in advance for any comments or suggestions you can provide me. Sincerely, - Claudio Telmon -- Claudio Telmon claudio@telmon.org http://www.telmon.org From jdfalk-lists@cybernothing.org Mon Jun 22 10:08:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DBD3A6DE2 for ; Mon, 22 Jun 2009 10:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GMCKYPL2Z4D for ; Mon, 22 Jun 2009 10:08:55 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0646828C18B for ; Mon, 22 Jun 2009 10:08:54 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n5MH977P003835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Jun 2009 11:09:09 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n5MH977P003835 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1245690549; bh=NHZ3S023PFBUxSw2+ax1W4H8giRPOjrYzb7vzNdR yso=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=gDXJgjoDK+j6AC51kzHeAgGIhhjagBa8mnJC4 cslDZ6E2iHcOJPgvj0+sAYlVH9nMXgDrAN4O3+ozaLA75jUESaWClJGEO8/WH3jtZjq xArS0NQCgnkdR785mY50iRZhR2xp1E8/ouFPda68jaRm6TJ994WoNZyjfrHc9mo9W+g = Message-ID: <4A3FBAAE.4080100@cybernothing.org> Date: Mon, 22 Jun 2009 11:09:02 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] MUA as MSA or MTA (was Re: What are the IPs that sends mail for a domain?) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 17:08:57 -0000 Alessandro Vesely wrote: > Being suspicious about their ESPs, those users may prefer to > deliver directly whenever possible. That is the only reason I see for > attempting a direct delivery first, and it is a largely suboptimal > solution anyway (e.g. it provides no reliable storage for sent messages.) What you're describing, here, is a vanishingly tiny minority of users. -- J.D. Falk From john@jlc.net Mon Jun 22 10:52:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800D428C220 for ; Mon, 22 Jun 2009 10:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oN8tipcs7Kl for ; Mon, 22 Jun 2009 10:52:16 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 8E8C03A68BB for ; Mon, 22 Jun 2009 10:52:16 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1BFCB33C7A; Mon, 22 Jun 2009 13:52:31 -0400 (EDT) Date: Mon, 22 Jun 2009 13:52:31 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090622175230.GA57980@verdi> References: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <4A3F63BE.1030303@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3F63BE.1030303@tana.it> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] "Affiliation" X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 17:52:17 -0000 Alessandro Vesely wrote: > Douglas Otis wrote: > >> CSV was to offer a DNS record type that explicitly declared a host as >> being an outbound MTA. This would not in itself prevent abuse, but would >> help to determine which compromised systems might be sending email and >> resolving which domain is administrating the MTA. > > It didn't help retrieving the responsible domain, though. CSV intended to use the EHLO string _as_ the responsible domain, even though it might be one of several subdomains under a single management. > Furthermore, it didn't do ranges, thus making it laborious to deny > sending to a bunch of hosts. I agree it didn't "do ranges", since it seemed appropriate to allow separate reputations for separate EHLO names. > In addition, CSA spec curiously had a "MAY" for an non-authorized host > with a non-ignored target resulting in weight 0. That was an artifact of our being told that excessive queries for the root "." would cause problems. The "MAY" covered how to program a case which "should" never happen. > However, _client._smtp.domain-name records authorizing various targets > would be almost equivalent to setting SPF, or MX heuristics. (I'll > possibly add that to the next vhlo draft.) I'm certainly game to do any needed updates to draft...csv... > AFAIK, all discussions eventually reach the conclusion that the > receiving server does not know which domain administers the client > MTA. CSV was intended to address exactly that problem. We felt that the vast majority of domains _could_ get by with half a dozen IP addresses returned by a A)ddress record, and that for those that couldn't, the ability to have separable reputations was an _advantage_. For a reputation service, more than one reputation record per domain actively sending (reasonable) email seemed simple enough. > FWIW the old ietf-marid-csv-csa asserts that > > The SMTP [RFC2821] [RFC0821] protocol permits a client to declare > its affiliation, by asserting a domain name in the HELO or EHLO > announcement. > > which is wrong. EHLO only allows it to declare its identity. It's a relief, actually, to _finally_ have a useful correction to these drafts! I agree that "affiliation" was not the best choice of words in draft-ietf-marid-csv-csa-02. "Affiliation" should be multi-valued, with an individual sending MTA able to affiliate with multiple entities. OTOH, "identity" isn't quite right either. Though it is the term used in RFC 2821, that RFC in no sense requires that the "identity" identify a single server. "Identity" would probably be better that "affiliation"; some other term might be better than either... > Declaring the affiliation is VHLO's raison d'?tre. Hmm... I still think "affiliation" deserves to be multi-valued... -- John Leslie From gep2@terabites.com Mon Jun 22 11:04:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C162128C1F3 for ; Mon, 22 Jun 2009 11:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXLcYCARMo1a for ; Mon, 22 Jun 2009 11:04:19 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by core3.amsl.com (Postfix) with ESMTP id B57533A68BB for ; Mon, 22 Jun 2009 11:04:15 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 140D11C444C0 for ; Mon, 22 Jun 2009 18:04:30 +0000 (UTC) X-Spam-Summary: 2, 0, 0, 2b7e3d8e61469466, d41d8cd98f00b204, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:728:854:945:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1766:1792:2194:2196:2199:2200:2393:2525:2559:2563:2682:2685:2689:2705:2733:2741:2828:2857:2859:2900:2901:2917:2920:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3636:3657:3865:3866:3867:3868:3869:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:6119:7652:7679:7809:7903:7974:8985:9025:9036:9108:10004, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:none, DNSBL:none, Custom_rules:0:0:0 X-Session-Marker: 6765703261407465726162697465732E636F6D X-Filterd-Recvd-Size: 2619 Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2009 18:04:29 +0000 (UTC) Message-ID: <4A3FC7AD.2060307@terabites.com> Date: Mon, 22 Jun 2009 13:04:29 -0500 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] Horses X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:04:20 -0000 > It's been best practice for a decade to use SUBMIT or a tunnel back to your own host to send mail. These days it's just laziness to do anything else. As someone else asked a few minutes ago, are there any significant mail systems that still don't provide SUBMIT? Yes... basically ALL of those which allow you to send e-mails though an e-mail kiosk-type service, such as you find at airport waiting lounges, cruise ship and other public-access Internet cafes, (including Internet mail public-access systems you find at public libraries, Chinese post offices, etc. etc., where you do not get to use your own computer, and basically are limited to entering your return e-mail address, the destination e-mail address, the subject, and your mail message.) >>>E-mail coming from unfamiliar correspondents can be held to a (even much) > >higher-than-usual standard regarding the ground rules for what is > >acceptable and what is not. > Yes, that's why we've been working on mail authentication a la DKIM for The point being that Aunt Martha's machine can be compromised, such that even with her own IP, her habitual outgoing mail server, and her valid credentials, it might still be shipping spam. It's not enough that it LOOKS like (or even IS) coming from her... just as it's not enough to see that mail has your friend's return E-mail address if it's actually Grouply spam. It's far better to see whether the incoming e-mail with Martha's return address has all the typical things that Aunt Martha's mail messages ACTUALLY HAVE (for example, does it use the 'stationery' that she maybe 'always' uses?) Again, this is analogous to what humans actually do when considering a suspect incoming e-mail message... does it look the way you'd expect mail FROM THAT SENDER to actually look? What yellow or red flags is it flying? This requires looking at the content, too. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking From dotis@mail-abuse.org Mon Jun 22 11:16:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C4B28C250 for ; Mon, 22 Jun 2009 11:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+5RdNRAD6Vo for ; Mon, 22 Jun 2009 11:16:13 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 2DACB3A6ACF for ; Mon, 22 Jun 2009 11:16:05 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id A9236A94439 for ; Mon, 22 Jun 2009 18:16:18 +0000 (UTC) Message-Id: <1AAD9995-CBBB-42F9-937F-93D2DE35465E@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3F63BE.1030303@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 11:16:18 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <4A3F63BE.1030303@tana.it> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:16:18 -0000 On Jun 22, 2009, at 3:58 AM, Alessandro Vesely wrote: > As for forcefully disabling accounts, one needs a legal authority to =20= > break a commercial agreement. For some reasons, they tend to move =20 > quicker for child porn than spammers. Last time I talked about spam =20= > to our postal police, the first thing he said has been "me too". =20 > Since we lack police resources for snatches and rapes, I felt =20 > arrogant asking them to go after my spammer, and gave up. This suggests poor Acceptable Use Policies. > I don't follow how OpenId would help. Stable identifiers might mitigate some vetting. >> CSV was to offer a DNS record type that explicitly declared a host =20= >> as being an outbound MTA. This would not in itself prevent abuse, =20= >> but would help to determine which compromised systems might be =20 >> sending email and resolving which domain is administrating the MTA. > > It didn't help retrieving the responsible domain, though. =20 > Furthermore, it didn't do ranges, thus making it laborious to deny =20 > sending to a bunch of hosts. In addition, CSA spec curiously had a =20 > "MAY" for an non-authorized host with a non-ignored target resulting =20= > in weight 0. The domain administrating MTAs ARE the truly responsible Domains. It =20= would be speculation whether an entity offering authorization actually =20= originated the messages. CSV was intended to affirm the SMTP =20 operation by a specific domain. Any CSA record not expressing an =20 affirmation MAY be assumed an indication of the host not being =20 authorized. > However, _client._smtp.domain-name records authorizing various =20 > targets would be almost equivalent to setting SPF, or MX heuristics. =20= > (I'll possibly add that to the next vhlo draft.) Only the HELO mechanism of SPF comes close, but SPF itself does not =20 offer a means to limit the SPF record scope. >> SPF does not work well at resolving a domain that should be held =20 >> accountable for a few reasons- > > One reason is that it works the other way around: given the domain, =20= > authenticate an IP address as a mail transmitter (thus implicitly =20 > authorizing it to send mail). Authorization does not indicate either administration or origination. =20= Any need for authorization records for acceptance will be extorting =20 the publication of records that might allow blame to be incorrectly =20 placed. Hardly a way to ensure providers remain accountable. :^( >> a) risks high and impractical transaction overheads at attempts to =20= >> indirectly reference the customers of a provider. > > I agree it is more complicated than the average users need. =20 > Presumably, the spec is so for being usable in a wider number of =20 > cases. 10 lookups, however, seems reasonable to me. It is actually eleven TXT SPF records that might be needed. The SPF =20 spec allows 10 mechanisms, where there might be a need for 10 =20 subsequent target resolutions per mechanism . The actual limit of DNS =20= transactions is at 111. >> b) may not qualify any specific IP address for a positive result. > > Yes, especially if not used. Even when used. The record can end in +all or use some exists(). SPF =20= also allows the use of macros. These macros can be cached, and yet =20 cause recipients to generate different transactions based upon =20 changing local-parts or IP addresses, for example. >> c) Mail =46rom or PRA references do not resolve which domain =20 >> administered the MTA or actually sent the message. > > AFAIK, all discussions eventually reach the conclusion that the =20 > receiving server does not know which domain administers the client =20 > MTA. FWIW the old ietf-marid-csv-csa asserts that > > The SMTP [RFC2821] [RFC0821] protocol permits a client to declare =20 > its affiliation, by asserting a domain name in the HELO or EHLO =20 > announcement. SMTP (RFC 5321) section 2.3.5 does not stipulate the resolution of the =20= domain asserted by EHLO as using A, AAAA or MX records. It also =20 allows use of address literals. Section 4.1.4 then indicates =20 resolution failure of the EHLO domains or mismatch of address literals =20= MUST NOT be cause for refusing messages. Likewise, SPF also fails to =20= impose negative assertions for ELHO domain failures for Mail-=46rom or =20= PRA domains, of course. > which is wrong. EHLO only allows it to declare its identity. =20 > Declaring the affiliation is VHLO's raison d'=EAtre. Since VHLO can be asserted by bad actors, there is no reason to trust =20= the guidance offered. > At any rate, forwarding -when MAIL FROM and PRA differ- requires a =20 > framework different from SMTP to administer legitimate use of third =20= > parties' email addresses. Classic mailing lists (as this one) comply =20= > with various privacy laws, but most direct marketing lists and =20 > users' .forward files don't. Trusting the MTA via CSV/CSA does not impact message handling, unlike =20= problems created by Sender-ID and SPF. >> d) holds customers of a provider accountable for the provider's =20 >> stewardship without any solid evidence of their involvement. > > See below (at Why do you so often mention authorizing a provider?) Most domains outsource email services. This is a growing trend as =20 email becomes more heavily abused. >> Who said providers need to be criminal for naive users to be harmed =20= >> by SPF? A recipient may check PRAs, where providers may check Mail-=20= >> Froms. > > Formally, SPF only recommends to check MAIL FROM. Any other use of =20 > the underlying mechanism is just heuristics. The lackadaisical attitude ends abruptly when reputation is misapplied =20= as a result of unverifiable assumptions of message origination when =20 erroneously based upon authorizations. This would be extending SPF =20 well beyond its intended purpose. >> Once a user's domain reputation is damaged due to receiver error, =20 >> how can reputations be restored and then protected? > > That has nothing to do with SPF. Any negative assertions based upon SPF might be misapplied against =20 PRAs not protected by the provider. Misapplication of negative =20 assertions might also be due to SPF when Mail-Froms are also not =20 protected by the provider. Have you ever seen a SLA that stipulates =20 PRA or Mail-=46rom exclusivity? >> When asked in the past, those customers are advised to obtain their =20= >> own IP address. > > If responsibility were attributed correctly, this wouldn't be needed =20= > any more. Of course, if I had an address @spammer, I'd have to share =20= > their fate, but my address is my choice. If the IP address were only associated with that of the MTAs, users =20 would be able to seek services from any other provider. When a =20 provider's lack of stewardship impacts user's domains, then users are =20= left without resource, while the provider remains free to seek more =20 victims. >> It is wrong to hold someone accountable for authorizing a provider =20= >> once authorization becomes a requisite for acceptance. Users are =20 >> thereby extorted into assuming risks well beyond their control. > > Why do you so often mention authorizing a provider? SPF is a scheme aimed at authorizing providers and thereby shifting =20 blame. > If I use a vanity address I have to trust an ESP who provides that =20 > service and set MX and SPF RRs accordingly. Why do you feel there is a need to publish SPF records? > The ESP may or may not be my connection provider. The risk is =20 > related with choosing the ESP correctly, so that trust is well put. =20= > That trust is not different for users of an existing domain, who =20 > don't control the domain, but have to trust its admins. Of course, trusting an ESP to keep incoming email confidential is =20 important, and is often covered in SLAs and various laws. But why =20 are users required to blindly trust that email providers will filter =20 other users outbound email? It is unlikely that this filtering is =20 covered by SLAs or by various laws. >> Instead, providers should be held accountable by requiring CSV =20 >> records with a limited number of EHLO host names over time. > > But the targets of those records need an address too. What's the =20 > difference between writing an IP number in an SPF rather than an A RR? CSV is only about who is administrating the MTA. It has nothing to do =20= with who might be inadvertently held responsible based upon Mail-Froms =20= or the PRAs. >> This approach better defends receiving MTAs from abuse with lower =20 >> overhead, and better controls DNS related exploits that threaten =20 >> the entire Internet. > > All of them rely on DNS, and some posts in that "DNS over SCTP" =20 > thread showed that various people think just of http when they =20 > figure out "typical" DNS usage... :-( Unfortunately, when risks associated with SPF with respect to DNS was =20= explained, SPF advocates expressed distain for DNS. -Doug From gep2@terabites.com Mon Jun 22 11:27:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E213A67B5 for ; Mon, 22 Jun 2009 11:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5xTY9wASMzB for ; Mon, 22 Jun 2009 11:27:15 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by core3.amsl.com (Postfix) with ESMTP id 9E6123A67D9 for ; Mon, 22 Jun 2009 11:27:15 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 7992F20FA9AB for ; Mon, 22 Jun 2009 18:27:30 +0000 (UTC) X-Spam-Summary: 30, 2, 0, 1108748d39e1eb5b, d41d8cd98f00b204, gep2@terabites.com, asrg@irtf.org, RULES_HIT:2:355:379:599:854:945:946:967:972:973:980:988:989:1042:1187:1260:1261:1277:1311:1313:1314:1345:1358:1437:1515:1516:1518:1535:1593:1594:1605:1730:1747:1766:1792:1963:2194:2196:2197:2198:2199:2200:2201:2202:2234:2378:2379:2393:2525:2553:2559:2563:2682:2685:2689:2691:2692:2693:2705:2730:2736:2737:2739:2745:2828:2857:2859:2898:2910:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3657:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4051:4120:4250:4321:4470:4659:5007:6117:6119:6248:7576:7652:7679:7808:7809:7903:8660:8957:8985:9025:9040:9108:9153:10007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:none, DNSBL:none, Custom_rules:0:1:0 X-Session-Marker: 6765703261407465726162697465732E636F6D X-Filterd-Recvd-Size: 9208 Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2009 18:27:29 +0000 (UTC) Message-ID: <4A3FCD11.4080702@terabites.com> Date: Mon, 22 Jun 2009 13:27:29 -0500 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:27:17 -0000 Gordon Peterson wrote: > > I believe that ultimately, the best way to deal with spam (okay, we're > > talking principle here, not necessarily given existing, insufficiently > > clever mail clients) is to simply deliver the spam to the recipient's > > system, and let their system decide which mail is wanted, and which is > > not, and to either simply delete or archive somewhere the mail which the > > recipient user's rules determine is not wanted. I do not consider a > > bounceback message to be necessary or even desirable if a message is > > found to be spam/virus/phishing ... in part because you cannot reliably > > determine who the original, legitimate sender is (even if there IS one) > > to send the bounceback message to. > Except that you cannot reliably determine whether a message is spam. UCE isn't the only issue. The issue is whether it's something that the recipient wants to receive, or doesn't want to see. > Machines do not understand human language. They make spam/ham decisions based on indeterministic criteria. Why do we run journaled file system on RAID drives when we would want to kill random files for the sake of spam abatement? I wouldn't "kill" stuff, unless the user has specified rules under which they are willing to summarily kill it. I think it's generally worthwhile to file stuff on a local hard drive at the recipient, hard drive space is cheap, so that they can go back and search for something that maybe got routed to the spam folder that shouldn't have been. > > [...] I (a) still want to use my own > > From: address for reply or posting permission purposes, even though (b) > > I might not have ANY say at all regarding what outgoing mail server(s) > > are used [...] > > > > The fact that it's easier, or cheaper, or otherwise "more efficient" to > > do antispam blocking using some halfassed, braindead scheme which > > doesn't work reliably or well for (even some admittedly small) > > legitimate mail transmissions doesn't make that the right solution. > The difference between content filtering and however braindead authentication schemes is that the latter ones are deterministic, rather than easier, or cheaper, or otherwise "more efficient". Deterministic results mean that messages sent correctly are delivered independently of their content, uniformly. Deterministically bad or incorrect is not an improvement. The finely grained rules I am talking about are absolutely deterministic, in any case... even if they are hard for spammers to determine. > IMHO, the correct way to go is to have a (weak) authentication scheme that works well enough for most relevant cases, and at the same time keep the existing system as a compatibility option for the cases where it doesn't work. > If you want to use prehistoric appliances deploying obsolete mail transmission methods that have historically proven to be vulnerable to spammers, All mail can be vulnerable to spammers. But: 1) you can eliminate the shadows and tricks they use to conceal themselves; 2) you can set up rules to eliminate the great majority of bogus stuff (and I continue to add rules to my personal copy of Thunderbird on an ongoing basis); 3) there is an enormous installed base, including applications (as in the case of embedded e-mail based accounting systems and similar) which are not something where humans are directly involved in sending the messages. > you have to accept that your mail will be handled via compatibility options, including unreliable spam filtering. That's okay, as long as the unreliable filtering happens at the RECIPIENT (and is something they can tweak) and and not at their ISP, (or, worse, enroute) where "nothing" can be done about it. > If you expect your From: address to be treated specially, be aware that any spammer can use it just like you do That would be true, if they could guess the rules that are being applied to the messages. Since those rules are determined by individual recipients, that becomes a very difficult gauntlet for the spammers and abusers to negotiate. > (and wait until spammers decide to relate recipients to the From: addresses that they whitelist.) They have no way to determine what addresses are and are not whitelisted, and what the rules are for a given recipient. > Anything that is capable to deterministically recognize that you are really you, is an authentication scheme. Right, but just establishing the definition seems like it doesn't advance the discussion much. > > Another situation is where an accounting system at one of my consulting > > clients generates and sends electronic invoices, EFT notices, price > > updates, etc to their customers. For these cases, it is VERY helpful > > for their own inhouse outgoing LAN mail server (which maybe doesn't try > > to handle incoming mail at all) is going to try to send outgoing > > mails... if for no other reason than to have a local, inhouse log that > > evidences the delivery of the e-mail not just to a relay somewhere, but > > actually to (usually) the mail server associated with the destination > > indicated for the e-mail message. > How come you consider that log line reliable, given that it doesn't tell you whether the corresponding message has been "simply deleted or archive somewhere"? It only tells me what it needs to tell me... that the message was delivered to the intended recipient's own incoming mail server (whether inhouse, at their ISP or whatever). Anything that happens to it after that is (of course) beyond our control. At least we got the message "there", and that's adequate evidence of our own "best faith" effort to deliver it. As far as it being reliable, it's as reliable as our own outgoing mail server. > > Yet another case is where a traveling salesperson connects via a > > prospect's WiFi connection during a sales call visit on-site to his > > customer, and where that host's corporate network policy blocks sending > > of port 25 messages other than to/through that company's own outgoing > > SMTP server. > Try port 587. How about if he's sitting at a desktop machine inside the customer's office? He's not going to be able to reconfigure the mail software he's sitting in front of. > > I still believe that a far better and more worthwhile direction for spam > > blocking involves a combination of tools, probably much of it performed > > at the receiving end, involving a finely grained discrimination tailored > > to familiar versus unfamiliar (to the recipient) e-mail senders. This > > is not unlike the way locks work... they generally provide a series of > > grooves, chamfers and cuts (to the key BLANK!) which prevent the vast > > majority of presented keys from even being inserted INTO the lock, > > before the pins of the lock do the final determination based on how the > > individual key has been cut. > Except that you want external unknown people to be able to contact you by email (otherwise you could just use an unofficial port different than 25 and relay mail privately within your closed group.) Fine. I am willing to simply decree that (for example) I don't accept HTML mail, big messages, or attachments from people I don't know. This doesn't preclude people from contacting me, only preventing them from abusing me (by whatever my own definition of "abuse" is, and ONLY MY DEFINITION MATTERS!). > It would be also appreciable if newcomers could open brand new ESP shops and run their SMTP servers without having to spend years learning the intricacies of finely grained discrimination tools. I think the place to implement these tools is at the e-mail client software level, where it is integrated and maps well with the user interface that the user is familiar to with their e-mail. > As those tools evolve, desperately seeking new ways to find needles in the growing haystack of spam, users experience more and more malfunctions. If you dig into the actual rules and data that your filters base their decisions upon, you may get surprised. Maybe, but if it's not open to auditing and inspection, then that's the fault of the e-mail client software that implements it... and users can presumably switch to software that works better. -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking From gep2@terabites.com Mon Jun 22 11:32:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3023A680C for ; Mon, 22 Jun 2009 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rYXz5h+2aUV for ; Mon, 22 Jun 2009 11:32:39 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by core3.amsl.com (Postfix) with ESMTP id E3AA33A67B5 for ; Mon, 22 Jun 2009 11:32:38 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 66BF1168D3A9 for ; Mon, 22 Jun 2009 18:32:53 +0000 (UTC) X-Spam-Summary: 2, 0, 0, 467fcce5635a1844, d41d8cd98f00b204, gep2@terabites.com, asrg@irtf.org, RULES_HIT:355:379:854:945:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2378:2393:2525:2559:2563:2682:2685:2705:2828:2857:2859:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3636:3657:3865:3866:3867:3868:3869:3870:3871:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4659:5007:7652:7679:7903:8985:9025:10004, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:none, DNSBL:none, Custom_rules:0:0:0 X-Session-Marker: 6765703261407465726162697465732E636F6D X-Filterd-Recvd-Size: 1645 Received: from [192.168.20.198] (cpe-76-187-196-5.tx.res.rr.com [76.187.196.5]) (Authenticated sender: gep2a@terabites.com) by omf08.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2009 18:32:52 +0000 (UTC) Message-ID: <4A3FCE54.6010905@terabites.com> Date: Mon, 22 Jun 2009 13:32:52 -0500 From: Gordon Peterson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: asrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] non-domain E-mail addresses X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:32:39 -0000 > We use IP address reputation services because there's nothing else we can use, in the absence of some way to authenticate the sender address. Of course, those mechanisms exist and are widely deployed but not universally, or even by a majority of domains. When they become so, we'll no doubt see domain based reputation services, and even address based reputation services being used as much as IP address reputation services are. And that does bring up an interesting question. There's really nothing that says that E-mail address have to be domain-based e-mail addresses, I could just as easily distribute an e-mail address of the form gep2@ip.ad.dr.ess ...obviously though that address could change with little notice. IP address-based return addressess have an even more tenuous association with a given sender and their mail server they are relaying through (especially when that sender is mobile). -- Gordon Peterson II http://personal.terabites.com 1977-2007: Thirty year anniversary of local area networking From dotis@mail-abuse.org Mon Jun 22 12:04:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED5B3A680C for ; Mon, 22 Jun 2009 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VJAOY+xqlU2 for ; Mon, 22 Jun 2009 12:04:47 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id E03C23A6801 for ; Mon, 22 Jun 2009 12:04:47 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5B3C9A94439 for ; Mon, 22 Jun 2009 19:05:01 +0000 (UTC) Message-Id: <41937DE9-BAF3-486B-953E-8C638F3A49D2@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 12:05:00 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:04:48 -0000 On Jun 22, 2009, at 7:12 AM, Ian Eiloart wrote: > --On 21 June 2009 23:34:16 -0700 Douglas Otis > wrote: >> >> SPF does not work well at resolving a domain that should be held >> accountable for a few reasons- >> >> a) risks high and impractical transaction overheads at attempts to >> indirectly reference the customers of a provider. > > Er, we already have ridiculous transaction overheads for email. > Anything that stopped spam would reduce the transaction overheads > for legitimate email by up to ten fold. Only the application of reputation and address range policies reduces spam levels. Not using SPF and instead using CSV will reduce the transaction overhead needed to validate an associated domain. SPF often requires several transactions, that may exceed several hundred transactions where 111 could be generated by PRAs and then another 111 for the Mail-From. The high overhead problem of SPF can be made worse when the SPF records contain macros. Using SPF macros, bad actors can cause recipients to generate a long series of different DNS transactions based upon portions of an email-address local-part, for example. This enables a free DDoS attack while spamming, since SPF macros can make DNS caching ineffective. >> b) may not qualify any specific IP address for a positive result. > > I'm not sure what that phrase means. If it means that some lookups > result in softfail or neutral results, then that actually doesn't > matter much. The passes and the fails still get us useful > information. Anything else just puts us back where we were before. An SPF pass result may never be based upon the IP address of the MTA. The way SPF is defined, there might not be a means to know whether an IP address check is bogus when resolving exists functions, for example. >> c) Mail From or PRA references do not resolve which domain >> administered the MTA or actually sent the message. > > It doesn't matter. If the domain owner devolves responsibility to > the IP address owner, then the mail is effectively from the domain > owner, and they can be held responsible for their email. Reputation > services, and the law can be applied as appropriate. You have this the wrong way around. SPF devolves responsibility to that of the email-address domain owner from that of the provider. Any conclusions about email origination based upon authorization is purely speculative. It would be wrong, perhaps even risky, to conclude a message originated from a domain offering MTA authorization. >> d) holds customers of a provider accountable for the provider's >> stewardship without any solid evidence of their involvement. > > Please expand, I don't understand this either. Providers are not required to assure any particular email-address domain within the Mail-From or that of some PRA is used exclusively by users of the email-address domain. There may not be a relationship between the account used to gain access to an email providers' outbound MTA and the domain of SPF record authorizing the MTA. >> There should be greater concern accountability is correctly applied. > > If the domain owners are feckless, then apply sanctions. > Accountability HAS to lie with domain owners if you want to > establish reputation services based on domain names, and most people > do want to do that. If the domain owner is found to be feckless, > then reputation sanctions should be applied. CSV better ensures the domain providing access is held accountable. Accountability is normally applied against the IP address of the MTA. SPF's attempt at holding Mail From or the PRA domains accountable subverts the often intended use of SPF as a means to mitigate backscatter. It would be foolish to assume SPF assigns who is accountable for having originated a message. -Doug From dotzero@gmail.com Mon Jun 22 13:15:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED20B3A6E0A for ; Mon, 22 Jun 2009 13:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs9b3uKj8QI5 for ; Mon, 22 Jun 2009 13:15:00 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id A1C323A6B5A for ; Mon, 22 Jun 2009 13:13:45 -0700 (PDT) Received: by qyk33 with SMTP id 33so3915120qyk.15 for ; Mon, 22 Jun 2009 13:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iBwjdL6ysXmSQNAYZGBAEhEAmH9Ez7rmbkZF1uEOF18=; b=DgecVSmexsPprUM8U8qiwLwpfb8aBuhIKqYMfZuKn5Nz0MgHjSSINhyVX8nP1ObjCk eVa6dcNdLfXfwKUy9S5kBkJx7WAU523JkOKqxqINi8sU0jfpgU1KeHCuYE38PWZ7hQrC 1Zx0Lnd1mI5+yz10fv0Ys3INm+DEFola6Mxz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IYEMuPyAmOGAGaLjK+jI8i79rIRBSDv9aSjG+F/h1noSt+tqoXF/sNtK/Ahz733v9L 3fQhLh+Dz36IhKyvMEl2+FBIfeWHACKwpL0XJ9XV1wD9nDP9f49rZodMJD2vcajWO3P+ i5NvhlwFQRzJjV99dvGVAL5ev8ezQMFi6kcUk= MIME-Version: 1.0 Received: by 10.220.73.209 with SMTP id r17mr4334074vcj.46.1245701617607; Mon, 22 Jun 2009 13:13:37 -0700 (PDT) In-Reply-To: <41937DE9-BAF3-486B-953E-8C638F3A49D2@mail-abuse.org> References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> <41937DE9-BAF3-486B-953E-8C638F3A49D2@mail-abuse.org> Date: Mon, 22 Jun 2009 16:13:37 -0400 Message-ID: <7ae58c220906221313n6e39d3c1o6591596f6c2b8b9@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 20:15:01 -0000 On Mon, Jun 22, 2009 at 3:05 PM, Douglas Otis wrote: > > On Jun 22, 2009, at 7:12 AM, Ian Eiloart wrote: > >> --On 21 June 2009 23:34:16 -0700 Douglas Otis >> wrote: >>> >>> SPF does not work well at resolving a domain that should be held >>> accountable for a few reasons- >>> >>> =A0a) risks high and impractical transaction overheads at attempts to >>> indirectly reference the customers of a provider. >> >> Er, we already have ridiculous transaction overheads for email. Anything >> that stopped spam would reduce the transaction overheads for legitimate >> email by up to ten fold. > > Only the application of reputation and address range policies reduces spa= m > levels. =A0Not using SPF and instead using CSV will reduce the transactio= n > overhead needed to validate an associated domain. =A0SPF often requires > several transactions, that may exceed several hundred transactions where = 111 > could be generated by PRAs and then another 111 for the Mail-From. =A0 Th= e > high overhead problem of SPF can be made worse when the SPF records conta= in > macros. =A0Using SPF macros, bad actors can cause recipients to generate = a > long series of different DNS transactions based upon portions of an > email-address local-part, for example. =A0This enables a free DDoS attack > while spamming, since SPF macros can make DNS caching ineffective. > Doug, I'd take your discussions of SPF more seriously if you would stop conflating SPF and Sender-ID. They are two different animals. SPF (the specification) does not include anything called PRA. Sender-ID includes the concept of PRA. PRA is broken in the spec so there isn't any purpose in spending time discussing it. All one needs to do is look at the paragraph that states that if a sender field exists you set the PRA to that. This bypasses any SPF record published for the Mail From (envelope sender) domain. End of discussion. From claudio@telmon.org Mon Jun 22 14:12:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EAB3A689D for ; Mon, 22 Jun 2009 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2VUE9xAN0iA for ; Mon, 22 Jun 2009 14:12:02 -0700 (PDT) Received: from slim-2c.inet.it (slim-2c.inet.it [213.92.5.123]) by core3.amsl.com (Postfix) with ESMTP id 305CE3A6C15 for ; Mon, 22 Jun 2009 14:12:02 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-2c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+OHkb4eRNQnK; Mon, 22 Jun 2009 23:12:16 +0200 Message-ID: <4A3FF3AF.9030401@telmon.org> Date: Mon, 22 Jun 2009 23:12:15 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> In-Reply-To: <4A3F9B2B.8020603@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:12:03 -0000 Alessandro Vesely wrote: > Claudio, > I've skimmed part of your paper, and I think your framework has a > problem in the transition to consent-enabled mailboxes: When users > switch their mailboxes to consent-enabled, they lose the ability to > receive any message from consent-unaware senders, including friends, > business contacts, mailing lists, banks and similar notification > services, reminders, cell phones, etcetera. You're absolutely right, of course. This is the most critical deployment issue, and I have tried to consider some strategies in the "deployment" section. Nobody could actually "switch" to consent-enabled mailboxes: a gradual, albeit less effective transition path is required. > Most of them will end up > having a second mailbox which is not consent-enabled, or functionally > similar arrangement, resulting in two streams of messages. They'll have > to watch both streams and will find wanted and unwanted messages in each > one. A couple of thing could help. First, at the beginning the framework could be implemented by the receiver's MUA, instead of the receiver's MTA. This could produce backscatter, so it wouldn't be suited for wide deployment, but this way, people willing to adopt it were not bound to the choices of their ISPs. This way users wouldn't need two separate addresses: messages carrying proper tokens would be whitelisted, while others would receive a worse spam score. Also, messages for addresses associated to token in the address book, but not carrying a proper token, would be marked as forgery and treated as such. However, some people could actually prefer to have two different email addresses, even if then forwarding all messages to the non-consent-enabled mailbox. This helps in adopting the framework, but doesn't help much in finding it useful. In the beginning, the advantage could be more for senders that for receivers. A bank offering this option to its customers could protect its communications from phishing: messages without consent token, and with an address from the bank, could be highlighted by the MUA as probable phishing attempt. The main point here is that the presence/absence of tokens should be easily understood by most people, while mail authentication failures are usually not, and message authentication is hard for many reasons. People worried about forgeries could be told by the bank to adopt the framework (this wouldn't replace other security measures and proper behaviour, it would however add another layer of protection). Some services could be offered, e.g. protected mailboxes for children; relatives and friends would need to adopt the framework in order to communicate with them. These mailboxes would actually only accept messages with proper tokens. In this respect, having plugins available for most common MUAs would be critical. Friends and relatives willing to communicate with them could just be told to "install the plugin and put this string in this field", and then forget the whole thing. But again, all this may make sense if there is enough interest in this form of control on communications, which is probably not the case just for UBE. > (Well, the consent-enabled stream will have to wait for spammers to > become aware of the X-Consent-request header to get much unwanted > stuff.) The hope is that messages conforming to the consent request format and semantic should be much easier to deal with by using other antispam tools and controls. However, this is my guess, you know better than me. > Since any other action will be performed as usual, there will be > no visible advantage resulting from the framework. That state of affairs > will never be an incentive for widespread adoption, and, on the other > hand, without widespread adoption the framework will always require that > disappointing stream doubling. Well, this stream doubling is something many already do, keeping one address for close friends and business partners, not disclosing it in order to avoid spam and other messages. But again you're right, the framework would need reach a critical mass in some time, or it would be abandoned even by early adopters. Regards, - Claudio -- Claudio Telmon claudio@telmon.org http://www.telmon.org From prussell@nd.edu Mon Jun 22 14:30:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BF43A697B for ; Mon, 22 Jun 2009 14:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MjRayV5jEz0 for ; Mon, 22 Jun 2009 14:30:12 -0700 (PDT) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id 462063A6971 for ; Mon, 22 Jun 2009 14:30:12 -0700 (PDT) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5MLQmHF018159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jun 2009 17:26:49 -0400 Received: from [172.19.226.96] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n5MLUPmH007552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jun 2009 17:30:25 -0400 (EDT) Message-ID: <4A3FF7F1.1060705@nd.edu> Date: Mon, 22 Jun 2009 17:30:25 -0400 From: Paul Russell User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> In-Reply-To: <4A3FF3AF.9030401@telmon.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Mon, 22 Jun 2009 17:26:49 EDT Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:30:13 -0000 On 6/22/2009 17:12, Claudio Telmon wrote: > Well, this stream doubling is something many already do, keeping one > address for close friends and business partners, not disclosing it in > order to avoid spam and other messages. But again you're right, the > framework would need reach a critical mass in some time, or it would be > abandoned even by early adopters. Back in the day when most spammers obtained addresses by harvesting them from web pages, you could, for the most part, keep a mailbox spam-free by disclosing your email address only to those from whom you wanted to receive email. The sun set on that scene long ago. Spammers generate potential recipient addresses based on common names and naming schemes, or harvest them from address books and private mail archives on compromised systems. Security by obscurity seldom works for very long. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame From steve@blighty.com Mon Jun 22 14:37:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D203A6971 for ; Mon, 22 Jun 2009 14:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGKRFHzSz2Ou for ; Mon, 22 Jun 2009 14:37:02 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 983443A6A03 for ; Mon, 22 Jun 2009 14:37:01 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id D613E80D62 for ; Mon, 22 Jun 2009 14:37:03 -0700 (PDT) Message-Id: <2CCA5AC9-154F-494B-B9BB-63D83AC4393C@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3FF7F1.1060705@nd.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 14:37:16 -0700 References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:37:03 -0000 On Jun 22, 2009, at 2:30 PM, Paul Russell wrote: > On 6/22/2009 17:12, Claudio Telmon wrote: >> Well, this stream doubling is something many already do, keeping one >> address for close friends and business partners, not disclosing it in >> order to avoid spam and other messages. But again you're right, the >> framework would need reach a critical mass in some time, or it >> would be >> abandoned even by early adopters. > > Back in the day when most spammers obtained addresses by harvesting > them from > web pages, you could, for the most part, keep a mailbox spam-free by > disclosing > your email address only to those from whom you wanted to receive > email. The sun > set on that scene long ago. Spammers generate potential recipient > addresses > based on common names and naming schemes, or harvest them from > address books and > private mail archives on compromised systems. Security by obscurity > seldom > works for very long. Also any actual usage of an email address leads to it being in a mailbox on a Windows machine. That, in turn, leads to it being sprayed all over the internet by viruses, and hence harvested by spammers. I have lots of uniquely created addresses that were provably not guessed that get a lot of spam via that route. Cheers, Steve From claudio@telmon.org Mon Jun 22 14:44:56 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FDE3A6B55 for ; Mon, 22 Jun 2009 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKUcJifHaH1k for ; Mon, 22 Jun 2009 14:44:55 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id 381683A6898 for ; Mon, 22 Jun 2009 14:44:55 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+GX6NyYVUKpw; Mon, 22 Jun 2009 23:45:09 +0200 Message-ID: <4A3FFB64.6030409@telmon.org> Date: Mon, 22 Jun 2009 23:45:08 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> In-Reply-To: <4A3FF7F1.1060705@nd.edu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:44:56 -0000 Paul Russell wrote: > On 6/22/2009 17:12, Claudio Telmon wrote: >> Well, this stream doubling is something many already do, keeping one >> address for close friends and business partners, not disclosing it in >> order to avoid spam and other messages. But again you're right, the >> framework would need reach a critical mass in some time, or it would be >> abandoned even by early adopters. > > Back in the day when most spammers obtained addresses by harvesting them from > web pages, you could, for the most part, keep a mailbox spam-free by disclosing > your email address only to those from whom you wanted to receive email. The sun > set on that scene long ago. Spammers generate potential recipient addresses > based on common names and naming schemes, or harvest them from address books and > private mail archives on compromised systems. Security by obscurity seldom > works for very long. > In this respect, the framework should be effective, since spammers would also need to generate the consent token, which they can't. When harvesting email addresses (and tokens) from compromised systems, the framework provides a way to detect who was compromised and to invalidate the token. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From rsk@gsp.org Mon Jun 22 14:52:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922F83A6971 for ; Mon, 22 Jun 2009 14:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTr7MkK2Sg0F for ; Mon, 22 Jun 2009 14:52:42 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id C43A13A6898 for ; Mon, 22 Jun 2009 14:52:42 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5MLqu0V025279 for ; Mon, 22 Jun 2009 17:52:58 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5MLmQPs005651 for ; Mon, 22 Jun 2009 17:48:26 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5MLqpKB002659 for ; Mon, 22 Jun 2009 17:52:51 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5MLqpT0002658 for asrg@irtf.org; Mon, 22 Jun 2009 17:52:51 -0400 Date: Mon, 22 Jun 2009 17:52:51 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090622215251.GA2137@gsp.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3FFB64.6030409@telmon.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:52:43 -0000 On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote: > In this respect, the framework should be effective, since spammers would > also need to generate the consent token, which they can't. Why not? They can run any code they want on any compromised system, therefore they can generate the consent token the same way the former owner of that system could. ---Rsk From rsk@gsp.org Mon Jun 22 14:54:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D153A6898 for ; Mon, 22 Jun 2009 14:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqvZBxo7n1-F for ; Mon, 22 Jun 2009 14:54:05 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 953303A6D5C for ; Mon, 22 Jun 2009 14:53:45 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5MLrx3G010401 for ; Mon, 22 Jun 2009 17:54:00 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5MLnTWd015151 for ; Mon, 22 Jun 2009 17:49:29 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5MLrsGa002717 for ; Mon, 22 Jun 2009 17:53:54 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5MLrsGg002716 for asrg@irtf.org; Mon, 22 Jun 2009 17:53:54 -0400 Date: Mon, 22 Jun 2009 17:53:54 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090622215354.GC2137@gsp.org> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> <4A3F7AAC.8030402@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:54:06 -0000 On Mon, Jun 22, 2009 at 02:59:01PM +0100, Ian Eiloart wrote: > We use IP address reputation services because there's nothing else we can > use, in the absence of some way to authenticate the sender address. Of > course, those mechanisms exist and are widely deployed but not > universally, or even by a majority of domains. When they become so, we'll > no doubt see domain based reputation services, and even address based > reputation services being used as much as IP address reputation services > are. I don't think so. Domains and addresses are nearly-free and disposable, so spammers could easily render both pointless exercises whenever it suited them to do so. Given that registrars are quite happy to continue selling dirt-cheap domains by the thousands to even the worst spammers (and registrars ARE spammers) it will always be possible for abusers to come up with another domain and another email address -- or another ten thousand of each -- whenever it suits them. Network space is not quite so easy to come by, so I think we stand a better chance keeping track of allocations. ---Rsk From rsk@gsp.org Mon Jun 22 15:08:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84F228C266 for ; Mon, 22 Jun 2009 15:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP9LJMh7HWHP for ; Mon, 22 Jun 2009 15:08:03 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id D1B3728C270 for ; Mon, 22 Jun 2009 15:08:02 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5MLr0aY011171 for ; Mon, 22 Jun 2009 17:53:00 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5MLmT87019017 for ; Mon, 22 Jun 2009 17:48:29 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5MLqsTf002682 for ; Mon, 22 Jun 2009 17:52:54 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5MLqsTU002681 for asrg@irtf.org; Mon, 22 Jun 2009 17:52:54 -0400 Date: Mon, 22 Jun 2009 17:52:54 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090622215254.GB2137@gsp.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <2CCA5AC9-154F-494B-B9BB-63D83AC4393C@blighty.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CCA5AC9-154F-494B-B9BB-63D83AC4393C@blighty.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:08:03 -0000 On Mon, Jun 22, 2009 at 02:37:16PM -0700, Steve Atkins wrote: > Also any actual usage of an email address leads to it being in a mailbox > on a Windows machine. That, in turn, leads to it being sprayed all over > the internet by viruses, and hence harvested by spammers. > > I have lots of uniquely created addresses that were provably not guessed > that get a lot of spam via that route. Precisely correct, and worth emphasizing. I've gone so far as to deliberately embed non-guessable addresses in the headers of single messages sent to single recipients -- and have subsequently received spam at some of them. And of course addresses used repeatedly with multiple recipients tend to attract spam much quicker, since such usage increases the probability that the addresss will show up on a compromised system. It's no longer possible to keep any email address that's actually used out of the hands of spammers, at least not for long. (I often find it ironic how many people using obfuscated domain registration, putatively to keep addresses away from spammers, are running Windows on their desktops or laptops, and thus are either (a) already compromised or (b) going to be compromised.) ---Rsk From steve@blighty.com Mon Jun 22 15:08:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F7528C278 for ; Mon, 22 Jun 2009 15:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePmXFfAz3yO4 for ; Mon, 22 Jun 2009 15:08:07 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 7CF2828C279 for ; Mon, 22 Jun 2009 15:08:07 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 41E6280FE9 for ; Mon, 22 Jun 2009 15:08:07 -0700 (PDT) Message-Id: <09283EE0-0252-4DD0-9BDA-FAA9B1B10C4A@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <20090622215354.GC2137@gsp.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 15:08:17 -0700 References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> <4A3F7AAC.8030402@tana.it> <20090622215354.GC2137@gsp.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:08:08 -0000 On Jun 22, 2009, at 2:53 PM, Rich Kulawiec wrote: > On Mon, Jun 22, 2009 at 02:59:01PM +0100, Ian Eiloart wrote: >> We use IP address reputation services because there's nothing else >> we can >> use, in the absence of some way to authenticate the sender address. >> Of >> course, those mechanisms exist and are widely deployed but not >> universally, or even by a majority of domains. When they become so, >> we'll >> no doubt see domain based reputation services, and even address based >> reputation services being used as much as IP address reputation >> services >> are. > > I don't think so. Domains and addresses are nearly-free and > disposable, > so spammers could easily render both pointless exercises whenever it > suited them to do so. Given that registrars are quite happy to > continue > selling dirt-cheap domains by the thousands to even the worst spammers > (and registrars ARE spammers) it will always be possible for abusers > to > come up with another domain and another email address -- or another > ten > thousand of each -- whenever it suits them. Network space is not > quite > so easy to come by, so I think we stand a better chance keeping > track of > allocations. The critical point here is that while it's easy to cycle through domains, only those who are doing Bad Stuff will do so. If you're sending wanted email then the reputation associated with any reputation key (including domains) will increase, and quality of delivery will continue to improve. If you're sending unwanted email then the associated reputation will decrease and delivery rates will drop. Because of that, people sending bad email will cycle through reputation identifiers rapidly, meaning that their reputation is never better than that of a brand new identifier, but not usually much worse. That makes reputation of this sort (whether it be IP based, authenticated domain based or anything else where it's easy to create a new reputation key, but hard to steal someone elses) is extremely useful for identifying mail that's likely to be wanted, and not really great for identifying mail that's likely to be unwanted. It's not something that's useful on it's own, but it's incredibly useful when used in conjunction with other approaches. Cheers, Steve From claudio@telmon.org Mon Jun 22 15:14:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18CF3A6B2F for ; Mon, 22 Jun 2009 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+PHnXEg63+O for ; Mon, 22 Jun 2009 15:14:17 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 51F853A67E6 for ; Mon, 22 Jun 2009 15:14:17 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+hp3TxXSFvHa; Tue, 23 Jun 2009 00:14:31 +0200 Message-ID: <4A400246.9060103@telmon.org> Date: Tue, 23 Jun 2009 00:14:30 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> In-Reply-To: <20090622215251.GA2137@gsp.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:14:18 -0000 Rich Kulawiec wrote: > On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote: >> In this respect, the framework should be effective, since spammers would >> also need to generate the consent token, which they can't. > > Why not? They can run any code they want on any compromised system, > therefore they can generate the consent token the same way the former > owner of that system could. The owner of the compromised system can only generate tokens then accepted by his address's MTA, the same can the spammer that compromised the system. The attacker can collect the tokens provided to the system owner in order to communicate with other people. It will then be able to send spam to the owner's correspondents. These, in turn, can see that spam arrives with the tokens they provided to the system owner, inform the system owner about this fact and invalidate the tokens. Once the system security is "restored", the spammer is left with useless tokens. Collected consent-protected addresses are useless without valid tokens. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From lyndon@orthanc.ca Mon Jun 22 15:30:58 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5897128C276 for ; Mon, 22 Jun 2009 15:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+pLBTQqcLCH for ; Mon, 22 Jun 2009 15:30:57 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by core3.amsl.com (Postfix) with ESMTP id 4C5E528C10B for ; Mon, 22 Jun 2009 15:30:57 -0700 (PDT) Received: from [192.168.0.42] (S01060011242eafe2.cg.shawcable.net [68.145.131.177]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n5MMVAsc093933 for ; Mon, 22 Jun 2009 16:31:10 -0600 (MDT) (envelope-from lyndon@orthanc.ca) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orthanc.ca; s=2009-1; t=1245709871; bh=O2Y2uJK7w61q67MA/O1IArsVJSCUtvqvVqtWFbfwDXY=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=CNM9fddPqlg1mxk5MPe6iyKCPJRSWu/fqMYcPkV2i2PRw82341PSnAcf7qT1IZoPc pJQRAz07TMdg89NiVpuTxyMaMrFkoWzMeGvyU7blXWT/kTohJkpa0kt5mE/W/V8UUJ 9IphPH24SYQlSL/dfe/MYzTRSolirdvwlN2npjKhf6iwKreEtMGKzkacivRhqWNG4A rUoeuMdum13RlsTSwAgtxPy4vHW74aUDlIjwf5tMZVM5pKDUUwLxT6VoO3IVnD1oMe PAvS/0i/qq0BS5p0+TFDduqA0ZBAJv6cQwjGxZPTCCWjV/KYLJYKW0OZMkWijSJlA6 LPG1qoPgl2DDA== From: Lyndon Nerenberg To: Anti-Spam Research Group - IRTF In-Reply-To: <4A400246.9060103@telmon.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> Content-Type: text/plain Date: Mon, 22 Jun 2009 16:31:04 -0600 Message-Id: <1245709864.77647.26.camel@legolas.orthanc.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:30:58 -0000 On Tue, 2009-06-23 at 00:14 +0200, Claudio Telmon wrote: > These, in turn, can see that spam > arrives with the tokens they provided to the system owner, inform the > system owner about this fact and invalidate the tokens. Once the > system > security is "restored", the spammer is left with useless tokens. > Collected consent-protected addresses are useless without valid > tokens. All of which puts the burden once again -- or 'still' -- on the backs of the innocent victims. This doesn't solve anything. From dotis@mail-abuse.org Mon Jun 22 15:45:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFBC28C21C for ; Mon, 22 Jun 2009 15:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhRgXuu8S6EX for ; Mon, 22 Jun 2009 15:45:19 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3F61D3A68BB for ; Mon, 22 Jun 2009 15:45:19 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 215F0A9443D for ; Mon, 22 Jun 2009 22:45:32 +0000 (UTC) Message-Id: <9C2ED955-306F-4633-ACFB-B99BBF226900@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <7ae58c220906221313n6e39d3c1o6591596f6c2b8b9@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 15:45:31 -0700 References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> <41937DE9-BAF3-486B-953E-8C638F3A49D2@mail-abuse.org> <7ae58c220906221313n6e39d3c1o6591596f6c2b8b9@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:45:20 -0000 On Jun 22, 2009, at 1:13 PM, Dotzero wrote: > Doug, > > I'd take your discussions of SPF more seriously if you would stop > conflating SPF and Sender-ID. They are two different animals. SPF > (the specification) does not include anything called PRA. Sender-ID > includes the concept of PRA. PRA is broken in the spec so there > isn't any purpose in spending time discussing it. All one needs to > do is look at the paragraph that states that if a sender field > exists you set the PRA to that. This bypasses any SPF record > published for the Mail From (envelope sender) domain. End of > discussion. The SPF (RFC 4408) lacks a means to constrain the scope of authorization records to just Mail-From. Sender-ID (RFC 4406) section 3 allows SPF (RFC 4408) records to authorize MTAs based upon PRA headers, and perhaps failing that, upon the Mail-From parameter. RFC 4406 section 3.1 modifies RFC 4408 versioning and adds a scope parameter. Per RFC 4406 section 3.4, the unmodified SPF record is to be considered the same as spf2.0/mfrom,pra. :^( Section 3.4 of RFC 4406 also states: ,--- If the information in a "v=spf1" record is not correct for a PRA check, administrators SHOULD publish either an "spf2.0/pra" record with correct information or an "spf2.0/pra ?all" record indicating that the result of a PRA check is explicitly inconclusive. '--- Per RFC 4406, when PRA authorization fails, an attempt to verify Mail- From authorization might be attempted. When only RFC 4408 has been relied upon, the Mail-From domain may inadvertently offer authorization based upon PRA headers. In this case, how SPF records are used is uncontrolled. From an overhead standpoint, RFC 4406 potentially doubles the overhead related to SPF record resolution. Although RFC 4406 recommends against use of MTAs that "lie" about local-parts, it failed to exclude macro use, or to consider what happens when providers do not restrict the use of domains in originating headers, in addition to the use of local-parts. Email would have likely faired much better by recommending immediate rejection, use of RFC 3464, and minimal DSN content with"multipart/ report" content types. -Doug From claudio@telmon.org Mon Jun 22 16:19:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF623A69D4 for ; Mon, 22 Jun 2009 16:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw7QC2LWoXRA for ; Mon, 22 Jun 2009 16:19:39 -0700 (PDT) Received: from slim-2c.inet.it (slim-2c.inet.it [213.92.5.123]) by core3.amsl.com (Postfix) with ESMTP id 450DD3A6A26 for ; Mon, 22 Jun 2009 16:19:39 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-2c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+TNlx3NGiR4q; Tue, 23 Jun 2009 01:19:54 +0200 Message-ID: <4A401199.6010502@telmon.org> Date: Tue, 23 Jun 2009 01:19:53 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> In-Reply-To: <1245709864.77647.26.camel@legolas.orthanc.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 23:19:40 -0000 Lyndon Nerenberg wrote: > All of which puts the burden once again -- or 'still' -- on the backs of > the innocent victims. This doesn't solve anything. I'm probably missing your point. I'm corresponding with person A. I give him a token he can use to send me messages. He is careless, and has his system compromised, so a spammer can take that token and use it for sending me spam. I would feel more a victim of A than a victim of the spammer. This framework takes the problem at the level of a relationship between me and somebody who doesn't handle the relationship with proper care. The system compromise is an accident that is known to happen to careless people. By using this framework, I can give another opportunity to A, by informing him of the problem, reprimand him, talk about this with our friends, invalidate the token and send him another one, or I can just close the (email) relationship. The same if the token is directly provided by A to other undesired correspondents. These are things I cannot do if I just look at spam messages. Also, I can restore a situation where the information in the hands of the spammer is useless, and at almost no cost, so I wouldn't say that it doesn't solve anything. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From dotis@mail-abuse.org Mon Jun 22 18:09:07 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB033A6B54 for ; Mon, 22 Jun 2009 18:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPCRpEVwrhXE for ; Mon, 22 Jun 2009 18:09:06 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id EFCFE3A6E02 for ; Mon, 22 Jun 2009 18:08:55 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id E3F5DA94439 for ; Tue, 23 Jun 2009 01:09:11 +0000 (UTC) Message-Id: <5AB32FFA-A830-4BB6-BEFC-EBA58CC090E4@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A3FFB64.6030409@telmon.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 18:09:11 -0700 References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 01:09:07 -0000 Claudio, An alternative for tokens would be to offer message links. Rather than sending messages, a reference to a message is exchanged instead. The link format associated with the message should allow recipients a means to know who issued the message. This would eliminate a need to track delivery status. Unless the recipient follows the link, the message would not be considered delivered. Receiving MTAs could offer a menu to allow recipients a means to automatically fetch messages from specific links as a method to save time when online, especially when dealing with slow uplinks. This mode of operation might be globally used to ensure compatibility with existing MUAs or domains that don't support this mode of exchange. Importantly, this method would not represent a major change in how email is currently handled, however authentication would become inherent with the transfer. -Doug From sethb@panix.com Mon Jun 22 20:56:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E663A6C01 for ; Mon, 22 Jun 2009 20:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljzY3SKRLP98 for ; Mon, 22 Jun 2009 20:56:36 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id E0C6A3A6BE0 for ; Mon, 22 Jun 2009 20:56:35 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 6E3141F5AE for ; Mon, 22 Jun 2009 23:56:51 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id 32562242FF; Mon, 22 Jun 2009 23:56:51 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A3F63BE.1030303@tana.it> (message from Alessandro Vesely on Mon, 22 Jun 2009 12:58:06 +0200) References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <4A3F63BE.1030303@tana.it> Message-Id: <20090623035651.32562242FF@panix5.panix.com> Date: Mon, 22 Jun 2009 23:56:51 -0400 (EDT) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 03:56:40 -0000 Alessandro Vesely wrote: > As for forcefully disabling accounts, one needs a legal authority to > break a commercial agreement. You mean the way the spammers get a court order before they violate their agreement not to spam? The typical ISP agreement says the ISP can close the account for abuse, and the ISP gets to determine what is abuse. Seth From vesely@tana.it Mon Jun 22 22:22:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844DE3A689F for ; Mon, 22 Jun 2009 22:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQAWiOUOUUMw for ; Mon, 22 Jun 2009 22:22:07 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id EFEE03A681F for ; Mon, 22 Jun 2009 22:22:06 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 07:22:20 +0200 id 00000000005DC031.000000004A40668C.00003343 Message-ID: <4A4066A0.50404@tana.it> Date: Tue, 23 Jun 2009 07:22:40 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3FCD11.4080702@terabites.com> In-Reply-To: <4A3FCD11.4080702@terabites.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 05:22:08 -0000 Gordon Peterson wrote: > > Except that you cannot reliably determine whether a message is spam. > > UCE isn't the only issue. The issue is whether it's something that the > recipient wants to receive, or doesn't want to see. What if I don't like to see bad news? > > Machines do not understand human language. [...] > > I wouldn't "kill" stuff, unless the user has specified rules under which > they are willing to summarily kill it. I think it's generally > worthwhile to file stuff on a local hard drive at the recipient, hard > drive space is cheap, so that they can go back and search for something > that maybe got routed to the spam folder that shouldn't have been. Are senders required to send an SMS to prompt recipients to go search for their mail? Why don't we just use SMS transport then? We can still store it on our hard disks via bluetooth connections... > Deterministically bad or incorrect is not an improvement. The finely > grained rules I am talking about are absolutely deterministic, in any > case... even if they are hard for spammers to determine. They are not. You may hold they are deterministic since they are the output of a deterministic machine. However, from users' points of view, both senders and recipients, based on just the data that each one sees, the behavior is randomly intermittent. In facts, spammers and friends are treated alike. Making friend or foe determinations based on authentication would allow to discern more consistently. > > IMHO, the correct way to go is to have a (weak) authentication scheme > that works well enough for most relevant cases, and at the same time > keep the existing system as a compatibility option for the cases where > it doesn't work. > > > If you want to use prehistoric appliances deploying obsolete mail > transmission methods that have historically proven to be vulnerable to > spammers, > > All mail can be vulnerable to spammers. But: > > 1) you can eliminate the shadows and tricks they use to conceal > themselves; Not quite. E.g., Bill recently suggested, and I agree, that the single most effective method is using Spamhaus Zen list. Why would people use it if they could eliminate shadows and tricks spammers use? > 2) you can set up rules to eliminate the great majority of bogus > stuff (and I continue to add rules to my personal copy of Thunderbird on > an ongoing basis); One could generate all combination of words and then look for those that make sense. That collection would include most literature masterpieces. It is not deemed the most effective method for creating new ones, though. BTW, how would your rules behave at that? > > (and wait until spammers decide to > relate recipients to the From: addresses that they whitelist.) > > They have no way to determine what addresses are and are not > whitelisted, and what the rules are for a given recipient. There are places where they can sniff mail traffic. Infected machines is one, but I guess there are more, possibly related with spyware (too many times sending a sporadic mail abroad starts a sequence of spam apparently unrelated, except for the language; and I don't believe all of those recipients were infected, as some were part of tough organizations.) They could easily try and pick your whitelisted addresses from the recipients you write to, for example. I think they don't do it because they don't need it, yet. > > Try port 587. > > How about if he's sitting at a desktop machine inside the customer's > office? He's not going to be able to reconfigure the mail software he's > sitting in front of. Webmail > Fine. I am willing to simply decree that (for example) I don't accept > HTML mail, big messages, or attachments from people I don't know. This > doesn't preclude people from contacting me, only preventing them from > abusing me (by whatever my own definition of "abuse" is, and ONLY MY > DEFINITION MATTERS!). There are legitimate senders who use HTML just because it may look nicer, and is very difficult to acquaint them with the technical details that make it bad. Given that, you can delete their messages without telling, or reject them with an appropriate message. For a number of reasons, complicated rules are fired after the message has been accepted, and they may result in deleting or hiding the message. The more often that happens, the more misunderstandings. You may call that anything but a reliable system. > I think the place to implement these tools is at the e-mail client > software level, where it is integrated and maps well with the user > interface that the user is familiar to with their e-mail. Hmm... and the desktop machine inside the customer's office? From vesely@tana.it Mon Jun 22 22:30:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8C03A697E for ; Mon, 22 Jun 2009 22:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrSS7BuzXWaf for ; Mon, 22 Jun 2009 22:30:24 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 58A963A6882 for ; Mon, 22 Jun 2009 22:30:24 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 07:30:39 +0200 id 00000000005DC031.000000004A40687F.00003469 Message-ID: <4A406894.3040507@tana.it> Date: Tue, 23 Jun 2009 07:31:00 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3FBAAE.4080100@cybernothing.org> In-Reply-To: <4A3FBAAE.4080100@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] MUA as MSA or MTA X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 05:30:25 -0000 J.D. Falk wrote: > Alessandro Vesely wrote: > >> Being suspicious about their ESPs, those users may prefer to >> deliver directly whenever possible. That is the only reason I see for >> attempting a direct delivery first, and it is a largely suboptimal >> solution anyway (e.g. it provides no reliable storage for sent messages.) > > What you're describing, here, is a vanishingly tiny minority of users. Not if you think of all the intermediate measures, from exim+mutt to ibm.com, say. Devising a clever configuration that allows to relay directly or route to a smarthost based on sound principles would be useful almost everywhere. For privacy, I, for one, wouldn't like _all_ my mail to go through gmail. Too much rope. For efficiency, offices with a few or more people exchange most of their mail internally. Does it make sense to cross the ocean and back? In addition, some like to control newsletters notifications as directly as possible, including having the final MTA's response. However, even a large company my find out that delivering some mail trough a large MSA may increase their deliverability. (I'm not sure gmail would still be free for ibm.com using it as a smarthost, but it might.) From vesely@tana.it Mon Jun 22 23:01:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A228C1BE for ; Mon, 22 Jun 2009 23:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6h4a9IxHAQG for ; Mon, 22 Jun 2009 23:01:35 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E6F363A6E3F for ; Mon, 22 Jun 2009 23:01:34 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 08:01:48 +0200 id 00000000005DC031.000000004A406FCC.00003783 Message-ID: <4A406FE2.1020800@tana.it> Date: Tue, 23 Jun 2009 08:02:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <4A3F63BE.1030303@tana.it> <20090622175230.GA57980@verdi> In-Reply-To: <20090622175230.GA57980@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] "Affiliation" X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 06:01:36 -0000 John Leslie wrote: >> [CSV] didn't help retrieving the responsible domain, though. > > CSV intended to use the EHLO string _as_ the responsible domain, even > though it might be one of several subdomains under a single management. Large organizations are often partitioned into (proper) subdomains, more or less independent from one another. OTOH single mailout hosts names may also be considered a (degenerate) subdomain. >> Furthermore, it didn't do ranges, thus making it laborious to deny >> sending to a bunch of hosts. > > I agree it didn't "do ranges", since it seemed appropriate to allow > separate reputations for separate EHLO names. Interesting. However, it is useless to separate reputation of different EHLO names belonging to an array of mailout hosts where a specific one is chosen based on traffic optimization and may even change on retries. >> AFAIK, all discussions eventually reach the conclusion that the >> receiving server does not know which domain administers the client >> MTA. > > CSV was intended to address exactly that problem. We felt that the > vast majority of domains _could_ get by with half a dozen IP addresses > returned by a A)ddress record, and that for those that couldn't, the > ability to have separable reputations was an _advantage_. For a > reputation service, more than one reputation record per domain actively > sending (reasonable) email seemed simple enough. OTOH, it is more difficult to track subdomains. A spammer can easily add new names at incredible rates. What about DKIM's distinction between domain (d) and identity (i)? As clever as DKIM may bee, I never noticed mail messages altered in transit, and would be curious to know how many filter look at its signature headers for the sole purpose of extracting the affiliation. > I agree that "affiliation" was not the best choice of words in > draft-ietf-marid-csv-csa-02. "Affiliation" should be multi-valued, > with an individual sending MTA able to affiliate with multiple > entities. > > OTOH, "identity" isn't quite right either. Though it is the term > used in RFC 2821, that RFC in no sense requires that the "identity" > identify a single server. John K. has been very clear on that point. Section 2.3.5 says The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4. It is true that section 4.1.4 specifies that giving the affiliation instead of the host name cannot be punished by rejecting messages. However, that wording obviously implies that no reliable affiliation information can be derived from the EHLO name. John himself suggested to use VHLO if affiliation is required. In his words Although I'd predict that you'd have trouble getting it off the ground, another possibility would be to propose to replace EHLO with a validated-hello command, VHLO, which would be just like EHLO except for support for a different argument architecture. [http://www.imc.org/ietf-smtp/mail-archive/msg05444.html] >> Declaring the affiliation is VHLO's raison d'etre. > > Hmm... I still think "affiliation" deserves to be multi-valued... In what sense? In the vhlo draft[1] I define two domains compatible if they share at least one primary mail exchanger. Would that be a multi-affiliation example? [1] http://tools.ietf.org/html/draft-vesely-vhlo From vesely@tana.it Mon Jun 22 23:21:42 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E5228C276 for ; Mon, 22 Jun 2009 23:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFKroPMJYi5u for ; Mon, 22 Jun 2009 23:21:41 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1D4CD3A6E3F for ; Mon, 22 Jun 2009 23:21:40 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 08:21:56 +0200 id 00000000005DC02F.000000004A407484.000039BC Message-ID: <4A407499.1030401@tana.it> Date: Tue, 23 Jun 2009 08:22:17 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <2CCA5AC9-154F-494B-B9BB-63D83AC4393C@blighty.com> <20090622215254.GB2137@gsp.org> In-Reply-To: <20090622215254.GB2137@gsp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 06:21:42 -0000 Rich Kulawiec wrote: > On Mon, Jun 22, 2009 at 02:37:16PM -0700, Steve Atkins wrote: >> Also any actual usage of an email address leads to it being in a mailbox >> on a Windows machine. That, in turn, leads to it being sprayed all over >> the internet by viruses, and hence harvested by spammers. >> >> I have lots of uniquely created addresses that were provably not guessed >> that get a lot of spam via that route. > > Precisely correct, and worth emphasizing. I've gone so far as to > deliberately embed non-guessable addresses in the headers of single > messages sent to single recipients -- and have subsequently received spam > at some of them. And of course addresses used repeatedly with multiple > recipients tend to attract spam much quicker, since such usage increases > the probability that the addresses will show up on a compromised system. And are you sure their machines were actually infected? I experienced spam after sending to organizations that should be secured, e.g. nic.es. As I wrote a few minutes ago, I recognized the connection by timely receiving spam in the relevant foreign language. My guess is that spammers have also other means to sniff mail traffic. From claudio@telmon.org Tue Jun 23 00:26:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024983A63EC for ; Tue, 23 Jun 2009 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2zwe7PzV7xM for ; Tue, 23 Jun 2009 00:26:32 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 3D4F43A6922 for ; Tue, 23 Jun 2009 00:26:29 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+TyvQiuePKYt; Tue, 23 Jun 2009 09:26:43 +0200 Message-ID: <4A4083B2.8060905@telmon.org> Date: Tue, 23 Jun 2009 09:26:42 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <5AB32FFA-A830-4BB6-BEFC-EBA58CC090E4@mail-abuse.org> In-Reply-To: <5AB32FFA-A830-4BB6-BEFC-EBA58CC090E4@mail-abuse.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 07:26:34 -0000 Douglas Otis wrote: > Claudio, > > An alternative for tokens would be to offer message links. Rather than > sending messages, a reference to a message is exchanged instead. The > link format associated with the message should allow recipients a means > to know who issued the message. This would eliminate a need to track > delivery status. Unless the recipient follows the link, the message > would not be considered delivered. Receiving MTAs could offer a menu to > allow recipients a means to automatically fetch messages from specific > links as a method to save time when online, especially when dealing with > slow uplinks. This mode of operation might be globally used to ensure > compatibility with existing MUAs or domains that don't support this mode > of exchange. Importantly, this method would not represent a major > change in how email is currently handled, however authentication would > become inherent with the transfer. This seems to mix Internet mail 2000 with the consent framework. You suggest to put the token in the link, so that the receiver's notification agent can perform the same selection as the receiver's MTA in my proposal. While this would be possible, goals are different and implementations seem to be independent. It should work, from a technical perspective. However, Internet mail 2000 already has its own deployment issues, so mixing the two things seems to increase the deployment difficulties, which are already high. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From rsk@gsp.org Tue Jun 23 03:05:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0FE3A6E5A for ; Tue, 23 Jun 2009 03:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yur0fglunpK1 for ; Tue, 23 Jun 2009 03:05:34 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id BF9853A6C7E for ; Tue, 23 Jun 2009 03:05:33 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5NA5lvP028710 for ; Tue, 23 Jun 2009 06:05:49 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5NA1Fqa030378 for ; Tue, 23 Jun 2009 06:01:15 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5NA5gCN010762 for ; Tue, 23 Jun 2009 06:05:42 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5NA5guj010761 for asrg@irtf.org; Tue, 23 Jun 2009 06:05:42 -0400 Date: Tue, 23 Jun 2009 06:05:42 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090623100542.GA9628@gsp.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A400246.9060103@telmon.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 10:05:34 -0000 On Tue, Jun 23, 2009 at 12:14:30AM +0200, Claudio Telmon wrote: > The attacker can collect the tokens provided to the system owner in > order to communicate with other people. It will then be able to send > spam to the owner's correspondents. These, in turn, can see that spam > arrives with the tokens they provided to the system owner, inform the > system owner about this fact and invalidate the tokens. This is unworkable for multiple reasons, not the least of which of scale: as of a few years ago, there were at least a hundred million compromised systems, and the number today is certainly much higher. There's no good way to inform the former owners of those systems, there's no reason to believe that they'll see the notification (especially if automated, since the new owners of those systems can prevent them from seeing it), there's no way to stop those systems from emitting bogus notifications, the recipients' systems may themselves be compromised, etc. Not to mention it's a LOT of work for everyone to keep track of all these tokens. Any proposal (not just anti-spam) which depends on the presumption that end-user systems are secure or securable is dead-on-arrival *until* the zombie problem is solved, and there is at the moment nothing at all happening to indicate that problem is even being seriously addressed, let alone "solved". ---Rsk From claudio@telmon.org Tue Jun 23 03:47:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D5B28C2A2 for ; Tue, 23 Jun 2009 03:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbc3tfJg33iu for ; Tue, 23 Jun 2009 03:47:17 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id EC40A3A6E99 for ; Tue, 23 Jun 2009 03:47:16 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+hNh1BFhPGW0; Tue, 23 Jun 2009 12:47:31 +0200 Message-ID: <4A40B2C0.8090604@telmon.org> Date: Tue, 23 Jun 2009 12:47:28 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> In-Reply-To: <20090623100542.GA9628@gsp.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 10:47:18 -0000 Rich Kulawiec wrote: > This is unworkable for multiple reasons, not the least of which of scale: > as of a few years ago, there were at least a hundred million compromised > systems, and the number today is certainly much higher. There's no > good way to inform the former owners of those systems, there's no reason > to believe that they'll see the notification (especially if automated, > since the new owners of those systems can prevent them from seeing it), > there's no way to stop those systems from emitting bogus notifications, > the recipients' systems may themselves be compromised, etc. Not to > mention it's a LOT of work for everyone to keep track of all these tokens. While what you say is true in general, I think you missed a critical part of the consent framework I'm proposing. A consent-enabled address will only accept messages from senders that received a valid token for that address though some channel (usually, not email). That is, each sender will only have tokens for consent-enabled addresses he received a token for, which is comparable to the number of addresses he has in his address book. If the sender's system is compromised, the attacker/spammer will only collect tokens for these addresses. The spammer can send spam to any non-consent-enabled address, but this is outside the scope of the framework. The spammer can however send messages only to the consent-enabled addresses he has tokens for, which are the people in the address book of the compromised system. These are the (few) people the system owner is in direct contact with, which will detect which token is used in the spam they receive and therefore whose system was compromised. The owner of this system will be informed, possibly not via email, and the tokens will be invalidated anyway. The other millions of compromised hosts are not relevant in this scenario: even if the spammer distributes the tokens to these hosts, or sells the address and the token in a list, all this becomes useless once the token is invalidated, which should happen almost immediately after a couple of spam messages. At this point, those receiving the spam can decide if they want to issue a new token for the (once) compromised sender, provided that its host has been cleaned. If they keep receiving spam with the new token, they surely will revoke this token too, and will be put in front of the problem of their relationship with somebody that is not able to keep its system clean. With respect to consent-enabled addresses, it would turn the problem of informing the owners of millions of compromised systems, into a "local" problem of relationships inside small groups of people. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From iane@sussex.ac.uk Tue Jun 23 04:36:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7BAD3A6D08 for ; Tue, 23 Jun 2009 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F90BqoU6vXCP for ; Tue, 23 Jun 2009 04:36:54 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id D3D503A6CDF for ; Tue, 23 Jun 2009 04:36:53 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56877) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLOWA8-000D3G-68 for asrg@irtf.org; Tue, 23 Jun 2009 12:37:20 +0100 Date: Tue, 23 Jun 2009 12:36:59 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <1245709864.77647.26.camel@legolas.orthanc.ca> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> Originator-Info: login-token=Mulberry:01U57l3rz/U0OUCzlAv8TGE1hRuRYGOLbEyAk=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:36:54 -0000 --On 22 June 2009 16:31:04 -0600 Lyndon Nerenberg wrote: > On Tue, 2009-06-23 at 00:14 +0200, Claudio Telmon wrote: >> These, in turn, can see that spam >> arrives with the tokens they provided to the system owner, inform the >> system owner about this fact and invalidate the tokens. Once the >> system >> security is "restored", the spammer is left with useless tokens. >> Collected consent-protected addresses are useless without valid >> tokens. > > All of which puts the burden once again -- or 'still' -- on the backs of > the innocent victims. This doesn't solve anything. > That's the wrong test. The test should not be "does this mechanism place a burden on the innocent?". All new mechanisms do that. Instead, you should ask whether the mechanism places a disproportionate burden on the innocent. The burden should be at least somewhat less than the burden currently imposed by spammers. That's a much easier test to pass if you include the burden on sys-admins. However, the burden placed on end users should not be a cognitive burden - most won't cope. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Tue Jun 23 04:42:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC4B28C2B8 for ; Tue, 23 Jun 2009 04:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt5x5N7QC1w9 for ; Tue, 23 Jun 2009 04:42:08 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id DCD473A6D0F for ; Tue, 23 Jun 2009 04:42:07 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56947) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLOWJ7-000FXF-BY for asrg@irtf.org; Tue, 23 Jun 2009 12:42:43 +0100 Date: Tue, 23 Jun 2009 12:42:23 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A3FC7AD.2060307@terabites.com> References: <4A3FC7AD.2060307@terabites.com> Originator-Info: login-token=Mulberry:01gjhB9euZr1rDpZVX7l71rbRo6LBiT+Ve96M=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] Horses X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:42:09 -0000 --On 22 June 2009 13:04:29 -0500 Gordon Peterson wrote: > > > Yes, that's why we've been working on mail authentication a la DKIM for > > The point being that Aunt Martha's machine can be compromised, such that > even with her own IP, her habitual outgoing mail server, and her valid > credentials, it might still be shipping spam. It's not enough that it > LOOKS like (or even IS) coming from her... If Aunt Martha's spamming me, then I'll know it from the content. I can then help her fix the problem, provided the authentication tells me that her credentials have been used. Otherwise, I'll just put it down to spoofing. If I don't know Aunt Martha, I'll still want to alert her or her ISP that she's spamming. I don't care who the owner of the botnet is, it's Aunt Martha that can fix her machine. > just as it's not enough to see > that mail has your friend's return E-mail address if it's actually > Grouply spam. It's far better to see whether the incoming e-mail with > Martha's return address has all the typical things that Aunt Martha's > mail messages ACTUALLY HAVE (for example, does it use the 'stationery' > that she maybe 'always' uses?) Again, this is analogous to what humans > actually do when considering a suspect incoming e-mail message... does it > look the way you'd expect mail FROM THAT SENDER to actually look? What > yellow or red flags is it flying? This requires looking at the content, > too. > -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From claudio@telmon.org Tue Jun 23 04:59:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915EC28C2D5 for ; Tue, 23 Jun 2009 04:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOdfBrK8Pam0 for ; Tue, 23 Jun 2009 04:59:34 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id A695428C2D2 for ; Tue, 23 Jun 2009 04:59:33 -0700 (PDT) Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+PXmmAYmURBh; Tue, 23 Jun 2009 13:59:49 +0200 Message-ID: <4A40C3B4.5060103@telmon.org> Date: Tue, 23 Jun 2009 13:59:48 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:59:35 -0000 Ian Eiloart wrote: > However, the burden placed > on end users should not be a cognitive burden - most won't cope. If I understand what you mean, then IMHO this framework should pass this cognitive test, since the availability of tokens to correspondents (and spammers) should be easy to understand... well, much easier than failures of digital signatures, DSN, and locks on web pages, anyway... -- Claudio Telmon claudio@telmon.org http://www.telmon.org From sethb@panix.com Tue Jun 23 06:39:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BFB3A6A0B for ; Tue, 23 Jun 2009 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83B2UbM0MX+9 for ; Tue, 23 Jun 2009 06:39:26 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 07CE73A6956 for ; Tue, 23 Jun 2009 06:39:26 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id D83D5392AC for ; Tue, 23 Jun 2009 09:39:41 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id CABAC24289; Tue, 23 Jun 2009 09:39:41 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A40B2C0.8090604@telmon.org> (message from Claudio Telmon on Tue, 23 Jun 2009 12:47:28 +0200) References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> Message-Id: <20090623133941.CABAC24289@panix5.panix.com> Date: Tue, 23 Jun 2009 09:39:41 -0400 (EDT) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 13:39:26 -0000 Claudio Telmon wrote: > While what you say is true in general, I think you missed a critical > part of the consent framework I'm proposing. A consent-enabled > address will only accept messages from senders that received a valid > token for that address though some channel (usually, not > email). That is, each sender will only have tokens for > consent-enabled addresses he received a token for, which is > comparable to the number of addresses he has in his address book. If > the sender's system is compromised, the attacker/spammer will only > collect tokens for these addresses. What benefit does that offer over using tagged addresses (with the tag as the "consent token")? I do that now, for commercial mailers; when an address starts getting spammed, I turn it off. Sometimes, I give the company that got it a new address to use. Seth From iane@sussex.ac.uk Tue Jun 23 07:02:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2535128C351 for ; Tue, 23 Jun 2009 07:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w172pvHyzRZ for ; Tue, 23 Jun 2009 07:02:15 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id C8A6528C2EA for ; Tue, 23 Jun 2009 07:02:13 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:58577) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLP30I-000EM2-KC for asrg@irtf.org; Tue, 23 Jun 2009 15:02:42 +0100 Date: Tue, 23 Jun 2009 15:02:22 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090622215354.GC2137@gsp.org> References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> <4A3F7AAC.8030402@tana.it> <20090622215354.GC2137@gsp.org> Originator-Info: login-token=Mulberry:01sgVK6xtmuFDzcp5NHisler1eGH1rRRUrJ3A=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 14:02:16 -0000 --On 22 June 2009 17:53:54 -0400 Rich Kulawiec wrote: > On Mon, Jun 22, 2009 at 02:59:01PM +0100, Ian Eiloart wrote: >> We use IP address reputation services because there's nothing else we >> can use, in the absence of some way to authenticate the sender address. >> Of course, those mechanisms exist and are widely deployed but not >> universally, or even by a majority of domains. When they become so, >> we'll no doubt see domain based reputation services, and even address >> based reputation services being used as much as IP address reputation >> services are. > > I don't think so. Domains and addresses are nearly-free and disposable, > so spammers could easily render both pointless exercises whenever it > suited them to do so. Yes, they are. But, acquiring reputation for a domain is a different question. Sure, a new email address doesn't have a negative reputation, but it doesn't have a positive reputation either. Mail server configurations of the future will likely reject email from addresses with negative reputations (except where whitelisted), accept email from addresses with good positive reputations (except where blacklisted), and do other stuff with addresses without reputation (including newly registered addresses, and previously unused addresses. What will they do with the addresses without reputation scores? Well, at worst only what they do now - examine the content, check the IP address reputation, etc. But, they'll also have a host of other things they can do, including domain based whitelisting and blacklisting (pointless without authentication). And, they'll be able to - for example - rate limit mail from unusual addresses until the new addresses have acquired sufficient reputation. And, if they do use new domains for spam, we can track them through the registrars. Unresponsive registrars will acquire poor reputation - so expect to see registrar based reputation services, too. > Given that registrars are quite happy to continue > selling dirt-cheap domains by the thousands to even the worst spammers > (and registrars ARE spammers) it will always be possible for abusers to > come up with another domain and another email address -- or another ten > thousand of each -- whenever it suits them. Network space is not quite > so easy to come by, so I think we stand a better chance keeping track of > allocations. Yes, but what's the point? I've never had any of my users ask me to whitelist an IP address. I've had plenty ask me to whitelist domains and specific addresses. We don't do that at the moment, because a whitelist entry is simply a hole in our spam defences. Oh, and notice that it hasn't actually worked very well. > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From claudio@telmon.org Tue Jun 23 07:22:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47EC3A6BE1 for ; Tue, 23 Jun 2009 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVEbMPfw21ay for ; Tue, 23 Jun 2009 07:22:07 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 3E2393A69DA for ; Tue, 23 Jun 2009 07:22:07 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+enHnkj59P3; Tue, 23 Jun 2009 16:22:22 +0200 Message-ID: <4A40E51D.7040307@telmon.org> Date: Tue, 23 Jun 2009 16:22:21 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> <20090623133941.CABAC24289@panix5.panix.com> In-Reply-To: <20090623133941.CABAC24289@panix5.panix.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 14:22:08 -0000 Seth wrote: > What benefit does that offer over using tagged addresses (with the tag > as the "consent token")? I do that now, for commercial mailers; when > an address starts getting spammed, I turn it off. Sometimes, I give > the company that got it a new address to use. It's quite similar. The framework is actually quite similar to anything that sets a different "tag" or "token" for different correspondents, and then accepts only messages carrying those tags somewhere in the message. I referred to "ham passwords" as an example, but in the paper I also cite tagged addresses (I call them "address name extensions", which as I understand it is one of the many names of this kind of mechanisms). There are some relevant differences between how tagged addresses are currently defined/deployed, and this proposal. I don't say that the same results couldn't be achieved with tagged addresses, but a framework similar to the one I've defined would be required in order to cope with these differences. The main problem is that tagged addresses would be disclosed every time messages are sent in Cc to many addresses. This opens to forgery, and most of the positive effects discussed until now in this thread were lost. A solution would require either not to send messages in Cc:, or to purge the messages from the tags when delivered to other recipients, which is the main task for the framework I've described. I think that tags/tokens in a separate header can ease this task, since addresses can be disclosed in many places, e.g. in the body of a message. Also, currently (but it doesn't need to be so), tags are bound to addresses and service providers, so distributing tags or moving to another provider would be complicated. The framework I've described provides an explicit solution to this, since it uses an SMTP extension that can be standardised. Finally, the framework provides a way to deal with consent requests (requests of contact from unknown people), that should reduce the risk of spam and malware. Again, this could be done also with tagged addresses. All in all, all I've described could be done with tagged addresses, but IMO it would end up with the same framework, just with tags/tokens put in a different, maybe less appropriate place. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From iane@sussex.ac.uk Tue Jun 23 08:18:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677A028C177 for ; Tue, 23 Jun 2009 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTkx04Wm55bu for ; Tue, 23 Jun 2009 08:18:30 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 6B8B028C172 for ; Tue, 23 Jun 2009 08:18:30 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49506) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLP6JS-000FBB-99 for asrg@irtf.org; Tue, 23 Jun 2009 16:19:04 +0100 Date: Tue, 23 Jun 2009 16:18:43 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A40C3B4.5060103@telmon.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> <4A40C3B4.5060103@telmon.org> Originator-Info: login-token=Mulberry:01ocKtvQojGyLiLwEfDegUNyAwBzrOFwToFi0=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 15:18:31 -0000 --On 23 June 2009 13:59:48 +0200 Claudio Telmon wrote: > Ian Eiloart wrote: > >> However, the burden placed >> on end users should not be a cognitive burden - most won't cope. > > If I understand what you mean, then IMHO this framework should pass this > cognitive test, since the availability of tokens to correspondents (and > spammers) should be easy to understand... well, much easier than > failures of digital signatures, DSN, and locks on web pages, anyway... It the behaviour of the user is required to change, then that's a bad thing. I've not read the spec, so I'm not judging this proposal. Just correcting the claim that you can't burden the use at all. You can, but ideally you want to do it in ways that the user doesn't notice. If your spec requires a user to find something in addition to an email address, then it needs to be extremely easy to do. Still, we're already in a position where people are fearful of publishing email addresses, so this spec might alleviate that problem. But, it isn't fundamental to combatting spam. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From dotis@mail-abuse.org Tue Jun 23 10:37:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9693328C399 for ; Tue, 23 Jun 2009 10:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiOAOrGHKEit for ; Tue, 23 Jun 2009 10:37:52 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 91B3D28C349 for ; Tue, 23 Jun 2009 10:37:52 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 77EBAA9443C for ; Tue, 23 Jun 2009 17:38:00 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A4083B2.8060905@telmon.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 10:38:00 -0700 References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <5AB32FFA-A830-4BB6-BEFC-EBA58CC090E4@mail-abuse.org> <4A4083B2.8060905@telmon.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 17:37:53 -0000 On Jun 23, 2009, at 12:26 AM, Claudio Telmon wrote: > > This seems to mix Internet mail 2000 with the consent framework. You > suggest to put the token in the link, so that the receiver's > notification agent can perform the same selection as the receiver's > MTA in my proposal. While this would be possible, goals are > different and implementations seem to be independent. It should > work, from a technical perspective. However, Internet mail 2000 > already has its own deployment issues, so mixing the two things > seems to increase the deployment difficulties, which are already high. Your strategy requires servicing a method that does not depend upon "pass-tokens" as a means to obtain them. The task of collecting source specific tokens represents a fair amount of administrative effort for both senders and recipients that is likely to be problematic. Not good. Spitting the email-address onto separate headers is problematic. In addition, what one MTA might understand may not apply to the subsequent. Review how one might use "+" : http://css.its.psu.edu/news/emailplus.html Then imagine this acceptance criteria is combined valid DKIM respondent's messages. As yet a better alternative, to thwart wasted and undesired exchanges, an exchange by reference offers an inherent means to authenticate sources without cryptography, and avoid undesired exchanges. -Doug From vesely@tana.it Tue Jun 23 10:39:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10D028C370 for ; Tue, 23 Jun 2009 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4db5fGzlTnQ9 for ; Tue, 23 Jun 2009 10:39:39 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A05FA28C3EC for ; Tue, 23 Jun 2009 10:38:46 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 19:39:01 +0200 id 00000000005DC02F.000000004A411335.00001394 Message-ID: <4A411335.3070507@tana.it> Date: Tue, 23 Jun 2009 19:39:01 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090617175332.5169.qmail@simone.iecc.com> <4A3B6E59.5010002@tana.it> <4A3F7AAC.8030402@tana.it> <20090622215354.GC2137@gsp.org> <09283EE0-0252-4DD0-9BDA-FAA9B1B10C4A@blighty.com> In-Reply-To: <09283EE0-0252-4DD0-9BDA-FAA9B1B10C4A@blighty.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 17:39:40 -0000 Steve Atkins wrote: >>> We use IP address reputation services because there's nothing else we >>> can use [...] >> >> I don't think so. Domains and addresses are nearly-free and disposable, >> so spammers could easily render both pointless exercises whenever it >> suited them to do so. Given that registrars are quite happy to continue >> selling dirt-cheap domains by the thousands to even the worst spammers >> (and registrars ARE spammers) it will always be possible for abusers to >> come up with another domain and another email address -- or another ten >> thousand of each -- whenever it suits them. Network space is not quite >> so easy to come by, so I think we stand a better chance keeping track of >> allocations. Maintaining reputation records based on domain is much easier than doing single email addresses, especially if one knows what egress anti-spam practices they deploy, and what's their policy for creating new accounts. In this case, mandating SUBMIT a la SPF shouldn't affect a domain's reputation; however, only messages that are relayed that way can be whitelisted on the basis that they come from a whitelisted domain. > The critical point here is that while it's easy to cycle through domains, > only those who are doing Bad Stuff will do so. > > If you're sending wanted email then the reputation associated with any > reputation key (including domains) will increase, and quality of delivery > will continue to improve. A domain changing ISP or location will most likely get new IP addresses. This noise is absent when tracking reputation by domain name. > If you're sending unwanted email then the associated reputation will > decrease and delivery rates will drop. Because of that, people sending > bad email will cycle through reputation identifiers rapidly, meaning that > their reputation is never better than that of a brand new identifier, > but not usually much worse. If whitelists by domain were the rule, newcomers would seek the endorsement of their business associations, reputable friends, and possibly even employees. They will introduce themselves, and avoid whois privacy concealments. Investing in such sort of vernissage for new IP addresses makes little sense. > That makes reputation of this sort (whether it be IP based, authenticated > domain based or anything else where it's easy to create a new reputation > key, but hard to steal someone elses) is extremely useful for identifying > mail that's likely to be wanted, and not really great for identifying > mail that's likely to be unwanted. It's not something that's useful on > it's own, but it's incredibly useful when used in conjunction with other > approaches. It's only natural to think that mail that's likely to be wanted shall take priority, as it does not require Bayesian content filtering, waiting for hashes from honeypots, and similar mumbo jumbos. Then, if whitelisted domains become widespread, we can peacefully harden the rules for filtering the rest. The point is, if it is easier and convenient, why isn't it plenty of RHSWLs out there? From rsk@gsp.org Tue Jun 23 13:37:46 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305CA28C3E7 for ; Tue, 23 Jun 2009 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02CmFhv0DfUO for ; Tue, 23 Jun 2009 13:37:45 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 10C0E3A6A89 for ; Tue, 23 Jun 2009 13:37:44 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5NKbxvv005084 for ; Tue, 23 Jun 2009 16:38:00 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5NKXP5U003380 for ; Tue, 23 Jun 2009 16:33:25 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5NKbrwG015115 for ; Tue, 23 Jun 2009 16:37:53 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5NKbrTJ015114 for asrg@irtf.org; Tue, 23 Jun 2009 16:37:53 -0400 Date: Tue, 23 Jun 2009 16:37:53 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090623203753.GA14617@gsp.org> References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A40B2C0.8090604@telmon.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:37:46 -0000 On Tue, Jun 23, 2009 at 12:47:28PM +0200, Claudio Telmon wrote: > While what you say is true in general, I think you missed a critical > part of the consent framework I'm proposing. A consent-enabled address > will only accept messages from senders that received a valid token for > that address though some channel (usually, not email). Yeah, I get that. But whatever that channel is, if it ultimately connects to a network endpoint that's compromised (more and more likely every day), or if it originates on a network endpoint that's compromised (likewise), then whatever is communicated via that channel can't be trusted. Moreover, even if the information that's communicated via that channel is authentic, any compromised endpoint can't be trusted to act on it properly. Maybe I'm not saying this very well. Let me try examples: Fred doesn't know Barney, but gets a request for consent: it looks plausible, so he grants it. But the request *wasn't* from Barney, it was from the malware on Barney's laptop, and now Fred not only has to deal with the spam, he's got to revoke the consent. Or: Wilma knows Betty, and sends a request for consent. Betty grants it, and things go fine, until the night Wilma's system is compromised and sends a dozen pieces of spam to Betty, who wakes up to it. (Why does this happen? Because the malware resident on Wilma's computer read the list of people-who-have-granted-consent-to-Wilma and targeted that first.) And so on, for all kinds of scenarios we could come up with. Yes, this is not a big problem for Fred or Betty, but when we multiply them by a hundred million, it's a pretty big problem. Which is why this idea sounds to me like an attempt to build a layer on top of a computing base (end-user systems) that are already compromised in enormous numbers. > With respect to consent-enabled addresses, it would turn > the problem of informing the owners of millions of compromised systems, > into a "local" problem of relationships inside small groups of people. I don't think so: there is no "local". Take for example, the members of this mailing list: presuming that all of us use a mail client which maintains an "address book" (and I don't) I'm certain that every one of us has at least one entry in it that nobody else on this list has. Most of us probably have *many* entries that nobody else on this list has. And some of those entries are mailing lists which forward to many people. Consider the extent of the damage that could be done if one of our systems started spewing -- and how many spam recipients would have to individually act in order to fully mitigate it. (Because A and B revoking their consent to mail from Z does not help C, D, E...) (Which raises another scalability question: how would those of us who have hundreds or thousands of correspondents find the time to manage all this? And any of us participating in any mailing list have many more potential correspondents: anyone on any of those lists might write to us off-list. Same for anyone with a web site or blog or running any other resource. A quick check of my personally-addressed and valid inbound mail -- that is, not including mailing lists, not including spam or phishes -- suggests that I've had over 11,500 correspondents in the past few years. That's a lot of tokens to keep track of. And that's just *me*.) Moreover, "informing the owners" has already proven to be a badly-losing strategy. *If* the owners actually receive such communication (telling them their system is probably compromised), they tend to either disbelieve it, ignore it, classify it as a phish--often correct, deny it, or act ineffectively to remedy the situation. No anti-spam scheme which requires effective, clueful participation by end-users has any chance of working: if they existed (in very large numbers) then we wouldn't have such a large spam problem because (a) their systems would be compromised in huge numbers and (b) they would have learned by now to never respond to any spam. ---Rsk From claudio@telmon.org Tue Jun 23 14:26:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DC928C0E2 for ; Tue, 23 Jun 2009 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axxbi-BQvqkD for ; Tue, 23 Jun 2009 14:26:46 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id CFBD33A6C99 for ; Tue, 23 Jun 2009 14:26:45 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+uYoCRdp927; Tue, 23 Jun 2009 23:26:59 +0200 Message-ID: <4A4148A3.9060903@telmon.org> Date: Tue, 23 Jun 2009 23:26:59 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <5AB32FFA-A830-4BB6-BEFC-EBA58CC090E4@mail-abuse.org> <4A4083B2.8060905@telmon.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 21:26:48 -0000 Douglas Otis wrote: > Your strategy requires servicing a method that does not depend upon > "pass-tokens" as a means to obtain them. Tokens can be obtained trough a "consent request" email message, which is a normal "text only" message with some constraints, or trough some other communication channel, including face by face meetings. Other, more powerful or easy means to obtain token would probably mean that the address owner would be flooded by spam hiding as consent request, or that tokens could be surreptitiously obtained. > The task of collecting source > specific tokens represents a fair amount of administrative effort for > both senders and recipients that is likely to be problematic. Not good. > This kind of evaluation is a critical one for the model the framework is based on. I take the cell phone numbers as an example. Most of us has hundreds of cell phone numbers, (almost) none of which has been obtained automatically. We took the burden of collecting them, and usually, if we need to contact somebody, and this person is willing to talk with us, we manage to get a phone number through one of the many communication channels that are offered to us. We also happily take the burden of distributing by hand our cell phone number, even if we could just put it on phone directories and have it automatically distributed, because we understand the advantages of not distributing it. I would say, most of us is more unhappy with the ease unknown people can contact us through email, than with the difficulties they have contacting us through our cell phone. > Spitting the email-address onto separate headers is problematic. In > addition, what one MTA might understand may not apply to the subsequent. > I think this is a technical problem the framework deals properly with. I may be missing something, of course. And, it requires an extension to SMTP. > Review how one might use "+" : > http://css.its.psu.edu/news/emailplus.html > Yes, I wrote a detailed answer on this to Seth in a previous message. > Then imagine this acceptance criteria is combined valid DKIM > respondent's messages. > I don't think this would solve the problem of address (that is, tag) disclosure in messages with multiple recipients. > As yet a better alternative, to thwart wasted and undesired exchanges, > an exchange by reference offers an inherent means to authenticate > sources without cryptography, and avoid undesired exchanges. Maybe I didn't catch this one, but tokens can be exchanged between users, so a "reference" would just be the use of the same token. But probably I didn't understand what "exchange by reference" is, google just gives me some cryptic pages on taxation and foreign currency :) -- Claudio Telmon claudio@telmon.org http://www.telmon.org From johnl@iecc.com Tue Jun 23 14:37:20 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD2C28C107 for ; Tue, 23 Jun 2009 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaiJtv0V-hlx for ; Tue, 23 Jun 2009 14:37:19 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 89C9B28C441 for ; Tue, 23 Jun 2009 14:37:19 -0700 (PDT) Received: (qmail 77273 invoked from network); 23 Jun 2009 21:37:30 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 23 Jun 2009 21:37:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=oH8/x2pHeqkp3UvFgiu7V7B90ebQxIdPD6q0MptHblw=; b=cDhpaesnsbKBmBZivp4LYGIfOxOgZ9vaSalLOdQ41nu3ypqiZcNfIiBW7sa+mKaQCMayLuQMdlcvdoOnyWLacaMx9PGCRUUIwlSFQ0SxIC6+gZ97P7w/1XiGxjKNHTyyLcblfD/P+JDTyMbkRleptjtZgeS+MilQ+4SLoSaCi/M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=oH8/x2pHeqkp3UvFgiu7V7B90ebQxIdPD6q0MptHblw=; b=bYznvhQG8iPCdkrbCOxpdyptBgjlvkwRONHrO4u/CEHUVtBQxwZG4lAMiNQGL5B7UZrkGrW+uw8rXQH6CylKQWq3tgpkdTEO6gwNZ3XZzqf2P+NHcgc8Yl0IvvVfvxH5pdOzrtIC5n3iEWOlv22JhldzAcd9KSfwOxN8OwCGEc8= Date: 23 Jun 2009 21:37:28 -0000 Message-ID: <20090623213728.1825.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A40B2C0.8090604@telmon.org> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 21:37:20 -0000 >A consent-enabled address will only accept messages from senders that >received a valid token for that address though some channel (usually, >not email). It seems to me that if you want a private e-mail network, there are plenty of ways to construct one now, e.g., use S/MIME and only accept mail from senders whose signing keys are on your whitelist and encrypt with your public key. Or use per-correspondent subaddresses, as Zoemail has been doing for over a decade. If this were a problem that needed to be solved, there are plenty of solutions already. R's, John From claudio@telmon.org Wed Jun 24 00:36:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372783A6F52 for ; Wed, 24 Jun 2009 00:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKnTw1G4lybC for ; Wed, 24 Jun 2009 00:36:46 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 9A24B3A68DF for ; Wed, 24 Jun 2009 00:36:43 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+j2df9xGEJI; Wed, 24 Jun 2009 09:36:15 +0200 Message-ID: <4A41D76E.3040404@telmon.org> Date: Wed, 24 Jun 2009 09:36:14 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> <20090623203753.GA14617@gsp.org> In-Reply-To: <20090623203753.GA14617@gsp.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 07:36:48 -0000 Rich Kulawiec wrote: > Maybe I'm not saying this very well. Let me try examples: Fred > doesn't know Barney, but gets a request for consent: it looks plausible, > so he grants it. But the request *wasn't* from Barney, it was from > the malware on Barney's laptop, and now Fred not only has to deal with > the spam, he's got to revoke the consent. This is a very good example, and I'm really happy to read it, since this is exactly the kind of problems that lets me put "non FUSSP" in the subject. In order to answer to your example, I must take advantage of existing antispam techniques. A consent request is a message with some syntax limits, but it's not just that: it is... well, a request for consent. If it looks like spam, current antispam tools could deal with it at least as good as they do with other messages (including DKIM, blacklist, check on the envelope, etc., but on a simpler and smaller message). If it doesn't look like spam, then Fred reads it: it is not spam, but now it must also be a convincing request specifically for Fred, so that he may be willing to believe it. Now, let's get to Fred: he receives a convincing request for a contact, whatever "convincing" means to him. Should he take the risk of granting a token? Answers: 1. No. It then just doesn't accept consent requests: whoever wants to contact him must manage to obtain a token through some other channel, e.g. a common friend. Somebody won't be able to contact him: Fred's choice. 2. Yes. Well, if a software on Barney's laptop manages to pass all the other antispam protections, and also passes the "Turing test" of mimicing Barney so good to be able to provide a request that is convincing for Fred, what can we do about it? The fact is, it shouldn't be that easy to get to this point, but we can't put limits on spammer talents :). 3. Yes, but with a trick. I wrote the trick in the "Additional fields in the MTA database" section. I don't like it, since it requires the MTA to be able to write in the database, which increases implementation complexity, but anyway: Barney is provided a token with a counter. When a message is received with that token, the MTA decreases the counter. When the counter is zero, the token is invalidated. Should Barney (or his personal zombie) abuse of the token, he could do so for a very limited number of messages. Should Barney actually be Fred's good fiend, he would be provided a new token. All this can be automatically managed, Fred would be asked by the MUA to choose if to set a counter when answering to the consent request, and could then answer "Yes" when, while reading Barney's messages, the MUA proposes to grant an unlimited token. This is at least how I conceived to deal with the problem. > I don't think so: there is no "local". Take for example, the members > of this mailing list: presuming that all of us use a mail client which > maintains an "address book" (and I don't) I'm certain that every one > of us has at least one entry in it that nobody else on this list has. > Most of us probably have *many* entries that nobody else on this list has. > And some of those entries are mailing lists which forward to many people. > Consider the extent of the damage that could be done if one of our > systems started spewing -- and how many spam recipients would have to > individually act in order to fully mitigate it. (Because A and B > revoking their consent to mail from Z does not help C, D, E...) > I don't think that much action would be needed. If my system is compromised, the tokens I have were compromised. My friends would complain (the "local" blame that works), and the spammer would have a token for the mailing list, the one I use, so it would be able to send spam to the list. While this wouldn't avoid spam to the list and its recipients, it wouldn't increase the risk/damage with respect to the current situation. The list (not me) owns tokens for its subscribers, and would forward the spam to these users with these tokens. These tokens wouldn't be compromised, since me and my personal zombie cannot access them. You would complain with the list owner: not with me, you don't have a token for it and in any case I wouldn't care (the "non local" blame). The list owner invalidates the token me and my personal zombie use in order to send messages to the list. End of the game. In the meantime, since my friends threaten me not to grant me tokens any more, I will probably clean up my system. If I don't, they will either stop communicating with me, or accept my little problem, the same way it usually goes with personal relationships. The mailing list will not. > (Which raises another scalability question: how would those of us who > have hundreds or thousands of correspondents find the time to manage > all this? And any of us participating in any mailing list have many more > potential correspondents: anyone on any of those lists might write to us > off-list. Same for anyone with a web site or blog or running any other > resource. A quick check of my personally-addressed and valid inbound mail > -- that is, not including mailing lists, not including spam or phishes -- > suggests that I've had over 11,500 correspondents in the past few years. > That's a lot of tokens to keep track of. And that's just *me*.) > Dealing with the framework without an address book would be actually impossible. With respect to numbers, I cannot answer. People and software explicitly dealing with large lists of addresses/subscribers would usually need to deal with an equal (well, double) number of tokens. People like you, dealing, if I understand correctly, with a large number of occasional correspondents, would need to do the same. Note however that probably in these cases, most of the token exchanges would be automated (you receive a token through a consent request, put a token in piggyback in your first answer) and handled by the MUA, you wouldn't even see these tokens. You would however need to collect some through other means. I cannot make any guess on numbers, nor would I take me or people I know as a reference on how many correspondents people has (did anybody ever publish any statistics on this?), but it would all turn down on how strict you are when accepting consent requests, and how strict your correspondents are. At one end, you answer to every contact request: this would end up with no consent protection, no limits to communications with you, and in some cases to useless messages (note that a consent request wouldn't be usually a useless message, it just must be short and text). You could then disable the consent protection on your address. At the other end, you do not accept consent requests, and end up with a private network. The same for your correspondents. Between these extremes, you select your correspondents, and the same do they, and still enjoy the protection of antispam tools, especially on consent requests. > Moreover, "informing the owners" has already proven to be a badly-losing > strategy. *If* the owners actually receive such communication > (telling them their system is probably compromised), they tend to > either disbelieve it, ignore it, classify it as a phish--often correct, > deny it, or act ineffectively to remedy the situation. Do you feel that the same would be true if the communication were not an automated communication but a communication from correspondents, not by email, and maybe implying the (temporary) inability to communicate with some of them? This would actually severely limit the usability of the scheme. > No anti-spam > scheme which requires effective, clueful participation by end-users has > any chance of working: if they existed (in very large numbers) then we > wouldn't have such a large spam problem because (a) their systems would > be compromised in huge numbers and (b) they would have learned by > now to never respond to any spam. I don't know. Me, as probably each of us, I'm often asked by friends to "reinstall" their systems because they are full of garbage. My email address probably got collected also through their systems, but I never considered blaming them, as I couldn't show any evidence of the fact. Should I receive spam using their token, I could be much more aggressive than I've been until now, and maybe others would do the same. This kind of blame usually works with other communication channels (again, people disseminating phone numbers), why shouldn't it work with email? People usually don't care of ineffective blame, but don't like to be considered stupid by their friends. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From claudio@telmon.org Wed Jun 24 00:39:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172293A6F52 for ; Wed, 24 Jun 2009 00:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB8BOh-5LW9T for ; Wed, 24 Jun 2009 00:39:07 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 9E74C3A6F4E for ; Wed, 24 Jun 2009 00:38:36 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+xD7EGjA5xQ; Wed, 24 Jun 2009 09:36:19 +0200 Message-ID: <4A41D773.50508@telmon.org> Date: Wed, 24 Jun 2009 09:36:19 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> In-Reply-To: <20090623213728.1825.qmail@simone.iecc.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 07:39:08 -0000 John Levine wrote: >> A consent-enabled address will only accept messages from senders that >> received a valid token for that address though some channel (usually, >> not email). > > It seems to me that if you want a private e-mail network, there are > plenty of ways to construct one now, e.g., use S/MIME and only accept > mail from senders whose signing keys are on your whitelist and encrypt > with your public key. Or use per-correspondent subaddresses, as > Zoemail has been doing for over a decade. If this were a problem that > needed to be solved, there are plenty of solutions already. It could turn down to a private network in some cases, but in general people would still be able to contact each other. But if you mean that anybody should be able send messages to whoever he wants, and expect that they are accepted unless they are collectively classified as "spam", whatever this means (vs. being considered undesired by the receiver), or sent by a misbehaved agent, this is not what I want. My guess is exactly this, that a lot of people don't want it either, and would appreciate to be able to use the current tools and protocols with some control on correspondents. Cell phones are not a private network, and people like to have (some of) this control. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From Jose-Marcio.Martins@mines-paristech.fr Wed Jun 24 01:32:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E709E3A6963 for ; Wed, 24 Jun 2009 01:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROa-fJx+-w4t for ; Wed, 24 Jun 2009 01:32:17 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id DC6E43A67BD for ; Wed, 24 Jun 2009 01:32:16 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5O8W95v016301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jun 2009 10:32:09 +0200 (MEST) Message-ID: <4A41E506.2010106@mines-paristech.fr> Date: Wed, 24 Jun 2009 10:34:14 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> In-Reply-To: <4A41D773.50508@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A41E489.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A41E489.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:32:18 -0000 Claudio Telmon wrote: > John Levine wrote: ... > It could turn down to a private network in some cases, but in general > people would still be able to contact each other. But if you mean that > anybody should be able send messages to whoever he wants, and expect > that they are accepted unless they are collectively classified as > "spam", whatever this means (vs. being considered undesired by the > receiver), or sent by a misbehaved agent, this is not what I want. My > guess is exactly this, that a lot of people don't want it either, and > would appreciate to be able to use the current tools and protocols with > some control on correspondents. Cell phones are not a private network, > and people like to have (some of) this control. There are some very big philosophic differences between "cell phones networks" and internet. Among them, internet is a "freedom space". And that's the main reason why spam is a difficult problem to solve. You're right when you say that sometimes some people may want to use internet as a private network. But this is contrary to internet philosophy. IMHO, there are little chance to see new standards allowing/enabling using internet as a private network. But if people want to do it, the best way isn't to set up a new standard, but just creating a proprietary and closed protocol to set up his private network. No need to publish it, nor to create a RFC about it, just set it up with your friends. A good example of consent is Donald Knuth. He has a web page explaining how to contact him. It's simple and efficient, and doesn't require any new standard to continue working. http://www-cs-faculty.stanford.edu/~knuth/email.html From iane@sussex.ac.uk Wed Jun 24 02:24:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2C83A6F59 for ; Wed, 24 Jun 2009 02:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W75QAfsMx17q for ; Wed, 24 Jun 2009 02:24:18 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 4D6503A6F5A for ; Wed, 24 Jun 2009 02:24:18 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:50553) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLQKPY-000417-I3; Wed, 24 Jun 2009 10:22:46 +0100 Date: Wed, 24 Jun 2009 10:22:37 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF Message-ID: <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A41E506.2010106@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> Originator-Info: login-token=Mulberry:01dk80/9+womS3vIhh4nXpxKdy3MdVWdl167o=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Cc: spamcop report Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:24:19 -0000 --On 24 June 2009 10:34:14 +0200 Jose-Marcio Martins da Cruz wrote: > Claudio Telmon wrote: >> John Levine wrote: > > ... > >> It could turn down to a private network in some cases, but in general >> people would still be able to contact each other. But if you mean that >> anybody should be able send messages to whoever he wants, and expect >> that they are accepted unless they are collectively classified as >> "spam", whatever this means (vs. being considered undesired by the >> receiver), or sent by a misbehaved agent, this is not what I want. My >> guess is exactly this, that a lot of people don't want it either, and >> would appreciate to be able to use the current tools and protocols with >> some control on correspondents. Cell phones are not a private network, >> and people like to have (some of) this control. > > There are some very big philosophic differences between "cell phones > networks" and internet. Among them, internet is a "freedom space". And > that's the main reason why spam is a difficult problem to solve. > > You're right when you say that sometimes some people may want to use > internet as a private network. But this is contrary to internet > philosophy. > > IMHO, there are little chance to see new standards allowing/enabling > using internet as a private network. But if people want to do it, the > best way isn't to set up a new standard, but just creating a proprietary > and closed protocol to set up his private network. No need to publish it, > nor to create a RFC about it, just set it up with your friends. > > A good example of consent is Donald Knuth. He has a web page explaining > how to contact him. It's simple and efficient, and doesn't require any > new standard to continue working. He uses a secretary to filter his email. If only we all had that resource. Instead, my 12,000 users have me and a bunch of rules that I maintain. A better example of consent is spamcop. If you want to report a spam message to them, you can send it to an email address like submit.xxxxxxxxxxxxxxxx@spam.spamcop.net where xxxxxxxxxxxxxxxx is an apparently random string. Perhaps it carries some cryptographic authentication which prevents others from using it, perhaps not, so I've obfuscated it. I can't remember how I got the string - probably from a web form - I just keep it in my address book. I wonder whether creating a standard just makes the idea easier to attack through automated means. I have, for example, a mechanism that prevents people spoofing local email (ie pretending the sender is in our domain when the recipient is in our domain). I could have used something clever, but went for something simple and very easy to attack. However, it's still working some years later, and has in the meantime kept our internal email pretty spam free. If someone does attack it, I'll do something more principled. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From Jose-Marcio.Martins@mines-paristech.fr Wed Jun 24 02:55:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B113A682D for ; Wed, 24 Jun 2009 02:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar3IrXILRvor for ; Wed, 24 Jun 2009 02:55:02 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 53D643A6B24 for ; Wed, 24 Jun 2009 02:55:02 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5O9tDhj016757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2009 11:55:13 +0200 (MEST) Message-ID: <4A41F87F.4040506@mines-paristech.fr> Date: Wed, 24 Jun 2009 11:57:19 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Ian Eiloart References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A41F801.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A41F801.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:55:03 -0000 Ian Eiloart wrote: > > He uses a secretary to filter his email. If only we all had that > resource. Instead, my 12,000 users have me and a bunch of rules that I > maintain. An automated secretary... > A better example of consent is spamcop. If you want to report a spam > message to them, you can send it to an email address like > submit.xxxxxxxxxxxxxxxx@spam.spamcop.net where xxxxxxxxxxxxxxxx is an > apparently random string. Perhaps it carries some cryptographic > authentication which prevents others from using it, perhaps not, so I've > obfuscated it. I can't remember how I got the string - probably from a > web form - I just keep it in my address book. Well, you submited my message to spamcop... ;-). Their address was in the list of recipients... > I wonder whether creating a standard just makes the idea easier to > attack through automated means. I have, for example, a mechanism that That's a good point. > prevents people spoofing local email (ie pretending the sender is in our > domain when the recipient is in our domain). I could have used something > clever, but went for something simple and very easy to attack. However, > it's still working some years later, and has in the meantime kept our > internal email pretty spam free. If someone does attack it, I'll do > something more principled. You're right. A standard will just work till the moment it will be cracked. And after that the standard will be droped down and people will go back to their own home made rules. Either way, a good point to think when proposing a standard is if people is open to it. E.g., is spamcop open to replace their consent mechanism by a standard one ? JM From iane@sussex.ac.uk Wed Jun 24 04:00:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE56028C2C8 for ; Wed, 24 Jun 2009 04:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAy9DYYKatl2 for ; Wed, 24 Jun 2009 04:00:32 -0700 (PDT) Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 9DF4128C420 for ; Wed, 24 Jun 2009 04:00:31 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:52948) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLQP79-0006JL-M1; Wed, 24 Jun 2009 11:59:33 +0100 Date: Wed, 24 Jun 2009 11:59:23 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Jose-Marcio.Martins@mines-paristech.fr Message-ID: <812375D23E32D2ADE271A8F2@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A41F87F.4040506@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> <4A41F87F.4040506@mines-paristech.fr> Originator-Info: login-token=Mulberry:01Pxe2+ah4JF6AhApbqz2yjClspY/XU6I9tII=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 11:00:33 -0000 --On 24 June 2009 11:57:19 +0200 Jose-Marcio Martins da Cruz wrote: > Ian Eiloart wrote: > >> >> He uses a secretary to filter his email. If only we all had that >> resource. Instead, my 12,000 users have me and a bunch of rules that I >> maintain. > > An automated secretary... > >> A better example of consent is spamcop. If you want to report a spam >> message to them, you can send it to an email address like >> submit.xxxxxxxxxxxxxxxx@spam.spamcop.net where xxxxxxxxxxxxxxxx is an >> apparently random string. Perhaps it carries some cryptographic >> authentication which prevents others from using it, perhaps not, so I've >> obfuscated it. I can't remember how I got the string - probably from a >> web form - I just keep it in my address book. > > Well, you submited my message to spamcop... ;-). Their address was in the > list of recipients... Sorry - was using my mail client's autocomplete to check the format. Forgot to delete the address . Actually, the report isn't complete until I confirm it, and spamcop probably won't be able to parse the report because my message to them didn't include your message headers. Hmm, maybe some address harvester will harvest that address and start spamming spamcop directly, cutting me out of the loop! Perhaps I'd better try to change the address. > >> I wonder whether creating a standard just makes the idea easier to >> attack through automated means. I have, for example, a mechanism that > > That's a good point. > >> prevents people spoofing local email (ie pretending the sender is in our >> domain when the recipient is in our domain). I could have used something >> clever, but went for something simple and very easy to attack. However, >> it's still working some years later, and has in the meantime kept our >> internal email pretty spam free. If someone does attack it, I'll do >> something more principled. > > You're right. A standard will just work till the moment it will be > cracked. And after that the standard will be droped down and people will > go back to their own home made rules. > > Either way, a good point to think when proposing a standard is if people > is open to it. E.g., is spamcop open to replace their consent mechanism > by a standard one ? > > JM -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From sethb@panix.com Wed Jun 24 09:02:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13D928C244 for ; Wed, 24 Jun 2009 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEyHfhhihSm3 for ; Wed, 24 Jun 2009 09:02:43 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id DCCF03A6F36 for ; Wed, 24 Jun 2009 09:02:42 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id C590E3937C for ; Wed, 24 Jun 2009 12:00:52 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id B5DC62428A; Wed, 24 Jun 2009 12:00:52 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A41E506.2010106@mines-paristech.fr> (message from Jose-Marcio Martins da Cruz on Wed, 24 Jun 2009 10:34:14 +0200) References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> Message-Id: <20090624160052.B5DC62428A@panix5.panix.com> Date: Wed, 24 Jun 2009 12:00:52 -0400 (EDT) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:02:43 -0000 Jose-Marcio Martins da Cruz wrote: > You're right when you say that sometimes some people may want to use > internet as a private network. But this is contrary to internet > philosophy. No, it isn't. The Internet philosophy is "we ship bits around. Interpretation is someone else's problem." VPNs aren't against that philosophy, they're embraced by it. Seth From Jose-Marcio.Martins@mines-paristech.fr Wed Jun 24 11:07:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294113A6CFA for ; Wed, 24 Jun 2009 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb+auA6+QjaF for ; Wed, 24 Jun 2009 11:07:18 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id B1F193A6A5E for ; Wed, 24 Jun 2009 11:07:17 -0700 (PDT) Received: from localhost.localdomain (joe.j-chkmail.org [88.168.143.55]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5OI6N6x019903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jun 2009 20:06:24 +0200 (MEST) Message-ID: <4A426B9D.7090901@mines-paristech.fr> Date: Wed, 24 Jun 2009 20:08:29 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> In-Reply-To: <20090624160052.B5DC62428A@panix5.panix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A426B1F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A426B1F.000/88.168.143.55/joe.j-chkmail.org/localhost.localdomain/ Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 18:07:19 -0000 Seth wrote: > Jose-Marcio Martins da Cruz > wrote: > >> You're right when you say that sometimes some people may want to use >> internet as a private network. But this is contrary to internet >> philosophy. > Hmmmmm..... > No, it isn't. The Internet philosophy is "we ship bits around. That's what spammers do... > Interpretation is someone else's problem." and this is what usual spam filters do. In your idea, the problem is pushed into recipients. Consent pushes the problem to the sender. Either way, I don't think we can agree. > > VPNs aren't against that philosophy, they're embraced by it. Ther's a big difference between VPNs and consent. VPNs are really private - information about VPNs instances (IP address of entry points, protocol, flavour, ...) aren't public and aren't available to unknown users. Consent users information is public : Claudio Telmon email address is public and known by everybody. -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@mines-paristech.fr From 64414253@ngi.it Wed Jun 24 11:01:02 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310243A6C8F for ; Wed, 24 Jun 2009 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnXA+boZg1Ky for ; Wed, 24 Jun 2009 11:01:01 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id F30A93A6819 for ; Wed, 24 Jun 2009 11:01:00 -0700 (PDT) Received: from ::ffff:212.234.174.155 ([::ffff:212.234.174.155]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.155+EYuVA5rsp; Wed, 24 Jun 2009 19:20:52 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.155 Message-ID: <212.234.174.155.98452337.1245864051@webmail.inet.it> In-Reply-To: <812375D23E32D2ADE271A8F2@lewes.staff.uscs.susx.ac.uk> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> <4A41F87F.4040506@mines-paristech.fr> <812375D23E32D2ADE271A8F2@lewes.staff.uscs.susx.ac.uk> Date: Wed, 24 Jun 2009 17:20:51 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 07:12:01 -0000 > > Well, you submited my message to spamcop... ;-). Their address was in the > > list of recipients... > > Sorry - was using my mail client's autocomplete to check the format. Forgot > to delete the address . Actually, the report isn't complete until I > confirm it, and spamcop probably won't be able to parse the report because > my message to them didn't include your message headers. > > Hmm, maybe some address harvester will harvest that address and start > spamming spamcop directly, cutting me out of the loop! Perhaps I'd better > try to change the address. > This is a joke you made me, isn't it? :) Spamcop is using address tagging, and you happened to demonstrate what I said about the risks that tags get disclosed when sending messages to multiple recipients, since addresses may be in many places in the body of the message, whereas a specific header could be detected and purged by the MUA/MTA... From 64414253@ngi.it Wed Jun 24 10:28:35 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508B828C4C6 for ; Wed, 24 Jun 2009 10:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHtQ38sHqeuw for ; Wed, 24 Jun 2009 10:28:34 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 2C83A28C4A9 for ; Wed, 24 Jun 2009 10:28:33 -0700 (PDT) Received: from ::ffff:212.234.174.155 ([::ffff:212.234.174.155]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.155+nET4nplFS; Wed, 24 Jun 2009 19:27:35 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.155 Message-ID: <212.234.174.155.745994146.1245864455@webmail.inet.it> In-Reply-To: <4A41F87F.4040506@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> <4A41F87F.4040506@mines-paristech.fr> Date: Wed, 24 Jun 2009 17:27:35 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 07:13:22 -0000 > You're right. A standard will just work till the moment it will be cracked. And after that > the standard will be droped down and people will go back to their own home made rules. I don't agree with that. A standard is a way many people can manage have good rules in an interoperable way. A good standard is peer reviewed and hard to break. Home made tricks usually just work for security through obscurity, and are not available to the community, which may try to invent tricks that usually don't work. From 64414253@ngi.it Thu Jun 25 02:50:40 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D4C3A6A63 for ; Thu, 25 Jun 2009 02:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZnT8Iq9wK4t for ; Thu, 25 Jun 2009 02:50:39 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 05AD33A6AE9 for ; Thu, 25 Jun 2009 02:50:38 -0700 (PDT) Received: from ::ffff:212.234.174.155 ([::ffff:212.234.174.155]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.155+cePD6cqrB; Thu, 25 Jun 2009 11:09:18 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.155 Message-ID: <212.234.174.155.751333572.1245920958@webmail.inet.it> In-Reply-To: <4A426B9D.7090901@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> Date: Thu, 25 Jun 2009 09:09:18 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 09:50:40 -0000 > Da: Jose-Marcio Martins da Cruz > Ther's a big difference between VPNs and consent. > > VPNs are really private - information about VPNs instances (IP address of entry points, > protocol, flavour, ...) aren't public and aren't available to unknown users. > > Consent users information is public : Claudio Telmon email address is public and known by > everybody. I can't follow you on this. A telnet port is public, yet you must be welcome in order to use the service.The same for ftp, where you access the service, but the owner decides what to share with everybody (public ftp) and what to keep just for some buddies (authenticated). It has always been like this, Internet has been about sharing, but just what the owner wants to share. I choose this two very old services because they are part of the Internet since the beginning. This long before the Internet being about freedom, which is an issue that came up much later. --- Claudio Telmon claudio@telmon.org http://www.telmon.org From rsk@gsp.org Thu Jun 25 04:39:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B163A6AAD for ; Thu, 25 Jun 2009 04:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 540ENSvpTK1U for ; Thu, 25 Jun 2009 04:39:17 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id DED1F3A6B49 for ; Thu, 25 Jun 2009 04:39:04 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5PBZR2T009923 for ; Thu, 25 Jun 2009 07:35:29 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5PBUmS5014533 for ; Thu, 25 Jun 2009 07:30:48 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5PBZLkT014531 for ; Thu, 25 Jun 2009 07:35:21 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5PBZL9v014522 for asrg@irtf.org; Thu, 25 Jun 2009 07:35:21 -0400 Date: Thu, 25 Jun 2009 07:35:21 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090625113521.GA7313@gsp.org> References: <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> <20090623203753.GA14617@gsp.org> <4A41D76E.3040404@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A41D76E.3040404@telmon.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 11:39:19 -0000 On Wed, Jun 24, 2009 at 09:36:14AM +0200, Claudio Telmon wrote: > I don't think that much action would be needed. If my system is > compromised, the tokens I have were compromised. My friends would > complain (the "local" blame that works), and the spammer would have a > token for the mailing list, the one I use, so it would be able to send > spam to the list. (a) How would your friends know? and (b) What stops an attacker who has compromised Fred *and* Barney's computer from using Barney's tokens from Fred's computer? Keep in mind that since the attacker has full control over both systems, he/she also has, or can have, all of Fred and Barney's email credentials -- login names, passwords, etc. and (c) I get the sense that this will scale as N^2, which doesn't bode well. > Dealing with the framework without an address book would be actually > impossible. So you want me to stop using the mail client I've used for years -- which I've deliberately chosen because of its simplicity, speed, features, and most importantly, security? Not a chance. Moreover, even if I had a mail client with an address book, why would I want to put 11,500 people in it? Especially since the overwhelming majority of those communications are one-time? > With respect to numbers, I cannot answer. People and > software explicitly dealing with large lists of addresses/subscribers > would usually need to deal with an equal (well, double) number of > tokens. People like you, dealing, if I understand correctly, with a > large number of occasional correspondents, would need to do the same. I'm already way too busy to even try to answer most of my email; where am I going to get all the extra time needed to do this task? Especially given that there is no meaningful anti-spam value: if today I approve a token from Fred, that doesn't help me at all if Fred's computer is compromised tomorrow night and delivers 50 spam messages to me before I wake up the next morning. I could have done *nothing* and done just as well. > > Moreover, "informing the owners" has already proven to be a badly-losing > > strategy. *If* the owners actually receive such communication > > (telling them their system is probably compromised), they tend to > > either disbelieve it, ignore it, classify it as a phish--often correct, > > deny it, or act ineffectively to remedy the situation. > > Do you feel that the same would be true if the communication were not an > automated communication but a communication from correspondents, not by > email, and maybe implying the (temporary) inability to communicate with > some of them? This would actually severely limit the usability of the > scheme. Two points; first: If it's not automated, it won't scale. If it's automated, then it will be faked billions of times and people will quickly learn not to pay any attention to it. Second: how am I going to communicate with correspondents "not by email" when that's the only way I *have* to communicate with them? You can't seriously expect me or anyone else to spend out time IM'ing or phoning or otherwise trying to convince people that their system is compromised. I see several thousand attempts per day on this address alone that are obviously from compromised end-user systems. > > No anti-spam > > scheme which requires effective, clueful participation by end-users has > > any chance of working: if they existed (in very large numbers) then we > > wouldn't have such a large spam problem because (a) their systems would > > be compromised in huge numbers and (b) they would have learned by > > now to never respond to any spam. > > I don't know. Me, as probably each of us, I'm often asked by friends to > "reinstall" their systems because they are full of garbage. [...] > Should I receive spam using their token, I could be much more aggressive > than I've been until now, and maybe others would do the same. This kind > of blame usually works with other communication channels (again, people > disseminating phone numbers), why shouldn't it work with email? People > usually don't care of ineffective blame, but don't like to be considered > stupid by their friends. We're now 6-7 years into the period when Windows systems are compromised at will by attackers and used not just for spam, but for DoS attacks and all kinds of other mischief. Yet there has been no mass migration away from these insecure and insecurable systems -- just a little bit of movement here and there. Your approach won't get them to change either. They'll either (a) deny there's a problem (b) run some anti-malware tool on their compromised system and believe what it says (c) get someone else to do (b) or (d) in rare cases, get the system detoxed using known-clean boot media or by starting over...but will then get it re-infested a month later the same way they got it infested the first time. ---Rsk From vesely@tana.it Thu Jun 25 05:59:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2143A6ECB for ; Thu, 25 Jun 2009 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHq1Z245+Qa3 for ; Thu, 25 Jun 2009 05:59:21 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E05FD3A6CDC for ; Thu, 25 Jun 2009 05:59:20 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 25 Jun 2009 13:37:46 +0200 id 00000000005DC02F.000000004A43618A.00005B4F Message-ID: <4A43618A.6000205@tana.it> Date: Thu, 25 Jun 2009 13:37:46 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> In-Reply-To: <4A426B9D.7090901@mines-paristech.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] VPNs (was: request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:59:24 -0000 Jose-Marcio Martins da Cruz wrote: > > Ther's a big difference between VPNs and consent. > > VPNs are really private - information about VPNs instances (IP address > of entry points, protocol, flavour, ...) aren't public and aren't > available to unknown users. They are available to allowed users (nearly) transparently. Once it is properly setup, users can run "internet" software that uses the existing connection --obviously including SMTP. > Consent users information is public : Claudio Telmon email address is > public and known by everybody. However, it is not enough to set up consent at the local server. Each user has to take care of tokens management in order for it to work. That's one way that consent pushes the problem to users. AFAIK, there is no way SMTP can be configured so that a given sending location can be whitelisted. One can try and detect what MTA sends the message and whitelist specific filters, presumably doing detection by the IP address of each mailout. That's much like VPN: being at a higher level doesn't ease the task. For example, assume someone trusts Gmail's egress filtering and wants to skip content filtering for mail coming from there. What work is required to accomplish (and maintain) that task, on typical MTA software? From Jose-Marcio.Martins@mines-paristech.fr Thu Jun 25 06:30:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593A33A6DAB for ; Thu, 25 Jun 2009 06:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uCHBO+HHyix for ; Thu, 25 Jun 2009 06:30:51 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 5533C3A6D6B for ; Thu, 25 Jun 2009 06:30:51 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5PCqawJ024557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Jun 2009 14:52:36 +0200 (MEST) Message-ID: <4A437393.3060105@mines-paristech.fr> Date: Thu, 25 Jun 2009 14:54:43 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> In-Reply-To: <4A43618A.6000205@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A437314.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A437314.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 13:30:52 -0000 Alessandro Vesely wrote: > Jose-Marcio Martins da Cruz wrote: > > AFAIK, there is no way SMTP can be configured so that a given sending > location can be whitelisted. One can try and detect what MTA sends the > message and whitelist specific filters, presumably doing detection by > the IP address of each mailout. That's much like VPN: being at a higher > level doesn't ease the task. For example, assume someone trusts Gmail's > egress filtering and wants to skip content filtering for mail coming > from there. What work is required to accomplish (and maintain) that > task, on typical MTA software? Hmmmm.... You're raising a problem which is similar to the problem of management of user preferences on a border smtp gateway. This isn't a problem at, say, gmail or mailbox providers as most of the time users have only one email address. But talking about universities, or look alike organisations... Myself, I have many **non shared** identities : only to cite two, the one you can see in this message and my login. But also I have many **shared** identities. These identities correspond to email addresses (administrative or not) which resolve to many people. I can hardly see some kind of management of *shared consent* for these addresses. From 64414253@ngi.it Thu Jun 25 06:47:55 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB6B3A6B0C for ; Thu, 25 Jun 2009 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlxN6gqtXAw3 for ; Thu, 25 Jun 2009 06:47:54 -0700 (PDT) Received: from slim-2c.inet.it (slim-2c.inet.it [213.92.5.123]) by core3.amsl.com (Postfix) with ESMTP id C48BE3A69B8 for ; Thu, 25 Jun 2009 06:47:53 -0700 (PDT) Received: from ::ffff:212.234.174.167 ([::ffff:212.234.174.167]) by slim-2c.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.167+r9DQYTOdd; Thu, 25 Jun 2009 15:46:43 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.167 Message-ID: <212.234.174.167.998405720.1245937603@webmail.inet.it> In-Reply-To: <20090625113521.GA7313@gsp.org> References: <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> <20090623203753.GA14617@gsp.org> <4A41D76E.3040404@telmon.org> <20090625113521.GA7313@gsp.org> Date: Thu, 25 Jun 2009 13:46:43 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 13:47:55 -0000 Da: Rich Kulawiec > (a) How would your friends know? > They too get spam with my tokens, unless the spammer decided to just target the mailing list. Each of them will receive spam messages carrying the token they provided (just) to me > and > > (b) What stops an attacker who has compromised Fred *and* Barney's > computer from using Barney's tokens from Fred's computer? Keep in > mind that since the attacker has full control over both systems, > he/she also has, or can have, all of Fred and Barney's email > credentials -- login names, passwords, etc. > Hmm, Maybe I don't understand the scenario. If the spammer uses the tokens he found on Barney's computer, he will be able to send spam to Barney's contacts, no matter from which computer. And, Barney's contact will know that Barney's computer has been compromised, since they gave that token to Barney, no matter where the message comes from. > and > > (c) I get the sense that this will scale as N^2, which doesn't bode well. > I considered this issue, but I think it doesn't apply. It would be a problem if some part of the system would need to deal with all of the tokens. However, each user will deal win N tokens, no matter if they are equal or different from the tokens others use. To be clear: each will have N addresses of their correspondents, which scale with N. Each will have N (well, 2N) tokens for their correspondents, even if they are different for each couple and scale with N^2. They won't see the difference, nor will any part of the system. > So you want me to stop using the mail client I've used for years -- > which I've deliberately chosen because of its simplicity, speed, > features, and most importantly, security? > > Not a chance. :) Each tool has some drawbacks. As we (almost) switched from telnet to ssh, people started to need keyrings, which are very similar in terms of usability. There was a good reason for this, which had to be evaluated by each person vs. the convenience of telnet. However, if you won't adopt the consent framework, you may still be required to insert tokens if your correspondents adopt the framework. But, if most (of your correspondents) agree with you and don't see a benefit from the framework, they won't adopt it either and you won't be required to put tokens in your messages. > > Moreover, even if I had a mail client with an address book, why would > I want to put 11,500 people in it? Especially since the overwhelming > majority of those communications are one-time? > If a communication is one-time, you don't need to add the address to an address book, since you won't need to keep any token for future contacts. BTW, this may increase the use of short text-only messages for fast email exchanges, instead of html or similar. This kind of messages would fit the constraints of consent requests, and wouldn't require to actually manage tokens. > I'm already way too busy to even try to answer most of my email; where > am I going to get all the extra time needed to do this task? The goal is to have less useless messages to deal with. If you have a very low noise/signal in your messages, then the framework probably wouldn't fit your need. I see it somehow as to publish the cell number and spend the time answering the (few?) undesired calls, instead of spending time giving the number only to people you want to talk with. However, I would avoid any evaluation based on personal taste (mine or yours), that's why I asked if there are available statistics on how many correspondents people have. > Especially > given that there is no meaningful anti-spam value: if today I approve > a token from Fred, that doesn't help me at all if Fred's computer > is compromised tomorrow night and delivers 50 spam messages to me before > I wake up the next morning. I could have done *nothing* and done just > as well. > So you don't think that being able to tell Fred that he, and not "the Internet", is the reason why you receive spam, would not help convincing Fred to keep his computer clean? I mean, if Fred cares about your opinion, which usually happens with at least some of our correspondents (and usually happens much less if the communication comes from some unknown person). > > Do you feel that the same would be true if the communication were not an > > automated communication but a communication from correspondents, not by > > email, and maybe implying the (temporary) inability to communicate with > > some of them? This would actually severely limit the usability of the > > scheme. > > Two points; first: > > If it's not automated, it won't scale. > It will, in my opinion, since it is distributed among the same people that increase the number. Saying that anything that is not automated won't scale is a bit too generic. > Second: how am I going to communicate with correspondents "not by email" > when that's the only way I *have* to communicate with them? You can't > seriously expect me or anyone else to spend out time IM'ing or phoning > or otherwise trying to convince people that their system is compromised. Well, I do :) Either you are interested into communicating with them, or you're not. If you're not, just invalidate their token and avoid providing a new one. If you are interested, and you know that their system is compromised (don't think at the consent framework, it doesn't matter in this), wouldn't you search a mean to tell them? If someone I want to send mail to has some consistent delivery error, so that I cannot contact him by email, I usually manage to inform him through some other channel. For what I understand and hear about social networks (actual social networks, not the services that support some), they are very effective in forcing people to a behaviour that is accepted by their peers. BTW, this is how the Internet managed to have a "netiquette" in the beginning. This interest in not having our peers as our main source of spam, is the "social" base for the whole framework, be it because you tell them, or because you invalidate their token. > I see several thousand attempts per day on this address alone that > are obviously from compromised end-user systems. > These thousands of attempts are due to thousands of compromised systems, not to thousands of compromised correspondents of yours. The number of systems the spammer would use with the same token is not relevant, since they would all be blocked by invalidating that token. > Yet there has been no mass migration > away from these insecure and insecurable systems -- just a little bit > of movement here and there. Your approach won't get them to change either. Why should they? People is used to these problems, which to them seem to be part of ICT. However, I don't agree that a properly configured Windows system is that undefendable these days. (b) run some anti-malware tool > on their compromised system and believe what it says (c) get someone > else to do (b) or (d) in rare cases, get the system detoxed using > known-clean boot media or by starting over...but will then get it > re-infested a month later the same way they got it infested the first time. Well, they will do what they can. Which, in my opinion, would take us anyway to a much cleaner Internet than it is now. --- --- Claudio Telmon claudio@telmon.org http://www.telmon.org From 64414253@ngi.it Thu Jun 25 07:12:26 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1CF3A6D6E for ; Thu, 25 Jun 2009 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbORK8Z+Shdu for ; Thu, 25 Jun 2009 07:12:25 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 65DB03A682B for ; Thu, 25 Jun 2009 07:12:25 -0700 (PDT) Received: from ::ffff:212.234.174.167 ([::ffff:212.234.174.167]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.167+Aco6R58FJ; Thu, 25 Jun 2009 16:11:34 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.167 Message-ID: <212.234.174.167.138736292.1245939094@webmail.inet.it> In-Reply-To: <4A43618A.6000205@tana.it> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> Date: Thu, 25 Jun 2009 14:11:34 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] VPNs (was: request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:12:26 -0000 > Da: Alessandro Vesely > AFAIK, there is no way SMTP can be configured so that a given sending > location can be whitelisted. One can try and detect what MTA sends the > message and whitelist specific filters, presumably doing detection by > the IP address of each mailout. That's much like VPN: being at a > higher level doesn't ease the task. For example, assume someone trusts > Gmail's egress filtering and wants to skip content filtering for mail > coming from there. What work is required to accomplish (and maintain) > that task, on typical MTA software? It's not clear to me if you're asking how the consent framework would deal with the problem, but I can tell you. Suppose that Gmail implements the consent framework in their MUAs. Then, MTAs could whitelist Gmail with respect to the consent framework. Let's see what it means to example.com's incoming MTA. 1. user1@example.com is not consent-enabled. Then the framework is not used, and nothing relevant happens, mail if acceptet/rejected as it currently is. 2. user2@example.com is consent-enabled, and a message arrives with proper headers/tokens; then, the framework is deployed and the message is accepted/rejected based on tokens (and some other usual controls), whitelisting is not relevant 3 user2@example.com is consent-enabled, a message without tokens arrives from address@gmail, and gmail is whitelisted; in this case: - user2@example.com expressed the will to enable the framework; - address@gmail can use the framework, since gmail is whitelisted, so the sender MUA implements the framework; - however, the message has no proper token; this means that user2 didn't provide a token to the sender, and the message can be safely rejected, with no need to other controls This way, nobody can send messages to user2@example.com with a forged address from any gmail address (unless the attacker manages to get a token from a user2's gmail correspondent). So, implementing the framework could be of some interest e.g. to banks, since accessing their token should be hopefully hard 4 user2@example.com is consent-enabled, a message without tokens arrives from address@gmail, and gmail is not whitelisted; In this last case, we don't know if the message is without token because the token was not provided, or because the gmail MUA doesn't implement the framework and thus the token cannot be inserted in the message. It's up to the receiver to decide if the message sould be rejected, or handled as if user2 were not consent-enambled (that is, go through the usual checks), which is what would probably happen at least until the framework were widely implemented. In any case, no work is required to the sender MTA, the sender domain/organization is only required to implement the framework support in the MUA --- --- Claudio Telmon claudio@telmon.org http://www.telmon.org From 64414253@ngi.it Thu Jun 25 07:59:55 2009 Return-Path: <64414253@ngi.it> X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356FE3A6AA0 for ; Thu, 25 Jun 2009 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YZyd5M64Db8 for ; Thu, 25 Jun 2009 07:59:54 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id D16313A68C8 for ; Thu, 25 Jun 2009 07:59:53 -0700 (PDT) Received: from ::ffff:212.234.174.167 ([::ffff:212.234.174.167]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:212.234.174.167+0cBuqY6Dv; Thu, 25 Jun 2009 16:58:10 +0200 From: "Claudio Telmon" To: Anti-Spam Research Group - IRTF X-wmSenderIP: 212.234.174.167 Message-ID: <212.234.174.167.1726486840.1245941890@webmail.inet.it> In-Reply-To: <4A437393.3060105@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> Date: Thu, 25 Jun 2009 14:58:10 +0000 X-Mailer: NGI Webmail Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: claudio@telmon.org, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:59:55 -0000 > Da: Jose-Marcio Martins da Cruz But also I have many **shared** identities. These identities correspond to email addresses > (administrative or not) which resolve to many people. I can hardly see some kind of > management of *shared consent* for these addresses. If you mean by shared consent that all receivers must agree on consent, I think it can' t be done in a usable way. However, shared addresses usually mean that the consent of one of the receivers suffices. Then, from a technical perspective, it can be partially done. Anybody can distribute tokens for the address, and upload them to the MTA database. Since it is the MTA database that matters for filtering, messages will be properly accepted/rejected. Should a token need to be invalidated, any of the receivers should be able to do it, even if the token is not in his7her address book, again because its the token on the MTA that matters. However, they will need to cooperate in order to understand e.g. whose system has been compromised, since only one will probably have associated the token to an address. The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue. --- --- Claudio Telmon claudio@telmon.org http://www.telmon.org From Jose-Marcio.Martins@mines-paristech.fr Thu Jun 25 08:23:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2E63A6A0C for ; Thu, 25 Jun 2009 08:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBIhrHny84PL for ; Thu, 25 Jun 2009 08:23:09 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 361563A68C8 for ; Thu, 25 Jun 2009 08:23:08 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5PFKQgJ025715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 17:20:26 +0200 (MEST) Message-ID: <4A439639.9090106@mines-paristech.fr> Date: Thu, 25 Jun 2009 17:22:33 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: claudio@telmon.org, Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> In-Reply-To: <212.234.174.167.1726486840.1245941890@webmail.inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at boipeva with ID 4A4395BA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A4395BA.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:23:09 -0000 Claudio Telmon wrote: > > If you mean by shared consent that all receivers must agree on consent, I think it can' t be done in a usable way. However, shared addresses usually mean that the consent of one of the receivers suffices. Then, from a technical perspective, it can be partially done. Anybody can distribute tokens for the address, and upload them to the MTA database. Since it is the MTA database that matters for filtering, messages will be properly accepted/rejected. Should a token need to be invalidated, any of the receivers should be able to do it, even if the token is not in his7her address book, again because its the token on the MTA that matters. However, they will need to cooperate in order to understand e.g. whose system has been compromised, since only one will probably have associated the token to an address. > The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue. > This is something which appear in other situations too : like users preferences management (enable filtering, filtering threshold, ... to name some of them). You can't do any inference about what to do : unanimity, majority, one win, ... Eventually, the border SMTP gateway just know that an address rcpt@domain.com shall be routed to rcpt@dept.domain.com, but rcpt@dept.domain.com will be expanded into a dozen address, when reaching the mailserver of dept.domain.com (which aren't known from the border gateway). The other problem I mentioned is multiple addresses (jose-marcio.martins_da_cruz, jose-marcio.martins, martins, ...). I can't imagine managing preferences for each identity, nor a system telling that each address is equivalent to some other one, in a domain with, say, 10000 or more users. Unless you're able to build an "usine à gaz" (as we say in France), with preferences for each valid address, there isn't a clean solution. From sethb@panix.com Thu Jun 25 09:11:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BC13A6A07 for ; Thu, 25 Jun 2009 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnQBjiz3tB36 for ; Thu, 25 Jun 2009 09:11:44 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id C54B13A6967 for ; Thu, 25 Jun 2009 09:11:44 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id A6449395E0 for ; Thu, 25 Jun 2009 12:11:11 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id 93DCE2428A; Thu, 25 Jun 2009 12:11:11 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A426B9D.7090901@mines-paristech.fr> (message from Jose-Marcio Martins da Cruz on Wed, 24 Jun 2009 20:08:29 +0200) References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> Message-Id: <20090625161111.93DCE2428A@panix5.panix.com> Date: Thu, 25 Jun 2009 12:11:11 -0400 (EDT) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:11:45 -0000 Jose-Marcio Martins da Cruz wrote: > Seth wrote: >> No, it isn't. The Internet philosophy is "we ship bits around. > That's what spammers do... And pirates, and people sending email to their aunts, and people making VOIP phone calls to their lovers, and . . . That's what using the Internet _means_. >> Interpretation is someone else's problem." > and this is what usual spam filters do. And every application likewise. > In your idea, the problem is pushed into recipients. I didn't say that. The Internet moves bits around; that's what IP does. You put a packet into the Internet, with a specified destination address, and the Internet gets it there (or not). > Consent pushes the problem to the sender. Consent is at a higher level, just like interpretation (though consent is around level 9). >> VPNs aren't against that philosophy, they're embraced by it. > Ther's a big difference between VPNs and consent. They aren't anywhere near the same thing. Why are you comparing them? > VPNs are really private - information about VPNs instances (IP > address of entry points, protocol, flavour, ...) aren't public and > aren't available to unknown users. Whether or not they are is up to the owner of the equipment providing the VPN. (Hint: encrypted proxies are VPNs, and with the current events in Iran there are a lot of public ones.) > Consent users information is public What does that mean? Information that is mine is public to the extent I publicize it. > Claudio Telmon email address is public and known by everybody. Very unlikely. Even "president@whitehouse.gov" isn't known by _everybody_. And I personally have hundreds of email addresses, each of which is (or should be) known by precisely one entity. Seth From danny.angus@gmail.com Tue Jun 23 15:14:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6A03A67D4 for ; Tue, 23 Jun 2009 15:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV91jFzwX3hg for ; Tue, 23 Jun 2009 15:14:08 -0700 (PDT) Received: from mail-bw0-f226.google.com (mail-bw0-f226.google.com [209.85.218.226]) by core3.amsl.com (Postfix) with ESMTP id 2CDA13A6879 for ; Tue, 23 Jun 2009 15:13:55 -0700 (PDT) Received: by bwz26 with SMTP id 26so404256bwz.7 for ; Tue, 23 Jun 2009 15:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ukVfQQlXghAxEWYHxq3+e9ffBVRNS0VvEnfbS3KCiVc=; b=wDUhaI9LbJ5tQStmg7LjupNwxeHUhmKdTFKijUVwnlZy2m5qc8+0N8AOnxGHuxz1Do o7OVINcgBsxIfnpPmsdNLLlV6wZlrnGVUpprEN7wzh7Jq8rqju9nRRU66zO5raSXVgp6 GxOJi4vC1Ncp8YdSGJKPxuOi381+Bn2hWnV/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=HFU15RsChyk7EZu/jQyLPxOalalpsdEFmXfqIfPN3DJwacwB15WzsYIwN9brcKcCuE M2Yig4kAfXIquWH0qTRa6BR68eiYX8FOSiv9f7xmiC2RbyLCk6NJEESSKaKBzqbOgzQg QF0da3M7VCSSFYyhjoOWSbfbVXIcyDBfcLpM8= MIME-Version: 1.0 Received: by 10.223.119.5 with SMTP id x5mr486065faq.40.1245795248860; Tue, 23 Jun 2009 15:14:08 -0700 (PDT) In-Reply-To: <4A3DFC91.2090506@telmon.org> References: <4A3DFC91.2090506@telmon.org> Date: Tue, 23 Jun 2009 23:14:08 +0100 Message-ID: <5ec229170906231514k73c9ddcbq780c403118373f76@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=001636c5a8d1457060046d0b4f34 X-Mailman-Approved-At: Thu, 25 Jun 2009 10:02:49 -0700 Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:16:32 -0000 --001636c5a8d1457060046d0b4f34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I've skimmed your paper, it seems very well thought out, I also believe that a distributed consent system, or more accurately distributed rules denying consent, would be beneficial as it would allow any "upstream" MTA to discard messages for which a rule existed saving downstream MTA's & MUA's from the effort of even considering them. I tried some time ago to articulate some tests which any proposal ought to at least acknowledge, which you can find here.. http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html You may find them helpful. I'll try to find time to give your paper fuller attention. d. On Sun, Jun 21, 2009 at 10:25 AM, Claudio Telmon wrote: > Dear Sirs, > I've developed a proposal for an extension to the SMTP protocol that > should provide to address owners the ability to express consent to > delivery of messages in their mailboxes. While it is not the Ultimate > Solution to the Spam Problem, and strictly speaking it is not even an > antispam solution, it could help reducing spam. I already discussed my > proposal with some researchers, which judged it positively, but which > didn't have a very specific competence. > I think that my proposal could be of some interest for the ASRG > community, and I'm looking for comments and advise. > > The paper is in html and pdf at > http://www.telmon.org/consent/smtp-consent-1.1.html > and > http://www.telmon.org/consent/smtp-consent-1.1.pdf > > The paper is quite long, as I tried to anticipate most of the > implementation and deployment issues, but the idea is quite simple and > not really new, since it is very similar to "ham passwords". If you just > want to see what it's all about, you could just read the "Introduction" > and "General overview of the framework" sections, and maybe the > "Deployment of the framework" section at the end of the document. > > Thanks in advance for any comments or suggestions you can provide me. > > Sincerely, > > - Claudio Telmon > > -- > > Claudio Telmon > claudio@telmon.org > http://www.telmon.org > > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > --001636c5a8d1457060046d0b4f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've skimmed your paper, it seems very well thought out, I also believe= that a distributed consent system, or more accurately distributed=C2=A0 ru= les denying consent, would be beneficial as it would allow any "upstre= am" MTA to discard messages for which a rule existed saving downstream= MTA's & MUA's from the effort of even considering them.

I tried some time ago to articulate some tests which any proposal ought= to at least acknowledge, which you can find here..
=C2=A0http://www.kille= rbees.co.uk/draft-irtf-asrg-criteria-00.html

You may find them helpful.

I'll try to find time to give yo= ur paper fuller attention.

d.

On S= un, Jun 21, 2009 at 10:25 AM, Claudio Telmon <claudio@telmon.org> wrote:
Dear Sirs,
I've developed a proposal for an extension to the SMTP protocol that should provide to address owners the ability to express consent to
delivery of messages in their mailboxes. While it is not the Ultimate
Solution to the Spam Problem, and strictly speaking it is not even an
antispam solution, it could help reducing spam. I already discussed my
proposal with some researchers, which judged it positively, but which
didn't have a very specific competence.
I think that my proposal could be of some interest for the ASRG
community, and I'm looking for comments and advise.

The paper is in html and pdf at
http://www.telmon.org/consent/smtp-consent-1.1.html
and
http://www.telmon.org/consent/smtp-consent-1.1.pdf

The paper is quite long, as I tried to anticipate most of the
implementation and deployment issues, but the idea is quite simple and
not really new, since it is very similar to "ham passwords". If y= ou just
want to see what it's all about, you could just read the "Introduc= tion"
and "General overview of the framework" sections, and maybe the "Deployment of the framework" section at the end of the document.=

Thanks in advance for any comments or suggestions you can provide me.

Sincerely,

- Claudio Telmon

--

Claudio Telmon
claudio@telmon.org
http://www.telmon.org


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

--001636c5a8d1457060046d0b4f34-- From jdfalk-lists@cybernothing.org Thu Jun 25 11:59:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C213A6B51 for ; Thu, 25 Jun 2009 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW3MuwohnnKK for ; Thu, 25 Jun 2009 11:59:52 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 8250A3A6ACF for ; Thu, 25 Jun 2009 11:59:51 -0700 (PDT) Received: from rpco-jdmacbook.rpcorp.local (np60.co.returnpath.net [38.109.196.60]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n5PHeh5M023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Jun 2009 11:40:45 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n5PHeh5M023867 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1245951645; bh=J2VxAkDnyY++t06kNb1tFKvl+Jia63aLX8DibDXe dYQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=Fn9rc5OA/Wbk4dffI/B9FubQH6r1DL6oiMIlW g9RCBaizjGxbwJ6t2PjcF35+BEG+LjXA7AOEYWhlczAgkqR6AakkVw3TebhSSHM3nNd aj7jX+T0XMOQVfsneZDX/e1ribD54JA2M02kTR8nBS9xt3hGtPC695oNctjQbK6FIso = Message-ID: <4A43B696.2000106@cybernothing.org> Date: Thu, 25 Jun 2009 11:40:38 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 18:59:53 -0000 Danny Angus wrote: > I tried some time ago to articulate some tests which any proposal ought > to at least acknowledge, which you can find here.. > http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html > > You may find them helpful. Nicely done; I think this could be the start of a very useful document. Any interest in starting up work on it again? First steps could be: - update terminology to match draft-crocker-email-arch - include some examples taken from other RFCs, both successful and non- -- J.D. Falk Return Path Inc http://www.returnpath.net/ From dotis@mail-abuse.org Thu Jun 25 12:41:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB83F3A6DFB for ; Thu, 25 Jun 2009 12:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N5zOODjAubN for ; Thu, 25 Jun 2009 12:41:08 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 10C503A6972 for ; Thu, 25 Jun 2009 12:41:08 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 531D2A94439 for ; Thu, 25 Jun 2009 19:40:19 +0000 (UTC) Message-Id: <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A43B696.2000106@cybernothing.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 12:40:19 -0700 References: <4A43B696.2000106@cybernothing.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 19:41:09 -0000 On Jun 25, 2009, at 10:40 AM, J.D. Falk wrote: > Danny Angus wrote: > >> I tried some time ago to articulate some tests which any proposal >> ought >> to at least acknowledge, which you can find here.. >> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html >> >> You may find them helpful. > > Nicely done; I think this could be the start of a very useful > document. Any interest in starting up work on it again? > > First steps could be: > - update terminology to match draft-crocker-email-arch > - include some examples taken from other RFCs, both successful and > non- This draft overlooked an important area. It assumes a viable and scaleable means to identify initial senders when confronting massive levels of abuse. Simply put, without a two tier approach to abuse that begins by identifying outbound MTAs, email will not remain viable. This paper overlooks that need. - Include a means for efficient and efficacious host name identification and domain level authorization of systems granting access for outbound public (non-authenticated port 25) SMTP messages. Even reverse DNS queries often impose a too great of a burden on resources due to bot-net related abuse. :^( Reducing the number of systems that need vetting are best consolidated by identifying the outbound MTA explicitly signified as providing this service within the forward facing name space. A means to explicitly facilitate this function becomes more necessary with increased inclusion of IPv6 and further growth of bot-nets. Once outbound MTAs provide stable and specific identifications within the domain name space, the immediate vetting this allows provides a much needed reduction on the resource burdens imposed upon SMTP by abuse. These schemes should also not cause undue burden on DNS either. -Doug From meta404@gmail.com Thu Jun 25 17:27:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132A33A67E2 for ; Thu, 25 Jun 2009 17:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gznY4vxtXDcG for ; Thu, 25 Jun 2009 17:27:33 -0700 (PDT) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by core3.amsl.com (Postfix) with ESMTP id 277D43A6A12 for ; Thu, 25 Jun 2009 17:27:32 -0700 (PDT) Received: by fxm23 with SMTP id 23so667142fxm.7 for ; Thu, 25 Jun 2009 17:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=PJVuilfaXPnNYbqB053JzQ3E88OxzRFsDhEpAGdESfg=; b=P5T6GLyO6Utlc0K6WIjV4C4EBRwSlf0nXHjhqUHjIFirMKVPn46H7gWMjAVDzKMfCw dCHcB9jh0D2w5Jv2CH+eV05hua+64rO8QNGxvGqFrsF3efzGopVUDn1ReiRReyM1Xl2B D6gEQQssNUlsD0pJKx2UZWCWE5CbY5FjAb9a8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=bfuoY51BiQhd0+BTjpO8GRhW2AP5VvJS/mXDgdSstmZfwtSfWOdy4qOiPTAIUBqI7e hC8KNcSATvXxFDdQQ4ERRJxGSXaC72lGFYozNPQrySMdv6wj/3WAKtA5oqqG+TQxCBpS ZXJWt6VDUSGeWsOAfnr1AuXKnNw+vRuKDild0= MIME-Version: 1.0 Sender: meta404@gmail.com Received: by 10.223.114.74 with SMTP id d10mr2581115faq.87.1245975989611; Thu, 25 Jun 2009 17:26:29 -0700 (PDT) In-Reply-To: <20090619100604.2572.qmail@simone.iecc.com> References: <4A3B3335.6040507@tana.it> <20090619100604.2572.qmail@simone.iecc.com> Date: Thu, 25 Jun 2009 19:26:29 -0500 X-Google-Sender-Auth: 656e1046611d1fb8 Message-ID: <7eeceb440906251726p217e1b2bse575f732d1aaafaf@mail.gmail.com> From: mathew To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Proposed corollary to Godwin's law X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 00:27:34 -0000 On Fri, Jun 19, 2009 at 05:06, John Levine wrote: > I think that as soon as you start quoting the dictionary, you've lost > the argument. Exactly what Humpty Dumpty would say. Glory! mathew From vesely@tana.it Fri Jun 26 02:53:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814453A6890 for ; Fri, 26 Jun 2009 02:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.181 X-Spam-Level: X-Spam-Status: No, score=-0.181 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEx+AVNFh+aO for ; Fri, 26 Jun 2009 02:53:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 814593A6784 for ; Fri, 26 Jun 2009 02:53:36 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 26 Jun 2009 11:53:00 +0200 id 00000000005DC031.000000004A449A7C.00007C91 Message-ID: <4A449A7C.6070106@tana.it> Date: Fri, 26 Jun 2009 11:53:00 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> In-Reply-To: <4A43B696.2000106@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 09:53:37 -0000 J.D. Falk wrote: > Danny Angus wrote: >> I tried some time ago to articulate some tests which any proposal ought >> to at least acknowledge, which you can find here.. >> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html That paper thickens the ranks of anti-anti-spam trenches. It is good as it avoids an excess of proposal that would possibly result in a waste of time for evaluating proposed techniques that don't come quite close to the point. However, I think an it could, and should, go beyond that. For example, why is it not in the scope of that document "to attempt to distinguish or justify any more detailed definition of [the term spam]"? [1.1.1] The given definition is subjective and should be amended. Recipients' fickle wishes won't lead to a reliable transport. The second definition is better, although it leaves the _necessity of transport_ undefined. You don't have to query recipients to know that a sender is going to abuse the mail system. The definition of spam can be worded in terms of the senders: where do they get recipients' addresses from, and how well they comply with existing privacy laws, including opt-in/out issues. > Nicely done; I think this could be the start of a very useful document. > Any interest in starting up work on it again? Hey, that implies interest in finding new anti-spam techniques! Good, but I think the assumption "that there will be early adopters" [2.3.9] might be misunderstood as an overpromising statement. > First steps could be: > - update terminology to match draft-crocker-email-arch As it is transport-centric, just updating 2821->5321 might suffice... > - include some examples taken from other RFCs, both successful and non- Absolutely agreed. From rsk@gsp.org Fri Jun 26 03:09:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5933A6985 for ; Fri, 26 Jun 2009 03:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVzkpPpTbHoW for ; Fri, 26 Jun 2009 03:09:26 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 307B53A6855 for ; Fri, 26 Jun 2009 03:09:26 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5QA7g2I015765 for ; Fri, 26 Jun 2009 06:07:43 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5QA30ox016106 for ; Fri, 26 Jun 2009 06:03:00 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5QA7aT8029346 for ; Fri, 26 Jun 2009 06:07:36 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5QA7aMj029345 for asrg@irtf.org; Fri, 26 Jun 2009 06:07:36 -0400 Date: Fri, 26 Jun 2009 06:07:36 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090626100736.GA29159@gsp.org> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A449A7C.6070106@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 10:09:27 -0000 On Fri, Jun 26, 2009 at 11:53:00AM +0200, Alessandro Vesely wrote: > > That paper thickens the ranks of anti-anti-spam trenches. It is good as > it avoids an excess of proposal that would possibly result in a waste of > time for evaluating proposed techniques that don't come quite close to > the point. However, I think an it could, and should, go beyond that. For > example, why is it not in the scope of that document "to attempt to > distinguish or justify any more detailed definition of [the term spam]"? The canonical definition of spam (in the context of email) was settled on a very long time ago ("unsolicited bulk email") and is NOT in need of tinkering or refinement. It's served us very well -- and one reason why is that it's *deliberately* silent on a number of points. It would be a very serious mistake -- one that would greatly assist spammers -- to change that situation. ---Rsk From iane@sussex.ac.uk Fri Jun 26 03:18:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2763A6A58 for ; Fri, 26 Jun 2009 03:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIiFfRUtMGIx for ; Fri, 26 Jun 2009 03:18:29 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id BA1343A6855 for ; Fri, 26 Jun 2009 03:18:29 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60491) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUCMI-0004S1-OA; Fri, 26 Jun 2009 11:18:19 +0100 Date: Fri, 26 Jun 2009 11:17:29 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: claudio@telmon.org, Anti-Spam Research Group - IRTF Message-ID: <254DA756687142D2C2566841@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <212.234.174.155.98452337.1245864051@webmail.inet.it> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <008E8EE8BFAAE1C24E4F75DF@lewes.staff.uscs.susx.ac.uk> <4A41F87F.4040506@mines-paristech.fr> <812375D23E32D2ADE271A8F2@lewes.staff.uscs.susx.ac.uk> <212.234.174.155.98452337.1245864051@webmail.inet.it> Originator-Info: login-token=Mulberry:01DQ+5lHZwJ/lOfA32eTWAhCwHc4fa7nA1gno=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 10:18:31 -0000 --On 24 June 2009 17:20:51 +0000 Claudio Telmon wrote: > >> > Well, you submited my message to spamcop... ;-). Their address was in >> > the list of recipients... >> >> Sorry - was using my mail client's autocomplete to check the format. >> Forgot to delete the address . Actually, the report isn't >> complete until I confirm it, and spamcop probably won't be able to >> parse the report because my message to them didn't include your message >> headers. >> >> Hmm, maybe some address harvester will harvest that address and start >> spamming spamcop directly, cutting me out of the loop! Perhaps I'd >> better try to change the address. >> > > This is a joke you made me, isn't it? :) Spamcop is using address > tagging, and you happened to demonstrate what I said about the risks that > tags get disclosed when sending messages to multiple recipients, since > addresses may be in many places in the body of the message, whereas a > specific header could be detected and purged by the MUA/MTA... > A fair point. Some of the same considerations apply, though, especially with regard to obtaining the token. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Fri Jun 26 03:24:22 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E4A3A69BA for ; Fri, 26 Jun 2009 03:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGTbCnJxHtl4 for ; Fri, 26 Jun 2009 03:24:21 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 367DF3A682F for ; Fri, 26 Jun 2009 03:24:21 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60528) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUCVF-0007K8-4J; Fri, 26 Jun 2009 11:23:39 +0100 Date: Fri, 26 Jun 2009 11:22:50 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF Message-ID: <7A6EBB41141B1854E7FCE875@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A426B9D.7090901@mines-paristech.fr> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> Originator-Info: login-token=Mulberry:01aPcg5tFYjkupZHRI1B3bbJNZzm9BQMsd3WI=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 10:24:22 -0000 --On 24 June 2009 20:08:29 +0200 Jose-Marcio Martins da Cruz wrote: > Seth wrote: >> Jose-Marcio Martins da Cruz >> wrote: >> >>> You're right when you say that sometimes some people may want to use >>> internet as a private network. But this is contrary to internet >>> philosophy. >> > > Hmmmmm..... > >> No, it isn't. The Internet philosophy is "we ship bits around. > > That's what spammers do... > >> Interpretation is someone else's problem." > > and this is what usual spam filters do. You miss his point. You're talking about senders and recipients, he's talking about different protocol layers (IP versus VPN, perhaps). For an Internet application like VPN or SMTP to work, both the sender and the recipient need to have the same interpretation of what the bits mean. Similarly, a conversation is just exchange of words, for it to be useful, both the sender and receiver need to have (at least to some approximation) the same interpretation of each word. ;) > In your idea, the problem is pushed into recipients. Consent pushes the > problem to the sender. > > Either way, I don't think we can agree. > >> >> VPNs aren't against that philosophy, they're embraced by it. > > Ther's a big difference between VPNs and consent. > > VPNs are really private - information about VPNs instances (IP address of > entry points, protocol, flavour, ...) aren't public and aren't available > to unknown users. > > Consent users information is public : Claudio Telmon email address is > public and known by everybody. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Fri Jun 26 03:49:11 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E293A69FF for ; Fri, 26 Jun 2009 03:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF1DZxi4Hf6H for ; Fri, 26 Jun 2009 03:49:10 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id C4BC73A6855 for ; Fri, 26 Jun 2009 03:49:03 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60647) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUE04-000KLZ-PG for asrg@irtf.org; Fri, 26 Jun 2009 11:48:05 +0100 Date: Fri, 26 Jun 2009 11:47:15 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> Originator-Info: login-token=Mulberry:01UUXPm7qmPQCSsiP9vWvEukIOt73w9bRrxrA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 10:49:11 -0000 --On 25 June 2009 12:40:19 -0700 Douglas Otis wrote: > > On Jun 25, 2009, at 10:40 AM, J.D. Falk wrote: > >> Danny Angus wrote: >> >>> I tried some time ago to articulate some tests which any proposal >>> ought >>> to at least acknowledge, which you can find here.. >>> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html >>> >>> You may find them helpful. >> >> Nicely done; I think this could be the start of a very useful >> document. Any interest in starting up work on it again? >> >> First steps could be: >> - update terminology to match draft-crocker-email-arch >> - include some examples taken from other RFCs, both successful and >> non- > > This draft overlooked an important area. It assumes a viable and > scaleable means to identify initial senders when confronting massive > levels of abuse. Which section assumes that. > Simply put, without a two tier approach to abuse that > begins by identifying outbound MTAs, email will not remain viable. This > paper overlooks that need. I think that's a different level, isn't it? That's a proposal to be judged by the criteria in this paper. The paper shouldn't make any claims about how to prevent spam. It's just trying to outline the problem space. > - Include a means for efficient and efficacious host name identification > and domain level authorization of systems granting access for outbound > public (non-authenticated port 25) SMTP messages. > > Even reverse DNS queries often impose a too great of a burden on > resources due to bot-net related abuse. :^( > > Reducing the number of systems that need vetting are best consolidated by > identifying the outbound MTA explicitly signified as providing this > service within the forward facing name space. A means to explicitly > facilitate this function becomes more necessary with increased inclusion > of IPv6 and further growth of bot-nets. Once outbound MTAs provide > stable and specific identifications within the domain name space, the > immediate vetting this allows provides a much needed reduction on the > resource burdens imposed upon SMTP by abuse. These schemes should also > not cause undue burden on DNS either. > > -Doug > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Fri Jun 26 03:54:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0F93A67AD for ; Fri, 26 Jun 2009 03:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-SsFjWuRAbq for ; Fri, 26 Jun 2009 03:54:14 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 54DED3A6A75 for ; Fri, 26 Jun 2009 03:54:06 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60702) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUEA7-000N09-7N for asrg@irtf.org; Fri, 26 Jun 2009 11:54:07 +0100 Date: Fri, 26 Jun 2009 11:53:18 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <4A449A7C.6070106@tana.it> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> Originator-Info: login-token=Mulberry:01PNmcs6U6Chh9RvAVqP+vTg8molG9DZ//sUQ=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 10:54:15 -0000 --On 26 June 2009 11:53:00 +0200 Alessandro Vesely wrote: > > Hey, that implies interest in finding new anti-spam techniques! Good, but > I think the assumption "that there will be early adopters" [2.3.9] might > be misunderstood as an overpromising statement. It's simply saying that not everyone will adopt the proposal at the same time. The alternatives are "everyone will adopt it at once" (a common pitfall), and "nobody will ever adopt it" (a risk for any proposal). A common counter to many proposals is that they won't work unless everyone adopts the proposal at the same time. 2.3.9 tries to warn of this possibility. Perhaps it should read "there will be early adopters (if any at all)". -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Fri Jun 26 04:02:58 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933503A6A6D for ; Fri, 26 Jun 2009 04:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJXSsj77sU4w for ; Fri, 26 Jun 2009 04:02:57 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B720E3A6855 for ; Fri, 26 Jun 2009 04:02:57 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 26 Jun 2009 12:55:06 +0200 id 00000000005DC033.000000004A44A90A.0000059B Message-ID: <4A44A90A.9090503@tana.it> Date: Fri, 26 Jun 2009 12:55:06 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> In-Reply-To: <20090626100736.GA29159@gsp.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 11:02:58 -0000 Rich Kulawiec wrote: >> For example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term spam]"? > > The canonical definition of spam (in the context of email) was settled > on a very long time ago ("unsolicited bulk email") and is NOT in need of > tinkering or refinement. It's served us very well -- and one reason > why is that it's *deliberately* silent on a number of points. It would > be a very serious mistake -- one that would greatly assist spammers -- > to change that situation. UBE is still better than "the class of Messages which the Recipient wishes to prevent from ever being presented with." In particular, it allows to determine a message's spaminess *on sending*. However, expanding on that definition may be useful for a number of purposes. I mention two: 1. Many countries now have laws that address privacy, and it would be informative for postmasters, managers, and lawyers to know what each one's neighbor is talking about. 2. We don't fight spam as a uniform diffused phenomenon, and some tools are better than others in specific areas. For example, discerning direct marketing from zombies is just practical. How would that assist which kind of spammer? From iane@sussex.ac.uk Fri Jun 26 04:14:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373E43A6A99 for ; Fri, 26 Jun 2009 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zYjGIoB9mzN for ; Fri, 26 Jun 2009 04:14:20 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 5A16E3A6A9B for ; Fri, 26 Jun 2009 04:14:02 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:60834) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUF73-0007TT-JV for asrg@irtf.org; Fri, 26 Jun 2009 12:13:51 +0100 Date: Fri, 26 Jun 2009 12:13:02 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090626100736.GA29159@gsp.org> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> Originator-Info: login-token=Mulberry:01eHX8V+HWary54lC55Jvr6m/K3u0dsdub7eA=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 11:14:21 -0000 --On 26 June 2009 06:07:36 -0400 Rich Kulawiec wrote: > On Fri, Jun 26, 2009 at 11:53:00AM +0200, Alessandro Vesely wrote: >> >> That paper thickens the ranks of anti-anti-spam trenches. It is good as >> it avoids an excess of proposal that would possibly result in a waste of >> time for evaluating proposed techniques that don't come quite close to >> the point. However, I think an it could, and should, go beyond that. For >> example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term spam]"? > > The canonical definition of spam (in the context of email) was settled > on a very long time ago ("unsolicited bulk email") and is NOT in need of > tinkering or refinement. It's served us very well -- and one reason > why is that it's *deliberately* silent on a number of points. It would > be a very serious mistake -- one that would greatly assist spammers -- > to change that situation. Frankly, I don't like that definition. Specifically it misses an important class of spam - well targeted, individualised, unsolicited marketing messages which are necessarily unique (and hence not bulk). The problem comes with trying to define spam succinctly. It's like trying to define "mammal" succinctly - the more succinct the definition, the more likely it is that you'll get false positives or false negatives. > ---Rsk > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Fri Jun 26 04:44:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30523A697B for ; Fri, 26 Jun 2009 04:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQDkJSMffMNR for ; Fri, 26 Jun 2009 04:44:53 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 35FCA3A68ED for ; Fri, 26 Jun 2009 04:44:53 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 26 Jun 2009 13:37:59 +0200 id 00000000005DC033.000000004A44B317.00000B47 Message-ID: <4A44B317.9010409@tana.it> Date: Fri, 26 Jun 2009 13:37:59 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> In-Reply-To: <4A3FF3AF.9030401@telmon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 11:44:54 -0000 Claudio Telmon wrote: >> problem in the transition to consent-enabled mailboxes: When users >> switch their mailboxes to consent-enabled, they lose the ability to >> receive any message from consent-unaware senders, including friends, >> business contacts, mailing lists, banks and similar notification >> services, reminders, cell phones, etcetera. > > You're absolutely right, of course. This is the most critical deployment > issue, and I have tried to consider some strategies in the "deployment" > section. Nobody could actually "switch" to consent-enabled mailboxes: a > gradual, albeit less effective transition path is required. Your are right, in turn: after reading the "deployment" section, it is fairly clear that a transition is not necessary. I'm not sure how well point "Voluntary participation" 2.3.9 of Danny's criteria connotes your framework as not being an anti-spam technique. I think it may actually have more chances when explicitly targeted to guard children, rather than generically "non FUSSP". From sethb@panix.com Fri Jun 26 07:03:28 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02E03A6B5A for ; Fri, 26 Jun 2009 07:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bf6zstrC1+E for ; Fri, 26 Jun 2009 07:03:28 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id 290E93A6B3A for ; Fri, 26 Jun 2009 07:03:28 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id E53C11FAED for ; Fri, 26 Jun 2009 10:03:20 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id B0C8C24300; Fri, 26 Jun 2009 10:03:20 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <4A44A90A.9090503@tana.it> (message from Alessandro Vesely on Fri, 26 Jun 2009 12:55:06 +0200) References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> Message-Id: <20090626140320.B0C8C24300@panix5.panix.com> Date: Fri, 26 Jun 2009 10:03:20 -0400 (EDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:03:28 -0000 Alessandro Vesely wrote: > UBE is still better than "the class of Messages which the Recipient > wishes to prevent from ever being presented with." In particular, it > allows to determine a message's spaminess *on sending*. Definitionally, yes. Effectively, no. There's no way for anyone other than the sender (e.g. the sender's ISP) to determine that I asked someone I met at a party last week to send me some information by email. (Sure, they could ask me; but I _didn't_ solicit that.) Seth From sethb@panix.com Fri Jun 26 07:12:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4A13A6B87 for ; Fri, 26 Jun 2009 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-bFIKGQ0FDF for ; Fri, 26 Jun 2009 07:12:15 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 5F6713A6B85 for ; Fri, 26 Jun 2009 07:12:15 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id E65E339101 for ; Fri, 26 Jun 2009 10:11:49 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id CDEEF24300; Fri, 26 Jun 2009 10:11:49 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> (message from Ian Eiloart on Fri, 26 Jun 2009 12:13:02 +0100) References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> Message-Id: <20090626141149.CDEEF24300@panix5.panix.com> Date: Fri, 26 Jun 2009 10:11:49 -0400 (EDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:12:16 -0000 Ian Eiloart wrote: > Frankly, I don't like that definition. Specifically it misses an > important class of spam - well targeted, individualised, unsolicited > marketing messages which are necessarily unique (and hence not > bulk). What makes them unique? If the individualisation is merely a mail merge, they're still bulk. If the salescritter spent an hour investigating me in order to determine that I'm a good prospect and figure out the best way to entice me, the problem scales just fine. Seth From iane@sussex.ac.uk Fri Jun 26 07:39:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531F428C0F1 for ; Fri, 26 Jun 2009 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCFGkROmvQTN for ; Fri, 26 Jun 2009 07:39:50 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 49C583A6AEA for ; Fri, 26 Jun 2009 07:39:49 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63517) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUORY-00085O-DE for asrg@irtf.org; Fri, 26 Jun 2009 15:40:46 +0100 Date: Fri, 26 Jun 2009 15:39:55 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: In-Reply-To: <20090626141149.CDEEF24300@panix5.panix.com> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> <20090626141149.CDEEF24300@panix5.panix.com> Originator-Info: login-token=Mulberry:01hnOHtu/U9RvH4NsY8pn56Pop7OuoEOmZ+94=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:39:52 -0000 --On 26 June 2009 10:11:49 -0400 Seth wrote: > Ian Eiloart wrote: > >> Frankly, I don't like that definition. Specifically it misses an >> important class of spam - well targeted, individualised, unsolicited >> marketing messages which are necessarily unique (and hence not >> bulk). > > What makes them unique? If the individualisation is merely a mail > merge, they're still bulk. If the salescritter spent an hour > investigating me in order to determine that I'm a good prospect and > figure out the best way to entice me, the problem scales just fine. And how would I, as a recipient, know which had happened? How would I know whether to report the message as spam? > Seth > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From sethb@panix.com Fri Jun 26 07:42:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388B128C145 for ; Fri, 26 Jun 2009 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u8J9tS9y5vM for ; Fri, 26 Jun 2009 07:42:53 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 81A7F28C126 for ; Fri, 26 Jun 2009 07:42:53 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 3383638E43 for ; Fri, 26 Jun 2009 10:42:55 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id 1D65724300; Fri, 26 Jun 2009 10:42:55 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: (message from Ian Eiloart on Fri, 26 Jun 2009 15:39:55 +0100) References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> <20090626141149.CDEEF24300@panix5.panix.com> Message-Id: <20090626144255.1D65724300@panix5.panix.com> Date: Fri, 26 Jun 2009 10:42:55 -0400 (EDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:42:54 -0000 Ian Eiloart wrote: > --On 26 June 2009 10:11:49 -0400 Seth wrote: >> Ian Eiloart wrote: >> >>> Frankly, I don't like that definition. Specifically it misses an >>> important class of spam - well targeted, individualised, unsolicited >>> marketing messages which are necessarily unique (and hence not >>> bulk). >> >> What makes them unique? If the individualisation is merely a mail >> merge, they're still bulk. If the salescritter spent an hour >> investigating me in order to determine that I'm a good prospect and >> figure out the best way to entice me, the problem scales just fine. > > And how would I, as a recipient, know which had happened? How would > I know whether to report the message as spam? If it isn't apparent from the message itself, you probably shouldn't be on the net without adult supervision. Seth From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 26 07:44:51 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E53428C122 for ; Fri, 26 Jun 2009 07:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU+-ERmkVe9G for ; Fri, 26 Jun 2009 07:44:50 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 4D52E28C0EC for ; Fri, 26 Jun 2009 07:44:50 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA17182; Fri, 26 Jun 2009 10:44:29 -0400 (EDT) From: der Mouse Message-Id: <200906261444.KAA17182@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 26 Jun 2009 10:36:26 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:44:51 -0000 >> The canonical definition of spam (in the context of email) was >> settled on a very long time ago ("unsolicited bulk email") [...] > Frankly, I don't like that definition. Specifically it misses an > important class of spam - well targeted, individualised, unsolicited > marketing messages which are necessarily unique (and hence not bulk). The "bulk" in UBE is the same one in the Briedbart Index for Usenet: they have to be substantively identical. Form-letter "personalization" of the "Dear %s, [invariant text]" kind does not make them non-bulk. Neither do hashbusters or randomized spelling errors. However, if they are individualized in the sense that they don't use invariant text, each one being written for the particular recipient, then they're not spam, even if they are unsolicited and/or unwanted: they may be problematic, but at worst they are abuse _on_ the net, not abuse _of_ the net - that is to say, that problem, even if it _is_ a problem, scales just fine. Just don't think "spam" needs to include all problematic email (or something equivalent, such as "if it's not spam it must be OK"). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 26 07:51:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2B23A6B8F for ; Fri, 26 Jun 2009 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.27 X-Spam-Level: X-Spam-Status: No, score=-9.27 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0HUdqYfgerj for ; Fri, 26 Jun 2009 07:51:50 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id C87C13A6882 for ; Fri, 26 Jun 2009 07:51:49 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA17268; Fri, 26 Jun 2009 10:51:53 -0400 (EDT) From: der Mouse Message-Id: <200906261451.KAA17268@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 26 Jun 2009 10:45:22 -0400 (EDT) To: Anti-Spam Research Group - IRTF In-Reply-To: References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> <20090626141149.CDEEF24300@panix5.panix.com> Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:51:50 -0000 >> What makes them unique? If the individualisation is merely a mail >> merge, they're still bulk. If the salescritter spent an hour >> investigating me in order to determine that I'm a good prospect and >> figure out the best way to entice me, the problem scales just fine. > And how would I, as a recipient, know which had happened? It's usually pretty obvious from the mail itself. And I do have some basis for that. I get spam through at least a half-dozen different addresses, and I can count on the fingers of one hand the number of times _ever_ that I've gotten a spam and failed to recognize it as spam until I saw additional copies spammed to other addresses. (And that's just considering the content. When looking at the headers reveals that it was sent from an anonymous African host through an unsecured Web form in Singapore, for mail that's supposedly Canadian-to-Canadian, the chance that it's ham is ignorably low.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From iane@sussex.ac.uk Fri Jun 26 08:34:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DCD3A68B9 for ; Fri, 26 Jun 2009 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyqEzUXNkXMd for ; Fri, 26 Jun 2009 08:34:39 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 9FECC3A6922 for ; Fri, 26 Jun 2009 08:34:39 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:63786) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLUQDS-000JKF-CF for asrg@irtf.org; Fri, 26 Jun 2009 16:15:28 +0100 Date: Fri, 26 Jun 2009 16:14:38 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <85578757E72FE7CC2CEA4753@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <20090626144255.1D65724300@panix5.panix.com> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> <20090626141149.CDEEF24300@panix5.panix.com> <20090626144255.1D65724300@panix5.panix.com> Originator-Info: login-token=Mulberry:01iwtc5/RsykzMeLBJ9zH+gM9a8YN9Qe4xAHY=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:34:40 -0000 --On 26 June 2009 10:42:55 -0400 Seth wrote: > Ian Eiloart wrote: >> --On 26 June 2009 10:11:49 -0400 Seth wrote: >>> Ian Eiloart wrote: >>> >>>> Frankly, I don't like that definition. Specifically it misses an >>>> important class of spam - well targeted, individualised, unsolicited >>>> marketing messages which are necessarily unique (and hence not >>>> bulk). >>> >>> What makes them unique? If the individualisation is merely a mail >>> merge, they're still bulk. If the salescritter spent an hour >>> investigating me in order to determine that I'm a good prospect and >>> figure out the best way to entice me, the problem scales just fine. >> >> And how would I, as a recipient, know which had happened? How would >> I know whether to report the message as spam? > > If it isn't apparent from the message itself, you probably shouldn't > be on the net without adult supervision. Really, SMTP has some feature that lets me determine -from the content of an email- exactly how that email was constructed and who spent what amount of time putting it together? Neat. Is that in RFC 2821 of 2822. Must be 2822, since you said "from the message itself". Well, there's our solution then. We just need to examine the content of the X-i-struggled-for-half-an-hour-to-discover-whether-you'd-be-likely-to-be-interested-in-this-offer header. > Seth > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From sethb@panix.com Fri Jun 26 08:51:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE89C3A6AE0 for ; Fri, 26 Jun 2009 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.323 X-Spam-Level: X-Spam-Status: No, score=0.323 tagged_above=-999 required=5 tests=[AWL=-2.877, BAYES_00=-2.599, GB_CHAT_3=5, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfVHcmlt0Yvs for ; Fri, 26 Jun 2009 08:51:26 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 1CAEA3A6922 for ; Fri, 26 Jun 2009 08:51:25 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id AD77A38E55 for ; Fri, 26 Jun 2009 11:51:35 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id 9A5EE24300; Fri, 26 Jun 2009 11:51:35 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: <85578757E72FE7CC2CEA4753@lewes.staff.uscs.susx.ac.uk> (message from Ian Eiloart on Fri, 26 Jun 2009 16:14:38 +0100) References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> <20090626141149.CDEEF24300@panix5.panix.com> <20090626144255.1D65724300@panix5.panix.com> <85578757E72FE7CC2CEA4753@lewes.staff.uscs.susx.ac.uk> Message-Id: <20090626155135.9A5EE24300@panix5.panix.com> Date: Fri, 26 Jun 2009 11:51:35 -0400 (EDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:51:26 -0000 > --On 26 June 2009 10:42:55 -0400 Seth wrote: >> Ian Eiloart wrote: >>> --On 26 June 2009 10:11:49 -0400 Seth wrote: >>>> Ian Eiloart wrote: >>>> What makes them unique? If the individualisation is merely a mail >>>> merge, they're still bulk. If the salescritter spent an hour >>>> investigating me in order to determine that I'm a good prospect and >>>> figure out the best way to entice me, the problem scales just fine. >>> >>> And how would I, as a recipient, know which had happened? How would >>> I know whether to report the message as spam? >> >> If it isn't apparent from the message itself, you probably shouldn't >> be on the net without adult supervision. > > Really, SMTP has some feature that lets me determine -from the content of > an email- exactly how that email was constructed and who spent what amount > of time putting it together? No, the English language and typical adult ability to read for content provide the capability of determining whether a message appears to be (lightly-customized) boilerplate or individually crafted. For instance, it's apparent to me that all of the earlier messages in this thread were hand-crafted. It's likewise apparent that "Hi, this is . I saw your profile and I'd like to get to know you better. I borrowed my friend's account to send this, so you should reply to me on ." is spam. Seth From vesely@tana.it Fri Jun 26 09:02:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2951A3A6BBF for ; Fri, 26 Jun 2009 09:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZesedgzdbsQ5 for ; Fri, 26 Jun 2009 09:02:05 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id EB2933A697E for ; Fri, 26 Jun 2009 09:02:04 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 26 Jun 2009 18:02:11 +0200 id 00000000005DC030.000000004A44F103.00003065 Message-ID: <4A44F103.7010608@tana.it> Date: Fri, 26 Jun 2009 18:02:11 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> In-Reply-To: <20090626140320.B0C8C24300@panix5.panix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 16:02:06 -0000 Seth wrote: >> UBE is still better than "the class of Messages which the Recipient >> wishes to prevent from ever being presented with." In particular, it >> allows to determine a message's spaminess *on sending*. > > Definitionally, yes. Effectively, no. There's no way for anyone > other than the sender (e.g. the sender's ISP) to determine that I > asked someone I met at a party last week to send me some information > by email. (Sure, they could ask me; but I _didn't_ solicit that.) Likewise, a recipient's ESP has no way to determine what the recipient _wishes_. Even asking may result in ambiguous answers, possibly affected by unexpected unconscious evocations. In addition, to surmise that a recipient's wishes can be partitioned into classes according to some standard is beyond any residual trace of objectivity. When interpreted operatively, it calls for inconsistent behavior -which indeed is what we currently have. Even if we may be skeptical about the effectiveness of meatspace laws for limiting spam, we should give them credit for defining and describing a number of useful terms. Privacy laws are aimed at protecting people against undiscriminated usage of collected personally identifiable information, a.k.a. personal data. For example, European privacy directives' definitions[1] don't use the term "spam", but pin unauthorized usage of email addresses. Technically, UBE is covered in section 6.2 of rfc5321, loosening up on delivering or bouncing. According to privacy criteria, it should be covered in section 3.9, which is where the lists of addresses come into play. Is that the difference between coping and fixing? [1] http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28 From dotis@mail-abuse.org Fri Jun 26 11:39:28 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB663A68B5 for ; Fri, 26 Jun 2009 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLusLvJPdFCY for ; Fri, 26 Jun 2009 11:39:27 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 0602A3A6989 for ; Fri, 26 Jun 2009 11:39:27 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 40484A9443A for ; Fri, 26 Jun 2009 18:37:22 +0000 (UTC) Message-Id: <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 11:37:21 -0700 References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 18:39:28 -0000 On Jun 26, 2009, at 3:47 AM, Ian Eiloart wrote: > --On 25 June 2009 12:40:19 -0700 Douglas Otis > wrote: >> >> This draft overlooked an important area. It assumes a viable and >> scaleable means to identify initial senders when confronting >> massive levels of abuse. > > Which section assumes that. http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html Section 1.3.1 defines "Sender" as something responsible for creation and initial entry of a message into the Transport System and should be identified by RFC 5321. The 1.3.1 definition necessitates indirect assessments of the outbound MTA which is not good. Section 2.1.2.1, when followed, precludes most "Sender" IP address authorization schemes as potentially burdening innocent third party DNS servers or their networks. For example, DNSSEC expects EDNS0@4096. This draft fails to include a definition that encompasses a crucial and safe point of control essential for effective spam mitigation. The missing definition is that of the Outbound MTA, the entity granting access and facilitating public SMTP exchanges to other domains. Email-Arch's definition tends to understate the role with: Outbound MTA, an MTA that relays messages to other ADMDs. >> Simply put, without a two tier approach to abuse that begins by >> identifying outbound MTAs, email will not remain viable. This >> paper overlooks that need. > > I think that's a different level, isn't it? That's a proposal to be > judged by the criteria in this paper. The paper shouldn't make any > claims about how to prevent spam. It's just trying to outline the > problem space. What level? This paper is about the management of spam. Failing to offer a definition of a crucial and safe management point suggests a desire to ignore this aspect of control. Today's spam levels necessities exclusion of messages from outbound MTAs demonstrating poor stewardship at removing access from abusive message sources. This approach scales since it expects a hierarchy of spam management. Often assessments of stewardship is measured in many ways, which might include responsiveness to reports of abuse. It is no longer reasonable to assume spam can be filtered based upon purported message sources. The existence of bot-nets necessitates MTA triage, where the entire MTA message stream is handled as one. For the MTAs accepted, only then individual message assessment becomes possible. As email begins to accept IPv6 exchanges, traditional IP address blocking strategies are unlikely to scale in a manner that offers efficacy. Expecting stable and verifiable host name EHLO announcements will dramatically reduce the efforts of collecting stewardship histories which can be immediately applied during initial SMTP connections. This requirement tends to exclude the use of a large number of MTAs behind a common NAT. Often such instances represent networks containing uncontrolled, compromised systems. However, the current use of IP address block-lists are also likely to exclude the use of a large number of MTAs behind a common NAT. At Today's level of abuse, it is not reasonable nor safe to execute hundreds of DNS transactions to verify possible MTA authorizations in response to every SMTP connection. It should also be noted that SPF schemes include macros that might negate DNS caching effectiveness. A reasonable and scaleable approach that should take email safely into IPv6 is described in: http://mipassoc.org/csv/ -Doug From jdfalk-lists@cybernothing.org Fri Jun 26 13:05:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2F43A6BA7 for ; Fri, 26 Jun 2009 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVc-4Uafv1NN for ; Fri, 26 Jun 2009 13:05:39 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 8A5DD3A6B07 for ; Fri, 26 Jun 2009 13:05:39 -0700 (PDT) Received: from rpco-jdmacbook.local (97-122-151-2.hlrn.qwest.net [97.122.151.2]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n5QK5pnP009912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jun 2009 14:05:56 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n5QK5pnP009912 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1246046756; bh=azVgFVL9z37qzSil2sM5YVxL+cM1RC0762AyzTV9 ZJo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Tk71NnkZdzk2 mstUKJGvYsw/WwCoNpOL3mdbadbWvyLqNFTDJkiAJN2CVWTh9rEUt+YfHZ2WEtvb2fo h8IoW9vdJdKwvziuIaNYCpKBMMaOkR52FDo7+1++gYhLXVMzF7xh0JPNqrdYUMSlA0s QPBUv+2m/OMKHFcGQEFn20g70= Message-ID: <4A452A12.2070302@cybernothing.org> Date: Fri, 26 Jun 2009 14:05:38 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b12 (Macintosh/2009051120) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> In-Reply-To: <4A449A7C.6070106@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 20:05:40 -0000 Alessandro Vesely wrote: > However, I think an it could, and should, go beyond that. For > example, why is it not in the scope of that document "to attempt to > distinguish or justify any more detailed definition of [the term spam]"? Because attempting to define "spam" is the very best way to ensure that a document is never finished. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From dotis@mail-abuse.org Fri Jun 26 13:39:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3D3A6BA5 for ; Fri, 26 Jun 2009 13:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw9ytdYGqyHU for ; Fri, 26 Jun 2009 13:39:35 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 5E0053A6977 for ; Fri, 26 Jun 2009 13:39:35 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B1540A94439 for ; Fri, 26 Jun 2009 20:29:01 +0000 (UTC) Message-Id: <7C1229F5-0346-4FC6-98D2-41BE2BA70EBA@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <4A452A12.2070302@cybernothing.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 13:29:01 -0700 References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 20:39:36 -0000 On Jun 26, 2009, at 1:05 PM, J.D. Falk wrote: > Alessandro Vesely wrote: > >> However, I think an it could, and should, go beyond that. For >> example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term >> spam]"? > > Because attempting to define "spam" is the very best way to ensure > that a document is never finished. Agreed. -Doug From vesely@tana.it Sat Jun 27 05:37:38 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821213A6ADC for ; Sat, 27 Jun 2009 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxjefNo69ZCm for ; Sat, 27 Jun 2009 05:37:37 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A111C3A6AB0 for ; Sat, 27 Jun 2009 05:37:37 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 27 Jun 2009 14:37:52 +0200 id 00000000005DC030.000000004A4612A0.0000467C Message-ID: <4A4612A0.8070208@tana.it> Date: Sat, 27 Jun 2009 14:37:52 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> In-Reply-To: <4A452A12.2070302@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 12:37:38 -0000 J.D. Falk wrote: >> However, I think an it could, and should, go beyond that. For >> example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term spam]"? > > Because attempting to define "spam" is the very best way to ensure that > a document is never finished. Finishing a document, by itself, is not a progress in the anti-spam endeavor, unless it contains useful knowledge for countering spam. I suspect that if we are not even able to agree on a definition of spam, there will never be much efficient anti-spam research by our group. And if people were to judge such research by the spam levels out there, they'd conclude it's all hot air. Could we start again, please? Let me try the following variation on UBE, in order to see if we can classify the objections against adopting it as a working definition. *Spam* is a message or a class of messages composed automatically, possibly using templates and databases of names or words, using a list of destination mailbox addresses, and failing to meet both the following conditions: * There is a record or evidence whatsoever, even implied, that the recipient has registered, subscribed, or otherwise solicited the message; and * it is obvious from the message content, including the headers, who is in charge of controlling the processing, and how the recipients can amend or delete their addresses from the list (as well as any other part of their personally identifiable data from any database used to compose the message), where "obvious" means the relevant entity is indicated, exists, is normally reachable by the recipient, and is effectual to the purpose it is referred for. From claudio@telmon.org Sat Jun 27 08:21:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA2F28C186 for ; Sat, 27 Jun 2009 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EifkQyDZGwd for ; Sat, 27 Jun 2009 08:21:15 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 0DCEC3A6A3E for ; Sat, 27 Jun 2009 08:21:14 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+XYOAt9RWdu; Sat, 27 Jun 2009 17:21:32 +0200 Message-ID: <4A4638FB.4010207@telmon.org> Date: Sat, 27 Jun 2009 17:21:31 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 15:21:17 -0000 First, let me say, from the point of view of one that just submitted a proposal, that I've been looking for such a document for days before submitting my proposal to the list, and (once finished) this document should definitely be cited in the faq. I don't think that spam should be redefined in this kind of document, since it wouldn't be of much help to prospective proposers. I don't think that having a proposer think at whether a specific class of messages is spam or not would help in getting better proposals, especially since even this knowledgeable group can't agree on the term. Said that, I don't think that the definition in the document is appropriate, since a lot of messages, including harassment messages and messages from some co-workers or bosses :) are messages one wouldn't definitely like to be presented, but unfortunately they can hardly be classified as spam :) Some additional information in the document could help in preparing a better proposal, e.g. a list of "cases" and "issues" to be considered: I spent a lot of time trying to "imagine" some, but still missed e.g. the shared address issue. Some could be: - multiple recipients in messages; - webmail vs. personal MUA vs. both; - message forwarding - mailing lists - incoming MTA different from outgoing MTA - legacy protocol versions - ... This would avoid proposals that miss some key situations where they will break. While it is reasonable to expect that proposers are willing to understand the difficulties and internals of email before proposing anything, I think it's not reasonable to expect them to have a good understanding from the beginning: it often happen that truly innovative proposals come from people who look at a system "from the outside". Maybe also a reference to a description of current techniques, both implemented and failed. Many of you pointed me to e.g. different address tagging services/proposals. While I had already seen most, I spent a lot of time in this search too (not that this has been wasted time). But, while I've seen that the ASRG moved to non-consent research, I didn't find anywhere why, so I was left guessing why it happened. Also, the critical requirement that it should reduce the effort of managing spam for the recipient is not very clear. Many solutions may reduce the burden for some, and increase it for others. Also, for many it will reduce the bured of some tasks but will add some other tasks. My discussion with Rich about MUAs, address books etc. is a clear example. So, I suggest that being able to classify users with respect to increase/decrease of burden, and to clearly state what additional tasks are required, would be more useful. Also, just stating that it would decrease the burden for the majority of users is not enough, or else anything that works for Outlook and a couple of ESP would suffice. Another point is the "voluntary participation", which may also be unclear. As an example, one can "voluntarily" enable the consent framework, but without some care this would force its correspondent to deal with the framework too. This may seem a violation of the rule, but many protocols have the same requirement. As an example, if I protect my http service with TSL, users willing to access it will need to implement TSL, and I won't usually offer the same service, and this is common to most security protocols (e.g. VPNs). One could argue that with email, one could not know that the security/antispam protocol until a message is rejected. As Alessandro suggested, I'm interested especially in this final issue. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From claudio@telmon.org Sat Jun 27 09:01:49 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22CC63A6983 for ; Sat, 27 Jun 2009 09:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkcm5gO7F1ou for ; Sat, 27 Jun 2009 09:01:48 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id AD5153A6403 for ; Sat, 27 Jun 2009 09:01:47 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+GJSYisjVmt; Sat, 27 Jun 2009 18:02:05 +0200 Message-ID: <4A46427C.3020608@telmon.org> Date: Sat, 27 Jun 2009 18:02:04 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A44B317.9010409@tana.it> In-Reply-To: <4A44B317.9010409@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 16:01:49 -0000 Alessandro Vesely wrote: > Your are right, in turn: after reading the "deployment" section, it is > fairly clear that a transition is not necessary. I'm not sure how well > point "Voluntary participation" 2.3.9 of Danny's criteria connotes your > framework as not being an anti-spam technique. I think it may actually > have more chances when explicitly targeted to guard children, rather > than generically "non FUSSP". I considered to use terms like "protected mailboxes", but at the end it didn't like it, since it describes an expected effect (protection) and not what is actually done (enabling the framework). Also, while the "children" case is a clear one, I think that many other classes of users could benefit from this option. I only used the term FUSSP in the message to this list :) Anyway, the "voluntary participation issue" is probably not clearly stated in the document. If I enable the framework, you're not forced into enabling the framework, you just won't be able to communicate with me. The same happens if I enable https on my webserver: you're not forced into adopting https, you just won't be able to access my content, you can access the rest of Internet. This doesn't make https a "non voluntary" protocol. BTW, there is still a couple of points in my paper on which I would really like to have a comment from this list. One is the key point that spam (at least, UBE) respecting the constraints of consent requests, that is "short text-only messages", would reduce the workload for MTAs with respect to protected/consent-enabled addresses. This wouldn't be true e.g. if most filtering is actually made on the envelope. Also, I suppose that the burden of dealing with the token database on the MTA is not a big issue for the MTA itself (not for the user), but you surely know better. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From dhc@dcrocker.net Sat Jun 27 09:34:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4853A67FF for ; Sat, 27 Jun 2009 09:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC3luapiVomj for ; Sat, 27 Jun 2009 09:34:27 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 821523A6403 for ; Sat, 27 Jun 2009 09:34:26 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-124-148-164.dsl.pltn13.pacbell.net [67.124.148.164]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n5RGYcVU031190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jun 2009 09:34:43 -0700 Message-ID: <4A464A1D.1070100@dcrocker.net> Date: Sat, 27 Jun 2009 09:34:37 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> In-Reply-To: <4A452A12.2070302@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 27 Jun 2009 09:34:44 -0700 (PDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 16:34:27 -0000 J.D. Falk wrote: > Alessandro Vesely wrote: > >> However, I think an it could, and should, go beyond that. For >> example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term spam]"? > > Because attempting to define "spam" is the very best way to ensure that > a document is never finished. +1 A long time ago, it was observed that other disciplines make progress because the latest round of workers stand on the shoulders of the giants who came before, but in computer science, we stand on their feet. Constantly starting over to debate first principles and first definitions isn't just standing on those feet, it's stomping on them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From claudio@telmon.org Sat Jun 27 10:39:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317523A6842 for ; Sat, 27 Jun 2009 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.396 X-Spam-Level: X-Spam-Status: No, score=0.396 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BawVDn3z99D1 for ; Sat, 27 Jun 2009 10:39:29 -0700 (PDT) Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id B86BD3A68AC for ; Sat, 27 Jun 2009 10:39:28 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+Pn1mHUuND6; Sat, 27 Jun 2009 19:39:46 +0200 Message-ID: <4A465961.2090901@telmon.org> Date: Sat, 27 Jun 2009 19:39:45 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <4A464A1D.1070100@dcrocker.net> In-Reply-To: <4A464A1D.1070100@dcrocker.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 17:39:30 -0000 Alessandro Vesely wrote: >> Because attempting to define "spam" is the very best way to ensure >> that a document is never finished. Why not take the opposite approach? Any relevant antispam technique must at least significantly affect some UBE, or else it is probably useless. Also, any approach that relevantly affects UBE can be considered antispam. So, instead of trying to define spam, the document can simply state that the proposal must at least relevantly affect UBE, while it can affect other categories of spam. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From mike@mtcc.com Sat Jun 27 12:51:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29E33A68CF for ; Sat, 27 Jun 2009 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-F6ziA9MdYl for ; Sat, 27 Jun 2009 12:51:13 -0700 (PDT) Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by core3.amsl.com (Postfix) with ESMTP id 306973A6819 for ; Sat, 27 Jun 2009 12:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=543; t=1246132279; x=1246996279; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20draft-irtf-asrg-criteria=20(wa s=20Re=3A=20request=20for=20review=20for=0A=20a=20non=20FUSS P=20proposal) |Sender:=20 |To:=20=20dcrocker@bbiw.net,=20Anti-Spam=20Research=20Group =20-=20IRTF=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=l06O9k6FBH996uIdyP1vruFc2P3JhFaMedoCJVfcr/Y=; b=n+1Jevt6z3kDREtmcmQXUXx2KO/QMdXNXgE68vexUeRGVAq9bOFM+XqOlj JuTdDcA/OLUebXiCyac0nMFIZ71pdnb1Hmve6K+yntMC7GQC5RtAiUijoffn joYoB3Rs2HHsEe+RJNNMsklGzsXODFafgO/6NSIr+OG6sGW9170FU=; Received: from [127.0.0.1] (fugu.mtcc.com [127.0.0.1]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id n5RJpJfC006439; Sat, 27 Jun 2009 12:51:19 -0700 Message-ID: <4A467837.4060503@mtcc.com> Date: Sat, 27 Jun 2009 12:51:19 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <4A464A1D.1070100@dcrocker.net> In-Reply-To: <4A464A1D.1070100@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 19:51:13 -0000 Dave CROCKER wrote: > A long time ago, it was observed that other disciplines make progress > because the latest round of workers stand on the shoulders of the giants > who came before, but in computer science, we stand on their feet. Which nicely explains the existence of the Internet instead of the Interbell. > Constantly starting over to debate first principles and first > definitions isn't just standing on those feet, it's stomping on them. Ossified feet become more and more sensitive, I take it. Mike From johnl@iecc.com Sat Jun 27 16:15:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939143A6AE4 for ; Sat, 27 Jun 2009 16:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.199 X-Spam-Level: X-Spam-Status: No, score=-19.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3uB8EkTLDn7 for ; Sat, 27 Jun 2009 16:15:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 99B553A67E7 for ; Sat, 27 Jun 2009 16:15:35 -0700 (PDT) Received: (qmail 78446 invoked from network); 27 Jun 2009 23:15:53 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 27 Jun 2009 23:15:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=V7NxpTbSXXjcraMCCE1rk5xRZNaLL1sThHbeowcq6oI=; b=WtyfK2DUQ01Kx1KRkRzficIiOr0dvI9Ul5Xgrntw+ODR+nGI58RyBpA31tK31KJZD4Kj2CPd3PyyKYgIpyNNN/sByd5+JO9/SCr7i4keSnCdv3oxz8Eeku6gIpT3sdf6Laz2xCScRPdAQeg04dvTw8wGY68H5m5yf1pbGHVEylc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=V7NxpTbSXXjcraMCCE1rk5xRZNaLL1sThHbeowcq6oI=; b=U0wEy9QsNN8VV7FXuYJ33V+wGaw/Cw77nNj9yHwjsCxdX3QOtE2LiI9x3HLIGc411fzhY3CVU++3UnfPQ8exuXff6gBa7bR1rZH9SZM0/l8TXzU74/kySkK1K4CFnsv5O3DMJz+JZhm+dGFHypHioeZs5HfCzezLa3uihEzHkEc= Date: 27 Jun 2009 23:15:52 -0000 Message-ID: <20090627231552.2163.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A4612A0.8070208@tana.it> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] No, we're not going to define spam X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 23:15:36 -0000 >I suspect that if we are not even able to agree on a definition of >spam, there will never be much efficient anti-spam research by our >group. The world hasn't agreed on a definition of spam in 20 years, and I see no reason to think that anything has changed that would make it possible to do so now. Fortunately, all of the popular definitions (UBE, UCE, UBCE, mail recipients don't want) in practice tend to describe roughly the same mail. So my suggestion is that documents discussing anti-spam techniques say which definition they're using, if it matters, and leave it at that. Readers specifically don't get to complain that it's the wrong definition. R's, John From rsk@gsp.org Sun Jun 28 12:06:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2123C3A6B0A for ; Sun, 28 Jun 2009 12:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGpIOWBbagbr for ; Sun, 28 Jun 2009 12:06:14 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 4FBCB3A6A40 for ; Sun, 28 Jun 2009 12:06:13 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5SJ6I2F008749 for ; Sun, 28 Jun 2009 15:06:20 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5SJ1SWx022584 for ; Sun, 28 Jun 2009 15:01:28 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5SJ6D9R019111 for ; Sun, 28 Jun 2009 15:06:13 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5SJ6CYk019110 for asrg@irtf.org; Sun, 28 Jun 2009 15:06:12 -0400 Date: Sun, 28 Jun 2009 15:06:12 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090628190612.GG12932@gsp.org> References: <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> <4A40C3B4.5060103@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:06:15 -0000 On Tue, Jun 23, 2009 at 04:18:43PM +0100, Ian Eiloart wrote: > Still, we're already in a position where people are fearful of publishing > email addresses, so this spec might alleviate that problem. But, it isn't > fundamental to combatting spam. You're correct that we're in that position: we see it everywhere, from Google's needlessly-obfuscated Usenet archives (like spammers don't have their own NNTP feeds and haven't already harvested all email addresses long before Google publishes them) or the presence of address-obfuscation code in mail archivers (e.g., even the notes on the newest/development version of Mailman talk about the need for such obfuscation). And I _think_ we're in concurrence that it's a pointless waste of code and effort: spammers either have or will have soon any address that's actually used. (And will successfully guess at many that exist but aren't used.) The meta-problem we face is that "cargo cult" mentality that persists in the belief that it's possible to hide addresses from spammers. I've found it quite difficult to dislodge, and -- as I commented elsewhere -- am often by the irony that the people prattling the loudest about it are running Windows on their desktop/laptop are thus stand a reasonable chance of being the primary vector by which their address(es) is/are harvested by spammers. ---Rsk From iane@sussex.ac.uk Mon Jun 29 01:12:25 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A4328C192 for ; Mon, 29 Jun 2009 01:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlZA0-hUxu1r for ; Mon, 29 Jun 2009 01:12:25 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id E609D28C18E for ; Mon, 29 Jun 2009 01:12:24 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64946) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLZQUW-0009ZE-NB for asrg@irtf.org; Mon, 29 Jun 2009 09:13:44 +0100 Date: Mon, 29 Jun 2009 09:12:37 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> Originator-Info: login-token=Mulberry:013sjfOEcpTZ0fNTOaSu5RPVKrREAAkkHuUzM=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:12:26 -0000 --On 26 June 2009 11:37:21 -0700 Douglas Otis wrote: > This draft fails to include a definition that encompasses a crucial and > safe point of control essential for effective spam mitigation. The > missing definition is that of the Outbound MTA, the entity granting > access and facilitating public SMTP exchanges to other domains. > Email-Arch's definition tends to understate the role with: Outbound MTA, > an MTA that relays messages to other ADMDs. Defining an "outbound MTA" would be useful, I guess. > > What level? The paper isn't discussing particular proposals, but you seem to be saying that it should. It's discussing certain desirable properties of proposals. Perhaps you're looking for more detail, or something closer to an actual solution. If you want to say that a desirable proposal would be scalable, then that's fine. If you want to say that SPF doesn't scale for a particular reason, then that's outside the scope of this proposal. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 29 01:25:21 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBDC3A6969 for ; Mon, 29 Jun 2009 01:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-1.508, BAYES_40=-0.185, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot7DGN85jWQn for ; Mon, 29 Jun 2009 01:25:20 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id A68B03A68B3 for ; Mon, 29 Jun 2009 01:25:20 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:65104) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLZRGL-000E9A-QU for asrg@irtf.org; Mon, 29 Jun 2009 09:26:46 +0100 Date: Mon, 29 Jun 2009 09:25:40 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A44F103.7010608@tana.it> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> <4A44F103.7010608@tana.it> Originator-Info: login-token=Mulberry:01ZA+oBs1wFmulfPxo0DXXhBt5yofJYMc12Xo=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:25:21 -0000 --On 26 June 2009 18:02:11 +0200 Alessandro Vesely wrote: > > Even if we may be skeptical about the effectiveness of meatspace laws for > limiting spam, we should give them credit for defining and describing a > number of useful terms. Privacy laws are aimed at protecting people > against undiscriminated usage of collected personally identifiable > information, a.k.a. personal data. You're missing an important definition of "privacy" - the right to be undisturbed (for example, by unsolicited advertising in your INBOX or on your doormat). Many people consider privacy to be simply the right to remain unobserved (secrecy), but the right to be let alone is the basis of the UK's "Privacy and Electronic Communications (EC Directive) Regulations 2003". Those regulations are subsidiary to our Data Protection Act of 1998, but don't arise from it. Once upon a time, the two aspects of privacy were entwined by mass illiteracy and slow communications. Nowadays, near ubiquitous communications mean it's harder to voluntarily avoid interference by keeping your location secret - partly because it's harder to keep it secret, and partly because for many modern communications methods your physical location doesn't matter. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From iane@sussex.ac.uk Mon Jun 29 01:41:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F02D3A6969 for ; Mon, 29 Jun 2009 01:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vkUXkmo0+ud for ; Mon, 29 Jun 2009 01:41:23 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 126743A68C4 for ; Mon, 29 Jun 2009 01:41:22 -0700 (PDT) Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:65267) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KLZS7C-000JHS-E9 for asrg@irtf.org; Mon, 29 Jun 2009 09:42:48 +0100 Date: Mon, 29 Jun 2009 09:41:42 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: Anti-Spam Research Group - IRTF Message-ID: <5D548C8C6AB23557A0CCEF4D@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <4A4612A0.8070208@tana.it> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <4A4612A0.8070208@tana.it> Originator-Info: login-token=Mulberry:01hI42u+3vpCDF+4od8LT3A6ku6gZXFee0+fk=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:41:24 -0000 --On 27 June 2009 14:37:52 +0200 Alessandro Vesely wrote: > J.D. Falk wrote: >>> However, I think an it could, and should, go beyond that. For >>> example, why is it not in the scope of that document "to attempt to >>> distinguish or justify any more detailed definition of [the term spam]"? >> >> Because attempting to define "spam" is the very best way to ensure that >> a document is never finished. > > Finishing a document, by itself, is not a progress in the anti-spam > endeavor, unless it contains useful knowledge for countering spam. I > suspect that if we are not even able to agree on a definition of spam, > there will never be much efficient anti-spam research by our group. And > if people were to judge such research by the spam levels out there, > they'd conclude it's all hot air. > > Could we start again, please? The mistake below is to assume that "spam" is a single category that can be tidily defined. It can't. The best one could do is to try to enumerate some types of spam. I'd suggest two, that look very different from each other: (a) submission of large quantities of electronic messages to an electronic messaging service with the deliberate aim of reducing the usability of that service, and (b) transmission of unsolicited communications by means of electronic mail for direct marketing purposes. These are very different - the content is irrelevant in the first, but highly relevant in the second. The threat to the system is the motivation of the first, but would be harmful to the sender in the second. A recipient might welcome the second, but is unlikely to welcome the first. One might wish to add other types of spam (phishing, viruses, chain letters...) but it's unlikely that even the longest list constructed today will cover all future types of spam. > Let me try the following variation on UBE, in order to see if we can > classify the objections against adopting it as a working definition. > > *Spam* is a message or a class of messages composed automatically, > possibly using templates and databases of names or words, using a > list of destination mailbox addresses, and failing to meet both the > following conditions: > * There is a record or evidence whatsoever, even implied, that the > recipient has registered, subscribed, or otherwise solicited the > message; and > * it is obvious from the message content, including the headers, > who is in charge of controlling the processing, and how the > recipients can amend or delete their addresses from the list (as > well as any other part of their personally identifiable data from > any database used to compose the message), where "obvious" means > the relevant entity is indicated, exists, is normally reachable by > the recipient, and is effectual to the purpose it is referred for. > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From vesely@tana.it Mon Jun 29 03:20:50 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0090E28C1F9 for ; Mon, 29 Jun 2009 03:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.073 X-Spam-Level: * X-Spam-Status: No, score=1.073 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 627+l6Z6crTz for ; Mon, 29 Jun 2009 03:20:49 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 05CCA28C1E8 for ; Mon, 29 Jun 2009 03:20:48 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 29 Jun 2009 12:21:02 +0200 id 00000000005DC030.000000004A48958E.000017B1 Message-ID: <4A48958D.7020701@tana.it> Date: Mon, 29 Jun 2009 12:21:01 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> <4A44F103.7010608@tana.it> <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> In-Reply-To: <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:20:50 -0000 Ian Eiloart wrote: >> Privacy laws are aimed at protecting people >> against undiscriminated usage of collected personally identifiable >> information, a.k.a. personal data. > > You're missing an important definition of "privacy" - the right to be > undisturbed (for example, by unsolicited advertising in your INBOX or on > your doormat). No, I'm not. Since email addresses and doormat locations are part of a recipient's personal data, recipients can exercise their right on whether that piece of information may be used to deliver that piece of advertising. Let me exemplify: my email address is on my town's public directory, and some used cars sellers want to advertise by email special deals in each town. An interpretation of "privacy" may imply that when the sellers copy my address into their list, at the same time notify me the details of their data processing. I don't want an email for that notification, just a machine readable note at my MX server. That note should arrive _before_ any email message, so that I can automatically delete my address from the sellers' list even before they send me any advertisement, if that's how I've configured the server. > Many people consider privacy to be simply the right to remain unobserved > (secrecy), but the right to be let alone is the basis of the UK's > "Privacy and Electronic Communications (EC Directive) Regulations 2003". > Those regulations are subsidiary to our Data Protection Act of 1998, but > don't arise from it. They are too abstract to be useful for any practical purpose. Nevertheless, they provide guidance. > Once upon a time, the two aspects of privacy were entwined by mass > illiteracy and slow communications. Nowadays, near ubiquitous > communications mean it's harder to voluntarily avoid interference by > keeping your location secret - partly because it's harder to keep it > secret, and partly because for many modern communications methods your > physical location doesn't matter. It's not secrecy, it's usage. I have the right to allow my address to stay on one list and delete it from another one. Even if both lists are public, my data is mine. From vesely@tana.it Mon Jun 29 03:24:51 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD413A6784 for ; Mon, 29 Jun 2009 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+NGS1gNnknY for ; Mon, 29 Jun 2009 03:24:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 89DDE3A689F for ; Mon, 29 Jun 2009 03:24:50 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 29 Jun 2009 12:25:10 +0200 id 00000000005DC030.000000004A489686.0000184F Message-ID: <4A489686.9070007@tana.it> Date: Mon, 29 Jun 2009 12:25:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090627231552.2163.qmail@simone.iecc.com> In-Reply-To: <20090627231552.2163.qmail@simone.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] No, we're not going to define spam X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:24:51 -0000 John Levine wrote: >>I suspect that if we are not even able to agree on a definition of >>spam, there will never be much efficient anti-spam research by our >>group. > > The world hasn't agreed on a definition of spam in 20 years, and I see > no reason to think that anything has changed that would make it > possible to do so now. The European directives on privacy arrived around the turn of the century, so they are new in that respect. They may have all the defects that European directives usually have, but provide definitions. Not for spam, as I mentioned upthread; however, spam can be treated in that framework. > Fortunately, all of the popular definitions (UBE, UCE, UBCE, mail > recipients don't want) in practice tend to describe roughly the same > mail. I'd say they just largely overlap. I'd guess one line of disagreement would be what kind of well behaved direct marketing, if any, should be considered non-spam. That is, whether the "U" in the above definition may be considered implicit, on the argument that recipients cannot solicit something whose existence they ignore. MRDW (I'd propose to pronounce it "mérde-u", if that's the correct acronym for the last definition), although practical, is horrible. I'd also add botnet/zombie generated, spam to that list. > So my suggestion is that documents discussing anti-spam > techniques say which definition they're using, if it matters, and > leave it at that. Readers specifically don't get to complain that > it's the wrong definition. +1 That way, at least, we know what we're talking about. In addition, this suggestion leaves room for an eventual informative paper listing those popular definitions. From claudio@telmon.org Mon Jun 29 03:41:40 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D442D3A6D6F for ; Mon, 29 Jun 2009 03:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjqsZxXvqRys for ; Mon, 29 Jun 2009 03:41:40 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 7550D3A6D5B for ; Mon, 29 Jun 2009 03:41:39 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+l3pMYuiAQm; Mon, 29 Jun 2009 12:41:58 +0200 Message-ID: <4A489A75.7060005@telmon.org> Date: Mon, 29 Jun 2009 12:41:57 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> <4A44F103.7010608@tana.it> <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> <4A48958D.7020701@tana.it> In-Reply-To: <4A48958D.7020701@tana.it> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:41:40 -0000 Alessandro Vesely wrote: > Let me exemplify: my email address is on my town's public directory, and > some used cars sellers want to advertise by email special deals in each > town. An interpretation of "privacy" may imply that when the sellers > copy my address into their list, at the same time notify me the details > of their data processing. I don't want an email for that notification, > just a machine readable note at my MX server. That note should arrive > _before_ any email message, so that I can automatically delete my > address from the sellers' list even before they send me any > advertisement, if that's how I've configured the server. This is another interesting example of "consent". Now, suppose that the "details" require some lines of free text description, so that you can properly decide if you like "how and why" they are using your address. There, you have a consent request. But the problem is, spammers won't be that polite, not even in Europe with our EU Directive :) So you will need to find a way to enforce compliance with this requirement for your address, that is, a way for the MTA to know who you authorized... -- Claudio Telmon claudio@telmon.org http://www.telmon.org From rsk@gsp.org Mon Jun 29 04:22:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45633A6D3D for ; Mon, 29 Jun 2009 04:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9-woB4dQLlu for ; Mon, 29 Jun 2009 04:22:12 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id CAA3B3A690C for ; Mon, 29 Jun 2009 04:22:11 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5TBMUJ6007926 for ; Mon, 29 Jun 2009 07:22:31 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5TBHciD013172 for ; Mon, 29 Jun 2009 07:17:38 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5TBMOis031955 for ; Mon, 29 Jun 2009 07:22:24 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5TBMOE3031954 for asrg@irtf.org; Mon, 29 Jun 2009 07:22:24 -0400 Date: Mon, 29 Jun 2009 07:22:24 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090629112224.GA31201@gsp.org> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:22:12 -0000 On Fri, Jun 26, 2009 at 12:13:02PM +0100, Ian Eiloart wrote: >> The canonical definition of spam (in the context of email) was settled >> on a very long time ago ("unsolicited bulk email") and is NOT in need of >> tinkering or refinement. It's served us very well -- and one reason >> why is that it's *deliberately* silent on a number of points. It would >> be a very serious mistake -- one that would greatly assist spammers -- >> to change that situation. > > Frankly, I don't like that definition. Specifically it misses an > important class of spam - well targeted, individualised, unsolicited > marketing messages which are necessarily unique (and hence not bulk). Two points: 1. Anything that's not bulk isn't spam, and is thus outside the consideration of this working group. It may be unwelcome or annoying or any number of other things, but none of that matters. 2. That definition does not miss any classes of [email] spam: it covers them all beautifully, which is one reason why it's not in need of revision. It is silent on the point of "targeting", for example, because it doesn't matter whether spam is targeted or not. It's silent on the point of whether messages are individualized, because *that* doesn't matter either. So, for example, suppose some spammer went through the trouble to enumerate which MTA you and I and 5000 other folks are using, and sent us UBE which (a) was targeted on a per-MTA basis and (b) addressed us by full name in the body. It's obviously UBE, thus obviously spam -- and equally obviously, covered the same long-standing definition that has served us well. ---Rsk From rsk@gsp.org Mon Jun 29 04:31:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B1D3A6D7A for ; Mon, 29 Jun 2009 04:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ismVlMHbStc for ; Mon, 29 Jun 2009 04:31:43 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 0EFFD3A6D2A for ; Mon, 29 Jun 2009 04:31:42 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5TBW2Lr000377 for ; Mon, 29 Jun 2009 07:32:03 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5TBR9P8029980 for ; Mon, 29 Jun 2009 07:27:09 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5TBVuZS032625 for ; Mon, 29 Jun 2009 07:31:56 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5TBVuCn032624 for asrg@irtf.org; Mon, 29 Jun 2009 07:31:56 -0400 Date: Mon, 29 Jun 2009 07:31:56 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090629113156.GA32258@gsp.org> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A437393.3060105@mines-paristech.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:31:43 -0000 On Thu, Jun 25, 2009 at 02:54:43PM +0200, Jose-Marcio Martins da Cruz wrote: > But also I have many **shared** identities. These identities correspond > to email addresses (administrative or not) which resolve to many people. > I can hardly see some kind of management of *shared consent* for these > addresses. A brief check of my own procmail config indicates that I'm on over 500 of these -- the overwhelming majority of which are role addresses such as those specified in RFC 2142. A secondary check indicates that about 3/4 of those are shared with one or more other people, which means I'd have to work out some kind of "shared consent" for several hundred addresses. That's not feasible in a reasonable period of time, especially since neither the addresses nor the pool of people they're shared with are static. ---Rsk From rsk@gsp.org Mon Jun 29 05:08:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F2F3A6917 for ; Mon, 29 Jun 2009 05:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljNDkVFSLoDw for ; Mon, 29 Jun 2009 05:08:13 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 59F6428C235 for ; Mon, 29 Jun 2009 05:08:13 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5TC8WI1032433 for ; Mon, 29 Jun 2009 08:08:33 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5TC3eua002269 for ; Mon, 29 Jun 2009 08:03:40 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5TC8QIN006873 for ; Mon, 29 Jun 2009 08:08:26 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5TC8QTZ006872 for asrg@irtf.org; Mon, 29 Jun 2009 08:08:26 -0400 Date: Mon, 29 Jun 2009 08:08:26 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090629120826.GA6823@gsp.org> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A43618A.6000205@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] VPNs (was: request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:08:14 -0000 On Thu, Jun 25, 2009 at 01:37:46PM +0200, Alessandro Vesely wrote: > AFAIK, there is no way SMTP can be configured so that a given sending > location can be whitelisted. One can try and detect what MTA sends the > message and whitelist specific filters, presumably doing detection by > the IP address of each mailout. That's much like VPN: being at a higher > level doesn't ease the task. For example, assume someone trusts Gmail's > egress filtering and wants to skip content filtering for mail coming from > there. What work is required to accomplish (and maintain) that task, on > typical MTA software? Yes, MTAs can be configured so that a given sending location -- that is, IP address -- is whitelisted. I do it all the time. But it's not a very good solution, and it doesn't scale. Moreover, it's brittle: if the sender's outbound mail server changes its address, then it stops working. Conversely, if someone else acquires that server's previous address, then it starts working for someone I didn't intend it to work for. Level of work? I think, roughly speaking, it's one or two lines of configuration with most MTAs. But (as I think you're pointing out) the actual configuration itself isn't the issue: it's the time and effort that it takes to figure out what should be in the configuration, and then to maintain it. ---Rsk From vesely@tana.it Mon Jun 29 06:38:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAAF3A6DE1 for ; Mon, 29 Jun 2009 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWVDAJKSd-4c for ; Mon, 29 Jun 2009 06:38:21 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 03F763A6DD5 for ; Mon, 29 Jun 2009 06:38:20 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 29 Jun 2009 15:38:05 +0200 id 00000000005DC036.000000004A48C3BD.00003C02 Message-ID: <4A48C3BC.90501@tana.it> Date: Mon, 29 Jun 2009 15:38:04 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <4A44A90A.9090503@tana.it> <20090626140320.B0C8C24300@panix5.panix.com> <4A44F103.7010608@tana.it> <11FD07CCCE54CCC7FB8A2513@lewes.staff.uscs.susx.ac.uk> <4A48958D.7020701@tana.it> <4A489A75.7060005@telmon.org> In-Reply-To: <4A489A75.7060005@telmon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 13:38:27 -0000 Claudio Telmon wrote: >> Let me exemplify: my email address is on my town's public directory, and >> some used cars sellers want to advertise by email special deals in each >> town. An interpretation of "privacy" may imply that when the sellers >> copy my address into their list, at the same time notify me the details >> of their data processing. I don't want an email for that notification, >> just a machine readable note at my MX server. That note should arrive >> _before_ any email message, so that I can automatically delete my >> address from the sellers' list even before they send me any >> advertisement, if that's how I've configured the server. > > This is another interesting example of "consent". Now, suppose that the > "details" require some lines of free text description, so that you can > properly decide if you like "how and why" they are using your address. > There, you have a consent request. Well, having to collect agreements for data processing from each subject is one of the most annoying applications of EU privacy directives. It is as when one says: "May I ask you XYZ?" And the other one replies: "Yes, you already did!" For email, it is possible to avoid that _that kind_ of consent requests become entries in the recipient's INBOX. One way to do so, considering multi-destination delivery a kind of forwarding (see sec. 3.9 of rfc5321), is being tentatively described at http://fixforwarding.org/. > But the problem is, spammers won't be that polite, not even in Europe > with our EU Directive :) So you will need to find a way to enforce > compliance with this requirement for your address, that is, a way for > the MTA to know who you authorized... It may be enough to provide a convenient way to do it, without enforcing it with blocking policies. While it seems self-evident that spammers are exempted from complying with anti-abuse message sender common practices, many careful senders may be classified as spammers according to the MRDW acceptation of the term spam. "Spammers" of the latter kind are sensible to reputation concepts and make a good faith effort to comply with common practices, because they reason that going along with prospects' desires is more remunerative than loosing their own reputation on questionable deeds. From claudio@telmon.org Mon Jun 29 06:52:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C35628C279 for ; Mon, 29 Jun 2009 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxk12DB97tbV for ; Mon, 29 Jun 2009 06:52:04 -0700 (PDT) Received: from slim-4a.inet.it (slim-4a.inet.it [213.92.5.126]) by core3.amsl.com (Postfix) with ESMTP id A822C28C23D for ; Mon, 29 Jun 2009 06:52:03 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+66HYyo62uL; Mon, 29 Jun 2009 15:12:14 +0200 Message-ID: <4A48BDAC.1060602@telmon.org> Date: Mon, 29 Jun 2009 15:12:12 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> In-Reply-To: <20090629113156.GA32258@gsp.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 13:52:05 -0000 Rich Kulawiec wrote: > A brief check of my own procmail config indicates that I'm on over 500 of > these -- the overwhelming majority of which are role addresses such as > those specified in RFC 2142. A secondary check indicates that about 3/4 > of those are shared with one or more other people, which means I'd have > to work out some kind of "shared consent" for several hundred addresses. > That's not feasible in a reasonable period of time, especially since > neither the addresses nor the pool of people they're shared with are static. Well, I suppose that most of those mailboxes shouldn't be consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant to be contacted by anybody that needs it, right? The same for the official contact addresses of companies. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From vesely@tana.it Mon Jun 29 07:46:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8993A6A08 for ; Mon, 29 Jun 2009 07:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPSe1bsQdHXU for ; Mon, 29 Jun 2009 07:46:43 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 838CE3A67B5 for ; Mon, 29 Jun 2009 07:46:43 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 29 Jun 2009 16:46:38 +0200 id 00000000005DC030.000000004A48D3CE.00004620 Message-ID: <4A48D3CD.9070206@tana.it> Date: Mon, 29 Jun 2009 16:46:37 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A44B317.9010409@tana.it> <4A46427C.3020608@telmon.org> In-Reply-To: <4A46427C.3020608@telmon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] request for review for a non FUSSP proposal X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:46:44 -0000 Claudio Telmon wrote: > Alessandro Vesely wrote: >> I think it may actually >> have more chances when explicitly targeted to guard children, rather >> than generically "non FUSSP". > > I considered to use terms like "protected mailboxes", but at the end I > didn't like it, since it describes an expected effect (protection) and > not what is actually done (enabling the framework). Also, while the > "children" case is a clear one, I think that many other classes of users > could benefit from this option. I only used the term FUSSP in the > message to this list :) What about "adult-assisted mailboxes"? Besides the fact that you could adapt an MTA to do mixed enabled and non-enabled reception on the same email address, if the two addresses correspond to different persons, a child and a supervising adult, you don't have to. Targeting children does not necessarily imply that adults refrain to self assist themselves, if they like. Having a clear case would help working out the specification details that are currently missing. (How much software is needed? What exactly should each piece of software do? Do both mailboxes have to be on the same host? And the database? Etc.) In addition, it may help reckoning a potential user base. Finally, anything that helps to protect the children may get the attention of specific organizations. From Jose-Marcio.Martins@mines-paristech.fr Mon Jun 29 08:35:24 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9406828C13A for ; Mon, 29 Jun 2009 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNahFPw1DrQ6 for ; Mon, 29 Jun 2009 08:35:23 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 9085B28C12C for ; Mon, 29 Jun 2009 08:35:23 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5TFZeuU015453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 17:35:40 +0200 (MEST) Message-ID: <4A48DFCF.9080305@mines-paristech.fr> Date: Mon, 29 Jun 2009 17:37:51 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 pango-text SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org> In-Reply-To: <4A48BDAC.1060602@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A48DF4C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A48DF4C.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:35:24 -0000 Claudio Telmon wrote: > Rich Kulawiec wrote: > >> A brief check of my own procmail config indicates that I'm on over 500 of >> these -- the overwhelming majority of which are role addresses such as >> those specified in RFC 2142. A secondary check indicates that about 3/4 >> of those are shared with one or more other people, which means I'd have >> to work out some kind of "shared consent" for several hundred addresses. >> That's not feasible in a reasonable period of time, especially since >> neither the addresses nor the pool of people they're shared with are static. > > Well, I suppose that most of those mailboxes shouldn't be > consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant > to be contacted by anybody that needs it, right? The same for the No ! > official contact addresses of companies. In fact, at our domain, few of these kind of adresses aren't protected. Most of them are adresses of the kind "everybody in the engineering department" (addresses which are of internal use only) "butterfly research workgroup" (a closed group working on some particular subject) and so. These are adresses which *are* protected and the concept of consent-enable is materialized by checking if the SMTP client sending messages to is in some known network or if the connection was authenticated. But nothing prevents that this kind of consent should be expanded. Either way, in an organisation like the ours, users couldn't understand that the same consent system used for individual addresses couldn't be used for collective addresses. From claudio@telmon.org Mon Jun 29 09:04:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5353A6DE7 for ; Mon, 29 Jun 2009 09:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR503XeAsLUm for ; Mon, 29 Jun 2009 09:04:26 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 9B8933A6DDB for ; Mon, 29 Jun 2009 09:04:25 -0700 (PDT) Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+uKqYI0quQ0; Mon, 29 Jun 2009 18:04:22 +0200 Message-ID: <4A48E605.5080507@telmon.org> Date: Mon, 29 Jun 2009 18:04:21 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org> <4A48DFCF.9080305@mines-paristech.fr> In-Reply-To: <4A48DFCF.9080305@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:04:27 -0000 Jose-Marcio Martins da Cruz wrote: > Claudio Telmon wrote: >> Rich Kulawiec wrote: >> >>> A brief check of my own procmail config indicates that I'm on over >>> 500 of >>> these -- the overwhelming majority of which are role addresses such as >>> those specified in RFC 2142. A secondary check indicates that about 3/4 >>> of those are shared with one or more other people, which means I'd have >>> to work out some kind of "shared consent" for several hundred addresses. >>> That's not feasible in a reasonable period of time, especially since >>> neither the addresses nor the pool of people they're shared with are >>> static. >> >> Well, I suppose that most of those mailboxes shouldn't be >> consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant >> to be contacted by anybody that needs it, right? The same for the > > No ! > I'm just saying that RFC 2142 are not meant to be consent-enabled. Anybody should be able to contact these addresses, but: - other (antispam) protections may well be enabled; - other shared addresses may be meant to be "for closed groups" or consent-enabled >> official contact addresses of companies. > > In fact, at our domain, few of these kind of adresses aren't protected. > Most of them are adresses of the kind "everybody in the engineering > department" (addresses which are of internal use only) "butterfly > research workgroup" (a closed group working on some particular subject) > and so. These are adresses which *are* protected and the concept of > consent-enable is materialized by checking if the SMTP client sending > messages to is in some known network or if the connection was > authenticated. But nothing prevents that this kind of consent should be > expanded. Either way, in an organisation like the ours, users couldn't > understand that the same consent system used for individual addresses > couldn't be used for collective addresses. This is a very interesting case. I'll have to think at the implications of it. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From asrg3@billmail.scconsult.com Mon Jun 29 09:35:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930B63A6B91 for ; Mon, 29 Jun 2009 09:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7mY4pnsNti9 for ; Mon, 29 Jun 2009 09:35:34 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 88EE83A6B73 for ; Mon, 29 Jun 2009 09:35:34 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 2F5998E0857 for ; Mon, 29 Jun 2009 12:35:52 -0400 (EDT) Message-ID: <4A48ED68.8010901@billmail.scconsult.com> Date: Mon, 29 Jun 2009 12:35:52 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> In-Reply-To: <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:35:36 -0000 Douglas Otis wrote, On 6/16/09 8:24 PM: > > On Jun 16, 2009, at 3:55 PM, John Levine wrote: [...] >> We've had a variety of proposals to identify mail client hosts. See >> http://mipassoc.org/csv/ > > The CSV effort proved most providers do not want their MTAs identified > as belonging to them, even when it could improve email acceptance. Not really. As far as I can tell, provider attention was not controlled for in that experiment. In my experience the awareness of existing Internet standards, the Internet standards process, and the "open unstructured testing in production" model that dominates the development of new protocol features among people running mail systems and companies selling mail services is very low. I would be shocked if most providers of mail services even today are aware of the CSV proposals' existence at any level, either corporately or among their technical staff. > This > might be especially true now after their support staff has been reduced. Obviously that plays strongly into the awareness issue. From asrg3@billmail.scconsult.com Mon Jun 29 10:35:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E9C3A6B93 for ; Mon, 29 Jun 2009 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bahqcf+O1EYZ for ; Mon, 29 Jun 2009 10:35:47 -0700 (PDT) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 2A96D3A6B91 for ; Mon, 29 Jun 2009 10:35:47 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 7942A8E091C for ; Mon, 29 Jun 2009 13:36:00 -0400 (EDT) Message-ID: <4A48FB80.10709@billmail.scconsult.com> Date: Mon, 29 Jun 2009 13:36:00 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4A3F76B8.2030409@terabites.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 17:35:48 -0000 Ian Eiloart wrote, On 6/22/09 10:16 AM: > > > --On 22 June 2009 07:19:04 -0500 Gordon Peterson > wrote: [...] >> In my personal mailboxes I have (way) more than 50,000 archived >> bounceback messages to e-mails which I have never sent... just because >> they have a (forged, and generally invalid) From: address that is >> supposedly in one of my domains. >> >> Since I haven't sent these messages (neither intentionally, nor by >> irresponsible management of my systems here) there is NOTHING I can do to >> prevent such messages. > > There is, actually. If you publish SPF records with a strong -all, then > recipients can easily decide to reject (not bounce) messages. Add DKIM > signatures, and they'll be able to tell when someone has forwarded your > legitimate email. Do you have any evidence that this actually works to any detectable degree? I have solid proof that it is far from perfect, but I only have a handful of addresses that ever had significant bogus bounce flow in the one domain I could safely use in a SPF '-all' effectiveness test. The first 5 years of that test have shown a slow drop in the rate of bad bounces in general offered to that domain, but it isn't much more proportionally than the drop from a dribble to a trickle that I've seen for a domain with no SPF record. The noise in my minuscule and weakly controlled data makes it quantitatively worthless, but on a qualitative basis it makes clear that strong SPF records are not yet a strong universal tool for preventing blowback bounces. If you are aware of SPF being any more useful than prayer at controlling blowback, please share it. From asrg3@billmail.scconsult.com Mon Jun 29 11:49:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C1F28C251 for ; Mon, 29 Jun 2009 11:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4RnGl5U0laR for ; Mon, 29 Jun 2009 11:49:27 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 5EAEA3A6AF1 for ; Mon, 29 Jun 2009 11:49:27 -0700 (PDT) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 80F688E0A25 for ; Mon, 29 Jun 2009 14:49:41 -0400 (EDT) Message-ID: <4A490CC5.8020601@billmail.scconsult.com> Date: Mon, 29 Jun 2009 14:49:41 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> In-Reply-To: <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 18:49:29 -0000 David Nicol wrote, On 6/20/09 7:06 PM: > On Sat, Jun 20, 2009 at 2:20 PM, Alessandro Vesely wrote: >> However, in practice one needs an email address to do any legitimate use of >> SMTP, and hence a domain is required. > > There isn't any technical reason why MUA software can't do its own > delivery with today's technology. The whole concept of "outbound MTA" > seems like a throwback. With the exception of delivery delays, but > having a MUA attempt its own delivery and then switch to the smarthost > on connection or other temporary failure wouldn't require any > inspiration. Injecting a concrete fact into the scholastic debate... The original Eudora (before it became an alpha-quality extension for a beta version of Thunderbird) had such functionality going back at least to the early 90's. That was not an expression of any sort of advanced modern technology, but rather a necessity for the early days of putting a MUA on a personal system instead of on a shared system with its own local submission and queuing system. The reasons that younger MUA's do not offer that are social, not technical. It has never been particularly difficult technically for a MUA to work without a smarthost/MSA, but for the past decade it has been increasingly difficult because receiving systems have become less trusting of random strangers as clients. It is empirically useful for a receiving system to assume that mail offered via SMTP from an IP that is being used by a personal computer without useful sender authentication (which might be "this IP is on my network") is some variety of spam. The "outbound MTA" (or more properly: MSA) is not a throwback, but a relative novelty. Hypothesizing its elimination without a model for eliminating the preconditions that led to it being a standard part of how people use mail is pointless. Those preconditions are: 1. There is no working global mechanism for identifying an accountable party (i.e. one who explicitly *accepts* accountability) from an IP address, due largely to the political and historical variations in how IP addresses have been allocated. 2. A large fraction of users who have theoretical control over the traffic coming from a public IP address do not have the requisite understanding of their own systems and how they use those systems to be accountable for the traffic generated by them. Funneling email through MSA systems run by providers that in principle have some means of holding their users accountable and are capable of at least understanding bad behavior in mail if not always keeping it controlled is the best partial workaround we have, and it implies the need for domain-level accountability or its equivalent. The fact that other models could work technically is not relevant unless they come with strong mechanisms to work around those social gaps. From dotis@mail-abuse.org Mon Jun 29 11:54:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8AB28C2EB for ; Mon, 29 Jun 2009 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKMlsgVMGz4b for ; Mon, 29 Jun 2009 11:54:11 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 4DD6428C2EA for ; Mon, 29 Jun 2009 11:53:44 -0700 (PDT) Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 09548A94439 for ; Mon, 29 Jun 2009 18:53:48 +0000 (UTC) Message-Id: From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 11:53:47 -0700 References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 18:54:13 -0000 On Jun 29, 2009, at 1:12 AM, Ian Eiloart wrote: > --On 26 June 2009 11:37:21 -0700 Douglas Otis > wrote: > >> This draft fails to include a definition that encompasses a crucial >> and safe point of control essential for effective spam mitigation. >> The missing definition is that of the Outbound MTA, the entity >> granting access and facilitating public SMTP exchanges to other >> domains. Email-Arch's definition tends to understate the role with: >> Outbound MTA, an MTA that relays messages to other ADMDs. > > Defining an "outbound MTA" would be useful, I guess. See: http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor9 A definition for spam sources should acknowledge RFC 5321 Sender is not the _only_ identifier that might be used to manage spam. It may even prove impractical or unsafe to attempt to check where a message may have been created and initially entered, as Section 1.3.1 definition for Sender seems to imply. This Sender definition runs afoul of several SMTP concepts. The RFC 5321 Sender does not define persons, automated-systems, or groups that create or enter messages. The Mail command defines an error notification path (reverse-path) and not a person, automated-system, or group responsible for having created or entered the message. In fact, the error notification path might be NULL in some cases. This can not be referring to the EHLO command, since this would be the SMTP client, and not not a person, automated-system, or group responsible for having created or entered the message. By even using the word "Sender" and implying this identifies a person, automated-system, or group responsible for having created or entered the message confuses RFC 5321 identifiers with those of RFC 5322. One might assume that redefinition of RFC 5321 is the underlying intent of this draft. Rather than misusing the term "Sender", perhaps the term "RFC 5321 Originating Identifiers" would be better. A list of Originating Identifiers could include those expressed by either RFC 5321 MAIL or EHLO commands. Omission and erroneous definition may have a tendency to preclude other options. While no one likes to find the outbound MTA they are using has been blocked for policy reasons, it is often possible to rectify this by obtaining access to a different outbound MTA. When the domain used in an email-address is blocked for policy reasons, rectification may require abandonment of the email-address domain instead. There are no perfect solutions. Policy based upon the EHLO command, rather than the Mail command, may provide more efficacious, practical, and scalable solutions than policies based upon the MAIL command. This draft should not preclude the use of the EHLO identity, nor misconstrue MAIL command assertions. >> What level? > > The paper isn't discussing particular proposals, but you seem to be > saying that it should. It's discussing certain desirable properties > of proposals. Perhaps you're looking for more detail, or something > closer to an actual solution. The draft should drop its current definition of Sender. Spam does not just originate from purported RFC 5321 Senders, nor is it safe to assume that an MTA authorization referenced by an RFC 5321 Sender asserts where a message was initially created and entered. Authorization does not provide this property. > If you want to say that a desirable proposal would be scalable, then > that's fine. If you want to say that SPF doesn't scale for a > particular reason, then that's outside the scope of this proposal. Stronger statements along the lines of scaling might be helpful. It seems increasing potential DNS transactions by an order of magnitude or more has not been given adequate consideration in some anti-spam efforts. :^( -Doug From johnl@iecc.com Mon Jun 29 14:05:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4AF3A6977 for ; Mon, 29 Jun 2009 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.8 X-Spam-Level: X-Spam-Status: No, score=-18.8 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTI-6Wcj2sgF for ; Mon, 29 Jun 2009 14:05:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 9B61C3A67B0 for ; Mon, 29 Jun 2009 14:05:18 -0700 (PDT) Received: (qmail 93870 invoked from network); 29 Jun 2009 21:05:37 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 29 Jun 2009 21:05:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=EFAAkpmp6IbCNSW77j/Hg8JAs4rYJHFlDngAqHDY4uw=; b=ecRf63H1OxJEKPDr+wlYjvbzosPZ2zOJ/Nkk7XKoWrqKC34RSTA+J0dJihFQHY+o2BA673L5GOqivSRPghq8O2EqNb5RYd9cVqsdgv9fNpTkh66lmLVMYVzwIyEbbzFXMuEAlSLJiHczAtjBxzFcvfnbVaL1/HB4kwbHUN7CYyw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=EFAAkpmp6IbCNSW77j/Hg8JAs4rYJHFlDngAqHDY4uw=; b=LVW1ylOMD0YiZ1JbYumFIRvToCMNqHeRX4/ioCO7QzzLcUM5r9XaRbUe3nquwSZXTi14U22jb4XXGZYpSG+6p0Ran+ck62TPbJv41N1ZvvPafXfWH6LsxNq+6hEMd3U09oUjOZCB+wbq0pLy1wRh4ChGPkpPsS+pWOIgqvdDHqs= Date: 29 Jun 2009 21:05:37 -0000 Message-ID: <20090629210537.59382.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090629112224.GA31201@gsp.org> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] really, we're not going to define spam, was draft-irtf-asrg-criteria X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:05:19 -0000 >>> The canonical definition of spam (in the context of email) was >>> settled on a very long time ago ("unsolicited bulk email") and is >>> NOT in need of tinkering or refinement. It's a perfectly good definition, but it's not the only one. It is not, for example, the one used in any law that regulates spam (they all use some version of UCE), nor is it the one used by ISPs who provide a junk mail button to their users (some version of mail their users don't want.) We've all seen all the arguments about the reasons to prefer one definition over another so DO NOT rehash them here. I can think of few things less productive than to argue about whether people over whom we have no influence are using the "wrong" definition of spam, so don't. Like I said, in contexts where it matters which definition you're using, tell us. R's, John From johnl@iecc.com Mon Jun 29 14:09:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F7F28C2F0 for ; Mon, 29 Jun 2009 14:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.175 X-Spam-Level: X-Spam-Status: No, score=-19.175 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3X9cnooqJ8W for ; Mon, 29 Jun 2009 14:09:57 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id C24DF28C2A6 for ; Mon, 29 Jun 2009 14:09:56 -0700 (PDT) Received: (qmail 99537 invoked from network); 29 Jun 2009 21:10:16 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 29 Jun 2009 21:10:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; olt=johnl@user.iecc.com; bh=P0T+yCXvRHyvBinMyzRcV6ZLtTGGk0pf1b6oZ22TG7c=; b=C3Q02qy3DPI1SBPEHITSuGJQ+9s1lL8VqXkt5u+UJzDj7J5Sd2Jplt3i3r6T2578YAQVKsPdvJCHgM1WlxJBCtD78DSHnHPSf/bguZNXLyH5OxgHpTPgymOu5YyEFxF/1MFg/BX1OU2nddLY26+PUz+vRzxLLqyHjCPzZ+WkWYw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0906; bh=P0T+yCXvRHyvBinMyzRcV6ZLtTGGk0pf1b6oZ22TG7c=; b=fyk982bDrwPWtuw1ygei5W3byFkplPW2OKr0htusj5Fbobaqus1+31sOY7d11VtDjxyWsRW1hE6kP1HNfxjr4z6WxEGXDWNUKR2yJ+0MO37WHFC7Vbvg0fT7arI3bavDj+wcaDjj5RQiFt7CC2WFbwYi79ffCEB6HVZteeH5zpw= Date: 29 Jun 2009 21:10:16 -0000 Message-ID: <20090629211016.60522.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <4A490CC5.8020601@billmail.scconsult.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:09:57 -0000 >The reasons that younger MUA's do not offer that are social, not technical. >It has never been particularly difficult technically for a MUA to work >without a smarthost/MSA, ... Well, for fairly loose definitions of "work", since I've never seen an MUA that did retries on soft failure. Now the question is essentially moot, since any legitimate mail sent direct from an MUA is swamped in the flood from bots. R's, John From rsk@gsp.org Mon Jun 29 15:27:19 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F113A6DD1 for ; Mon, 29 Jun 2009 15:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tffkxbfzPnd for ; Mon, 29 Jun 2009 15:27:19 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id E8C513A6B64 for ; Mon, 29 Jun 2009 15:27:18 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5TMRbVi023781 for ; Mon, 29 Jun 2009 18:27:38 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5TMMiSW008581 for ; Mon, 29 Jun 2009 18:22:44 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5TMRWgc029394 for ; Mon, 29 Jun 2009 18:27:32 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5TMRW1u029393 for asrg@irtf.org; Mon, 29 Jun 2009 18:27:32 -0400 Date: Mon, 29 Jun 2009 18:27:32 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090629222732.GC23581@gsp.org> References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A48BDAC.1060602@telmon.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 22:27:19 -0000 On Mon, Jun 29, 2009 at 03:12:12PM +0200, Claudio Telmon wrote: > consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant > to be contacted by anybody that needs it, right? The same for the > official contact addresses of companies. In some cases, yes: certainly "abuse" is a role address that should be reachable by everyone. But for a counterexample, the "-request" and "-owner" addresses corresponding to various mailing lists don't need to be. (Neither do some mailing list addresses.) It's turned out to be rather complicated in practice to figure out what policies each role address should use, doubly so when there are sharply differing opinions among the people sharing those addresses. I can't claim to have any "good" answers to this, only "adequate" ones. ---Rsk From vesely@tana.it Tue Jun 30 00:41:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194C528C1F6 for ; Tue, 30 Jun 2009 00:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTUd3AXajjQ1 for ; Tue, 30 Jun 2009 00:41:53 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 0DDB73A6CFC for ; Tue, 30 Jun 2009 00:41:52 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 30 Jun 2009 09:42:07 +0200 id 00000000005DC033.000000004A49C1CF.000048C6 Message-ID: <4A49C1DD.8020205@tana.it> Date: Tue, 30 Jun 2009 09:42:21 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: asrg@irtf.org References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> In-Reply-To: <4A490CC5.8020601@billmail.scconsult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 07:41:54 -0000 Bill Cole wrote: > 1. There is no working global mechanism for identifying an accountable > party (i.e. one who explicitly *accepts* accountability) from an IP > address, due largely to the political and historical variations in how > IP addresses have been allocated. At a first glance, this may seem a flaw in the rDNS/whois systems. Upon reconsideration, I realize I have no means to accept accountability for an IP address of mines, since SPF or CSV/CSA only convey authorization for using a name. In facts, we don't even have a term for "the accountable party related to an IP address". Dave's Email Arch mentions an Originator as "accountable for the message content", but doesn't relate it to an IP address. Rfc5068 associates accountability after submission with traceability features of the MSA, apparently suggesting that the first relaying thereafter is from an IP which is (indirectly) accountable for the message content. Reasoning by induction on the hops, one may conclude that all relays using a smarthost are accountable: smarthosts require either IP/firewall configuration or authentication (assuming they are not open relays.) Accountability breaks at the MX-driven relay, often referred as "boundary". > Funneling email through MSA systems run by providers that in principle > have some means of holding their users accountable and are capable of at > least understanding bad behavior in mail if not always keeping it > controlled is the best partial workaround we have, and it implies the > need for domain-level accountability or its equivalent. Why is it partial? "Domain-level accountability" is a good approximation. However, a smarthost is not necessarily within the same domain (e.g. ukisp.com is not even in the same 1st level domain) or the same organization. How does accountability degrade through indirection? That is, would you trust an SMTP client the same if it relays on behalf of some other party? From vesely@tana.it Tue Jun 30 01:54:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E9F3A68EA for ; Tue, 30 Jun 2009 01:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UohZm6I+asaq for ; Tue, 30 Jun 2009 01:54:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D0FDB28C32C for ; Tue, 30 Jun 2009 01:54:06 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 30 Jun 2009 10:41:34 +0200 id 00000000005DC031.000000004A49CFBE.000051BC Message-ID: <4A49CFCC.7040802@tana.it> Date: Tue, 30 Jun 2009 10:41:48 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <20090629120826.GA6823@gsp.org> In-Reply-To: <20090629120826.GA6823@gsp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] VPNs X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 08:54:12 -0000 Rich Kulawiec wrote: > On Thu, Jun 25, 2009 at 01:37:46PM +0200, Alessandro Vesely wrote: >> AFAIK, there is no way SMTP can be configured so that a given sending >> location can be whitelisted. [...] > > Yes, MTAs can be configured so that a given sending location -- that is, > IP address -- is whitelisted. I do it all the time. But it's not a > very good solution, and it doesn't scale. Moreover, it's brittle: if the > sender's outbound mail server changes its address, then it stops working. > Conversely, if someone else acquires that server's previous address, > then it starts working for someone I didn't intend it to work for. > > Level of work? I think, roughly speaking, it's one or two lines of > configuration with most MTAs. But (as I think you're pointing out) the > actual configuration itself isn't the issue: it's the time and effort > that it takes to figure out what should be in the configuration, and > then to maintain it. Thanks for confirming that. My feeling is that we are overloading IP numbers with an accountability functionality that doesn't belong there. For a different approach, there is a Message Security Level[1] SMTP extension that allows the above configuration to be written as example.com: /SECURITY=STARTTLS for each destination domain. That way, on can establish secure mail delivery channels between trusted domains, connected by an untrusted public network. It works by recognizing the certificates rather than the IP addresses. The option configured merely requires that TLS is used at each hop; it may be specified on the MAIL FROM command. 1: http://www.courier-mta.org/draft-varshavchik-security-smtpext.txt From iane@sussex.ac.uk Tue Jun 30 02:55:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D39F3A6CE4 for ; Tue, 30 Jun 2009 02:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxPLidjenJbP for ; Tue, 30 Jun 2009 02:55:44 -0700 (PDT) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 166603A6AF6 for ; Tue, 30 Jun 2009 02:55:43 -0700 (PDT) Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:52533) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from ) id KM1Q90-000E60-69 for asrg@irtf.org; Tue, 30 Jun 2009 10:55:48 +0100 Date: Tue, 30 Jun 2009 10:55:04 +0100 From: Ian Eiloart Sender: iane@sussex.ac.uk To: asrg@irtf.org Message-ID: <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> In-Reply-To: <4A48FB80.10709@billmail.scconsult.com> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> Originator-Info: login-token=Mulberry:01vvpVTydbw7T/Z6mxKiAxb8jCJHJ2qSEgM2U=; token_authority=support@its.sussex.ac.uk X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Sussex: true X-Sussex-transport: remote_smtp Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:55:45 -0000 --On 29 June 2009 13:36:00 -0400 Bill Cole wrote: > >> There is, actually. If you publish SPF records with a strong -all, then >> recipients can easily decide to reject (not bounce) messages. Add DKIM >> signatures, and they'll be able to tell when someone has forwarded your >> legitimate email. > > Do you have any evidence that this actually works to any detectable > degree? > > I have solid proof that it is far from perfect, but I only have a handful > of addresses that ever had significant bogus bounce flow in the one > domain I could safely use in a SPF '-all' effectiveness test. The first 5 > years of that test have shown a slow drop in the rate of bad bounces in > general offered to that domain, but it isn't much more proportionally > than the drop from a dribble to a trickle that I've seen for a domain > with no SPF record. The noise in my minuscule and weakly controlled data > makes it quantitatively worthless, but on a qualitative basis it makes > clear that strong SPF records are not yet a strong universal tool for > preventing blowback bounces. > > If you are aware of SPF being any more useful than prayer at controlling > blowback, please share it. Well, my claim is a theoretical one, and perhaps a hope for the future. It probably isn't yet effective. I do believe that it will be one day. However, I do believe that people should take SPF records into account when deciding whether to generate bounce messages. It should not be a problem if there's a positive SPF or DKIM match. You shouldn't do it if there's an SPF fail. It's harder to decide what to do in the absence of SPF, or a neutral or softfail result. I'd suggest that to drive up adoption of SPF, don't bounce for a neutral or softfail result (instead give a 5xx error), but (this will be controversial) feel free to bounce into domains that aren't trying to help - ie domains that don't publish SPF records at all. (ducks). -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From Jose-Marcio.Martins@mines-paristech.fr Tue Jun 30 03:17:02 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1FA3A6E45 for ; Tue, 30 Jun 2009 03:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR+pfwJTeLa8 for ; Tue, 30 Jun 2009 03:17:01 -0700 (PDT) Received: from boipeva.ensmp.fr (cobra.ensmp.fr [194.214.158.101]) by core3.amsl.com (Postfix) with ESMTP id 91E753A6E40 for ; Tue, 30 Jun 2009 03:17:01 -0700 (PDT) Received: from localhost.localdomain (minho.ensmp.fr [10.3.5.5]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.3/8.14.3/JMMC-11/Feb/2009) with ESMTP id n5UAEmgq004455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 12:14:49 +0200 (MEST) Message-ID: <4A49E61B.4010307@mines-paristech.fr> Date: Tue, 30 Jun 2009 12:16:59 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc11 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <20090629113156.GA32258@gsp.org> <4A48BDAC.1060602@telmon.org> <4A48DFCF.9080305@mines-paristech.fr> <4A48E605.5080507@telmon.org> In-Reply-To: <4A48E605.5080507@telmon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 4A49E598.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A49E598.000/10.3.5.5/minho.ensmp.fr/localhost.localdomain/ Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:17:02 -0000 Claudio Telmon wrote: > Jose-Marcio Martins da Cruz wrote: > >>> official contact addresses of companies. >> In fact, at our domain, few of these kind of adresses aren't protected. >> Most of them are adresses of the kind "everybody in the engineering >> department" (addresses which are of internal use only) "butterfly >> research workgroup" (a closed group working on some particular subject) >> and so. These are adresses which *are* protected and the concept of >> consent-enable is materialized by checking if the SMTP client sending >> messages to is in some known network or if the connection was >> authenticated. But nothing prevents that this kind of consent should be >> expanded. Either way, in an organisation like the ours, users couldn't >> understand that the same consent system used for individual addresses >> couldn't be used for collective addresses. > > This is a very interesting case. I'll have to think at the implications > of it. You got the message ! 8-) And as said Rich, I'm only pointing you points to taking into account. From rsk@gsp.org Tue Jun 30 04:11:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82E33A6D95 for ; Tue, 30 Jun 2009 04:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4qoEBy1M-1a for ; Tue, 30 Jun 2009 04:11:37 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id E27FA3A6B66 for ; Tue, 30 Jun 2009 04:11:36 -0700 (PDT) Received: from squonk.gsp.org (bltmd-207.114.17.162.dsl.charm.net [207.114.17.162]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n5UBBDM7017419 for ; Tue, 30 Jun 2009 07:11:14 -0400 (EDT) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n5UB6HFr026109 for ; Tue, 30 Jun 2009 07:06:17 -0400 (EDT) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n5UBB79g020655 for ; Tue, 30 Jun 2009 07:11:07 -0400 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n5UBB5NO020558 for asrg@irtf.org; Tue, 30 Jun 2009 07:11:05 -0400 Date: Tue, 30 Jun 2009 07:11:05 -0400 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090630111105.GA12502@gsp.org> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 11:11:37 -0000 On Tue, Jun 30, 2009 at 10:55:04AM +0100, Ian Eiloart wrote: > However, I do believe that people should take SPF records into account > when deciding whether to generate bounce messages. Despite the ostentatious claims made by its originator ("Spam as a technical problem is solved by SPF"), SPF has no anti-spam value. Nor should it be used when deciding whether to generate a bounce: the answer to that is always "no". It's far better to reject (not to mention far simpler, with any sane MTA) and thus greatly diminish the possibility of outscatter/backscatter spam. ---Rsk From dotzero@gmail.com Tue Jun 30 10:17:54 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8943A6B07 for ; Tue, 30 Jun 2009 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbmVnrVaP7SB for ; Tue, 30 Jun 2009 10:17:54 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id D62873A6A3E for ; Tue, 30 Jun 2009 10:17:53 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so123807qwd.7 for ; Tue, 30 Jun 2009 10:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WItlnIEL+R8E5+YIdR1Bc5sCk8J2++1goBb+g3dmiqE=; b=LOB5geVrqb/RjSrZohVlovVC0TY9kyHk4k1gcvpjM5FUz/KkwIdhmg8XtjhnOWkpdV fTFa13B5o5QYnMmxQ5IWhTbO2X5BFnNv3D1TzVb/jfkzyT5/xz2u0H7mPRbLLgs40G+E StoPVZ8mNxCbXPXiljxsSBZkmnTLFCK2NbwCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=MUnnAwPpkDd7t2XqLY/2d+tRsUC5z50IFjvK+Sczyacp5v7MuosXozLx8zrUrsvQWT yfmwQ3AbAQVIV7GekakCrKHF4VTGh9Novse2rM98zWSCHjpGYQV/wm5eQ5Y2Gxcmd1M9 GKDwDNUUenmbZiGq2sUfrHzbXpTs6wiPD0ZE0= MIME-Version: 1.0 Received: by 10.220.45.80 with SMTP id d16mr6800148vcf.93.1246382251511; Tue, 30 Jun 2009 10:17:31 -0700 (PDT) In-Reply-To: <20090630111105.GA12502@gsp.org> References: <4A3F76B8.2030409@terabites.com> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org> Date: Tue, 30 Jun 2009 13:17:31 -0400 Message-ID: <7ae58c220906301017i49fb9413n41683acf67b16110@mail.gmail.com> From: Dotzero To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:17:54 -0000 On Tue, Jun 30, 2009 at 7:11 AM, Rich Kulawiec wrote: > On Tue, Jun 30, 2009 at 10:55:04AM +0100, Ian Eiloart wrote: >> However, I do believe that people should take SPF records into account >> when deciding whether to generate bounce messages. > > Despite the ostentatious claims made by its originator ("Spam as a > technical problem is solved by SPF"), SPF has no anti-spam value. > Nor should it be used when deciding whether to generate a bounce: > the answer to that is always "no". =A0It's far better to reject (not > to mention far simpler, with any sane MTA) and thus greatly diminish > the possibility of outscatter/backscatter spam. > > ---Rsk I'm going to agree with Rich that it's better to reject than to bounce. I can't speak to whether SPF has anti-spam value generally but my experience with publishing -all records for a number of well known large sending sites is that it is useful in addressing phishing at the risk of a small amount of breakage. (Different folks will have different thresholds for this type of tradeoff) This is particularly true if used in conjunction with DKIM signing all outbound mail and making an assertion that one signs all mail. For other types of senders YMMV. As far as whether this is empirical or anecdotal, my statements are based on a corpus of approximately 750 million sent emails with analysis of outbound MTA logs for immediate rejects/bounces as well as bounces/DSNs that come in later. From john@jlc.net Tue Jun 30 11:40:04 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C053A6E7C for ; Tue, 30 Jun 2009 11:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtoWfmKppqHj for ; Tue, 30 Jun 2009 11:40:03 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 238563A6B8E for ; Tue, 30 Jun 2009 11:40:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 499AE33C95; Tue, 30 Jun 2009 14:40:18 -0400 (EDT) Date: Tue, 30 Jun 2009 14:40:18 -0400 From: John Leslie To: asrg@irtf.org Message-ID: <20090630184018.GK57980@verdi> References: <20090616225543.11524.qmail@simone.iecc.com> <628BBDFC-0DDE-47B6-BC41-EAF846EE9D5D@mail-abuse.org> <4A48ED68.8010901@billmail.scconsult.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A48ED68.8010901@billmail.scconsult.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:40:04 -0000 Bill Cole wrote: > > In my experience the awareness of existing Internet standards, the Internet > standards process, and the "open unstructured testing in production" model > that dominates the development of new protocol features among people > running mail systems and companies selling mail services is very low. I > would be shocked if most providers of mail services even today are aware of > the CSV proposals' existence at any level, either corporately or among > their technical staff. Available evidence supports that... I've been running CSV on input for years. Of 5 million recent email sessions on one server, I found 148 CSA entries, of which only 6 from cheetahmail.com indicated CSV authorization for the IP address connecting to us. For research purposes I list the "not-authorized" HELO domains: 123mail.org 2-mail.com airpost.net bestmail.us cluemail.com collaborations.com elitemail.org eml.cc f-m.fm fast-email.com fastem.com fastmail.cn fastmail.co.uk fastmail.fm fastmail.net fastmail.to fastmail.us fmgirl.com imap.cc letterboxes.org mail mailbolt.com mailc.net mailforce.net mailftp.com mailite.com mailnew.com mailservice.ms -- John Leslie From john@jlc.net Tue Jun 30 13:02:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED5D3A6EEF for ; Tue, 30 Jun 2009 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6-DTp9KQalc for ; Tue, 30 Jun 2009 13:02:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 2AC4B3A6EEC for ; Tue, 30 Jun 2009 13:02:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4FB7233CA1; Tue, 30 Jun 2009 16:01:50 -0400 (EDT) Date: Tue, 30 Jun 2009 16:01:50 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090630200150.GL57980@verdi> References: <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <4A3D366E.2020304@tana.it> <934f64a20906201606pff54ca3y904da141013f1d2a@mail.gmail.com> <4A490CC5.8020601@billmail.scconsult.com> <4A49C1DD.8020205@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A49C1DD.8020205@tana.it> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] What are the IPs that sends mail for a domain? X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:02:13 -0000 Alessandro Vesely wrote: > Bill Cole wrote: > >> 1. There is no working global mechanism for identifying an accountable >> party (i.e. one who explicitly *accepts* accountability) from an IP >> address, due largely to the political and historical variations in how >> IP addresses have been allocated. > > At a first glance, this may seem a flaw in the rDNS/whois systems. > Upon reconsideration, I realize I have no means to accept > accountability for an IP address of mines, since SPF or CSV/CSA only > convey authorization for using a name. I'm not certain whether that is a helpful statement. SPF doesn't really "convey authorization for using" a name. It sets out to convey information about which IP addresses are "expected" to be used by MTAs sending emails "using" a name. But even that evades us as SPF calls for executing a particular algorithm which returns pass/fail (or something else...). CSV _does_ set out to convey _exactly_ "authorization for using a name" in the HELO command; but the standard CSA query generally returns a list of IP addresses which are "authorized" to use that HELO name. > In facts, we don't even have a term for "the accountable party related > to an IP address". Are you sure that's a useful concept? The CSV paradigm is that the operator of a MTA should exercise some responsibility for what is sends. The HELO string identifies the MTA (though not necessarily one string exclusively by one MTA), and the DNS management for that domain-name string states whether that domain exercises responsibility (and by automatic return of A)ddress RRs on SRV queries, what IP address(es) that MTA uses). While this perhaps comes "close", it's not designating an "accountable party"; and the IP address is related to the HELO string, not the other way around. It does _not_ lead to an "accountable party" -- it merely associates a reference string (the domain name) that we can use as a query to reputation services. > Dave's Email Arch mentions an Originator as "accountable for the > message content", but doesn't relate it to an IP address. ... or anything else... > Rfc5068 " " This note recommends conventions for the operation of email submission " and transport services between independent operators, such as " enterprises and Internet Service Providers. > associates accountability after submission with traceability features > of the MSA, apparently suggesting that the first relaying thereafter > is from an IP which is (indirectly) accountable for the message content. Actually, " " Relaying and delivering employ policies that occur after submission and " are outside the scope of this document. RFC5068 deals with the operation of Mail Submission Agents. I don't agree it even "suggests" how accountablity should follow the message as it winds its way to the recipient. -- John Leslie From claudio@telmon.org Tue Jun 30 14:45:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D6F3A68BD for ; Tue, 30 Jun 2009 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mgzaoSVOeu1 for ; Tue, 30 Jun 2009 14:45:47 -0700 (PDT) Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id 1067A3A67AE for ; Tue, 30 Jun 2009 14:45:46 -0700 (PDT) Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+PuQWvv25pHN; Tue, 30 Jun 2009 23:46:07 +0200 Message-ID: <4A4A879D.80008@telmon.org> Date: Tue, 30 Jun 2009 23:46:05 +0200 From: Claudio Telmon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> In-Reply-To: <4A439639.9090106@mines-paristech.fr> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] VPNs vs consent X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 21:45:48 -0000 Jose-Marcio Martins da Cruz wrote: > The other problem I mentioned is multiple addresses > (jose-marcio.martins_da_cruz, jose-marcio.martins, martins, ...). I > can't imagine managing preferences for each identity, nor a system > telling that each address is equivalent to some other one, in a domain > with, say, 10000 or more users. > I need some more clarification on this, maybe it's just me not knowing enough about MTAs internals. As the border MTA receives a RCPT TO for either of these addresses, it should be able to know if it is a valid address. In my (very limited) experience, this means that each of these addresses mut be defined as a valid address, the MTA doesn't have rules to decide that since jose-marcio.martins_da_cruz is a valid address, jose-marcio.martins must be valid too. So, if each of these addresses is individually defined in some list/database accessed by the MTA, then with the same rules, the related token database should be accessed too. Should an "automatic aliasing" rule exist, then the same rule could exist for the token database. Also, if "somewhere" an alias is defined for an address, then the correspondent database could just be a pointer to the database of the "main" address. This could even implement "chains of aliases" as "chains of pointers to token databases". This unless you use forwarding, which is not aliasing and which should be handled as having different addresses. Now, from the user perspective, the address book management tool could just keep a "default" token database, that is valid for each address the user send messages from. So, each time a correspondent is added, the appropriate token is pushed on the MTA databases for all the user's addresses. While this may seem a lot of work and "database space", again this should be in fact fully automated and need very little space compared to current mailbox sizes. Should there be a specific address that needs different tokens for different addresses, this could be explicitly set when adding the address to the address book. Again, since it is just the address owner that knows if a correspondent is permitted to send messages to one address and not to an alias, there is no solution but to involve some manual handling by the user. > Unless you're able to build an "usine à gaz" (as we say in France), with > preferences for each valid address, there isn't a clean solution. I think this is feasible with an appropriate address book manager. Anyway, the load is for the MUA, not for the MTA, so the number of users shouldn't matter. -- Claudio Telmon claudio@telmon.org http://www.telmon.org From danny.angus@gmail.com Mon Jun 29 23:46:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5B228C1F2 for ; Mon, 29 Jun 2009 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-XXLtRbqEnY for ; Mon, 29 Jun 2009 23:46:32 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 76B9628C144 for ; Mon, 29 Jun 2009 23:46:32 -0700 (PDT) Received: by bwz9 with SMTP id 9so30309bwz.7 for ; Mon, 29 Jun 2009 23:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5tfrum0H+rdSbnbrd2ZCZY497qXF4Kg8z85k0WSgtKw=; b=LPkcc7ClGtHxiHMmjb3phs9auTcjZ+Lm63ghIPr4cVwBx2gzZLXCJuu4J0M4l0WxRK st2QpTPutLT4yZ7/ZHAiiFPdlEpUOJYiGYURMmfKGQmU0LbpokLVK3Ie9bQc2c0IRapi +6iazHA5MMr6QJNSY9fnbcba75LfqH6kJ3yoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qm/BzUvzHPCvjju+ZEvaDX6+MvtcjBVba/4/qtENTF31IisajPCEdBlhOvSEGSOerp 7d2DvpmIjp5od1UkoXRhIAHZ1bGBDS2+/ekAWJEd1tbyUIJXvjXxKl+/4I2YeaClplAN IiJMCDbKE404AnNdPMi99Ca7wT/3PLgNmEW7o= MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr4950629fas.102.1246344399662; Mon, 29 Jun 2009 23:46:39 -0700 (PDT) In-Reply-To: References: <4A43B696.2000106@cybernothing.org> <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org> <7B7CEB6C086D94C295E661B1@lewes.staff.uscs.susx.ac.uk> <32FAD477-3720-466B-8A02-464ED4004859@mail-abuse.org> <7E7339F784451F2FF12B6C2F@lewes.staff.uscs.susx.ac.uk> Date: Tue, 30 Jun 2009 07:46:39 +0100 Message-ID: <5ec229170906292346o375faf34m273f6499029f333a@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 30 Jun 2009 15:46:23 -0700 Subject: Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition. X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:46:33 -0000 Ok, point taken about outbound MTA I'm not sure what this is about.. > The draft should drop its current definition of Sender. =C2=A0Spam does n= ot just > originate from purported RFC 5321 Senders, nor is it safe to assume that = an > MTA authorization referenced by an RFC 5321 Sender asserts where a messag= e > was initially created and entered. =C2=A0Authorization does not provide t= his > property. > Stronger statements along the lines of scaling might be helpful. =C2=A0It= seems > increasing potential DNS transactions by an order of magnitude or more ha= s > not been given adequate consideration in some anti-spam efforts. :^( I think the statements about scaling are clear, do you not? d. From danny.angus@gmail.com Tue Jun 30 00:04:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E803A6859 for ; Tue, 30 Jun 2009 00:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyR6pGRSw3fK for ; Tue, 30 Jun 2009 00:04:29 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 7FF383A6977 for ; Tue, 30 Jun 2009 00:04:29 -0700 (PDT) Received: by fxm9 with SMTP id 9so841473fxm.7 for ; Tue, 30 Jun 2009 00:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ZviOxiVjjntE4YA+mGeZWO9QTVOdbF9y4Cca+8qRJhA=; b=HlRVnhXQbXbfFXkgp2nu74Er1OyJC1hDWKXCGPvPQCZRmVLeDe50/H0e7V68FHrzTk Pq1Mf0TTv/crr/oNRZQZI24Bq/KZcYJuFvYR4NF7NwzcJUB+1I6EI5mOocLHCNoxIq9z pukqy/VOF/UUnmmizTDp5KNRDDWchNaJJB8Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=R82E14cLRTG8IUl4IImGsh7/qALIhj4sLDbrDDWnCAUtcDldX06LKNUqu3NaXNeby1 22/qF6LzuNPbBhp1jdt4T7secwenN/Sq2lifhDYNMDrq61lNIGKjT27PjuO5/9/EuvbA Tr1k0OBEg0kGcLEEngUNdYx6bqIdQ27NqXhvs= MIME-Version: 1.0 Received: by 10.223.127.8 with SMTP id e8mr5021658fas.81.1246345488174; Tue, 30 Jun 2009 00:04:48 -0700 (PDT) In-Reply-To: <4A452A12.2070302@cybernothing.org> References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> Date: Tue, 30 Jun 2009 08:04:48 +0100 Message-ID: <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> From: Danny Angus To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Jun 2009 15:46:23 -0700 Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 07:04:30 -0000 On Fri, Jun 26, 2009 at 9:05 PM, J.D. Falk wrote: > Alessandro Vesely wrote: > >> However, I think an it could, and should, go beyond that. For >> example, why is it not in the scope of that document "to attempt to >> distinguish or justify any more detailed definition of [the term spam]"? > > Because attempting to define "spam" is the very best way to ensure that a > document is never finished. In fact trying to define spam would ensure it never got started! Actually I would have liked to have included *some* definition, but because members of this group hold pretty entrenched opinions covering most possible definitions I felt that on the one hand it would be impossible and on the other hand it would be unecessary. I believe that it is unnecessary for two reasons, the first being that this group cannot agree a definition, yet operates reasonably successfully, and secondly there can be an empirical test for a solution, even if there is no agreed definition of spam itself. d. From steve@blighty.com Tue Jun 30 16:04:33 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3583A6B2E for ; Tue, 30 Jun 2009 16:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3-NVvvvfCiV for ; Tue, 30 Jun 2009 16:04:32 -0700 (PDT) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 4B8D03A6B09 for ; Tue, 30 Jun 2009 16:04:32 -0700 (PDT) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 686DC806FE for ; Tue, 30 Jun 2009 16:04:39 -0700 (PDT) Message-Id: From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 16:04:51 -0700 References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 23:04:33 -0000 On Jun 30, 2009, at 12:04 AM, Danny Angus wrote: > On Fri, Jun 26, 2009 at 9:05 PM, J.D. Falk > wrote: >> Alessandro Vesely wrote: >> >>> However, I think an it could, and should, go beyond that. For >>> example, why is it not in the scope of that document "to attempt to >>> distinguish or justify any more detailed definition of [the term >>> spam]"? >> >> Because attempting to define "spam" is the very best way to ensure >> that a >> document is never finished. > > > In fact trying to define spam would ensure it never got started! > > Actually I would have liked to have included *some* definition, but > because members of this group hold pretty entrenched opinions covering > most possible definitions I felt that on the one hand it would be > impossible and on the other hand it would be unecessary. > > I believe that it is unnecessary for two reasons, the first being that > this group cannot agree a definition, yet operates reasonably > successfully, and secondly there can be an empirical test for a > solution, even if there is no agreed definition of spam itself. One issue is that there are a number of definitions of spam that are useful in different contexts. The definition that's useful for operational handling at an abuse desk is different to that for operational handling of inbound mail filters, different again to that useful for someone developing content based filters, different again for someone drafting legislation and very different again for someone litigating. All of these definitions are fairly well defined and extremely useful in the context in which they're used. And they'll generally agree on the categorization of the vast majority of emails, but there are emails where they'll disagree. This isn't a problem. The problem arises when someone, anyone, claims that there is One True Definition of spam. The fact that that's blatantly false isn't the problem. That it causes hordes of people to come out of the woodwork to argue for their One True Definition of spam, causing yet another rerun of the Thread That Would Not Die is the problem. (A problem that's usually best solved by killfiling anyone participating in that sort of thread). Cheers, Steve From sethb@panix.com Tue Jun 30 21:53:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841C63A6ABF for ; Tue, 30 Jun 2009 21:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIPm0txTHEJU for ; Tue, 30 Jun 2009 21:53:15 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id D4FA43A6767 for ; Tue, 30 Jun 2009 21:53:15 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id E5A2638E47 for ; Wed, 1 Jul 2009 00:53:36 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id DAA7624307; Wed, 1 Jul 2009 00:53:36 -0400 (EDT) From: Seth To: asrg@irtf.org In-reply-to: (message from Steve Atkins on Tue, 30 Jun 2009 16:04:51 -0700) References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <4A452A12.2070302@cybernothing.org> <5ec229170906300004m687af225vf5a3f621646f5fcb@mail.gmail.com> Message-Id: <20090701045336.DAA7624307@panix5.panix.com> Date: Wed, 1 Jul 2009 00:53:36 -0400 (EDT) Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 04:53:16 -0000 It seems clear that different definitions are useful for different things; in particular, different methods are better or worse depending on the definition used. For instance, it seems apparent that using "This Is Spam" buttons hit by users to train filters will do best under a definition like "email users say is spam". My suggestion of filtering confirmations through the ISP (so the site clicked on is theirs rather than the sender's, and they record the click and notify the sender) works really well using an "unsolicited" definition, and less well using a "user complaints" definition (since it's well known that users sometimes complain about mail they solicited). So, it can be worthwhile to specify which definition you're using when you suggest a method to optimize under that definition. But that's pure practicality, it has nothing to do with "right" or "wrong". There's no such thing with definitions. Rather, the purpose of a definition is to enable discussion about something without having to describe it in full each time it's mentioned. Seth