Re: [Asrg] Spam, why is it still a problem?
Danny Angus <Danny_Angus@slc.co.uk> Wed, 18 January 2006 09:38 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9m6-0007up-4s; Wed, 18 Jan 2006 04:38:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9m4-0007uW-BP for asrg@megatron.ietf.org; Wed, 18 Jan 2006 04:38:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22734 for <asrg@ietf.org>; Wed, 18 Jan 2006 04:37:13 -0500 (EST)
Received: from mail83.messagelabs.com ([195.245.231.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ez9uJ-0001bu-IH for asrg@ietf.org; Wed, 18 Jan 2006 04:47:15 -0500
X-VirusChecked: Checked
X-Env-Sender: Danny_Angus@slc.co.uk
X-Msg-Ref: server-7.tower-83.messagelabs.com!1137577099!20254104!1
X-StarScan-Version: 5.5.9.1; banners=slc.co.uk,-,-
X-Originating-IP: [195.99.121.125]
Received: (qmail 14008 invoked from network); 18 Jan 2006 09:38:20 -0000
Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-7.tower-83.messagelabs.com with SMTP; 18 Jan 2006 09:38:19 -0000
Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id <T75e94a8824c0a8646561c@drsneaky.slc.co.uk>; Wed, 18 Jan 2006 09:39:09 +0000
In-Reply-To: <17355.57089.337059.779704@world.std.com>
Subject: Re: [Asrg] Spam, why is it still a problem?
To: Barry Shein <bzs@world.std.com>
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF0E1B735B.463D9215-ON802570FA.003052DA-802570FA.0035048C@slc.co.uk>
From: Danny Angus <Danny_Angus@slc.co.uk>
Date: Wed, 18 Jan 2006 09:39:05 +0000
X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 18/01/2006 09:39:09
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: asrg@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org
Barry, You make some good points, and althought I accept that I don't have the answer I'll try to illustrate what I mean by rising to your challenge.. Effectively in my view, the difference between a "new" protocol and enhancements to existing mechanisms is that a new one would be able to be designed such that transmission of messages was denyed by default, enabled by choice and could be revoked at will. > (I'll call that the First Axiom of IFUSSP) > Sounds good, but I claim there is no such solution, or it's never been > outlined that I've seen. Thats probably true, but we can guess what elements it would include. > So let's just have this IFUSSP design, please. Or let's stop claiming > it exists. I haven't heard anyone claim it exists, there is a key variability. What I do know is that it is possible to design systems which satisfy bounded requirements. The variability comes in because no-one has yet defined those requirements unambigously, all we have is unbounded requirements or requirements which are based on concepts which have no commonly accepted definition (such as "spam"), and commonly stated requirements which are sometimes incompatibly different depending upon what role you are playing in the system. IMHO any "IFUSSP" solution would probably need to meet the following requirements.. 1/ it would allow unknown (new) senders to *attempt* to send mail to any user of any domain 2/ it would not involve any charge being levied for transport (even an indirect charge like cpu cycles) 3/ it would involve the use of open standard identity and trust mechanisms to associate levels of trust with people and domains (no one will want to re-invent that wheel) 4/ it would not require a centralised register, nor require the use of any commerically controlled register, it would be capable of benefiting from operational efficiencies achieved by the use of chains of trust. 5/ it would not impose additional direct or indirect loads on external systems, don't shoot the messenger. 6/ unit cost of normal operations would not increase. For instance if a proposal increases the cpu cycles required to accept good mail rather than reducing the cycles required to reject unwanted mail then as the number of unwanted messages presented falls the total cost might fall but the unit cost rises and any increases in allowable traffic become more expensive to accomodate. It might involve the exchange of trust tokens (and other domain details) between unknown parties as means of registering allowable senders *before* any attempt to send will be accepted. Trust tokens could be accepted at face value where out-of-channel mechanisms for establishing trust exist (for example between corporate domain operators) or some third party trust provider could be required as a signatory for anonymous or less trustworthy domains. The recipient system would respond at its convenience when the identity of the sender (and any other checks which the recipient chose to make) had been verified and accepted. The senders system would then, and only then, attempt to send mail to the recipient. Recipients would be able to revoke this permission at any time, resulting in an end to all traffic from the sender for a period stated in the revokation. Mail could be accepted into the recipients domain by checking only that it held a validated identity. Recipient systems could continue (as at present) to scan content, the difference being that in the new process it would actually be possible to block the transmission of unwanted content, not simply to can it after it has consumed resources. If people managed to circumvent the personal aspect whole domains could be blocked. Where chains of mail transport exist chains of trust could be established, recipients could chose to block incoming mail that their domain might accept. The key is that at each step in the transport of mail it would be possible for a recipient to effectively turn-off the source for a finite or indefinite period of time. Obviously without the existence of some clear (i.e. codifiable) definition of what is accpetable one person might object to mail from a sneder which their neighbour considers relevant and desirable, to this extent the solution doesn't and cannot by defninition, prevent all unwanted content. What it can do is to allow (but not compel) recipient users and automated systems to identify the senders of unwanted content and disbar them from even attempting to send mail. I know this isn't the answer to your question! ButI hope it does demonstrate that there are ideas out there which could form the basis of a new form of SMTP which would permit some of the key requirements for controlling the sending of unwanted mail. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] Re: Bots Frank Ellermann
- [Asrg] Spam, why is it still a problem? Craig Cockburn
- Re: [Asrg] Spam, why is it still a problem? der Mouse
- Re: [Asrg] Spam, why is it still a problem? Tom Petch
- Re: [Asrg] Spam, why is it still a problem? Danny Angus
- Re: [Asrg] Spam, why is it still a problem? Andrew W. Donoho
- Re: [Asrg] Spam, why is it still a problem? Dave Crocker
- [Asrg] Re: Spam, why is it still a problem? Frank Ellermann
- Re: [Asrg] Spam, why is it still a problem? Barry Shein
- RE: [Asrg] Spam, why is it still a problem? Hallam-Baker, Phillip
- Re: [Asrg] Spam, why is it still a problem? Seth Breidbart
- [Asrg] Email service assumptions and making syste… Dave Crocker
- Re: [Asrg] Email service assumptions and making s… Barry Shein
- [Asrg] Re: Email service assumptions and making s… Frank Ellermann
- Re: [Asrg] Email service assumptions and making s… Seth Breidbart
- Re: [Asrg] Email service assumptions and making s… Douglas Otis
- Re: [Asrg] Email service assumptions and making s… Barry Shein
- Re: [Asrg] Email service assumptions and making s… Seth Breidbart
- [Asrg] Re: Spam, why is it still a problem? Stephane Bortzmeyer
- Re: [Asrg] Re: Spam, why is it still a problem? Gadi Evron
- [Asrg] Re: Spam, why is it still a problem? Stephane Bortzmeyer
- Re: [Asrg] Re: Spam, why is it still a problem? Tom Petch
- Bots was Re: [Asrg] Email service assumptions and… Tom Petch
- Re: [Asrg] Email service assumptions and making s… John Levine
- Re: Bots was Re: [Asrg] Email service assumptions… John Levine
- Re: [Asrg] Email service assumptions and making s… Barry Shein
- Re: [Asrg] Email service assumptions and making s… Douglas Otis
- Re: Bots was Re: [Asrg] Email service assumptions… Barry Shein
- [Asrg] Re: Bots Frank Ellermann
- RE: [Asrg] Re: Bots Larry Seltzer
- Re: [Asrg] Re: Bots Douglas Otis
- Re: [Asrg] Re: Bots Seth Breidbart
- [Asrg] Re: Bots Frank Ellermann
- Re: [Asrg] Spam, why is it still a problem? Craig Cockburn
- [Asrg] Re: Bots Frank Ellermann
- Re: [Asrg] Re: Spam, why is it still a problem? Craig Cockburn
- RE: [Asrg] Re: Bots Larry Seltzer
- Re: [Asrg] Re: Bots Gadi Evron
- Re: [Asrg] Re: Spam, why is it still a problem? Douglas Otis
- Re: [Asrg] Spam, why is it still a problem? John Levine
- Re: [Asrg] Spam, why is it still a problem? Craig Cockburn
- Re: [Asrg] Re: Spam, why is it still a problem? Craig Cockburn
- Re: [Asrg] Spam, why is it still a problem? Danny Angus
- Re: [Asrg] Email service assumptions and making s… Danny Angus
- Re: [Asrg] Email service assumptions and making s… Danny Angus
- Re: [Asrg] Spam, why is it still a problem? John Levine
- Re: [Asrg] Spam, why is it still a problem? John Levine
- Re: [Asrg] Email service assumptions and making s… Seth Breidbart
- Re: [Asrg] Spam, why is it still a problem? Craig Cockburn
- Re: [Asrg] Spam, why is it still a problem? Bill Cole
- Re: [Asrg] Spam, why is it still a problem? John Levine
- Re: [Asrg] Spam, why is it still a problem? Barry Shein
- Re: [Asrg] Email service assumptions and making s… Barry Shein
- Re: [Asrg] Email service assumptions and making s… Laird Breyer
- [Asrg] Re: Email service assumptions and making s… Frank Ellermann
- Re: [Asrg] Email service assumptions and making s… Danny Angus
- Re: [Asrg] Spam, why is it still a problem? John Levine
- RE: [Asrg] Re: Spam, why is it still a problem? Wesley Peters
- Re: [Asrg] Spam, why is it still a problem? Dave Crocker
- Re: [Asrg] Email service assumptions and making s… Dave Crocker
- Re: [Asrg] Spam, why is it still a problem? Danny Angus