From asrg-bounces@ietf.org Fri Sep 01 00:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ0gr-0007nO-3A; Fri, 01 Sep 2006 00:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ0gp-0007nG-LJ for asrg@ietf.org; Fri, 01 Sep 2006 00:31:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ0gn-0005uZ-8a for asrg@ietf.org; Fri, 01 Sep 2006 00:31:35 -0400 Received: from [192.168.0.2] (adsl-68-122-238-32.dsl.pltn13.pacbell.net [68.122.238.32]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k814VVFa026805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 21:31:32 -0700 Message-ID: <44F7B788.9000809@dcrocker.net> Date: Thu, 31 Aug 2006 21:31:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Kaplan Subject: Re: [Asrg] A Technique for Universal Authentication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: asrg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Michael Kaplan wrote: > I have a design for a system that allows for universal email > authentication by improving upon an anti-spam concept that I introduced > earlier. Any email may be authenticated, including mail not > authenticated by existing schemes such as DKIM. This system does not > require email users to change their behavior. I sent a message to you and cc it to John Levine. What value is put into the rfc2822.from field, the subaddress for mail to you or the one for John Levine? Further, if it is the subaddress tailored for you, then I cannot receive a reply from John. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 00:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ0tV-00015M-OK; Fri, 01 Sep 2006 00:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ0tV-00015H-2S for asrg@ietf.org; Fri, 01 Sep 2006 00:44:41 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ0tT-0007C8-PU for asrg@ietf.org; Fri, 01 Sep 2006 00:44:41 -0400 Received: by py-out-1112.google.com with SMTP id e30so822621pya for ; Thu, 31 Aug 2006 21:44:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=SnzGY9QQJgU8OEq09cSxB0NkLgehxm2sKy7dSYXxDrjnA3HnSZXnDYRigtAwVk7QHibWSw0DmY6LmJAqHeiCF3OTtmDYmxxidD9YXSqfQ/5v7rh8yfK3QLmcNiv3/2T9bWppN0pOANm9ObLTI9Q5aXuINgkj6aV5eiSmb8Kv3lQ= Received: by 10.65.112.5 with SMTP id p5mr2225687qbm; Thu, 31 Aug 2006 21:44:06 -0700 (PDT) Received: by 10.65.107.2 with HTTP; Thu, 31 Aug 2006 21:44:06 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 00:44:06 -0400 From: "Michael Kaplan" To: dcrocker@bbiw.net Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: <44F7B788.9000809@dcrocker.net> MIME-Version: 1.0 References: <44F7B788.9000809@dcrocker.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: asrg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0809787391==" Errors-To: asrg-bounces@ietf.org --===============0809787391== Content-Type: multipart/alternative; boundary="----=_Part_56494_16491394.1157085846109" ------=_Part_56494_16491394.1157085846109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In your scenario a unique sub-address would be sent to myself and to John Levine, although it would also be quite acceptable to dispatch the same sub-address to each of us. Anyone can use any sub-address. You would receive John's email but as demonstrated in Figure 5 you would know that John replied to you using the sub-address that was originally sent to me. John would only need to use a sub-address if his email received a poor rating from a Bayesian filter. Michael Kaplan On 9/1/06, Dave Crocker wrote: > > > > Michael Kaplan wrote: > > I have a design for a system that allows for universal email > > authentication by improving upon an anti-spam concept that I introduced > > earlier. Any email may be authenticated, including mail not > > authenticated by existing schemes such as DKIM. This system does not > > require email users to change their behavior. > > > I sent a message to you and cc it to John Levine. > > What value is put into the rfc2822.from field, the subaddress for mail > to you or the one for John Levine? > > Further, if it is the subaddress tailored for you, then I cannot receive > a reply from John. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ------=_Part_56494_16491394.1157085846109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
In your scenario a unique sub-address would be sent to myself and to John Levine, although it would also be quite acceptable to dispatch the same sub-address to each of us.
 
Anyone can use any sub-address.  You would receive John's email but as demonstrated in Figure 5 you would know that John replied to you using the sub-address that was originally sent to me.
 
John would only need to use a sub-address if his email received a poor rating from a Bayesian filter.
 
Michael Kaplan

 
On 9/1/06, Dave Crocker <dhc@dcrocker.net> wrote:


Michael Kaplan wrote:
> I have a design for a system that allows for universal email
> authentication by improving upon an anti-spam concept that I introduced
> earlier.   Any email may be authenticated, including mail not
> authenticated by existing schemes such as DKIM.  This system does not
> require email users to change their behavior.


I sent a message to you and cc it to John Levine.

What value is put into the rfc2822.from field, the subaddress for mail
to you or the one for John Levine?

Further, if it is the subaddress tailored for you, then I cannot receive
a reply from John.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

------=_Part_56494_16491394.1157085846109-- --===============0809787391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0809787391==-- From asrg-bounces@ietf.org Fri Sep 01 01:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1Fy-00017j-H4; Fri, 01 Sep 2006 01:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1Fw-00017Y-H1 for asrg@ietf.org; Fri, 01 Sep 2006 01:07:52 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ1Fv-00016M-51 for asrg@ietf.org; Fri, 01 Sep 2006 01:07:52 -0400 Received: from [192.168.0.3] (adsl-68-122-238-32.dsl.pltn13.pacbell.net [68.122.238.32]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k81580cF032607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 22:08:01 -0700 Message-ID: <44F7C01A.6010200@dcrocker.net> Date: Thu, 31 Aug 2006 22:07:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Kaplan Subject: Re: [Asrg] A Technique for Universal Authentication References: <44F7B788.9000809@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: asrg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Michael Kaplan wrote: > In your scenario a unique sub-address would be sent to myself and to > John Levine, although it would also be quite acceptable to dispatch the > same sub-address to each of us. The main point of my questions was to raise the question of creating and tracking combinatorials, or else the problem of replies among groups. As the combinatorials of interaction increase, so will the complexity of keeping track of all the addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 01:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1ql-0003eZ-Ep; Fri, 01 Sep 2006 01:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1qk-0003eG-0q for asrg@ietf.org; Fri, 01 Sep 2006 01:45:54 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJ1qh-0003PB-N0 for asrg@ietf.org; Fri, 01 Sep 2006 01:45:53 -0400 Received: (qmail 13918 invoked from network); 1 Sep 2006 05:39:02 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 1 Sep 2006 05:39:02 -0000 Date: 1 Sep 2006 05:39:02 -0000 Message-ID: <20060901053902.53022.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >I have a design for a system that allows for universal email authentication >by improving upon an anti-spam concept that I introduced earlier. Per-correspondent subaddresses are a rather old idea. The idea was popularized by Zoemail in 2001 but it goes way back, at least as far as the CMU Andrew system in 1990 or 1991. All of the subaddress schemes appear to try to turn the spam problem into the introduction problem. That is, if we can recognize mail from people we already know, then we can do something more aggressive to mail from strangers like hashcash, C/R, or cranked up filters, and if a stranger jumps through our hoops, then add them to the list of known people. Recognizing mail from known correspondents is a very thoroughly solved problem. If I were doing it, I would use S/MIME, not because I am particularly fond of S/MIME, but because it is already implemented in all the popular MUAs, so you can skip the "if only the six largest mail vendors implemented it" stuff, they already do. But the spam problem is not the same as the introduction problem. They are somewhat related, since it is certainly true that people who have a history of sending non-spammy mail will probably continue to do so, but there's all sorts of real but complex situations that it doesn't deal with at all well, with discussion lists like this one leading the pack. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 11:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAnu-0002bV-1U; Fri, 01 Sep 2006 11:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAns-0002SA-3z for asrg@ietf.org; Fri, 01 Sep 2006 11:19:32 -0400 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAnq-0003Ah-CU for asrg@ietf.org; Fri, 01 Sep 2006 11:19:32 -0400 Received: by nz-out-0102.google.com with SMTP id q3so611780nzb for ; Fri, 01 Sep 2006 08:19:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=SLZp8RszWTYk8T1RXU1x245+fLpIOYayx/ApQNNA+s70ottcU2lIvUY99xWMzDnMA/16bkAu+Ov28+BzqzgQi7S438J5ECQ7SsNfVMsnHCS3u0ZMZ8YJNHWpXzCTyjNtVEUjyzdTLZWQWWicArviZCjeaJdD7pRxvoQAlsFow9Y= Received: by 10.64.143.12 with SMTP id q12mr558220qbd; Fri, 01 Sep 2006 08:19:27 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Fri, 1 Sep 2006 08:19:27 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 11:19:27 -0400 From: "Michael Kaplan" To: "John Levine" Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: <20060901053902.53022.qmail@simone.iecc.com> MIME-Version: 1.0 References: <20060901053902.53022.qmail@simone.iecc.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487880734==" Errors-To: asrg-bounces@ietf.org --===============1487880734== Content-Type: multipart/alternative; boundary="----=_Part_53033_24932278.1157123967628" ------=_Part_53033_24932278.1157123967628 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1 Sep 2006 05:39:02 -0000, John Levine wrote: > Recognizing mail from known correspondents is a very thoroughly solved > problem. I agree, yet my system is designed to recognize mail from unknown sources. Strangers will frequently send mail without using a sub-address. This mail will only get bounced if it receives a poor score via a filter. If the stranger is using a popular MUA then the bounce is resent and successfully received without either party being aware that it was bounced in the first place (assuming that the popular MUAs have updated their software). As a last resort the stranger can manually 'Reply' to the bounce if his MUA isn't updated. This situation, however, is unlikely as there is an amazingly minuscule number of popular MUAs. > But the spam problem is not the same as the introduction problem. They > are somewhat related, since it is certainly true that people who have a > history of sending non-spammy mail will probably continue to do so, > but there's all sorts of real but complex situations that it doesn't > deal with at all well, with discussion lists like this one leading > the pack. Again, updates by a minuscule number of MUAs effectively eliminates the introduction problem for this system. Discussion lists like this one would never face the introduction problem if the administrator used one of the popular MUAs (again assuming that the popular MUAs have updated their software). Regarding an earlier question of creating and tracking combinatorials: individual systems can decide for themselves if it is too complex to send multiple sub-addresses to the recipients of a group email. The efficacy of this system will not suffer much if only one sub-address is sent out with a group email. Tracking all of the sub-addresses does not strike me as a strenuous task in an age where we have email systems that hash every email. Michael ------=_Part_53033_24932278.1157123967628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 1 Sep 2006 05:39:02 -0000, John Levine <asrg@johnlevine.com> wrote:

 
Recognizing mail from known correspondents is a very thoroughly solved
problem.  
 
I agree, yet my system is designed to recognize mail from unknown sources.  Strangers will frequently send mail without using a sub-address.  This mail will only get bounced if it receives a poor score via a filter.  If the stranger is using a popular MUA then the bounce is resent and successfully received without either party being aware that it was bounced in the first place (assuming that the popular MUAs have updated their software). 
 
As a last resort the stranger can manually 'Reply' to the bounce if his MUA isn't updated.  This situation, however, is unlikely as there is an amazingly minuscule number of popular MUAs.

 
But the spam problem is not the same as the introduction problem.  They
are somewhat related, since it is certainly true that people who have a
history of sending non-spammy mail will probably continue to do so,
but there's all sorts of real but complex situations that it doesn't
deal with at all well, with discussion lists like this one leading
the pack.
 
Again, updates by a minuscule number of MUAs effectively eliminates the introduction problem for this system.  Discussion lists like this one would never face the introduction problem if the administrator used one of the popular MUAs (again assuming that the popular MUAs have updated their software).

 
 
Regarding an earlier question of creating and tracking combinatorials:  individual systems can decide for themselves if it is too complex to send multiple sub-addresses to the recipients of a group email.  The efficacy of this system will not suffer much if only one sub-address is sent out with a group email.  Tracking all of the sub-addresses does not strike me as a strenuous task in an age where we have email systems that hash every email.
 
Michael
 
------=_Part_53033_24932278.1157123967628-- --===============1487880734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1487880734==-- From asrg-bounces@ietf.org Fri Sep 01 11:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBHQ-0006sc-R9; Fri, 01 Sep 2006 11:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBHQ-0006sX-83 for asrg@ietf.org; Fri, 01 Sep 2006 11:50:04 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJBHN-0006C4-UC for asrg@ietf.org; Fri, 01 Sep 2006 11:50:04 -0400 Received: (qmail 12658 invoked from network); 1 Sep 2006 15:50:01 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 1 Sep 2006 15:50:01 -0000 Date: 1 Sep 2006 15:50:01 -0000 Message-ID: <20060901155001.1479.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >> Recognizing mail from known correspondents is a very thoroughly solved >> problem. >I agree, yet my system is designed to recognize mail from unknown sources. I don't see you proposing anything that S/MIME doesn't do better. If you S/MIME sign all your mail, each message has the key that recipients need to recognize future mail from you, and existing MUA address books already support it. >> But the spam problem is not the same as the introduction problem. ... >Again, updates by a minuscule number of MUAs effectively eliminates the >introduction problem for this system. Discussion lists like this one would >never face the introduction problem if the administrator used one of the >popular MUAs Right, so if I am a spammer, I need only subscribe to high-traffic lists, collect the subaddresses as they come by, and then blast away. > Tracking all of the sub-addresses does not strike me as a > strenuous task in an age where we have email systems that hash every email. This might be a good time to review the difference between O(N) and O(N^2). Incidentally, if you think this is such a good idea, why don't you write a Thunderbird add-in to support it? It's all open source, you know. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 14:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJE25-0001TM-66; Fri, 01 Sep 2006 14:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJE24-0001TH-3M for asrg@ietf.org; Fri, 01 Sep 2006 14:46:24 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJE22-0002Sp-PE for asrg@ietf.org; Fri, 01 Sep 2006 14:46:24 -0400 Received: by nz-out-0102.google.com with SMTP id q3so655251nzb for ; Fri, 01 Sep 2006 11:46:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gG0zdmrq62eyhU8zlxf1ALz8ljFh+DkN0Qqll8C2wQ73nMBQkBNAA6zCwnRPs4CWKNWyjqHktu6eSkXLL+bd2mNlZSvWc4KogaYvDsD/OIiyWK8fAyzSum2JOxQBZ8+LmQzc7Gx5PGiHbmz5P211KpAKaexWJD8PvA7jKVU65ko= Received: by 10.65.160.7 with SMTP id m7mr859974qbo; Fri, 01 Sep 2006 11:46:22 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Fri, 1 Sep 2006 11:46:21 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 14:46:21 -0400 From: "Michael Kaplan" To: "John Levine" Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: <20060901155001.1479.qmail@simone.iecc.com> MIME-Version: 1.0 References: <20060901155001.1479.qmail@simone.iecc.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965523575==" Errors-To: asrg-bounces@ietf.org --===============1965523575== Content-Type: multipart/alternative; boundary="----=_Part_56326_9855577.1157136381957" ------=_Part_56326_9855577.1157136381957 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1 Sep 2006 15:50:01 -0000, John Levine wrote: > > >> Recognizing mail from known correspondents is a very thoroughly solved > >> problem. > > >I agree, yet my system is designed to recognize mail from unknown > sources. > > I don't see you proposing anything that S/MIME doesn't do better. If > you S/MIME sign all your mail, each message has the key that > recipients need to recognize future mail from you, and existing MUA > address books already support it. I will illustrate by example. You receive an email from a stranger. As is often the case the email is not authenticated by DKIM or Sender ID, it isn't S/MIME signed, and it isn't using a sub-address. Your filter rates this email as having an intermediate risk for being spam. Under my system this email would be bounced back to the sender along with a sub-address. The sender's MUA will likely be updated to resend this bounce, but if it isn't then all is not lost as the sender has the opportunity to manually resend the bounce. The stranger's email is now authenticated. I don't think that S/MIME is able to reproduce these functions. >> But the spam problem is not the same as the introduction problem. ... > > >Again, updates by a minuscule number of MUAs effectively eliminates the > >introduction problem for this system. Discussion lists like this one > would > >never face the introduction problem if the administrator used one of the > >popular MUAs > > Right, so if I am a spammer, I need only subscribe to high-traffic lists, > collect the subaddresses as they come by, and then blast away. Life would be good if I knew that all of the spam I received was the result of my belonging to a single discussion list. I might demand that the list operator not publicly disclose any of my sub-addresses. There are many other viable ways to address the continued harvesting of emails from a single clearly identified source. The list operator may find his domain on the suspicious list if he continually supplies spammers with sub-addresses. Michael ------=_Part_56326_9855577.1157136381957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 1 Sep 2006 15:50:01 -0000, John Levine <asrg@johnlevine.com> wrote:
>> Recognizing mail from known correspondents is a very thoroughly solved
>> problem.

>I agree, yet my system is designed to recognize mail from unknown sources.

I don't see you proposing anything that S/MIME doesn't do better.  If
you S/MIME sign all your mail, each message has the key that
recipients need to recognize future mail from you, and existing MUA
address books already support it.
 
 
I will illustrate by example.  You receive an email from a stranger.  As is often the case the email is not authenticated by DKIM or Sender ID, it isn't S/MIME signed, and it isn't using a sub-address.  Your filter rates this email as having an intermediate risk for being spam.
 
Under my system this email would be bounced back to the sender along with a sub-address.  The sender's MUA will likely be updated to resend this bounce, but if it isn't then all is not lost as the sender has the opportunity to manually resend the bounce.  The stranger's email is now authenticated.  I don't think that S/MIME is able to reproduce these functions.

>> But the spam problem is not the same as the introduction problem. ...

>Again, updates by a minuscule number of MUAs effectively eliminates the
>introduction problem for this system.  Discussion lists like this one would
>never face the introduction problem if the administrator used one of the
>popular MUAs

Right, so if I am a spammer, I need only subscribe to high-traffic lists,
collect the subaddresses as they come by, and then blast away.
 
Life would be good if I knew that all of the spam I received was the result of my belonging to a single discussion list.  I might demand that the list operator not publicly disclose any of my sub-addresses.  There are many other viable ways to address the continued harvesting of emails from a single clearly identified source.  The list operator may find his domain on the suspicious list if he continually supplies spammers with sub-addresses.
 
 
Michael
------=_Part_56326_9855577.1157136381957-- --===============1965523575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1965523575==-- From asrg-bounces@ietf.org Fri Sep 01 15:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJF1J-0003I2-45; Fri, 01 Sep 2006 15:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJF1H-0003Hw-HE for asrg@ietf.org; Fri, 01 Sep 2006 15:49:39 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJF1G-0006Wu-A5 for asrg@ietf.org; Fri, 01 Sep 2006 15:49:39 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1191333wxc for ; Fri, 01 Sep 2006 12:49:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MZ3pSXrS5z344miv+RH9WDDR1ajMVVGJ5Qh7Moshob7zGVX1LpN8caFGgwG88nPB36Rz0G+heIpTYVWXmSxxIVcbvVFwv75NwNLownWG7NxVhP3RFsROJEQ7g5NsSsVzArSosZNiA6Wdn3gkoEV8XlZDZ5ygx7tEhwQE5aXtxB0= Received: by 10.90.100.2 with SMTP id x2mr835415agb; Fri, 01 Sep 2006 12:49:37 -0700 (PDT) Received: by 10.90.105.8 with HTTP; Fri, 1 Sep 2006 12:49:37 -0700 (PDT) Message-ID: <934f64a20609011249uc60ace7g720beaf1e1c2c5e@mail.gmail.com> Date: Fri, 1 Sep 2006 14:49:37 -0500 From: "David Nicol" To: "Michael Kaplan" Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060901155001.1479.qmail@simone.iecc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9/1/06, Michael Kaplan wrote: > I will illustrate by example. You receive an email from a stranger. As is > often the case the email is not authenticated by DKIM or Sender ID, it isn't > S/MIME signed, and it isn't using a sub-address. Your filter rates this > email as having an intermediate risk for being spam. > > Under my system this email would be bounced back to the sender along with a > sub-address. The sender's MUA will likely be updated to resend this bounce, > but if it isn't then all is not lost as the sender has the opportunity to > manually resend the bounce. The stranger's email is now authenticated. I > don't think that S/MIME is able to reproduce these functions. A shared centralized challenge-response system, which could be the beginning of the reputation infrastructure that gets talked about here, would do the same thing with fewer steps for the senders and no software upgrades required. As I understand it, any proposal that requires some kind of zero-day during which everyone on the internet is mandated to upgrade their MUAs in order for it to work is a non-starter. Is your work a step towards a distributable reputation infrastructure? Please refer to http://www.rhyolite.com/anti-spam/you-might-be.html _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 16:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFU3-0004pT-Jf; Fri, 01 Sep 2006 16:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFU2-0004pL-FX for asrg@ietf.org; Fri, 01 Sep 2006 16:19:22 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJFU1-0008WR-6f for asrg@ietf.org; Fri, 01 Sep 2006 16:19:22 -0400 Received: (qmail 5070 invoked from network); 1 Sep 2006 20:19:18 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 1 Sep 2006 20:19:18 -0000 Date: 1 Sep 2006 20:19:18 -0000 Message-ID: <20060901201918.67795.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >> >> Recognizing mail from known correspondents is a very thoroughly solved >> >> problem. >> >> >I agree, yet my system is designed to recognize mail from unknown >> sources. It's the same problem -- the mail that's not from known correspondents is from unknown sources. >I don't think that S/MIME is able to reproduce these functions. S/MIME recognizes the known corrspondents. You've added on a C/R layer for everyone else. See the ASRG archives for lengthy discussions of all the reasons that C/R is a bad idea. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 16:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFb4-0004e6-EW; Fri, 01 Sep 2006 16:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFb3-0004Z9-J3 for asrg@ietf.org; Fri, 01 Sep 2006 16:26:37 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJFb2-0000Td-AX for asrg@ietf.org; Fri, 01 Sep 2006 16:26:37 -0400 Received: (qmail 13647 invoked from network); 1 Sep 2006 20:26:36 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 1 Sep 2006 20:26:36 -0000 Date: 1 Sep 2006 20:26:36 -0000 Message-ID: <20060901202636.69584.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: [Asrg] About that anti-spam taxonomy Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org A little while ago I suggested the ASRG work on a taxonomy of anti-spam techniques, to give a common vocabulary and a common place to collect knowledge about them. The current discussion about yet another anti-spam proposal would be a lot quicker if we could say you're proposing PER-CORRESPONDENT ADDRESS combined with CHALLENGE/RESPONSE, apparently the subflavor MUA AUTO-RESPONSE. Anyone else interested in working on it? I'd start by trying to map out the major areas of approach, e.g., identity, path, and contents, then see what fits in each area. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 16:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJG4K-0004MG-3r; Fri, 01 Sep 2006 16:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJG4J-0004M7-3A for asrg@ietf.org; Fri, 01 Sep 2006 16:56:51 -0400 Received: from nz-out-0102.google.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJG4H-00027o-NX for asrg@ietf.org; Fri, 01 Sep 2006 16:56:51 -0400 Received: by nz-out-0102.google.com with SMTP id q3so676179nzb for ; Fri, 01 Sep 2006 13:56:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=I04FXdzkoikPaf76ds4QlXTMP+pBJkvl6T2JCnD/rJ1Zlx04fWrSpkbmHLjYpXRD21mx6KjJw0a2bbISvy5gooEpqhPTeQ2josGMpv2GCrjC9NTSn03/8sOzpEgnvmbzzFiFBVr44KRCTUMdJAQvOQOeZ7rr3DqXi1Z4IvwxW2M= Received: by 10.65.139.9 with SMTP id r9mr994251qbn; Fri, 01 Sep 2006 13:56:49 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Fri, 1 Sep 2006 13:56:48 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 16:56:48 -0400 From: "Michael Kaplan" To: "David Nicol" Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: <934f64a20609011249uc60ace7g720beaf1e1c2c5e@mail.gmail.com> MIME-Version: 1.0 References: <20060901155001.1479.qmail@simone.iecc.com> <934f64a20609011249uc60ace7g720beaf1e1c2c5e@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362577751==" Errors-To: asrg-bounces@ietf.org --===============1362577751== Content-Type: multipart/alternative; boundary="----=_Part_57602_2065570.1157144208927" ------=_Part_57602_2065570.1157144208927 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/1/06, David Nicol wrote: > > On 9/1/06, Michael Kaplan < michaelkaplanasrg@gmail.com > wrote: > > I will illustrate by example. You receive an email from a stranger. As > is > > often the case the email is not authenticated by DKIM or Sender ID, it > isn't > > S/MIME signed, and it isn't using a sub-address. Your filter rates this > > > email as having an intermediate risk for being spam. > > > > Under my system this email would be bounced back to the sender along > with a > > sub-address. The sender's MUA will likely be updated to resend this > bounce, > > but if it isn't then all is not lost as the sender has the opportunity > to > > manually resend the bounce. The stranger's email is now > authenticated. I > > don't think that S/MIME is able to reproduce these functions. > > A shared centralized challenge-response system, which could be the > beginning > of the reputation infrastructure that gets talked about here, would do the > same > thing with fewer steps for the senders and no software upgrades required. > > As I understand it, any proposal that requires some kind of zero-day > during which > everyone on the internet is mandated to upgrade their MUAs in order for it > to work is a non-starter. This proposal does not require any kind of zero-day. It combines the advantages of a Bayesian filter and a sub-address based email system to ensure that challenges are only seen sent for a small fraction of legitimate mail. Updating the MUAs is only essential to make this system universally transparent. Ideally it would be great if the 10 largest MUA developers made this rather simplistic upgrade, then maybe a year later this system would be deployed. This system would not be a C/R system for any of the vast majority of people with an updated MUA. It would not be a C/R system for anyone sending non-spammy email. Again, I contrast the tremendous ease of deploying Auto-Reply software with the impossible task of the near universal deployment of DKIM or SPF. The challenge will only apply to the ever diminishing number of emails that fall through the cracks. C/R systems are not desirable, but I argue that there comes a point where if the challenge becomes so infrequent (1 out of 200 legit email?) that the undesirability of C/R fades along with the appropriateness of calling it C/R. The question is can this system block spam and make challenges so infrequent that we have reached the point where it is desirable. Michael ------=_Part_57602_2065570.1157144208927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/1/06, David Nicol <davidnicol@gmail.com > wrote:
On 9/1/06, Michael Kaplan < michaelkaplanasrg@gmail.com > wrote:
> I will illustrate by example.  You receive an email from a stranger.  As is
> often the case the email is not authenticated by DKIM or Sender ID, it isn't
> S/MIME signed, and it isn't using a sub-address.  Your filter rates this
> email as having an intermediate risk for being spam.
>
> Under my system this email would be bounced back to the sender along with a
> sub-address.  The sender's MUA will likely be updated to resend this bounce,
> but if it isn't then all is not lost as the sender has the opportunity to
> manually resend the bounce.  The stranger's email is now authenticated.  I
> don't think that S/MIME is able to reproduce these functions.

A shared centralized challenge-response system, which could be the beginning
of the reputation infrastructure that gets talked about here, would do the same
thing with fewer steps for the senders and no software upgrades required.

As I understand it, any proposal that requires some kind of zero-day
during which
everyone on the internet is mandated to upgrade their MUAs in order for it
to work is a non-starter.
 
This proposal does not require any kind of zero-day.  It combines the advantages of a Bayesian filter and a sub-address based email system to ensure that challenges are only seen sent for a small fraction of legitimate mail.  Updating the MUAs is only essential to make this system universally transparent.
 
Ideally it would be great if the 10 largest MUA developers made this rather simplistic upgrade, then maybe a year later this system would be deployed.  This system would not be a C/R system for any of the vast majority of people with an updated MUA.  It would not be a C/R system for anyone sending non-spammy email.
 
Again, I contrast the tremendous ease of deploying Auto-Reply software with the impossible task of the near universal deployment of DKIM or SPF.  The challenge will only apply to the ever diminishing number of emails that fall through the cracks. 
 
C/R systems are not desirable, but I argue that there comes a point where if the challenge becomes so infrequent (1 out of 200 legit email?) that the undesirability of C/R fades along with the appropriateness of calling it C/R.  The question is can this system block spam and make challenges so infrequent that we have reached the point where it is desirable.
 
Michael
 
------=_Part_57602_2065570.1157144208927-- --===============1362577751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1362577751==-- From asrg-bounces@ietf.org Fri Sep 01 17:33:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGcR-0008QO-Ty; Fri, 01 Sep 2006 17:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJGcR-0008Pe-4b for asrg@ietf.org; Fri, 01 Sep 2006 17:32:07 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJGcM-0004nF-JU for asrg@ietf.org; Fri, 01 Sep 2006 17:32:07 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GJGc9-0008TH-Qc for asrg@ietf.org; Fri, 01 Sep 2006 23:31:49 +0200 Received: from pd9fba91d.dip0.t-ipconnect.de ([217.251.169.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Sep 2006 23:31:49 +0200 Received: from nobody by pd9fba91d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Sep 2006 23:31:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Fri, 01 Sep 2006 23:27:59 +0200 Organization: Lines: 14 Message-ID: <44F8A5DF.74B5@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba91d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Asrg] Re: A Technique for Universal Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Michael Kaplan wrote: > I will illustrate by example. You receive an email from a > stranger. As is often the case the email is not authenticated > by DKIM or Sender ID, it isn't S/MIME signed, and it isn't > using a sub-address. Your filter rates this email as having > an intermediate risk for being spam. Under my system this > email would be bounced back to the sender That's technically impossible, unless you forgot to mention that it had an SPF PASS. Otherwise you participate with over 95% probability in DDoS or other net abuse, sending mails to innocent bystanders. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 18:19:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJHJx-0003bS-J8; Fri, 01 Sep 2006 18:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJHJv-0003bK-Sd for asrg@ietf.org; Fri, 01 Sep 2006 18:17:03 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJHJu-0007ik-Mk for asrg@ietf.org; Fri, 01 Sep 2006 18:17:03 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1237007wxc for ; Fri, 01 Sep 2006 15:17:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X/6kFBuZZzolBhQBnINxfogiOqU2nphZRdhU3ds0xb/6wc8Ub8s2lx3cM0SNx/fa3vRxOtqcLN/gCCYtY6yi6CfurF8rHoFaJTdywxMAXuLAwHS2SZBMhydI+eh3ooeqU1c/QWaA5I4OMKIN0fPwyFSunv9nkRBkKce2Xm3w2Ss= Received: by 10.90.54.4 with SMTP id c4mr914397aga; Fri, 01 Sep 2006 15:17:02 -0700 (PDT) Received: by 10.90.105.8 with HTTP; Fri, 1 Sep 2006 15:17:02 -0700 (PDT) Message-ID: <934f64a20609011517y59fedcbcqbebb689fc0f92c69@mail.gmail.com> Date: Fri, 1 Sep 2006 17:17:02 -0500 From: "David Nicol" To: "John Levine" Subject: Re: [Asrg] About that anti-spam taxonomy In-Reply-To: <20060901202636.69584.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060901202636.69584.qmail@simone.iecc.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 1 Sep 2006 20:26:36 -0000, John Levine wrote: > The current discussion about yet another anti-spam proposal would be a > lot quicker if we could say you're proposing PER-CORRESPONDENT ADDRESS > combined with CHALLENGE/RESPONSE, apparently the subflavor MUA > AUTO-RESPONSE. > > Anyone else interested in working on it? I'd start by trying to map > out the major areas of approach, e.g., identity, path, and contents, > then see what fits in each area. > > R's, > John the FUSSP anti-spam kook page would be a good place to start, as it seems pretty comprehensive, although dismissive. That is, the task at hand could be redefined to going through the person types listed on the page and rewriting the proposals implied in a more serious tone. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Sep 01 21:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJKUz-0001KP-GW; Fri, 01 Sep 2006 21:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJKUx-0001Et-1v for asrg@ietf.org; Fri, 01 Sep 2006 21:40:39 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJKUs-0007wE-NE for asrg@ietf.org; Fri, 01 Sep 2006 21:40:39 -0400 Received: by py-out-1112.google.com with SMTP id e30so1147835pya for ; Fri, 01 Sep 2006 18:39:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eFSlBBdzyp+slp1FkHi/wkl3UAEA5Tfxg6+kHaeo83X/tONn7qV6ieKWvwkKjnLp8XsOz3rxTfFSjliCreCTFC6uZSM/jN7E9SaT/2ck4BSqqJfHuv+xRrHuYoAhOySldv/Ouuw076vtQoeh9CANJD29E409x+iOtghpS34YB6s= Received: by 10.65.114.11 with SMTP id r11mr3416249qbm; Fri, 01 Sep 2006 18:39:59 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Fri, 1 Sep 2006 18:39:58 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 21:39:59 -0400 From: "Michael Kaplan" To: "Frank Ellermann" Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <44F8A5DF.74B5@xyzzy.claranet.de> MIME-Version: 1.0 References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0090120807==" Errors-To: asrg-bounces@ietf.org --===============0090120807== Content-Type: multipart/alternative; boundary="----=_Part_59590_25566951.1157161199030" ------=_Part_59590_25566951.1157161199030 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/1/06, Frank Ellermann wrote: > > Michael Kaplan wrote: > > > I will illustrate by example. You receive an email from a > > stranger. As is often the case the email is not authenticated > > by DKIM or Sender ID, it isn't S/MIME signed, and it isn't > > using a sub-address. Your filter rates this email as having > > an intermediate risk for being spam. Under my system this > > email would be bounced back to the sender > > That's technically impossible, unless you forgot to mention > that it had an SPF PASS. Otherwise you participate with over > 95% probability in DDoS or other net abuse, sending mails to > innocent bystanders. Your argument is not unique to my proposal but it is directed against all bounces, vacation messages, etc. It is certainly not technically impossible, but I assume you mean undesirable. Existing methods such as BATV can easily protect mail systems from this problem. The Auto-Reply update to MUAs will block erroneous bounces for almost the entire global email population. It is highly unlikely that email with an SPF PASS would get bounced. The receipt of erroneous bounces would annoy some (mostly victims of Joe jobs) but, ironically, it would accelerate the adoption of BATV and the Auto-Reply update for MUAs. I suggest that when debating an anti-spam proposal we should answer questions in a certain order: 1st - If implemented will it actually stop spam? 2nd - Is it practical to implement? 3rd - Is it unacceptably burdensome to the sender/recipient? 4th - Is it unacceptably burdensome to third parties? Thank you for your input, Michael ------=_Part_59590_25566951.1157161199030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/1/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Michael Kaplan wrote:

> I will illustrate by example. You receive an email from a
> stranger. As is often the case the email is not authenticated
> by DKIM or Sender ID, it isn't S/MIME signed, and it isn't
> using a sub-address. Your filter rates this email as having
> an intermediate risk for being spam. Under my system this
> email would be bounced back to the sender

That's technically impossible, unless you forgot to mention
that it had an SPF PASS.  Otherwise you participate with over
95% probability in DDoS or other net abuse, sending mails to
innocent bystanders.
 
Your argument is not unique to my proposal but it is directed against all bounces, vacation messages, etc.  It is certainly not technically impossible, but I assume you mean undesirable.  Existing methods such as BATV can easily protect mail systems from this problem.  The Auto-Reply update to MUAs will block erroneous bounces for almost the entire global email population. 
 
It is highly unlikely that email with an SPF PASS would get bounced.
 
The receipt of erroneous bounces would annoy some (mostly victims of Joe jobs) but, ironically, it would accelerate the adoption of BATV and the Auto-Reply update for MUAs.
 
I suggest that when debating an anti-spam proposal we should answer questions in a certain order:
1st - If implemented will it actually stop spam?
2nd - Is it practical to implement?
3rd - Is it unacceptably burdensome to the sender/recipient?
4th - Is it unacceptably burdensome to third parties?
 
Thank you for your input,
Michael
------=_Part_59590_25566951.1157161199030-- --===============0090120807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0090120807==-- From asrg-bounces@ietf.org Fri Sep 01 22:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJLPk-0006tO-Fc; Fri, 01 Sep 2006 22:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJLPj-0006tJ-7f for asrg@ietf.org; Fri, 01 Sep 2006 22:39:19 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJLPg-0003v8-U3 for asrg@ietf.org; Fri, 01 Sep 2006 22:39:19 -0400 Received: (qmail 26283 invoked from network); 2 Sep 2006 02:39:15 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 2 Sep 2006 02:39:15 -0000 Date: 2 Sep 2006 02:39:15 -0000 Message-ID: <20060902023915.53378.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -2.2 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >Your argument is not unique to my proposal but it is directed against >all bounces, vacation messages, etc. Right. You don't want to send a response unless you know a message isn't spam, but if you already know it's not spam, there isn't much point in sending a C/R challenge, is there? Incidentally, it occurs to me that S/MIME addresses the introduction problem at least as well as your hack. Remember that S/MIME uses hierarchical signed certificates just like SSL, and MUAs typically have a list of well-known S/MIME signers just like the list of well known SSL signers, more often than not the same list. All of the signers make some desultory effort to ensure that that they only sign certs that belong to the address on the cert, typically by mailing out a token that you need to use to claim your cert. Anyone with a signed cert has jumped through a hoop at least as difficult as responding to a C/R challenge. If you whitelist all mail with signed certs, and tell people to get an S/MIME cert if they want to talk to you (they're free, after all), that solves the same problems as your scheme, with added benefits of preventing snooping in transit in the common case that the sender knows your cert, too. And it's already available in Outlook, Outlook Express, Eudora, Thunderbird, and probably lots of other MUAs I haven't looked at. What are you waiting for? > Existing methods such as BATV can easily protect mail systems from > this problem. The Auto-Reply update to MUAs will block erroneous > bounces for almost the entire global email population. You keep waving your hands and assuming that everyone will implement your stuff. I think BATV is swell, and I've been running it longer than anyone else, but I am under no illusions about how slow its uptake has been. If I were king and could demand that everyone in the world implement my favorite mail hacks, I would mandate a whole lot more interesting stuff than some subaddresses and C/R challenges. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Sep 02 00:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJNHS-0004Sa-1W; Sat, 02 Sep 2006 00:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJNHQ-0004P8-76 for asrg@ietf.org; Sat, 02 Sep 2006 00:38:52 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJNHM-00048h-0q for asrg@ietf.org; Sat, 02 Sep 2006 00:38:52 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1331010wxc for ; Fri, 01 Sep 2006 21:38:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HJbwCmHbtMRFxtwPDbJwQQ7Dq0/h6zJDz7LZ1FD9boZBHbe3seIJ7MCXX+tNJ9C48uj7sxo8WLIAgfTp60wkdQtqRN8PHmBtwTV7PnuxXpwCZlRu5NAriv4FH+GadkXC/NgHvU7UiOcxeVWSJugFAjs8+vaAGkZ+UHGhZdhNGFA= Received: by 10.90.50.6 with SMTP id x6mr922453agx; Fri, 01 Sep 2006 21:38:45 -0700 (PDT) Received: by 10.90.105.8 with HTTP; Fri, 1 Sep 2006 21:38:45 -0700 (PDT) Message-ID: <934f64a20609012138k27ecde4exa6c36b5dcafa690b@mail.gmail.com> Date: Fri, 1 Sep 2006 23:38:45 -0500 From: "David Nicol" To: "anti-spam research group" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Asrg] more thoughts on SSP taxonomy X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org http://www.davidnicol.com/ASRG/taxonomyrant060901.html $> wc taxonomyrant060901.html 163 1308 8200 taxonomyrant060901.html -- Although efforts are under way to mitigate the problem, this message may contain flippancy, hyperbole and/or confusing assertions. Please reply directly to fall2006sigfile@davidnicol.com for clarification of any points appearing unclear, vague, cruel, frustrating, threatening, negative, dilletantish or otherwise unprofessional before taking action based on misintepretation or misconstruction of such points. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Sep 02 01:36:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJO9t-0006vT-2k; Sat, 02 Sep 2006 01:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJO9r-0006uB-5c for asrg@ietf.org; Sat, 02 Sep 2006 01:35:07 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJO9q-0001sI-Nd for asrg@ietf.org; Sat, 02 Sep 2006 01:35:07 -0400 Received: by py-out-1112.google.com with SMTP id e30so1205157pya for ; Fri, 01 Sep 2006 22:35:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=s9BWpykhZiXHugFfr5sdeaY+fnbyqQ9bZVPmgfcbJamZ9YeH5BqSLUjjdpwWb6NH3Ar5r/IT/zLj7i2qbjg+gI/NkY6wsni6dhyUf5XPLpHI3uVtHiD/j9hVahfxeIeWmOL0nWl0FZ+zHaK92uuEq/Ubt/hQRwVnLMW0S7oBxjI= Received: by 10.65.154.10 with SMTP id g10mr2502518qbo; Fri, 01 Sep 2006 22:35:06 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Fri, 1 Sep 2006 22:35:06 -0700 (PDT) Message-ID: Date: Sat, 2 Sep 2006 01:35:06 -0400 From: "Michael Kaplan" To: "John Levine" Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <20060902023915.53378.qmail@simone.iecc.com> MIME-Version: 1.0 References: <20060902023915.53378.qmail@simone.iecc.com> X-Spam-Score: 2.6 (++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1587982941==" Errors-To: asrg-bounces@ietf.org --===============1587982941== Content-Type: multipart/alternative; boundary="----=_Part_60926_29780464.1157175306130" ------=_Part_60926_29780464.1157175306130 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 2 Sep 2006 02:39:15 -0000, John Levine wrote: > > >Your argument is not unique to my proposal but it is directed against > >all bounces, vacation messages, etc. > > Right. You don't want to send a response unless you know a message > isn't spam, but if you already know it's not spam, there isn't much > point in sending a C/R challenge, is there? My website states that the bounce would only be sent to email that has an intermediate risk of being spam. Incidentally, it occurs to me that S/MIME addresses the introduction > problem at least as well as your hack. Remember that S/MIME uses > hierarchical signed certificates just like SSL, and MUAs typically > have a list of well-known S/MIME signers just like the list of well > known SSL signers, more often than not the same list. All of the > signers make some desultory effort to ensure that that they only sign > certs that belong to the address on the cert, typically by mailing out > a token that you need to use to claim your cert. > > Anyone with a signed cert has jumped through a hoop at least as > difficult as responding to a C/R challenge. If you whitelist all mail > with signed certs, and tell people to get an S/MIME cert if they want > to talk to you (they're free, after all), that solves the same > problems as your scheme, with added benefits of preventing snooping in > transit in the common case that the sender knows your cert, too. And > it's already available in Outlook, Outlook Express, Eudora, > Thunderbird, and probably lots of other MUAs I haven't looked at. > What are you waiting for? I support any means by which MUAs can be used to authenticate email, and it would be fantastic to see S/MIME signing. Obviously any signed email would almost certainly bypass the need for a challenge and successfully reach the inbox. There are two main reasons why I promote issuing bounces with sub-addresses as described on my site: 1) Multiple senders can use the same sub-address thus reducing the frequency with which bounces are issued. I can send an email to support@business.combut I may get a reply from manager@business.com. Manager@business.com is a stranger yet the his email will almost certainly reach my inbox unimpeded as he is using the valid sub-address issued to Support. As my site states "Experience with other sub-address generating systems suggests that 90-97% of all legitimate email uses a sub-address that is not used by spammers." Spammers will acquire only a fraction of issued sub-addresses. My system is not identical to other sub-address based systems but the principle is the same. A single one of my sub-address can be forwarded to multiple strangers who can use it to email me. It is highly unlikely that emails from these strangers will generate a bounce. 2) Correspondents with MUAs that lack Auto-Reply can manually resend the bounce, thus authenticating their email. There is no zero-day when every single MUA in the world must be updated for this system to work. This system can authenticate every email from day one. The level of participation for MUAs only effects the transparency of this system. So S/MIME is good, but I'm not sure that it can substitute the above. I'm also not sure how the mechanism of "tell people to get an S/MIME cert if they want to talk to you" would work. C/R systems are extraordinarily effective at eliminating spam yet they are equally annoying. I've tried to preserve as much of efficacy of C/R as possible and yet with a combination of Bayesian filters, sub-addresses, and Auto-Reply I've tried to produce a system that will challenge so infrequently that its deployment is justified. A respectable Bayesian filter might have a 0.5% false positive rate. Under this system 0.5% of correspondents might see a bounce/challenge while almost completely eliminating spam. If this were to happen then the annoyance of this "C/R" system would certainly be less than the status quo. Thank you for your input, Michael ------=_Part_60926_29780464.1157175306130 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 2 Sep 2006 02:39:15 -0000, John Levine <asrg@johnlevine.com> wrote:
>Your argument is not unique to my proposal but it is directed against
>all bounces, vacation messages, etc.

Right.  You don't want to send a response unless you know a message
isn't spam, but if you already know it's not spam, there isn't much
point in sending a C/R challenge, is there?
 
My website states that the bounce would only be sent to email that has an intermediate risk of being spam.
 

Incidentally, it occurs to me that S/MIME addresses the introduction
problem at least as well as your hack.  Remember that S/MIME uses
hierarchical signed certificates just like SSL, and MUAs typically
have a list of well-known S/MIME signers just like the list of well
known SSL signers, more often than not the same list.  All of the
signers make some desultory effort to ensure that that they only sign
certs that belong to the address on the cert, typically by mailing out
a token that you need to use to claim your cert.

Anyone with a signed cert has jumped through a hoop at least as
difficult as responding to a C/R challenge.  If you whitelist all mail
with signed certs, and tell people to get an S/MIME cert if they want
to talk to you (they're free, after all), that solves the same
problems as your scheme, with added benefits of preventing snooping in
transit in the common case that the sender knows your cert, too.  And
it's already available in Outlook, Outlook Express, Eudora,
Thunderbird, and probably lots of other MUAs I haven't looked at.
What are you waiting for?
 
I support any means by which MUAs can be used to authenticate email, and it would be fantastic to see S/MIME signing.  Obviously any signed email would almost certainly bypass the need for a challenge and successfully reach the inbox.  There are two main reasons why I promote issuing bounces with sub-addresses as described on my site:
 
1) Multiple senders can use the same sub-address thus reducing the frequency with which bounces are issued.  I can send an email to support@business.com but I may get a reply from manager@business.com.  Manager@business.com is a stranger yet the his email will almost certainly reach my inbox unimpeded as he is using the valid sub-address issued to Support.  As my site states "Experience with other sub-address generating systems suggests that 90-97% of all legitimate email uses a sub-address that is not used by spammers."  Spammers will acquire only a fraction of issued sub-addresses.
 
My system is not identical to other sub-address based systems but the principle is the same.  A single one of my sub-address can be forwarded to multiple strangers who can use it to email me.  It is highly unlikely that emails from these strangers will generate a bounce.
 
2) Correspondents with MUAs that lack Auto-Reply can manually resend the bounce, thus authenticating their email.  There is no zero-day when every single MUA in the world must be updated for this system to work.  This system can authenticate every email from day one.  The level of participation for MUAs only effects the transparency of this system.
 
 
So S/MIME is good, but I'm not sure that it can substitute the above.  I'm also not sure how the mechanism of "tell people to get an S/MIME cert if they want to talk to you" would work.

 
C/R systems are extraordinarily effective at eliminating spam yet they are equally annoying.   I've tried to preserve as much of efficacy of C/R as possible and yet with a combination of Bayesian filters, sub-addresses, and Auto-Reply I've tried to produce a system that will challenge so infrequently that its deployment is justified.  A respectable Bayesian filter might have a 0.5% false positive rate.  Under this system 0.5% of correspondents might see a bounce/challenge while almost completely eliminating spam.  If this were to happen then the annoyance of this "C/R" system would certainly be less than the status quo.
 
Thank you for your input,
Michael
------=_Part_60926_29780464.1157175306130-- --===============1587982941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1587982941==-- From asrg-bounces@ietf.org Sat Sep 02 11:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJX7L-0002xb-NA; Sat, 02 Sep 2006 11:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJX7L-0002xW-9R for asrg@ietf.org; Sat, 02 Sep 2006 11:09:07 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJX7K-000216-1A for asrg@ietf.org; Sat, 02 Sep 2006 11:09:07 -0400 Received: by py-out-1112.google.com with SMTP id e30so1345005pya for ; Sat, 02 Sep 2006 08:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hy0Rp1c9yLA+RpvcbPGXmEV5RZNkmVzuygtny4jJTKca58L6o1fN2Ep9PYCO44aJC6EmKPGSm+kQT0nKzOed5QDxyQeR8OitjLXy9gC7MXoRT/BzZLelmZvZ8eRf67at9aHhLUke0jkuiD96j1Hz+4gkoJLi/JE5ILh+Sa4Pej0= Received: by 10.65.185.3 with SMTP id m3mr1484714qbp; Sat, 02 Sep 2006 08:09:05 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Sat, 2 Sep 2006 08:09:05 -0700 (PDT) Message-ID: Date: Sat, 2 Sep 2006 11:09:05 -0400 From: "Michael Kaplan" To: "Jeff Macdonald" Subject: Re: [Asrg] A Technique for Universal Authentication In-Reply-To: <20060902130103.GI18168@localhost.localdomain> MIME-Version: 1.0 References: <20060902130103.GI18168@localhost.localdomain> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: asrg X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0250967581==" Errors-To: asrg-bounces@ietf.org --===============0250967581== Content-Type: multipart/alternative; boundary="----=_Part_64707_1496278.1157209745440" ------=_Part_64707_1496278.1157209745440 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/2/06, Jeff Macdonald wrote: > > On Thu, Aug 31, 2006 at 11:43:25PM -0400, Michael Kaplan wrote: > > I have a design for a system that allows for universal email > > authentication by improving upon an anti-spam concept that I > introduced > > earlier. Any email may be authenticated, including mail not > > authenticated by existing schemes such as DKIM. This system does not > > require email users to change their behavior. > > > > > > > > [1]http://home.nyc.rr.com/spamsolution/UniversalAuthentication.htm > > So am I missing something, why doesn't a MTA/MDA need to be changed to > support sub-addresses? Isn't every sub-address a new mailbox? As with existing sub-address systems any network that wants to take advantage of this system (PER-CORRESPONDENT ADDRESS combined with CHALLENGE/RESPONSE subflavor MUA AUTO-RESPONSE as it has been called) will need to install it on an individual basis. My hope is that this system will be so effective and non-disruptive that an increasing number of mail systems will choose to implement it. When I said that this system "does not require email users to change their behavior" I was referring to the average user, not the system administrator who would obviously need to install it. Michael ------=_Part_64707_1496278.1157209745440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/2/06, Jeff Macdonald <jmacdonald@e-dialog.com> wrote:
On Thu, Aug 31, 2006 at 11:43:25PM -0400, Michael Kaplan wrote:
>    I have a design for a system that allows for universal email
>    authentication by improving upon an anti-spam concept that I introduced
>    earlier.   Any email may be authenticated, including mail not
>    authenticated by existing schemes such as DKIM.  This system does not
>    require email users to change their behavior.
>
>
>
>    [1]http://home.nyc.rr.com/spamsolution/UniversalAuthentication.htm

So am I missing something, why doesn't a MTA/MDA need to be changed to
support sub-addresses? Isn't every sub-address a new mailbox?
 
As with existing sub-address systems any network that wants to take advantage of this system (PER-CORRESPONDENT ADDRESS combined with CHALLENGE/RESPONSE subflavor MUA
AUTO-RESPONSE as it has been called)  will need to install it on an individual basis.  My hope is that this system will be so effective and non-disruptive that an increasing number of mail systems will choose to implement it.
 
When I said that this system "does not require email users to change their behavior" I was referring to the average user, not the system administrator who would obviously need to install it.
 
Michael
------=_Part_64707_1496278.1157209745440-- --===============0250967581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0250967581==-- From asrg-bounces@ietf.org Sat Sep 02 19:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJecE-0003vJ-Iz; Sat, 02 Sep 2006 19:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJecD-0003vE-IA for asrg@ietf.org; Sat, 02 Sep 2006 19:09:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJec8-0002I0-Tv for asrg@ietf.org; Sat, 02 Sep 2006 19:09:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GJebw-0000BV-0y for asrg@ietf.org; Sun, 03 Sep 2006 01:09:12 +0200 Received: from pd9fba93c.dip0.t-ipconnect.de ([217.251.169.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Sep 2006 01:09:12 +0200 Received: from nobody by pd9fba93c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Sep 2006 01:09:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sun, 03 Sep 2006 00:37:49 +0200 Organization: Lines: 137 Message-ID: <44FA07BD.71A@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba93c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [Asrg] Re: A Technique for Universal Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Michael Kaplan wrote: [bounced back to the sender == technically impossible] > Your argument is not unique to my proposal but it is directed > against all bounces, vacation messages, Yes, almost all auto-replies covered by RFC 3864, unsolicited DSNs, the works. > It is certainly not technically impossible, but I assume you > mean undesirable. No, I meant "impossible", because you don't know who the sender is. If you got an SPF PASS (or any equivalent indication that the Return-Path is no nonsense) that person might consider your procedure as "undesirable", but that's nobody else's business. For your case "unknown stranger" the default is that you just have no clue who the sender is. At that point you've already filtered your inbox, all "known good guys" either made it, or you reject it as trivial forgery. Let's say 80% of your ham. All "more than intermediate spam likelihood" is also out, that is 50% of your spam. So if your inbound is 5% ham, 84% spam, and 11% misdirected bounces, then your filtered inbound is: 1) 4% "identified ham" (80% of "5"), already in your inbox 2) 42% "identified spam" (50% of "84"), dropped or rejected 3) 11% "misdirected bounces", let's say you drop this unread 4) 42% "unidentified spam" (rest of 84) gets a challenge 5) 1% "unidentified ham" (rest of 5) also gets a challenge Therefore about 42 of 43 challenges hit innocent bystanders. Smart spammers probably abuse "plausible" Return-Paths, with "plausible" = survives call-back-verification (tests arriving as apparently empty spam), and they might also avoid SPF FAIL paths. If they're not so smart they probably ended up in your first 42% of "identified spam", because you could as well test this. If the ratio is 42 of 43, or only 40 of 43, whatever, you end up with huge amounts of spam (unsolicited challenges are spam) sent by you. The typical plan B for those who think that SPF is not really necessary would be a separate IP used to send your backscatter. If that IP is blocked your challenges will be rejected on their way (maybe including the one you're really interested in), and the problem is solved. I don't see a working system here, same problem as in RFC 2821. > Existing methods such as BATV can easily protect mail systems > from this problem. BATV works if a Return-Path is bound to mailouts and MXs in the same mail originating / receiving network. The relevant MXs have to know which Return-Paths were created by corresponding mailouts. BATV is a kind of hardcore SPF, the senders enforce their own policy wrt bounces. Or rather the MDA has to know which Return-Paths were actually sent, anything else can be dropped. Reject at the MX might be better, but not required. If your system is "BATV-ready" it MUST use an empty Return-Path in its challenges, the other methods mentioned by RFC 3864 work only after DATA in SMTP (or after HEAD if that draft makes it). A system only working if the whole world deploys BATV or SPF (if you take the latter into account in your filtering) is IMHO premature. You'd have to wait until you get a ratio "1 of 43" instead of "42 of 43", and then the "1" is still an unsolicited challenge. > It is highly unlikely that email with an SPF PASS would get > bounced. That's no real problem, after all an SPF PASS is a guarantee that bounces won't hit innocent bystanders. If the sender does not like your challenge (s)he can "just hit del" and be done with it. > The receipt of erroneous bounces would annoy some (mostly > victims of Joe jobs) Let's reserve the term "Joe Job" for something more serious than "84% of mail are spam with plausible forged Return-Paths", that's the reason for "11% of mails are misdirected bounces". I'd wish I could remember where I read this 84+11+5 = 100, it was this year, and not a too obscure source (e.g. not nanae). > but, ironically, it would accelerate the adoption of BATV I doubt it. Folks thinking that SPF is too restrictive won't like the more restrictive BATV. If you can identify BATV or SPF PASS, and limit your bounces to these cases, you won't run into trouble. Maybe SPF should offer a BATV flag: "All Return-Paths with this domain are BATV-protected (and anything else is forged)". But actually the BATV-sender knows which local parts are okay, a sender policy "v=spf1 exists:%l.%d -all" or similar allows receivers to get a clear PASS or FAIL (without any forwarding issues). Anybody supporting BATV could also support this kind of sender policy (IIRC that was the or a part of the SES idea). But that's not yet the case, and it could take a decade until deployment allows you to ignore "the rest of the world". With a good chance that it will never happen. > 1st - If implemented will it actually stop spam? "Works after worldwide deployment" - one of the FUSSP points. > 2nd - Is it practical to implement? If that boils down to "can receivers identify BATV local parts with sufficient certainity" I can't tell. Identifying an SPF PASS is a solved problem. > 3rd - Is it unacceptably burdensome to the sender/recipient? Some don't like BATV and/or SPF. In your original article you mentioned other schemes (SenderID PASS + DKIM PASS) where you never send a bounce (?). Maybe it's acceptable that senders pick one or more of these schemes as it pleases them. > 4th - Is it unacceptably burdensome to third parties? "42 of 43 challenges are unsolicited" wouldn't be good enough. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 03 00:37:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJjfy-0003nR-Sc; Sun, 03 Sep 2006 00:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJjfx-0003nL-8Y for asrg@ietf.org; Sun, 03 Sep 2006 00:33:41 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJjfv-0008UJ-TW for asrg@ietf.org; Sun, 03 Sep 2006 00:33:41 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA11979; Sun, 3 Sep 2006 00:33:29 -0400 (EDT) From: der Mouse Message-Id: <200609030433.AAA11979@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sun, 3 Sep 2006 00:30:36 -0400 (EDT) To: asrg@ietf.org Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <44FA07BD.71A@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > For your case "unknown stranger" the default is that you just have no > clue who the sender is. If I might be forgiven a slight nitpick, you actually have a 20% chance of knowing who the sender is (assuming an 80% spam figure). I call this a nitpick because while it is definitely better than having "no clue", it is not good enough to be useful in a practical sense. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 03 10:03:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJsUa-0006dk-Ic; Sun, 03 Sep 2006 09:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJsUX-0006bT-Rx for asrg@ietf.org; Sun, 03 Sep 2006 09:58:29 -0400 Received: from 81-223-91-228.treustrasse.xdsl-line.inode.at ([81.223.91.228] helo=zeno.hjp.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJsUW-0001mw-Dq for asrg@ietf.org; Sun, 03 Sep 2006 09:58:29 -0400 Received: by zeno.hjp.at (Postfix, from userid 1000) id 2088F4039; Sun, 3 Sep 2006 15:58:17 +0200 (CEST) Date: Sun, 3 Sep 2006 15:58:17 +0200 From: "Peter J. Holzer" To: asrg@ietf.org Message-ID: <20060903135817.GA28518@hjp.at> Mail-Followup-To: asrg@ietf.org Mime-Version: 1.0 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Asrg] DSN generation and handling X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032992464==" Errors-To: asrg-bounces@ietf.org --===============1032992464== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This isn't directly spam-related but since some anti-spam schemes (e.g. Michael Kaplan's) generate DSNs and require the user (or his system) to act on them this may be of interest: I have recently begun to collect information about the generation and handling of DSN messages. More specifically, the points I am interested in are: * What format are DSN messages generated in? Do they conform to RFC 3464? Do they contain all relevant information? Is it presented in a human (user) readable manner? Do they contain the complete undelivered message or just part of it? * Are DSNs generated by other systems passed through faithfully, or are they in some way changed? * How is the DSN presented to the user? Does the user see all the information in the DSN? Does he get extra information? (for example, there may be explanations for the extended status codes)? Is the DSN linked to the bounced message?=20 * How are unusual cases (e.g., multi-line SMTP responses or SMTP responses with very long lines or non-ASCII characters) handled? First, has anybody already done this? I can't believe I'm the first, but my googling skills don't seem adequate to find anything. Secondly, I'm asking for material: DSNs, screenshots, etc. Feel free to edit out sensitive information (email addresses, bodies of bounced mails, etc.) but if you do, please state clearly what you removed. The more information you can supply, the better. For now, I'll just collect everything I get on http://www.hjp.at/mail/dsn/.=20 That should become a bit more structured as I get more material. I'll also set up some test addresses which reject mail with different messages. For now you can try and . hp --=20 _ | Peter J. Holzer | Schlagfertigkeit ist das, was einem |_|_) | Sysadmin WSR | auf dem Nachhauseweg einf=E4llt. | | | hjp@hjp.at | -- Lars 'Cebewee' Noschinski in dasr. __/ | http://www.hjp.at/ | --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE+t95fZ+RkG8quy0RAgFSAJ9qK5gxvZjU1rYruyfeWfPARupKywCePWc6 CkmFzKtmnSKoTJNPmK6jVjU= =gok8 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- --===============1032992464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1032992464==-- From asrg-bounces@ietf.org Sun Sep 03 13:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJvMp-0005fl-LT; Sun, 03 Sep 2006 13:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJvMo-0005ej-76 for asrg@ietf.org; Sun, 03 Sep 2006 13:02:42 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJvMl-0008L7-Tr for asrg@ietf.org; Sun, 03 Sep 2006 13:02:42 -0400 Received: (qmail 4988 invoked from network); 3 Sep 2006 17:02:39 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 3 Sep 2006 17:02:39 -0000 Date: 3 Sep 2006 17:02:39 -0000 Message-ID: <20060903170239.11718.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] DSN generation and handling In-Reply-To: <20060903135817.GA28518@hjp.at> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: hjp-asrg@hjp.at X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org An interesting topic. I've seen a fair amount of discussion but nothing approaching research. >* What format are DSN messages generated in? Do they conform to > RFC 3464? Do they contain all relevant information? Is it presented in > a human (user) readable manner? > Do they contain the complete undelivered message or just part of it? There sure are a lot of them. You can add qmail's QSBMF documented at http://cr.yp.to/proto/qsbmf.txt. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 03 16:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJyXE-0007m6-Qu; Sun, 03 Sep 2006 16:25:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJyXD-0007m1-8L for asrg@ietf.org; Sun, 03 Sep 2006 16:25:39 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJyX9-0007hf-Kz for asrg@ietf.org; Sun, 03 Sep 2006 16:25:39 -0400 Received: by py-out-1112.google.com with SMTP id e30so1728979pya for ; Sun, 03 Sep 2006 13:25:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QS+3Yn0jU2kUtG4cTLTnQteL+5EWJ79Ak4iB5/SML+77/x5aMKBp7EOr5C62xO5bpT76snI6yLgPFtfoKhrDtdITwjVkFVpjkJA48HXfFuohbHiN7eAuMja6VcH8UPK31OWug2SPwCuxmVzzIdcTI69ddV7vsBXXnBSCYnczKps= Received: by 10.65.114.16 with SMTP id r16mr4614269qbm; Sun, 03 Sep 2006 13:25:35 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Sun, 3 Sep 2006 13:25:34 -0700 (PDT) Message-ID: Date: Sun, 3 Sep 2006 16:25:34 -0400 From: "Michael Kaplan" To: "Frank Ellermann" Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <44FA07BD.71A@xyzzy.claranet.de> MIME-Version: 1.0 References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536785879==" Errors-To: asrg-bounces@ietf.org --===============0536785879== Content-Type: multipart/alternative; boundary="----=_Part_72899_10392418.1157315134958" ------=_Part_72899_10392418.1157315134958 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/2/06, Frank Ellermann wrote: > Michael Kaplan wrote: > > [bounced back to the sender == technically impossible] > > Your argument is not unique to my proposal but it is directed > > against all bounces, vacation messages, > > Yes, almost all auto-replies covered by RFC 3864, unsolicited > DSNs, the works. I accept the fact that many individuals feel very passionately about the auto-reply issue but I hope you would acknowledge that your sentiment is a minority position not shared by a vast number of reputable top email companies that frequently enable it in one fashion or another. Officially the IETF does not consider the auto-reply provisions of RFC 3864 abuse either. Rather than reiterate the concept of "any system that employs any automated response is absolutely unacceptable" I'd like for us to look beyond that for now - we know that the major email companies will certainly look beyond it. Can we at least look beyond this issue for arguments sake? > > It is certainly not technically impossible, but I assume you > > mean undesirable. > > No, I meant "impossible", because you don't know who the sender > is. If you got an SPF PASS (or any equivalent indication that > the Return-Path is no nonsense) that person might consider your > procedure as "undesirable", but that's nobody else's business. > > For your case "unknown stranger" the default is that you just > have no clue who the sender is. At that point you've already > filtered your inbox, all "known good guys" either made it, or > you reject it as trivial forgery. Let's say 80% of your ham. > > All "more than intermediate spam likelihood" is also out, that > is 50% of your spam. So if your inbound is 5% ham, 84% spam, > and 11% misdirected bounces, then your filtered inbound is: > > 1) 4% "identified ham" (80% of "5"), already in your inbox > 2) 42% "identified spam" (50% of "84"), dropped or rejected > 3) 11% "misdirected bounces", let's say you drop this unread > 4) 42% "unidentified spam" (rest of 84) gets a challenge > 5) 1% "unidentified ham" (rest of 5) also gets a challenge > > Therefore about 42 of 43 challenges hit innocent bystanders. I think you underestimate the discriminating power of Bayesian filters. Check out the last figure on the SpamBayes website: http://spambayes.sourceforge.net/background.html As you can see almost all ham is unambiguously classified as ham, while almost all spam is unambiguously classified as spam. So 50% of spam is not given an intermediate rating; the figure is no where even close to that. The intermediate rated email between the two extremes makes up a small percentage of the total volume of email. This is the small percentage that I would bounce. I don't believe that everyday filter data produces results as distinct as seen on the SpamBayes website, but the general concept holds. How about if we bounce the 10% least spammy mail that otherwise would have gone to the junk folder as well as 5% of the most spammy mail that would have gone into the inbox? I won't say that this will result in a final result of 0% false negatives and positives, but I argue that it will yield a final false negative and false positive rate substantively better than you would get just by using a filter. Your calculation also assumes that 100% of spam spoofs a real email address. A substantial amount (the vast majority??) of spam uses randomly generated addresses. A system only working if the whole world deploys BATV or SPF > (if you take the latter into account in your filtering) is IMHO > premature. You'd have to wait until you get a ratio "1 of 43" > instead of "42 of 43", and then the "1" is still an unsolicited > challenge. > I suggested BATV as part of 'belt and suspenders' approach to distribution of auto-reply software. As I stated distribution of Auto-Reply will be more effective when done at the level of the MUA. Every MUA has filtering ability, so I suggest correlating incoming bounces with recent outgoing mail and filtering bounces that don't correspond. Let's reserve the term "Joe Job" for something more serious > than "84% of mail are spam with plausible forged Return-Paths", > that's the reason for "11% of mails are misdirected bounces". > I used the term Joe Job because I suspect that the problem of erroneous bounces is exaggerated. I say this because of the dearth of literature (beyond anecdotal reports) that even mentions it as a problem. I see tons of reports such as the follow recent addition: http://weblog.infoworld.com/techwatch/archives/007730.html I've never seen a breakdown that included a category for erroneous bounces. I know that John Levine has been plagued by this issue, but I would classify his problem as Joe Jobbing. I suspect that much of the foot dragging on BATV is because it addresses a problem that most people don't have. If you can site any literature on this issue then I would certainly appreciate it. > 1st - If implemented will it actually stop spam? > > "Works after worldwide deployment" - one of the FUSSP points. > I've already gone over in detail that "worldwide deployment" is completely unnecessary > 2nd - Is it practical to implement? > > If that boils down to "can receivers identify BATV local parts > with sufficient certainity" I can't tell. Identifying an SPF > PASS is a solved problem. > > > 3rd - Is it unacceptably burdensome to the sender/recipient? > > Some don't like BATV and/or SPF. In your original article you > mentioned other schemes (SenderID PASS + DKIM PASS) where you > never send a bounce (?). Maybe it's acceptable that senders > pick one or more of these schemes as it pleases them. > Again my system is primarily focused on authenticating email that has no authentication. I (and almost every major company) disagree with the concept that you can't send an automated response to an email unless that email was authenticated. Given this I propose sending an auto-reply in the most selective fashion possible. > 4th - Is it unacceptably burdensome to third parties? > > "42 of 43 challenges are unsolicited" wouldn't be good enough. > see above Thank you for your input Michael ------=_Part_72899_10392418.1157315134958 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/2/06, Frank Ellermann <nobody@xyzzy.claranet.de > wrote:
Michael Kaplan wrote:

