From msk@cloudmark.com Tue Oct 18 12:01:35 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A551021F8B74 for ; Tue, 18 Oct 2011 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XSv6ncXIa5s for ; Tue, 18 Oct 2011 12:01:34 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4081221F85F2 for ; Tue, 18 Oct 2011 12:01:23 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 18 Oct 2011 12:01:22 -0700 From: "Murray S. Kucherawy" To: "asrg@irtf.org" Date: Tue, 18 Oct 2011 12:01:21 -0700 Thread-Topic: Greylisting BCP Thread-Index: AcyNyFMiwGiS2GCfTAOjHwpIcL/KzA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C14AC6EXCHC2corpclo_" MIME-Version: 1.0 Subject: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 18 Oct 2011 19:01:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14AC6EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After some chatter inside MAAWG and on the ietf-smtp mailing list, I've sta= rted an outline for a BCP on the practice of greylisting. The main purpose= is to explain what it is, discuss the pros and cons of its variants, and g= ive some recommendations for implementation and configuration for a few exa= mple installations and policies. The draft (which is currently only an outline) is here: https://datatracker= .ietf.org/doc/draft-kucherawy-greylisting-bcp/ Comments welcome. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C14AC6EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After some chatt= er inside MAAWG and on the ietf-smtp mailing list, I’ve started an ou= tline for a BCP on the practice of greylisting.  The main purpose is t= o explain what it is, discuss the pros and cons of its variants, and give s= ome recommendations for implementation and configuration for a few example = installations and policies.

 <= /o:p>

The draft (which is currently only an outline= ) is here: https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp= /

 

