From mailnull@www1.ietf.org Thu May 1 00:12:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06318 for ; Thu, 1 May 2003 00:12:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h414I1D08252 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 00:18:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414I1808249 for ; Thu, 1 May 2003 00:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06310; Thu, 1 May 2003 00:11:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B5SA-0005uS-00; Thu, 01 May 2003 00:13:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B5SA-0005uP-00; Thu, 01 May 2003 00:13:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414FJ808186; Thu, 1 May 2003 00:15:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414E3808092 for ; Thu, 1 May 2003 00:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06267 for ; Thu, 1 May 2003 00:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B5OK-0005tb-00 for asrg@ietf.org; Thu, 01 May 2003 00:09:52 -0400 Received: from www.somewhere.com ([66.92.72.194] helo=somewhere.com) by ietf-mx with esmtp (Exim 4.12) id 19B5OF-0005tW-00 for asrg@ietf.org; Thu, 01 May 2003 00:09:47 -0400 Received: from [66.92.72.194] (account nazgul HELO [192.168.1.104]) by somewhere.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 2304040; Wed, 30 Apr 2003 23:10:14 -0500 Mime-Version: 1.0 X-Sender: nazgul@somewhere.com@pop.messagefire.com Message-Id: In-Reply-To: <798BD6DA-7B7D-11D7-B499-000393CAA6AA@pobox.com> References: <798BD6DA-7B7D-11D7-B499-000393CAA6AA@pobox.com> To: mathew From: Kee Hinckley Subject: Re: [Asrg] Protecting Legitimate Commercial Email (was Re: ESPC P roposal) Cc: asrg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 23:53:54 -0400 At 10:34 PM -0400 4/30/03, mathew wrote: >>No, that isn't how they do it. Court suits are a last resort. > >What are the other resorts? Negotiation. >>when their customers spam. They don't. They don't even do the >>"We'll charge your credit card $500 if you spam" thing. > >I'm pretty sure Barry Shein does. Perhaps he could chime in on >whether that's just an empty threat, though. I think it was Barry who told me it wasn't worth it--but I'm *quite* sure he can speak for himself on the issue :-). >> Why? Because the customer simply disputes the charge, and then >>you're off to court to try and get $500. You can't win that game. > >So what you're saying is that providing I defraud you of less than >$500, you wouldn't bother to do anything about it? Not if the cost of recovering it is greater than $500. This isn't abstract, it's happened to me personally. I had a plumber walk off with $6000 of my money, skip out on the court dates, and skip out on the bankruptcy hearing. We put a trace on him for a while, but eventually we gave up. Getting the money back costs too much. Modern society doesn't work because people will sue you at the drop of the hat if you do something wrong. It works because people are basically honest. >Made-up e-mail addresses, lying on subscription forms and >deliberately subscribing other people's e-mail addresses are not a >problem if you're doing confirmed opt-in. And if you're not doing >confirmed opt-in, you're a spammer. I used to think confirmed opt-in was the answer. I'm no longer so sure. End users are not as smart as I thought they were. (And I didn't think they were very smart from the get go.) But there's certainly no point in labeling 90% of the emailing community spammers just because they don't agree with you on how to verify an address. You aren't going to get very far in negotiations that way. >>What we need in this system is some way of restoring trust. Trust >>by a recipient that they can safely unsubscribe. Trust by a >>bulkmailer that the list owner has followed best practices. Trust >>by the list owner that the recipients haven't lied. There's a >>circle there, and it's broken. > >Well, those things would be nice, but I don't see that any of them >would solve the spam problem, or even improve the situation. That's because you've already decided that everyone who doesn't believe what you believe is evil. You've got no where to go when it comes to trust. On the bright side, you are being consistent. That's perfectly in line with assuming that people behave because they are afraid that otherwise they'll get sued. -- Kee Hinckley http://www.messagefire.com/ Junk-Free Email Filtering http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 00:35:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06609 for ; Thu, 1 May 2003 00:35:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h414f2h09654 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 00:41:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414f2809651 for ; Thu, 1 May 2003 00:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06592; Thu, 1 May 2003 00:34:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B5oR-0005yN-00; Thu, 01 May 2003 00:36:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B5oQ-0005yH-00; Thu, 01 May 2003 00:36:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414d6809574; Thu, 1 May 2003 00:39:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h414cU809553 for ; Thu, 1 May 2003 00:38:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06560 for ; Thu, 1 May 2003 00:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B5lk-0005y3-00 for asrg@ietf.org; Thu, 01 May 2003 00:34:04 -0400 Received: from sccrmhc02.attbi.com ([204.127.202.62]) by ietf-mx with esmtp (Exim 4.12) id 19B5lV-0005xm-00 for asrg@ietf.org; Thu, 01 May 2003 00:33:49 -0400 Received: from art.lextek.com (12-254-130-29.client.attbi.com[12.254.130.29]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <20030501043318002006inbie>; Thu, 1 May 2003 04:33:18 +0000 Message-Id: <5.1.0.14.2.20030430223501.02da2008@mail.1s.com> X-Sender: PollardA@mail.1s.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: asrg@ietf.org From: Art Pollard Subject: Re: [Asrg] Changing mailing lists from push to pull Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 22:35:10 -0600 At 10:58 PM 4/30/2003 -0400, you wrote: > It should possible to set up a script to make a PC (Windows/Max/Linux) >poll a POP server once a day or once a week, etc. Has anyone ever tried >writing up a script and simply throwing announcements on a central POP >server. The subscribers' machine would poll the central POP server as >required. This solves the permission problem, because the subscriber is >doing the pulling. No changes required to SMTP, for the simple reason >that SMTP is totally bypassed. Sounds like NNTP .... ;-) Well sort of. Without the message distribution stuff. Personally, I'd love to see a "references" header become more standard so that mail readers could thread messages. It would also mean that a mail reader could "pull" mailing list threads. Finally, if it could be counted on, it would mean that there could be gateways between NNTP/WebBBS/Mailing Lists if one so desired as the threading mechanisms would be the same. I use Eudora which strips these things out unfortunately. -Art -- Art Pollard http://www.lextek.com/ Suppliers of High Performance Text Retrieval Engines. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 02:48:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20479 for ; Thu, 1 May 2003 02:48:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h416scc28346 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 02:54:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h416sc828343 for ; Thu, 1 May 2003 02:54:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20474; Thu, 1 May 2003 02:48:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B7tg-0006sI-00; Thu, 01 May 2003 02:50:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B7tf-0006sF-00; Thu, 01 May 2003 02:50:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h416qV828280; Thu, 1 May 2003 02:52:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h416nG828169 for ; Thu, 1 May 2003 02:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20440 for ; Thu, 1 May 2003 02:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B7oU-0006rg-00 for asrg@ietf.org; Thu, 01 May 2003 02:45:02 -0400 Received: from argon.connect.org.uk ([193.110.243.33]) by ietf-mx with esmtp (Exim 4.12) id 19B7oP-0006rT-00 for asrg@ietf.org; Thu, 01 May 2003 02:44:57 -0400 Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 19B7oV-0000Ql-00; Thu, 01 May 2003 07:45:03 +0100 In-Reply-To: <1051734132.17309.47.camel@david.couchpotato.net> Subject: Re: [Asrg] Domain-Authorized SMTP Mail To: "David Green" From: "Jon Kyme" Cc: "ASRG" X-Mailer: [ConnectMail 3.4.21] X-connectmail-Originating-IP: 193.195.0.101 Message-Id: Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 May 2003 07:45:03 +0100 > > I posted the "Domain Authorized SMTP Mail" proposal to this mailing list > some time ago, and I've since created a separate web site for it. Here's > the link: > I'm not sure how this works: SMTP servers MUST remove any Authorized-By SMTP headers of incoming mail. They SHOULD be configurable to preserve Authorized-By headers on incoming mail from a set of trusted servers. The first sentence seems to preclude the second. -- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 04:33:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02264 for ; Thu, 1 May 2003 04:33:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h418dFQ03238 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 04:39:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418dE803235 for ; Thu, 1 May 2003 04:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02257; Thu, 1 May 2003 04:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9Ws-0007LW-00; Thu, 01 May 2003 04:34:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B9Ws-0007LT-00; Thu, 01 May 2003 04:34:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418bL802809; Thu, 1 May 2003 04:37:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418aN802255 for ; Thu, 1 May 2003 04:36:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02213 for ; Thu, 1 May 2003 04:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9U7-0007Kv-00 for asrg@ietf.org; Thu, 01 May 2003 04:32:07 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf-mx with esmtp (Exim 4.12) id 19B9U1-0007Kj-00 for asrg@ietf.org; Thu, 01 May 2003 04:32:01 -0400 Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h418UnMq002399 for ; Thu, 1 May 2003 04:30:49 -0400 (EDT) Received: from DXHIRX1 ([24.162.230.108]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 1 May 2003 04:34:11 -0400 Message-ID: <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> From: "Ken Hirsch" To: References: <013301c30dc8$df22dc90$b1ad86a2@hirschk1> <01bd01c30e0a$4cc9c7e0$0201a8c0@DXHIRX1> <02d401c30eaf$b5563fa0$0201a8c0@DXHIRX1> <03cb01c30ed8$0acae620$0201a8c0@DXHIRX1> <200305010156.h411uoQM008784@new.agentzero.com> Subject: Re: [Asrg] Proposal for transition to authenticated email MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 04:22:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From: "Jim Youll" > You're missing lots of issues, like all the sites that aren't at the end of > a whomping fast Internet connection... the big messages dribble in over the > slow link and local access is decoupled from link speed. When I put up my > first home Linux server many years ago, it was on a demand-dialed line and > it batched out the locally-gathered mail every 30 minutes.. the ISP was > an MX secondary for inbound mail. I don't understand this objection. You can send to the ISP's SMTP server at the same speed as you send to another SMTP server. > > Further, why should an independent organization's e-mail policies be subject > to the wholly unrelated policies of an intermediate party? Because the current system is broken! > Should we also > proxy all web serving and retrieval through the ISP too? No. > Shall we ask the ISP > to maintain our e-mail accounts? Do we then have to trust the ISP to store > all these messages? What about privacy? I'm only talking about outgoing messages. > Since there will be hundreds of thousands of SMTP servers no matter how > loudly anyone here complains, there is little point in trying to shout > against the wind in this way. Yeah, yeah, nothing will ever change. The world will come to an end if these regulations pass. People say things all the time. Then the regulations pass and it's no big deal. I'm more interested in whether the regulations will work. Yes there are costs, but there are costs to the current situation and to any other solution, too. The actual impact of these changes is tiny. So far people have legitimately pointed out: 1) Now, you can use TLS to the end server. 2) You get feedback from one hop later if you do the SMTP yourself. That's it. For 1) Well, if you use S/MIME, your ISP knows the email of your recipient. If you use TLS, your ISP knows the SMTP server of the recipient. If that difference is important to you, get a certificate for your SMTP server! Come to think of it, if you accept TLS, you probably already got a certificate! Will the new certificate be so much more of a burden than the current one? (Slightly more rigorous, hopefully.) For 2) Yes, but you still don't know if the recipient gets the message. (Kudos to Microsoft for implementing S/MIME receipts, by the way. That is one real advance in reliability and they were the first major MUA vendor to do it, AFAIK.) If that's really important to you, get a certificate for your SMTP server. Right now the reliability of email is just so-so. And spam contributes to the problem. I will note that hierarchically-structured systems (like the phone system) tend to be more reliable than N^2 connection sytems. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 05:41:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03629 for ; Thu, 1 May 2003 05:41:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h419lf507281 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 05:47:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419lf807278 for ; Thu, 1 May 2003 05:47:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03623; Thu, 1 May 2003 05:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BAb5-0007h2-00; Thu, 01 May 2003 05:43:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BAb5-0007gz-00; Thu, 01 May 2003 05:43:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419hJ807190; Thu, 1 May 2003 05:43:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419gh807171 for ; Thu, 1 May 2003 05:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03568 for ; Thu, 1 May 2003 05:36:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BAW3-0007g7-00 for asrg@ietf.org; Thu, 01 May 2003 05:38:11 -0400 Received: from smtp.xl.wp.pl ([212.77.101.224]) by ietf-mx with esmtp (Exim 4.12) id 19BAVx-0007fm-00 for asrg@ietf.org; Thu, 01 May 2003 05:38:05 -0400 Received: (WP-SMTPD 19175 invoked from network); 1 May 2003 09:37:41 -0000 Received: from unknown (HELO pe152.warszawa.cvx.ppp.tpnet.pl) (anfi@xl.wp.pl@[213.76.100.152]) (envelope-sender ) by smtp4.xl.wp-sa.pl (WP-SMTPD) with SMTP for ; 1 May 2003 09:37:41 -0000 Received: from Box43.pl (anfi.freeshell.org [127.0.0.1]) by anfi.freeshell.org (8.12.9/8.12.9) with ESMTP id h419bf7e005331 for ; Thu, 1 May 2003 11:37:42 +0200 Message-ID: <3EB0EAE5.6000902@Box43.pl> From: Andrzej Filip User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: asrg@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: skaner antywirusowy poczty xl.wp.pl Content-Transfer-Encoding: 7bit Subject: [Asrg] Reference: Realtime UNblocking Lists Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 May 2003 11:37:41 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From: Leif Neland Subject: Idea: RUBL: Realtime UNblocking Lists Newsgroups: comp.mail.sendmail Date: Mon, 28 Apr 2003 18:47:31 +0200 http://www.google.com./groups?selm=3ead5b2b%240%2442636%24edfadb0f%40dread11.news.tele.dk -- Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 05:59:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04277 for ; Thu, 1 May 2003 05:59:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41A5kJ07936 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 06:05:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41A5k807933 for ; Thu, 1 May 2003 06:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04248; Thu, 1 May 2003 05:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BAsa-0007nh-00; Thu, 01 May 2003 06:01:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BAsZ-0007nb-00; Thu, 01 May 2003 06:01:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41A36807833; Thu, 1 May 2003 06:03:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h419u2807508 for ; Thu, 1 May 2003 05:56:02 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03695 for ; Thu, 1 May 2003 05:49:33 -0400 (EDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h419nPMq011804 for ; Thu, 1 May 2003 05:49:25 -0400 (EDT) Received: from DXHIRX1 ([24.162.230.108]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 1 May 2003 05:47:45 -0400 Message-ID: <05e501c30fc7$2338cf20$0201a8c0@DXHIRX1> From: "Ken Hirsch" To: References: Subject: Re: [Asrg] Proposal for transition to authenticated email MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 05:49:38 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gah! I forgot one other important advantage of my proposal. End users can get certificates and use them with current MUA software. That way they won't be subject to challenge-response even if they have to send through a non-participating SMTP server. The free certificates that just certify your email address would not be acceptable, but the certificates don't have to be out of reach of individuals. There has to be some real effort to check real-world identity, plus, as I said in another message: A certificate that provides strong identity (e.g. government-issued) is not by itself sufficient as an antispam certificate. A CA would have to (1) check it against a database of known spammers (2) get the person to sign a contract to abide by a set of antispam policies and (3) have a set of procedures to handle complaints against the person (including reporting the person to the database if they do not cooperate). > From: "Ken Simpson" > > Instead of certificates, why not just use the Bonded Sender approach and > > use PTR queries to a whitelist DNS server or group of servers? A quick DNS > > query is less intensive than cryptography and requires less programming. > > Besides, running a CA is a huge undertaking. > > This is a possibility. A DNS query may be less computationally intensive, > but I think it takes more time. A DNS query would avoid the byte overhead > of a message signature. > > The advantage of cryptographic signatures is they prove that the message was > sent by the holder of the private key. This helps prevent malicious > complaints against a bonded sender. > > There are already CAs. I think that they would work with an organization > such as TRUSTe rather than try to handle complaints themselves. They could > work with more than one organization. The exact details about certificate > signing and revocation would need to be worked out. > > Other differences of my proposal from the Bonded Sender approach-- > More than one policy could be chosen. Getting consensus on just one is > hard. > Participating servers should require a challenge-response on all mail from > non-participating servers. > Labeling properties of individual messages and senders is encouraged. > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 06:15:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04475 for ; Thu, 1 May 2003 06:15:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41ALrd09265 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 06:21:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41ALr809262 for ; Thu, 1 May 2003 06:21:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04470; Thu, 1 May 2003 06:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BB8B-00003e-00; Thu, 01 May 2003 06:17:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BB8A-00003b-00; Thu, 01 May 2003 06:17:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41AK9809203; Thu, 1 May 2003 06:20:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41AJD809145 for ; Thu, 1 May 2003 06:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04457 for ; Thu, 1 May 2003 06:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BB5b-00003K-00 for asrg@ietf.org; Thu, 01 May 2003 06:14:55 -0400 Received: from argon.connect.org.uk ([193.110.243.33]) by ietf-mx with esmtp (Exim 4.12) id 19BB5V-000032-00 for asrg@ietf.org; Thu, 01 May 2003 06:14:49 -0400 Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 19BB5j-0003hK-00; Thu, 01 May 2003 11:15:03 +0100 In-Reply-To: <3EB0EAE5.6000902@Box43.pl> Subject: Re: [Asrg] Reference: Realtime UNblocking Lists To: "Andrzej Filip" From: "Jon Kyme" Cc: "ASRG" X-Mailer: [ConnectMail 3.4.21] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 May 2003 11:15:03 +0100 > From: Leif Neland > Subject: Idea: RUBL: Realtime UNblocking Lists > Newsgroups: comp.mail.sendmail > Date: Mon, 28 Apr 2003 18:47:31 +0200 As you pointed out, one needs to block any IP that might be dynamically allocated for this to work well. Even for IPs that don't change their association frequently, periodic retesting would be required. I suppose this might be requested by my MTA if I get an "old" response from the RUBL. One issue I see is that it might falsely whitelist the output IP of multistage relays. How big a problem would this be? -- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 06:54:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05062 for ; Thu, 1 May 2003 06:54:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41B0Yg11163 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 07:00:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41B0X811160 for ; Thu, 1 May 2003 07:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05057; Thu, 1 May 2003 06:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BBja-0000BD-00; Thu, 01 May 2003 06:56:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BBja-0000BA-00; Thu, 01 May 2003 06:56:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41AwD811087; Thu, 1 May 2003 06:58:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41AvX811062 for ; Thu, 1 May 2003 06:57:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05030 for ; Thu, 1 May 2003 06:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BBgR-0000AL-00 for asrg@ietf.org; Thu, 01 May 2003 06:52:59 -0400 Received: from host217-35-105-169.in-addr.btopenworld.com ([217.35.105.169] helo=mail.neosinteractive.com) by ietf-mx with esmtp (Exim 4.12) id 19BBgL-0000AH-00 for asrg@ietf.org; Thu, 01 May 2003 06:52:53 -0400 Received: from tthompson ([217.35.105.173] unverified) by mail.neosinteractive.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 May 2003 11:57:51 +0100 From: "Tom Thomson" To: Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <200304260406.h3Q46poO010322@calcite.rhyolite.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 01 May 2003 10:57:51.0953 (UTC) FILETIME=[82DB4C10:01C30FD0] Content-Transfer-Encoding: 7bit Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 11:52:04 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >Note that contrary that document, it generally makes no sense to talk >about valid BCC fields in incoming legitimate mail. See page 37 of >RFC 2822. I wouldn't be surprised if SpamAssassin treats a BCC >header as evidence of evil, because I can't recall ever seeing one >except in spam. More important and also contrary to that document, >RFC 822 and RFC 2822 do *NOT* require that every incoming message name >the receipient in any SMTP header. Most legitimate mailing list >messags are cases in point. Phill's document already points out that mailing lists are an exception which require exceptional treatment, so your "case in point" appears to be vacuous padding to try to fool us into thinking your message has more substance than it has. As for the bcc case, I used to use an MUA which generated n+1 copies of the body - 1 for each bcc recipient containing a bcc line with only that recipient, and one for all To and cc recipient containing no bcc line. These were transmitted separately - multiple Rcpt To lines with one Data phase for teh To and cc recipients, single Rcpt lines with a data phase for each bcc recipient. Since Phill is as much of an antique as I am, maybe he too remembers MUAs which did rather pleasant and intelligent things that didn't conform to the modern desire for "efficiency" at all costs (even at the cost of effectiveness) and maybe that's where theerrorneous statement comes from. An easy mistake to make if you grew up with civilised MUAs. >What discourages me most about this mailing list are self-described >expert statements such as "the RFC822 message standard requires every >message to have a valid To: CC: or BCC: field identifying the recipient, >making adjustment where necessary to account for messages relayed >through mailing lists." There are obvious reasons why RFC 822 and >RFC 2822 do not require mailing list exploders to anything of the sort. Heavy protestations of knowledg and expertise which are clearly false bother me too, but I also know the story about the pot and the kettle. Tom _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 09:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07908 for ; Thu, 1 May 2003 09:06:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41DCF023318 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 09:12:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DCF823315 for ; Thu, 1 May 2003 09:12:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07900; Thu, 1 May 2003 09:05:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDmz-0000qE-00; Thu, 01 May 2003 09:07:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BDmz-0000qB-00; Thu, 01 May 2003 09:07:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DAS823164; Thu, 1 May 2003 09:10:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D9d822658 for ; Thu, 1 May 2003 09:09:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07710 for ; Thu, 1 May 2003 09:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDkE-0000mc-00 for asrg@ietf.org; Thu, 01 May 2003 09:05:03 -0400 Received: from smtp.xl.wp.pl ([212.77.101.224]) by ietf-mx with esmtp (Exim 4.12) id 19BDk9-0000lu-00 for asrg@ietf.org; Thu, 01 May 2003 09:04:57 -0400 Received: (WP-SMTPD 23925 invoked from network); 1 May 2003 13:04:34 -0000 Received: from unknown (HELO pv111.warszawa.cvx.ppp.tpnet.pl) (anfi@xl.wp.pl@[217.99.5.111]) (envelope-sender ) by smtp4.xl.wp-sa.pl (WP-SMTPD) with SMTP for ; 1 May 2003 13:04:33 -0000 Received: from Andrzej.Adam.Filip (anfi.freeshell.org [127.0.0.1]) by anfi.freeshell.org (8.12.9/8.12.9) with ESMTP id h41CogMP001502; Thu, 1 May 2003 14:50:42 +0200 Message-ID: <3EB11822.101@Andrzej.Adam.Filip> From: Andrzej Filip Organization: It is for me to know and for you to find out User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: asrg@ietf.org CC: Jon Kyme Subject: Re: [Asrg] Reference: Realtime UNblocking Lists References: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: skaner antywirusowy poczty xl.wp.pl Content-Transfer-Encoding: 7bit Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 May 2003 14:50:42 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Kyme wrote: >>From: Leif Neland >>Subject: Idea: RUBL: Realtime UNblocking Lists >>Newsgroups: comp.mail.sendmail >>Date: Mon, 28 Apr 2003 18:47:31 +020 >> > >As you pointed out, one needs to block any IP that might be dynamically >allocated for this to work well. Even for IPs that don't change their >association frequently, periodic retesting would be required. I suppose >this might be requested by my MTA if I get an "old" response from the RUBL. > RUBL may itself implement retest policy of listed & looked up IP addresses e.g. declare IP as clean after test for 4 months, but if anybody asks in fourth month then send back "all clear" but schedule retest. >One issue I see is that it might falsely whitelist the output IP of >multistage relays. > RUBL (as proposed) it is not intended to detect multistage open relays. It have a big chance to reduce number of single stage open relays "by mistake" or "lack of proper knowledge" - if you want to send to us then you must accept open relay tests [blocking relay tests gets more common]. There is one big problem: some people are ready to fight any "open relay test" probes and declare them "illegal". >How big a problem would this be? > > At early stages of RUBL deployment it should not not be a big problem. Of course if we effectively block use of single stage open relays then multistage open relays will be more valuable to spammers. -- Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 09:29:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09004 for ; Thu, 1 May 2003 09:29:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41DZci28727 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 09:35:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DZc828724 for ; Thu, 1 May 2003 09:35:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08981; Thu, 1 May 2003 09:29:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DX7828203; Thu, 1 May 2003 09:33:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DWZ827757 for ; Thu, 1 May 2003 09:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08841 for ; Thu, 1 May 2003 09:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE6e-00017G-00 for asrg@ietf.org; Thu, 01 May 2003 09:28:12 -0400 Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 19BE6W-000152-00 for asrg@ietf.org; Thu, 01 May 2003 09:28:06 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h41DQIgn003147 for asrg@ietf.org env-from ; Thu, 1 May 2003 07:26:18 -0600 (MDT) From: Vernon Schryver Message-Id: <200305011326.h41DQIgn003147@calcite.rhyolite.com> To: asrg@ietf.org Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator References: Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 07:26:18 -0600 (MDT) > From: "Tom Thomson" > Phill's document already points out that mailing lists are an exception > which require exceptional treatment, so your "case in point" appears to be > vacuous padding to try to fool us into thinking your message has more > substance than it has. He did not say that mailing list software should be changed, but in effect said that all major past and current SMTP mailing list software violates words in RFC 822 that do not exist. In fact RFC 2822 not only does not require that recipients be listed, but allows an MTA to remove BCCs. He probably made the mistake common among end users who complain about spam not containing their addresses, because they do not know about or understand the significance of the SMTP envelope. If you have not spent much time fighting spam or SMTP servers in more than their external configuration spam, it is easy to not know about the SMTP envelope. > As for the bcc case, I used to use an MUA which generated n+1 copies of the > body - 1 for each bcc recipient containing a bcc line with only that > recipient, and one for all To and cc recipient containing no bcc line. These > were transmitted separately - multiple Rcpt To lines with one Data phase for > teh To and cc recipients, single Rcpt lines with a data phase for each bcc > recipient. Since Phill is as much of an antique as I am, maybe he too > remembers MUAs which did rather pleasant and intelligent things that didn't > conform to the modern desire for "efficiency" at all costs (even at the cost > of effectiveness) and maybe that's where theerrorneous statement comes from. > An easy mistake to make if you grew up with civilised MUAs. I still use an MUA whose first version probably predates the MUA that you are thinking of. It sends a single copy with the BCC recipients mentioned only in the envelope. The only older UNIX MUA that I've used of also sent only a single copy. (Email systems I used before UNIX were too different to mention.) The MUA that I recall that did as you describe was a fancy, "extensible," and "user friendly" package offered as a replacement for those two older MUAs. I've often wished that my preferred MUA would do as you describe, because I've learned the hard way the importance of preceding a BCC'ed message with another that says something like "the following is a BCC so don't reply to all." > >What discourages me most about this mailing list are self-described > >expert statements such as "the RFC822 message standard requires every > >message to have a valid To: CC: or BCC: field identifying the recipient, > >making adjustment where necessary to account for messages relayed > >through mailing lists." There are obvious reasons why RFC 822 and > >RFC 2822 do not require mailing list exploders to anything of the sort. > > Heavy protestations of knowledg and expertise which are clearly false bother > me too, but I also know the story about the pot and the kettle. Are you sure you see all of the relevant applications of the pot and kettle story? Do you see some of the obvious reasons why RFC 822, RFC 821, RFC 2822, and RFC 2821 do not contain the words that the other person thought they do? Did you check RFC 2822 on BCC headers? Requiring that every message list the recipient in a To, CC, or BCC header would require that the MTA serving the MUA that is the mailing list exploder send each copy to the next hop MTA by a separate SMTP transaction. The exploder MUA might do as it does now, sending messages to its MTA, each addressed to from 10, 100s, or perhaps 1000s of targets, but unlike now, the MUA would add to message BCC headers for each addressee in the batch. To honor the blindness required of a BCC (and the "Security Considerations" in RFC 2822), the MTA must convert those individual batch messages into sparate messages. Each new message would contain a single BCC header mentioning a single addressee, and would be handled in a separate SMTP transaction. Alternatively, the exploder MUA could generate the separate messages, each with a single BCC header. Have you watched an SMTP client responsible for passing a modest (few 1000 subscribers) or larger mailing list, particularly on hardware and networks more than 10 years old? Mailing list subscribers have always tended to be clustered on SMTP servers, even before big ISPs like AOL. Requiring separate transactions for each addressee would increase the load on the system by 10 times. I suspect that is why sendmail at least as early as the mid-1980s was willing to sort by next-hop and use a single SMTP transaction when possible. Vernon Schryver vjs@rhyolite.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 10:33:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13882 for ; Thu, 1 May 2003 10:33:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41EdjG12430 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 10:39:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Edj812427 for ; Thu, 1 May 2003 10:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13852; Thu, 1 May 2003 10:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BF9d-0001zk-00; Thu, 01 May 2003 10:35:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BF9c-0001zh-00; Thu, 01 May 2003 10:35:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EbN811962; Thu, 1 May 2003 10:37:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EaP811348 for ; Thu, 1 May 2003 10:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13574 for ; Thu, 1 May 2003 10:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BF4c-0001vY-00 for asrg@ietf.org; Thu, 01 May 2003 10:30:10 -0400 Received: from host217-35-105-169.in-addr.btopenworld.com ([217.35.105.169] helo=mail.neosinteractive.com) by ietf-mx with esmtp (Exim 4.12) id 19BF4W-0001uy-00 for asrg@ietf.org; Thu, 01 May 2003 10:30:05 -0400 Received: from tthompson ([217.35.105.173] unverified) by mail.neosinteractive.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 May 2003 15:34:32 +0100 From: "Tom Thomson" To: Subject: RE: [Asrg] Proposal for transition to authenticated email Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <200304282201.h3SM1JbR001866@calcite.rhyolite.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 01 May 2003 14:34:32.0908 (UTC) FILETIME=[C80798C0:01C30FEE] Content-Transfer-Encoding: 7bit Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 15:29:32 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >If any of that were true, then it would be equally true of ISPs. >Every SMTP message carries a practically unforgeable token identifying >and authenticating the previous hop ISP. If certificate authorities >could be trusted to police customers that spend $100/year for a >certificate, then ISPs could be trusted to police customers that spend >$240/year for ISP service. > > >Vernon Schryver vjs@rhyolite.com That sounds like a nonsense argument to me (but carefully phrased to look misleadingly plausible). An ISP has a lot of costs to cover for its $200 per year that a CA doesn't have to cover. That's why ISPs charge more for ISP service that CAs charge for certificates. Sometimes it seems to me that CAs do very little for their $100 per year, so they should have spare cash they could use to pay for the policing; perhaps that's an unfair view of CAs. There are a very large number of ISPs, so many that we can't keep track of them all so it's impossible to establish a trust relationship with them all, so it woukld be no good pretrnding we can trust them to do the policing even if they charged quite silly prices; there are far fewer CAs, it might be possible to establish the trust necessary relationships. I think the problem you have with proposals for authenticated email is a simple one - the same problem you have with the RMX proposal: you simply don't want a reliable way of tying spam to its originator, you would rather play with interesting methods of detecting spam and filtering it out. I don't know whether that's because you don't see the usefulness of being able to identify the originator, or because you find detecting bulk mail a fun passtime, or because you think RFC 2821 is holy writ and not a comma may be moved on pain of burning in hell throughout eternity for fould heresy and blasphemy. It has to be one of those three, I can't imagine another reason. Spam is a social problem, not a purely technical one. As with all anti-social behaviour, being able to identify the perpetrators will be useful. I'm not claiming that that's the only thing we have to do, just that it is an essential component of any proper answer to our problem. So I son't see it as helpful to sit back and snipe at every proposal that is ever made that stands any real chance of delivering some sort of reliable identification of the senders, particularly since most of the sniping you do is based around misleading arguments like the one you produced above. Tom _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 11:03:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15605 for ; Thu, 1 May 2003 11:03:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41F9Zi19130 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 11:09:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41F9Z819127 for ; Thu, 1 May 2003 11:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15558; Thu, 1 May 2003 11:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFcU-0002Qe-00; Thu, 01 May 2003 11:05:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BFcU-0002Qb-00; Thu, 01 May 2003 11:05:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41F6l817998; Thu, 1 May 2003 11:06:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EmE814678 for ; Thu, 1 May 2003 10:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14406 for ; Thu, 1 May 2003 10:41:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFHq-00028l-00 for asrg@ietf.org; Thu, 01 May 2003 10:43:50 -0400 Received: from www.somewhere.com ([66.92.72.194] helo=somewhere.com) by ietf-mx with esmtp (Exim 4.12) id 19BFHk-000278-00 for asrg@ietf.org; Thu, 01 May 2003 10:43:44 -0400 Received: from [66.92.72.194] (account nazgul HELO [192.168.1.104]) by somewhere.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 2305400; Thu, 01 May 2003 09:42:18 -0500 Mime-Version: 1.0 X-Sender: nazgul@somewhere.com@pop.messagefire.com Message-Id: In-Reply-To: <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> References: <013301c30dc8$df22dc90$b1ad86a2@hirschk1> <01bd01c30e0a$4cc9c7e0$0201a8c0@DXHIRX1> <02d401c30eaf$b5563fa0$0201a8c0@DXHIRX1> <03cb01c30ed8$0acae620$0201a8c0@DXHIRX1> <200305010156.h411uoQM008784@new.agentzero.com> <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> To: "Ken Hirsch" From: Kee Hinckley Subject: Re: [Asrg] Proposal for transition to authenticated email Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 10:34:58 -0400 At 4:22 AM -0400 5/1/03, Ken Hirsch wrote: > > Further, why should an independent organization's e-mail policies >be subject >> to the wholly unrelated policies of an intermediate party? > >Because the current system is broken! That doesn't excuse creating more problems. >The actual impact of these changes is tiny. So far people have >legitimately pointed >out: >1) Now, you can use TLS to the end server. >2) You get feedback from one hop later if you do the SMTP yourself. 3) You are talking about regulating the creation of at least three brand new industries that don't even exist right now. 4) You repeatedly ignore the cost issue--in fact, you don't even understand the current costs for services like those you describe, let alone what the potential costs would be. We keep telling you--based on our experience selling, supporting, writing and working with commercial email and commercial companies that this is not a trivial change. Please explain how your real world experience differs. >Come to think of it, if you accept TLS, you probably already got a >certificate! >Will the new certificate be so much more of a burden than the current one? >(Slightly more rigorous, hopefully.) 1. My current certificate can be self-signed. 2. Even if it's not, it costs less than $100. At 5:49 AM -0400 5/1/03, Ken Hirsch wrote: >A certificate that provides strong identity (e.g. government-issued) is >not by itself sufficient as an antispam certificate. A CA would have >to (1) check it against a database of known spammers (2) get the person >to sign a contract to abide by a set of antispam policies and (3) have >a set of procedures to handle complaints against the person (including >reporting the person to the database if they do not cooperate). What do you think these (currently non-existent) certificates would cost? On what basis do you make the assumption. Ask Phillip why personal certs with real identity checks aren't readily available. Never mind ones that guarantee that you aren't a spammer. -- Kee Hinckley http://www.messagefire.com/ Junk-Free Email Filtering http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 11:24:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16854 for ; Thu, 1 May 2003 11:24:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FUDO24438 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 11:30:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FUD824435 for ; Thu, 1 May 2003 11:30:13 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16817; Thu, 1 May 2003 11:23:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FR9823525; Thu, 1 May 2003 11:27:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FQp823382 for ; Thu, 1 May 2003 11:26:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16507 for ; Thu, 1 May 2003 11:20:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFrt-0002g0-00 for asrg@ietf.org; Thu, 01 May 2003 11:21:05 -0400 Received: from oreo.couchpotato.net ([208.147.134.98]) by ietf-mx with smtp (Exim 4.12) id 19BFri-0002br-00 for asrg@ietf.org; Thu, 01 May 2003 11:20:54 -0400 Received: (qmail 4018 invoked from network); 1 May 2003 15:17:28 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by oreo.couchpotato.net with SMTP; 1 May 2003 15:17:28 -0000 Subject: Re: [Asrg] Domain-Authorized SMTP Mail From: David Green To: Jon Kyme Cc: ASRG In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8bscQ0oXBDRPOwX7RVZn" Message-Id: <1051802248.20657.1.camel@david.couchpotato.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4-1.1mdk Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: 01 May 2003 11:17:28 -0400 --=-8bscQ0oXBDRPOwX7RVZn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Good point. I reworded it to make it more clear. I've actually received some suggestions to avoid stripping of headers altogether, since SMTP servers don't generally do this. 3. MT DNS queries and Authorized-By SMTP headers = =20 SMTP servers MUST remove any Authorized-By SMTP headers of incoming mail from untrusted servers. They SHOULD be configurable to preserve Authorized-By headers on incoming mail from a set of trusted servers. Cheers, David Green On Thu, 2003-05-01 at 02:45, Jon Kyme wrote: > >=20 > > I posted the "Domain Authorized SMTP Mail" proposal to this mailing lis= t > > some time ago, and I've since created a separate web site for it. Here'= s > > the link: > >=20 >=20 >=20 > I'm not sure how this works: > > SMTP servers MUST remove any Authorized-By SMTP headers of > incoming mail. They SHOULD be configurable to preserve Authorized-By > headers on incoming mail from a set of trusted servers. > >=20 > The first sentence seems to preclude the second. >=20 >=20 >=20 >=20 >=20 >=20 > -- --=20 David Green --=-8bscQ0oXBDRPOwX7RVZn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+sTqICi6CzkbyeRQRAuNiAKCvaaaIrNKkrkJ7rP9zBPCp2aeWqgCfaRkN Gy1C9r845V93cg/y2TzRHg0= =CdVR -----END PGP SIGNATURE----- --=-8bscQ0oXBDRPOwX7RVZn-- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 11:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17584 for ; Thu, 1 May 2003 11:37:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FhAG28128 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 11:43:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FhA828117 for ; Thu, 1 May 2003 11:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17558; Thu, 1 May 2003 11:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BG8o-0002ri-00; Thu, 01 May 2003 11:38:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BG8n-0002rf-00; Thu, 01 May 2003 11:38:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FcI826987; Thu, 1 May 2003 11:38:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fbv826971 for ; Thu, 1 May 2003 11:37:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17329 for ; Thu, 1 May 2003 11:31:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BG3w-0002oC-00 for asrg@ietf.org; Thu, 01 May 2003 11:33:32 -0400 Received: from agentzero.com ([216.40.238.8] helo=new.agentzero.com) by ietf-mx with esmtp (Exim 4.12) id 19BG3q-0002nf-00 for asrg@ietf.org; Thu, 01 May 2003 11:33:26 -0400 Received: from [65.56.5.172] (dialup-64.158.96.232.Dial1.Cleveland1.Level3.net [64.158.96.232]) by new.agentzero.com (8.12.9/8.12.9) with ESMTP id h41FZJQI001504; Thu, 1 May 2003 11:35:20 -0400 Message-Id: <200305011535.h41FZJQI001504@new.agentzero.com> Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> References: <013301c30dc8$df22dc90$b1ad86a2@hirschk1> <01bd01c30e0a$4cc9c7e0$0201a8c0@DXHIRX1> <02d401c30eaf$b5563fa0$0201a8c0@DXHIRX1> <03cb01c30ed8$0acae620$0201a8c0@DXHIRX1> <200305010156.h411uoQM008784@new.agentzero.com> <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> To: "Ken Hirsch" , From: Jim Youll Subject: Re: [Asrg] Proposal for transition to authenticated email Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 11:33:27 -0400 At 4:22 -0400 5/1/03, Ken Hirsch wrote: >From: "Jim Youll" >> You're missing lots of issues, like all the sites that aren't at the end of >> a whomping fast Internet connection... the big messages dribble in over the >> slow link and local access is decoupled from link speed. When I put up my >> first home Linux server many years ago, it was on a demand-dialed line and >> it batched out the locally-gathered mail every 30 minutes.. the ISP was >> an MX secondary for inbound mail. > >I don't understand this objection. You can send to the ISP's SMTP >server at the >same speed as you send to another SMTP server. Not exactly. My laptop can send mail to the in-house server at 10 to 100mbps. I close the lid and leave. The in-house server can batch the mail out in 30 minutes, at 128Kbps over ISDN to the destination. there's no benefit to adding another hop for the mail in the middle of all this. > > Further, why should an independent organization's e-mail policies >be subject >> to the wholly unrelated policies of an intermediate party? > >Because the current system is broken! > >> Should we also >> proxy all web serving and retrieval through the ISP too? > >No. > >> Shall we ask the ISP >> to maintain our e-mail accounts? Do we then have to trust the ISP to store >> all these messages? What about privacy? > >I'm only talking about outgoing messages. > >> Since there will be hundreds of thousands of SMTP servers no matter how >> loudly anyone here complains, there is little point in trying to shout >> against the wind in this way. > >Yeah, yeah, nothing will ever change. The world will come to an end if these >regulations pass. People say things all the time. Then the >regulations pass and >it's no big deal. I'm more interested in whether the regulations >will work. Yes >there are costs, but there are costs to the current situation and to any other >solution, too. Here we disagree. I think the trend is toward more of all kinds of servers, not less. Teasing out e-mail may solve one problem, or if the solution is not well liked, will just push users (and the same problems) onto other technologies. Already people are starting to have home media servers. Why would you NOT put e-mail in there too? E-mail is not so special compared to the myriad other digital services we now publish and consume... there is just this problem of spam, and it's an incentive and accountability problem, more than anything else. How in the world can you regulate these bits? Can i ignore your regulations? How about if I adopt a different protocol? When is e-mail like instant messaging? When is it like newsgroups? Yes i am thinking abstractly. >Right now the reliability of email is just so-so. And spam contributes to the >problem. I will note that hierarchically-structured systems (like >the phone system) >tend to be more reliable than N^2 connection sytems. But the phone system is centrally controlled and slow-changing. messaging protocols that are being reinvented every day, over this messy, heterogeneous and evolving network, are not like that. I worry a lot about too-strong controls being put in place too early. We are in the first moments of this technology, and none of it is mature. I would rather build protocols that support further evolution and improvement, than rulemaking that could potentially freeze progress at this point. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 11:57:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18968 for ; Thu, 1 May 2003 11:57:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41G3ZH32761 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:03:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41G3Z832758 for ; Thu, 1 May 2003 12:03:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18853; Thu, 1 May 2003 11:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGSk-0003B3-00; Thu, 01 May 2003 11:59:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGSj-0003Ao-00; Thu, 01 May 2003 11:59:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fw3831370; Thu, 1 May 2003 11:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fvv831355 for ; Thu, 1 May 2003 11:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18519 for ; Thu, 1 May 2003 11:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGN3-000360-00 for asrg@ietf.org; Thu, 01 May 2003 11:53:17 -0400 Received: from lvs00-fl.valueweb.net ([216.219.253.199] helo=ams004.ftl.affinity.com) by ietf-mx with esmtp (Exim 4.12) id 19BGMv-00034d-00 for asrg@ietf.org; Thu, 01 May 2003 11:53:10 -0400 Received: from DAVELAPTOP ([66.160.84.232]) by lmg.ahnet.net with ESMTP id <235210-12084>; Thu, 1 May 2003 11:52:19 -0400 From: "Dave Hendricks" To: "'IRTF Anti-Spam Research Group'" Subject: RE: So what's the *right* way to be a bulkmailer? (Was RE: [Asrg] A New Plan for No Spam / DNSBLS) Message-ID: <00f201c30ff9$a3a070a0$6628fea9@DAVELAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41Fvw831356 Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 11:52:15 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit As a veteran of the so-called permission marketing industry, I have offered my pithy comments to the ones made below. So. Let's say you are that company. You have tens or hundreds of > thousands of clients with millions or tens of millions of email > addresses. > [ ... ] > > What kind of system will make this all work with maximum success? > Perfection is not a goal, it's not possible. What's going to give > optimal results? > > > And don't say "confirmed opt-in". That's a policy. Maybe right, > maybe wrong. But anyone can say it. How are you going to enforce > compliance with the above list managers? You raise some good points (most of which I've snipped). However, I will say "confirmed opt-in". And I would enforce the compliance in part by using complaints and DNSBL listings. 1: Actually, I will say "confirmed opt-in with yearly renewals". Every new list you get, you require all list members to "renew" their subscription to the mailing list and they must continue to renew their subscription every year or so. Save these confirmations and renewals so that if there is any dispute, you have something to show that you are not sending unsolicited email. Unlike initial subscriptions, I think it would probably be reasonable to send maybe two emails about the renewal. Just like initial subscriptions, the renewal request must not contain any advertising and the description of the mailing list should be brief and approved by the bulk mailers. A: This is not going to happen. Marketers spend many years and many dollars to build legitimate lists through their websites and POS and they will not voluntarily chop it in half just because someone didn't 're-up'. Many customers who get email newsletters selling products buy something once or twice a year, and often don't open the messages for months at a time, but continue to want to subscribe - they buy seasonally for example. This approach is not practical and has no chance of being adopted. 2: Bulk mailers should get as many IP addresses as possible, preferably some in different CIDR blocks. New customers (not subscribers) with their own lists would be put on "high risk" IP addresses that DNSBLs may quickly blacklist. As time passes and the number of emails sent to the list increases without complaints, you can move the lists to lower risk IP addresses. How many different pools of risk levels you need will have to be determined by experience. A: The legitimate email marketing houses already use either individual netblocks, MTAs or subdomains (or a combination) to separate their clients out. This is a very effective way to make sure that high risk clients can be isolated. Moving them around different netblocks as you describe would only make it look like something fishy was happening with the list. And enough complaints would get the client fired, most likely. 3. Bulk emailers need to watch DNSBLs and abuse complaints very carefully. If complaints start coming from a particular mailing list, then they need to moved into higher risk IP blocks or segregated into an IP address by itself. A: They watch spews and other dnsbl's very closely. Getting off of those lists is very difficult. More important to most are relationships with top ISPs, those being Yahoo, MSN, AOL, Earthlink, etc. 4. New customers should be required to physically sign a contract, and place a "large" damage deposit which will be refunded when the mailing list has reached a low enough risk category. Maybe a $1000 + $0.01/email deposit would work. A: No customer thinks its list is dirty. If you think that their list is dirty enough to consider escrow, it is best not to work with that client in the first place. 5. The bulk emailer could then almost advertise about how their low risk customers are rarely, if ever, placed on DNSBLs. Actually, this kind of procedure would probably scare away most spammers also, so the bulk emailer would mostly have to deal with people who don't quite understand email rather than people who are outright trying to deceive them. A: This happens organically by not being a spammer, but still sending bulk commercial 'permission' mail. 6. Basically, I think that nothing really needs to be changed at the technical level. It is all a matter of bulk emailers implementing policies that keep them out of trouble rather than send the most email. A: You are wrong. The legitimate mailers that you target with these proposals typically already do this right. Spammers do not adhere to these rules and will not. These spammers are the ones that this group wants to shut down. They do not comply with 'best practices' that we promulgate here. That is why legislative and other sociological approaches will not work - only technical solutions will. Economic approaches are a very close second, since spam is really an economic issue at its heart. 7. Some might complain that this type of system will cost a lot more money, but I'm not so sure that is true. The low risk lists will cost the bulk emailer below average costs and they will probably be able to charge above average fees and that can pay for the expense of making sure the lists are clean. A: The email marketing business is highly competitive, making this final assertion/suggestion also less than practical. Dave Hendricks Permission Technology Suite 100 1261 Post Road Fairfield CT, 06430 203 254 7222 203 254 9222 dave@permissiontechnology.com www.permissiontechnology.com -----Original Message----- From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org] On Behalf Of wayne Sent: Wednesday, April 30, 2003 10:12 PM To: IRTF Anti-Spam Research Group Subject: Re: So what's the *right* way to be a bulkmailer? (Was RE: [Asrg] A New Plan for No Spam / DNSBLS) In Kee Hinckley writes: > > So. Let's say you are that company. You have tens or hundreds of > thousands of clients with millions or tens of millions of email > addresses. > [ ... ] > > What kind of system will make this all work with maximum success? > Perfection is not a goal, it's not possible. What's going to give > optimal results? > > > And don't say "confirmed opt-in". That's a policy. Maybe right, > maybe wrong. But anyone can say it. How are you going to enforce > compliance with the above list managers? You raise some good points (most of which I've snipped). However, I will say "confirmed opt-in". And I would enforce the compliance in part by using complaints and DNSBL listings. Actually, I will say "confirmed opt-in with yearly renewals". Every new list you get, you require all list members to "renew" their subscription to the mailing list and they must continue to renew their subscription every year or so. Save these confirmations and renewals so that if there is any dispute, you have something to show that you are not sending unsolicited email. Unlike initial subscriptions, I think it would probably be reasonable to send maybe two emails about the renewal. Just like initial subscriptions, the renewal request must not contain any advertising and the description of the mailing list should be brief and approved by the bulk mailers. Bulk mailers should get as many IP addresses as possible, preferably some in different CIDR blocks. New customers (not subscribers) with their own lists would be put on "high risk" IP addresses that DNSBLs may quickly blacklist. As time passes and the number of emails sent to the list increases without complaints, you can move the lists to lower risk IP addresses. How many different pools of risk levels you need will have to be determined by experience. Bulk emailers need to watch DNSBLs and abuse complaints very carefully. If complaints start coming from a particular mailing list, then they need to moved into higher risk IP blocks or segregated into an IP address by itself. New customers should be required to physically sign a contract, and place a "large" damage deposit which will be refunded when the mailing list has reached a low enough risk category. Maybe a $1000 + $0.01/email deposit would work. The bulk emailer could then almost advertise about how their low risk customers are rarely, if ever, placed on DNSBLs. Actually, this kind of procedure would probably scare away most spammers also, so the bulk emailer would mostly have to deal with people who don't quite understand email rather than people who are outright trying to deceive them. Basically, I think that nothing really needs to be changed at the technical level. It is all a matter of bulk emailers implementing policies that keep them out of trouble rather than send the most email. Some might complain that this type of system will cost a lot more money, but I'm not so sure that is true. The low risk lists will cost the bulk emailer below average costs and they will probably be able to charge above average fees and that can pay for the expense of making sure the lists are clean. -wayne _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 12:04:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19447 for ; Thu, 1 May 2003 12:04:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41G60f00959 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:06:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41G60800956 for ; Thu, 1 May 2003 12:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19121; Thu, 1 May 2003 11:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGV5-0003Dz-00; Thu, 01 May 2003 12:01:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGV4-0003Du-00; Thu, 01 May 2003 12:01:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fs6830582; Thu, 1 May 2003 11:54:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Frv830560 for ; Thu, 1 May 2003 11:53:57 -0400 Received: from ams003.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18290 for ; Thu, 1 May 2003 11:47:05 -0400 (EDT) Received: from DAVELAPTOP ([66.160.84.232]) by lmg.ahnet.net with ESMTP id <264498-17728>; Thu, 1 May 2003 11:31:15 -0400 From: "Dave Hendricks" To: Message-ID: <00e901c30ff6$b27b6ab0$6628fea9@DAVELAPTOP> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C30FD5.2B69CAB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Asrg] FTC Anti-spam conference update - Weds 4/30 sessions Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 11:31:08 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C30FD5.2B69CAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Folks: =20 Greetings from Washington DC, where today (May 1) is more reminiscent of August 1 in terms of temp. =20 Yesterday's FTC anti-spam conference was interesting to say the least. Highlights? Not many. =20 The first session ('intro to spam') featured spammers from Empire Towers = and the head of the DMA Robert Wientzen, who was least well received for = stating that some commercial email was perfectly acceptable. See the DM News (www.dmnews.com ) for Ken Magill's story about = it. Senators Burns and Wyden also spoke, introducing and explaining their = bill to the audience. =20 The second session was more interesting ('email address gathering') and featured presentations from Matthew Steele of Brightmail and Doug Mclean = of Postini. Steele's presentation (the better of the two for being less marketing and more technical) was a practical how to on how to collect = email addresses using harvesting tools such as "Power Email Verifier 2.1". If = I were a novice spammer and wanted to learn the rudiments of directory harvesting, this was a good presentation. Also on the panel was a = gentleman named William Waggoner of AAW (who has heard of them?), who claimed that Google sells traffic and generates pop-up ads. The Google guy on the = panel (David DesJardins) and the audience got a kick out of that. Despite vigorous talk for 1.5 hours about Directory Harvesting, there were no recommendations for what to do about it, other than coding email = addresses on sites with HTML or javascript and not 'mailto:' links. No = discussions of legality of the process of harvesting. Directory attacks also came up = with the sole recommendation that you should make your email address longer = than 6 characters and not post it on Usenet. Duh! One panel member defended = the practice of using bounces for list cleaning purposes. =20 The third session was titled 'Falsity in sending of spam' concerned the intricacies - and to a very minor extent the legality - of falsifying headers and other information. This panel was led off by a presentation from AOL's Margot Koschier (mgr antispam analysis and prevention) who performed a demo using Telnet on how to falsify a message header. = Another excellent how-to for the aspiring spammer. Again in this panel, no recommendations for action. However, much wasted time spent discussing = the urban myth of not hitting unsubscribe within spam messages. The panel = had apparently never heard of web beacons within HTML email. =20 Right before the fourth session, NY's Senior Senator Chuck Schumer had = an impromptu news conference for his announcement of his anti-spam bill. = The Senator's solution was to force all mailers of commercial mail (and no distinction was made between spam and legitimate business = communications) to put 'ADV:' before the subject line. Another cornerstone of his = legislative approach was extensive fines and even - gasp - jail time for spammers. = He wants to establish a national 'Do Not Email' list as well. And stated = that it would have 'military-quality encryption'. No details on who would = manage this and how it would be utilized. He also spoke out against directory harvesting, fake subject line and reply addresses and non-functioning unsubscribe links. As anti-spam as everyone on this list is, from what = I heard in the Senator's brief presentation this is not practical nor = likely to be supported by either marketers or technically sophisticated = anti-spam zealots. =20 The fourth session was titled 'Open Relays/Open Proxies/Form mail = Scripts'. This was an interesting session as it also offered some more how to's on = how to locate and exploit open proxies and relays. Matt Sergeant of = MessageLabs put together a good presentation that described open proxies. The = consensus if I remember correctly was that there are 400 new open relays each day = and many of these are outside of the US, especially in Korea. Another demonstration and explanation was given on setting up Zombie netblocks. = A question was asked whether the government should get involved to close = all of the open relays and the answer was no. =20 =20 So far no solution to end spam. However, the free cookies and bottled = water were a nice touch. =20 Dave Hendricks =20 Permission Technology Suite 100 1261 Post Road Fairfield CT, 06430 =20 203 254 7222 (voice) 203 254 9222 (fax) 917 833 2242 (mobile) mailto:dave@permissiontechnology.com www.permissiontechnology.com =20 ------=_NextPart_000_00EA_01C30FD5.2B69CAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Folks:

 

Greetings from Washington DC, where today (May 1) is more reminiscent of August 1 in terms of = temp.

 

Yesterday’s FTC anti-spam conference was = interesting to say the least.  Highlights?  Not many.

 

The first session (‘intro to spam’) featured spammers from Empire Towers and the = head of the DMA Robert Wientzen, who was least well received for stating that = some commercial email was perfectly acceptable.  See the DM News (www.dmnews.com) for Ken = Magill’s story about it.  Senators Burns and Wyden also spoke, introducing and = explaining their bill to the audience.

 

The second session was more interesting = (‘email address gathering’) = and featured presentations from Matthew Steele of Brightmail and Doug Mclean = of Postini.  Steele’s presentation (the better of the two for being less marketing and more technical) was a practical how to on how to collect = email addresses using harvesting tools such as “Power Email Verifier = 2.1”.  If I were a novice spammer and wanted to learn the rudiments of = directory harvesting, this was a good presentation.  Also on the panel was a gentleman = named William Waggoner of AAW (who has heard of them?), who claimed that = Google sells traffic and generates pop-up ads.  The Google guy on the panel = (David DesJardins) and the audience got a kick out of that.  Despite vigorous talk for = 1.5 hours about Directory Harvesting, there were no recommendations for what = to do about it, other than coding email addresses on sites with HTML or = javascript and not ‘mailto:’ links.  No discussions of legality of = the process of harvesting.  Directory attacks also came up with the = sole recommendation that you should make your email address longer than 6 = characters and not post it on Usenet.  Duh!  One panel member defended = the practice of using bounces for list cleaning purposes.

 

The third session was titled ‘Falsity in sending of spam’ concerned the intricacies - and to a very minor extent the legality – of = falsifying headers and other information.  This panel was led off by a = presentation from AOL’s Margot Koschier (mgr antispam analysis and prevention) = who performed a demo using Telnet on how to falsify a message header.  = Another excellent how-to for the aspiring spammer.  Again in this panel, no recommendations for action.  However, much wasted time spent = discussing the urban myth of not hitting unsubscribe within spam messages.  = The panel had apparently never heard of web beacons within HTML = email.

 

Right before the fourth session, NY’s Senior = Senator Chuck Schumer had an impromptu news conference for his announcement of = his anti-spam bill.  The Senator’s solution was to force all = mailers of commercial mail (and no distinction was made between spam and legitimate business communications) to put ‘ADV:’ before the subject line.  Another cornerstone of his legislative approach was = extensive fines and even – gasp – jail time for spammers.  He wants to establish a national ‘Do Not Email’ list as well.  And = stated that it would have ‘military-quality encryption’.  No = details on who would manage this and how it would be utilized.  He also = spoke out against directory harvesting, fake subject line and reply addresses and non-functioning unsubscribe links.  As anti-spam as everyone on = this list is, from what I heard in the Senator’s brief presentation this is = not practical nor likely to be supported by either marketers or technically = sophisticated anti-spam zealots.

 

The fourth session was titled ‘Open Relays/Open Proxies/Form mail = Scripts’.  This was an interesting session as it also offered some more how = to’s on how to locate and exploit open proxies and relays.  Matt Sergeant = of MessageLabs put together a good presentation that described open proxies.  The consensus if I remember correctly was that there are 400 new open relays = each day and many of these are outside of the US, = especially in Korea.  Another demonstration and explanation was given on setting up Zombie netblocks. =  A question was asked whether the government should get involved to close = all of the open relays and the answer was no. 

 

So far no solution to end spam.  However, the = free cookies and bottled water were a nice touch.

 

Dave Hendricks

 

Permission Technology

Suite 100

1261 Post Road

Fairfield CT, 06430

 

203 254 7222 (voice)

203 254 9222 (fax)

917 833 2242 (mobile)

mailto:dave@permissiontechn= ology.com

www.permissiontechnology.com

 

------=_NextPart_000_00EA_01C30FD5.2B69CAB0-- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 12:28:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20885 for ; Thu, 1 May 2003 12:28:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GZ0v07989 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:35:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GYx807986 for ; Thu, 1 May 2003 12:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20864; Thu, 1 May 2003 12:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGx7-0003cR-00; Thu, 01 May 2003 12:30:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGx7-0003cN-00; Thu, 01 May 2003 12:30:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GX8807881; Thu, 1 May 2003 12:33:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GL4806229 for ; Thu, 1 May 2003 12:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20138 for ; Thu, 1 May 2003 12:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGje-0003RF-00 for asrg@ietf.org; Thu, 01 May 2003 12:16:38 -0400 Received: from adsl-63-195-85-27.dsl.snfc21.pacbell.net ([63.195.85.27] helo=zardoc.esmtp.org) by ietf-mx with esmtp (Exim 4.12) id 19BGjX-0003Q0-00 for asrg@ietf.org; Thu, 01 May 2003 12:16:32 -0400 Received: from zardoc.esmtp.org (localhost [127.0.0.1]) by zardoc.esmtp.org (8.12.9/8.12.7.Beta1) with ESMTP id h41FlPTo027563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 May 2003 08:47:26 -0700 (PDT) Received: (from ca@localhost) by zardoc.esmtp.org (8.12.7/8.12.0.Beta12) id h41FlPTo021698 for asrg@ietf.org; Thu, 1 May 2003 08:47:25 -0700 (PDT) From: Claus Assmann To: asrg@ietf.org Subject: Re: [Asrg] Proposal for transition to authenticated email Message-ID: <20030501084725.A14507@zardoc.esmtp.org> Reply-To: asrg@ietf.org References: <20030430104613.A14350@zardoc.esmtp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from feenberg@nber.org on Wed, Apr 30, 2003 at 05:50:33PM -0400 Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 08:47:25 -0700 On Wed, Apr 30, 2003, Daniel Feenberg wrote: > Wouldn't TLS traffic go via port 465 in most cases? I don't think any No. I'm talking about STARTTLS, not smtps. > of the proposals here are intended to regulate anything except port 25. > > In any case, for TLS wouldn't you need explicit cooperation from the the > remote MTA, in which case the pair of you could agree to use a port other There is a standard, why do you want to invent something new? It's hard enough to get people to use this standard, no need to make it even more complicated... > than 25. Or is there a way to use TLS when communicating with strangers? Yes. Please see RFC 2487 (SMTP Service Extension for Secure SMTP over TLS). _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 12:47:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21674 for ; Thu, 1 May 2003 12:47:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GrJv11842 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:53:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GrJ811839 for ; Thu, 1 May 2003 12:53:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21650; Thu, 1 May 2003 12:46:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHEq-0003nB-00; Thu, 01 May 2003 12:48:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BHEp-0003n7-00; Thu, 01 May 2003 12:48:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GlN810924; Thu, 1 May 2003 12:47:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Ggc809970 for ; Thu, 1 May 2003 12:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21146 for ; Thu, 1 May 2003 12:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BH4W-0003gI-00 for asrg@ietf.org; Thu, 01 May 2003 12:38:12 -0400 Received: from peacock.verisign.com ([65.205.251.73]) by ietf-mx with esmtp (Exim 4.12) id 19BH4Q-0003f9-00 for asrg@ietf.org; Thu, 01 May 2003 12:38:06 -0400 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by peacock.verisign.com (8.12.9/) with ESMTP id h41GbH4u021437; Thu, 1 May 2003 09:37:28 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 07:04:41 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Vernon Schryver'" , "'asrg@ietf.org'" Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 07:01:28 -0700 Actually I find it rather difficult to accept the terms 'design' and smtp in the same sentence without a negative inbetween. Interpretation of ietf docments of the era are at best an exercise in hermeneutics. I use the term advisedly since there is much that is not written that is as important as that which is. Do not ascribe to ignorance of others what may be due to your own lack of knowledge. In this environment that type of talk is far more insulting than anything else which may be said. Rfc822 is a deeply flawed document. It was written in an ra when we did not know better and it was writen in an era when rfc meant what it says. Rfcs began not as standards but as the starting point for standards. But even so it does not state that the to cc etc addresses mean other than what one would assume them to mean. My position is quite clear, he definitin of smtp is embedded in internet usage. I would no more expect to be able to know the smtp spec from the rfcs than I would expect to understand theology from reading the bible alone. -----Original Message----- From: Vernon Schryver Sent: Thu May 01 06:30:59 2003 To: asrg@ietf.org Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator > From: "Tom Thomson" > Phill's document already points out that mailing lists are an exception > which require exceptional treatment, so your "case in point" appears to be > vacuous padding to try to fool us into thinking your message has more > substance than it has. He did not say that mailing list software should be changed, but in effect said that all major past and current SMTP mailing list software violates words in RFC 822 that do not exist. In fact RFC 2822 not only does not require that recipients be listed, but allows an MTA to remove BCCs. He probably made the mistake common among end users who complain about spam not containing their addresses, because they do not know about or understand the significance of the SMTP envelope. If you have not spent much time fighting spam or SMTP servers in more than their external configuration spam, it is easy to not know about the SMTP envelope. > As for the bcc case, I used to use an MUA which generated n+1 copies of the > body - 1 for each bcc recipient containing a bcc line with only that > recipient, and one for all To and cc recipient containing no bcc line. These > were transmitted separately - multiple Rcpt To lines with one Data phase for > teh To and cc recipients, single Rcpt lines with a data phase for each bcc > recipient. Since Phill is as much of an antique as I am, maybe he too > remembers MUAs which did rather pleasant and intelligent things that didn't > conform to the modern desire for "efficiency" at all costs (even at the cost > of effectiveness) and maybe that's where theerrorneous statement comes from. > An easy mistake to make if you grew up with civilised MUAs. I still use an MUA whose first version probably predates the MUA that you are thinking of. It sends a single copy with the BCC recipients mentioned only in the envelope. The only older UNIX MUA that I've used of also sent only a single copy. (Email systems I used before UNIX were too different to mention.) The MUA that I recall that did as you describe was a fancy, "extensible," and "user friendly" package offered as a replacement for those two older MUAs. I've often wished that my preferred MUA would do as you describe, because I've learned the hard way the importance of preceding a BCC'ed message with another that says something like "the following is a BCC so don't reply to all." > >What discourages me most about this mailing list are self-described > >expert statements such as "the RFC822 message standard requires every > >message to have a valid To: CC: or BCC: field identifying the recipient, > >making adjustment where necessary to account for messages relayed > >through mailing lists." There are obvious reasons why RFC 822 and > >RFC 2822 do not require mailing list exploders to anything of the sort. > > Heavy protestations of knowledg and expertise which are clearly false bother > me too, but I also know the story about the pot and the kettle. Are you sure you see all of the relevant applications of the pot and kettle story? Do you see some of the obvious reasons why RFC 822, RFC 821, RFC 2822, and RFC 2821 do not contain the words that the other person thought they do? Did you check RFC 2822 on BCC headers? Requiring that every message list the recipient in a To, CC, or BCC header would require that the MTA serving the MUA that is the mailing list exploder send each copy to the next hop MTA by a separate SMTP transaction. The exploder MUA might do as it does now, sending messages to its MTA, each addressed to from 10, 100s, or perhaps 1000s of targets, but unlike now, the MUA would add to message BCC headers for each addressee in the batch. To honor the blindness required of a BCC (and the "Security Considerations" in RFC 2822), the MTA must convert those individual batch messages into sparate messages. Each new message would contain a single BCC header mentioning a single addressee, and would be handled in a separate SMTP transaction. Alternatively, the exploder MUA could generate the separate messages, each with a single BCC header. Have you watched an SMTP client responsible for passing a modest (few 1000 subscribers) or larger mailing list, particularly on hardware and networks more than 10 years old? Mailing list subscribers have always tended to be clustered on SMTP servers, even before big ISPs like AOL. Requiring separate transactions for each addressee would increase the load on the system by 10 times. I suspect that is why sendmail at least as early as the mid-1980s was willing to sort by next-hop and use a single SMTP transaction when possible. Vernon Schryver vjs@rhyolite.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 12:48:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21843 for ; Thu, 1 May 2003 12:48:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GsO412600 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:54:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GsO812597 for ; Thu, 1 May 2003 12:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21792; Thu, 1 May 2003 12:47:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHFt-0003p6-00; Thu, 01 May 2003 12:49:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BHFt-0003p2-00; Thu, 01 May 2003 12:49:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GqJ811801; Thu, 1 May 2003 12:52:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Gpe811684 for ; Thu, 1 May 2003 12:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21557 for ; Thu, 1 May 2003 12:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHDF-0003lf-00 for asrg@ietf.org; Thu, 01 May 2003 12:47:13 -0400 Received: from peacock.verisign.com ([65.205.251.73]) by ietf-mx with esmtp (Exim 4.12) id 19BHD9-0003lO-00 for asrg@ietf.org; Thu, 01 May 2003 12:47:07 -0400 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by peacock.verisign.com (8.12.9/) with ESMTP id h41GlK4q029666; Thu, 1 May 2003 09:47:20 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 09:14:41 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Vernon Schryver'" , "'asrg@ietf.org'" Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 May 2003 07:01:28 -0700 Actually I find it rather difficult to accept the terms 'design' and smtp in the same sentence without a negative inbetween. Interpretation of ietf docments of the era are at best an exercise in hermeneutics. I use the term advisedly since there is much that is not written that is as important as that which is. Do not ascribe to ignorance of others what may be due to your own lack of knowledge. In this environment that type of talk is far more insulting than anything else which may be said. Rfc822 is a deeply flawed document. It was written in an ra when we did not know better and it was writen in an era when rfc meant what it says. Rfcs began not as standards but as the starting point for standards. But even so it does not state that the to cc etc addresses mean other than what one would assume them to mean. My position is quite clear, he definitin of smtp is embedded in internet usage. I would no more expect to be able to know the smtp spec from the rfcs than I would expect to understand theology from reading the bible alone. -----Original Message----- From: Vernon Schryver Sent: Thu May 01 06:30:59 2003 To: asrg@ietf.org Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator > From: "Tom Thomson" > Phill's document already points out that mailing lists are an exception > which require exceptional treatment, so your "case in point" appears to be > vacuous padding to try to fool us into thinking your message has more > substance than it has. He did not say that mailing list software should be changed, but in effect said that all major past and current SMTP mailing list software violates words in RFC 822 that do not exist. In fact RFC 2822 not only does not require that recipients be listed, but allows an MTA to remove BCCs. He probably made the mistake common among end users who complain about spam not containing their addresses, because they do not know about or understand the significance of the SMTP envelope. If you have not spent much time fighting spam or SMTP servers in more than their external configuration spam, it is easy to not know about the SMTP envelope. > As for the bcc case, I used to use an MUA which generated n+1 copies of the > body - 1 for each bcc recipient containing a bcc line with only that > recipient, and one for all To and cc recipient containing no bcc line. These > were transmitted separately - multiple Rcpt To lines with one Data phase for > teh To and cc recipients, single Rcpt lines with a data phase for each bcc > recipient. Since Phill is as much of an antique as I am, maybe he too > remembers MUAs which did rather pleasant and intelligent things that didn't > conform to the modern desire for "efficiency" at all costs (even at the cost > of effectiveness) and maybe that's where theerrorneous statement comes from. > An easy mistake to make if you grew up with civilised MUAs. I still use an MUA whose first version probably predates the MUA that you are thinking of. It sends a single copy with the BCC recipients mentioned only in the envelope. The only older UNIX MUA that I've used of also sent only a single copy. (Email systems I used before UNIX were too different to mention.) The MUA that I recall that did as you describe was a fancy, "extensible," and "user friendly" package offered as a replacement for those two older MUAs. I've often wished that my preferred MUA would do as you describe, because I've learned the hard way the importance of preceding a BCC'ed message with another that says something like "the following is a BCC so don't reply to all." > >What discourages me most about this mailing list are self-described > >expert statements such as "the RFC822 message standard requires every > >message to have a valid To: CC: or BCC: field identifying the recipient, > >making adjustment where necessary to account for messages relayed > >through mailing lists." There are obvious reasons why RFC 822 and > >RFC 2822 do not require mailing list exploders to anything of the sort. > > Heavy protestations of knowledg and expertise which are clearly false bother > me too, but I also know the story about the pot and the kettle. Are you sure you see all of the relevant applications of the pot and kettle story? Do you see some of the obvious reasons why RFC 822, RFC 821, RFC 2822, and RFC 2821 do not contain the words that the other person thought they do? Did you check RFC 2822 on BCC headers? Requiring that every message list the recipient in a To, CC, or BCC header would require that the MTA serving the MUA that is the mailing list exploder send each copy to the next hop MTA by a separate SMTP transaction. The exploder MUA might do as it does now, sending messages to its MTA, each addressed to from 10, 100s, or perhaps 1000s of targets, but unlike now, the MUA would add to message BCC headers for each addressee in the batch. To honor the blindness required of a BCC (and the "Security Considerations" in RFC 2822), the MTA must convert those individual batch messages into sparate messages. Each new message would contain a single BCC header mentioning a single addressee, and would be handled in a separate SMTP transaction. Alternatively, the exploder MUA could generate the separate messages, each with a single BCC header. Have you watched an SMTP client responsible for passing a modest (few 1000 subscribers) or larger mailing list, particularly on hardware and networks more than 10 years old? Mailing list subscribers have always tended to be clustered on SMTP servers, even before big ISPs like AOL. Requiring separate transactions for each addressee would increase the load on the system by 10 times. I suspect that is why sendmail at least as early as the mid-1980s was willing to sort by next-hop and use a single SMTP transaction when possible. Vernon Schryver vjs@rhyolite.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From mailnull@www1.ietf.org Thu May 1 12:51:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21988 for ; Thu, 1 May 2003 12:51:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Gvas12995 for asrg-archive@odin.ietf.org; Thu, 1 May 2003 12:57:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Gva812992 for ; Thu, 1 May 2003 12:57:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21965; Thu, 1 May 2003 12:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHJ0-0003ro-00; Thu, 01 May 2003 12:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BHIz-0003rd-00; Thu, 01 May 2003 12:53:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Gt3812655; Thu, 1 May 2003 12:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GsR812615 for ; Thu, 1 May 2003 12:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21768 for ; Thu, 1 May 2003 12:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHFi-0003oi-00 for asrg@ietf.org; Thu, 01 May 2003 12:49:46 -0400 Received: from ocker.kanga.nu ([198.144.204.213] helo=dingo.home.kanga.nu) by ietf-mx with esmtp (Exim 4.12) id 19BHFc-0003nM-00 for asrg@ietf.org; Thu, 01 May 2003 12:49:40 -0400 Received: from localhost ([127.0.0.1] helo=kanga.nu) by dingo.home.kanga.nu with esmtp (Exim 3.35 #1 (Debian)) id 19BHFQ-0006oR-00; Thu, 01 May 2003 09:49:28 -0700 To: "Ken Hirsch" cc: asrg@ietf.org Subject: Re: [Asrg] Proposal for transition to authenticated email In-Reply-To: Message from "Ken Hirsch" of "Thu, 01 May 2003 04:22:24 EDT." <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> References: <013301c30dc8$df22dc90$b1ad86a2@hirschk1> <01bd01c30e0a$4cc9c7e0$0201a8c0@DXHIRX1> <02d401c30eaf$b5563fa0$0201a8c0@DXHIRX1> <03cb01c30ed8$0acae620$0201a8c0@DXHIRX1> <200305010156.h411uoQM008784@new.agentzero.com> <04ce01c30fbc$286a4fb0$0201a8c0@DXHIRX1> X-face: ?^_yw@fA`CEX&}--=*&XqXbF-oePvxaT4(kyt\nwM9]{]N!>b^K}-Mb9 YH%saz^>nq5usBlD"s{(.h'_w|U^3ldUq7wVZz$`u>MB(-4$f\a6Eu8.e=Pf\ X-image-url: http://www.kanga.nu/~claw/kanga.face.tiff X-url: http://www.kanga.nu/~claw/ Message-ID: <26190.1051807768@kanga.nu> From: J C Lawrence Sender: asrg-admin@ietf.org Errors-To: asrg-admin@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Anti-Spam Research Group - IRTF List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 May 2003 09:49:28 -0700 On Thu, 1 May 2003 04:22:24 -0400 Ken Hirsch wrote: > From: "Jim Youll" > I don't understand this objection. You can send to the ISP's SMTP > server at the same speed as you send to another SMTP server. For me the problems with using a smarthost are: a) I can't guarantee delivery performance or behaviour. b) I don't have transparency into the delivery process and so don't know how, when, or two whom any particular mail was delivered. I spend considerable time and effort on building fast mail systems and would rather not throw that away on a smarthost of dubious provenance, most especially when there is little motivation or interest on the ISP's job to do a particularly good job there. Further, it helps me offer a superlative service when I have full delivery and log transparency. I somewhat regularly get contacted by third parties with, "Why am I not getting my mail?", and the fact that I can reply in single digit minutes with, "I delivered your mail to your MX at
at