[bounced back to the sender == technically impossible]
> Your argument is not unique to my proposal but it is directed
> against all bounces, vacation messages,

Yes, almost all auto-replies covered by RFC 3864, unsolicited
DSNs, the works.
 
 
I accept the fact that many individuals feel very passionately about the auto-reply issue but I hope you would acknowledge that your sentiment is a minority position not shared by a vast number of reputable top email companies that frequently enable it in one fashion or another.  Officially the IETF does not consider the auto-reply provisions of RFC 3864 abuse either.  Rather than reiterate the concept of "any system that employs any automated response is absolutely unacceptable" I'd like for us to look beyond that for now - we know that the major email companies will certainly look beyond it.  Can we at least look beyond this issue for arguments sake?

 
> It is certainly not technically impossible, but I assume you
> mean undesirable.

No, I meant "impossible", because you don't know who the sender
is.  If you got an SPF PASS (or any equivalent indication that
the Return-Path is no nonsense) that person might consider your
procedure as "undesirable", but that's nobody else's business.

For your case "unknown stranger" the default is that you just
have no clue who the sender is.  At that point you've already
filtered your inbox, all "known good guys" either made it, or
you reject it as trivial forgery.  Let's say 80% of your ham.

All "more than intermediate spam likelihood" is also out, that
is 50% of your spam.   So if your inbound is 5% ham, 84% spam,
and 11% misdirected bounces, then your filtered inbound is:

