From asrg-bounces@ietf.org Sun Sep 16 17:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=4.0 tests=BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1190592023.49914@G5MQq2Ux+6XuNVNxU5IMvg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 16 Sep 2007 17:27:02 -0700 (MST) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8H00MlO012767 for ; Sun, 16 Sep 2007 20:00:23 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX40a-0004Ov-PM; Sun, 16 Sep 2007 19:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX40Y-0004Oq-Qy for asrg@ietf.org; Sun, 16 Sep 2007 19:58:35 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX40X-00085k-H7 for asrg@ietf.org; Sun, 16 Sep 2007 19:58:34 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1147012rvb for ; Sun, 16 Sep 2007 16:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=8aBc0QJRQGtDJdIUAMMh2GI9uNIc6U5im7/2pjRjrgg=; b=cd/xWCahYJIxdJT1xre9PP/QAQmo3oVkrOex8+F82186s3u72jvSUb9m20VZGR2HjCclgF2J/B7dANDTMHhJHg1OSV7+3deik6PWJG8Pg0m6YGm0vs0l8hE8v9QmlFyW6o6xjWZHKsrav+x34Xd4BKNugd8BDfHcnFZns+ivcKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=E3BGwVu4pylYEWdUEJttI5WxUQj+pwUIdvzAlaGgZX30ar4KQCveefnYblgfnAkVJ+mjNK52etwmVs95IoRi89RyYvTUGqVOGqta5ixOca/TRtDz6TaPjrVzP4o87tmWdcd1w4fQs5p3fxacL5LstwCa9BCwTJ+ZC3y2gSD8apY= Received: by 10.115.59.4 with SMTP id m4mr64320wak.1189987112464; Sun, 16 Sep 2007 16:58:32 -0700 (PDT) Received: by 10.114.192.18 with HTTP; Sun, 16 Sep 2007 16:58:32 -0700 (PDT) Message-ID: Date: Sun, 16 Sep 2007 19:58:32 -0400 From: "Michael Kaplan" To: asrg@ietf.org MIME-Version: 1.0 X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Asrg] Receiver Initiated Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1920055803==" Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean --===============1920055803== Content-Type: multipart/alternative; boundary="----=_Part_9265_21542714.1189987112467" ------=_Part_9265_21542714.1189987112467 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I propose a method of rapidly achieving a near comprehensive SPF database. The core of this concept is that questionable unauthenticated email will be bounced; the return of this bounce authenticates the domain. This domain and the MTA listed in the return path of the resent bounce is now entered into a shared database. All future emails from this previously unauthenticated domain sent via this MTA will now be authenticated after consulting this newly established database. Existing SPF cannot authenticate forwarded email. My proposal employees multiple mechanisms to transparently overcome this other major flaw with SPF so that even forwarded email is authenticated. Existing authentication schemes are dependent on the participation of the senders of email. My proposal allows for the receiver to initiate the process of authentication. I therefore call this proposal Receiver Initiated Authentication (RIA). The process is detailed at: http://spamfizzle.com I argue that RIA will authenticate all questionable incoming email. Innocent third parties will be relatively unaffected by erroneous bounces. I also demonstrate how RIA is orders of magnitude superior to C/R. Sincerely, Michael Kaplan ------=_Part_9265_21542714.1189987112467 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I propose a method of rapidly achieving a near comprehensive SPF database.  The core of this concept is that questionable unauthenticated email will be bounced; the return of this bounce authenticates the domain.  This domain and the MTA listed in the return path of the resent bounce is now entered into a shared database.  All future emails from this previously unauthenticated domain sent via this MTA will now be authenticated after consulting this newly established database.

Existing SPF cannot authenticate forwarded email.  My proposal employees multiple mechanisms to transparently overcome this other major flaw with SPF so that even forwarded email is authenticated.

Existing authentication schemes are dependent on the participation of the senders of email.  My proposal allows for the receiver to initiate the process of authentication.  I therefore call this proposal Receiver Initiated Authentication (RIA).  The process is detailed at:

http://spamfizzle.com

I argue that RIA will authenticate all questionable incoming email.  Innocent third parties will be relatively unaffected by erroneous bounces.  I also demonstrate how RIA is orders of magnitude superior to C/R.

Sincerely,

Michael Kaplan