Comments welcome.

 <= /p>

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14AC6EXCHC2corpclo_-- From feenberg@nber.org Tue Oct 18 12:42:30 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082BA21F8D7B for ; Tue, 18 Oct 2011 12:42:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUYpDI1tqL29 for ; Tue, 18 Oct 2011 12:42:29 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6B21F8DC1 for ; Tue, 18 Oct 2011 12:42:28 -0700 (PDT) Received: from nber7.nber.org (nber7.nber.org [66.251.72.41]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id p9IJgPAF071549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Oct 2011 15:42:25 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from localhost (feenberg@localhost) by nber7.nber.org (8.14.4/8.14.4/Submit) with ESMTP id p9IJgOMa003611; Tue, 18 Oct 2011 15:42:25 -0400 X-Authentication-Warning: nber7.nber.org: feenberg owned process doing -bs Date: Tue, 18 Oct 2011 15:42:24 -0400 (EDT) From: Daniel Feenberg To: Anti-Spam Research Group - IRTF In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-79550136-1409308532-1318966945=:27058" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20111018 #5493725, check: 20111018 clean Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 18 Oct 2011 19:42:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---79550136-1409308532-1318966945=:27058 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 18 Oct 2011, Murray S. Kucherawy wrote: > > After some chatter inside MAAWG and on the ietf-smtp mailing list, IĘve started an > outline for a BCP on the practice of greylisting.† The main purpose is to explain > what it is, discuss the pros and cons of its variants, and give some recommendations > for implementation and configuration for a few example installations and policies. > > † > > The draft (which is currently only an outline) is here: > https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp/ > > † > > Comments welcome. Where should comments go? I have a question really, though it might be construed as a comment. Why do greylisters match on the (sender, receipient, MTA) triple rather on just the MTA? Isn't it nearly certain that if an MTA returns for one sender/receipient pair, it will return for any pair? So that keeping track of all three seems unnecessary and increases the probability of a message being delayed. What am I missing? Daniel Feenberg NBER > > † > > -MSK > > > ---79550136-1409308532-1318966945=:27058-- From clewis@xplornet.com Tue Oct 18 16:12:21 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A921F8AF2 for ; Tue, 18 Oct 2011 16:12:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZNjKhE9iI0T for ; Tue, 18 Oct 2011 16:12:20 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by ietfa.amsl.com (Postfix) with ESMTP id D64EC21F8AEC for ; Tue, 18 Oct 2011 16:12:20 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay04.hostedemail.com (Postfix) with SMTP id 850BAF0282 for ; Tue, 18 Oct 2011 23:12:19 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 636C657769734078706C6F726E65742E636F6D X-Filterd-Recvd-Size: 2028 Received: from [192.168.0.8] (unknown [174.35.130.2]) (Authenticated sender: clewis@xplornet.com) by omf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Oct 2011 23:12:18 +0000 (UTC) Message-ID: <4E9E07D2.4090304@xplornet.com> Date: Tue, 18 Oct 2011 19:12:18 -0400 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 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] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 18 Oct 2011 23:12:21 -0000 On 11-10-18 03:42 PM, Daniel Feenberg wrote: > Where should comments go? I have a question really, though it might be > construed as a comment. Why do greylisters match on the (sender, > receipient, MTA) triple rather on just the MTA? Isn't it nearly certain > that if an MTA returns for one sender/receipient pair, it will return > for any pair? So that keeping track of all three seems unnecessary and > increases the probability of a message being delayed. What am I missing? As I understand it, some grey-listing systems match on sender/recipient pairs (not MTA) so as to not penalize clustered outbounds that share queues. There's all sorts of 'optimizations'/variations that you can apply for different behaviours. You're right, _just_ the MTA would work just about as well for the main use case: bot armies. But that's not the only potential use-case. There is a danger in specifying the precise details/tuning values of a "standardized gray listing" mechanism. If it's too predictable, you could probably come up with a simplistic mechanism for defeating it without requiring the complexity of queuing. "Hybrid vigor" is a good thing. From dotis@mail-abuse.org Tue Oct 18 20:39:16 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B811F0C87 for ; Tue, 18 Oct 2011 20:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9omfQp7CHBN for ; Tue, 18 Oct 2011 20:39:15 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id DC5D71F0C86 for ; Tue, 18 Oct 2011 20:39:15 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 8DE436E012C for ; Wed, 19 Oct 2011 03:39:13 +0000 (UTC) Received: from dhcp100.priv.bungi.com (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 147B1A9443B for ; Wed, 19 Oct 2011 03:39:14 +0000 (UTC) Message-ID: <4E9E4661.30205@mail-abuse.org> Date: Tue, 18 Oct 2011 20:39:13 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 03:39:16 -0000 On 10/18/11 12:42 PM, Daniel Feenberg wrote: > > > On Tue, 18 Oct 2011, Murray S. Kucherawy wrote: > >> >> After some chatter inside MAAWG and on the ietf-smtp mailing list, >> Iíve started an >> outline for a BCP on the practice of greylisting. The main purpose is >> to explain >> what it is, discuss the pros and cons of its variants, and give some >> recommendations >> for implementation and configuration for a few example installations >> and policies. >> >> >> >> The draft (which is currently only an outline) is here: >> https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp/ >> >> >> >> Comments welcome. > > Where should comments go? I have a question really, though it might be > construed as a comment. Why do greylisters match on the (sender, > receipient, MTA) triple rather on just the MTA? Isn't it nearly > certain that if an MTA returns for one sender/receipient pair, it will > return for any pair? So that keeping track of all three seems > unnecessary and increases the probability of a message being delayed. > What am I missing? Grey listing challenges stateful processing of the sender to test an often erroneous assumption that bots sending spam don't maintain state. Thanks to grey listing, many bots retry against the same recipients, just not always with the same message. Heuristic methods are quickly defeated once deployed on enough systems. Defining practices for failing concepts seems misguided since such heuristics are likely to make other erroneous assumptions related to the nature of the outbound MTA. We employ temp errors to prioritize limited resources which may delay sources with lower reputations. When they are in the middle of some campaign, the delay may persist until their run completes. There would not be any way to predict how long that might take, nor would any hint likely affect the average bulk sender focused on completing their runs. We are about to publish a list that categorizes this type of behavior. I agree it would make more sense to focus on knowing which domain _controls_ the outbound MTA without umpteen additional transactions. With outbound MTA authentication, receivers would have a sure and robust basis for avoiding abusive transactions, where grey listing would be considered wasted efforts. -Doug From Jose-Marcio.Martins@mines-paristech.fr Wed Oct 19 03:11:18 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653D21F8B56 for ; Wed, 19 Oct 2011 03:11:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgfhM4L-QKSD for ; Wed, 19 Oct 2011 03:11:17 -0700 (PDT) Received: from smtp-3.ensmp.fr (smtp-3.ensmp.fr [194.214.158.227]) by ietfa.amsl.com (Postfix) with ESMTP id 723D421F8B54 for ; Wed, 19 Oct 2011 03:11:17 -0700 (PDT) Received: from localhost.localdomain (bororo [10.3.5.15]) (authenticated bits=0) by smtp-3.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id p9JABE4o011207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 12:11:15 +0200 (MEST) Message-ID: <4E9EA250.7070403@mines-paristech.fr> Date: Wed, 19 Oct 2011 12:11:28 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc14 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E07D2.4090304@xplornet.com> In-Reply-To: <4E9E07D2.4090304@xplornet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at cascavel with ID 4E9EA242.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4E9EA242.000 from bororo/bororo/10.3.5.15/localhost.localdomain/ Cc: Chris Lewis Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2011 10:11:18 -0000 Chris Lewis wrote: > On 11-10-18 03:42 PM, Daniel Feenberg wrote: > > As I understand it, some grey-listing systems match on sender/recipient > pairs (not MTA) so as to not penalize clustered outbounds that share > queues. > > There's all sorts of 'optimizations'/variations that you can apply for > different behaviours. > > You're right, _just_ the MTA would work just about as well for the main > use case: bot armies. But that's not the only potential use-case. > > There is a danger in specifying the precise details/tuning values of a > "standardized gray listing" mechanism. If it's too predictable, you > could probably come up with a simplistic mechanism for defeating it > without requiring the complexity of queuing. "Hybrid vigor" is a good > thing. I think I agree with most you said. Maybe not all. Greylisting is there and it will exist for some time. There are good and bad variations/optimisations, good and bad software configurations... This BCP should not generalize saying that all greylisting is bad, even if some people are tempted to say so. It seems to me that this BCP mention only problems caused by the filters. What's still lacking in the BCP proposal is a section about the behaviour of senders MTAs, which, IMHO, causes a lot of problems too. Some examples of bad things which really causes problems to greylistings : * Some MTAs from some (big) ISPs, which connects 3 to 5 times within some seconds and try again only after some hours (some equals something between 4 to 24 hours). * Some ISPs using a pool of sending MTAs which IP addresses are randomly distributed over ranges without any common part. Something like 193.xxx.xxx.xxx followed by 67.xxx.xxx.xxx... * Some sender MTAs which begins retrying each some seconds (1 to 10) during some days, and ends being catched by some rate limit mechanism. * Some bad configured or misinterpreted 4xx reply code * ... -- From martijn.grooten@virusbtn.com Wed Oct 19 08:05:40 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F14F21F8C67 for ; Wed, 19 Oct 2011 08:05:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2za8nbsWy-h4 for ; Wed, 19 Oct 2011 08:05:39 -0700 (PDT) Received: from mx3.sophos.com (mx3.sophos.com [216.47.234.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8D26621F8C65 for ; Wed, 19 Oct 2011 08:05:39 -0700 (PDT) Received: from mx3.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B189918875C for ; Wed, 19 Oct 2011 16:05:38 +0100 (BST) Received: from uk-exch2.green.sophos (uk-exch2.green.sophos [10.100.199.17]) by mx3.sophos.com (Postfix) with ESMTPS id 57C44188214 for ; Wed, 19 Oct 2011 16:05:38 +0100 (BST) Received: from UK-EXCHMBX1.green.sophos ([fe80:0000:0000:0000:e1bd:d3c1:23.222.229.221]) by uk-exch2.green.sophos ([10.100.199.17]) with mapi; Wed, 19 Oct 2011 16:05:35 +0100 From: Martijn Grooten To: Anti-Spam Research Group - IRTF Date: Wed, 19 Oct 2011 16:05:35 +0100 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyN62oE1zfLNTw3TH29RcgMISZ73QAgwuSw Message-ID: <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> References: <4E9E07D2.4090304@xplornet.com> In-Reply-To: <4E9E07D2.4090304@xplornet.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 15:05:40 -0000 > There is a danger in specifying the precise details/tuning values of a > "standardized gray listing" mechanism. If it's too predictable, you > could probably come up with a simplistic mechanism for defeating it > without requiring the complexity of queuing. "Hybrid vigor" is a good > thing. Good point. I like the idea of a BCP though and I like the outline too. Some quick comments: Do people apply greylisting post-DATA in practise? Or is this really only s= omething only performed in labs as it is the only way to determine whether = causes false positives. It is hard to reliably determine how much greylisting helps on a specific s= ystem, i.e. what difference it makes compared to the hypothetical situation= greylisting wasn't used. May be an idea to include some caution about that= . "greylisting is more expensive than not greylisting" Can you explain this? "special actions to take if the same message is retried before the time lim= it expires" I assume by "message" you mean the (sender, recipient, MTA) triplet? Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. From hjp-asrg@hjp.at Wed Oct 19 08:59:21 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C8F21F8C7A for ; Wed, 19 Oct 2011 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.17 X-Spam-Level: * X-Spam-Status: No, score=1.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tpM1r2Z0c5W for ; Wed, 19 Oct 2011 08:59:20 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5A021F8C63 for ; Wed, 19 Oct 2011 08:59:19 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id 356DB4042; Wed, 19 Oct 2011 17:58:59 +0200 (CEST) Date: Wed, 19 Oct 2011 17:58:59 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20111019155859.GB21602@hjp.at> References: <4E9E07D2.4090304@xplornet.com> <4E9EA250.7070403@mines-paristech.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <4E9EA250.7070403@mines-paristech.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 15:59:21 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-10-19 12:11:28 +0200, Jose-Marcio Martins da Cruz wrote: > What's still lacking in the BCP proposal is a section about the behaviour= =20 > of senders MTAs, which, IMHO, causes a lot of problems too. > > Some examples of bad things which really causes problems to greylistings : > > * Some MTAs from some (big) ISPs, which connects 3 to 5 times within some= =20 > seconds and try again only after some hours (some equals something=20 > between 4 to 24 hours). > > * Some ISPs using a pool of sending MTAs which IP addresses are randomly= =20 > distributed over ranges without any common part. Something like=20 > 193.xxx.xxx.xxx followed by 67.xxx.xxx.xxx... > > * Some sender MTAs which begins retrying each some seconds (1 to 10)=20 > during some days, and ends being catched by some rate limit mechanism. * Some sender MTAs change the envelope sender with every delivery attempt (Yahoo Groups used to do this, but stopped several years ago. I don't know any recent example). This garantuees that the triple never matches ... * Some ISPs use one machine for the first delivery and another for processing the queue. The "queue processing" IP will get whitelisted but the "first try" address wont (unless you are lucky), resulting in a constant delay for every mail. > * Some bad configured or misinterpreted 4xx reply code Some MTAs (e.g. old versions of Groupwise) don't understand 4xx at all and treat it like 5xx. hp --=20 _ | Peter J. Holzer | Web 2.0 k=F6nnte man also auch =FCbersetzen als |_|_) | Sysadmin WSR | "Netz der kleinen Geister". | | | hjp@hjp.at |=20 __/ | http://www.hjp.at/ | -- Oliver Cromm in desd --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFOnvPCfZ+RkG8quy0RAnKWAKC2QN+NnzxbPVl5CC6LwomdnJUidgCfTxCS 5vXSXJ0Ima913T8Q6S3lJJ0= =7zZr -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From joseph.sniderman@thoroquel.org Wed Oct 19 09:19:58 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFFA21F8CE5 for ; Wed, 19 Oct 2011 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb+uvXTi0l2s for ; Wed, 19 Oct 2011 09:19:57 -0700 (PDT) Received: from mail.thoroquel.org (mail.thoroquel.org [IPv6:2001:470:b8c1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 291EA21F8CE4 for ; Wed, 19 Oct 2011 09:19:56 -0700 (PDT) Received: from [IPv6:2604:8800:101:1::c] (histamine.home.thoroquel.com [IPv6:2604:8800:101:1::c]) (authenticated bits=0) by mail.thoroquel.org (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9JGJpTi005255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 16:19:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoroquel.org; s=thoroquel2a; t=1319041194; bh=Pe0VpE71y7I1WS79fqFIljo0YXJv24db2RwX2VCHJV0=; h=Message-ID:Date:From:To:Subject:References:In-Reply-To:OpenPGP: Content-Type:Content-Transfer-Encoding:CC; b=ZHmHZpAp3lNNrM/u8yOtGyBR8i9ozXcsJj+vQwn19rrLkq6pDNRfHY5a0KcrKjZq1 d1zlvIOMzEiahLWUBM1EPdSNVj/Pgy6izFyQrmAQ8h9Jj1neey3TBLYN8DLV1dFkbd gqH1wxm73NLtCGXWdyEOwOhDFeZYJXqqh4A5YoeurD2jKIgBpwPhbPDDzQxAYl1nw1 ml8xPplvKGFN/XXvBAaHkDaALxPuRhKd+o0py6JTrXbL8M8g1BrtkXqlTwc9E/gajX n+IcnbDCm1fkgHYg74aB3OiKD9/xjP+YAv5mVs/ej7hxz6DJffbmNSS+D2HdEM5419 hshwH/9PvVcKQ== Message-ID: <4E9EF8A8.2030404@arpawocky.com> Date: Wed, 19 Oct 2011 12:19:52 -0400 From: Joe Sniderman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: asrg@irtf.org References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> In-Reply-To: <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> X-Enigmail-Version: 1.1.1 OpenPGP: id=605721CA; url=https://www.thoroquel.org/keys/PGP_605721CA.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 16:19:58 -0000 On 10/19/2011 11:05 AM, Martijn Grooten wrote: >> There is a danger in specifying the precise details/tuning values >> of a "standardized gray listing" mechanism. If it's too >> predictable, you could probably come up with a simplistic mechanism >> for defeating it without requiring the complexity of queuing. >> "Hybrid vigor" is a good thing. > > Good point. > > I like the idea of a BCP though and I like the outline too. me too > Some quick comments: > > Do people apply greylisting post-DATA in practise? milter-greylist supports greylisting during DATA (not sure if its at the beginning of DATA or at the end, could try it easily enough and find out though) by means of the dacl configuration directive (as opposed to racl for greylisting during RCPT) AFAIK the DCC also can perform greylisting during DATA. Might be worth adding a section to for greylisting performed during DATA. There's also some interesting archive discussion regarding it on the Mimedefang list: http://lists.roaringpenguin.com/pipermail/mimedefang/2009-May/034793.html It would appear from that discussion that at least Roaring Penguin probably does do so in practice. > Or is this really > only something only performed in labs as it is the only way to > determine whether causes false positives. AFAIK one of the supposed benefits of greylisting during DATA instead of RCPT is reduction of false positives. > It is hard to reliably determine how much greylisting helps on a > specific system, i.e. what difference it makes compared to the > hypothetical situation greylisting wasn't used. May be an idea to > include some caution about that. Log delivery attempts that are greylisted. Log greylisted delivery attempts that subsequently pass. Compare the IPs in question against whatever DNSBLs are in use to determine if the delivery attempts would have been blocked anyway (without resorting to computationally expensive content filtering).... Might also make sense to log the DNSBL result at the time that a delivery attempt is greylisted, and then log delivery attempts that pass greylisting but are rejecting due to DNSBLs, and thereby determine if greylisting is effectively giving a recently gone-bad host extra time to get itself listed. > "greylisting is more expensive than not greylisting" > > Can you explain this? > > "special actions to take if the same message is retried before the > time limit expires" > > I assume by "message" you mean the (sender, recipient, MTA) triplet? Or if performed during DATA it could mean the same message data or at least sufficiently similar message data, or even sender, recipient, message-id triplet, or some other combo. -- Joe Sniderman From martijn.grooten@virusbtn.com Wed Oct 19 11:42:40 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850CF21F8AEC for ; Wed, 19 Oct 2011 11:42:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQcOG6WCf0Hn for ; Wed, 19 Oct 2011 11:42:40 -0700 (PDT) Received: from mx4.sophos.com (mx4.sophos.com [216.47.234.213]) by ietfa.amsl.com (Postfix) with ESMTP id E502221F8AED for ; Wed, 19 Oct 2011 11:42:38 -0700 (PDT) Received: from mx4.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AFC6A4E0451 for ; Wed, 19 Oct 2011 19:42:37 +0100 (BST) Received: from uk-exch1.green.sophos (uk-exch1.green.sophos [10.100.199.16]) by mx4.sophos.com (Postfix) with ESMTPS id 3D2744E043B for ; Wed, 19 Oct 2011 19:42:37 +0100 (BST) Received: from UK-EXCHMBX1.green.sophos ([fe80:0000:0000:0000:e1bd:d3c1:23.222.229.221]) by uk-exch1.green.sophos ([10.100.199.16]) with mapi; Wed, 19 Oct 2011 19:42:34 +0100 From: Martijn Grooten To: Anti-Spam Research Group - IRTF Date: Wed, 19 Oct 2011 19:42:34 +0100 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyOeva3xG0DCy39RhOEJbfwJF+YegAERWoA Message-ID: <18B53BA2A483AD45962AAD1397BE1325382F2CC82C@UK-EXCHMBX1.green.sophos> References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> <4E9EF8A8.2030404@arpawocky.com> In-Reply-To: <4E9EF8A8.2030404@arpawocky.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 18:42:40 -0000 > > It is hard to reliably determine how much greylisting helps on a > > specific system, i.e. what difference it makes compared to the > > hypothetical situation greylisting wasn't used. May be an idea to > > include some caution about that. > > Log delivery attempts that are greylisted. Log greylisted delivery > attempts that subsequently pass. Compare the IPs in question against > whatever DNSBLs are in use to determine if the delivery attempts would > have been blocked anyway (without resorting to computationally > expensive > content filtering).... > > Might also make sense to log the DNSBL result at the time that a > delivery attempt is greylisted, and then log delivery attempts that > pass > greylisting but are rejecting due to DNSBLs, and thereby determine if > greylisting is effectively giving a recently gone-bad host extra time > to > get itself listed. Yes, that makes sense and, if you're running a test (and don't care too muc= h about computational performance) could be extended to content scanning to= o. But that assumes you are able to identify messages, which I doubt is possib= le to do in a reliable way unless you greylist during/post DATA. Which -- a= t least in theory -- does not need to give the same results as greylisting = at an earlier stage. I guess the only way to really test the effectiveness of (your version of) = greylisting (on your mail stream) is if you have a reasonably large stream = and you split that feed in two random groups and use greylisting one group = only. (I suppose most people don't care as much about measuring effectiveness as = I do, nor should they, but including something about effectiveness may be a= good idea as this is the main reason people use greylisting.) Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. From joseph.sniderman@thoroquel.org Wed Oct 19 12:22:44 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649EE21F8B09 for ; Wed, 19 Oct 2011 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtS+mM6wSUGp for ; Wed, 19 Oct 2011 12:22:40 -0700 (PDT) Received: from mail.thoroquel.org (mail.thoroquel.org [IPv6:2001:470:b8c1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D23DE21F8AFE for ; Wed, 19 Oct 2011 12:22:39 -0700 (PDT) Received: from [IPv6:2604:8800:101:1::c] (histamine.home.thoroquel.com [IPv6:2604:8800:101:1::c]) (authenticated bits=0) by mail.thoroquel.org (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9JJMXTv005572 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 19:22:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoroquel.org; s=thoroquel2a; t=1319052157; bh=ExvxMNvEXL2eYlSmqn+7BhvwjSZBoKEROytTb6P1SP8=; h=Message-ID:Date:From:To:Subject:References:In-Reply-To:OpenPGP: Content-Type:Content-Transfer-Encoding:CC; b=frbPmkcwr5TKbqe8Da9dsSHNNI8ZGTwCsV2pOlg1pdq9P7heRVqwE/B/HInE7NNdm 0B+DiJQ/cFVgAGME2eRGBBHAx/b/zPBMsltTLULF8YxB5zkOH/9oHjOdR2/Vmt9EvO drKLPERnQa64GpCB3iBHoFxVeRw8J7jf9YE1n1llVZdDXCNZyqbrqgwgv/vgDcd0a3 RPvCXPry6MoOKFxDjDsIjZPYjgEY1Fh3MeRsTbRL0VpPn3kNjVZ/cEq+tl5rMNv94q 8z6754KL1c31zyhnyR5munnH03DxMZKmcs29yJg33VbkCwR4TkH6ly12XUn7tx6ixw URhzjDRQSbdkw== Message-ID: <4E9F237A.4030009@arpawocky.com> Date: Wed, 19 Oct 2011 15:22:34 -0400 From: Joe Sniderman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: asrg@irtf.org References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> <4E9EF8A8.2030404@arpawocky.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC82C@UK-EXCHMBX1.green.sophos> In-Reply-To: <18B53BA2A483AD45962AAD1397BE1325382F2CC82C@UK-EXCHMBX1.green.sophos> X-Enigmail-Version: 1.1.1 OpenPGP: id=605721CA; url=https://www.thoroquel.org/keys/PGP_605721CA.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 19 Oct 2011 19:22:44 -0000 On 10/19/2011 02:42 PM, Martijn Grooten wrote: >>> It is hard to reliably determine how much greylisting helps on a >>> specific system, i.e. what difference it makes compared to the >>> hypothetical situation greylisting wasn't used. May be an idea >>> to include some caution about that. >> >> Log delivery attempts that are greylisted. Log greylisted delivery >> attempts that subsequently pass. Compare the IPs in question >> against whatever DNSBLs are in use to determine if the delivery >> attempts would have been blocked anyway (without resorting to >> computationally expensive content filtering).... >> >> Might also make sense to log the DNSBL result at the time that a >> delivery attempt is greylisted, and then log delivery attempts >> that pass greylisting but are rejecting due to DNSBLs, and thereby >> determine if greylisting is effectively giving a recently gone-bad >> host extra time to get itself listed. > > Yes, that makes sense and, if you're running a test (and don't care > too much about computational performance) could be extended to > content scanning too. Right, and then log whether content filters would have blocked the message anyway, had the sender eventually retried. Glean how many (if any) spams were stopped by greylisting that neither DNSBLs nor content filters would have otherwise caught. > But that assumes you are able to identify messages, which I doubt is > possible to do in a reliable way unless you greylist during/post > DATA. Which -- at least in theory -- does not need to give the same > results as greylisting at an earlier stage. Not necessarily.. Say one sees 1000 IPs that attempted to send 100,000 times, were greylisted, never passed greylisting, and weren't listed on DNSBLs that the system normally checks - that gives one possible piece of data on effectiveness. If one takes it a step further, find all the counted greylistings where the IP attempted to send to at least one spamtrap, and only count those incidents but exclude the actual attempted trap deliveries, one might get a very conservative count of how many attempted spam deliveries to actual user addresses were prevented by greylisting that the DNSBLs in use would not have caught. Since one isnt matching initial greylistings to later successful retries, identifying the message isnt necessary to get useful stats. Regarding the second method, simply logging blacklisted-ip-was-greylisted, and non-blacklisted-ip-was-greylisted, and then matching the second group of IPs (not messages) against later DNSBL-based rejections would give a good indicator as to whether greylisting is helping to mitigate the delay between when a host starts spamming and when a host is blacklisted. > I guess the only way to really test the effectiveness of (your > version of) greylisting (on your mail stream) is if you have a > reasonably large stream and you split that feed in two random groups > and use greylisting one group only. Yeah that would work. If thats not feasible, one could also disable greylisting periodically at random, and see if there is a spike in uncaught spam. > (I suppose most people don't care as much about measuring > effectiveness as I do, nor should they, but including something about > effectiveness may be a good idea as this is the main reason people > use greylisting.) Agreed. May also be a good idea to recommend some measuring techniques in the BCP, since effectiveness might vary based on site-specific factors. -- Joe Sniderman From Jose-Marcio.Martins@mines-paristech.fr Wed Oct 19 12:54:45 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3513921F8AD6 for ; Wed, 19 Oct 2011 12:54:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFiRAERz0WV0 for ; Wed, 19 Oct 2011 12:54:44 -0700 (PDT) Received: from smtp-3.ensmp.fr (smtp-3.ensmp.fr [194.214.158.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBA021F8AD2 for ; Wed, 19 Oct 2011 12:54:44 -0700 (PDT) Received: from localhost.localdomain (joe.j-chkmail.org [88.168.143.55]) (authenticated bits=0) by smtp-3.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id p9JJsfFt019172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 21:54:41 +0200 (MEST) Message-ID: <4E9F2B09.5010607@mines-paristech.fr> Date: Wed, 19 Oct 2011 21:54:49 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc14 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> <4E9EF8A8.2030404@arpawocky.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC82C@UK-EXCHMBX1.green.sophos> In-Reply-To: <18B53BA2A483AD45962AAD1397BE1325382F2CC82C@UK-EXCHMBX1.green.sophos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at cascavel with ID 4E9F2B01.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4E9F2B01.000 from joe.j-chkmail.org/joe.j-chkmail.org/88.168.143.55/localhost.localdomain/ Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2011 19:54:45 -0000 Martijn Grooten wrote: > > Yes, that makes sense and, if you're running a test (and don't care too much about computational performance) could be extended to content scanning too. > > But that assumes you are able to identify messages, which I doubt is possible to do in a reliable way unless you greylist during/post DATA. Which -- at least in theory -- does not need to give the same results as greylisting at an earlier stage. > > I guess the only way to really test the effectiveness of (your version of) greylisting (on your mail stream) is if you have a reasonably large stream and you split that feed in two random groups and use greylisting one group only. > > (I suppose most people don't care as much about measuring effectiveness as I do, nor should they, but including something about effectiveness may be a good idea as this is the main reason people use greylisting.) I think that it's not serious to run any security tool without monitoring it. If you run a tool which may reject messages (or any kind of communication), you should monitor and know how it performs : how many connections it handles, how many connections it rejects, etc, etc, etc... If you do, and observe this numbers each day, you can have some idea about effectiveness. "Fire and forget" is never a good thing in security. An unattended and interesting side effect of greylisting is that it blocks a lot of virus/worms. Josť-Marcio From hjp-asrg@hjp.at Thu Oct 20 00:22:46 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38BF21F84BB for ; Thu, 20 Oct 2011 00:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e49KF3MhO6U9 for ; Thu, 20 Oct 2011 00:22:46 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9C21F84BD for ; Thu, 20 Oct 2011 00:22:45 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id DB91C4042; Thu, 20 Oct 2011 09:22:41 +0200 (CEST) Date: Thu, 20 Oct 2011 09:22:41 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20111020072241.GC21602@hjp.at> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 20 Oct 2011 07:22:46 -0000 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-10-18 15:42:24 -0400, Daniel Feenberg wrote: > On Tue, 18 Oct 2011, Murray S. Kucherawy wrote: >> After some chatter inside MAAWG and on the ietf-smtp mailing list, I=E2= =80=99ve started an >> outline for a BCP on the practice of greylisting.=C2=A0 The main purpose= is to explain >> what it is, discuss the pros and cons of its variants, and give some rec= ommendations >> for implementation and configuration for a few example installations and= policies. >> >> The draft (which is currently only an outline) is here: >> https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp/ >> >> Comments welcome. > > Where should comments go? I have a question really, though it might be = =20 > construed as a comment. Why do greylisters match on the (sender, =20 > receipient, MTA) triple rather on just the MTA? Isn't it nearly certain = =20 > that if an MTA returns for one sender/receipient pair, it will return for= =20 > any pair? Yes, but how do you determine that the MTA returned for one sender/receipient pair? For that you need the whole tripel. Once you have established that the MTA does queue, the IP address is sufficient (this wasn't in Harris' original proposal, but it is a common optimization). Actually, the tripel (ip address, envelope sender, envelope recipient) is just an approximation. What greylisting really tries to establish is whether a particular /message/ is queued. To do that right you would have to compare the whole message, but that would be expensive. So greylisting assumes that if there is a second delivery attempt from the sam= e IP address with the same sender and recipient within a certain time window, then it is a second delivery attempt for the same message, not an independent message. We all know that this assumption isn't always true (and I've occasionally advised users to just send two mails within a few minutes to get through greylisting) but its a reasonable heuristic. There is also an argument for always using the whole tripel: It guards against bots on the same IP address (e.g., an MTA and an infected workstation behind a common NAT, or a reassigned IP address). hp --=20 _ | Peter J. Holzer | Web 2.0 k=C3=B6nnte man also auch =C3=BCberset= zen als |_|_) | Sysadmin WSR | "Netz der kleinen Geister". | | | hjp@hjp.at |=20 __/ | http://www.hjp.at/ | -- Oliver Cromm in desd --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFOn8xBfZ+RkG8quy0RAsovAJ93rbsL0nEEvf8Nf93b+VMS/2YvVQCggbhh +T/SmnTA+aS1I5bMx7PBOpY= =wZ2f -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From hjp-asrg@hjp.at Thu Oct 20 00:43:50 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DBF21F8B1C for ; Thu, 20 Oct 2011 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoNzAfM9g46J for ; Thu, 20 Oct 2011 00:43:49 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA221F8AC3 for ; Thu, 20 Oct 2011 00:43:49 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id 837DA4042; Thu, 20 Oct 2011 09:43:48 +0200 (CEST) Date: Thu, 20 Oct 2011 09:43:48 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20111020074348.GD21602@hjp.at> References: <4E9E07D2.4090304@xplornet.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+KJYzRxRHjYqLGl5" Content-Disposition: inline In-Reply-To: <4E9E07D2.4090304@xplornet.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 20 Oct 2011 07:43:50 -0000 --+KJYzRxRHjYqLGl5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-10-18 19:12:18 -0400, Chris Lewis wrote: > On 11-10-18 03:42 PM, Daniel Feenberg wrote: > > > Where should comments go? I have a question really, though it might be > > construed as a comment. Why do greylisters match on the (sender, > > receipient, MTA) triple rather on just the MTA? Isn't it nearly certain > > that if an MTA returns for one sender/receipient pair, it will return > > for any pair? So that keeping track of all three seems unnecessary and > > increases the probability of a message being delayed. What am I missing? > > As I understand it, some grey-listing systems match on sender/recipient = =20 > pairs (not MTA) so as to not penalize clustered outbounds that share=20 > queues. > > There's all sorts of 'optimizations'/variations that you can apply for = =20 > different behaviours. > > You're right, _just_ the MTA would work just about as well for the main = =20 > use case: bot armies. I don't think so. If the bot sends one spam from to and some time later (within the greylisting windo) another from to the second one would get through if you use only the IP address. To establish that a new MTA is "legitimate" you need to be fairly restrictive. After that you just need to make sure that it's an MTA you already checked and the IP address is (usually) sufficient. > There is a danger in specifying the precise details/tuning values of a = =20 > "standardized gray listing" mechanism. If it's too predictable, you =20 > could probably come up with a simplistic mechanism for defeating it =20 > without requiring the complexity of queuing. "Hybrid vigor" is a good = =20 > thing. ACK. However, for those who have to deal with greylisting (either on the sending or receiving side) it's valuable to know what works well and what doesn't. There's little sense in having everybody going through the same learning curve. So, a BCP should not define the One True Way of greylisting but list variants of greylisting as well as different queueing strategies and discuss their pros and cons. hp --=20 _ | Peter J. Holzer | Web 2.0 k=F6nnte man also auch =FCbersetzen als |_|_) | Sysadmin WSR | "Netz der kleinen Geister". | | | hjp@hjp.at |=20 __/ | http://www.hjp.at/ | -- Oliver Cromm in desd --+KJYzRxRHjYqLGl5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFOn9E0fZ+RkG8quy0RAg3rAJ9+3ZVHL/sFk5tWa3pIZolvqCKcJwCfRcA9 P6fe9/5CDtItLlwkduu8rB0= =UtV8 -----END PGP SIGNATURE----- --+KJYzRxRHjYqLGl5-- From ietfa@btconnect.com Fri Oct 21 09:51:09 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4F1F0C6C for ; Fri, 21 Oct 2011 09:51: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE61xBcXGFUt for ; Fri, 21 Oct 2011 09:51:07 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id E49981F0C67 for ; Fri, 21 Oct 2011 09:51:05 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr09.btconnect.com with SMTP id EXO18245; Fri, 21 Oct 2011 17:46:44 +0100 (BST) Message-ID: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Anti-Spam Research Group - IRTF" References: Date: Fri, 21 Oct 2011 17:41:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4EA1A1F3.0006, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.21.151815:17:7.586, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4EA1A2F7.0123,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 16:51:09 -0000 Well, I would prefer an alternative explanation, for why all my IRTF (and IETF) e-mail now shows 'SPF fail' because it has come to my ISP (British Telecom) from 157.55.224.141, and ARIN WHOIS lists 157.55.224.141 as an address allocated to Microsoft, which is not listed as a permitted sender for irtf.org. Any ideas? Tom Petch Received-SPF: fail (mail9-am1: domain of irtf.org does not designate 157.55.224.141 as permitted sender) client-ip=157.55.224.141; envelope-from=asrg-bounces@irtf.org; helo=DB3PRD0702HT003.eurprd07.prod.outlook.com ;.outlook.com ; Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 (MessageSwitch) id 1318964619898891_21731; Tue, 18 Oct 2011 19:03:39 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.252]) by mail9-am1.bigfish.com (Postfix) with ESMTP id D38CC1150054 for ; Tue, 18 Oct 2011 19:03:39 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 18 Oct 2011 19:03:39 +0000 Received: from mail64-va3-R.bigfish.com (216.32.180.112) by DB3PRD0702HT003.eurprd07.prod.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.1.225.71; Tue, 18 Oct 2011 19:03:38 +0000 Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3-R.bigfish.com (Postfix) with ESMTP id 209C74B8376 for ; Tue, 18 Oct 2011 19:03:37 +0000 (UTC) X-FB-SS: 13, Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3 (MessageSwitch) id 1318964522600467_28976; Tue, 18 Oct 2011 19:02:02 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.249]) by mail64-va3.bigfish.com (Postfix) with ESMTP id 7505A1640051 for ; Tue, 18 Oct 2011 19:02:02 +0000 (UTC) Received: from mail.ietf.org (12.22.58.30) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Oct 2011 19:01:55 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4106021F8B88; Tue, 18 Oct 2011 12:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A551021F8B74 for ; Tue, 18 Oct 2011 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XSv6ncXIa5s for ; Tue, 18 Oct 2011 12:01:34 -0700 (PDT) From scott@doc.net.au Fri Oct 21 10:07:40 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BAE1F0C8A for ; Fri, 21 Oct 2011 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep7zpk7l6Why for ; Fri, 21 Oct 2011 10:07:38 -0700 (PDT) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF41F0C7F for ; Fri, 21 Oct 2011 10:07:38 -0700 (PDT) Received: by qyk35 with SMTP id 35so968365qyk.13 for ; Fri, 21 Oct 2011 10:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.169 with SMTP id b41mr3272589qci.145.1319216855645; Fri, 21 Oct 2011 10:07:35 -0700 (PDT) Received: by 10.229.71.70 with HTTP; Fri, 21 Oct 2011 10:07:35 -0700 (PDT) In-Reply-To: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> Date: Fri, 21 Oct 2011 10:07:35 -0700 Message-ID: From: Scott Howard To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=0016e65da6ee0ffce604afd21cd5 Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 17:07:40 -0000 --0016e65da6ee0ffce604afd21cd5 Content-Type: text/plain; charset=ISO-8859-1 Perhaps because your "ISP" is using Microsoft? $ dig +short mx btconnect.com 1 btconnect-com.mail.eo.outlook.com. outlook.com (aka bigfish.com) is, fairly obviously, Microsoft. Why it's failing SPF is probably something you'll need to take up with BT. Scott. On Fri, Oct 21, 2011 at 8:41 AM, t.petch wrote: > Well, I would prefer an alternative explanation, for why all my IRTF (and > IETF) > e-mail now shows 'SPF fail' because it has come to my ISP (British Telecom) > from > 157.55.224.141, > and ARIN WHOIS lists 157.55.224.141 as an address allocated to Microsoft, > which > is not listed as a permitted sender for irtf.org. > > Any ideas? > > Tom Petch > > > > Received-SPF: fail (mail9-am1: domain of irtf.org does not designate > 157.55.224.141 as permitted sender) client-ip=157.55.224.141; > envelope-from=asrg-bounces@irtf.org; > helo=DB3PRD0702HT003.eurprd07.prod.outlook.com ;.outlook.com ; > Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 > (MessageSwitch) id 1318964619898891_21731; Tue, 18 Oct 2011 19:03:39 +0000 > (UTC) > Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.252]) by > mail9-am1.bigfish.com (Postfix) with ESMTP id D38CC1150054 for > ; Tue, 18 Oct 2011 19:03:39 +0000 (UTC) > Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) > by > AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) > id > 14.1.225.22; Tue, 18 Oct 2011 19:03:39 +0000 > Received: from mail64-va3-R.bigfish.com (216.32.180.112) by > DB3PRD0702HT003.eurprd07.prod.outlook.com (10.3.4.151) with Microsoft > SMTP > Server (TLS) id 14.1.225.71; Tue, 18 Oct 2011 19:03:38 +0000 > Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by > mail64-va3-R.bigfish.com (Postfix) with ESMTP id 209C74B8376 for > ; Tue, 18 Oct 2011 19:03:37 +0000 (UTC) > X-FB-SS: 13, > Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3 > (MessageSwitch) id 1318964522600467_28976; Tue, 18 Oct 2011 19:02:02 +0000 > (UTC) > Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.249]) by > mail64-va3.bigfish.com (Postfix) with ESMTP id 7505A1640051 for > ; Tue, 18 Oct 2011 19:02:02 +0000 (UTC) > Received: from mail.ietf.org (12.22.58.30) by VA3EHSMHS029.bigfish.com > (10.7.99.39) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Oct 2011 > 19:01:55 +0000 > Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com > (Postfix) with ESMTP id 4106021F8B88; Tue, 18 Oct 2011 12:01:36 -0700 > (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; > > X-Original-To: asrg@ietfa.amsl.com > Delivered-To: asrg@ietfa.amsl.com > Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com(Postfix) > with ESMTP id A551021F8B74 for ; Tue, 18 Oct 2011 > 12:01:35 -0700 (PDT) > X-Virus-Scanned: amavisd-new at amsl.com > X-Spam-Flag: NO > X-Spam-Score: -102.712 > X-Spam-Level: > X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 > tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, > USER_IN_WHITELIST=-100] > Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com > [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XSv6ncXIa5s for > ; Tue, 18 Oct 2011 12:01:34 -0700 (PDT) > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > --0016e65da6ee0ffce604afd21cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps because your "ISP" is using Microsoft?

$ dig +shor= t mx btconnect.com
1 btconnect-com.mail.eo.outlook.com.

outlook.com (aka bigfish.com) is, fairly obviously, Microsoft.

Why it= 's failing SPF is probably something you'll need to take up with BT= .

=A0 Scott.



On Fri, Oct 21, 20= 11 at 8:41 AM, t.petch <ietfa@btconnect.com> wrote:
Well, I would prefer an alternative explanation, for why all my IRTF (and I= ETF)
e-mail now shows 'SPF fail' because it has come to my ISP (British = Telecom) from
157.55.224.141, and ARIN WHOIS lists = 157.55.224.141 as an address allocated to Microsoft, which
is not listed as a permitted sender for irtf.org.

Any ideas?

Tom Petch


<snip>
Received-SPF: fail (mail9-am1: domain of irtf.org does not designate
157.55.224.141=A0= as permitted sender) client-ip=3D157.55.224.141;
envelope-from=3Dasrg-bounces@irtf.= org;
helo=3DDB3PRD0702HT003.eurprd07.prod.outlook.com ;.outlook.com ;
Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 =A0(MessageSwitch) id 1318964619898891_21731; Tue, 18 Oct 2011 19:03:39 +00= 00
=A0(UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.252]) by
=A0mail9-am1.big= fish.com (Postfix) with ESMTP id D38CC1150054 for
=A0<ietfa@btconnect.com>; = Tue, 18 Oct 2011 19:03:39 +0000 (UTC)
Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by
=A0AM1EHSMHS0= 11.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id
=A014.1.225.22; Tue, 18 Oct 2011 19:03:39 +0000
Received: from mail64-va3-R.bigfish.com (216.32.180.112) by
=A0DB3PRD0702HT003.eurprd07.prod.outlook.com (10.3.4.151) with Micr= osoft SMTP
=A0Server (TLS) id 14.1.225.71; Tue, 18 Oct 2011 19:03:38 +0000
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by
=A0mail64-va3= -R.bigfish.com (Postfix) with ESMTP id 209C74B8376 for
=A0<ietfa@btconnect.com>; = Tue, 18 Oct 2011 19:03:37 +0000 (UTC)
X-FB-SS: 13,
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3=
=A0(MessageSwitch) id 1318964522600467_28976; Tue, 18 Oct 2011 19:02:02 +00= 00
=A0(UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.249]) by
=A0mail64-va3.b= igfish.com (Postfix) with ESMTP id 7505A1640051 for
=A0<ietfa@btconnect.com>; = Tue, 18 Oct 2011 19:02:02 +0000 (UTC)
Received: from mail.ietf= .org (12.22.58.30) by VA3EHSMHS029.bigfish.com
=A0(10.7.99.39) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Oct 2011=
=A019:01:55 +0000
Received: from ietfa.am= sl.com (localhost [127.0.0.1]) by ietfa.amsl.com
=A0(Postfix) with ESMTP id 4106021F8B88; Tue, 18 Oct 2011 12:01:36 -0700 (P= DT)
DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; s=3Dietf1;
<snip>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To:
asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by
ietfa.amsl.com (Postfix)
=A0with ESMTP id A551021F8B74 for <asrg@ietfa.amsl.com>; Tue, 18 Oct 2011
=A012:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.712
X-Spam-Level:
X-Spam-Status: No, score=3D-102.712 tagged_above=3D-999 required=3D5
=A0tests=3D[AWL=3D-0.114, BAYES_00=3D-2.599, HTML_MESSAGE=3D0.001,
=A0USER_IN_WHITELIST=3D-100]
Received: from mail.ietf= .org ([12.22.58.30]) by localhost (ietfa.amsl.com
=A0[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XSv6ncXIa5s for =A0<asrg@ietfa.amsl.com>; = Tue, 18 Oct 2011 12:01:34 -0700 (PDT)

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

--0016e65da6ee0ffce604afd21cd5-- From steve@blighty.com Fri Oct 21 10:07:43 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD8B1F0C96 for ; Fri, 21 Oct 2011 10:07:43 -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_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DOZ72Yo5JdN for ; Fri, 21 Oct 2011 10:07:42 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id CD54E1F0C95 for ; Fri, 21 Oct 2011 10:07:42 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 7CDE52DDE5 for ; Fri, 21 Oct 2011 10:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1319216861; bh=kdcWdVxNcJml4FKY/ph3XIQ7SGx7xqapTeFQksk64hk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=bwq7BuiPBeWP5vzMXhHlTtHEL9VxkF5pWcEcm9FX90nHr3BvTf4Dnf05YIqi5yghj J+4s7h2+0kemFxT/KsqMp9sgh6A7JmefFuBZ8owNCDvJ9/GUJBh1qINPb41mW0vCdT RUhnkQUZuMiOokLyldiBM+N/ZuXdNgqDVrwR/CRA= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Steve Atkins X-Priority: 3 In-Reply-To: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> Date: Fri, 21 Oct 2011 10:07:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 17:07:43 -0000 On Oct 21, 2011, at 8:41 AM, t.petch wrote: > Well, I would prefer an alternative explanation, for why all my IRTF = (and IETF) > e-mail now shows 'SPF fail' because it has come to my ISP (British = Telecom) from > 157.55.224.141, > and ARIN WHOIS lists 157.55.224.141 as an address allocated to = Microsoft, which > is not listed as a permitted sender for irtf.org. BT have outsourced their email handling (for btconnect.com) to = Microsoft, and SPF is being checked at an inappropriate point in the internal handoff. The bigger issue is that you shouldn't care about SPF failing. An SPF = pass provides somewhat useful data, an SPF fail means absolutely nothing. Cheers, Steve From hanov3r@gmail.com Fri Oct 21 10:19:31 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FF611E80B3 for ; Fri, 21 Oct 2011 10:19: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psB3BP4GmNRA for ; Fri, 21 Oct 2011 10:19:31 -0700 (PDT) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09B11E80AD for ; Fri, 21 Oct 2011 10:19:31 -0700 (PDT) Received: by qyg14 with SMTP id 14so4865638qyg.13 for ; Fri, 21 Oct 2011 10:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r1pSY1fU6ow1nbCOJbjxRTRNKGx8oU7/DiKHph+pPho=; b=DyEfcAEstpmMOx4Zzpb5BWT/cwLjWj51y2hAEykO+/TQa/fyXOMWjhmXT4fcCRew5x 0McKkAkfebTTj5fxEVG9x3pCBl1R2GD6EQTPkxu+eRnvsRA+ZzvjXdZJGyRpdJLBSM7L 3woaIVAm01e1SXh6W9HtgoyzqH8BJEfDIwViE= Received: by 10.68.12.104 with SMTP id x8mr29272712pbb.79.1319217570339; Fri, 21 Oct 2011 10:19:30 -0700 (PDT) Received: from [172.22.21.39] (nyc-vpn.cloudmark.com. [208.83.137.226]) by mx.google.com with ESMTPS id x7sm32176572pbf.5.2011.10.21.10.19.28 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 10:19:28 -0700 (PDT) Message-ID: <4EA1A99E.80007@gmail.com> Date: Fri, 21 Oct 2011 13:19:26 -0400 From: David Romerstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> In-Reply-To: <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 17:19:31 -0000 On 10/21/2011 1:07 PM, Steve Atkins wrote: > The bigger issue is that you shouldn't care about SPF failing. An SPF pass > provides somewhat useful data, an SPF fail means absolutely nothing. That is not ENTIRELY true. Under the proper circumstances, an SPF failure should indicate that NDRs should not be sent to the purported 'Reply-To' or 'Return-Path' addresses. But, yes, in an "is this spam or not" sense, SPF fail means nothing. -- D From steve@blighty.com Fri Oct 21 10:28:45 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F4111E80C3 for ; Fri, 21 Oct 2011 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn-OFm08QGMs for ; Fri, 21 Oct 2011 10:28:45 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1B11E80AD for ; Fri, 21 Oct 2011 10:28:45 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id DB0ED2EAF4 for ; Fri, 21 Oct 2011 10:28:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <4EA1A99E.80007@gmail.com> Date: Fri, 21 Oct 2011 10:28:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <950381CE-65E4-4D54-B997-F9C0B779E73A@blighty.com> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA1A99E.80007@gmail.com> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 17:28:45 -0000 On Oct 21, 2011, at 10:19 AM, David Romerstein wrote: > On 10/21/2011 1:07 PM, Steve Atkins wrote: >> The bigger issue is that you shouldn't care about SPF failing. An SPF = pass >> provides somewhat useful data, an SPF fail means absolutely nothing. >=20 > That is not ENTIRELY true. Under the proper circumstances, an SPF = failure should indicate that NDRs should not be sent to the purported = 'Reply-To' or 'Return-Path' addresses. Yes. But if you remove the negative in that statement you end up with = something like "Under the proper circumstances, an SPF pass should = indicate that NDRs should be sent to the return-path address". :) (Neither says what you should do with an SPF neutral response, but = that's a whole other can of worms). > But, yes, in an "is this spam or not" sense, SPF fail means nothing. Yup. An SPF pass (or a DKIM pass) is a positive assertion - it means = something solid and well defined. An SPF or DKIM failure can be for any = number of unrelated reasons, so it doesn't mean anything in particular. Cheers, Steve From dotis@mail-abuse.org Fri Oct 21 10:47:19 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1C1F0C9B for ; Fri, 21 Oct 2011 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HziTGgeuh1PT for ; Fri, 21 Oct 2011 10:47:17 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id D8AED1F0C9A for ; Fri, 21 Oct 2011 10:47:17 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id DD1486E011F for ; Fri, 21 Oct 2011 17:47:15 +0000 (UTC) Received: from dhcp100.priv.bungi.com (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1C4D7A9443B for ; Fri, 21 Oct 2011 17:47:16 +0000 (UTC) Message-ID: <4EA1B025.4010508@mail-abuse.org> Date: Fri, 21 Oct 2011 10:47:17 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA1A99E.80007@gmail.com> In-Reply-To: <4EA1A99E.80007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 17:47:19 -0000 On 10/21/11 10:19 AM, David Romerstein wrote: > On 10/21/2011 1:07 PM, Steve Atkins wrote: >> The bigger issue is that you shouldn't care about SPF failing. An SPF >> pass >> provides somewhat useful data, an SPF fail means absolutely nothing. > > That is not ENTIRELY true. Under the proper circumstances, an SPF > failure should indicate that NDRs should not be sent to the purported > 'Reply-To' or 'Return-Path' addresses. > > But, yes, in an "is this spam or not" sense, SPF fail means nothing. The same problem may occur when traversing a carrier's LSN. In which case, dropping NDRs and not accepting messages will negatively impact email integrity. With a high level of shared MTAs, an SPF pass or fail should also be considered equally untrustworthy thanks to the efforts by malefactors. There is an ongoing effort to combine SPF and DKIM to establish reputation. DKIM excludes who sent the message and intended recipient. Will that mean DKIM signatures and SPF authorizations must be by same domain? Either scheme may induce an inordinately large number of transactions. Soon only the services of white-listed large providers will be a way out of this morass. -Doug From sethb@panix.com Fri Oct 21 12:20:04 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36F11E8082 for ; Fri, 21 Oct 2011 12:20:04 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi6IQhmAqJdg for ; Fri, 21 Oct 2011 12:20:03 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5511E8073 for ; Fri, 21 Oct 2011 12:20:03 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mailbackend.panix.com (Postfix) with ESMTP id E366928B56 for ; Fri, 21 Oct 2011 15:20:02 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 756) id D6AF92425C; Fri, 21 Oct 2011 15:20:02 -0400 (EDT) From: Seth To: Anti-Spam Research Group - IRTF In-reply-to: <950381CE-65E4-4D54-B997-F9C0B779E73A@blighty.com> (message from Steve Atkins on Fri, 21 Oct 2011 10:28:43 -0700) References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA1A99E.80007@gmail.com> <950381CE-65E4-4D54-B997-F9C0B779E73A@blighty.com> Message-Id: <20111021192002.D6AF92425C@panix5.panix.com> Date: Fri, 21 Oct 2011 15:20:02 -0400 (EDT) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 21 Oct 2011 19:20:04 -0000 Steve Atkins wrote: > But if you remove the negative in that statement you end up with > something like "Under the proper circumstances, an SPF pass should > indicate that NDRs should be sent to the return-path address". :) Rather, you end up with "Under the proper circumstances, and SPF pass would indicate that NDRs *may* be sent to the return-path address." Seth From ietfa@btconnect.com Sat Oct 22 04:30:39 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AFD21F8AF8 for ; Sat, 22 Oct 2011 04:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQRCknVQhQYY for ; Sat, 22 Oct 2011 04:30:37 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8921721F8AF5 for ; Sat, 22 Oct 2011 04:30:35 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr10.btconnect.com with SMTP id EXG22139; Sat, 22 Oct 2011 12:30:34 +0100 (BST) Message-ID: <00e501cc90a4$f1d7f4c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Anti-Spam Research Group - IRTF" References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> Date: Sat, 22 Oct 2011 12:25:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EA2A95A.0043, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.10.22.103615:17:9.535, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1400_1499, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EA2A95A.00EB,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 22 Oct 2011 11:30:39 -0000 Many thanks to all who responded to my query. I thought I could see what was happening but did not want to believe it - I would have expected to have heard something about this (which started over three weeks ago) in the general or specialist press, or even direct from my ISP - but .... Tom Petch ----- Original Message ----- From: "Steve Atkins" To: "Anti-Spam Research Group - IRTF" Sent: Friday, October 21, 2011 7:07 PM Subject: Re: [Asrg] Microsoft takes over British Telecom > > On Oct 21, 2011, at 8:41 AM, t.petch wrote: > > > Well, I would prefer an alternative explanation, for why all my IRTF (and IETF) > > e-mail now shows 'SPF fail' because it has come to my ISP (British Telecom) from > > 157.55.224.141, > > and ARIN WHOIS lists 157.55.224.141 as an address allocated to Microsoft, which > > is not listed as a permitted sender for irtf.org. > > BT have outsourced their email handling (for btconnect.com) to Microsoft, and > SPF is being checked at an inappropriate point in the internal handoff. > > The bigger issue is that you shouldn't care about SPF failing. An SPF pass > provides somewhat useful data, an SPF fail means absolutely nothing. > > Cheers, > Steve > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > > From vesely@tana.it Sun Oct 23 07:39:13 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4A621F8AA9 for ; Sun, 23 Oct 2011 07:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LP4i1yhPyYQ for ; Sun, 23 Oct 2011 07:39:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F721F8A97 for ; Sun, 23 Oct 2011 07:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319380752; bh=/60cWFysLWx29aljjWAaajk6h/KWBR+JILPPLxPKWAM=; l=331; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=J6y1MpKMlXiVOvhJ0O7WkyOCzlMxY1LKo7EZpI/SLr1f05bHE+O7FlhNYMGZIAZH9 FLgZDq4fPn8xXIdS49omGDGjgJPm4Yt2p4fnj5Y2vTre8tv4DXI135Ft3tI1791zbw dmooH0IeeNatBQdM2XW534Ct5YLVR2RUDUV3z04I= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 23 Oct 2011 16:39:11 +0200 id 00000000005DC03F.000000004EA4270F.000055C0 Message-ID: <4EA4270F.7000304@tana.it> Date: Sun, 23 Oct 2011 16:39:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> In-Reply-To: <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 23 Oct 2011 14:39:14 -0000 On 21/Oct/11 19:07, Steve Atkins wrote: > > The bigger issue is that you shouldn't care about SPF failing. An SPF pass > provides somewhat useful data, an SPF fail means absolutely nothing. Wasn't it supposed to mean "reject"? IIRC, that was the difference between setting -all (as irtf.org does) rather than ~all or ?all. From steve@blighty.com Sun Oct 23 09:09:30 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316CF21F8A80 for ; Sun, 23 Oct 2011 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov0dGWx6VkQx for ; Sun, 23 Oct 2011 09:09:29 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CF21F8A6C for ; Sun, 23 Oct 2011 09:09:29 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 774872E185 for ; Sun, 23 Oct 2011 09:09:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <4EA4270F.7000304@tana.it> Date: Sun, 23 Oct 2011 09:09:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 23 Oct 2011 16:09:30 -0000 On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote: > On 21/Oct/11 19:07, Steve Atkins wrote: >> >> The bigger issue is that you shouldn't care about SPF failing. An SPF pass >> provides somewhat useful data, an SPF fail means absolutely nothing. > > Wasn't it supposed to mean "reject"? IIRC, that was the difference > between setting -all (as irtf.org does) rather than ~all or ?all. That's what it's proponents used to claim, yes. But it's unfixably broken for that purpose. The only reason you don't see serious mail problems for anyone unwise enough to use -all is that almost nobody pays much attention to SPF for rejecting email. Cheers, Steve From prvs=0277E94BF7=paul@pscs.co.uk Sun Oct 23 14:20:08 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4674521F8B00 for ; Sun, 23 Oct 2011 14:20: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k08ciOYW3qVb for ; Sun, 23 Oct 2011 14:20:07 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id E579521F8AF0 for ; Sun, 23 Oct 2011 14:20:05 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Sun, 23 Oct 2011 22:19:59 +0100 Received: from [192.168.57.207] ([192.168.57.207]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Sun, 23 Oct 2011 22:16:57 +0100 Message-ID: <4EA48445.4080001@pscs.co.uk> Date: Sun, 23 Oct 2011 22:16:53 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> In-Reply-To: <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Cc: Steve Atkins Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 23 Oct 2011 21:20:08 -0000 On 23/10/2011 17:09, Steve Atkins wrote: > On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote: > >> On 21/Oct/11 19:07, Steve Atkins wrote: >>> The bigger issue is that you shouldn't care about SPF failing. An SPF pass >>> provides somewhat useful data, an SPF fail means absolutely nothing. >> Wasn't it supposed to mean "reject"? IIRC, that was the difference >> between setting -all (as irtf.org does) rather than ~all or ?all. > That's what it's proponents used to claim, yes. But it's unfixably broken for > that purpose. The only reason you don't see serious mail problems for > anyone unwise enough to use -all is that almost nobody pays much attention > to SPF for rejecting email. > How is it 'unfixably' broken? Just interested. it seems to me that the only reason it's 'unfixably broken' is that people are using it without really understanding what it's doing. If all MTAs rejected all mail that failed SPF checks, then they'd soon get the problems fixed. Remote users having to relay via a specified submission server is a trivial problem to fix (AFAICS), and incorrectly specified SPF records (as in the BT/MS case) deserve to cause messages to be blocked (IMHO) (SPF is certainly not that useful as an 'anti-spam' mechanism, but it seems to have the potential to work reasonably well as an anti-spoofing mechanism, which makes it considerably harder for many spammers) From steve@blighty.com Sun Oct 23 14:43:03 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BA421F8AFB for ; Sun, 23 Oct 2011 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuZW+4pkCHgP for ; Sun, 23 Oct 2011 14:43:02 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4021F888A for ; Sun, 23 Oct 2011 14:43:02 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id C75EA2DDE4 for ; Sun, 23 Oct 2011 14:43:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <4EA48445.4080001@pscs.co.uk> Date: Sun, 23 Oct 2011 14:43:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 23 Oct 2011 21:43:03 -0000 On Oct 23, 2011, at 2:16 PM, Paul Smith wrote: > On 23/10/2011 17:09, Steve Atkins wrote: >> On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote: >>=20 >>> On 21/Oct/11 19:07, Steve Atkins wrote: >>>> The bigger issue is that you shouldn't care about SPF failing. An = SPF pass >>>> provides somewhat useful data, an SPF fail means absolutely = nothing. >>> Wasn't it supposed to mean "reject"? IIRC, that was the difference >>> between setting -all (as irtf.org does) rather than ~all or ?all. >> That's what it's proponents used to claim, yes. But it's unfixably = broken for >> that purpose. The only reason you don't see serious mail problems for >> anyone unwise enough to use -all is that almost nobody pays much = attention >> to SPF for rejecting email. >>=20 > How is it 'unfixably' broken? Just interested. >=20 > it seems to me that the only reason it's 'unfixably broken' is that = people are using it without really understanding what it's doing. If all = MTAs rejected all mail that failed SPF checks, then they'd soon get the = problems fixed. Remote users having to relay via a specified submission = server is a trivial problem to fix (AFAICS), and incorrectly specified = SPF records (as in the BT/MS case) deserve to cause messages to be = blocked (IMHO) >=20 > (SPF is certainly not that useful as an 'anti-spam' mechanism, but it = seems to have the potential to work reasonably well as an anti-spoofing = mechanism, which makes it considerably harder for many spammers) Mail forwarding is one common cause of failure. If you're sending mail = to someone at @ieee.org and they forward it on to their @aol.com = account, and you and AOL decide between you to enforce SPF -all then = that mail will be undeliverable - and there's no way either you or AOL = can predict that. Mailing lists is another similar cause of SPF failures.. A third, which is a lot more common and complex to resolve than you'd = expect, is organizations simply not knowing or not controlling where = their mail is sent from. There've been cases both for SPF and ADSP ("SPF = for DKIM") where one group within a company put out a restrictive policy = based on their beliefs of where mail was sent from, and it all fell to = pieces when employees got kicked off mailing lists when mail appearing = to come from them was delivered from the mailing list manager and = rejected due to auth failure, or where internal monitoring email sent = from servers (cron, even) was silently discarded. Combine that with SPF being pretty much ineffective for "anti-phishing" = (which is what people actually mean when they say "anti-spoofing" or = "brand protection") and you end up with it being not very useful as a = negative assertion.=20 It's interesting to compare SPF with DKIM and ADSP. In many ways = DKIM+ADSP is the domain-based version of SPF. DKIM is the positive = assertion half ("If this mail is DKIM signed / passes SPF then you know = that you can trust that the sender is who they claim to be") while ADSP = is the negative assertion half ("If this mail is not DKIM signed or = fails SPF then you should reject / discard the mail").=20 The positive assertion is always valuable: it's difficult for "bad" mail = - where by "bad" I mean mail that appears to have been sent someone you = trust, but it isn't really from them - to "pass" SPF or DKIM. The = negative assertion much less so as it's pretty common for "good" mail to = fail SPF or ADSP. (I did some back of the envelope testing of ADSP as an anti-phishing / = anti=3Dspoofing measure, and based on my inbox it was worse than = flipping a coin for each email, based on both false positives and false = negatives). Cheers, Steve= From prvs=02786662B8=paul@pscs.co.uk Sun Oct 23 17:22:18 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FCF21F8B3F for ; Sun, 23 Oct 2011 17:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDRpkwuPhbE2 for ; Sun, 23 Oct 2011 17:22:18 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0501121F8B3B for ; Sun, 23 Oct 2011 17:22:13 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Mon, 24 Oct 2011 01:19:59 +0100 Received: from [192.168.57.207] ([192.168.57.207]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Mon, 24 Oct 2011 01:19:28 +0100 Message-ID: <4EA4AF0D.2000000@pscs.co.uk> Date: Mon, 24 Oct 2011 01:19:25 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> In-Reply-To: <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Cc: Steve Atkins Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 00:22:19 -0000 On 23/10/2011 22:43, Steve Atkins wrote: > On Oct 23, 2011, at 2:16 PM, Paul Smith wrote: > >> On 23/10/2011 17:09, Steve Atkins wrote: >>> On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote: >>> >>>> On 21/Oct/11 19:07, Steve Atkins wrote: >>>>> The bigger issue is that you shouldn't care about SPF failing. An SPF pass >>>>> provides somewhat useful data, an SPF fail means absolutely nothing. >>>> Wasn't it supposed to mean "reject"? IIRC, that was the difference >>>> between setting -all (as irtf.org does) rather than ~all or ?all. >>> That's what it's proponents used to claim, yes. But it's unfixably broken for >>> that purpose. The only reason you don't see serious mail problems for >>> anyone unwise enough to use -all is that almost nobody pays much attention >>> to SPF for rejecting email. >>> >> How is it 'unfixably' broken? Just interested. >> >> it seems to me that the only reason it's 'unfixably broken' is that people are using it without really understanding what it's doing. If all MTAs rejected all mail that failed SPF checks, then they'd soon get the problems fixed. Remote users having to relay via a specified submission server is a trivial problem to fix (AFAICS), and incorrectly specified SPF records (as in the BT/MS case) deserve to cause messages to be blocked (IMHO) >> >> (SPF is certainly not that useful as an 'anti-spam' mechanism, but it seems to have the potential to work reasonably well as an anti-spoofing mechanism, which makes it considerably harder for many spammers) > Mail forwarding is one common cause of failure. If you're sending mail to someone at @ieee.org and they forward it on to their @aol.com account, and you and AOL decide between you to enforce SPF -all then that mail will be undeliverable - and there's no way either you or AOL can predict that. I thought most people did return-path rewriting for this case. If you don't do that, then you get undesirable behaviour anyway - eg if the AOL mailbox is full, you get a bounce message from AOL, even though you didn't send any messages to AOL at all. > Mailing lists is another similar cause of SPF failures.. Similarly, I thought return-path rewriting was standard for mailing lists. Especially ones which do VERP, but usually even in ones which don't - eg the return path on the message I received from you was "", not your blighty.com address. Therefore, it correctly passed an SPF test for irtf.org. > A third, which is a lot more common and complex to resolve than you'd expect, is organizations simply not knowing or not controlling where their mail is sent from. There've been cases both for SPF and ADSP ("SPF for DKIM") where one group within a company put out a restrictive policy based on their beliefs of where mail was sent from, and it all fell to pieces when employees got kicked off mailing lists when mail appearing to come from them was delivered from the mailing list manager and rejected due to auth failure, or where internal monitoring email sent from servers (cron, even) was silently discarded. This is the problem of people who should know better not understanding what's going on. If the company had a policy that all mail from their domain had to go through certain servers, and employees were sending mail through other servers, then they deserved to get kicked off mailing lists... Just as they would deserve punishment for watching porn over the work Internet connection, etc. If they had a policy that mail had to go through certain servers, and configured SPF for different servers, then they shouldn't be managing mail systems. If 'SPF' and/or DKIM was standardised and rigourously enforced, then return-path rewriting would be de rigeuer as would people learning how to configure the mechanisms properly. The problem is that for years email was virtually unregulated (open relays were commonplace 15 years ago) which is why it is now so widely abused. The only chance of cutting back abuse is to tighten things up. Saying that attempts to tighten it up are "fatally flawed" just because people can't be bothered to do things properly is dooming the whole system to failure. Extra authentication and authorisation is necessary in email. However these are done (SPF, DKIM, a 'web of trust', trusted authority, or whatever) will need more rigourous configuration and management than there has been in the past. If we can't accept a requirement for more rigourous configuration and management, we may as well all give up now. I would say that giving a 5yz error in response to an SPF failure would be a good thing to do (silently discarding would not be). Accepting an SPF failed message just means that any bad configuration/behaviour goes "unpunished" and defeats the whole objective of having the SPF protection in the first place. In most cases, the sender should prefer to know that there's a problem with their SPF/DKIM configuration (so they can fix it), rather than it to be silently ignored all the time. IME, people set up SPF because they don't want their email addresses to be spoofed, not just as a fun way to spend half an hour. > (I did some back of the envelope testing of ADSP as an anti-phishing / anti=spoofing measure, and based on my inbox it was worse than flipping a coin for each email, based on both false positives and false negatives). > Is that just because it's poorly configured in many places? If so, then rejecting any failed messages will surely, over time, increase the effectiveness as people fix their configurations. Accepting them anyway will just keep the bad configurations in place. (i.e. 'Tough love') Big mail providers are happy rejecting mail for any and all spurious reasons, why can't others be willing to reject mail for badly configured senders? From steve@blighty.com Sun Oct 23 18:37:08 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CDA21F8672 for ; Sun, 23 Oct 2011 18:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh1+AeGpajO3 for ; Sun, 23 Oct 2011 18:37:08 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45621F852E for ; Sun, 23 Oct 2011 18:37:08 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 89A5F2E185 for ; Sun, 23 Oct 2011 18:37:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <4EA4AF0D.2000000@pscs.co.uk> Date: Sun, 23 Oct 2011 18:37:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 01:37:08 -0000 On Oct 23, 2011, at 5:19 PM, Paul Smith wrote: > On 23/10/2011 22:43, Steve Atkins wrote: >=20 >> (I did some back of the envelope testing of ADSP as an anti-phishing = / anti=3Dspoofing measure, and based on my inbox it was worse than = flipping a coin for each email, based on both false positives and false = negatives). >>=20 > Is that just because it's poorly configured in many places? If so, = then rejecting any failed messages will surely, over time, increase the = effectiveness as people fix their configurations. Accepting them anyway = will just keep the bad configurations in place. (i.e. 'Tough love') That was based on modeled "perfect" ADSP-compliant behaviour by the = recipient, and actual observed behaviour by paypal and phishers going = after their brands. Paypal are the main folks backing ADSP, so if they = can't get it right, nobody can.=20 The change I saw them make in response to these problems was to have = their employees use a domain other than paypal.com for paypal corporate = email. That improved the false positives (in much the same way sending = your email via Hotmail will prevent false positives based on your = domains misconfiguration, which isn't really fixing the problem). It had = no effect on the false negatives. > Big mail providers are happy rejecting mail for any and all spurious = reasons, why can't others be willing to reject mail for badly configured = senders? That's an entirely different issue - they, like all responsible email = providers, want to deliver email their users want. Cheers, Steve From lars.eggert@nokia.com Sun Oct 23 23:33:41 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF821F8610; Sun, 23 Oct 2011 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWW-LUh4SfhI; Sun, 23 Oct 2011 23:33:40 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7755721F85AE; Sun, 23 Oct 2011 23:33:40 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9O6WVah013993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 09:32:33 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.2 at fit.nokia.com Content-Type: multipart/signed; boundary="Apple-Mail=_4E501AC0-9CC4-4F83-BF1D-055F5A9BA945"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 24 Oct 2011 09:32:28 +0300 Message-Id: <1CEB8898-9246-49EE-A815-88E3A2A0A703@nokia.com> To: RFC Editor Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Mon, 24 Oct 2011 09:32:29 +0300 (EEST) X-Nokia-AV: Clean Cc: "John R. Levine" , asrg@irtf.org, Internet Research Steering Group Subject: [Asrg] Request to publish draft-irtf-asrg-bcp-blacklists-10 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 06:33:41 -0000 --Apple-Mail=_4E501AC0-9CC4-4F83-BF1D-055F5A9BA945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, RFC Editor, please publish draft-irtf-asrg-bcp-blacklists-10 as an Informational = IRTF RFC. The document has been approved for publication by the IRSG and also = received RFC5742 review by the IESG. See http://trac.tools.ietf.org/group/irtf/trac/ticket/47 for details and = history. Specifically, see this comment for edits to the document that = you should perform: = http://wiki.tools.ietf.org/group/irtf/trac/ticket/47#comment:7 Please copy all correspondence to the document shepherd, John Levine = (johnl@iecc.com). Thanks, Lars= --Apple-Mail=_4E501AC0-9CC4-4F83-BF1D-055F5A9BA945 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEFN3YRH35M0FMeg36jxbcOIwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTMwMDAwMDBaFw0x MjEwMTIyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XBgP3mTed9BOw4AGDgVaaop cmXqyewt4NAj5j0upYg6EzEAlkUTt6ZHE8AxCQeXt6q9/4ZjnuJeKuifA4bgXEfgUwOmMFayCH6J ecSpkfbo0YMw0ivNBXBhdEKuwSRyaZ1sCEoWE6Nu9pksuHoPkP0BQJMylK7NoJAYG9DY1pXHr4DS F3BIpKVBsKLMrX2ls0GJCpb1Ull0mugJyH6XZ8eWIU/t9JVHtmCEFj7QS+/7eJDp9DrZ/s8+m35p YLYIi/Gwj8zOU/xtjxp9NzblzJDImXpsIxQIy/oM/bXDqqS/McBUw+V3F55PcxRnw2N0HpJaqq/o tBLAwjt6GnZAiQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQB2nb6FbBdGaVQ8srzOqr9gahXwkBl2+RMEaH/T3OS1o6Gf40Qi 1EvcW3tSBzefop/S4QfEbjLIidFWUdgSSBTQFV8LnbNFUnLLcc/6Wpn+1UdHlhbW3pC8rCuOPcGD QVCzCk9aMHDwUC6hq1KchGjpSd+K7X1gBwe3RfAWN2MafQBYq12rsV4YSe//9ye41/yvgMk3RQBW 3hUE3eIjKcg2+HZQQmSWSeaYd2YLfT6CDWd8r+ceMD925P3Ak/6ZvTpw06l8a3UgByiTJ5ID45dm eVfJkI2LLzlYdSe6PwqhgrArmtJxgs8g+X3WO9YexpnFYi+43kPXgid2GmjEXeKXMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBTd2ER9+TNBTHoN+o8W3DiMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAyNDA2MzIyOVowIwYJKoZIhvcNAQkE MRYEFE4WxGFknjIn0JRaXPOFCe/wYegGMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFN3YRH35M0FMeg36jxb cOIwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBTd2ER9+TNBTHoN+o8W3DiMA0GCSqGSIb3DQEBAQUABIIB AByQ8yEPSWEf2dKnPIPfScxJceGbir65mNwRtmMUGCMdDB59uDKJ8jZFU1JFPZ0mQF9u5aUwJExb kJxAxyUq8ni7Ye5YGAjgFQYFdFJWtrUrf6qpCFBMWMM2x3Xk8u09gV6uOROPdaX7sijLa0YYgqgp PhiQ6cwbUtovC6qJKTnvZdu354WvvE+CBcU0anZ5NVnq5Tx1SXu2Ko+d+OCV2l4W2c0IS9ztWs7E KTRqUBKjMuGGzClSNJhbwHc/kz17rMMzIBgFDMPmb9SHeWwO9lOfoHRg58I6tlsm7Ap0W+XTQHA5 L+pSdeOqd1/ox6h79gWt4IlTWFJ0k602OwS7AtMAAAAAAAA= --Apple-Mail=_4E501AC0-9CC4-4F83-BF1D-055F5A9BA945-- From msk@cloudmark.com Mon Oct 24 01:33:53 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959EB21F8BBD for ; Mon, 24 Oct 2011 01:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcihSdqbbA2W for ; Mon, 24 Oct 2011 01:33:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3378D21F8BB2 for ; Mon, 24 Oct 2011 01:33:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 24 Oct 2011 01:33:52 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 01:33:52 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyN62+fn9EIf2M+Sjih8QAdT3h6RwEDlZfA Message-ID: References: <4E9E07D2.4090304@xplornet.com> In-Reply-To: <4E9E07D2.4090304@xplornet.com> 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 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 08:33:53 -0000 > -----Original Message----- > From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of C= hris Lewis > Sent: Tuesday, October 18, 2011 4:12 PM > To: asrg@irtf.org > Subject: Re: [Asrg] Greylisting BCP >=20 > There is a danger in specifying the precise details/tuning values of a > "standardized gray listing" mechanism. If it's too predictable, you > could probably come up with a simplistic mechanism for defeating it > without requiring the complexity of queuing. "Hybrid vigor" is a good > thing. Just to be clear, the intent of the BCP isn't to standardize greylisting, b= ut rather to write down what it is in general, what the variants are, their= respective advantages and disadvantages, and then recommend best practices= for a few common environments. Also valid for discussion would be why som= e sites think it's a bad idea overall. From msk@cloudmark.com Mon Oct 24 01:33:54 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC6221F8BB8 for ; Mon, 24 Oct 2011 01:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONCMJ0PyFG+w for ; Mon, 24 Oct 2011 01:33:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2CED221F8BB2 for ; Mon, 24 Oct 2011 01:33:54 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 24 Oct 2011 01:33:53 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 01:33:53 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyN62oE1zfLNTw3TH29RcgMISZ73QAgwuSwAOLki/A= Message-ID: References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> In-Reply-To: <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> 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 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 08:33:54 -0000 > -----Original Message----- > From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of M= artijn Grooten > Sent: Wednesday, October 19, 2011 8:06 AM > To: Anti-Spam Research Group - IRTF > Subject: Re: [Asrg] Greylisting BCP >=20 > Do people apply greylisting post-DATA in practise? Or is this really > only something only performed in labs as it is the only way to > determine whether causes false positives. I plan to do a survey of popular implementations. If none do, that section= can be dropped. But someone suggested including it in the outline which l= eads me to believe that some implementation does. > It is hard to reliably determine how much greylisting helps on a > specific system, i.e. what difference it makes compared to the > hypothetical situation greylisting wasn't used. May be an idea to > include some caution about that. Presumably a site using it turns it on because it perceives it has a proble= m, and notices a positive difference (or they'd turn it off). It's subject= ive though, which can make it hard to measure. So sure, a note about this = might be reasonable. > "greylisting is more expensive than not greylisting" >=20 > Can you explain this? Put simply, any new filter has a cost to install, maintain, and operate. F= or greylisting there has to be a local store of sources that you've seen th= at get to bypass greylisting, so anything not on that list gets caught. Th= at takes space, I/O, and processing time. So "expensive" in the resources = sense. > "special actions to take if the same message is retried before the time > limit expires" >=20 > I assume by "message" you mean the (sender, recipient, MTA) triplet? This might get back to the DATA thing above. I guess some greylisting take= s into account whether or not a specific message is retried, not just the s= ource. It depends on whether or not I can find one that actually does this= . -MSK From msk@cloudmark.com Mon Oct 24 01:33:56 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4024021F8C1E for ; Mon, 24 Oct 2011 01:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+otyeTdW91G for ; Mon, 24 Oct 2011 01:33:55 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id D6C3021F8C1B for ; Mon, 24 Oct 2011 01:33:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 24 Oct 2011 01:33:55 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 01:33:55 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyOELITE9CYLc2wSmGvPIgxfYpKIQD6en1A Message-ID: References: <4E9E4661.30205@mail-abuse.org> In-Reply-To: <4E9E4661.30205@mail-abuse.org> 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 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 08:33:56 -0000 > -----Original Message----- > From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of D= ouglas Otis > Sent: Tuesday, October 18, 2011 8:39 PM > To: asrg@irtf.org > Subject: Re: [Asrg] Greylisting BCP >=20 > Grey listing challenges stateful processing of the sender to test an > often erroneous assumption that bots sending spam don't maintain state. > Thanks to grey listing, many bots retry against the same recipients, > just not always with the same message. That doesn't sound like a "retry" to me, in the MTA queueing sense. For yo= ur claim to be true, it would mean bots institute MTA-style queue-and-retry= systems, but that substantially increases the footprint on the infected ma= chine. It's been my impression that their reluctance to do this is precise= ly why greylisting is perceived to be effective. From msk@cloudmark.com Mon Oct 24 01:33:58 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD421F8C1F for ; Mon, 24 Oct 2011 01:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gSh74TOIpdW for ; Mon, 24 Oct 2011 01:33:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E705621F8B1E for ; Mon, 24 Oct 2011 01:33:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 24 Oct 2011 01:33:57 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 01:33:56 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyO+SG6Tp6+XNvySq2Lj1jjZVwEAQDAjfSg Message-ID: References: <20111020072241.GC21602@hjp.at> In-Reply-To: <20111020072241.GC21602@hjp.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 08:33:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhc3JnLWJvdW5jZXNAaXJ0Zi5v cmcgW21haWx0bzphc3JnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBKLiBI b2x6ZXINCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjAsIDIwMTEgMTI6MjMgQU0NCj4gVG86 IGFzcmdAaXJ0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBc3JnXSBHcmV5bGlzdGluZyBCQ1ANCj4g DQo+IFllcywgYnV0IGhvdyBkbyB5b3UgZGV0ZXJtaW5lIHRoYXQgdGhlIE1UQSByZXR1cm5lZCBm b3Igb25lDQo+IHNlbmRlci9yZWNlaXBpZW50IHBhaXI/IEZvciB0aGF0IHlvdSBuZWVkIHRoZSB3 aG9sZSB0cmlwZWwuIE9uY2UgeW91DQo+IGhhdmUgZXN0YWJsaXNoZWQgdGhhdCB0aGUgTVRBIGRv ZXMgcXVldWUsIHRoZSBJUCBhZGRyZXNzIGlzIHN1ZmZpY2llbnQNCj4gKHRoaXMgd2Fzbid0IGlu IEhhcnJpcycgb3JpZ2luYWwgcHJvcG9zYWwsIGJ1dCBpdCBpcyBhIGNvbW1vbg0KPiBvcHRpbWl6 YXRpb24pLg0KDQpUaGUgY3VycmVudCBvdXRsaW5lIHdpbGwgbG9vayBhdCB2YXJpb3VzIHR1cGxl cyBvZiBkYXRhIGlkZW50aWZ5aW5nIHRoZSB0cmFuc2FjdGlvbi4gIFRoaXMgbWlnaHQgaW5jbHVk ZSB7SVAsIHNlbmRlciwgcmVjaXBpZW50fSwgb3IgYW55IHN1YnNldCBvZiB0aG9zZS4NCg0K From vesely@tana.it Mon Oct 24 02:40:36 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA721F8CBC for ; Mon, 24 Oct 2011 02:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql-c9LV3xPUJ for ; Mon, 24 Oct 2011 02:40:32 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CF45421F8B79 for ; Mon, 24 Oct 2011 02:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319449229; bh=QOZg/5q7zRFXTeuX6BOgwRLegs3MIgO938NX8Xi8INc=; l=2755; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Dc9NiQBS4Tb1fzKXF7CR+COqZxbsxXRRNcX8VId8lK3DjcYp7wXPKX3KNXdNPa7FX bfHZ8hZBNs7Bbg1y1J0MRTMJucFmFnDeabC2KJUKDit8OzjzDgBAa5C0d7pgiqT1QF 2bNppB0BoZDRHuq676g3Cj8A6t1meK+3y+35QR1s= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 24 Oct 2011 11:40:29 +0200 id 00000000005DC039.000000004EA5328D.000010F9 Message-ID: <4EA5328D.8060100@tana.it> Date: Mon, 24 Oct 2011 11:40:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> In-Reply-To: <4EA4AF0D.2000000@pscs.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 09:40:36 -0000 On 24/Oct/11 02:19, Paul Smith wrote: > On 23/10/2011 22:43, Steve Atkins wrote: > >> A third, which is a lot more common and complex to resolve than >> you'd expect, is organizations simply not knowing or not >> controlling where their mail is sent from. Forcing users to submit via official domain servers is one of the points SPF is good at. >> There've been cases both for SPF and ADSP ("SPF for DKIM") where >> one group within a company put out a restrictive policy based on >> their beliefs of where mail was sent from, and it all fell to >> pieces when employees got kicked off mailing lists when mail >> appearing to come from them was delivered from the mailing list >> manager and rejected due to auth failure, or where internal >> monitoring email sent from servers (cron, even) was silently >> discarded. > > This is the problem of people who should know better not > understanding what's going on. Yes, if I've understood the OP's complaint correctly, someone should have removed an SPF check altogether rather than leaving it in a check-but-don't-enforce hybrid status. > If the company had a policy that all mail from their domain had to > go through certain servers, and employees were sending mail through > other servers, then they deserved to get kicked off mailing > lists... Just as they would deserve punishment for watching porn > over the work Internet connection, etc. For the record, you get kicked off a mailing list when you reject mailing list messages. This can happen when you enforce ADSP and thus reject messages with broken author domain's signatures. That is, the duly compliant receiver gets punished in that case. ADSP is more broken than SPF, with respect to forwarding. SPF always claimed to be valid for first hops only, and predicated to change the envelope sender for further hops. DKIM initially seemed to overcome that limitation, but RFC 6377 finally clarified it cannot cope with forwarding either (and nobody wants to change the value of From:). > The problem is that for years email was virtually unregulated (open > relays were commonplace 15 years ago) which is why it is now so widely > abused. The only chance of cutting back abuse is to tighten things up. > Saying that attempts to tighten it up are "fatally flawed" just > because people can't be bothered to do things properly is dooming the > whole system to failure. Very much agreed. With two policies out of two that choke on forwarding, I'd suspect the culprit is the latter. Indeed, forwarding implies that target addresses are being kept on a server. Hence, such server must have some sort of authorization for using them. Why don't we check that? http://fixforwarding.org/ From msk@cloudmark.com Mon Oct 24 07:16:28 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DD721F8DD6 for ; Mon, 24 Oct 2011 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZBGG1UgnY0r for ; Mon, 24 Oct 2011 07:16:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 056F321F8DD1 for ; Mon, 24 Oct 2011 07:16:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 24 Oct 2011 07:16:27 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 07:16:25 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyOR3PevbNQmnkjQkygcmvI2VRA3gED1Vqw Message-ID: References: <4E9E07D2.4090304@xplornet.com> <4E9EA250.7070403@mines-paristech.fr> In-Reply-To: <4E9EA250.7070403@mines-paristech.fr> 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 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 14:16:29 -0000 > -----Original Message----- > From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of J= ose-Marcio Martins da Cruz > Sent: Wednesday, October 19, 2011 3:11 AM > To: Anti-Spam Research Group - IRTF > Cc: Chris Lewis > Subject: Re: [Asrg] Greylisting BCP >=20 > Greylisting is there and it will exist for some time. There are good and = bad > variations/optimisations, good and bad software configurations... This BC= P should not generalize > saying that all greylisting is bad, even if some people are tempted to > say so. The point is not to make a general good/bad statement about greylisting. T= he better approach, in my opinion, is to lay out the pros and cons and let = the reader decide if it's right for his/her installation. > It seems to me that this BCP mention only problems caused by the > filters. That's not the intent. It will also point out the benefits. > What's still lacking in the BCP proposal is a section about the > behaviour of senders MTAs, which, > IMHO, causes a lot of problems too. Good point. > Some examples of bad things which really causes problems to > greylistings : > [...] Thanks, I've added these to the outline. From msk@cloudmark.com Mon Oct 24 07:18:01 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7654F21F8DD6 for ; Mon, 24 Oct 2011 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SlrPdh6eGEE for ; Mon, 24 Oct 2011 07:18:00 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC621F8DDF for ; Mon, 24 Oct 2011 07:18:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 24 Oct 2011 07:18:00 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 07:17:59 -0700 Thread-Topic: [Asrg] Greylisting BCP Thread-Index: AcyOeBjcXX19TxoER2mpNJmZE7CZBgD33pSA Message-ID: References: <4E9E07D2.4090304@xplornet.com> <4E9EA250.7070403@mines-paristech.fr> <20111019155859.GB21602@hjp.at> In-Reply-To: <20111019155859.GB21602@hjp.at> 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 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 14:18:01 -0000 > -----Original Message----- > From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of P= eter J. Holzer > Sent: Wednesday, October 19, 2011 8:59 AM > To: asrg@irtf.org > Subject: Re: [Asrg] Greylisting BCP >=20 > * Some sender MTAs change the envelope sender with every delivery > attempt (Yahoo Groups used to do this, but stopped several years ago. > I don't know any recent example). This garantuees that the triple > never matches ... Yuck. OK, added. > * Some ISPs use one machine for the first delivery and another for > processing the queue. The "queue processing" IP will get whitelisted > but the "first try" address wont (unless you are lucky), resulting in > a constant delay for every mail. I think that's covered, in slightly more general terms. From msk@cloudmark.com Mon Oct 24 07:34:13 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9321F8E3D for ; Mon, 24 Oct 2011 07:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahgADny2HRru for ; Mon, 24 Oct 2011 07:34:12 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id DC9CD21F8DD9 for ; Mon, 24 Oct 2011 07:34:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 24 Oct 2011 07:34:12 -0700 From: "Murray S. Kucherawy" To: Anti-Spam Research Group - IRTF Date: Mon, 24 Oct 2011 07:34:10 -0700 Thread-Topic: Greylisting BCP Thread-Index: AcyNyFMiwGiS2GCfTAOjHwpIcL/KzAEkYibA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C14C4CEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 14:34:13 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14C4CEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to all for the feedback so far. I've updated the draft to fold in t= he points people raised. I'll start the work of actually adding text to th= e various sections after the next IETF meeting. If any of you have specific text you'd like to see in there, please do send= it along. From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Tuesday, October 18, 2011 12:01 PM To: asrg@irtf.org Subject: [Asrg] Greylisting BCP After some chatter inside MAAWG and on the ietf-smtp mailing list, I've sta= rted an outline for a BCP on the practice of greylisting. The main purpose= is to explain what it is, discuss the pros and cons of its variants, and g= ive some recommendations for implementation and configuration for a few exa= mple installations and policies. The draft (which is currently only an outline) is here: https://datatracker= .ietf.org/doc/draft-kucherawy-greylisting-bcp/ Comments welcome. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C14C4CEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to all for the feedback so far.  I’ve updat= ed the draft to fold in the points people raised.  I’ll start th= e work of actually adding text to the various sections after the next IETF = meeting.

 

If any of you have specific text you’d like to see in there= , please do send it along.

 

<= p class=3DMsoNormal>From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org= ] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, October = 18, 2011 12:01 PM
To: asrg@irtf.org
Subject: [Asrg] Gre= ylisting BCP

&nb= sp;

After some chatter inside MAAWG and on th= e ietf-smtp mailing list, I’ve started an outline for a BCP on the pr= actice of greylisting.  The main purpose is to explain what it is, dis= cuss the pros and cons of its variants, and give some recommendations for i= mplementation and configuration for a few example installations and policie= s.

 

The draft (which is currently only an outline) is here: https://datatr= acker.ietf.org/doc/draft-kucherawy-greylisting-bcp/

 

Comments welcome.

 

= -MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14C4CEXCHC2corpclo_-- From clewis@xplornet.com Mon Oct 24 09:12:11 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CE91F0C36 for ; Mon, 24 Oct 2011 09:12: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MqFozm3bENf for ; Mon, 24 Oct 2011 09:12:10 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by ietfa.amsl.com (Postfix) with ESMTP id 399EF1F0C35 for ; Mon, 24 Oct 2011 09:12:09 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with SMTP id C5E9F399432 for ; Mon, 24 Oct 2011 16:12:03 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 636C657769734078706C6F726E65742E636F6D X-Filterd-Recvd-Size: 1983 Received: from [10.115.196.145] (unknown [62.50.249.219]) (Authenticated sender: clewis@xplornet.com) by omf10.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Oct 2011 16:12:02 +0000 (UTC) Message-ID: <4EA58E4E.4000907@xplornet.com> Date: Mon, 24 Oct 2011 18:11:58 +0200 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: asrg@irtf.org References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 16:12:12 -0000 On 11-10-24 10:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of Martijn Grooten >> Sent: Wednesday, October 19, 2011 8:06 AM >> To: Anti-Spam Research Group - IRTF >> Subject: Re: [Asrg] Greylisting BCP >> >> Do people apply greylisting post-DATA in practise? Or is this really >> only something only performed in labs as it is the only way to >> determine whether causes false positives. > > I plan to do a survey of popular implementations. If none do, that section can be dropped. But someone suggested including it in the outline which leads me to believe that some implementation does. As a FYI, some (perhaps only historical now) implementations behave badly with post-DATA rejects. An old version of Exchange, in particular, treated even a post-data 5xx as "retry as quickly as possible". But I've not seen one in a while. From prvs=127807ee78=lists@hireahit.com Mon Oct 24 16:42:22 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A3811E81DC for ; Mon, 24 Oct 2011 16:42:22 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rRnSh+S+DwO for ; Mon, 24 Oct 2011 16:42:21 -0700 (PDT) Received: from vinny.hireahit.com (vinny.hireahit.com [72.51.42.137]) by ietfa.amsl.com (Postfix) with ESMTP id 502F111E80A4 for ; Mon, 24 Oct 2011 16:42:21 -0700 (PDT) Received: from [172.24.0.104] by hireahit.com (vinny.hireahit.com) (SecurityGateway 2.0.6) with SMTP id SG001145778.MSG for ; Mon, 24 Oct 2011 16:38:38 -0700 Message-ID: <4EA5F6FD.2030008@hireahit.com> Date: Mon, 24 Oct 2011 16:38:37 -0700 From: Dave Warren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E4661.30205@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SGOP-RefID: fgs=0 (_st=1 _vt=0 _iwf=0) Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 24 Oct 2011 23:42:22 -0000 On 10/24/2011 1:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of Douglas Otis >> Sent: Tuesday, October 18, 2011 8:39 PM >> To: asrg@irtf.org >> Subject: Re: [Asrg] Greylisting BCP >> >> Grey listing challenges stateful processing of the sender to test an >> often erroneous assumption that bots sending spam don't maintain state. >> Thanks to grey listing, many bots retry against the same recipients, >> just not always with the same message. > That doesn't sound like a "retry" to me, in the MTA queueing sense. For your claim to be true, it would mean bots institute MTA-style queue-and-retry systems, but that substantially increases the footprint on the infected machine. It's been my impression that their reluctance to do this is precisely why greylisting is perceived to be effective. Keep in mind that zombies don't necessarily need to create some copy of each message and "queue" it. Rather, it's just as simple as keeping track of MAIL/RCPT pairs that should be retried and this doesn't need to incur much of a footprint at all. Whether they have a DB entry to track which message they wanted to deliver or not is an implementation detail. Either way, it's well within the capabilities of a zombie running on a midrange laptop/desjtop computer. However, all of this misses a huge part of why greylisting can be a powerful tool: It's a happy accident that bots still don't retry properly. I only greylist if I'm already suspicious based on rDNS patterns, mismatching reverse DNS, and similar. I don't greylist because I care if they retry (although it's nice that so many still don't). I greylist to let URIBLs and similar have a chance to catch up and detect a new zombie, to let my bayesian have time to learn, and to hope they hit one of my traps and get themselves blacklisted. I don't advocate greylisting everything, I found it's too obnoxious for general purpose use here, but in cases where I'm already suspicious, it's a second chance for a poorly managed sender to get through some front-line filters. -- Dave Warren, CEO Hire A Hit Consulting Services http://ca.linkedin.com/in/davejwarren From Jose-Marcio.Martins@mines-paristech.fr Tue Oct 25 08:51:52 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04E21F8B17 for ; Tue, 25 Oct 2011 08:51: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEJY+1vwQvam for ; Tue, 25 Oct 2011 08:51:52 -0700 (PDT) Received: from smtp-3.ensmp.fr (smtp-3.ensmp.fr [194.214.158.227]) by ietfa.amsl.com (Postfix) with ESMTP id CF26D21F8B15 for ; Tue, 25 Oct 2011 08:51:51 -0700 (PDT) Received: from localhost.localdomain (joe.j-chkmail.org [88.168.143.55]) (authenticated bits=0) by smtp-3.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id p9PFpiUL022267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 17:51:44 +0200 (MEST) Message-ID: <4EA6DB13.8030700@mines-paristech.fr> Date: Tue, 25 Oct 2011 17:51:47 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc14 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E4661.30205@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at cascavel with ID 4EA6DB10.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4EA6DB10.000 from joe.j-chkmail.org/joe.j-chkmail.org/88.168.143.55/localhost.localdomain/ Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2011 15:51:52 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of Douglas Otis >> Sent: Tuesday, October 18, 2011 8:39 PM >> To: asrg@irtf.org >> Subject: Re: [Asrg] Greylisting BCP >> >> Grey listing challenges stateful processing of the sender to test an >> often erroneous assumption that bots sending spam don't maintain state. >> Thanks to grey listing, many bots retry against the same recipients, >> just not always with the same message. > > That doesn't sound like a "retry" to me, in the MTA queueing sense. For your claim to be true, it would mean bots institute MTA-style queue-and-retry systems, but that substantially increases the footprint on the infected machine. It's been my impression that their reluctance to do this is precisely why greylisting is perceived to be effective. Retry or not retry... This just means that there are some possible ways to pass through greylisting and that greylisting isn't perfect... as any other filtering method, be an RBL, SPF, statistical filters or anything else. The correct way to present it is something like : "... to test a most of the time valid assumption that bots sending spam don't maintain state". Maybe in the future this assumption won't be true anymore, but for the moment, it seems to me that it still holds. -- From dotis@mail-abuse.org Tue Oct 25 11:26:21 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAEE21F8B32 for ; Tue, 25 Oct 2011 11:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8zZHhZrPHIe for ; Tue, 25 Oct 2011 11:26:20 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id 9182F21F8B2A for ; Tue, 25 Oct 2011 11:26:20 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 61A5E3B009F for ; Tue, 25 Oct 2011 18:26:18 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id BA380A9443B for ; Tue, 25 Oct 2011 18:26:19 +0000 (UTC) Message-ID: <4EA6FF4A.6050108@mail-abuse.org> Date: Tue, 25 Oct 2011 11:26:18 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <4E9E4661.30205@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 25 Oct 2011 18:26:21 -0000 On 10/24/11 1:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> On Tuesday, October 18, 2011 8:39 PM, Douglas Otis wrote: >> >> Grey listing challenges stateful processing of the sender to test an >> often erroneous assumption that bots sending spam don't maintain state. >> Thanks to grey listing, many bots retry against the same recipients, >> just not always with the same message. > That doesn't sound like a "retry" to me, in the MTA queueing sense. For your claim to be true, it would mean bots institute MTA-style queue-and-retry systems, but that substantially increases the footprint on the infected machine. It's been my impression that their reluctance to do this is precisely why greylisting is perceived to be effective. Not all RATs install simple SMTP proxies. There is no reason to queue and retry messages. They can receive a list of recipients separate from messages to reduce inbound traffic. Marking transmission completion would allow repeated tuples compared by grey listing mechanisms. -Doug From dotis@mail-abuse.org Tue Oct 25 13:41:12 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAE21F8677 for ; Tue, 25 Oct 2011 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuBNgHFkQSKF for ; Tue, 25 Oct 2011 13:41:11 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id A006821F8669 for ; Tue, 25 Oct 2011 13:41:11 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id AF6D6308187 for ; Tue, 25 Oct 2011 20:41:09 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 282FBA9443C for ; Tue, 25 Oct 2011 20:41:10 +0000 (UTC) Message-ID: <4EA71EE5.2010603@mail-abuse.org> Date: Tue, 25 Oct 2011 13:41:09 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> In-Reply-To: <4EA5328D.8060100@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 25 Oct 2011 20:41:12 -0000 On 10/24/11 2:40 AM, Alessandro Vesely wrote: >> > The problem is that for years email was virtually unregulated (open >> > relays were commonplace 15 years ago) which is why it is now so widely >> > abused. The only chance of cutting back abuse is to tighten things up. >> > Saying that attempts to tighten it up are "fatally flawed" just >> > because people can't be bothered to do things properly is dooming the >> > whole system to failure. > Very much agreed. > > With two policies out of two that choke on forwarding, I'd suspect the > culprit is the latter. Indeed, forwarding implies that target > addresses are being kept on a server. Hence, such server must have > some sort of authorization for using them. Why don't we check that? Efforts aimed at determining an "IP address authorization" based upon some "message element" is flawed for two reasons: 1) Authorization is easily abused whenever reputation is applied against a "purported domain". Outbound IP addresses are commonly shared, and this is becoming increasingly prevalent. The potential for abuse risks denial of service and legal responses as a singular recourse. 2) Even if magic happened and all specific "message elements" now attempt to offer "IP address authorizations", addresses seen by recipients may change at intervening SMTP proxies, LSNs, or CGNs. This problem will become more pronounced as IPv6 sources increase and many MTAs fail to offer IPv6 connectivity. Any effort to assign reputation to a range of IPv6 addresses immediately confronts a scale of active prefixes (ignoring lower 64 address bits) that is 65K larger than all possible IPv4 addresses. This range is likely to increase another 6 fold in a few years. A rate well beyond Moore's law. A sensible solution is a cryptographic method to authenticate the domain of the outbound MTA. DKIM does not authenticate the outbound MTA, and remains prone to abuse in a manner similar to IP address authorization. Perhaps a new type of SMTP needs to be developed, where the protocol remains unchanged with the exception of MTA authentication requirements. Call it AMTP for Authenticated Mail Transport Protocol. Once the MTA can be authenticated, the guesswork and mistakenly purported domain issues go away. There would not be any need to grey list recipients once receivers are able to maintain and control who they permit to issue messages. This may mean new domains need to solicit intended recipient domains to request inclusion. Such a process predicated on authentication scales far better and would be less disruptive than reactive blocking of any "purported" abuse. It also seems Kerberos offered by various third parties could help reduce the overhead related to MTA authentications. -Doug From Jose-Marcio.Martins@mines-paristech.fr Wed Oct 26 02:23:31 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E621F8A6C for ; Wed, 26 Oct 2011 02:23:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od0fxi6iQvnR for ; Wed, 26 Oct 2011 02:23:31 -0700 (PDT) Received: from smtp-3.ensmp.fr (smtp-3.ensmp.fr [194.214.158.227]) by ietfa.amsl.com (Postfix) with ESMTP id A129821F8A69 for ; Wed, 26 Oct 2011 02:23:30 -0700 (PDT) Received: from localhost.localdomain (bororo [10.3.5.15]) (authenticated bits=0) by smtp-3.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id p9Q9NR9m028991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 11:23:27 +0200 (MEST) Message-ID: <4EA7D191.5060802@mines-paristech.fr> Date: Wed, 26 Oct 2011 11:23:29 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc14 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> <4E9EF8A8.2030404@arpawocky.com> In-Reply-To: <4E9EF8A8.2030404@arpawocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at cascavel with ID 4EA7D18F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4EA7D18F.000 from bororo/bororo/10.3.5.15/localhost.localdomain/ Cc: Joe Sniderman Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 09:23:31 -0000 Joe Sniderman wrote: > >> Some quick comments: >> >> Do people apply greylisting post-DATA in practise? > > milter-greylist supports greylisting during DATA (not sure if its at the > beginning of DATA or at the end, could try it easily enough and find out > though) by means of the dacl configuration directive (as opposed to racl > for greylisting during RCPT) > > AFAIK the DCC also can perform greylisting during DATA. > > Might be worth adding a section to for greylisting performed during DATA. > > There's also some interesting archive discussion regarding it on the > Mimedefang list: > http://lists.roaringpenguin.com/pipermail/mimedefang/2009-May/034793.html > > It would appear from that discussion that at least Roaring Penguin > probably does do so in practice. > >> Or is this really >> only something only performed in labs as it is the only way to >> determine whether causes false positives. > > AFAIK one of the supposed benefits of greylisting during DATA instead of > RCPT is reduction of false positives. In the case of MIMEDefang, the probable reason is to avoid the following situation : a bot try to send a message at some moment and some time later try to send a different message to the same recipient. So, reduction of false negatives. Another reason to do greylisting during DATA is to apply greylisting only on messages which content score (evaluated by some kind of content filter) is greater than some threshold. In this case, not reduction of false positives, but applying greylisting only to messages already considered suspects. Either way, one goal of original greylisting is precisely to avoid heavy content filtering checks. So, doing greylisting after DATA, may not be optimal. From Jose-Marcio.Martins@mines-paristech.fr Wed Oct 26 02:46:37 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8842021F8AEE for ; Wed, 26 Oct 2011 02:46:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCJ1AV3qUULI for ; Wed, 26 Oct 2011 02:46:37 -0700 (PDT) Received: from smtp-3.ensmp.fr (smtp-3.ensmp.fr [194.214.158.227]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF921F8AAC for ; Wed, 26 Oct 2011 02:46:36 -0700 (PDT) Received: from localhost.localdomain (bororo [10.3.5.15]) (authenticated bits=0) by smtp-3.ensmp.fr (8.14.3/8.14.3/JMMC-11/Mar/2010) with ESMTP id p9Q9kWEi029327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 11:46:32 +0200 (MEST) Message-ID: <4EA7D6FA.5070602@mines-paristech.fr> Date: Wed, 26 Oct 2011 11:46:34 +0200 From: Jose-Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc14 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at cascavel with ID 4EA7D6F8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4EA7D6F8.000 from bororo/bororo/10.3.5.15/localhost.localdomain/ Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 09:46:37 -0000 Murray S. Kucherawy wrote: >> "greylisting is more expensive than not greylisting" >> >> Can you explain this? > > Put simply, any new filter has a cost to install, maintain, and operate. For greylisting there has to be a local store of sources that you've seen that get to bypass greylisting, so anything not on that list gets caught. That takes space, I/O, and processing time. So "expensive" in the resources sense. > You should take some care with this. Ressource usage varies a lot with different implementations : you'll find in memory chained lists, some RDBMS (e.g. MySQL) or ISAM/B-Tree/HASH (e.g. BerkeleyDB). Some implementations are smarter than others about ressources needes : e.g. how to expire old entries or how to aggregate them. And this makes a big difference on how expensive the filter is. Put simply, when talking about greylisting, expensive or not is more related to the implementation and to some tuning (e.g. delays) than to the method itself. I'm not even talking about poor programming practices... JM -- From prvs=0280B923CD=paul@pscs.co.uk Wed Oct 26 03:00:14 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE821F8AFC for ; Wed, 26 Oct 2011 03:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEGdVizk9yBq for ; Wed, 26 Oct 2011 03:00:13 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2948521F8A57 for ; Wed, 26 Oct 2011 03:00:12 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP for ; Wed, 26 Oct 2011 11:00:03 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for ; Wed, 26 Oct 2011 10:51:11 +0100 Message-ID: <4EA7D80E.7090107@pscs.co.uk> Date: Wed, 26 Oct 2011 10:51:10 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4E9E07D2.4090304@xplornet.com> <18B53BA2A483AD45962AAD1397BE1325382F2CC6A6@UK-EXCHMBX1.green.sophos> <4EA7D6FA.5070602@mines-paristech.fr> In-Reply-To: <4EA7D6FA.5070602@mines-paristech.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] Greylisting BCP X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 26 Oct 2011 10:00:14 -0000 Murray S. Kucherawy wrote: > >>> "greylisting is more expensive than not greylisting" >>> >>> Can you explain this? >> >> Put simply, any new filter has a cost to install, maintain, and >> operate. For greylisting there has to be a local store of sources >> that you've seen that get to bypass greylisting, so anything not on >> that list gets caught. That takes space, I/O, and processing time. >> So "expensive" in the resources sense. >> > On the other hand, if it stops a reasonable amount of spam, it reduces bandwidth, processing time and storage requirements, as well as human time & annoyance handling the spam. It's up to the implementer to decide whether the cost of implementing greylisting is more or less than the cost of not implementing it. From vesely@tana.it Wed Oct 26 05:05:00 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5621F8AD8 for ; Wed, 26 Oct 2011 05:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2fDfKQZiVws for ; Wed, 26 Oct 2011 05:04:59 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5921F8AB9 for ; Wed, 26 Oct 2011 05:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319630696; bh=V507iV8ijnvj7Gy7xvrj7dEw4wEDdRHAKAsgfta/ArU=; l=2397; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Xv2Utb9yNWVRHTWmkA/BxyhSRF20Fcjh7uOzWEn58lsCpZIwTUdwE/Pv4NsKtJFrg naEnBb6sMx5FZ4HmvLV0LmBVmRrsrchDkELiATPpjJ780OP3yUpCQhJOgBlhucrk7U gxcoGfW1so5dh6IBfhlr7pJ1vvNPX+/AeBsI/24s= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 26 Oct 2011 14:04:56 +0200 id 00000000005DC039.000000004EA7F768.00006188 Message-ID: <4EA7F768.6040100@tana.it> Date: Wed, 26 Oct 2011 14:04:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> In-Reply-To: <4EA71EE5.2010603@mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 26 Oct 2011 12:05:00 -0000 On 25/Oct/11 22:41, Douglas Otis wrote: > On 10/24/11 2:40 AM, Alessandro Vesely wrote: >> >> With two policies out of two that choke on forwarding, I'd suspect the >> culprit is the latter. Indeed, forwarding implies that target >> addresses are being kept on a server. Hence, such server must have >> some sort of authorization for using them. Why don't we check that? > Efforts aimed at determining an "IP address authorization" based upon > some "message element" is flawed for two reasons: I assume you mean SPF. Flawed as it may be, it'd still be better than nothing. > A sensible solution is a cryptographic method to authenticate the > domain of the outbound MTA. DKIM does not authenticate the outbound > MTA, and remains prone to abuse in a manner similar to IP address > authorization. Ditto. > Perhaps a new type of SMTP needs to be developed, where the > protocol remains unchanged with the exception of MTA authentication > requirements. Call it AMTP for Authenticated Mail Transport > Protocol. Why not call it SMTP-AUTH? Indeed, it's much stronger than SPF or DKIM. > Once the MTA can be authenticated, the guesswork and mistakenly > purported domain issues go away. There would not be any need to grey > list recipients once receivers are able to maintain and control who > they permit to issue messages. Yep. > This may mean new domains need to solicit intended recipient > domains to request inclusion. No, not only new domains. Whenever someone prompts you for your email address and your consent for using it, according to various laws, it could/should store some form of auth token along with it. That way, I'd address forwarded mail only. That is, more or less, what policies such as SPF and ADSP seem to be unable to handle properly --I called it the culprit in the top quoted paragraph above. Direct personal messages, where recipient addresses are set as part of the message composition, need no authorization. Of course, black spammers will pretend to write personal messages, thereby breaking the law, but grey spammers won't. > Such a process predicated on authentication scales far better and > would be less disruptive than reactive blocking of any "purported" > abuse. I concur. The ability to mechanically tell legitimate messages will then allow spam reporting to be a well defined activity. From dotis@mail-abuse.org Fri Oct 28 11:28:30 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D383221F8A62 for ; Fri, 28 Oct 2011 11:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8-CWr6Nt8Vb for ; Fri, 28 Oct 2011 11:28:30 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2321F8A56 for ; Fri, 28 Oct 2011 11:28:30 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 05F663B005E for ; Fri, 28 Oct 2011 18:28:28 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 62A19A9443B for ; Fri, 28 Oct 2011 18:28:29 +0000 (UTC) Message-ID: <4EAAF44D.4020705@mail-abuse.org> Date: Fri, 28 Oct 2011 11:28:29 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> In-Reply-To: <4EA7F768.6040100@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 28 Oct 2011 18:28:30 -0000 On 10/26/11 5:04 AM, Alessandro Vesely wrote: > On 25/Oct/11 22:41, Douglas Otis wrote: > > On 10/24/11 2:40 AM, Alessandro Vesely wrote: > >> > >> With two policies out of two that choke on forwarding, I'd > >> suspect the culprit is the latter. Indeed, forwarding implies > >> that target addresses are being kept on a server. Hence, such > >> server must have some sort of authorization for using them. Why > >> don't we check that? > > > Efforts aimed at determining an "IP address authorization" based > > upon some "message element" is flawed for two reasons: > > I assume you mean SPF. Flawed as it may be, it'd still be better > than nothing. Not when SPF authorization is considered a basis in which to assess a domain's reputation. This occurs at a time when large scale NATs (LSNs) are deployed by ISPs to support IPv6 transitions. The inability to defend authorizations against reputation poisoning will foster dependence on providers protected by their "too big to block" status. The growing environment of shared outbound sources makes simple authorization fully unsuitable. In addition, each email transaction demands DNS resolve all IPv4 and IPv6 hosts used by any globally recognized domain. These DNS transactions may extend beyond 100 in the effort to authorize all outbound MTAs used by a single domain. This exercise can lead to DDoS against domains not a party to either end of the specific email transaction. SPF macro expansions defeat DNS caching and result in easily two orders of traffic amplification. :^( There are many methods that might be used to authenticate outbound MTAs, such as SMTP Auth. Ideally SMTP would include DANE extensions used in conjunction with Kerberos. If it were not for DKIM ignoring prepended headers, it would have merit as an anti-phishing strategy. Since DKIM does not verify who sent what to whom, it can only identify domains considered "too big to block" as well. > > A sensible solution is a cryptographic method to authenticate the > > domain of the outbound MTA. DKIM does not authenticate the > > outbound MTA, and remains prone to abuse in a manner similar to IP > > address authorization. > > Ditto. What do you think is standing in the way of SMTP authentication? > > Perhaps a new type of SMTP needs to be developed, where the > > protocol remains unchanged with the exception of MTA > > authentication requirements. Call it AMTP for Authenticated Mail > > Transport Protocol. > > Why not call it SMTP-AUTH? Indeed, it's much stronger than SPF or > DKIM. In the past, some of the objections had been cert costs. DANE should remedy the cost issue, and ensure domains support DNSsec. The increased overhead related with DNSsec demands greater attention given protocol dependent upon DNS that might lead to indirect high gain DDoS attacks. > > Once the MTA can be authenticated, the guesswork and mistakenly > > purported domain issues go away. There would not be any need to > > grey list recipients once receivers are able to maintain and > > control who they permit to issue messages. > > Yep. > > > This may mean new domains need to solicit intended recipient > > domains to request inclusion. > > No, not only new domains. Whenever someone prompts you for your > email address and your consent for using it, according to various > laws, it could/should store some form of auth token along with it. > > That way, I'd address forwarded mail only. That is, more or less, > what policies such as SPF and ADSP seem to be unable to handle > properly --I called it the culprit in the top quoted paragraph > above. Expectations any outbound MTA mitigate abusive accounts where reputation is based upon authentication of the MTA would have a profound outcome. Users in possession of compromised accounts/systems would be made aware and categorization of mail content (as you suggest) becomes moot. Don't expect recipients are able to sort compromised accounts of large senders. Placing that burden on recipients never scales. > Direct personal messages, where recipient addresses are set as part > of the message composition, need no authorization. Of course, black > spammers will pretend to write personal messages, thereby breaking > the law, but grey spammers won't. Or allow new domains to quickly obtain the same status of any domain that quickly mitigates abuse. > > Such a process predicated on authentication scales far better and > > would be less disruptive than reactive blocking of any "purported" > > abuse. > > I concur. The ability to mechanically tell legitimate messages will > then allow spam reporting to be a well defined activity. Hopefully spam reporting will also play a reduced role as well. -Doug From prvs=028393BEF0=paul@pscs.co.uk Fri Oct 28 18:40:04 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9DD21F8462 for ; Fri, 28 Oct 2011 18:40:04 -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_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj3wtF1Oy-cc for ; Fri, 28 Oct 2011 18:40:04 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id D265321F845F for ; Fri, 28 Oct 2011 18:40:02 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Sat, 29 Oct 2011 02:39:55 +0100 Received: from [192.168.1.121] ([86.131.209.148]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Sat, 29 Oct 2011 02:38:29 +0100 Message-ID: <4EAB5911.9010203@pscs.co.uk> Date: Sat, 29 Oct 2011 02:38:25 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> In-Reply-To: <4EAAF44D.4020705@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 29 Oct 2011 01:40:04 -0000 On 28/10/2011 19:28, Douglas Otis wrote: > There are many methods that might be used to authenticate outbound > MTAs, such as SMTP Auth. Ideally SMTP would include DANE extensions > used in conjunction with Kerberos. If it were not for DKIM ignoring > prepended headers, it would have merit as an anti-phishing strategy. > Since DKIM does not verify who sent what to whom, it can only identify > domains considered "too big to block" as well. Excuse me for being thick, I'm trying to understand your thoughts. I can sort of see how you could AUTHENTICATE outbound MTAs, however that's not the problem as far as I can see. You can reliably authenticate an outbound MTA based on its IP address at the moment (although that would probably be less useful than authenticating a 'group' of MTAs based on the owner, eg Yahoo, and will be less useful with IPv6). Some of the technicalities of authentication based on cryptographic means are a bit unclear, but I can see that it could probably be made to work. However, once you have authenticated the MTA, you then need to decide whether to authorise it,and what to authorise it for. Are you talking about just authorising it to be able to send mail from a particular domain? (If so, I'm not sure how this fixes the 'forwarding problem'), or authorising it be able to send mail to me at all? (in which case, who would decide on that authorisation?) (AFAICS Something like SRS should probably be able to fix the forwarding problem if the rest of the system is setup correctly) You say "Ideally SMTP would include DANE extensions used in conjunction with Kerberos" - now, I'm not very familiar with DANE or Kerberos at the moment, but I think DANE lets you associate a certificate with a domain name using DNS - yes?. Since it wouldn't be possible for a sending MTA to authenticate using such a certificate based on the sender's email domain, I presume you mean it will use the certificate based on the MTA's reverse DNS entry? So, how would that link the sending MTA with the sender's email address? And would Kerberos need a separate server? If so, where would that be, the sending or receiving end? (I'm not sure I like the idea of having to use Kerberos) If you are just going to authenticate based on the MTA's reverse DNS, then why not just mandate TLS and authenticate the client certificate using DANE? Could you not change SMTP to go something like: EHLO sender 220 ENVSIGN CHALLENGE=RandomText MAIL FROM: 220 OK RCPT TO: 220 OK RCPT TO: 220 OK ENVSIGN: 220 OK The sender signs the envelope data using the private key; the public key is exposed using DNS or something (DANE?) . Kerberus isn't needed, and the sending MTA can send from multiple different domains in a single session. (Still doesn't solve forwarding without return path rewriting, or the general authorisation problem, but authenticates the sender MTA effectively, AFAICS) From prvs=028393BEF0=paul@pscs.co.uk Sat Oct 29 02:20:17 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAB21F86AA for ; Sat, 29 Oct 2011 02:20:17 -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_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss3D-0h5AiA4 for ; Sat, 29 Oct 2011 02:20:15 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1E21F85A4 for ; Sat, 29 Oct 2011 02:20:13 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP for ; Sat, 29 Oct 2011 10:20:05 +0100 Received: from [192.168.1.121] ([86.131.209.148]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for ; Sat, 29 Oct 2011 10:16:30 +0100 Message-ID: <4EABC46B.3010903@pscs.co.uk> Date: Sat, 29 Oct 2011 10:16:27 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> In-Reply-To: <4EAB5911.9010203@pscs.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 29 Oct 2011 09:20:17 -0000 On 29/10/2011 02:38, Paul Smith wrote: > On 28/10/2011 19:28, Douglas Otis wrote: >> There are many methods that might be used to authenticate outbound >> MTAs, such as SMTP Auth. Ideally SMTP would include DANE extensions >> used in conjunction with Kerberos. If it were not for DKIM ignoring >> prepended headers, it would have merit as an anti-phishing strategy. >> Since DKIM does not verify who sent what to whom, it can only >> identify domains considered "too big to block" as well. > > > (Still doesn't solve forwarding without return path rewriting, or the > general authorisation problem, but authenticates the sender MTA > effectively, AFAICS) I've been thinking about forwarding If you have A -> B, then server B forwards to server C, C can't do any authentication based on A, because A doesn't know about the forwarding (or it would, presumably, just send to C directly). So, all sender domain authentication fails (without return path rewriting) So, what you need is for C to be able to give B an authentication key for the forwarding. Then, B could pass that back to C with the message (possibly as a parameter to the RCPT command). The issue with this is that user intervention would be needed - so every time a user wants to subscribe to a mailing list,or set up a forwarding to their gmail account, they would need to go to the destination server, get a key from it, and give it to the forwarding server. This could show consent for any anti-spamming legislation, but could also be too complicated for many users to handle. The authentication key would need to allow B to send *anything* to C for the relevant recipient, so ideally the key that C gives would be specific to B (to allow it to be revoked in the case of abuse) Technically this wouldn't need to be hard at all, it's just the manual requirement for key exchange that would be an issue for many people. From hjp-asrg@hjp.at Sat Oct 29 07:11:10 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F05521F8696 for ; Sat, 29 Oct 2011 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6HSY5rVi1Vs for ; Sat, 29 Oct 2011 07:11:09 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8D021F8669 for ; Sat, 29 Oct 2011 07:11:08 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id B07DF4004; Sat, 29 Oct 2011 16:10:43 +0200 (CEST) Date: Sat, 29 Oct 2011 16:10:43 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20111029141043.GJ6389@hjp.at> References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/D3X8sky0X3AmG5" Content-Disposition: inline In-Reply-To: <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Asrg] SPF and forwarding (was: Microsoft takes over British Telecom) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 29 Oct 2011 14:11:10 -0000 --W/D3X8sky0X3AmG5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-10-23 14:43:00 -0700, Steve Atkins wrote: > Mail forwarding is one common cause of failure. If you're sending mail > to someone at @ieee.org and they forward it on to their @aol.com > account, and you and AOL decide between you to enforce SPF -all then > that mail will be undeliverable - and there's no way either you or AOL > can predict that. Actually, I can because I told ieee.org to forward my mail to aol.com and I know that I enabled SPF for my aol.com address. There is nothing unpredictable about that - I control both sides of the forwarding. What AOL has to predict is that some of their customers may want to forward from another mail address to their AOL mailbox and provide a way to exempt specific sender IP addresses from SPF checks. hp --=20 _ | Peter J. Holzer | Web 2.0 k=F6nnte man also auch =FCbersetzen als |_|_) | Sysadmin WSR | "Netz der kleinen Geister". | | | hjp@hjp.at |=20 __/ | http://www.hjp.at/ | -- Oliver Cromm in desd --W/D3X8sky0X3AmG5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFOrAljfZ+RkG8quy0RAguSAJwLHEwawj8J2lvFsQTmsskrkYSn2ACcD/em uJl2GfaNtNVzSgoQBBhndxQ= =8vO5 -----END PGP SIGNATURE----- --W/D3X8sky0X3AmG5-- From vesely@tana.it Sun Oct 30 05:11:34 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACA21F8AF8 for ; Sun, 30 Oct 2011 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JIxcXRHdyPw for ; Sun, 30 Oct 2011 05:11:30 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0021F8AF7 for ; Sun, 30 Oct 2011 05:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319976687; bh=ltbpDMFk342dZjpmYDdl3HmOjrrK2kKvtYgdE5G9FrA=; l=3054; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=AHB1TwiptN17pH3I7QOGl4qPjL136hAaVkcsKE56lRc9YgnbLoNRRjDTDSjIww48d RoDD4+cSsZsf6IUgtDBNcfJIsH+m88+gm5o8Q5EVcaOd6Dlj0QbgrQdxywpnxVYnqS IB+EScrxaTxfq9xa0PValxCpCPFp8gBosae46Y+c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 30 Oct 2011 13:11:27 +0100 id 00000000005DC035.000000004EAD3EEF.00002280 Message-ID: <4EAD3EEE.7070007@tana.it> Date: Sun, 30 Oct 2011 13:11:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> <4EABC46B.3010903@pscs.co.uk> In-Reply-To: <4EABC46B.3010903@pscs.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Asrg] Authorized forwarding, was Microsoft takes over... X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 30 Oct 2011 12:11:34 -0000 On 29/Oct/11 11:16, Paul Smith wrote: > > I've been thinking about forwarding > > If you have A -> B, then server B forwards to server C, C can't do any > authentication based on A, because A doesn't know about the forwarding > (or it would, presumably, just send to C directly). Correct. One may still be able to tell whether a message originated at A, though. > So, all sender domain authentication fails (without return path > rewriting) That's the turn point. We pine for domain authentication looking forward to reckoning domain's reputation. So far so good. But a simpler SMTP-AUTH suffices for authenticating a specific sender that had been authorized beforehand. > So, what you need is for C to be able to give B an authentication key > for the forwarding. Then, B could pass that back to C with the message > (possibly as a parameter to the RCPT command). For SMTP AUTH, it is a parameter to the MAIL command. After having authenticated, B can use message-specific authorizations by MAIL FROM: AUTH=forwarder@B.example C can check B is authorized, but must trust B uses authorizations properly; that is, according to the message stream for which the authorization was granted. > The issue with this is that user intervention would be needed - so > every time a user wants to subscribe to a mailing list,or set up a > forwarding to their gmail account, they would need to go to the > destination server, get a key from it, and give it to the > forwarding server. This could show consent for any anti-spamming > legislation, but could also be too complicated for many users to > handle. Exactly. If law-makers had been clever, they would have provided for a protocol to exchange the consent automatically. Something similar to paying with a credit card via a bank site. Users would need to tell only their domain name to the mailing list manager, or gmail account. The wannabe forwarder B would redirect them to their server C where they can authenticate, configure any detail such as the target folder, and grant their consent back to B. > The authentication key would need to allow B to send *anything* to C > for the relevant recipient, so ideally the key that C gives would be > specific to B (to allow it to be revoked in the case of abuse) Yes. For non-transferable consent, the user's server C can pass an opaque local-part to the wannabe forwarder B. That way, B won't even know the full email address of the user. > Technically this wouldn't need to be hard at all, it's just the manual > requirement for key exchange that would be an issue for many people. It is easy technically, but not politically. In Europe, a consent-exchange protocol would get some traction if it could replace the tedious paperwork that Directive 95/46/EC requires. For that, we'd need the Art.29 Working Party to participate in an IETF Working Group so as to standardize and bless that protocol at the same time. Not an easy task. -- http://fixforwarding.org/ From dotis@mail-abuse.org Mon Oct 31 11:28:43 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD3E1F0C9C for ; Mon, 31 Oct 2011 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvI6heN+7ALD for ; Mon, 31 Oct 2011 11:28:42 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id DD7AD1F0C58 for ; Mon, 31 Oct 2011 11:28:42 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 9A64F3B007E; Mon, 31 Oct 2011 18:28:40 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id DE702A9443B; Mon, 31 Oct 2011 18:28:41 +0000 (UTC) Message-ID: <4EAEE8D3.3080408@mail-abuse.org> Date: Mon, 31 Oct 2011 11:28:35 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Smith References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> In-Reply-To: <4EAB5911.9010203@pscs.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 31 Oct 2011 18:28:43 -0000 On 10/28/11 6:38 PM, Paul Smith wrote: > On 28/10/2011 19:28, Douglas Otis wrote: > > There are many methods that might be used to authenticate outbound > > MTAs, such as SMTP Auth. Ideally SMTP would include DANE > > extensions used in conjunction with Kerberos. If it were not for > > DKIM ignoring prepended headers, it would have merit as an > > anti-phishing strategy. Since DKIM does not verify who sent what > > to whom, it can only identify domains considered "too big to block" > > as well. > Excuse me for being thick, I'm trying to understand your thoughts. > > I can sort of see how you could AUTHENTICATE outbound MTAs, however > that's not the problem as far as I can see. You can reliably > authenticate an outbound MTA based on its IP address at the moment > (although that would probably be less useful than authenticating a > 'group' of MTAs based on the owner, eg Yahoo, and will be less useful > with IPv6). Some of the technicalities of authentication based on > cryptographic means are a bit unclear, but I can see that it could > probably be made to work. > > However, once you have authenticated the MTA, you then need to decide > whether to authorise it,and what to authorise it for. Are you talking > about just authorising it to be able to send mail from a particular > domain? (If so, I'm not sure how this fixes the 'forwarding > problem'), or authorising it be able to send mail to me at all? (in > which case, who would decide on that authorisation?) David Black and myself authored a draft describing a method to authorize any number of domains using a single small DNS transaction. Murray also authored a similar version once this draft expired. Attempting to publish entire IP address sets for email domains is highly problematic, especially when misapplied as a basis for assessing accountability. Use of IP address authorization based upon entire address sets will become highly disruptive from either a DDoS or rejection basis. IP address translations occurring at providers that can not be anticipated by senders. Any expectation that possible LSNs will be white-listed would permit any amount of abuse. > (AFAICS Something like SRS should probably be able to fix the > forwarding problem if the rest of the system is setup correctly) Rather than expecting recipients to sort emails based upon message elements not authenticated with those who issued a message to specific recipients (which DKIM does not do), a more effective scheme holds outbound MTAs accountable for mitigating abuse. MTAs failing to respond would be blocked. Requiring outbound MTA to respond better informs individuals when accounts or systems are compromised and is the most effective method for controlling abuse. > You say "Ideally SMTP would include DANE extensions used in > conjunction with Kerberos" - now, I'm not very familiar with DANE or > Kerberos at the moment, but I think DANE lets you associate a > certificate with a domain name using DNS - yes?. Since it wouldn't be > possible for a sending MTA to authenticate using such a certificate > based on the sender's email domain, I presume you mean it will use > the certificate based on the MTA's reverse DNS entry? So, how would > that link the sending MTA with the sender's email address? Some delivery issues occur when recipients are unaware their servers lack adequate resources where connections fail and yet these failure are not logged. Doing any type of cryptographic authentication adds overhead, where a hybrid Kerberos/SMTP approach provides an efficient method with increased control. Those wanting to obtain fast processing would first authenticate with a designated Kerberos server located by SRV records. Once authenticated, a data-structure (perhaps published using APL RFC2133) could be accepted to open firewalls at the receivers, where individual SMTP transactions first exchange long-lived easy to process Kerberos tickets. > And would Kerberos need a separate server? If so, where would that > be, the sending or receiving end? (I'm not sure I like the idea of > having to use Kerberos) If you own a Mac, Apple provides users Kerberos services to enhance security on otherwise insecure networks. Any large domain could offer their own Kerberos server where senders would obtain a ticket once every 10 hours for example. It is also likely Kerberos services will be offered by various third-parties as well. > If you are just going to authenticate based on the MTA's reverse DNS, > then why not just mandate TLS and authenticate the client certificate > using DANE? rDNS is highly problematic because this involves separate administrations. Those running a service are not necessarily delegated to publish rDNS records. With the IP address ranges permitted by IPv6, rDNS is also unlikely to be useful for differentiating different categories of IP addresses. It is not practical to expect SMTP to query rDNS against every IPv6 connection. It is also not practical to expect a third-party will be publishing this information either. > Could you not change SMTP to go something like: EHLO sender 220 > ENVSIGN CHALLENGE=RandomText > > MAIL FROM: 220 OK RCPT TO: 220 > OK RCPT TO: 220 OK ENVSIGN: RandomText+sender@domain.com+rcpt1@user.com+rcpt2@user2.com> 220 OK > > The sender signs the envelope data using the private key; the public > key is exposed using DNS or something (DANE?) . Kerberus isn't > needed, and the sending MTA can send from multiple different domains > in a single session. Kerberos was suggested as a way to avoid much of the overhead related with processing certificates at each exchange. It also provides a way to offer layered protections, such as selectively enabling firewall subsequent to completion of a Kerberos exchange. Kerberos exchanges would be at much much lower rates than that demanded by SMTP. > (Still doesn't solve forwarding without return path rewriting, or the > general authorisation problem, but authenticates the sender MTA > effectively, AFAICS) IMHO, the IP address authorization scheme was poorly considered. With more than 95% of SMTP transactions being abusive, expecting recipients to then perform as many as 100 additional SPF DNS transactions and any number of reputation transactions per message is neither practical nor safe. In the face of IPv6, any IP address authorization requirement will also be highly disruptive. There is a practical way for each domain to authorize other domains. Whether this would be needed after outbound MTAs have been held accountable is yet to be determined. -Doug From john@jlc.net Mon Oct 31 11:46:17 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27801F0CC0 for ; Mon, 31 Oct 2011 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxc8EYTVpvqK for ; Mon, 31 Oct 2011 11:46:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8D1F0CBF for ; Mon, 31 Oct 2011 11:46:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5D16E33C24; Mon, 31 Oct 2011 14:46:16 -0400 (EDT) Date: Mon, 31 Oct 2011 14:46:16 -0400 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20111031184616.GA1872@verdi> References: <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> <4EAEE8D3.3080408@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAEE8D3.3080408@mail-abuse.org> User-Agent: Mutt/1.4.1i Subject: [Asrg] MTA Authorization/Authentication X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 31 Oct 2011 18:46:18 -0000 Douglas Otis wrote: > > David Black and myself authored a draft describing a method to > authorize any number of domains using a single small DNS transaction. Reference, please: I don't think I'm familiar with this. > Murray also authored a similar version once this draft expired. Likewise... > Attempting to publish entire IP address sets for email domains is > highly problematic, especially when misapplied as a basis for > assessing accountability. I quite agree. -- John Leslie From dotis@mail-abuse.org Mon Oct 31 13:26:39 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801F11E8223 for ; Mon, 31 Oct 2011 13:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eplMg9zmGX5F for ; Mon, 31 Oct 2011 13:26:38 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id B642A11E8222 for ; Mon, 31 Oct 2011 13:26:38 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id E2B223B007F for ; Mon, 31 Oct 2011 20:26:35 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 7A52DA9443B for ; Mon, 31 Oct 2011 20:26:37 +0000 (UTC) Message-ID: <4EAF047D.9070507@mail-abuse.org> Date: Mon, 31 Oct 2011 13:26:37 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> <4EAEE8D3.3080408@mail-abuse.org> <20111031184616.GA1872@verdi> In-Reply-To: <20111031184616.GA1872@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] MTA Authorization/Authentication X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 31 Oct 2011 20:26:39 -0000 On 10/31/11 11:46 AM, John Leslie wrote: > Douglas Otis wrote: >> David Black and myself authored a draft describing a method to >> authorize any number of domains using a single small DNS transaction. > Reference, please: I don't think I'm familiar with this. http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 >> Murray also authored a similar version once this draft expired. > Likewise... http://tools.ietf.org/html/draft-kucherawy-dkim-atps-10 The difference is tpa-label attempted to include methods to identify outbound MTAs, and was not limited to just authorized DKIM signature chains. -Doug From prvs=0285129CAC=paul@pscs.co.uk Mon Oct 31 15:10:25 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B490011E8134 for ; Mon, 31 Oct 2011 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUSjSZO6QjRI for ; Mon, 31 Oct 2011 15:10:22 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3BB11E80D7 for ; Mon, 31 Oct 2011 15:10:15 -0700 (PDT) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Mon, 31 Oct 2011 22:09:58 -0000 Received: from [192.168.57.207] ([217.155.61.155]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Mon, 31 Oct 2011 22:06:35 -0000 Message-ID: <4EAF1BE7.6000508@pscs.co.uk> Date: Mon, 31 Oct 2011 22:06:31 +0000 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Douglas Otis References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> <4EA5328D.8060100@tana.it> <4EA71EE5.2010603@mail-abuse.org> <4EA7F768.6040100@tana.it> <4EAAF44D.4020705@mail-abuse.org> <4EAB5911.9010203@pscs.co.uk> <4EAEE8D3.3080408@mail-abuse.org> In-Reply-To: <4EAEE8D3.3080408@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.9 - Registered X-Organisation: Paul Smith Computer Services Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam 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, 31 Oct 2011 22:10:26 -0000 X-List-Received-Date: Mon, 31 Oct 2011 22:10:26 -0000 On 31/10/2011 18:28, Douglas Otis wrote: > Kerberos was suggested as a way to avoid much of the overhead related > with processing certificates at each exchange. It also provides a > way to offer layered protections, such as selectively enabling > firewall subsequent to completion of a Kerberos exchange. Kerberos > exchanges would be at much much lower rates than that demanded by SMTP. I'm struggling with the Kerberos idea If you want to send a message to me, that means you need to authenticate with 'my' kerberos server? What authentication details do you use? Do I have to contact you to give you authentication details to my server? Surely that can't be the case, but how else would the authentication work? (or would the sender authenticate *with itself* via the receiver? I can see that working in theory, but would be complicated and I can't see how it would work with a standard kerberos implementation) Given that most of our customers are business with < 25 users, many of whom have their MX records pointing to their own MTA, how would this work? Most want to use their own MTA because their ISPs are useless, and switching to their own MTA gives them enhanced reliability and control. I can't see them rushing to sign up to a third party kerberos server (probably with extra fees and unknown reliability). Does this mean we'll be needing to create our own kerberos server to run alongside our mail server software? Most of our customers use Windows desktop OSes (eg Windows XP, Windows 7 etc), which, AFAIAA don't give you kerberos services. Using kerberos only makes sense if everyone who has a legitimate mail server has kerberos, which obviously isn't the case. > Kerberos was suggested as a way to avoid much of the overhead related > with processing certificates at each exchange. Does this mean that STARTTLS is undesirable as well? Is the calculation of a signature that problematic? It's relatively CPU intensive, but low bandwidth. I'd have thought most mail systems would be I/O bound rather than CPU bound (unless they're doing antispam/antivirus, in which case a calculating/checking a signature is a relatively miniscule extra load). DKIM already generates/checks signatures, and with much more data & complexity. From asrg3@billmail.scconsult.com Mon Oct 31 23:41:24 2011 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE66A21F8EB4 for ; Mon, 31 Oct 2011 23:41: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwNj-ySUvZLD for ; Mon, 31 Oct 2011 23:41:23 -0700 (PDT) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0547C21F8EAD for ; Mon, 31 Oct 2011 23:41:22 -0700 (PDT) Received: from deepfield.scconsult.com (deepfield.scconsult.com [192.168.254.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 331C9EA282C for ; Tue, 1 Nov 2011 02:41:19 -0400 (EDT) Message-ID: <4EAF948E.7080800@billmail.scconsult.com> Date: Tue, 01 Nov 2011 02:41:18 -0400 From: Bill Cole User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <029601cc9007$f2b94260$4001a8c0@gateway.2wire.net> <45A794EA-C3C4-4BB1-82EB-E8BA4781C947@blighty.com> <4EA4270F.7000304@tana.it> <28CC846A-5815-4179-BABF-A2007B7E6242@blighty.com> <4EA48445.4080001@pscs.co.uk> <6F5BD180-6BB6-4B2E-9D2A-BF47ADE204CA@blighty.com> <4EA4AF0D.2000000@pscs.co.uk> In-Reply-To: <4EA4AF0D.2000000@pscs.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] Microsoft takes over British Telecom X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2011 06:41:25 -0000 Paul Smith wrote, On 10/23/11 8:19 PM: > On 23/10/2011 22:43, Steve Atkins wrote: >> On Oct 23, 2011, at 2:16 PM, Paul Smith wrote: >> >>> On 23/10/2011 17:09, Steve Atkins wrote: >>>> On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote: >>>> >>>>> On 21/Oct/11 19:07, Steve Atkins wrote: >>>>>> The bigger issue is that you shouldn't care about SPF failing. An SPF >>>>>> pass >>>>>> provides somewhat useful data, an SPF fail means absolutely nothing. >>>>> Wasn't it supposed to mean "reject"? IIRC, that was the difference >>>>> between setting -all (as irtf.org does) rather than ~all or ?all. >>>> That's what it's proponents used to claim, yes. But it's unfixably >>>> broken for >>>> that purpose. The only reason you don't see serious mail problems for >>>> anyone unwise enough to use -all is that almost nobody pays much attention >>>> to SPF for rejecting email. >>>> >>> How is it 'unfixably' broken? Just interested. >>> >>> it seems to me that the only reason it's 'unfixably broken' is that >>> people are using it without really understanding what it's doing. If all >>> MTAs rejected all mail that failed SPF checks, then they'd soon get the >>> problems fixed. Remote users having to relay via a specified submission >>> server is a trivial problem to fix (AFAICS), and incorrectly specified >>> SPF records (as in the BT/MS case) deserve to cause messages to be >>> blocked (IMHO) >>> >>> (SPF is certainly not that useful as an 'anti-spam' mechanism, but it >>> seems to have the potential to work reasonably well as an anti-spoofing >>> mechanism, which makes it considerably harder for many spammers) >> Mail forwarding is one common cause of failure. If you're sending mail to >> someone at @ieee.org and they forward it on to their @aol.com account, and >> you and AOL decide between you to enforce SPF -all then that mail will be >> undeliverable - and there's no way either you or AOL can predict that. > I thought most people did return-path rewriting for this case. If you don't > do that, then you get undesirable behaviour anyway - eg if the AOL mailbox > is full, you get a bounce message from AOL, even though you didn't send any > messages to AOL at all. Yes, that happens. No, return-path rewriting is the exception, not the rule. People still use Sendmail aliases and ~/.forward mechanisms and functional work-alikes in other MTA's and it breaks the utility of explicitly derogatory SPF, both "-" and "~" However, as often as the classical forwarding model is brought up as an example of SPF breakage, it really isn't the critical failure mode for simplistic SPF usage, since classical forwarding is mostly a tool of people who remember the days before the Eternal September. We're an influential bunch, yes, but there are not enough of us to break something that would otherwise work. >> Mailing lists is another similar cause of SPF failures.. > Similarly, I thought return-path rewriting was standard for mailing lists. > Especially ones which do VERP, but usually even in ones which don't - eg the > return path on the message I received from you was > "", not your blighty.com address. Therefore, it > correctly passed an SPF test for irtf.org. Yes, any mailing lists using reasonable list management tools rewrite messages with their own return-path and cause no trouble for SPF. There are some things called mailing lists that use 'exploder' features of various MTA's which don't use their own return-paths or any distinct software, but those sorts of lists were basically dysfunctional before spam was a significant problem. Like classical forwarding, that is also not the hardest obstacle for clean and simple use of derogatory SPF results. >> A third, which is a lot more common and complex to resolve than you'd >> expect, is organizations simply not knowing or not controlling where their >> mail is sent from. There've been cases both for SPF and ADSP ("SPF for >> DKIM") where one group within a company put out a restrictive policy based >> on their beliefs of where mail was sent from, and it all fell to pieces >> when employees got kicked off mailing lists when mail appearing to come >> from them was delivered from the mailing list manager and rejected due to >> auth failure, or where internal monitoring email sent from servers (cron, >> even) was silently discarded. > This is the problem of people who should know better not understanding > what's going on. Yes. That is why this problem is the truly hard one for application of SPF in derogatory ways. Deprecating technical mechanisms via "standards" (to whatever degree a low-grade RFC can be called that) and real-world bad outcomes has a successful track record of working to extinguish their use or encourage workarounds. Deprecating human carelessness and ignorance has no successful track record. NO SUCCESSFUL TRACK RECORD In other words: THIS DOES NOT WORK! > If the company had a policy that all mail from their domain > had to go through certain servers, and employees were sending mail through > other servers, then they deserved to get kicked off mailing lists... Just as > they would deserve punishment for watching porn over the work Internet > connection, etc. If they had a policy that mail had to go through certain > servers, and configured SPF for different servers, then they shouldn't be > managing mail systems. That's nice. The fact is that sysadmins follow Sturgeon's Law just like any other large population. I'm very sorry about that. I really am. Beyond that sad fact of life, there are other issues with "-all" (and even "~all") grounded in forms of dumb that are external to the administrators of any domain setting SPF records. For example, diverse online service providers including resume search systems, news clipping agencies, magazine publishers, and so on (and on and on) will send email on behalf of registered users with any envelope sender address that they have for the user. Whether it is a "mail a friend this article" link at the NYT or a "find me candidates for this job" form at a headhunter agency, there are a lot of ways that random 3rd parties can end up sending mail claiming to be from a user of a domain whose SPF maintainers cannot predict them. I don't like that, I think it is wrong and bad. However, it is my direct experience that fighting that practice is a consistently losing battle because the practice rarely fails, is easily accommodated, and is attractive to those who engage in it because it lets them completely abdicate responsibility for the mail they generate and send. (I apologize for the overly complex sentences... ) > If 'SPF' and/or DKIM was standardised and rigourously enforced, then > return-path rewriting would be de rigeuer as would people learning how to > configure the mechanisms properly. This would require universal deployment of people designing and running mail systems who are almost entirely not stupid, evil, irresponsible, lazy, or even overworked. Good luck with that. If you figure out how to find clueful people in a reliable way, you can rule the world. In the real world, the result is not (as some have claimed here) that SPF is completely useless. It's just not a tool you can use without paying attention to its many failure modes and particularly the ones where ignorance and hubris are likely to cause trouble. The canonical example is to counter phishing, where the sender domain is not used by random human users and legitimate sources are actually known. The next most commonly cited example is to recognize SPF records that consist of "-all" as the only element, stating that there is no such thing as legitimate mail from the domain. Stranger uses can be based on the recognition that there are spammers who know about SPF and about simple spam filtering techniques; being "too good" while being "very new" is a sign that a sender is a spammer, and an affirmative SPF result can be a "tell." (yes, I have SA meta-rules, no, I'm not sharing) If there is a general rule, it is that SPF's uses require a sender domain (good or bad) whose admins understand SPF well. The bottom line is that SPF is actually useful as a small part of a spam control system, but not in the simplistic way that it was designed to be used or in ways that are practical for the giant providers of cheap/free mailboxes. If you want to use SPF to control spam, then you need to have someone skilled watching your mail stream. If you want to hand out cheap mailboxes to anyone who wanders by, you will not find SPF to be useful.