1)   4% "identified ham"  (80% of  "5"), already in your inbox
2)  42% "identified spam" (50% of "84"), dropped or rejected
3)  11% "misdirected bounces", let's say you drop this unread
4)  42% "unidentified spam" (rest of 84) gets a challenge
5)   1% "unidentified ham" (rest of 5) also gets a challenge

Therefore about 42 of 43 challenges hit innocent bystanders.
 
 
I think you underestimate the discriminating power of Bayesian filters.  Check out the last figure on the SpamBayes website:
 
 
As you can see almost all ham is unambiguously classified as ham, while almost all spam is unambiguously classified as spam.  So 50% of spam is not given an intermediate rating; the figure is no where even close to that.  The intermediate rated email between the two extremes makes up a small percentage of the total volume of email.  This is the small percentage that I would bounce.
 
I don't believe that everyday filter data produces results as distinct as seen on the SpamBayes website, but the general concept holds.  How about if we bounce the 10% least spammy mail that otherwise would have gone to the junk folder as well as 5% of the most spammy mail that would have gone into the inbox?  I won't say that this will result in a final result of 0% false negatives and positives, but I argue that it will yield a final false negative and false positive rate substantively better than you would get just by using a filter.
 
Your calculation also assumes that 100% of spam spoofs a real email address.  A substantial amount (the vast majority??) of spam uses randomly generated addresses.
 