------=_Part_9265_21542714.1189987112467-- --===============1920055803== 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 --===============1920055803==-- From asrg-bounces@ietf.org Sun Sep 16 19:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190598577.00157@XLq0CLh2pMbW1UtrB15grg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 16 Sep 2007 19:27:02 -0700 (MST) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8H1nUqH024723 for ; Sun, 16 Sep 2007 21:49:35 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX5jg-0002J1-9r; Sun, 16 Sep 2007 21:49:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX5je-0002Iv-Q2 for asrg@ietf.org; Sun, 16 Sep 2007 21:49:14 -0400 Received: from fruitbat.wordtothewise.com ([208.187.80.135] helo=m.wordtothewise.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX5je-0003nf-1r for asrg@ietf.org; Sun, 16 Sep 2007 21:49:14 -0400 Received: from [10.3.2.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id DFC2D800CE for ; Sun, 16 Sep 2007 18:49:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Receiver Initiated Authentication Date: Sun, 16 Sep 2007 18:49:11 -0700 To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.752.3) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sep 16, 2007, at 4:58 PM, Michael Kaplan wrote: > I propose a method of rapidly achieving a near comprehensive SPF > database. The core of this concept is that questionable > unauthenticated email will be bounced; the return of this bounce > authenticates the domain. This domain and the MTA listed in the > return path of the resent bounce is now entered into a shared > database. All future emails from this previously unauthenticated > domain sent via this MTA will now be authenticated after consulting > this newly established database. > > Existing SPF cannot authenticate forwarded email. My proposal > employees multiple mechanisms to transparently overcome this other > major flaw with SPF so that even forwarded email is authenticated. > > Existing authentication schemes are dependent on the participation > of the senders of email. My proposal allows for the receiver to > initiate the process of authentication. I therefore call this > proposal Receiver Initiated Authentication (RIA). The process is > detailed at: > > http://spamfizzle.com > > It does seem to combine most of the worst anti-spam ideas of the past decade - it's got challenge-response, it's got "have to install new software in all MUAs to make it not suck", it's got graphical captchas in auto responses, it's got "each correspondent should use a different tagged address", it's got "you have to be able to read HTML email to make the captchas work". The end result doesn't look as bad as you'd expect from combining all those things. There's not requirement to use a web browser (just a mail client that can handle html, images and possibly forms). > I argue that RIA will authenticate all questionable incoming > email. Innocent third parties will be relatively unaffected by > erroneous bounces. I also demonstrate how RIA is orders of > magnitude superior to C/R. That's a big claim. It looks like the core of your approach is this: 1. If Spamassassin (or whatever tech) thinks the inbound mail to a tagged address is spam, permanently disable that tagged address and send a challenge-response to the From address, including a newly generated tagged address. Similarly for mail sent to a non-tagged address. 2. If the sender responds to the challenge, whitelist the IP address / domain combination. (Your description of this is very confusing, and seems to be badly misusing the term SPF to refer to something completely unrelated, so I may be missing something there). 3. Install software in all end users MUAs to automatically intercept inbound challenges and respond to them. 4. For some domains ("suspicious domains") use a different approach, incompatible with the universally distributed software in (3) and require the recipient to manually resend the message, after answering a graphical captcha embedded in the challenge. This will require an MUA to handle HTML and render images within the client. It seems that it will send unwanted email to strangers. It also seems to be more concerned with spam than with handling mail you actually want to receive. For example, the usual use of a tagged email address is to allow some entity to send you mail and avoid a lot of your normal content-based filters as only legitimate mail is expected to be sent to that tagged address. Terminating a compromised tagged address is something that'll happen very rarely, while having content that may trigger a content based filter sent to that tagged address may be fairly common in some cases. Your approach seems to consider only the rare case of a compromised tagged address, not the common case of a non-compromised tagged address. Your use of the terms "SPF" and "bounce" in your description seem to differ widely from accepted usage, so you may want to clean up some of the descriptions if you're looking for broader feedback. You'll also want to discuss why you believe this will not impact legitimate bulk email, such as mailing lists, as that's not clear from your current discussion. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 16 20:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1190600991.20637@amdeB/FlNuWQ7/1k6dSCXw X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 16 Sep 2007 20:27:02 -0700 (MST) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8H2Th64028558 for ; Sun, 16 Sep 2007 22:29:48 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX6Me-0007wh-MK; Sun, 16 Sep 2007 22:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX6Mc-0007vW-Uq for asrg@ietf.org; Sun, 16 Sep 2007 22:29:30 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX6Mb-0003bb-Eo for asrg@ietf.org; Sun, 16 Sep 2007 22:29:30 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1173827rvb for ; Sun, 16 Sep 2007 19:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=NlBe6jKS4BBLyI5bkriJHvwGrZ9Hh9RnHoTpPJkhp4Y=; b=uqIqG+hbPw3SLBmA0cO2dxZD6o2YHLyBSQFdmpCHLHYS9FFL7iMVIo5WrcNgrbg5soJY14YjQ6Y2vqLIPFARBYvM555KTcJwn36ZLuigGfCTW6P9RC55FUHFl1tcysrQMv3RMJHF8AIJizxqE+uiwPGIc27uqP1AskPXwBgxGgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=A8RaaVilcVN07pcm2395CX9PZHVxONZDsy/euilKUO4DQuRGSlz4+kn4LeGPZpCqNUUu+7pBnOzQwk3nkWOr8vKFFuvMKkPFHhb+OuFEvjanzR0UMfK3xi+gsGmqms4w5PI1jAa/h528wrrFU4B2GPVfzU1ge0m/lZJAViEKa08= Received: by 10.114.160.1 with SMTP id i1mr2705856wae.1189996168656; Sun, 16 Sep 2007 19:29:28 -0700 (PDT) Received: by 10.114.192.18 with HTTP; Sun, 16 Sep 2007 19:29:28 -0700 (PDT) Message-ID: Date: Sun, 16 Sep 2007 22:29:28 -0400 From: "Michael Kaplan" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 References: X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1896434612==" Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean --===============1896434612== Content-Type: multipart/alternative; boundary="----=_Part_9649_24485784.1189996168651" ------=_Part_9649_24485784.1189996168651 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It does seem to combine most of the worst anti-spam ideas of the past > decade - it's got challenge-response, Section 12 details how this system is orders of magnitude better than C/R it's got "have to install new > software in all MUAs to make it not suck" Even without a very simple (section 5.2) upgrade to MUAs the system will be unseen by almost every legitimate sender. , it's got graphical > captchas in auto responses, As referenced at the top of section six this will likely only be sent bulk senders with less-than-ideal sending practices. Other senders whose domains are under spammer control will also be receive graphical CAPTCHA (I guess it depends on how much sympathy you have for a compromised sender with a server sending a thousand ham a day along with a million spam). it's got "each correspondent should use a > different tagged address" They should, but they certainly don't have to. How is this a problem , it's got "you have to be able to read HTML > email to make the captchas work". Again, this only applies to an extremely small segment of senders with poor reputations. It's 2007, most clients can handle this. > I argue that RIA will authenticate all questionable incoming > > email. Innocent third parties will be relatively unaffected by > > erroneous bounces. I also demonstrate how RIA is orders of > > magnitude superior to C/R. 2. If the sender responds to the challenge, whitelist the IP > address / domain combination. (Your description of this is very > confusing, and seems to be badly misusing the term SPF to refer to > something completely unrelated, so I may be missing something there). No, you don't whitelist the IP. You add the IP and the sending domain from the resent bounce (the resent bounce has authenticated the domain) into a database. This database works just like SPF. Let us assume that the sender now emails a a third party. This third party can look at the sender's domain and sending IP. The third party then accesses this new database and is able to authenticate the sender. The sender only had to resend one bounce, and now the entire world can authenticate every future email sent from the senders domain via that IP. 4. For some domains ("suspicious domains") use a different approach, > incompatible with the universally distributed software in (3) and > require the recipient to manually resend the message, after answering > a graphical captcha embedded in the challenge. This will require an > MUA to handle HTML and render images within the client. Clients will only need a one time update, and they don't even need that. The bounce from Figure three is only sent to senders that despite authentication are still suspicious, but yes - the client will need to be able to display images. It seems that it will send unwanted email to strangers. Section 9 It also seems > to be more concerned with spam than with handling mail you actually > want to receive. For example, the usual use of a tagged email address > is to allow some entity to send you mail and avoid a lot of your > normal content-based filters as only legitimate mail is expected to > be sent to that tagged address. Terminating a compromised tagged > address is something that'll happen very rarely, while having content > that may trigger a content based filter sent to that tagged address > may be fairly common in some cases. Your approach seems to consider > only the rare case of a compromised tagged address, not the common > case of a non-compromised tagged address. I used sub-addresses is completely unique way. A non-compromised sub-address will effectively guarantee successful delivery of ham. I'm not entirely sure what aspect of my use of sub-addresses you are concerned about. Your use of the terms "SPF" and "bounce" in your description seem to > differ widely from accepted usage, so you may want to clean up some > of the descriptions if you're looking for broader feedback. It uses the same principle as SPF (a database connecting domains to sending MTAs) but yes, it is not literally SPF since only the administrators of the sending domains generate the real SPF database. You'll > also want to discuss why you believe this will not impact legitimate > bulk email, such as mailing lists, as that's not clear from your > current discussion. Legitamate bulk email senders who maintain good reputations will continue to have their email delivered directly to the inbox. This system will actually enhance delivery of legitimate bulk email; current filters simply junk much of the email from these senders, but my system will allow for their delivery (see section 12 item 3 and the related info in that section to see how RIA will perform in comparison to convention filtering). Thank you for your feedback, Michael ------=_Part_9649_24485784.1189996168651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


It does seem to combine most of the worst anti-spam ideas of the past
decade - it's got challenge-response,

Section 12 details how  this system is orders of  magnitude better than C/R

it's got "have to install new
software in all MUAs to make it not suck"

Even without a very simple (section 5.2) upgrade to MUAs the system will be unseen by almost every legitimate sender.

, it's got graphical
captchas in auto responses,

As referenced at the top of section six this will likely only be sent bulk senders with less-than-ideal sending practices.  Other senders whose domains are under spammer control will also be receive graphical CAPTCHA (I guess it depends on how much sympathy you have for a compromised sender with a server sending a thousand ham a day along with a million spam).

it's got "each correspondent should use a
different tagged address"

They should, but they certainly don't have to.  How is this a problem

, it's got "you have to be able to read HTML
email to make the captchas work".

Again, this only applies to an extremely small segment of senders with poor reputations.  It's 2007, most clients can handle this.

> I argue that RIA will authenticate all questionable incoming
> email.  Innocent third parties will be relatively unaffected by
> erroneous bounces.  I also demonstrate how RIA is orders of
> magnitude superior to C/R.


 

2. If the sender responds to the challenge, whitelist the IP
address / domain combination. (Your description of this is very
confusing,  and seems to be badly misusing the term SPF to refer to
something completely unrelated, so I may be missing something there).


No,  you don't whitelist the  IP.  You add the IP and the sending domain from the resent bounce (the resent bounce has authenticated the domain) into a database.  This database works just like SPF.  Let us assume that the sender now emails a a third party.  This third party can look at the sender's domain and sending IP.  The third party then accesses this new database and is able to authenticate the sender.  The sender only had to resend one bounce, and now the entire world can authenticate every future email sent from the senders domain via that IP.


 

4. For some domains ("suspicious domains") use a different approach,
incompatible with the universally distributed software in (3) and
require the recipient to manually resend the message, after answering
a graphical captcha embedded in the challenge. This will require an
MUA to handle HTML and render images within the client.

Clients will only need a one time update, and they don't even need that.  The bounce from Figure three is only sent to senders that despite authentication are still suspicious, but yes - the client will need to be able to display images.
 

It seems that it will send unwanted email to strangers.

Section 9

It also seems
to be more concerned with spam than with handling mail you actually
want to receive. For example, the usual use of a tagged email address
is to allow some entity to send you mail and avoid a lot of your
normal content-based filters as only legitimate mail is expected to
be sent to that tagged address. Terminating a compromised tagged
address is something that'll happen very rarely, while having content
that may trigger a content based filter sent to that tagged address
may be fairly common in some cases. Your approach seems to consider
only the rare case of a compromised tagged address, not the common
case of a non-compromised tagged address.

I used sub-addresses is completely unique  way.  A  non-compromised sub-address will effectively guarantee successful delivery of ham.  I'm not entirely sure what aspect of my use of sub-addresses you are concerned about.

Your use of the terms "SPF" and "bounce" in your description seem to
differ widely from accepted usage, so you may want to clean up some
of the descriptions if you're looking for broader feedback.

It uses the same principle as SPF (a database connecting domains to sending MTAs) but yes, it is not literally SPF since only the administrators of the sending domains generate the real SPF database.

You'll
also want to discuss why you believe this will not impact legitimate
bulk email, such as mailing lists, as that's not clear from your
current discussion.

Legitamate bulk email senders who maintain good reputations will continue to have their email delivered directly to the inbox.  This system will actually enhance delivery of legitimate bulk email; current filters simply junk much of the email from these senders, but my system will allow for their delivery (see section 12 item 3 and the related info in that section to see how RIA will perform in comparison to convention filtering).

Thank you for your feedback,

Michael

------=_Part_9649_24485784.1189996168651-- --===============1896434612== 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 --===============1896434612==-- From asrg-bounces@ietf.org Sun Sep 16 20:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190603989.51317@pbwiVdHRtU5eJxTHG7b1Lg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 16 Sep 2007 20:27:04 -0700 (MST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8H3JgDL000765 for ; Sun, 16 Sep 2007 23:19:47 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX78u-0003e1-NI; Sun, 16 Sep 2007 23:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX78t-0003do-Hr for asrg@ietf.org; Sun, 16 Sep 2007 23:19:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX78s-0004fj-B2 for asrg@ietf.org; Sun, 16 Sep 2007 23:19:23 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1023220nfb for ; Sun, 16 Sep 2007 20:19:21 -0700 (PDT) Received: by 10.78.122.16 with SMTP id u16mr1153927huc.1189999159246; Sun, 16 Sep 2007 20:19:19 -0700 (PDT) Received: by 10.78.131.14 with HTTP; Sun, 16 Sep 2007 20:19:19 -0700 (PDT) Message-ID: <7d6a0cac0709162019l9b3c1en440eedfd1a8984c6@mail.gmail.com> Date: Sun, 16 Sep 2007 22:19:19 -0500 From: "Al Iverson" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On 9/16/07, Michael Kaplan wrote: > Thank you for your feedback, My feedback is that you should build it, see how it actually works for you, convince others to try it. If you can drive mass adoption then you've got something. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove "lists" from my email address to reach me faster and directly. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Sep 16 20:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190604372.14057@dPE8Esg6yZ5zumQIRiMgig X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 16 Sep 2007 20:27:04 -0700 (MST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8H3Q6ht001835 for ; Sun, 16 Sep 2007 23:26:11 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX7FM-0007gb-J9; Sun, 16 Sep 2007 23:26:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX7FK-0007gQ-Pz for asrg@ietf.org; Sun, 16 Sep 2007 23:26:02 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX7FJ-0004ol-BP for asrg@ietf.org; Sun, 16 Sep 2007 23:26:02 -0400 Received: from [192.168.0.2] (adsl-68-122-40-14.dsl.pltn13.pacbell.net [68.122.40.14]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8H3Pgn5032386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Sep 2007 20:25:42 -0700 Message-ID: <46EDF3C4.7030802@dcrocker.net> Date: Sun, 16 Sep 2007 20:25:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Receiver Initiated Authentication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Steve Atkins wrote: > It does seem to combine most of the worst anti-spam ideas of the past > decade - it's got ... Other than that, Mrs. Lincoln, how did you like... -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 03:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190628831.50011@2H6+B+rmJZcaNu72POSgKQ X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 03:27:03 -0700 (MST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HADioR013817 for ; Mon, 17 Sep 2007 06:13:49 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDbU-0007OW-ME; Mon, 17 Sep 2007 06:13:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDbT-0007OO-Bl for asrg@ietf.org; Mon, 17 Sep 2007 06:13:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXDbS-00013L-NG for asrg@ietf.org; Mon, 17 Sep 2007 06:13:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IXDbQ-0004Oh-Na for asrg@ietf.org; Mon, 17 Sep 2007 12:13:16 +0200 Received: from pd956aa3a.dip0.t-ipconnect.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Sep 2007 12:13:16 +0200 Received: from nobody by pd956aa3a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Sep 2007 12:13:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: "Frank Ellermann" Date: Mon, 17 Sep 2007 12:11:13 +0200 Lines: 65 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd956aa3a.dip0.t-ipconnect.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Asrg] Re: Receiver Initiated Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Michael Kaplan wrote: > The core of this concept is that questionable unauthenticated email > will be bounced I hope you mean "rejected", unsolicited bounces are evil. If whatever you do is some kind of "receiver generated SPF database" I also hope that folks like me, where all legit mails get a PASS, and anything else (including traditional forwarder scenarios) gets an SPF FAIL, don't need to worry about your concept. =20 But I'm far from confident that that's the case, there are dubious statements on your page. Example: | A perfectly comprehensive SPF record would require every domain | administrator in the world to constantly update their domain's | SPF record; an impossible expectation. As long as the IPs and/or domain names describing the "border" of an alleged sender don't change the administrator has no reason to touch her SPF sender policy. =20 > Existing SPF cannot authenticate forwarded email. To some degree it can, receivers are free to whitelist forwarders based on a HELO PASS for the outgoing MTAs of trusted forwarders, and forwarders are free to become redistributors, i.e rewrite the MAIL FROM. > overcome this other major flaw with SPF JFTR, that's only the short story. The long story is that this is a major flaw in the "simplified" e-mail architecture, specifically in RFC 1123 5.3.6(a), inherited by RFC 2821. In the "original" RFC 821 architecture each hop (including forwarders) had to modify the MAIL FROM resulting in a literal concept of "return path". Actually SPF offers to fix this major flaw in the SMTP architecture without "return routes" (see RFC 821 for the technical details, or the summary in an appendix of RFC 2821). Traditional RFC 1123 5.3.6(a) forwarding is broken by design. And domain administrators publishing an SPF FAIL policy know that this is the case, and accept that that their mail will be rejected by receivers supporting SPF in traditional forwarding scenarios. It's the price for getting rid of tons of bogus bounces for forged mails. And nobody's forced to pay this price until they actually need it, but I digress. =20 [RIA] > Innocent third parties will be relatively unaffected by erroneous > bounces. If innocent third parties with an SPF PASS/FAIL policy are affected your system is broken. Many SPF participants can't add BATV to their setup, or won't even if they could for various reasons. =20 If innocent third parties without BATV or without SPF PASS/FAIL policy are "relatively unaffected" they might have their own opinion about this issue. As an example I'd never allow Outlook Express to send "auto-responses". It's bad enough that I use this software at the moment. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 03:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190628919.30176@0B6FHIVeALq7WHKKn4I9pg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 03:27:04 -0700 (MST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HAFDqU013986 for ; Mon, 17 Sep 2007 06:15:18 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDdH-0001o3-LC; Mon, 17 Sep 2007 06:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDdF-0001fJ-HY for asrg@ietf.org; Mon, 17 Sep 2007 06:15:09 -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 1IXDdD-0007SE-Rp for asrg@ietf.org; Mon, 17 Sep 2007 06:15:09 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IXDd8-0004XO-0h for asrg@ietf.org; Mon, 17 Sep 2007 12:15:02 +0200 Received: from pd956aa3a.dip0.t-ipconnect.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Sep 2007 12:15:02 +0200 Received: from nobody by pd956aa3a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Sep 2007 12:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: "Frank Ellermann" Date: Mon, 17 Sep 2007 12:07:45 +0200 Lines: 65 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd956aa3a.dip0.t-ipconnect.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Asrg] Re: Receiver Initiated Authentication X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Michael Kaplan wrote: > The core of this concept is that questionable unauthenticated email > will be bounced I hope you mean "rejected", unsolicited bounces are evil. If whatever you do is some kind of "receiver generated SPF database" I also hope that folks like me, where all legit mails get a PASS, and anything else (including traditional forwarder scenarios) gets an SPF FAIL, don't need to worry about your concept. =20 But I'm far from confident that that's the case, there are dubious statements on your page. Example: |A perfectly comprehensive SPF record would require every domain = administrator in the world | to constantly update their domain's SPF record; an impossible = expectation. As long as the IPs and/or domain names describing the "border" of an = alleged sender don't change the administrator has no reason to touch her SPF sender policy. =20 > Existing SPF cannot authenticate forwarded email. To some degree it can, receivers are free to whitelist forwarders based on a HELO PASS for the outgoing MTAs of trusted forwarders, and forwarders are free to rewrite the MAIL FROM. > overcome this other major flaw with SPF JFTR, that's only the short story. The long story is that this is a major flaw in the "simplified" e-mail architecture, specifically in RFC 1123 5.3.6(a), inherited by RFC 2821. In the "original" RFC 821 architecture each hop (including forwarders) had to modify the MAIL FROM resulting a literal concept of "return path". Actually SPF offers to fix this major flaw in the SMTP architecture without "return routes" (see RFC 821 for the technical details, or the summary in an appendix of RFC 2821). Traditional RFC 1123 5.3.6(a) forwarding is broken by design. And domain administrators publishing an SPF FAIL policy know that this is the case, and accept that that their mail will be rejected by receivers supporting SPF in traditional forwarding scenarios. It's the price for getting rid of tons of bogus bounces for forged mails. And nobody's forced to pay this price until they actually need it, but I digress. =20 [RIA] > Innocent third parties will be relatively unaffected by erroneous > bounces. If innocent third parties with an SPF PASS/FAIL policy are affected your system is broken. Many SPF participants can't add BATV to their setup, or won't even if they could for various reasons. =20 If innocent third parties without BATV or without SPF PASS/FAIL policy are "relatively unaffected" they might have their own opinion about this issue. As an example I'd never allow Outlook Express to send "auto-responses". It's bad enough that I use this software at the moment. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 09:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190649190.42167@q5wlK1BMwC610gonNFxEHg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 09:27:02 -0700 (MST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HFr0Ke007381 for ; Mon, 17 Sep 2007 11:53:05 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXItq-0003k4-SX; Mon, 17 Sep 2007 11:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXItq-0003jz-1i for asrg@ietf.org; Mon, 17 Sep 2007 11:52:38 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXIto-0007Bk-GY for asrg@ietf.org; Mon, 17 Sep 2007 11:52:38 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2763424wah for ; Mon, 17 Sep 2007 08:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=vzG1o8t4maZ/POJfYn7ifqGcC0RVppoIGtJ6gBQC168=; b=Utz3djmU2Ypgf44kQnlq+4weRdlcZP5wqzBWglq5zoII88IIAhCSXmJYtpKM+IpCqd0DWnhibU2Kuze1vv3Bv0FpHWb4WGH5I/0I8rlEw0OpBhk6ErR3hEt4u/6ZJYbLRrb2TnQTFp8yJkI3s+He0L6Czmb1wlzKrBvMoC+jUEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=FAx0g3UOLL1mCn/lB189e0imOCytKoGxseCNeJ83BsScFsMO6QywPkgwFR/+ioWlT8l/p1KLsMiU3VEnT5owe46Sp5UQamQt7QjBhTG6yNsjHyM4QXksXy7LRmG8CjsMRvnmVJYxBmXuBHYb4PwMe/X5uMFa2IUKLa61QT6X/h8= Received: by 10.115.23.12 with SMTP id a12mr778725waj.1190044355309; Mon, 17 Sep 2007 08:52:35 -0700 (PDT) Received: by 10.114.192.18 with HTTP; Mon, 17 Sep 2007 08:52:35 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 11:52:35 -0400 From: "Michael Kaplan" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 References: X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1909162345==" Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean --===============1909162345== Content-Type: multipart/alternative; boundary="----=_Part_12628_33371557.1190044355289" ------=_Part_12628_33371557.1190044355289 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/17/07, Frank Ellermann wrote: > > Michael Kaplan wrote: > > > The core of this concept is that questionable unauthenticated email > > will be bounced > > I hope you mean "rejected", unsolicited bounces are evil. Yes, in section 9 I summarize the Ironport data on the bounce problem, and it is a real problem. Sometimes legitimate email is unauthenticated; adopting a policy of absolutely never sending a bounce in response to an unauthenticated email will degrade the integrity of email. Banning all such bounces solves one problem and creates another. Indiscriminate bounces are the real problem with bounces. In section 9 I demonstrate what would happen if 50% of the global email population used RIA and 4% of incoming spam was bounced. The conclusion is that the average user will receive a 0.2% increase in 'spam' volume. Some individuals/entities will suffer a DDoS attack as their domains are heavily spoofed by spammers. In this worse case scenario RIA will increase their email volume by only 5% despite having 50% global participation in RIA. Again the real problem with bounces is indiscriminate bouncing, highly selective bouncing is relatively inconsequential. 50% of the global population would have near perfect protection from spam in exchange for only a slight increase in erroneous bounces. If whatever > you do is some kind of "receiver generated SPF database" I also hope > that folks like me, where all legit mails get a PASS, and anything > else (including traditional forwarder scenarios) gets an SPF FAIL, > don't need to worry about your concept. Any email that gets an SPF FAIL will never be bounced. You never send spammy email, and all of your email is already authenticated. You will never even be aware of the existence of RIA as your emails will never be bounced. You need never use a sub-address, or you can use a deactivated sub-address - it really doesn't matter since your emails are unambiguously ham so they will always directly reach the inbox. Almost all email sent by individuals is unambiguously ham; most individual senders will remain completely unaffected by RIA. But I'm far from confident that that's the case, there are dubious > statements on your page. Example: > > | A perfectly comprehensive SPF record would require every domain > | administrator in the world to constantly update their domain's > | SPF record; an impossible expectation. > > As long as the IPs and/or domain names describing the "border" of an > alleged sender don't change the administrator has no reason to touch > her SPF sender policy. This is good; RIA will never block authenticated email from reputable senders. RIA will almost exclusively impact the less responsible senders who do not authenticate and also get a poor rating via a statistical filter. > Existing SPF cannot authenticate forwarded email. > > To some degree it can, receivers are free to whitelist forwarders > based on a HELO PASS for the outgoing MTAs of trusted forwarders, > and forwarders are free to become redistributors, i.e rewrite the > MAIL FROM. This is also good; email sent via trusted forwarders will be considered authenticated and RIA will not obstruct it. Some forwarders employ SRS, but some don't. Email sent without a sub-address via an untrusted forwarder that does not employ SRS will get bounced... but only if a statistical filter classifies the email as 'unsure'. > [RIA] > > Innocent third parties will be relatively unaffected by erroneous > > bounces. > > If innocent third parties with an SPF PASS/FAIL policy are affected > your system is broken. Many SPF participants can't add BATV to their > setup, or won't even if they could for various reasons. Bounces will not be sent to an SPF FAIL. See section 9 as to the impact on innocent third parties. If innocent third parties without BATV or without SPF PASS/FAIL > policy are "relatively unaffected" they might have their own opinion > about this issue. As an example I'd never allow Outlook Express to > send "auto-responses". It's bad enough that I use this software at > the moment. If you (and 50% of the global email population) instituted RIA and subsequently became almost completely spam free, could you then live with the fact that non-participants in RIA and non-participants in BATV will suffer an average of a 0.2% increase in spam volume? Yes, a very small number of individuals will suffer a 5% increase in erroneous bounce traffic. 50% of the email population living spam free would be an extraordinary thing; I for one would be willing to live with the guilt. Thank you for you input, Michael ------=_Part_12628_33371557.1190044355289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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

> The core of this concept is that questionable unauthenticated email
> will be bounced

I hope you mean "rejected", unsolicited bounces are evil.

Yes, in section 9  I summarize the Ironport data on the bounce problem, and it is a real problem.
Sometimes legitimate email is unauthenticated; adopting a policy of absolutely never sending a bounce in response to an unauthenticated email will degrade the integrity of email.  Banning all such bounces solves one problem and creates another.

Indiscriminate bounces are the real problem with bounces.  In section 9 I demonstrate what would happen if 50% of the global email population used RIA and 4% of incoming spam was bounced.  The conclusion is that the average user will receive a 0.2% increase in 'spam' volume.
Some individuals/entities will suffer a DDoS attack as their domains are heavily spoofed by spammers.  In this worse case scenario RIA will increase their email volume by only 5% despite having 50% global participation in RIA.

Again the real problem with bounces is indiscriminate bouncing, highly selective bouncing is relatively inconsequential.  50% of the global population would have near perfect protection from spam in exchange for only a slight increase in erroneous bounces.

  If whatever
you do is some kind of "receiver generated SPF database" I also hope
that folks like me, where all legit mails get a PASS, and anything
else (including traditional forwarder scenarios) gets an SPF FAIL,
don't need to worry about your concept.

Any email that gets an SPF FAIL will never be bounced.
You never send spammy email, and all of your email is already authenticated.  You will never even be aware of the existence of RIA as your emails will never be bounced.  You need never use a sub-address, or you can use a deactivated sub-address - it really doesn't matter since your emails are unambiguously ham so they will always directly reach the inbox.  Almost all email sent by individuals is unambiguously ham; most individual senders will remain completely unaffected by RIA.
 

But I'm far from confident that that's the case, there are dubious
statements on your page.  Example:

| A perfectly comprehensive SPF record would require every domain
| administrator in the world to constantly update their domain's
| SPF record; an impossible expectation.

As long as the IPs and/or domain names describing the "border" of an
alleged sender don't change the administrator has no reason to touch
her SPF sender policy.

This is good; RIA will never block authenticated email from reputable senders.  RIA will almost exclusively impact the less responsible senders who do not authenticate and also get a poor rating via a statistical filter.

> Existing SPF cannot authenticate forwarded email.

To some degree it can, receivers are free to whitelist forwarders
based on a HELO PASS for the outgoing MTAs of trusted forwarders,
and forwarders are free to become redistributors, i.e rewrite the
MAIL FROM.

This is also good; email sent via trusted forwarders will be considered authenticated and RIA will not obstruct it.  Some forwarders employ SRS, but some don't.  Email sent without a sub-address via an untrusted forwarder that does not employ SRS will get bounced... but only if a statistical filter classifies the email as 'unsure'.

 
[RIA]
> Innocent third parties will be relatively unaffected by erroneous
> bounces.

If innocent third parties with an SPF PASS/FAIL policy are affected
your system is broken.  Many SPF participants can't add BATV to their
setup, or won't even if they could for various reasons.

Bounces will not be sent to an SPF FAIL.  See section 9 as to the impact on innocent third parties.

If innocent third parties without BATV or without SPF PASS/FAIL
policy are "relatively unaffected" they might have their own opinion
about this issue.  As an example I'd never allow Outlook Express to
send "auto-responses".  It's bad enough that I use this software at
the moment.

If you (and 50% of the global email population) instituted RIA and subsequently became almost completely spam free, could you then live with the fact that non-participants in RIA and non-participants in BATV will suffer an average of a 0.2% increase in spam volume?  Yes, a very small number of individuals will suffer a 5% increase in erroneous bounce traffic.  50% of the email population living spam free would be an extraordinary thing; I for one would be willing to live with the guilt.

Thank you for you input,
Michael
------=_Part_12628_33371557.1190044355289-- --===============1909162345== 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 --===============1909162345==-- From asrg-bounces@ietf.org Mon Sep 17 09:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190649446.2883@6knnUMRzQH53Uf4iQtQ2Yw X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 09:27:03 -0700 (MST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HFvHkW007967 for ; Mon, 17 Sep 2007 11:57:23 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXIyH-0000x6-Ic; Mon, 17 Sep 2007 11:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXIyG-0000wy-RU for asrg@ietf.org; Mon, 17 Sep 2007 11:57:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXIyF-0007HR-MV for asrg@ietf.org; Mon, 17 Sep 2007 11:57:12 -0400 Received: by wr-out-0506.google.com with SMTP id 70so593324wra for ; Mon, 17 Sep 2007 08:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=bdVicXNE9n6VMMEi8xyzvTY2qao2el19AAetQGxZGEM=; b=K1TtM0QiHBCxbnCe2kDqcLbto2mhXabcwRXWXsiHXKuhklHFNHwgp8eFKRzGmgWQmpA02mJlh7zOI7U8krLrP4zICw/wYIEB7z6RC3vpNeKQvi1EcT0jikSKG5af6kls3YV8h0LemnStUxLPBU4CnumIp+WiH9+YJEPcVOx+UKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=NoLFvPdtoJ1vDLXgNJAy6Hn9nuMhcOLY4Xgnvkk4LgmwgyNDMsXJyzw5S2jBuXE/xkEoeTlDcgFge0vqBKmXhMvfos/Q+X1CBxRCCfxn5JlG3QtIZgJlaKXhhfhYqwF6BJ97DrzFcFX1FLuvZt/RJd1gGbQ4CCOkRcSJi1ZxmBU= Received: by 10.78.200.20 with SMTP id x20mr2786062huf.1190044629313; Mon, 17 Sep 2007 08:57:09 -0700 (PDT) Received: by 10.78.29.4 with HTTP; Mon, 17 Sep 2007 08:57:09 -0700 (PDT) Message-ID: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> Date: Mon, 17 Sep 2007 16:57:09 +0100 From: "Peter Bowyer" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: ef6d4467640b0a49 X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On 17/09/2007, Michael Kaplan wrote: > > > On 9/17/07, Frank Ellermann wrote: > > Michael Kaplan wrote: > > > > > The core of this concept is that questionable unauthenticated email > > > will be bounced > > > > I hope you mean "rejected", unsolicited bounces are evil. > > Yes, in section 9 I summarize the Ironport data on the bounce problem, and > it is a real problem. > Sometimes legitimate email is unauthenticated; adopting a policy of > absolutely never sending a bounce in response to an unauthenticated email > will degrade the integrity of email. Banning all such bounces solves one > problem and creates another. Your use of 'Yes' in your answer to Frank was clearly in the sense of 'No'. Unsolicited bounces are evil, and you're still proposing to send them. This is bad. Why are you not talking about SMTP-time rejections, which are not evil and don't suffer the same issues? Peter -- Peter Bowyer Email: peter@bowyer.org _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 10:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190651231.3186@gDEhdbT66wMsnOjbdYP/UA X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 10:27:04 -0700 (MST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HGR37l012161 for ; Mon, 17 Sep 2007 12:27:08 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJR0-0005tB-DG; Mon, 17 Sep 2007 12:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJQz-0005t6-D4 for asrg@ietf.org; Mon, 17 Sep 2007 12:26:53 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXJQy-00086X-23 for asrg@ietf.org; Mon, 17 Sep 2007 12:26:53 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2777103wah for ; Mon, 17 Sep 2007 09:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=SXG4n6TFmwVthS7cvyQjMW0iwwq1cerqhiT/M7rov/8=; b=sYmiHZbE0pDhq7u2yS4cqLIyRtA4PttIurD9UgnoDDBAH6poPJYlgiSkLVkBwmJlp2PQ26GOlYrFwnZeNCeVx6Z3F/EwRgc2/wvItdnFVmTOeE1jwrvKXSCKTbnCB42B6aYaCTxGxL6NVT2+FZTsTtgHI1B5ypJFyNg9fvwZGH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=f61adc0A6dG8gnSycZn2BsbhBSVlg02pZRnRf7x+sACcqwIdsY/UZW1HPnC+UaNzA/mjhFJshJqYmKrAsHlyq0NEVyL5J5bnwVZZ9tr74To3Qtwza5zNbt+Cy/yorvdF1yJ7tiQcAIwT/2Ij4FlO13Liggcqu8O8+vtL6nDtYAQ= Received: by 10.114.179.1 with SMTP id b1mr314284waf.1190046409569; Mon, 17 Sep 2007 09:26:49 -0700 (PDT) Received: by 10.114.192.18 with HTTP; Mon, 17 Sep 2007 09:26:49 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 12:26:49 -0400 From: "Michael Kaplan" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> MIME-Version: 1.0 References: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1932146922==" Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean --===============1932146922== Content-Type: multipart/alternative; boundary="----=_Part_12796_1931942.1190046409466" ------=_Part_12796_1931942.1190046409466 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/17/07, Peter Bowyer wrote: > > On 17/09/2007, Michael Kaplan wrote: > > > > > > On 9/17/07, Frank Ellermann wrote: > > > Michael Kaplan wrote: > > > > > > > The core of this concept is that questionable unauthenticated email > > > > will be bounced > > > > > > I hope you mean "rejected", unsolicited bounces are evil. > > > > Yes, in section 9 I summarize the Ironport data on the bounce problem, > and > > it is a real problem. > > Sometimes legitimate email is unauthenticated; adopting a policy of > > absolutely never sending a bounce in response to an unauthenticated > email > > will degrade the integrity of email. Banning all such bounces solves > one > > problem and creates another. > > Your use of 'Yes' in your answer to Frank was clearly in the sense of > 'No'. Unsolicited bounces are evil, and you're still proposing to send > them. This is bad. Why are you not talking about SMTP-time rejections, > which are not evil and don't suffer the same issues? > > > Peter I am concerned about forwarded email. Once the Receiver Generated SPF database is established then most of the unauthenticated ham will come via forwarders who already accepted the original email. I'm open to any suggestions on how to work around this, otherwise I still argue that highly selective bounces are only mildly evil. If we quantify evilness then: Massive quantities of spam >> small number of misdirected/easily filtered by BATV bounces. I'm arguing for the lesser of two evils, and I argue that my evil is much much smaller than the evil of existing spam. Michael ------=_Part_12796_1931942.1190046409466 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/17/07, Peter Bowyer <peter@bowyer.org> wrote:
On 17/09/2007, Michael Kaplan <michaelkaplanasrg@gmail.com> wrote:
>
>
> On 9/17/07, Frank Ellermann <nobody@xyzzy.claranet.de > wrote:
> > Michael Kaplan wrote:
> >
> > > The core of this concept is that questionable unauthenticated email
> > > will be bounced
> >
> > I hope you mean "rejected", unsolicited bounces are evil.
>
> Yes, in section 9  I summarize the Ironport data on the bounce problem, and
> it is a real problem.
> Sometimes legitimate email is unauthenticated; adopting a policy of
> absolutely never sending a bounce in response to an unauthenticated email
> will degrade the integrity of email.  Banning all such bounces solves one
> problem and creates another.

Your use of 'Yes' in your answer to Frank was clearly in the sense of
'No'. Unsolicited bounces are evil, and you're still proposing to send
them. This is bad. Why are you not talking about SMTP-time rejections,
which are not evil and don't suffer the same issues?


Peter

I am concerned about forwarded email.  Once the Receiver Generated SPF database is established then most of the unauthenticated ham will come via forwarders who already accepted the original email.  I'm open to any suggestions on how to work around this, otherwise I still argue that highly selective bounces are only mildly evil.

If we quantify evilness then:  Massive quantities of spam >> small number of misdirected/easily filtered by BATV bounces.

I'm arguing for the lesser of two evils, and I argue that my evil is much much smaller than the evil of existing spam.

Michael
------=_Part_12796_1931942.1190046409466-- --===============1932146922== 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 --===============1932146922==-- From asrg-bounces@ietf.org Mon Sep 17 10:27:06 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190653772.80121@Fxoa202nZxHWWSLMpGV+BQ X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 10:27:06 -0700 (MST) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HH91fH018837 for ; Mon, 17 Sep 2007 13:09:08 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXK5V-0000CW-Ro; Mon, 17 Sep 2007 13:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXK5T-0000CR-U6 for asrg@ietf.org; Mon, 17 Sep 2007 13:08:43 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXK5S-0001Am-Jx for asrg@ietf.org; Mon, 17 Sep 2007 13:08:43 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1359294rvb for ; Mon, 17 Sep 2007 10:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ko9L9PkTgdjdRIV2uIbr7KDetlwpnY40Jt28JkCqy1o=; b=X9L2iQUyKi6iD3Hx6vH+1gDMQm84yjH0Ju0TfJAGeXu0VlW6tRTFoPqVZ/6Kmb0Ks5aQs2sh06s5D87qWaJR4Jh6EHRY4O0j2QfjCGd/ivb5s6VkdAOHXzPlpT1tzTp9+CJcOvKi7KrpMf5rDRPxPCcuUp+qM/hJ5dd/bwm0Z/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I5zx00u6mA9JYZl0ylxxpJ8Vd3N8xYrSIbgENOx3m2UP4jvjguGQSx/tLd99GhTmlDHLoT7+OO8yKNneAb7jUHo+LLxXbMfbYrs1i9A2Cr7fuAESN5dzOYfYWqZ1om0bjK5Kk1Gprr3IAmHY7tS6UCyrdyLVXl+lhaqQhGIllgQ= Received: by 10.114.25.3 with SMTP id 3mr3508635way.1190048920549; Mon, 17 Sep 2007 10:08:40 -0700 (PDT) Received: by 10.114.240.12 with HTTP; Mon, 17 Sep 2007 10:08:40 -0700 (PDT) Message-ID: <934f64a20709171008o6e53406frece021f53d12f27d@mail.gmail.com> Date: Mon, 17 Sep 2007 12:08:40 -0500 From: "David Nicol" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On 9/17/07, Michael Kaplan wrote: > > I am concerned about forwarded email. Once the Receiver Generated SPF > database is established then most of the unauthenticated ham will come via > forwarders who already accepted the original email. I'm open to any > suggestions on how to work around this, otherwise I still argue that highly > selective bounces are only mildly evil. Quarantine (or soft-fail) and query the recipient. Parse the headers in the forwarded message; if a spf-good appears earlier, offer the addressee the option of whitelisting the final relay. The addressee has signed up for the protection, knowing there may be a touch of configuration. Integrate with reputation systems (and refer to documentation strongly suggesting using a SPF-compliant RFC 821 "SRS" envelope instead of a simplified one) in the 450 rejection) and statistical analysis in deciding how to dispose of such messages. -- "I will not tolerate continued noncompliance" -- Neelie Kroes _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 11:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190655139.4627@F2RGAI7mZYsYNjAsXYCEhw X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 11:27:04 -0700 (MST) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HHWDeK022215 for ; Mon, 17 Sep 2007 13:32:19 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXKSA-00031U-9M; Mon, 17 Sep 2007 13:32:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXKS8-00031F-As for asrg@ietf.org; Mon, 17 Sep 2007 13:32:08 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXKS7-00054S-NF for asrg@ietf.org; Mon, 17 Sep 2007 13:32:08 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8HHVWbY001978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2007 10:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190050313; x=1190136713; bh=HhPUkYDMA5h9WUB3uMExDp37q3jUo8Z5VjGl 6vjKTl8=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=EWo fqdBNC/4qGKXHbfYSTp+CU4ijtDSH8NDl0prpJZg+qtBW8qX48XX+WHFLRGU/UwZm+U yxkQWSV9Zsrq+erx6y5V+MyJcaUqT3xkNfypRNGmVkdHT3XiBFclkQGXKMi9eh+wzvG ti63XESOzGm+UzNmbYsaarlpvu/SkWMjbQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=j3kbYOLr7uHZQx9in/pPA/HKFxNzocFQ4/2yi3Euu1II+oCKnJ5zWD9h8+4PlQXpo nIg+5qu7tEAFZ/aIyrrFWJ2WmSC3BZIGfJv/FzBwcosdcQmbPC8Dwn0+8JA9fyTCpLh rVamrpzLQl4iQ99/ICoR24GPuVtS1fF0puNnpms= Message-Id: <6.2.5.6.2.20070917094159.02dc25b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 17 Sep 2007 10:31:20 -0700 To: Anti-Spam Research Group - IRTF From: SM Subject: Re: [Asrg] Receiver Initiated Authentication In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean At 16:58 16-09-2007, Michael Kaplan wrote: >I propose a method of rapidly achieving a near comprehensive SPF >database. The core of this concept is that questionable >unauthenticated email will be bounced; the return of this bounce >authenticates the domain. This domain and the MTA listed in the >return path of the resent bounce is now entered into a shared >database. All future emails from this previously unauthenticated >domain sent via this MTA will now be authenticated after consulting >this newly established database. As this is a research group, it's good to see new proposals like yours. Your proposal, like a few others, revolves around Challenge/Response. Once we start meddling with bounces, we make that feature even more unreliable. Near universal distribution of Auto-Resend software is not as easy as it sounds. If you cannot get the administrators to update their systems, then you won't get hundred times more people upgrading their software. The cost will be much more if you upgrade the client software. CAPTCHA has been circumvented. Getting users to a website to solve a CAPTCHA is not that difficult. If spammers did not get more than an insignificant number of people to visit their website, they would not have been in business. CAPTCHA also has usability issues. A Single Universal Receiver Generated SPF Database is like having a single worldwide authority responsible for email. This raises questions about control and cost. I suggest that you don't underestimate the technical prowless of spammers. Regards, -sm _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 11:27:05 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190657577.51124@hAfOp5ZTYfEsk/3iWh77Ig X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 11:27:05 -0700 (MST) Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HICpXX028354 for ; Mon, 17 Sep 2007 14:12:56 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXL5H-000246-EN; Mon, 17 Sep 2007 14:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXL5G-00021I-5h for asrg@ietf.org; Mon, 17 Sep 2007 14:12:34 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXL5F-0003Rh-04 for asrg@ietf.org; Mon, 17 Sep 2007 14:12:34 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8HIAA820443 for ; Mon, 17 Sep 2007 18:10:10 GMT Received: from [47.130.16.51] ([47.130.16.51] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 14:12:29 -0400 Message-ID: <46EEC382.3090305@nortel.com> Date: Mon, 17 Sep 2007 14:12:18 -0400 From: "Chris Lewis" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Receiver Initiated Authentication References: <6.2.5.6.2.20070917094159.02dc25b0@resistor.net> In-Reply-To: <6.2.5.6.2.20070917094159.02dc25b0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 18:12:30.0021 (UTC) FILETIME=[4F88AF50:01C7F956] X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean SM wrote: > I suggest that you don't underestimate the technical prowless of spammers. Freudian slip? ;-) I can't help thinking that spammers will have a field day spamming themselves with forged, say, @hotmail.com, doing the captchas to "approve" bogus IPs, and then firehosing the world with what would now verify. The Nigerian 419 hordes would have fun. Frankly, also, much as I'm not fond of SPF, I'd object to having our SPF policy subverted to lend additional credibility to entities that aren't under _our_ control. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 12:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190659647.6453@jnA8vSp/Zd3zyVvFDKzVbA X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 12:27:04 -0700 (MST) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HIlJJ8000389 for ; Mon, 17 Sep 2007 14:47:27 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXLck-0000qZ-Hl; Mon, 17 Sep 2007 14:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXLci-0000q8-4H for asrg@ietf.org; Mon, 17 Sep 2007 14:47:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXLcg-0004xi-7i for asrg@ietf.org; Mon, 17 Sep 2007 14:47:07 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2385525uge for ; Mon, 17 Sep 2007 11:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=40usJ5tibCy7S7G8eBW4ZpV2qW6EEom8UaMEEn5GmHI=; b=Q9eNLOXQcfxqhhBMmQ7dNKPgKD6FQzWVY6/5ju6Zsd0+04QjMkUoQ2R8Wo9NKB4pfNeE8H9vIi2n2qllfO/9fwcuzC8e8zA4PkFiaks8wDh591Qe3N9w0CvCz7nQ09zHe/LC/TPorLCtDUY181qWDzk9/Z0ls+g7av78ubbU170= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZqNHO9PBrL2NYQHq3oeMC6iIEK28iXVvUSnIuCfpaaii55e1rqsdPL2Uh/E5ga90mCCgg0YwrmVHSOSD9TqA2fsafAYyXI2utzBgi6yGbbhDZ9/JGbT10h1AZXZ4QOQGrec35313qihUZkIzKESxgRe2noFTWqGKT3YkmbuZosM= Received: by 10.78.172.20 with SMTP id u20mr2973638hue.1190054824956; Mon, 17 Sep 2007 11:47:04 -0700 (PDT) Received: by 10.78.29.4 with HTTP; Mon, 17 Sep 2007 11:47:04 -0700 (PDT) Message-ID: <56152ae90709171147o644a35c5qa3f980816eca53fd@mail.gmail.com> Date: Mon, 17 Sep 2007 19:47:04 +0100 From: "Peter Bowyer" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> X-Google-Sender-Auth: 89250b1a5127e395 X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On 17/09/2007, Michael Kaplan wrote: > > > > On 9/17/07, Peter Bowyer wrote: > > On 17/09/2007, Michael Kaplan wrote: > > > > > > > > > On 9/17/07, Frank Ellermann wrote: > > > > Michael Kaplan wrote: > > > > > > > > > The core of this concept is that questionable unauthenticated email > > > > > will be bounced > > > > > > > > I hope you mean "rejected", unsolicited bounces are evil. > > > > > > Yes, in section 9 I summarize the Ironport data on the bounce problem, > and > > > it is a real problem. > > > Sometimes legitimate email is unauthenticated; adopting a policy of > > > absolutely never sending a bounce in response to an unauthenticated > email > > > will degrade the integrity of email. Banning all such bounces solves > one > > > problem and creates another. > > > > Your use of 'Yes' in your answer to Frank was clearly in the sense of > > 'No'. Unsolicited bounces are evil, and you're still proposing to send > > them. This is bad. Why are you not talking about SMTP-time rejections, > > which are not evil and don't suffer the same issues? > > > > > > Peter > > I am concerned about forwarded email. Once the Receiver Generated SPF > database is established then most of the unauthenticated ham will come via > forwarders who already accepted the original email. I'm open to any > suggestions on how to work around this, otherwise I still argue that highly > selective bounces are only mildly evil. Not sure how that answers the question about Bounce vs Reject...it's been asked twice now. Peter -- Peter Bowyer Email: peter@bowyer.org _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 13:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190662221.24253@/b8U8UJUjFLw7N0YTxZ+TA X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 13:27:04 -0700 (MST) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HJUFDs006153 for ; Mon, 17 Sep 2007 15:30:20 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXM3f-0005u7-Kg; Mon, 17 Sep 2007 15:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXM3e-0005sk-At for asrg@ietf.org; Mon, 17 Sep 2007 15:14:58 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXM3T-0006TP-2d for asrg@ietf.org; Mon, 17 Sep 2007 15:14:53 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8HJDtOd008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2007 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190056456; x=1190142856; bh=F+62mAB9n3hDOfUTmXE/rv6TS02JyG3Y5qMB Kc5sHys=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=dm/ b/if6bVp9V3UlvnrPc7sMXsNzonXuM1BAlzUa6Eo3L0/xABh62MuyCUB9bl3z7SHxub b5xbqSfRw7tYZC0tSnTStUEdoqvWfdvm7PwRp6YZLZP7NLp6oxS9DTvlLmzKBMGrszk dlb8W6HNqTB/74eExYwowEuvcu9KtgH5C4= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=E4l98BwvmIGT6lMOOAIU0XdWySwlGdSwDtz/9tfxqOfY/s+5sqNgFCIUva+s4s/zQ HdXEzjN1/ifPhGzLTIpNxmAnP5NoynVJ8QH+KqpNiJHktBxMa2vn84S40TqLr4reeY9 CrumKHy7RFYYeiE3uR5LXrodc7ubYGPwdCsXz8I= Message-Id: <6.2.5.6.2.20070917112848.02d26f40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 17 Sep 2007 12:13:32 -0700 To: Anti-Spam Research Group - IRTF From: SM Subject: Re: [Asrg] Receiver Initiated Authentication In-Reply-To: <46EEC382.3090305@nortel.com> References: <6.2.5.6.2.20070917094159.02dc25b0@resistor.net> <46EEC382.3090305@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean At 11:12 17-09-2007, Chris Lewis wrote: >Freudian slip? ;-) No. :-) I was merely pointing out why every new measure introduced gets circumvented. >I can't help thinking that spammers will have a field day spamming >themselves with forged, say, @hotmail.com, doing the captchas to >"approve" bogus IPs, and then firehosing the world with what would >now verify. The Nigerian 419 hordes would have fun. Or they could push more authenticated mail through as they already control the user's computer. Regards, -sm _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 13:27:04 2007 X-mallorn-MailScanner-Watermark: 1190663311.70209@gsmJGHqNk5tkZeKsnyzmrg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 13:27:04 -0700 (MST) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HJmJFZ008993 for ; Mon, 17 Sep 2007 15:48:24 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMSL-0004A6-Ls; Mon, 17 Sep 2007 15:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMSL-0004A1-3p for asrg@ietf.org; Mon, 17 Sep 2007 15:40:29 -0400 Received: from trillian.net.astrum.ch ([213.144.132.251] helo=mail.leisi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXMSF-0007V8-Jh for asrg@ietf.org; Mon, 17 Sep 2007 15:40:29 -0400 X-Spam-ASN: AS13030 213.144.128.0/19 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on trillian.net.astrum.ch X-Spam-Relays: trusted= untrusted=[ ip=213.144.132.250 rdns=marvin.net.astrum.ch helo=!192.168.1.21! by=mail.leisi.net ident= envfrom= intl=0 id=6A29D6F05A auth= msa=0 ] internal= external=[ ip=213.144.132.250 rdns=marvin.net.astrum.ch helo=!192.168.1.21! by=mail.leisi.net ident= envfrom= intl=0 id=6A29D6F05A auth= msa=0 ] X-Spam-Hammy: 0.000-+--H*UA:Mnenhy, 0.000-+--H*u:Mnenhy, 0.000-+--H*u:0.7.5.0, 0.000-+--H*UA:0.7.5.0, 0.000-+--sha1 X-Spam-Status: No, hits=-91.1 required=4.5 test=AWL=11.485,BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-100, SPF_PASS=-0.001 autolearn=ham AWL=11.5 DNSWL=YES X-Spam-Spammy: 0.987-1--tools X-Spam-Level: X-Spam-LastExternal: ip=213.144.132.250 rdns=marvin.net.astrum.ch helo=!192.168.1.21! X-Spam-DNSWL: YES RCVD_IN_DNSWL_HI X-Spam-Report: * -100 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [213.144.132.250 listed in list.dnswl.org] * -0.0 SPF_PASS SPF: sender matches SPF record * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 11 AWL AWL: From: address is in the auto white-list Received: from [192.168.1.21] (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.leisi.net (Postfix) with ESMTP id 6A29D6F05A for ; Mon, 17 Sep 2007 21:40:01 +0200 (CEST) Message-ID: <46EED810.5060209@leisi.net> Date: Mon, 17 Sep 2007 21:40:00 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF X-Enigmail-Version: 0.95.3 OpenPGP: id=7CA2FE89 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -8.0 (--------) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Asrg] DNSxL notation for IPv6? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Asrg List, I asked this question over at SPAM-L, but I think the question may be of interest to asrg@ietf as well: - --- cut --- Google was not helpful on this subject, so you may be able to help to reveal the status of DNSxL notation for IPv6. What would make sense, and what not? What has already been tried? I think it would make sense to use something similar to the reverse-dotted-quad notation used for IPv4, and use the same request/response types (DNS A/TXT records -- there are enough bits of information in a A response, no need for A6/AAAA). Using the "full format" of IPv6 encoding (like [1]), replacing ":" by "." and reversing the whole thing would be the obvious notation, and most similar to the IPv4 notation -- however, it seems like a great waste of bandwidth to me. Any better ideas? - --- cut --- On SPAM-L, the use of the PTR format was suggested: > windtunnel.rarpsl.com. 38400 IN AAAA fe80::203:93ff:fe96:296c > c.6.9.2.6.9.e.f.f.f.3.9.3.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. > 38400 IN PTR windtunnel.rarpsl.com. Besides the bandwidth argument (is this a valid argument?) against using the "full PTR" format, I have a different thought: Since Anti-Spam tools will need to be upgrade one way or the other anyway, it may make sense to include a quasi standard for lookups for larger (and non-octet-boundary) ranges. - -- Matthias [1] 2001:0db8:0000:0000:0000:0000:1428:57ab -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFG7tgQxbHw2nyi/okRAuL+AJ9rYeimgcUA553QMpLM1Z9r0mEy4QCghchP 1RVSUk7NM3GdHqYJ8/ppxfk= =proJ -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 13:27:06 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190664719.46034@h+xT7ipuUNLMMHyeJCXLQg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 13:27:06 -0700 (MST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HKBr0f012370 for ; Mon, 17 Sep 2007 16:11:59 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMm2-0004b1-4H; Mon, 17 Sep 2007 16:00:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMm1-0004Oa-An for asrg@ietf.org; Mon, 17 Sep 2007 16:00:49 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXMlg-0002TH-W5 for asrg@ietf.org; Mon, 17 Sep 2007 16:00:29 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 263212F0; Mon, 17 Sep 2007 16:00:48 -0400 (EDT) Received: from [192.168.3.77] (h-68-166-189-141.snvacaid.dynamic.covad.net [68.166.189.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id C831A7FE27; Mon, 17 Sep 2007 16:00:46 -0400 (EDT) In-Reply-To: <46EED810.5060209@leisi.net> References: <46EED810.5060209@leisi.net> 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: Meng Weng Wong Subject: Re: [Asrg] DNSxL notation for IPv6? Date: Mon, 17 Sep 2007 13:00:22 -0700 To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.752.2) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sep 17, 2007, at 12:40 PM, Matthias Leisi wrote: > Google was not helpful on this subject, so you may be able to help to > reveal the status of DNSxL notation for IPv6. > > What would make sense, and what not? What has already been tried? We need better protocols. DNS was never designed for this. I believe a number of next-generation protocols have been developed, or are being developed. At my company we use a very simple protocol; it runs on UDP with retry and failover to TCP, just like DNS. The serialization codec is based on BitTorrent so it already has library support in many languages. We'd be happy to opensource it and publish it as a standard for others to use. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 14:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190666484.38413@BTI2Dgw7AJjmGFNY8uvhxg X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 14:27:03 -0700 (MST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HKfI9Z017559 for ; Mon, 17 Sep 2007 16:41:23 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNEq-0006OM-Gd; Mon, 17 Sep 2007 16:30:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNEo-0006Ic-0P for asrg@ietf.org; Mon, 17 Sep 2007 16:30:34 -0400 Received: from fruitbat.wordtothewise.com ([208.187.80.135] helo=m.wordtothewise.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXNEd-0003NP-6g for asrg@ietf.org; Mon, 17 Sep 2007 16:30:23 -0400 Received: from [10.3.2.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id A3DD1800FC for ; Mon, 17 Sep 2007 13:30:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46EED810.5060209@leisi.net> References: <46EED810.5060209@leisi.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859A213A-4F50-4F3E-8FB7-C8E2AF22B2B9@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] DNSxL notation for IPv6? Date: Mon, 17 Sep 2007 13:30:21 -0700 To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.752.3) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sep 17, 2007, at 12:40 PM, Matthias Leisi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Asrg List, > > I asked this question over at SPAM-L, but I think the question may > be of > interest to asrg@ietf as well: > > - --- cut --- > Google was not helpful on this subject, so you may be able to help to > reveal the status of DNSxL notation for IPv6. > > What would make sense, and what not? What has already been tried? > > I think it would make sense to use something similar to the > reverse-dotted-quad notation used for IPv4, and use the same > request/response types (DNS A/TXT records -- there are enough bits of > information in a A response, no need for A6/AAAA). Seems reasonable. But the only reason we use that now is because it was an easy kludge in sendmail, not because there's anything special, or even particularly good about it. > > Using the "full format" of IPv6 encoding (like [1]), replacing ":" by > "." and reversing the whole thing would be the obvious notation, and > most similar to the IPv4 notation -- however, it seems like a great > waste of bandwidth to me. Absolutely the wrong notation, IMO. Try listing a /49 using that approach - you'll end up with something like 32768 A records for the one range, as compared to 8 for a nybble based notation. > > Any better ideas? > - --- cut --- > > On SPAM-L, the use of the PTR format was suggested: > >> windtunnel.rarpsl.com. 38400 IN AAAA >> fe80::203:93ff:fe96:296c >> c.6.9.2.6.9.e.f.f.f. >> 3.9.3.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. >> 38400 IN PTR windtunnel.rarpsl.com. > > Besides the bandwidth argument (is this a valid argument?) Not really, no. You'd need to do the packet stuffing math and some IP range distributions and suchlike to demonstrate that the difference in size relative to fixed overhead isn't that great, but it's really not a big deal. > against using > the "full PTR" format, I have a different thought: > > Since Anti-Spam tools will need to be upgrade one way or the other > anyway, it may make sense to include a quasi standard for lookups for > larger (and non-octet-boundary) ranges. If you want your database to consist of anything other than a list of /128s then you do need to put in zone cuts to allow wildcards (assuming you're piggybacking on DNS, which seems a reasonable assumption for now). IPv4 usage puts those zone cuts on 8 bit boundaries, which is a bit large for comfort, as it makes listing a /25 fairly tedious[1]. Four bit cuts, using hex digits rather than decimal integers, makes perfect sense[3]. Conveniently, that's exactly how IPv6 PTRs are defined, as you show above[2]. Another interesting question would be "Would you ever check for anything smaller than a /64?". And, should there be an "I'm not dead" entry (127.0.0.2), and perhaps an "I am dead" entry or response? And, should the response not just say "This /128 is listed", but rather "This /128 is listed as part of this larger /52" ? I suspect these questions, and many more like them, are already being touched on as part of the DNSBL BCP stuff people are looking at, but I've not looked at recent drafts so I'm not sure. Cheers, Steve [1] Yes, I know it's all generated by scripts, or on the fly from some internal data structure, depending on which DNS server you're using, but still... [2] I'm supporting that IPv6 notation, amongst others, on my most discriminating blacklists nofalsepositive.stopspam.samspade.org and nofalsenegative.stopspam.samspade.org, should you want to test any tools. [3] Though I suspect that the multiply repeated nybbles will trigger some bugs in poorly tested dns name compression code. :) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Sep 17 14:27:07 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1190666484.77316@AAEzvR85GKdq52vwGrp4mQ X-Envelope-From: asrg-bounces@ietf.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 17 Sep 2007 14:27:07 -0700 (MST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8HKfITO017558 for ; Mon, 17 Sep 2007 16:41:23 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNF9-0006Sj-So; Mon, 17 Sep 2007 16:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNF7-0006R9-EI for asrg@ietf.org; Mon, 17 Sep 2007 16:30:53 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXNEz-0000YS-KY for asrg@ietf.org; Mon, 17 Sep 2007 16:30:52 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1404891rvb for ; Mon, 17 Sep 2007 13:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=9KjR0hg0EBJDr1O92u5vjj4MNaDvhlXUaOkC/ep5few=; b=Kpz5wdEkuJL8LNauvFlhDuqbDA3PEtQTf8g5q2iG6ULMVwd7tLak0WcXiPMnWN1f6NQAWvmWQipwLqv+/Oo8qBGDzVq7SDyQOtnUuG5YVu3u8yJApCAAt6u4TuiupWuurxgi226kBR1yDmFeVnEOAajdajTveFwiwCEVimTpwGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=J6ZXmebU43hvfOgpiQY9mh7d6ZTOf6uw1S//T98qkXgIQvJxH0/9UvuXqfDQw45vtz4sWY+YTd1O/4KClE/YB6qylRFhfdwxihPwhg8iIzLdn/YagAxps9LzuHGN93jPM5pOnvRBmpC+sipgixMX6Ma+8kcj0qnkWanLZ2CW5L0= Received: by 10.114.199.1 with SMTP id w1mr211239waf.1190061022734; Mon, 17 Sep 2007 13:30:22 -0700 (PDT) Received: by 10.114.192.18 with HTTP; Mon, 17 Sep 2007 13:30:22 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 16:30:22 -0400 From: "Michael Kaplan" To: "Anti-Spam Research Group - IRTF" Subject: Re: [Asrg] Re: Receiver Initiated Authentication In-Reply-To: <934f64a20709171008o6e53406frece021f53d12f27d@mail.gmail.com> MIME-Version: 1.0 References: <56152ae90709170857i31ec8a3fy6cbc9d31a788e95@mail.gmail.com> <934f64a20709171008o6e53406frece021f53d12f27d@mail.gmail.com> X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050837128==" Errors-To: asrg-bounces@ietf.org X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean --===============0050837128== Content-Type: multipart/alternative; boundary="----=_Part_14339_19890869.1190061022720" ------=_Part_14339_19890869.1190061022720 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/17/07, Michael Kaplan wrote: > > > > I am concerned about forwarded email. Once the Receiver Generated SPF > > database is established then most of the unauthenticated ham will come > via > > forwarders who already accepted the original email. I'm open to any > > suggestions on how to work around this, otherwise I still argue that > highly > > selective bounces are only mildly evil. > > Quarantine (or soft-fail) and query the recipient. Parse the headers in > the > forwarded message; if a spf-good appears earlier, offer the addressee the > option of whitelisting the final relay. It is good if addressees whitelisted the final relay; this would be good for all mail systems, not just RIA. If, however, mail comes via an forwarder than does not have an established reputation then I would bounce the email. If you don't then you will need to constantly expose the receiver to unauthenticated spam; RIA is supposed to make the sending of unauthenticated spam absolutely futile. Receipt of the resent bounce will prove the legitimacy of the original forwarding server so now the addressee can have this forwarding server automatically whitelisted. The addressee has signed up for the > protection, knowing there may be a touch of configuration. Integrate with > reputation systems (and refer to documentation strongly suggesting using > a SPF-compliant RFC 821 "SRS" envelope instead of a simplified one) in > the 450 rejection) and statistical analysis in deciding how to dispose of > such messages. RIA will do all of this, but at the end of it a very small amount of unauthenticated 'unsure' email will remain and require bouncing. As this is a research group, it's good to see new proposals like > yours. Your proposal, like a few others, revolves around > Challenge/Response. Once we start meddling with bounces, we make > that feature even more unreliable. > I argue that this is an excellent way to use bounces (even if a small number are misdirected). I'm not sure what "unreliable" refers to Near universal distribution of Auto-Resend software is not as easy as > it sounds. If you cannot get the administrators to update their > systems, then you won't get hundred times more people upgrading their > software. The cost will be much more if you upgrade the client software. > Section 5.2 outlines how surprisingly simple it is to distribute Auto-Resend to most of the population, and the last bullet point of section 11 details how unnecessary Auto-Resend is. A routine Windows Update patch would take care of most of the Outlooks out there. With passage of enough time people will inevitably upgrade their computers and software, thus gradual near-perfect of Auto-Resend is inevitable. Contrast this to the current SPF database; in 10 years it will still be woefully incomplete. CAPTCHA has been circumvented. Getting users to a website to solve a > CAPTCHA is not that difficult. If spammers did not get more than an > insignificant number of people to visit their website, they would not > have been in business. > Section 6.2 details how CAPTCHA, as used by RIA, cannot be circumvented. A CAPTCHA guarding against web page registrations needs to be a thousand times more secure than a CAPTCHA that requires an non-spoofed email for every attempt at solving it. CAPTCHA also has usability issues. > If RIA got rid of the CAPTCHA altogether then it would still be a system that would generate a near perfect SPF record and authenticate all questionable email. The purpose of the CAPTCHA is to challenge the extremely small number of emails that are 'unsure' despite authentication (see reference #1); again most of the unsure authenticated ham will come from bulk senders or senders with spambot compromised systems. The CAPTCHA, directed at this small population of senders, is needed to make the sending of spam completely futile. The CAPTCHA is only tolerable as so few legitamate senders will ever see it; answering the CAPTCHA will improve you reputation and help get you off of the suspicious list so in the future your emails won't bounce. A Single Universal Receiver Generated SPF Database is like having a > single worldwide authority responsible for email. This raises > questions about control and cost. > This database will be based on preexisting proposals for a shared universal reputation system (Reference 13). I suggest that you don't underestimate the technical prowless of spammers. > In section 7 I theorize a mechanism of spammer circumvention and how to neutralize it. If anyone else can think of how spammers can bypass this system then please let me know. Regards, > -sm > I can't help thinking that spammers will have a field day spamming > themselves with forged, say, @hotmail.com, doing the captchas to > "approve" bogus IPs, and then firehosing the world with what would now > verify. The Nigerian 419 hordes would have fun. I'm not sure what it is you are describing. Hotmail addresses cannot be spoofed as Hotmail has an SPF record. How would spammers control email accounts that are used by participants of RIA? (Other than what I describe in section 7). The Receiver Generated SPF database would be created by the information generated from trusted email accounts such as those held by AOL, Earthlink, Verizon, corporate customers, established trusted users of Hotmail and Gmail (someone who signed up for a webmail account 5 minutes ago probably won't be considered a trusted webmail user), etc. How is a 419 scammer going to corrupt the database (other than as described in section 7)? Frankly, also, much as I'm not fond of SPF, I'd object to having our SPF > policy subverted to lend additional credibility to entities that aren't > under _our_ control. This is not a policy; the Receiver Generated SPF database is a private database generated by all willing participants of RIA. I'd love to think that every major email entity would participate. Thank you, Michael ------=_Part_14339_19890869.1190061022720 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On 9/17/07, Michael Kaplan < michaelkaplanasrg@gmail.com> wrote:
>
> I am concerned about forwarded email.  Once the Receiver Generated SPF
> database is established then most of the unauthenticated ham will come via
> forwarders who already acc