A system only working if the whole world deploys BATV or SPF
(if you take the latter into account in your filtering) is IMHO
premature.  You'd have to wait until you get a ratio "1 of 43"
instead of "42 of 43", and then the "1" is still an unsolicited
challenge.
 
I suggested BATV as part of 'belt and suspenders' approach to distribution of auto-reply software.  As I stated distribution of Auto-Reply will be more effective when done at the level of the MUA.  Every MUA has filtering ability, so I suggest correlating incoming bounces with recent outgoing mail and filtering bounces that don't correspond.
 

Let's reserve the term "Joe Job" for something more serious
than "84% of mail are spam with plausible forged Return-Paths",
that's the reason for "11% of mails are misdirected bounces".
 
 
I used the term Joe Job because I suspect that the problem of erroneous bounces is exaggerated.  I say this because of the dearth of literature (beyond anecdotal reports) that even mentions it as a problem.  I see tons of reports such as the follow recent addition:
 
 
I've never seen a breakdown that included a category for erroneous bounces.  I know that John Levine has been plagued by this issue, but I would classify his problem as Joe Jobbing.  I suspect that much of the foot dragging on BATV is because it addresses a problem that most people don't have.  If you can site any literature on this issue then I would certainly appreciate it.

 

> 1st - If implemented will it actually stop spam?

"Works after worldwide deployment" - one of the FUSSP points.
 
I've already gone over in detail that "worldwide deployment" is completely unnecessary
 

> 2nd - Is it practical to implement?

If that boils down to "can receivers identify BATV local parts
with sufficient certainity" I can't tell.  Identifying an SPF
PASS is a solved problem.
 
> 3rd - Is it unacceptably burdensome to the sender/recipient?

Some don't like BATV and/or SPF.  In your original article you
mentioned other schemes (SenderID PASS + DKIM PASS) where you
never send a bounce (?).  Maybe it's acceptable that senders
pick one or more of these schemes as it pleases them.
 
 
Again my system is primarily focused on authenticating email that has no authentication.  I (and almost every major company) disagree with the concept that you can't send an automated response to an email unless that email was authenticated.  Given this I propose sending an auto-reply in the most selective fashion possible.

> 4th - Is it unacceptably burdensome to third parties?

"42 of 43 challenges are unsolicited" wouldn't be good enough.
 
 
see above
 
Thank you for your input
Michael
------=_Part_72899_10392418.1157315134958-- --===============0536785879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============0536785879==-- From asrg-bounces@ietf.org Sun Sep 03 18:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK09P-0005Dk-Go; Sun, 03 Sep 2006 18:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK09N-0005Df-Ns for asrg@ietf.org; Sun, 03 Sep 2006 18:09:09 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GK09L-0004eK-EO for asrg@ietf.org; Sun, 03 Sep 2006 18:09:09 -0400 Received: (qmail 19451 invoked from network); 3 Sep 2006 22:09:02 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 3 Sep 2006 22:09:02 -0000 Date: 3 Sep 2006 22:09:02 -0000 Message-ID: <20060903220902.85822.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >I accept the fact that many individuals feel very passionately about the >auto-reply issue but I hope you would acknowledge that your sentiment is a >minority position not shared by a vast number of reputable top email >companies that frequently enable it in one fashion or another. No, we will not acknowledge that because it is not true. We all know that Exchange has a widely despised "I'm out of the office so come rob my house" feature, but it's hardly the only bad idea you'll find in Microsoft's mail software. AOL has spent quite a lot of time and money reworking their mail system so it does NOT send bounces and other auto-response messages, but instead rejects undeliverable mail with SMTP 5xx codes. This is precisely because of the spam blowback problems we have all been telling you about. In any event, as you surely know, the IETF's motto is rough consensus and running code. Go write some running code and tell us how it works. I hear that Thunderbird plugins aren't all that hard to write. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 03 20:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK2Q9-0004Xp-Uj; Sun, 03 Sep 2006 20:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK2Q8-0004Xj-7p for asrg@ietf.org; Sun, 03 Sep 2006 20:34:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK2Q0-0006nQ-3u for asrg@ietf.org; Sun, 03 Sep 2006 20:34:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GK2Pg-0003ez-3p for asrg@ietf.org; Mon, 04 Sep 2006 02:34:08 +0200 Received: from pd9fba8fc.dip0.t-ipconnect.de ([217.251.168.252]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:34:08 +0200 Received: from nobody by pd9fba8fc.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:34:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 04 Sep 2006 02:24:35 +0200 Organization: Lines: 180 Message-ID: <44FB7243.78C3@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8fc.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Asrg] Re: A Technique for Universal Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Michael Kaplan wrote: > I hope you would acknowledge that your sentiment is a > minority position not shared by a vast number of reputable > top email companies that frequently enable it in one fashion > or another. Officially the IETF does not consider the > auto-reply provisions of RFC 3864 abuse either. Apparently we have a communication problem here: I support RFC 3864, it's one of the best RFCs I know, and I seriously hope that it progresses to a full Internet standard. It does however (like all non-delivery reports) depend on a single premise: Return-Paths must be no nonsense. For the old (pre-1123) SMTP that was "guaranteed" by design - as far as those guarantees go, in theory it was a sound design. Certainly the "SPF FAIL or PASS" folks including me are a minority. But without it stuff like RFC 3864 (incl. your proposals) and NDRs can't work anymore, because the flood of unsolicited auto-replies (incl. bounces) forces receivers to block or drop them. Anybody who used mail in one of the more obscure positions like an unofficial UUCP link five hops from the Internet or a Fido node behind various gateways to the rfc822-world, would tell you that (store and forward) mail cannot work without error reports (NDRs). As soon as bounces are dropped wholesale the complete system breaks together, mail vanishes in black holes. SMTP is too "simple" to work without error reports. Today it's already almost normal to confirm the arrival of important mail by phone calls. This is worse than a decade ago, where I could trust that the Fido-gateway or UUCP-link might be slow, but generally reliable. So in other words I strongly believe in "good bounces", and an SPF PASS is not only a permission to send eror reports if necessary, it's a plea. Like the opposite SPF FAIL is not only a permission to reject forged mails. Anybody seriously considering SPF FAIL as an indicator to drop mails missed the point. Reject and drop are different. > I'd like for us to look beyond that for now - we know that > the major email companies will certainly look beyond it. As far as I'm concerned you can get it right, do whatever you like if you get an SPF PASS, and reject FAIL. For BATV I've no clue how you identify it, or how you could know that it's missing. But as you said those are minorities today, for the vast majority sending challenges to unverified Return-Paths won't fly. A system that works only if the whole world uses BATV or SPF is exactly as relevant as a system assuming that the whole world implements STD 10 verbatim (without the RFC 1123 bug): It's a wrong premise. > I think you underestimate the discriminating power of > Bayesian filters. Possible. Feel free to fix the numbers, raw 5+11+84, filtered (4+1)+11+(42+42). If your definition of "intermediate spam likelihood" is 25:75 instead of 50:50 you get (4+1)+11+(63+21). With that you'd arrive at 1+21 challenges (21 unsolicited). 42 of 43 was 97%, 21 of 22 is 95%. I've offered 40 of 43 (93%) in the same article where I arrived at 42 of 43. And der Mouse has proposed 80%, that's conservative, showing that the details don't matter: 80% unsolicited challenges won't work. You'd be blocked, and then your other challenges never make it. > How about if we bounce the 10% least spammy mail With the same scenario in permille that's (10+40)+110+(756+84) for 84 unsolicited challenges of 94, you're down to 89% spam. If that's realistic for your case I'm fine with these numbers, but 89% of all challenges unsolicited is still quite a lot UBE. > Your calculation also assumes that 100% of spam spoofs a real > email address. Yes, if you use call-back-verification other addresses never come near to your C/R system. And if you don't do it the smart spammers have done it. Completely bogus addresses aren't very interesting, you only need some disk space for your send queue while you try (in vain) to send challenges to these addresses - no problem. > A substantial amount (the vast majority??) of spam uses > randomly generated addresses. That doesn't match my obsevations (catchall vanity domain): The vast majority are parts of or complete Message-IDs, local parts generated by Sober and other mail worms, and similar cases, not completely random 1*63(ALPHA / DIGIT / "-" / more). Any longer addresses I see are almost always real Message-IDs. > I suggest correlating incoming bounces with recent outgoing > mail and filtering bounces that don't correspond. That's the BATV idea in a nutshell, doing it at the MUA has its own challenges (not everybody can create Return-Paths on the fly, other matching methods are tricky, and last but not least ifit hits the mailbox before POP3 or IMAP the battle is already almost lost, V90 users note it immediately, others see it on their invoice if they pay by volume). > I used the term Joe Job because I suspect that the problem of > erroneous bounces is exaggerated. I disagree. Anybody who doesn't drop bounces unread has a serious problem. Less so for SPF FAIL folks, and almost ideal for BATV users, but even then there are many "wannabe-bounces", crap like Mailer-Daimon@ (sic). In 2004, when SpamCop did not allow to report bogus bounces, I tried to filter such crap for some months, it was a PITA. Since about two years my spammers mainly got the idea of SPF FAIL, therefore it's under control from my POV. But I did note the two weeks in 2005 when they tested again to forge my addresses. Even today I'd still note it if there are 1000 bogus bounces per day in addition to the "normal" spam - but fortunately (or thanks to SPF FAIL) that's not the case. > I know that John Levine has been plagued by this issue, but I > would classify his problem as Joe Jobbing. He told us that he uses BATV, and I'd be very surprised if the professional spammers don't read this list to stay up to date (among a few others). No "Joe Jobbing" in my book, an attempt to (ab)use the reputation of abuse.net maybe. Without SPF FAIL the receivers can't identify "missing BATV" or "invalid BATV", they'd need CSV or an emulation of it to reject bogus "EHLO abuse net" sessions. If that's what his box says, ...checking, no, not necessarily, it can be "EHLO iecc.com". I forgot the details how to check CSV for this. > I suspect that much of the foot dragging on BATV is because > it addresses a problem that most people don't have. You'd only see it with a domain, on other addresses (no vanity domain) I've seen it only in conjunction with mail worms (the worms forged my address, and I got the backscatter), not spam. > If you can site any literature on this issue then I would > certainly appreciate it. You might find some links in the related Wikipedia articles: Caveat: I had my fingers in some of those Wikipedia articles. The most often quoted source I'm aware of is the Spamcop FAQ: quotes Ironport, Messagelabs, and Postini, and if that's the source where I saw 84% I wonder where I got the 11% - this article says 9% misdirected bounces. I'm too lazy to dig for the original Ironport report, if you find it please post a link. > "worldwide deployment" is completely unnecessary Good. You did however hint that anybody who doesn't like the unsolicited challenges can deploy BATV, and I doubted that. > I (and almost every major company) disagree with the concept > that you can't send an automated response to an email unless > that email was authenticated. I guess we disagree about this, but as long as you reject all SPF FAIL it won't affect me personally. I won't mind if you challenge an SPF PASS from me, I'm free to ignore it or to answer it - depends on what I want, I answer challenges from say ICANN or IANA (again and again... so far ;-). Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 03 20:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK2Xb-0002AY-OO; Sun, 03 Sep 2006 20:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK2Xb-0002AT-7M for asrg@ietf.org; Sun, 03 Sep 2006 20:42:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK2XZ-0000CD-UU for asrg@ietf.org; Sun, 03 Sep 2006 20:42:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GK2XT-0006M4-WF for asrg@ietf.org; Mon, 04 Sep 2006 02:42:12 +0200 Received: from pd9fba8fc.dip0.t-ipconnect.de ([217.251.168.252]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:42:11 +0200 Received: from nobody by pd9fba8fc.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:42:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 04 Sep 2006 02:41:35 +0200 Organization: Lines: 2 Message-ID: <44FB763F.4F2E@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> <44FB7243.78C3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8fc.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Asrg] RFC 3464 (was: A Technique for Universal Authentication) X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org s/3864/3464/g I also like 3864, but here I meant 3464, sorry. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 00:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKSOQ-0006T3-10; Tue, 05 Sep 2006 00:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKSOP-0006R4-3j for asrg@ietf.org; Tue, 05 Sep 2006 00:18:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKSOL-0001hD-SX for asrg@ietf.org; Tue, 05 Sep 2006 00:18:33 -0400 Received: by wx-out-0506.google.com with SMTP id t4so2333653wxc for ; Mon, 04 Sep 2006 21:18:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R5GOZ4JVCX5PIIVXYNOE+w7FhK/x6v0cOqiTG8DWbCa1s2Xuvy5z4Oj+W6vVcqssQIgqqJvTcn8PI+uFJx0XWXQ+NtQmEg4lQF2d+RWzCFH+DMr3J4kirbBQV7RnwCx1lou6uu4e7f5wCWVDgxpR0x+w3NFKF93THOukfp8IeYQ= Received: by 10.90.81.14 with SMTP id e14mr1207014agb; Mon, 04 Sep 2006 21:18:29 -0700 (PDT) Received: by 10.90.105.8 with HTTP; Mon, 4 Sep 2006 21:18:29 -0700 (PDT) Message-ID: <934f64a20609042118p30ac606dtfc726b6179d7b9d9@mail.gmail.com> Date: Mon, 4 Sep 2006 23:18:29 -0500 From: "David Nicol" To: "Frank Ellermann" Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <44FA07BD.71A@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> X-Spam-Score: 1.9 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9/2/06, Frank Ellermann wrote: > Maybe SPF should offer a BATV flag: "All Return-Paths with > this domain are BATV-protected (and anything else is forged)". or BATV could declare a syntax to include in TXT records. SPF is too old by now to add features to, but I believe (could be wrong) that it can co-exist in a TXT record with other things; if not example.net coul declare its BATV record in -batv.example.net or something although there's some BCP that gets violated when you start mandating parts of names. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 03:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKUw6-0003qJ-GQ; Tue, 05 Sep 2006 03:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKUw5-0003qD-0O for asrg@ietf.org; Tue, 05 Sep 2006 03:01:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKUw3-0004BI-Id for asrg@ietf.org; Tue, 05 Sep 2006 03:01:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GKUvd-0007ng-Rk for asrg@ietf.org; Tue, 05 Sep 2006 09:01:01 +0200 Received: from du-001-236.access.de.clara.net ([212.82.227.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Sep 2006 09:01:01 +0200 Received: from nobody by du-001-236.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Sep 2006 09:01:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Tue, 05 Sep 2006 08:58:06 +0200 Organization: Lines: 46 Message-ID: <44FD1FFE.18B3@xyzzy.claranet.de> References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> <934f64a20609042118p30ac606dtfc726b6179d7b9d9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-236.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Asrg] Re: A Technique for Universal Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org David Nicol wrote: > BATV could declare a syntax to include in TXT records Yes. > SPF is too old by now to add features to No, you can add "modifiers", stuff like batv=what.ever.syntax New "mechanisms" as in batv:syntax.ever.what would require a new version, in essence a new tag at the begin of the TXT, as in v=spf1 vs. spf2.0/pra. > I believe (could be wrong) that it can co-exist in a TXT > record with other things Yes, a separate TXT or SPF record with its own tag. You'd be limited by the q=txt (or q=spf) response, the complete set has to fit, same idea as for q=mx and several MX records. Reviving the old SES idea could be fully integrated into SPF, it can use its exists: mechanism (for that the sender needs a name server answering queries about wannabe SES/BATV local parts, forged or valid). The BATV senders can identify valid local parts (otherwise they couldn't reject bounces to forged Return-Paths), but sharing that knowledge via DNS SPF exists: with arbitrary receivers might be difficult... or interesting for bad actors, how can they abuse this. With mail it's probably a good idea to write all new protocols directly for the main mail users, the spammers. With the less frequent legit cases as (desired) side effects. > there's some BCP that gets violated when you start mandating > parts of names. Maybe draft-iab-dns-choices-03.txt, but that's not yet a BCP. The SRV records have name conventions, and IDNA uses xn-- and reserves similar prefixes. I can't tell how mandatory that is, maybe I'm still free to create a label xn--what-ever, or this depends on the TLD. An interesting question... :-) Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 11:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcUE-0005l5-SZ; Tue, 05 Sep 2006 11:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcUD-0005ku-U6 for asrg@ietf.org; Tue, 05 Sep 2006 11:05:13 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcUC-0005Tx-Ni for asrg@ietf.org; Tue, 05 Sep 2006 11:05:13 -0400 Received: by wr-out-0506.google.com with SMTP id i4so608493wra for ; Tue, 05 Sep 2006 08:05:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=kJGGPZ8hHmFcCXga33xQrl6ZNrGn2TES2eY2JMROPA0M753VeCJxbLFQr2qvav//d0paJB85kI7JJN0f0687U+oPNzckT1/IiD+bYtrhUWQK/DMNL3jEIffmEoqOPR2zh5DUDU+LfFNuimrixMjyRFI6lSPMc/pwBXsF9lsh8lQ= Received: by 10.90.52.18 with SMTP id z18mr1483147agz; Tue, 05 Sep 2006 08:05:12 -0700 (PDT) Received: by 10.90.105.8 with HTTP; Tue, 5 Sep 2006 08:05:12 -0700 (PDT) Message-ID: <934f64a20609050805k22e19404ka41f3f841fe70747@mail.gmail.com> Date: Tue, 5 Sep 2006 10:05:12 -0500 From: "David Nicol" To: "Frank Ellermann" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: asrg@ietf.org Subject: [Asrg] BATV + SPF roadmap X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9/5/06, Frank Ellermann wrote: > > SPF is too old by now to add features to > > No, you can add "modifiers", stuff like batv=what.ever.syntax Thanks. I remembered about that eventually. To state what may be obvious, the shortest path would seem to be for (1) the BATV community to agree on and test an SPF modifier syntax&semantics and (2) document it as frozen and available for use; possibly issuing patches to the popular spf resolver modules. -- Although efforts are under way to mitigate the problem, this message may contain flippancy, hyperbole and/or confusing assertions. Please reply directly to fall2006sigfile@davidnicol.com for clarification of any points appearing unclear, vague, cruel, frustrating, threatening, negative, dilletantish or otherwise unprofessional before taking action based on misintepretation or misconstruction of such points. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 11:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcqn-0002xn-0n; Tue, 05 Sep 2006 11:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKcql-0002s3-AV for asrg@ietf.org; Tue, 05 Sep 2006 11:28:31 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKcqR-0001W9-JY for asrg@ietf.org; Tue, 05 Sep 2006 11:28:31 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k85FRv4q003528; Tue, 5 Sep 2006 08:27:58 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k85FRvSa003515; Tue, 5 Sep 2006 08:27:57 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 5 Sep 2006 08:27:56 -0700 (PDT) From: "william(at)elan.net" To: David Nicol Subject: Re: [Asrg] BATV + SPF roadmap In-Reply-To: <934f64a20609050805k22e19404ka41f3f841fe70747@mail.gmail.com> Message-ID: References: <934f64a20609050805k22e19404ka41f3f841fe70747@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Frank Ellermann , asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 5 Sep 2006, David Nicol wrote: > On 9/5/06, Frank Ellermann wrote: >> > SPF is too old by now to add features to >> >> No, you can add "modifiers", stuff like batv=what.ever.syntax > > Thanks. I remembered about that eventually. > > To state what may be obvious, > the shortest path would seem to be for > > (1) the BATV community to agree on and test an SPF modifier > syntax&semantics and > > (2) document it as frozen and available for use; possibly issuing > patches to the popular spf resolver modules. Like it was mentioned, I would remind that BATV is a modification of SES which came from SPF community. At some point I did propose that BATV and SES people work together to create syntax for extended MAIL FROM address (to include SRS), but there was no interest (and there is no BATV community to speak of anyway). SES is really a lot better then BATV as far as its integration with SPF and otherwise its all the same. So what can be done is for SPF community to release protocol specification of SES as part of SPF set of documents, perhaps then it would get more attention. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 12:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdwH-0004jb-Md; Tue, 05 Sep 2006 12:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdwG-0004jV-6W for asrg@ietf.org; Tue, 05 Sep 2006 12:38:16 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GKdwE-0002pa-RI for asrg@ietf.org; Tue, 05 Sep 2006 12:38:16 -0400 Received: (qmail 13219 invoked from network); 5 Sep 2006 16:38:14 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 5 Sep 2006 16:38:14 -0000 Date: 5 Sep 2006 16:38:14 -0000 Message-ID: <20060905163814.82599.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] BATV + SPF roadmap In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: william@elan.net X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > Like it was mentioned, I would remind that BATV is a modification of > SES which came from SPF community. Actually, it's the other way around. BATV came first under some other name that I forget now, SES added a lot of extra junk to it to come up with what I have always seen as an inferior version of DK. BATV is deliberately simple and works unilaterally, without recipient hosts needing to know anything about it. The BATV documents point out that if there is a per-domain public key system like DK or DKIM, it would not be hard to do a version of BATV with signatures that could be verified remotely, but that is something to think about after we're done with DKIM. In the meantime, how about that taxonomy? R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 12:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeBB-0002TN-SN; Tue, 05 Sep 2006 12:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKeBA-0002T7-8s for asrg@ietf.org; Tue, 05 Sep 2006 12:53:40 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKeB8-0004U3-RD for asrg@ietf.org; Tue, 05 Sep 2006 12:53:40 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k85GrbbG005479; Tue, 5 Sep 2006 09:53:38 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k85Grb6m005476; Tue, 5 Sep 2006 09:53:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 5 Sep 2006 09:53:37 -0700 (PDT) From: "william(at)elan.net" To: John Levine Subject: Re: [Asrg] BATV + SPF roadmap In-Reply-To: <20060905163814.82599.qmail@simone.iecc.com> Message-ID: References: <20060905163814.82599.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 5 Sep 2006, John Levine wrote: >> Like it was mentioned, I would remind that BATV is a modification of >> SES which came from SPF community. > > Actually, it's the other way around. You know I've been around during that time too - you better have very good evidence before you make statement like above. Because I still remember when you said you came up with BATV concept few days before MARID's interim meeting in May 2004 and Wayne immediately told you (or possibly to Dave Crocker - I think he was the one presenting it on the meeting) that SPF had the same developed as SES and indeed spf-discuss archives how it's been developed a year before and its original form was exactly like BATV you introduced (difference in encoding syntax but I'm sure you'd agree this is not important). I can point everyone to correct archives of when it all happs and can even point to your posts on SES's own list. > BATV came first under some other name that I forget now, Please provide that name and evidence to back up what you said above. > SES added a lot of extra junk to it to come up > with what I have always seen as an inferior version of DK. That was later version of SES which I tole the authors was bad direction to take it to. > BATV is deliberately simple and works unilaterally, without recipient > hosts needing to know anything about it. SES can work just like that too. The only difference is that it optionally to not only to answer if MAIL FROM is properly encrypted but also to check on that by remote using dns and that can optionally be referenced from SPF record. In fact same feature can be bullt on BATV - the syntax is really not all that important. > The BATV documents point out that if there is a per-domain public key > system like DK or DKIM, it would not be hard to do a version of BATV > with signatures that could be verified remotely, but that is something > to think about after we're done with DKIM. You originally wanted to also have public-key based BATV signature using DK public keys and I pointed out that size of the data you can put in MAIL FROM is too small for you to use anything but 384k key which is not going to be acceptable for security reasons (indeed DKIM minimum is now 1024k). -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 13:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKesV-0001R3-BR; Tue, 05 Sep 2006 13:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKesR-0001M2-QU for asrg@ietf.org; Tue, 05 Sep 2006 13:38:24 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKejQ-0002Qz-67 for asrg@ietf.org; Tue, 05 Sep 2006 13:29:06 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k85HSvNv009844 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Sep 2006 10:28:57 -0700 In-Reply-To: References: <20060905163814.82599.qmail@simone.iecc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] BATV + SPF roadmap Date: Tue, 5 Sep 2006 10:29:24 -0700 To: "william(at)elan.net" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Anti-Spam Research Group Group X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Sep 5, 2006, at 9:53 AM, william(at)elan.net wrote: > > On Tue, 5 Sep 2006, John Levine wrote: > >>> Like it was mentioned, I would remind that BATV is a modification >>> of SES which came from SPF community. >> >> Actually, it's the other way around. > > You know I've been around during that time too - you better have > very good evidence before you make statement like above. Because I > still remember when you said you came up with BATV concept few days > before MARID's interim meeting in May 2004 and Wayne immediately > told you (or possibly to Dave Crocker - I think he was the one > presenting it on the meeting) that SPF had the same developed as > SES and indeed spf-discuss archives how it's been developed a year > before and its original form was exactly like BATV you introduced > (difference in encoding syntax but I'm sure you'd agree this is not > important). I can point everyone to correct archives of when it > all happs and can even point to your posts on SES's own list. Apples and oranges are similar in that they are both round fruit. : ) There might be a desire to standardize upon a common syntax however. From what I can see, the latest BATV draft should not impose undue constraints. >> BATV came first under some other name that I forget now, > > Please provide that name and evidence to back up what you said above. In John's defense, I recall a few conversations that prompted John to document BATV. These conversations were in regard to a prior concept. >> The BATV documents point out that if there is a per-domain public >> key system like DK or DKIM, it would not be hard to do a version >> of BATV with signatures that could be verified remotely, but that >> is something to think about after we're done with DKIM. > > You originally wanted to also have public-key based BATV signature > using DK public keys and I pointed out that size of the data you > can put in MAIL FROM is too small for you to use anything but 384k > key which is not going to be acceptable for security reasons > (indeed DKIM minimum is now 1024k). When a domain indicates they sign all messages, then BATV imposes no additional constrains. BATV can also offer a valuable method to sort through fake DSNs that are sure to happen with DKIM, as the DKIM signature will be expected to be damaged. There was some conversation regarding use of public keys, but that never materialized. Perhaps for the reasons you mention. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 16:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKhdu-0002XO-Q9; Tue, 05 Sep 2006 16:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKhdt-0002Ue-QA for asrg@ietf.org; Tue, 05 Sep 2006 16:35:33 -0400 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GKhdq-0003b4-PZ for asrg@ietf.org; Tue, 05 Sep 2006 16:35:33 -0400 Received: (qmail 3639 invoked from network); 5 Sep 2006 20:35:30 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 5 Sep 2006 20:35:30 -0000 Date: 5 Sep 2006 20:35:30 -0000 Message-ID: <20060905203530.40410.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] BATV + SPF roadmap In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: william@elan.net X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >>> Like it was mentioned, I would remind that BATV is a modification of >>> SES which came from SPF community. >> >> Actually, it's the other way around. > >You know I've been around during that time too - you better have very >good evidence before you make statement like above. Sorry, pissing contests are off-topic for this list. SES and BATV have very different goals. BATV protects against bounce forgery blowback. SES is, as best I understand it, includes a signed checksum of the message intended to let recipients check that the message was really sent by the putative sender, and some sort of callback to keep people from delivering the same message many times. All that BATV does is to let you check incoming bounces to see if they were provoked by something you sent. It's a much smaller goal, but much more achievable. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Sep 05 20:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKlbp-0002X5-KO; Tue, 05 Sep 2006 20:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKlbn-0002TA-Sb for asrg@ietf.org; Tue, 05 Sep 2006 20:49:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKlbh-0003Ay-8s for asrg@ietf.org; Tue, 05 Sep 2006 20:49:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GKlbZ-0005bI-Lc for asrg@ietf.org; Wed, 06 Sep 2006 02:49:25 +0200 Received: from pd9fba8f5.dip0.t-ipconnect.de ([217.251.168.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Sep 2006 02:49:25 +0200 Received: from nobody by pd9fba8f5.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Sep 2006 02:49:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Wed, 06 Sep 2006 02:48:05 +0200 Organization: Lines: 28 Message-ID: <44FE1AC5.573D@xyzzy.claranet.de> References: <20060905163814.82599.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f5.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Asrg] Re: BATV + SPF roadmap X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org John Levine wrote: > BATV came first under some other name that I forget now Maybe one of VERP, SRS, DMP, DRIP. FSV, ... the name doesn't matter, and who invented what is mainly a historic question - unless somebody else claims to have "patented" it. Unrelated: http://www.ietf.org/ietf/IPR/rsa-ipr-draft-jennings-sip-hashcash-00.txt > BATV is deliberately simple and works unilaterally, without > recipient hosts needing to know anything about it. Yes, that's not good enough. Receiving hosts wishing to know something about it should get what they need to reject forged Return-Paths. Ignorant hosts would still create backscatter, and BATV would still catch most of it, that's no issue. More interesting, if receiving hosts can identify it, then spammers would also know which Return-Paths they better don't forge, like they can know which Return-Paths are SPF FAIL protected. And the non-ignorant hosts would know which Return-Paths they can accept "on probation", where later bounces won't get them blacklisted as ignorants, like they know it today for SPF PASS. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Sep 06 11:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzSc-0007Fh-KI; Wed, 06 Sep 2006 11:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzSb-0007Fc-Pv for asrg@ietf.org; Wed, 06 Sep 2006 11:37:05 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzSa-0006qY-CF for asrg@ietf.org; Wed, 06 Sep 2006 11:37:05 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k86Fb0pQ010356; Wed, 6 Sep 2006 08:37:00 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k86FawQj010352; Wed, 6 Sep 2006 08:36:59 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 6 Sep 2006 08:36:58 -0700 (PDT) From: "william(at)elan.net" To: John Levine Subject: Re: [Asrg] BATV + SPF roadmap In-Reply-To: <20060905203530.40410.qmail@simone.iecc.com> Message-ID: References: <20060905203530.40410.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Tue, 5 Sep 2006, John Levine wrote: >>>> Like it was mentioned, I would remind that BATV is a modification of >>>> SES which came from SPF community. >>> >>> Actually, it's the other way around. >> >> You know I've been around during that time too - you better have very >> good evidence before you make statement like above. > > Sorry, pissing contests are off-topic for this list. I was not getting into one. My point is that all public evidence clearly indicates that SES predates BATV by about a year. And I was very surprised that you said you did it based on something else - that is directly opposite to what you said before. But if you don't want to tell us what it is, that's fine, I'll live this topic along if it causes you concerns about "pissing contests". > SES and BATV have very different goals.BATV protects against bounce > forgery blowback. SES is, as best I understand it, includes a signed > checksum of the message intended to let recipients check that the > message was really sent by the putative sender, and some sort of > callback to keep people from delivering the same message many times. As I'm not SES designer, I can not for sure speak about their goals when it was being developed. My understanding however is that SES had the same overall goals of stopping blowback and forgery of envelope MAIL FROM email data. Developers at some point decided to extend that to include forgery (or non-repudiation maybe?) of email as a whole (i.e. DATA) - I don't think this was ever fully implemented through. Whoever is using it (as modification of SRS or directly) are all doing it exactly same way as you do with BATV as way to verify MAIL FROM. In basic terms leaving (leaving difference in record syntax and format) BATV is basically a subset of SES where SES allows to do a lot more functionality that BATV either does not specify or does not allow. My interest is still to bring it to see standard format for MAIL FROM signature-like data (including also VERP and SRS) but I'm not going to support BATV format over SES or something else (even though you did add second separator symbol making even closer to SES syntax) unless SES developers and others agree with it and my guess is some neutral yet-unused name will have to be for generalized format. > All that BATV does is to let you check incoming bounces to see if they > were provoked by something you sent. It's a much smaller goal, but > much more achievable. SES works same way plus allows 3rd party to check if you'd accept the bounce by making DNS query to special RBL-like server (think of it as SMTP call-back to verify BATV bounce address is correct; but dns is a lot simpler effort to do it). -- William Leibzon Elan Networks william@elan.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 10 22:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMbLC-0007hz-Py; Sun, 10 Sep 2006 22:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMbLB-0007hq-0L for asrg@ietf.org; Sun, 10 Sep 2006 22:16:05 -0400 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMbL5-00022E-EE for asrg@ietf.org; Sun, 10 Sep 2006 22:16:04 -0400 Received: by nz-out-0102.google.com with SMTP id q3so477967nzb for ; Sun, 10 Sep 2006 19:15:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NLQCOErYt/Atlv7RabpHlIJOJPCt07D6DaykTHVEnTskDu0UZ/imYsbKsVDBnkK27WwR0rhqEV8myQqhymlRUgaUvcuxcrSTfcrkRvhH6gkTMtN5rlfMvDqQawm51aIuSyTzSHAWXoT/1lIaXoiJQhK/n5v9DtWciIh4tLxi494= Received: by 10.65.59.20 with SMTP id m20mr1255138qbk; Sun, 10 Sep 2006 19:15:58 -0700 (PDT) Received: by 10.65.105.9 with HTTP; Sun, 10 Sep 2006 19:15:57 -0700 (PDT) Message-ID: Date: Sun, 10 Sep 2006 22:15:58 -0400 From: "Michael Kaplan" To: "Frank Ellermann" Subject: Re: [Asrg] Re: A Technique for Universal Authentication In-Reply-To: <44FB7243.78C3@xyzzy.claranet.de> MIME-Version: 1.0 References: <20060901155001.1479.qmail@simone.iecc.com> <44F8A5DF.74B5@xyzzy.claranet.de> <44FA07BD.71A@xyzzy.claranet.de> <44FB7243.78C3@xyzzy.claranet.de> X-Spam-Score: 0.3 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098335698==" Errors-To: asrg-bounces@ietf.org --===============1098335698== Content-Type: multipart/alternative; boundary="----=_Part_151732_32191816.1157940958010" ------=_Part_151732_32191816.1157940958010 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/3/06, Frank Ellermann wrote: > > I guess we disagree about this, but as long as you reject all > SPF FAIL it won't affect me personally. I won't mind if you > challenge an SPF PASS from me, I'm free to ignore it or to > answer it - depends on what I want, I answer challenges from > say ICANN or IANA (again and again... so far ;-). Thank you for the feedback. Misdirected indiscriminant bounces are a major problem, so it is natural to presume that a widely enacted anti-spam system based on bounces would be absolutely disastrous. But what if bounces were not indiscriminant but were instead highly selective as I propose in a system that has been referred to as PER-CORRESPONDENT ADDRESS combined with CHALLENGE/RESPONSE sub-flavor MUA AUTO-RESPONSE? I call attention to the Ironport report on bounces. It provides the most useful data on the bounce problem that I've seen so far. The report is free from: http://www.ironport.com/company/ironport_pr_2006-04-24.html To summarize the hard data: -9% of global email traffic is misdirected bounce mail, 71% is spam/viruses/phishing, and 20% is legitimate. -Less than 0.5% of bounce messages make it through to the end user. -20% or more of what a spammer sends is bounced because of invalid addresses -55% of fortune 500 companies have experienced partial or total disruptions of service due to bounce caused DDoS -There are 4.5 billion misdirected bounce messages per day. 10% of these have valid addresses resulting in 450 million reaching mailboxes each day. For my system to be highly effective I will assume that one of the better email filters is being used and that 4% of spam and 4% of ham gets bounced. I pick these numbers as the graphs of filter performance at: http://sam.holden.id.au/writings/spam2/ Allowing a 4% bounce rate of suspected ham and spam transforms the top performing spam filters into nearly perfect filters. Keep in mind that the data from the above website was generated prior to current email authentication practices, and of course it doesn't take into account the fact that the use of sub-addresses on incoming mail will further improve filter performance. Filter performance would therefore likely be superior when used for my proposed system. The following is an analysis of how a properly implemented bounce based anti-spam system would impact the areas that are of the most concern when we think of misdirected bounces: *Effect on global email traffic* I will assume that 50% of global email accounts are protected by this system. (4% spam bounced)*(71% global spam)*(50% participation) = 1.42% (4% ham bounced)*(20% global ham)*(50% participation) = 0.4% 50% of the global email population is almost totally protected from spam at the cost of a 1.82% absolute increase in global email traffic. *Effect on DDoS* Currently if a spammer sends 100 million spam emails using the return address of a single company then 20 million misdirected bounces would hit that company's system. We will generously assume that 80 million of these spam emails target real addresses. Assuming 50% of the global population uses this system then: (80 million)*(50%)*(4%) = 1.6 million additional emails will hit the company's system resulting in a total of 21.6 million, an 8% increase in bounce volume. This 8% increase in volume during a DDoS is should be weighted against the benefit of nearly totally blocking spam to 50% of the global population. Actually a good filter is unlikely to mistake an unauthenticated email sent from a dubious server with a legitimate email from a Fortune 500 company. The true increase in the volume of bounce DDoS attacks for large companies is likely much less or almost non-existent. *Effect of diverting spam on the inboxes of third parties* Again assuming 50% of the global population uses this system: (50%)*(4%) = 2% relative increase in the amount of "spam" sent globally. (2%)*(10% of spam that spoofs an existing 'From' address) = 0.2% relative increase in global spam directed at real addresses. 50% of these misdirected spam bounces will target users of this system. Since the sub-address reproduces the benefit of BATV users of this system will be perfectly protected from these bounces. So only the remaining 50% of the global email population will face a 0.2% increase in the amount of spam. This also assumes that the third parties are not using other mechanisms, such BATV, to stop bounces. This bounce spam will still need to face all of the anti-spam mechanisms of the third party; content filters will still be able to evaluate the spammy material in the bounce. The bounce will contain the IP of the server that originated the spam so that the bounce recipient's filter can evaluate its reputation. On average we have at most a 0.2% increase in the average spam burden among nonusers of this system. As with DDoS attacks a small number of individuals may be disproportionately affected, but as with the DDoS example above these individuals will face at most an 8% increase in the amount of bounce spam. This slight increase in the amount of spam received by a small fraction of users is again weighted against the benefit of 50% of the population being free of spam. Michael Kaplan ------=_Part_151732_32191816.1157940958010 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On 9/3/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
>
> I guess we disagree about this, but as long as you reject all
> SPF FAIL it won't affect me personally.  I won't mind if you
> challenge an SPF PASS from me, I'm free to ignore it or to
> answer it - depends on what I want, I answer challenges from
> say ICANN or IANA (again and again... so far ;-).

Thank you for the feedback.  Misdirected indiscriminant bounces are a major problem, so it is natural to presume that a widely enacted anti-spam system based on bounces would be absolutely disastrous.  But what if bounces were not indiscriminant but were instead highly selective as I propose in a system that has been referred to as PER-CORRESPONDENT ADDRESS combined with CHALLENGE/RESPONSE sub-flavor MUA AUTO-RESPONSE?

I call attention to the Ironport report on bounces.  It provides the most useful data on the bounce problem that I've seen so far.  The report is free from:

http://www.ironport.com/company/ironport_pr_2006-04-24.html

To summarize the hard data:

-9% of global email traffic is misdirected bounce mail, 71% is spam/viruses/phishing, and 20% is legitimate.

-Less than 0.5% of bounce messages make it through to the end user.

-20% or more of what a spammer sends is bounced because of invalid addresses

-55% of fortune 500 companies have experienced partial or total disruptions of service due to bounce caused DDoS

-There are 4.5 billion misdirected bounce messages per day.  10% of these have valid addresses resulting in 450 million reaching mailboxes each day.


For my system to be highly effective I will assume that one of the better email filters is being used and that 4% of spam and 4% of ham gets bounced.  I pick these numbers as the graphs of filter performance at:

http://sam.holden.id.au/writings/spam2/

Allowing a 4% bounce rate of suspected ham and spam transforms the top performing spam filters into nearly perfect filters.  Keep in mind that the data from the above website was generated prior to current email authentication practices, and of course it doesn't take into account the fact that the use of sub-addresses on incoming mail will further improve filter performance.  Filter performance would therefore likely be superior when used for my proposed system.

The following is an analysis of how a properly implemented bounce based anti-spam system would impact the areas that are of the most concern when we think of misdirected bounces:

Effect on global email traffic
I will assume that 50% of global email accounts are protected by this system.

(4% spam bounced)*(71% global spam)*(50% participation) = 1.42%

(4% ham bounced)*(20% global ham)*(50% participation) = 0.4%

50% of the global email population is almost totally protected from spam at the cost of a 1.82% absolute increase in global email traffic.

Effect on DDoS
Currently if a spammer sends 100 million spam emails using the return address of a single company then 20 million misdirected bounces would hit that company's system.  We will generously assume that 80 million of these spam emails target real addresses.  Assuming 50% of the global population uses this system then:

(80 million)*(50%)*(4%) = 1.6 million additional emails will hit the company's system resulting in a total of 21.6 million, an 8% increase in bounce volume.

This 8% increase in volume during a DDoS is should be weighted against the benefit of nearly totally blocking spam to 50% of the global population.

Actually a good filter is unlikely to mistake an unauthenticated email sent from a dubious server with a legitimate email from a Fortune 500 company.  The true increase in the volume of bounce DDoS attacks for large companies is likely much less or almost non-existent.

 
Effect of diverting spam on the inboxes of third parties
Again assuming 50% of the global population uses this system:

(50%)*(4%) = 2% relative increase in the amount of "spam" sent globally.

(2%)*(10% of spam that spoofs an existing 'From' address) = 0.2% relative increase in global spam directed at real addresses.

50% of these misdirected spam bounces will target users of this system.  Since the sub-address reproduces the benefit of BATV users of this system will be perfectly protected from these bounces.  So only the remaining 50% of the global email population will face a 0.2% increase in the amount of spam.

This also assumes that the third parties are not using other mechanisms, such BATV, to stop bounces.  This bounce spam will still need to face all of the anti-spam mechanisms of the third party; content filters will still be able to evaluate the spammy material in the bounce.  The bounce will contain the IP of the server that originated the spam so that the bounce recipient's filter can evaluate its reputation.

On average we have at most a 0.2% increase in the average spam burden among nonusers of this system.  As with DDoS attacks a small number of individuals may be disproportionately affected, but as with the DDoS example above these individuals will face at most an 8% increase in the amount of bounce spam.  This slight increase in the amount of spam received by a small fraction of users is again weighted against the benefit of 50% of the population being free of spam.
 
 
Michael Kaplan
------=_Part_151732_32191816.1157940958010-- --===============1098335698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg --===============1098335698==--