From list-managers-owner Sat Aug 1 03:27:03 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id DAA21871; Sat, 1 Aug 1998 03:12:17 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id DAA21864 for ; Sat, 1 Aug 1998 03:11:59 -0700 (PDT) Received: from quill (norbert@gate3-25.cyberlink.ch [195.246.74.95]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id MAA30012; Sat, 1 Aug 1998 12:18:06 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id NAA00294; Sat, 1 Aug 1998 13:12:11 +0200 Date: Sat, 1 Aug 1998 13:12:11 +0200 Message-Id: <199808011112.NAA00294@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: list-managers@GreatCircle.COM CC: ERIC@VM.SE.LSOFT.COM In-reply-to: <199808010519.WAA11795@web.webcoach.com> (RAF@CU.NIH.GOV) Subject: Re: Listserv's violation of RFC821 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I wrote: > > b) Such a "probe failed" message MUST NOT be sent with MAIL FROM:<> > > In fact, RFC821 is very clear that e-mail messages are supposed to > > have a good reverse-path > > [..] > > and later the exception of bounces is introduced with the words Roger Fajman writes: > RFC 821 isn't the whole story on this issue. Other RFCs have introduced > the principle that some messages may be sent with a null MAIL FROM. Ok, but still there is no RFC which would allow any software product to start sending arbitrary kinds of error messages with a null envelope sender. > RFC 1894 states that Delivery Status Notifications (DSNs) are to be sent > with a null MAIL FROM address. While a DSN may be a bounce message, it > may also be a report of successful delivery. RFC 2298 states that > Message Disposition Notifications (MDNs) are also to be sent with a > null MAIL FROM address. Ok, you are right that both DSNs and MDNs are further exceptions to the general rule that e-mail messages are supposed to have a valid, non-null reverse path. > Also note the following text in RFC 821: > > MAIL (MAIL) > > ... In some types of error > reporting messages (for example, undeliverable mail > notifications) the reverse-path may be null (see Example 7). > > This suggests that there could be messages other than bounces that > have a null MAIL FROM. Sure. This leaves room for later RFCs to introduce other kinds of error messages which can also be sent with a null reverse-path. But note the wording "In _some_ types of error reporting messages (...) the reverse-path may be null". This does not give any arbitrary software package the right to invent new types of error reporting messages and send them with null reverse path without having the new type of error reporting message properly reviewed and specified in an RFC so that people who develop spam filters (like e.g. Ron) and those who develop bounce-handlers (like e.g. me) and also developers of others kinds of software that might be affected by this are properly warned and enabled to make their software react properly to the new types of messages. So far, the only situation when an entity A can legally send something with null return path to another entity B is when A needs to make some kind of status report about an e-mail message (with non-null return path) which was sent by B. -- NB. From list-managers-owner Sat Aug 1 10:42:06 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA28110; Sat, 1 Aug 1998 10:36:11 -0700 (PDT) Received: from CU.NIH.GOV (cu.nih.gov [128.231.160.111]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id KAA28103 for ; Sat, 1 Aug 1998 10:36:03 -0700 (PDT) Message-Id: <199808011736.KAA28103@honor.greatcircle.com> To: nb@thinkcoach.com, list-managers@GreatCircle.COM cc: ERIC@VM.SE.LSOFT.COM From: "Roger Fajman" Date: Sat, 1 Aug 1998 13:37:44 -0400 (EDT) Subject: Re: Listserv's violation of RFC821 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > Ok, you are right that both DSNs and MDNs are further exceptions to the > general rule that e-mail messages are supposed to have a valid, non-null > reverse path. > > > Also note the following text in RFC 821: > > > > MAIL (MAIL) > > > > ... In some types of error > > reporting messages (for example, undeliverable mail > > notifications) the reverse-path may be null (see Example 7). > > > > This suggests that there could be messages other than bounces that > > have a null MAIL FROM. > > Sure. This leaves room for later RFCs to introduce other kinds of error > messages which can also be sent with a null reverse-path. > > But note the wording "In _some_ types of error reporting messages (...) > the reverse-path may be null". This does not give any arbitrary software > package the right to invent new types of error reporting messages and > send them with null reverse path without having the new type of error > reporting message properly reviewed and specified in an RFC so that > people who develop spam filters (like e.g. Ron) and those who develop > bounce-handlers (like e.g. me) and also developers of others kinds of > software that might be affected by this are properly warned and enabled > to make their software react properly to the new types of messages. > > So far, the only situation when an entity A can legally send something > with null return path to another entity B is when A needs to make some > kind of status report about an e-mail message (with non-null return > path) which was sent by B. > > -- NB. That is debatable, I think. There is no wording in RFC 821 that says that only types of messages authorized by a standards-track RFC may use a null MAIL FROM. When RFC 821 was written, spam did not exist, so the issue wasn't considered. But even the draft revision to RFC 821 does not take a firm position on this issue. See the document at http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-07.txt The mailing list for the working group is drums@cs.utk.edu. To be added, write to drums-request@cs.utk.edu. But the working group is trying to get both this document and the RFC 822 revision out the door, so it may well not want to consider this issue at this late date. From list-managers-owner Sat Aug 1 19:26:11 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA03428; Sat, 1 Aug 1998 19:10:53 -0700 (PDT) Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA03421 for ; Sat, 1 Aug 1998 19:10:47 -0700 (PDT) Received: from micron (pool-207-205-187-4.clev.grid.net [207.205.187.4]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id WAA29996 for ; Sat, 1 Aug 1998 22:16:53 -0400 (EDT) Message-ID: <199808012214410910.0038D6F5@mail.mindspring.com> X-Mailer: Calypso Version 2.40.41.05 Date: Sat, 01 Aug 1998 22:14:41 -0400 From: "ron40xc" To: list-managers@GreatCircle.COM Subject: ownership change? Sender: list-managers-owner@GreatCircle.COM Precedence: bulk how do we change ownership with a majordomo list? From list-managers-owner Sat Aug 1 19:40:38 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA03664; Sat, 1 Aug 1998 19:35:48 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA03657 for ; Sat, 1 Aug 1998 19:35:40 -0700 (PDT) Received: from Venus.mcs.net (dattier@Venus.mcs.net [192.160.127.92]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id VAA07576 for ; Sat, 1 Aug 1998 21:42:04 -0500 (CDT) Received: (from dattier@localhost) by Venus.mcs.net (8.8.7/8.8.2) id VAA18819 for list-managers@greatcircle.com; Sat, 1 Aug 1998 21:42:02 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199808020242.VAA18819@Venus.mcs.net> Subject: Re: individualized probe messages To: list-managers@greatcircle.com Date: Sat, 1 Aug 1998 21:42:01 -0500 (CDT) In-Reply-To: <000101bdbc98$d33c7ed0$017b7b0a@gillette> from "Tom Neff" at Jul 31, 98 11:35:20 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk When I wrote [about getting a bounce for an address that is not on to the list because a member must be forwarding it there], | > Probe messages work only if the refusing site sends you back the text, or | > sends you back your outgoing subject, or at least returns something that | > distinguishes one probe message from the others. Prodigy tells you only | > that such-and-such a user ID is not valid: no text, no Received: headers | > for the trip from your site to Prodigy, no trace of your Subject:, | > nothing... Tom Neff replied, | Actually there is a way around this problem if you have forwarding/alias | control at a site, i.e., you can configure your local mail transfer agent | (MTA) so that many addresses all deliver to you. Operative word: "if". Write it, as Lulu sang, across the sky with letters that would sore a thousand feet high. If you don't control the domain's addressing -- if you are a user on someone else's machine or a customer of an ISP whose MTA doesn't do VERPs or even suffixing -- then Tom's idea is something to dream, not to do. | Instead of (or in addition to) serializing the Subject header in each probe | message, you also serialize the From: and Errors-To: headers as follows: | | From: test01347@mybox.mydomain.com | Errors-To: errs01347@mybox.mydomain.com | Subject: List Test #001347 | | This is a list test message - please ignore it. Most MTAs ignore Errors-To:, but if you have control over the domain and can give yourself as many addresses in it as you like, you can use them as envelope senders; in other words, you're simulating qmail's VERPs, as I said before and as Dave Sill just mentioned. | Now even the most uncooperative Prodigy-class mail agent can't help revealing | which message it's bouncing, because each one will be delivered to a unique | "userid." Even if they omit a To: header in the bounce, you can examine the | Received: headers for the delivery address your local MTA saw. They do omit the To: header, but either their MTA or Smail on WWA was filling it into Apparently-To: as well as Received: ... for. By using my own logname and the list's aliases as envelope senders, I eventually tracked down the culprit. Skip the indented part and go to my next quote from Mr. Neff if you've read my previous posts of this story: Based on the timing of the bounces, I knew that the forwarder was a digest- mode subscriber who was not on the list's sublist. That left 1220 suspects. With seven envelope sender addresses at my disposal, I divided the 1220 into seven groups of 174 or 175 and sent out seven first-round probes, one to each group. About ten minutes later one of them bounced. The addressee of the NDN was all I had to go by, but it narrowed the field to 175 addresses. Some sub- scribers replied to probe #1 to assure me they received it, and I answered thanks, but they didn't have to. I divided them into seven groups of twenty-five and repeated the process, assuring recipients in the text that still being there in the second round didn't mean they were more suspect, just that they were less lucky. One second-round probe bounced, narrowing it to twenty-five people. I divided them into seven groups of three or four and sent the third round of seven probes. One bounced, and there were three people left. In the fourth round I wrote to them individually with three different envelope senders, and one bounced. Officer, arrest that woman! I booted her from the list. If only the NDNs from Prodigy had included the To: or Subject: or Received: or even Message-Id: of the undelivered piece (I could have blind carboned all probes to myself and had a list of which Message-Id: was on whose, or I could have encoded the addressee into the Message-Id:) it would have been completely unncessary. OK, so I'd still have had to send 1220 probes, but not 1220+175+24+3=1422. And I'd have had the answer far sooner and not had to spend all that extra time on line when I had other things to get done. | This is particularly easy to do with today's "virtual servers" that forward | anything@yourdomain.com to the same address. Not everyone has a personal domain, and I have no intention to shell out the costs of having one (not only for the registration but also for the MX ser- vice from an ISP) when I have no need for it except to cope with Prodigy's poor netizenship. From list-managers-owner Sat Aug 1 20:40:37 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA04139; Sat, 1 Aug 1998 20:25:01 -0700 (PDT) Received: from queernet.queernet.org (queernet.queernet.org [140.174.78.69]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA04121 for ; Sat, 1 Aug 1998 20:24:53 -0700 (PDT) Received: from localhost (rogerk@localhost) by queernet.queernet.org (8.8.5/8.8.5) with SMTP id UAA26699 Date: Sat, 1 Aug 1998 20:31:13 -0700 (PDT) From: "Roger B.A. Klorese" To: ron40xc cc: list-managers@GreatCircle.COM Subject: Re: ownership change? In-Reply-To: <199808012214410910.0038D6F5@mail.mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Sat, 1 Aug 1998, ron40xc wrote: > how do we change ownership with a majordomo list? With the normal setup, where it is hard-wired into the system's mail aliases, you ask your Majordomo-Owner to do so. If eithr of the following optional extended setups is in use, you can do it yourself: - if the site is running MajorCool, you can change the owner field there. - if the site is using a separate unpublished mailing list as the list of owners, subscribe the new one and unsubscribe the old one. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG urgent: rogerk-page@QueerNet.ORG 2215-R Market Street #576 San Francisco, CA 94114 +1 415 ALL-ARFF "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From list-managers-owner Sun Aug 2 01:32:03 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA07916; Sun, 2 Aug 1998 00:48:46 -0700 (PDT) Received: from eagle.ns.net (eagle.ns.net [204.75.146.20]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id AAA07909 for ; Sun, 2 Aug 1998 00:48:39 -0700 (PDT) Received: from monkeys.com (rfg.ns.net [207.159.10.82]) by eagle.ns.net (8.8.5/8.8.5) with ESMTP id AAA13650 for ; Sun, 2 Aug 1998 00:55:02 -0700 (PDT) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.8.8/8.8.5) with ESMTP id AAA06491 for ; Sun, 2 Aug 1998 00:57:05 -0700 To: list-managers@GreatCircle.COM Subject: Re: Listserv's violation of RFC821 In-reply-to: Your message of Sat, 01 Aug 1998 01:17:07 -0400. <199808010513.WAA17158@honor.greatcircle.com> From: "Ronald F. Guilmette" Date: Sun, 02 Aug 1998 00:57:05 -0700 Message-ID: <6489.902044625@monkeys.com> X-Processed-By: Deadbolt(tm) Personal E-Mail Filter, Version 0.90 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk In message <199808010513.WAA17158@honor.greatcircle.com>, "Roger Fajman" wrote: >This suggests that there could be messages other than bounces that >have a null MAIL FROM. > >LISTSERV's "probe failed" message sounds to me like an "error >reporting message". You are obviously using a VERY loose definition of the term. If I decide to write a letter (or have some automated bot do it for me) to some sysadmins somewhere, telling him that he's a bonehead for con- tinuing to run an open mail relay, is that an ``error reporting message'' also?? Well... you could call it that. Where do you draw the line? I believe that the only sensible place to draw it is to say that the term ``error reporting messages'' (in the context of the relevant SMTP RFCs) refers to error reporting messages having to do with (and/or generated by) the SMTP mail transport system itself, not by mere clients thereof. Other- wise, these ``error reporting messages'' become fair game, and _everybody_ can start calling _their_ messages ``error reporting messages''. (``You're a dork, and you ice isn't cold enough!'' There! Now _that's_ an error message! :-) Or how about ``Your request to Majordodo failed because it was unintelligible and unparsable.''? Or how about ``This is the vacation program. Joe will read your mail when he gets back from the Bahamas in two weeks. Until then, live in envy.''?) I am merely a client of the SMTP mail transport system. So are _all_ of the various mailing list packages, including Listserv. I don't screw around and go out of my way to make my messages look like bounces (even though doing so might appear to be convenient for me in some special cases... just as it appears to be for some spammers) and I don't believe that Listserv should be crossing this line either. Again, Listserv isn't a part of the SMTP transport system, it is a mere client of that system, as am I. -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc. -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/ -- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/ From list-managers-owner Sun Aug 2 02:59:27 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id CAA09911; Sun, 2 Aug 1998 02:43:01 -0700 (PDT) Received: from queernet.queernet.org (queernet.queernet.org [140.174.78.69]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id CAA09904 for ; Sun, 2 Aug 1998 02:42:54 -0700 (PDT) Received: from localhost (rogerk@localhost) by queernet.queernet.org (8.8.5/8.8.5) with SMTP id CAA03607 Date: Sun, 2 Aug 1998 02:47:56 -0700 (PDT) From: "Roger B.A. Klorese" To: "Ronald F. Guilmette" cc: list-managers@greatcircle.com Subject: Re: Listserv's violation of RFC821 In-Reply-To: <6489.902044625@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Sun, 2 Aug 1998, Ronald F. Guilmette wrote: > Again, Listserv isn't > a part of the SMTP transport system, it is a mere client of that system, > as am I. Really? If it connects to an SMTP server directly and has an SMTP session with it, how is it any less "a part of the SMTP transport system" than the sendmail invocation that's called by Majordomo? -- ROGER B.A. KLORESE rogerk@QueerNet.ORG urgent: rogerk-page@QueerNet.ORG 2215-R Market Street #576 San Francisco, CA 94114 +1 415 ALL-ARFF "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From list-managers-owner Sun Aug 2 08:01:49 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14604; Sun, 2 Aug 1998 07:40:05 -0700 (PDT) Received: from ifolk.iserver.net (ifolk.iserver.net [192.41.44.203]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA14592 for ; Sun, 2 Aug 1998 07:39:53 -0700 (PDT) Received: from newmicronpc (slip-32-100-103-114.ct.us.ibm.net [32.100.103.114]) by ifolk.iserver.net (8.8.5) id IAA10643; Sun, 2 Aug 1998 08:46:15 -0600 (MDT) From: "Tom Neff" To: Subject: Re: individualized probe messages Date: Sun, 2 Aug 1998 10:55:15 -0400 Message-ID: <000001bdbe25$8edc1fa0$72676420@newmicronpc> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199808020800.BAA08091@honor.greatcircle.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I appreciate the info on David Tamkin's personal access level, budget, plans and so forth, but the serialized-From technique has potential value to those listmanagers who, through whatever quirk of fate, do have a machine (if only a Linux box) whose mail they can configure, or who have access to a virtual domain (their own or a friend's). List-Managers is for the benefit of all members, not a private chatline, so I hope others get a chance to use the trick. I should emphasize (if it's not already obvious) that the From: addresses, machine and domain you use for the serialized probe need have nothing to do with the machine or domain that the mailing list itself emanates from. So you don't have to have full mail control over that (possibly commercial or centrally managed) host. Just your own little node, real or virtual. > From: "David W. Tamkin" > Operative word: "if". Write it, as Lulu sang, across the sky with letters > that would sore a thousand feet high. ... We all have our soar points... From list-managers-owner Sun Aug 2 10:01:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA15602; Sun, 2 Aug 1998 09:45:19 -0700 (PDT) Received: from eagle.ns.net (eagle.ns.net [204.75.146.20]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA15593 for ; Sun, 2 Aug 1998 09:45:06 -0700 (PDT) Received: from monkeys.com (rfg.ns.net [207.159.10.82]) by eagle.ns.net (8.8.5/8.8.5) with ESMTP id JAA26904 for ; Sun, 2 Aug 1998 09:51:26 -0700 (PDT) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.8.8/8.8.5) with ESMTP id JAA21563 for ; Sun, 2 Aug 1998 09:54:07 -0700 To: list-managers@greatcircle.com Subject: Re: Listserv's violation of RFC821 In-reply-to: Your message of Sun, 02 Aug 1998 02:47:56 -0700. From: "Ronald F. Guilmette" Date: Sun, 02 Aug 1998 09:54:07 -0700 Message-ID: <21561.902076847@monkeys.com> X-Processed-By: Deadbolt(tm) Personal E-Mail Filter, Version 0.90 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk In message , "Roger B.A. Klorese" wrote: >On Sun, 2 Aug 1998, Ronald F. Guilmette wrote: >> Again, Listserv isn't >> a part of the SMTP transport system, it is a mere client of that system, >> as am I. > >Really? If it connects to an SMTP server directly and has an SMTP >session with it, how is it any less "a part of the SMTP transport system" >than the sendmail invocation that's called by Majordomo? Does it do MX resolution? Does it cycle through the MXes, trying various ones until it finds a live one? Does it do queuing? Does it do retries? Does it connect to *non-local* SMTP servers? If the answers to all of the above are ``yes'', then heck! Let's just throw away our MTAs and use Listserv instead, because the MTAs are ob- viously just redundant excess baggage. -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc. -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/ -- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/ From list-managers-owner Sun Aug 2 13:00:40 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA17281; Sun, 2 Aug 1998 12:48:37 -0700 (PDT) Received: from dt053nd2.san.rr.com (dt053nd2.san.rr.com [204.210.34.210]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id MAA17274 for ; Sun, 2 Aug 1998 12:48:31 -0700 (PDT) Received: from dal.net (Studded@localhost [127.0.0.1]) by dt053nd2.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA04230; Sun, 2 Aug 1998 12:54:49 -0700 (PDT) (envelope-from Studded@dal.net) Message-ID: <35C4C409.AEB8ECED@dal.net> Date: Sun, 02 Aug 1998 12:54:49 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0507 i386) MIME-Version: 1.0 To: "Vince Sabio, Alpha Listmom" CC: list-managers@GreatCircle.COM Subject: "Reviewing" mailing list? (Was: Re: Lyris) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Vince Sabio, Alpha Listmom wrote: > (3) inform me whenever someone attempts > to REVIEW any of my mailing lists (I have my lists configured to > disallow such things, but I still like to know when they try), You made the above statement in reference to praise of lyris. I am not familiar with the phrase "review a mailing list" and I was wondering if you could expand on what that means, how it is detected and why it is undesirable. Thanks for any help, Doug From list-managers-owner Sun Aug 2 13:15:46 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA17431; Sun, 2 Aug 1998 13:04:33 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA17424 for ; Sun, 2 Aug 1998 13:04:27 -0700 (PDT) Received: from Mercury.mcs.net (dattier@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id PAA28045 for ; Sun, 2 Aug 1998 15:10:57 -0500 (CDT) Received: (from dattier@localhost) by Mercury.mcs.net (8.8.7/8.8.2) id PAA29678 for list-managers@greatcircle.com; Sun, 2 Aug 1998 15:10:57 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199808022010.PAA29678@Mercury.mcs.net> Subject: Re: individualized probe messages To: list-managers@greatcircle.com Date: Sun, 2 Aug 1998 15:10:56 -0500 (CDT) In-Reply-To: <000001bdbe25$8edc1fa0$72676420@newmicronpc> from "Tom Neff" at Aug 2, 98 10:55:15 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Background: I posted about a problem I had had to deal with without the facilities that many of you have at your disposal. Tom Neff then posted a follow-up that offered a solution I could not have used. When I responded that yes, others can do that, but I had to settle for a less efficient ap- proach, he rejoined, | ... the serialized-From technique has potential value to [many] | listmanagers ... Yes, no question. It has potential value to all who can use it. It certainly beats the heck out of what I had to do. | List-Managers is for the benefit of all members, not | a private chatline, so I hope others get a chance to use the trick. I hope so too, but by the same token that "all members" includes those whose situations are unlike mine, it also includes those whose situations are like mine. | I should emphasize (if it's not already obvious) that the From: addresses, | machine and domain you use for the serialized probe need have nothing to do | with the machine or domain that the mailing list itself emanates from. Yes, the From: address and the From_ address can differ from the true send- ing point and from one another. It was the From_ address that mattered that time, and that is not as easy to set for a non-admin as the From: address. While at the time I knew how to rig the local part of the From_ address, I did not yet know a reliable way to point From_ to a remote address (I do now). Had I known, there would have been nine available return addresses instead of seven and not 1422 probe letters but at most 1374. (The other providers where I had email addresses don't support plus-suffixing either.) | So you don't have to have full mail control over that (possibly commercial | or centrally managed) host. Just your own little node, real or virtual. But you do need to come up with as many distinct addresses as there are subscribers to whom you need to send the probe message, and they have to be such that mail to them will reach you. If you have your own domain, whether real or virtual, you can do that. If you have suffixed addressing available, you can do that. If you have neither available but you run a mailing list anyway, you still have a right to be on list-managers. | > Operative word: "if". Write it, as Lulu sang, across the sky with letters | > that would sore a thousand feet high. ... | | We all have our soar points... Oops ... sorry for the typo, and clever way to point it out, Mr. Neff. From list-managers-owner Sun Aug 2 15:59:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA18848; Sun, 2 Aug 1998 15:41:14 -0700 (PDT) Received: from nisto.com (nisto.com [207.34.64.161]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA18841 for ; Sun, 2 Aug 1998 15:41:02 -0700 (PDT) Received: from [207.34.64.181] by nisto.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 2 Aug 1998 16:51:58 -0600 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 2 Aug 1998 16:51:32 -0600 To: list-header@list.nisto.com, list-managers@GreatCircle.COM, ListMom-Talk@lists.SKYLIST.net From: Grant Neufeld Subject: List-Probe field proposal Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Here are the relevant parts from a new internet-draft I'm preparing. The working form of the document itself can be found at http://www.nisto.com/listspec/#DOCUMENTS Please address all follow up to the list-header mailing list , or to me privately. Thanks. The List-Probe Message Header Field for Identifying Mail List Probe Messages Abstract This document defines the message header field "List-Probe" to be used in consistently identifying mail list probe messages. 1. Introduction Many MTAs (mail transfer agents - mail servers) in use today do not provide adequate details when failing to transfer mail messages. In particular, when email is automatically forwarded from a recipient address to a second address that is 'bouncing' incoming mail, the error response messages may not properly including the original (forwarding) recipient address. To help deal with this problem, many mailing list managers have taken to sending out individualized "probe" messages. The probes include enough identifying information - even if the original recipient address is not included in the error response - that the forwarding address can be properly identified. The drawback to this approach is that valid recipients will receive the probe messages in their mail - an unfortunate waste of time and resources. This document defines a message header field, List-Probe, which will allow MUAs (mail user agents - email clients) to identify and automatically discard probe messages so the user does not have to be involved in the process. If a probe message is received by a MUA, the recipient address is valid, so the probe does not need to be responded to (and can safely be discarded) since probes are only seeking error responses. 2. The List-Probe Header Field The List-Probe message header field MUST contain a single RFC822 format recipient address. The field MAY also contain round-bracket enclosed comments. For example, a probe message for the address user@some.host might look like: List-Probe: user@some.host To: user@some.host From: admin@server.host Errors-To: probe@server.host Subject: Probe message - Please ignore We are checking for invalid email addresses. Since you have received this message, your email is valid. Please discard this message - DO NOT REPLY. Our appologies for the interruption. 3. Security Considerations Since the originating system is responsible for introducing the List-Probe field into the message, with the expectation that valid recipients will discard the message, it is expected that no unwanted message discarding will occur. There is a danger that senders of unwanted bulk email could make use of the List-Probe field in validating recipient addresses. To provide users with the option to avoid this, MTAs MUST provide an option to ignore the List-Probe field (not deleting the messages), allowing the user to see the probe messages. In the case of ignoring the List-Probe field, the MTA MAY hilite the message in some manner to alert the user that it is a probe message. Mail list processors SHOULD NOT allow user-originated List-Probe fields to pass through to their lists, lest they confuse the user and have the potential to create security problems. -- http://www.nisto.com/ O- <*> MIME PGP: http://www.nisto.com/grant/pgpkey.kagi.txt 838B 977B 080E 1B61 BA78 D159 6ABB 8CBA A825 0CDF From list-managers-owner Sun Aug 2 16:29:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA19112; Sun, 2 Aug 1998 16:12:05 -0700 (PDT) Received: from nisto.com (nisto.com [207.34.64.161]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA19105 for ; Sun, 2 Aug 1998 16:11:53 -0700 (PDT) Received: from [207.34.64.181] by nisto.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 2 Aug 1998 17:23:08 -0600 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 2 Aug 1998 17:22:43 -0600 To: list-managers@GreatCircle.COM From: Grant Neufeld Subject: The List- headers are now an RFC Sender: list-managers-owner@GreatCircle.COM Precedence: bulk This is a request for you to implement support for the List- header fields defined in RFC2369. This will make mail list access easier for your users. The List- fields provide you with a standard method by which you can consistently describe your mailing lists' command syntax so that client applications can implement an interface to make list access easier for users. As they are adopted and supported by email software developers, the List header fields will make it easier for users to interact with email lists. The currently defined fields are List-Subscribe, List-Unsubscribe, List-Help, List-Post, List-Owner and List-Archive. They describe commands for subscribing, unsubscribing, retrieving help information, posting to the list, contacting a human administrator and accessing message archives. As an example, for the list-managers list, the fields could be something like: List-Subscribe: List-Unsubscribe: List-Help: List-Post: List-Owner: List-Archive: , , Implementation guidelines for list managers and administrators are available at: Extended details on the List header fields are available from: A mailing list for discussion is available at: or Information on the format of mailto URLs: Thanks! -- http://www.nisto.com/ O- <*> MIME PGP: http://www.nisto.com/grant/pgpkey.kagi.txt 838B 977B 080E 1B61 BA78 D159 6ABB 8CBA A825 0CDF From list-managers-owner Sun Aug 2 17:44:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA19631; Sun, 2 Aug 1998 17:33:43 -0700 (PDT) Received: from dt053nd2.san.rr.com (dt053nd2.san.rr.com [204.210.34.210]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA19624 for ; Sun, 2 Aug 1998 17:33:35 -0700 (PDT) Received: from dal.net (Studded@localhost [127.0.0.1]) by dt053nd2.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA05452 for ; Sun, 2 Aug 1998 17:40:08 -0700 (PDT) (envelope-from Studded@dal.net) Message-ID: <35C506E8.4405AB9D@dal.net> Date: Sun, 02 Aug 1998 17:40:08 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0507 i386) MIME-Version: 1.0 To: list-managers@GreatCircle.COM Subject: Re: "Reviewing" mailing list? (Was: Re: Lyris) References: <35C4C409.AEB8ECED@dal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Studded wrote: > > Vince Sabio, Alpha Listmom wrote: > > > (3) inform me whenever someone attempts > > to REVIEW any of my mailing lists (I have my lists configured to > > disallow such things, but I still like to know when they try), > > You made the above statement in reference to praise of lyris. I am not > familiar with the phrase "review a mailing list" and I was wondering if > you could expand on what that means, how it is detected and why it is > undesirable. I got some answers to this already, thanks. The listserv (and others?) 'review' command does what 'who' does on majordomo. Doug From list-managers-owner Sun Aug 2 18:59:44 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA20194; Sun, 2 Aug 1998 18:39:47 -0700 (PDT) Received: from quilla.tezcat.com (quilla.tezcat.com [204.128.247.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA20187 for ; Sun, 2 Aug 1998 18:39:39 -0700 (PDT) Received: from [208.145.52.97] (adamb.tezcat.com [208.145.52.97]) by quilla.tezcat.com (8.8.5/8.8.5/tezcat-96091001) with SMTP id UAA14356 for ; Sun, 2 Aug 1998 20:46:12 -0500 (CDT) Message-Id: <199808030146.UAA14356@quilla.tezcat.com> Subject: Re: "Reviewing" mailing list? (Was: Re: Lyris) Date: Sun, 2 Aug 1998 20:47:08 -0500 x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Adam Bailey cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On 8/2/98 2:54 PM, Studded wrote... >Vince Sabio, Alpha Listmom wrote: > >> (3) inform me whenever someone attempts >> to REVIEW any of my mailing lists (I have my lists configured to >> disallow such things, but I still like to know when they try), > > You made the above statement in reference to praise of lyris. I am not >familiar with the phrase "review a mailing list" and I was wondering if >you could expand on what that means, how it is detected and why it is >undesirable. The REVIEW command/procedure, in some packages, produces a list of all the subscribers to a list. Back in The Good Old Days(tm) when the net was a reasonably safe place to be, anyone (or, at least, any subscriber) could find out who else was on the list, so they'd know who all they were talking to (individual subscribers would still have the ability to hide just their subscription). But with the rise of UBE and other forms of mass email abuse, most lists are now closed to any form of REVIEW (as well they should be). -- Adam Bailey | Chicago, Illinois adamb@tezcat.com | "Logic is the art of going wrong with adamkb@aol.com | confidence." - George Bernard Shaw Finger for PGP | http://www.tezcat.com/~adamb/ From list-managers-owner Sun Aug 2 19:55:36 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA20796; Sun, 2 Aug 1998 19:44:09 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA20789 for ; Sun, 2 Aug 1998 19:44:02 -0700 (PDT) Received: from Venus.mcs.net (dattier@Venus.mcs.net [192.160.127.92]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id VAA06317; Sun, 2 Aug 1998 21:50:35 -0500 (CDT) Received: (from dattier@localhost) by Venus.mcs.net (8.8.7/8.8.2) id VAA02722; Sun, 2 Aug 1998 21:50:35 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199808030250.VAA02722@Venus.mcs.net> Subject: Re: "Reviewing" mailing list? (Was: Re: Lyris) To: Studded@dal.net (Studded) Date: Sun, 2 Aug 1998 21:50:34 -0500 (CDT) Cc: list-managers@greatcircle.com In-Reply-To: <35C4C409.AEB8ECED@dal.net> from "Studded" at Aug 2, 98 12:54:49 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Doug asked, | Vince Sabio, Alpha Listmom wrote: | | > (3) inform me whenever someone attempts | > to REVIEW any of my mailing lists (I have my lists configured to | > disallow such things, but I still like to know when they try), | | You made the above statement in reference to praise of lyris. I am not | familiar with the phrase "review a mailing list" and I was wondering if | you could expand on what that means, how it is detected and why it is | undesirable. The word "review" has different meanings for different list packages. Vince appears to be referring to it as a command sent to certain listservers to request a copy of the membership roster. There was a time when few lists needed to disable that command; now many do, because of the spam problem, and the rest have to allow only members or privileged members to use it. In other software the word is used differently: a member of an unmoderated list is said to be on "review status" if his or her submissions are diverted for moderation rather than being sent right out, either because he or she is new to the list or because he or she has violated posting guidelines in the past. The ambiguities can be funny sometimes: once a member sent the following com- mand to me (at an address that reaches my eyes and does not interpret com- mands, but if I know what they mean I carry them out), apostrophes and all: request '*out*' Thinking it was a request to get out, but not being positive, I shut her subscription off without purging it and wrote to her to ask for clarifica- tion. She said no, she didn't want to unsub; she was trying to get a copy of the membership roster. I turned her subscription back on, sent her the list activity she had missed, and explained that I don't give the list out. About two years later another member sent this: request *out* with the same words and the same asterisks but no apostrophes. So as before, I shut her subscription off without purging it and asked her to elucidate, telling her about the previous incident. She replied that no, she wasn't trying to get the membership roster, she wanted to unsubscribe. So I thanked her for getting back to me and purged her subscription. From list-managers-owner Sun Aug 2 20:55:36 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA21516; Sun, 2 Aug 1998 20:50:58 -0700 (PDT) Received: from CU.NIH.GOV (silkt.nih.gov [128.231.160.112]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id UAA21509 for ; Sun, 2 Aug 1998 20:50:48 -0700 (PDT) Message-Id: <199808030350.UAA21509@honor.greatcircle.com> To: list-managers@GreatCircle.COM From: "Roger Fajman" Date: Sun, 2 Aug 1998 23:54:58 -0400 (EDT) Subject: Re: Listserv's violation of RFC821 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > In message <199808010513.WAA17158@honor.greatcircle.com>, > "Roger Fajman" wrote: > > >This suggests that there could be messages other than bounces that > >have a null MAIL FROM. > > > >LISTSERV's "probe failed" message sounds to me like an "error > >reporting message". > > You are obviously using a VERY loose definition of the term. > > If I decide to write a letter (or have some automated bot do it for me) > to some sysadmins somewhere, telling him that he's a bonehead for con- > tinuing to run an open mail relay, is that an ``error reporting message'' > also?? Well... you could call it that. > > Where do you draw the line? > > I believe that the only sensible place to draw it is to say that the term > ``error reporting messages'' (in the context of the relevant SMTP RFCs) > refers to error reporting messages having to do with (and/or generated by) > the SMTP mail transport system itself, not by mere clients thereof. Other- > wise, these ``error reporting messages'' become fair game, and _everybody_ > can start calling _their_ messages ``error reporting messages''. (``You're > a dork, and you ice isn't cold enough!'' There! Now _that's_ an error > message! :-) Or how about ``Your request to Majordodo failed because it > was unintelligible and unparsable.''? Or how about ``This is the vacation > program. Joe will read your mail when he gets back from the Bahamas in > two weeks. Until then, live in envy.''?) > > I am merely a client of the SMTP mail transport system. So are _all_ of > the various mailing list packages, including Listserv. I don't screw > around and go out of my way to make my messages look like bounces (even > though doing so might appear to be convenient for me in some special > cases... just as it appears to be for some spammers) and I don't believe > that Listserv should be crossing this line either. Again, Listserv isn't > a part of the SMTP transport system, it is a mere client of that system, > as am I. > > > -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc. > -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/ > -- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/ I believe that the original motivation for the presence of the null MAIL FROM in RFC 821 is the prevention of loops. That's why RFC 821 says that error messages should use it, why DSNs use it, and why MDNs use it. It doesn't matter what's generating the message. MDNs are generated by user agents, not SMTP servers. By your definition, they would not be allowed to use a null MAIL FROM. Now LISTSERV's probe failed message is not likely to cause a loop if it did not have a null MAIL FROM, but only because LISTSERV has other measures to keep that from happening. There are other cases when a list server might need to use a null MAIL FROM. For example, suppose that it forwards copies of error messages received as a result of messages sent from the command processing address to the list server maintainers. Such messages might cause a loop if they bounce and the MAIL FROM is not null. My main point is that there are things other than bounce messages that are specified by Internet standards track documents to use a null MAIL FROM. They can't be considered to be spam. From list-managers-owner Sun Aug 2 21:10:37 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA21752; Sun, 2 Aug 1998 21:08:03 -0700 (PDT) Received: from eagle.ns.net (eagle.ns.net [204.75.146.20]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA21745 for ; Sun, 2 Aug 1998 21:07:57 -0700 (PDT) Received: from monkeys.com (rfg.ns.net [207.159.10.82]) by eagle.ns.net (8.8.5/8.8.5) with ESMTP id VAA23115; Sun, 2 Aug 1998 21:14:26 -0700 (PDT) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.8.8/8.8.5) with ESMTP id VAA10273; Sun, 2 Aug 1998 21:17:14 -0700 To: list-header@peyak.nisto.com, list-managers@GreatCircle.COM, ListMom-Talk@lists.SKYLIST.net Subject: Re: List-Probe field proposal In-reply-to: Your message of Sun, 02 Aug 1998 16:51:32 -0600. From: "Ronald F. Guilmette" Date: Sun, 02 Aug 1998 21:17:13 -0700 Message-ID: <10271.902117833@monkeys.com> X-Processed-By: Deadbolt(tm) Personal E-Mail Filter, Version 0.90 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk In message , Grant Neufeld wrote: >Here are the relevant parts from a new internet-draft I'm preparing. The >working form of the document itself can be found at >http://www.nisto.com/listspec/#DOCUMENTS > >Please address all follow up to the list-header mailing list > , >or to me privately. Thanks. > > The List-Probe Message Header Field for > Identifying Mail List Probe Messages > >Abstract > > This document defines the message header field "List-Probe" > to be used in consistently identifying mail list probe messages. > > >1. Introduction > > Many MTAs (mail transfer agents - mail servers) in use today do not > provide adequate details when failing to transfer mail messages. In > particular, when email is automatically forwarded from a recipient > address to a second address that is 'bouncing' incoming mail, the > error response messages may not properly including the original > (forwarding) recipient address. > > To help deal with this problem, many mailing list managers have taken > to sending out individualized "probe" messages. The probes include > enough identifying information - even if the original recipient > address is not included in the error response - that the forwarding > address can be properly identified. > > The drawback to this approach is that valid recipients will receive > the probe messages in their mail - an unfortunate waste of time and > resources. > > This document defines a message header field, List-Probe, which will > allow MUAs (mail user agents - email clients) to identify and > automatically discard probe messages so the user does not have to be > involved in the process. If a probe message is received by a MUA, > the recipient address is valid, so the probe does not need to be > responded to (and can safely be discarded) since probes are only > seeking error responses. A question if you don't mind... Isn't this basically the exact same sort of facility that the SMTP VRFY command is supposed to provide? If so, why write a new RFC? Why not just get people to implement the old one(s)? It seems to me that a lot of people out there disable the VRFY command in their MTAs out of a misplaced concern for ``security''. So even if you come up with a new way of verifying addresses as being really and truly alive and active, won't people just disable _that_ also? -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc. -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/ -- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/ From list-managers-owner Mon Aug 3 02:25:38 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA24975; Mon, 3 Aug 1998 00:58:16 -0700 (PDT) Received: from sparc.sandiegoca.ncr.com (tan7.NCR.COM [192.127.94.7]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id AAA24968 for ; Mon, 3 Aug 1998 00:58:07 -0700 (PDT) Received: (from bhoule@localhost) by sparc.sandiegoca.ncr.com (8.8.8/8.8.5) id BAA20596; Mon, 3 Aug 1998 01:03:01 -0700 (PDT) From: Bill Houle Message-Id: <199808030803.BAA20596@sparc.sandiegoca.ncr.com> Subject: Re: ownership change? To: rogerk@QueerNet.ORG (Roger B.A. Klorese) Date: Mon, 3 Aug 1998 01:03:00 -0700 (PDT) Cc: ron40xc@mindspring.com, list-managers@GreatCircle.COM In-Reply-To: from "Roger B.A. Klorese" at Aug 1, 98 08:31:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Roger B.A. Klorese said: > > - if the site is running MajorCool, you can change the owner field there. To clarify, "there" is the list configuration [file]. And this is not a blanket statement, as implementation of the "owner" keyword is entirely optional and may not be present even if MajorCool is installed. --bill From list-managers-owner Mon Aug 3 02:40:42 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA24073; Sun, 2 Aug 1998 23:45:08 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA24063 for list-managers@greatcircle.com; Sun, 2 Aug 1998 23:45:06 -0700 (PDT) Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [128.219.128.125]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id HAA03680 for ; Fri, 31 Jul 1998 07:04:17 -0700 (PDT) Received: (qmail 2372 invoked by uid 3995); 31 Jul 1998 14:10:20 -0000 Message-ID: <19980731141020.2371.qmail@sws5.ctd.ornl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Dave Sill To: list-managers@GreatCircle.COM Subject: Re: "probe failed" (was: Re: Unhelpful Bounce Of The Week) In-Reply-To: <30704.901867732@monkeys.com> References: <2.2.32.19980731024749.01086a74@pop.ma.ultranet.com> <30704.901867732@monkeys.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M wrote: > >Why does it make any sense to send yet another message to an address that >you already know and believe is dead? Because you don't know it's dead--you just know it's bouncing. I've seen several cases where bounced messages were *also* successfully delivered. If you don't send the user a message saying "Hey, your mail is bouncing", they may never realize it. -Dave From list-managers-owner Mon Aug 3 02:47:45 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA23842; Sun, 2 Aug 1998 23:42:09 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA23832 for list-managers@greatcircle.com; Sun, 2 Aug 1998 23:42:06 -0700 (PDT) Received: from mail.wavefront.com (ns.wavefront.com [204.73.244.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id NAA13012 for ; Tue, 28 Jul 1998 13:36:55 -0700 (PDT) Received: by mail.wavefront.com (8.6.10/SMI-4.1.R931202) id PAA12110; Tue, 28 Jul 1998 15:46:58 -0500 Message-Id: <199807282046.PAA12110@mail.wavefront.com> Received: from pm3-47.wavefront.net(206.146.214.47), claiming to be "clift.wavefront.com" via SMTP by ns.wavefront.com, id smtpdAAAa12104; Tue Jul 28 20:46:48 1998 Comments: Authenticated sender is From: "Steven Clift" Organization: Democracies Online To: list-managers@greatcircle.com Date: Tue, 28 Jul 1998 15:35:21 -0500 Subject: Major E-mail Announce Lists Reply-to: clift@publicus.net X-mailer: Pegasus Mail for Win32 (v2.54) Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Does anyone have advice on reliable providers of e-mail announcement list services in the U.S.? A project I work with may need support for web based subscription to a one-way announcement list. It is hard to estimate the number of subscribers but to say between 5,000 to 50,000. About one message a week from mid-September into November would be sent. With a few extras around election time. I am interested in systems that ask the web form subscribers to verify their address by glancing at it on a confirmation page, but feel a confirm reply e-mail message might reduce the number of subscribers. I am also interested in systems that use the listserv "probe" feature or some other feature that can be used to clean out bad addresses. The list would potentially be used lightly in 1999 and regeared up for 2000 with non-partisan activities related to the Presidential election. Any suggestions on who to get a bid from on such a list? And who has the best track record with such matters? Thanks, Steven Clift ------------------------------------------------------- Steven Clift - Public Strategies for the Online World 3454 Fremont Ave S T: +1.612.822.8667 Mpls, MN 55408 USA E: clift@publicus.net Consulting and Home Page - http://www.publicus.net Democracies Online - http://www.e-democracy.org/do Read my new article "Democracy is Online" from link. ------------------------------------------------------- From list-managers-owner Mon Aug 3 02:55:50 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA23566; Sun, 2 Aug 1998 23:38:54 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA23556 for list-managers@greatcircle.com; Sun, 2 Aug 1998 23:38:51 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA25547 for ; Sat, 25 Jul 1998 19:14:17 -0700 (PDT) Received: from slip129-37-51-83.ca.us.ibm.net (slip129-37-51-83.ca.us.ibm.net [129.37.51.83]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id CAA24362 for ; Sun, 26 Jul 1998 02:19:21 GMT Message-ID: <35BA93BC.AD1@Qmail.com> Date: Sat, 25 Jul 1998 19:26:04 -0700 From: Thompson X-Mailer: Mozilla 3.04 (Win16; I) MIME-Version: 1.0 To: list-managers@GreatCircle.COM Subject: Helpful Feedback for Newbies Who Err? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk - -------------- Quoting Chuq ----------- - > Date: Thu, 23 Jul 1998 21:36:32 -0700 > From: Chuq Von Rospach > Subject: Re: Some thoughts on user validation.... > > 7/23/98 [Mike]--- >> They don't know how to use an editor, so they send 2 or 3 line posts >> followed by the ENTIRE message they're responding to, and sometime >> the entire message that THAT one responded to, etc. >> >> We get posts that contain redundant data in HTML format, posts with >> Microsoft TNEF attachments on them, whatever the Bill Gates those are, etc. [Chuq]--- > That's why I built front end filters on things. It traps this stuff, > and sends back a useful message to the user that actually tries to > explain the situation. Wow, Chuq, would I like to see those messages! I wonder if they may be useful as templates for others of us to consider? Are they copyrighted? Steal-able? is there a way you could possibly make them available? Post them on a web site somewhere...? I'm a list maintainer, learning that I can't help zubscribers whose email tools are completely unfamiliar to me. I would love to have---and share with zubscribers---some helpful information on how/where to turn off html or QP or iso or whatever, in their email clients. Folks who don't read manuals and are completely unfamiliar with their own email tools, create key problems. And I can't help them with that, if I too am clueless about their client. That stymies me, time and again. Hmm, not only would I like to offer helpful information, I'd like to offer it in a way that doesn't reflect annoyance on my part. That would be a bonus. Thanks, Thompson From list-managers-owner Mon Aug 3 03:05:27 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA24041; Sun, 2 Aug 1998 23:44:40 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA24033 for list-managers@greatcircle.com; Sun, 2 Aug 1998 23:44:38 -0700 (PDT) Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA23433 for ; Thu, 30 Jul 1998 19:41:09 -0700 (PDT) Received: from voyager (d233.dial-5.cmb.ma.ultra.net [209.6.68.233]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with SMTP id WAA24217; Thu, 30 Jul 1998 22:47:02 -0400 (EDT) Message-Id: <2.2.32.19980731024749.01086a74@pop.ma.ultranet.com> X-Sender: stanr@pop.ma.ultranet.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jul 1998 22:47:49 -0400 To: "Ronald F. Guilmette" From: Stan Ryckman Subject: "probe failed" (was: Re: Unhelpful Bounce Of The Week) Cc: list-managers@GreatCircle.COM Sender: list-managers-owner@GreatCircle.COM Precedence: bulk At 04:25 PM 7/30/98 -0700, Ronald F. Guilmette wrote: >Speaking of ``probes'', I have just been dealing with a problem on my end >that is rather annoying and which seems to be due to some rather glaring >stupidity on the part of those folks who developed the Listserv package. >(Is that Lsoft, Inc.?) Yup (and I'm not speaking for them, but I'm "owner" of a LISTSERV list). [snip] >The problem is that 9apparently) Listserv cane be told (by the list owner) >to perform some sort of a ``probe'' on a given address which may be bad, >and it will then go and try to do that. It can also be told to do this routinely (at least recent versions). >Now get this... if the probe FAILS... which is to say if the address is >in fact bad... then it appears that Listserv then tries to send a ``probe >failed'' message TO THE ADDRESS THAT JUST FAILED! I think this give the subscriber's system one last chance to have recovered from one of those "transient permanent" errors. >No, I'm not making this up. > >That doesn't bother me so much as the WAY in which these idiotic ``probe >failed'' messages are sent... They appear to be sent with a null/empty >envelope return address, thus making them (in some ways related to spam >filtering) indistinguishable from ordinary Mailer-Daemon bounces for mail >which was sent *from* my system to someplace else. > >It seems to me that this is beyond moronic. Up till now I really believed >that there were only two uses for null envelope return addresses, i.e. for >sending back E-mail bounce messages and for spamming. > >If anybody wants to explain to me why my criticisms of Listserv are unfound- >ed, I'm all ears. Well, the null envelope return address just means that there is nobody who cares if the message can be delivered; it can be silently trashed. It is you who CHOSE to examine mail that said "discard if undeliverable." Its use predates spamming by decades. True, the most COMMON use is to avoid "bounce loops." When LISTSERV probes, it needs the bounce so it can remove the subscriber, so the probe itself has a non-null envelope return address. Once it has removed the subscriber, there is nothing more LISTSERV can do unless the subscriber rejoins by the normal process--so why tell the other system to generate another bounce, and then discard the bounce? Waste of traffic on both sides. LISTSERV generates null envelope return addresses for other messages as well. I believe an example of this may be a request to search an archive. If the search results can't reach the requestor, LISTSERV can do nothing with bounced search results. Maybe you disagree with the probe process or the "probe failed" message or the fact that it now happens to fall in your "mis-addressed spam" pile... but it hardly seems deserving of the term "beyond moronic." That's my opinion, anyway. Cheers, Stan From list-managers-owner Mon Aug 3 03:09:48 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA23624; Sun, 2 Aug 1998 23:39:36 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA23614 for list-managers@greatcircle.com; Sun, 2 Aug 1998 23:39:33 -0700 (PDT) Received: from lokkur.dexter.mi.us (lokkur.dexter.mi.us [148.59.2.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA09685 for ; Sun, 26 Jul 1998 19:14:29 -0700 (PDT) Received: (from scs@localhost) by lokkur.dexter.mi.us (8.8.8/8.8.8/lokkur-1.1-scs) id WAA17972; Sun, 26 Jul 1998 22:16:31 -0400 (EDT) To: list-managers@GreatCircle.COM Path: lokkur.dexter.mi.us!not-for-mail From: scs@lokkur.dexter.mi.us (Steve Simmons) Newsgroups: local.list-managers Subject: Unhelpful Bounce**2 Of The Week Date: 26 Jul 1998 22:16:30 -0400 Organization: Inland Sea Lines: 110 Distribution: local Message-ID: <6pgntu$hhh$1@lokkur.dexter.mi.us> Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Oh, this one was great. Someone sent mail to a list with a member whose company receives mail via Compuserve MX. First there was the bounce message. Not the worst ever seen, but far from the best. I forwarded the bounce message to the postmaster (1st message below) and got a startling response. First, my message forwarding the bounce to postmaster@compuserve.com. Note the recipients name was *not* in the To: or Cc fields; Compuserve apparently created a plaintext bcc containing it. They also rewrote the case in the fulltext name, and inserted a fairly amazing number of %-directives into the
. ===================================================================== > The following bounce message has been occurring regularly for a person > at Ryder systems. When it departs here, the To: field is > dorsai@lokkur.dexter.mi.us and the envelope is for > . > By the time of the bounce, it seems to have been rewritten into the > odd bcc format below. > > In any case, ``Server's name changed'' is not a very informative > error message. If there's anything I can do on my end to rectify > this, please let me know. > > Steve > > ----- Forwarded message from Mailer-Daemon@sxhad.compuserve.net ----- > > Message-Id: <9807261730.AA1319@notesgw.compuserve.com> > To: scs > From: Mailer-Daemon@sxhad.compuserve.net > Date: Sun, 26 Jul 98 13:30:18 > Subject: Returned mail > Mime-Version: 1.0 > Content-Type: Multipart/Mixed; Boundary="-- message ----" > > ---- message ---- > > Router: Unable to open mailbox file CSERVE-82/SERVER/CSERVE mail.box: > Server's name changed > > ---- message ---- > Content-Type: Message/rfc822 > Content-Description: RFC822 > > To: dorsai > bcc: "name-removed-by-scs/rdl/rydersysteminc/us" /rydersysteminc/us%rydersysteminc%rydersysteminc%rydergate > @notesgw.compuserve.com> > From: cl29 > Date: 21 Jul 98 13:07:35 > Subject: beer > MIME-Version: 1.0 > Content-Type: Text/Plain > > ---- message ------ > > ----- End forwarded message ----- Imagine my surpise when a few seconds later this missive arrived: > Date: Mon, 27 Jul 1998 00:15:50 -0400 > Message-Id: <199807270415.AAA25003@postmaster.compuserve.com> > To: scs@lokkur.dexter.mi.us > References: <19980726215333.A17452@lokkur.dexter.mi.us> > In-Reply-To: <19980726215333.A17452@lokkur.dexter.mi.us> > Precedence: addrb1 > X-Loop: postmaster@compuserve.com > From: CompuServe Postmaster > Subject: RE: Addressing Members > Reply-To: pmaster@postmaster.compuserve.com > Error-To: pmaster@postmaster.compuserve.com > Status: RO > Content-Length: 925 > Lines: 26 > > > All CompuServe addresses are either of the form 7xxxx,xxx or > 1xxxxx,xxx. (where each "x" signifies a digit from 0 to 7). > There can be from 2 to 4 digits following the comma. > > To send mail to such an address from the Internet, change the > comma to a period and attach "@CompuServe.com" as is shown > in the following examples: > > 74906.1610@CompuServe.com or 100906.1610@CompuServe.com > > All CompuServe alphanumeric addresses contain 2-32 characters. > Valid characters are A-Z, a-z, 0-9, and "_" (underscore). > There must be one alpha character, but not more than four of > the same character consecutively. To send mail to such an > address from the Internet, type the address and attach > "@CompuServe.com" as is shown in the following example: > > ID_123@CompuServe.com > > Please contact postmaster@compuserve.com if you need additional > formatting information for other types of addresses. > > Cordially, > > The Electronic Postmaster Note the From address is exactly the address I sent to! My brief and testy reply was sent to the reply-to, and it doesn't seem to have bounced. Let's see if a human being responds . . . -- "Where there's a will, there's a lawyer." Kinky Friedman, `God Bless John Wayne' From list-managers-owner Mon Aug 3 03:23:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id DAA27478; Mon, 3 Aug 1998 03:03:11 -0700 (PDT) Received: from wubios.wustl.edu (wubios.wustl.edu [128.252.117.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id DAA27471 for ; Mon, 3 Aug 1998 03:03:05 -0700 (PDT) Received: (from phil@localhost) by wubios.wustl.edu (8.9.0/8.9.0) id FAA28239; Mon, 3 Aug 1998 05:09:37 -0500 (CDT) From: "J. Philip Miller" Message-Id: <199808031009.FAA28239@wubios.wustl.edu> Subject: Re: "probe failed" (was: Re: Unhelpful Bounce Of The Week) To: de5@sws5.ctd.ornl.gov (Dave Sill) Date: Mon, 3 Aug 1998 05:09:36 -0500 (CDT) Cc: list-managers@greatcircle.com In-Reply-To: <19980731141020.2371.qmail@sws5.ctd.ornl.gov> from "Dave Sill" at Jul 31, 98 10:10:19 am X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > "Ronald F. Guilmette" wrote: > > > >Why does it make any sense to send yet another message to an address that > >you already know and believe is dead? > > Because you don't know it's dead--you just know it's bouncing. I've > seen several cases where bounced messages were *also* successfully > delivered. If you don't send the user a message saying "Hey, your mail > is bouncing", they may never realize it. > which is why the majordomo solution of placing "bouncing subscribers" onto a special "bounces" (list which sends the message that the subscriber has been removed for many days after they have been removed) work so well. -phil > -Dave > > -- J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University School of Medicine, St. Louis MO 63110 phil@wubios.WUstl.edu - (314) 362-3617 [362-2693(FAX)] http://www.biostat.wustl.edu/~phil From list-managers-owner Mon Aug 3 06:56:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA02854; Mon, 3 Aug 1998 06:13:50 -0700 (PDT) Received: from ifolk.iserver.net (ifolk.iserver.net [192.41.44.203]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA02841 for ; Mon, 3 Aug 1998 06:13:35 -0700 (PDT) Received: from newmicronpc (slip-32-100-104-62.ct.us.ibm.net [32.100.104.62]) by ifolk.iserver.net (8.8.5) id HAA27488; Mon, 3 Aug 1998 07:20:01 -0600 (MDT) From: "Tom Neff" To: Subject: Re: individualized probe messages Date: Mon, 3 Aug 1998 09:29:04 -0400 Message-ID: <000001bdbee2$af2b9fc0$3e686420@newmicronpc> 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 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <199808030800.BAA25109@honor.greatcircle.com> Importance: Normal Sender: list-managers-owner@GreatCircle.COM Precedence: bulk "David W. Tamkin" wrote: > Background: I posted about a problem I had had to deal with without the > facilities that many of you have at your disposal. Tom Neff then posted a > follow-up that offered a solution I could not have used... ... > | I should emphasize (if it's not already obvious) that the From: addresses, > | machine and domain you use for the serialized probe need have nothing to do > | with the machine or domain that the mailing list itself emanates from. > > Yes, the From: address and the From_ address can differ from the true send- > ing point and from one another. No, that's not what I'm saying. I'm saying that if the LIST you wish to probe is hosted at BLACKIRONPRISON.COM and you have NO privileges there at all, it doesn't matter, because you can conduct your probe from LITTLEBOX.CUTEPUPPY.EDU or FRIEND.VANITY.COM or anywhere else you can either throw a real or virtual server on the Net, or borrow the service from someone else who has one. If other list-managers here use the serialized-From trick successfully, then one could just post a query "Need to conduct an individualized probe - will trade old Archie comix - private replies please" and someone could respond. You could even offer the service for money, hint hint. By the way, the suggestion was also made to use Unix "plus addressing", e.g., From: jsmith+12345@something.com - it's a great suggestion but after trying it on three separate sites, I haven't gotten it to work. Has Sendmail 8.9 broken this, perhaps? From list-managers-owner Mon Aug 3 13:26:29 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA03309; Mon, 3 Aug 1998 06:49:03 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA03302 for ; Mon, 3 Aug 1998 06:48:54 -0700 (PDT) Received: from quill (norbert@gate3-4.cyberlink.ch [195.246.74.74]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id PAA19591; Mon, 3 Aug 1998 15:55:22 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id QAA00561; Mon, 3 Aug 1998 16:35:10 +0200 Date: Mon, 3 Aug 1998 16:35:10 +0200 Message-Id: <199808031435.QAA00561@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: RAF@CU.NIH.GOV CC: list-managers@GreatCircle.COM In-reply-to: <199808011742.KAA24896@web.webcoach.com> (RAF@CU.NIH.GOV) Subject: Re: Listserv's violation of RFC821 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I wrote: > > So far, the only situation when an entity A can legally send something > > with null return path to another entity B is when A needs to make some > > kind of status report about an e-mail message (with non-null return > > path) which was sent by B. Roger Fajman replied: > When RFC 821 was written, spam did not exist, so the > issue wasn't considered. You have a good point here. The issue should be considered and then clarified. I will stop arguing about obscure implications of RFCs on matters which were not considered when the original standard was written. > The mailing list for the working group is drums@cs.utk.edu. To be > added, write to drums-request@cs.utk.edu. Done. > But the working group is trying to get both this document and the RFC > 822 revision out the door, so it may well not want to consider this > issue at this late date. Actually IMHO the most logical place to clarify this matter would not be the revision of RFC 821, but a revision of RFC 1123. Do you know whether such a revision is planned or in progress? -- NB. From list-managers-owner Mon Aug 3 14:22:49 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA10609; Mon, 3 Aug 1998 13:44:23 -0700 (PDT) Received: from beltway.cd.com (beltway.cd.com [204.217.30.66]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id NAA10601 for ; Mon, 3 Aug 1998 13:43:46 -0700 (PDT) Received: from bif.cd.com by beltway.cd.com (5.x/SMI-SVR4) id AA14435; Mon, 3 Aug 1998 15:49:39 -0500 Received: by bif.cd.com (SMI-8.6/SMI-SVR4) id PAA11797; Mon, 3 Aug 1998 15:46:35 -0500 From: richardm@cd.com (Richard Masoner) Message-Id: <199808032046.PAA11797@bif.cd.com> Subject: Re: individualized probe messages To: tneff@panix.com (Tom Neff) Date: Mon, 3 Aug 1998 15:46:35 -0500 (CDT) Cc: List-Managers@GreatCircle.COM In-Reply-To: <000001bdbee2$af2b9fc0$3e686420@newmicronpc> from "Tom Neff" at Aug 3, 98 09:29:04 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > By the way, the suggestion was also made to use Unix "plus addressing", e.g., > From: jsmith+12345@something.com - it's a great suggestion but after trying it > on three separate sites, I haven't gotten it to work. Has Sendmail 8.9 broken > this, perhaps? Works for me with systems running sendmail 8.7 and 8.8.8. It doesn't work on the sendmail that comes with Solaris 2.6. I haven't tried it with a system running sendmail 8.9. sendmail that comes with various versions of IRIX also seem to break. sendmail which ships with IRIX 6.5, for example, is based on 8.8.8 code. Richard Masoner Champaign Illinois USA From list-managers-owner Mon Aug 3 14:55:01 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA10114; Mon, 3 Aug 1998 13:07:37 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA10106 for ; Mon, 3 Aug 1998 13:07:17 -0700 (PDT) Received: from Venus.mcs.net (dattier@Venus.mcs.net [192.160.127.92]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id PAA16612 for ; Mon, 3 Aug 1998 15:13:51 -0500 (CDT) Received: (from dattier@localhost) by Venus.mcs.net (8.8.7/8.8.2) id PAA08481 for list-managers@greatcircle.com; Mon, 3 Aug 1998 15:13:51 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199808032013.PAA08481@Venus.mcs.net> Subject: Re: individualized probe messages To: list-managers@greatcircle.com Date: Mon, 3 Aug 1998 15:13:50 -0500 (CDT) In-Reply-To: <000001bdbee2$af2b9fc0$3e686420@newmicronpc> from "Tom Neff" at Aug 3, 98 09:29:04 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Tom Neff wrote, | I'm saying that if the LIST you wish to probe is hosted at | BLACKIRONPRISON.COM and you have NO privileges there at all, it doesn't | matter, because you can conduct your probe from LITTLEBOX.CUTEPUPPY.EDU or | FRIEND.VANITY.COM or anywhere else you can either throw a real or virtual | server on the Net, or borrow the service from someone else who has one. Yes ... as long as the site is under your control or whoever controls it lets you. Thank you for clarifying; that is rather different from what I thought you meant (which was also true). | If other list-managers here use the serialized-From trick successfully, | then one could just post a query "Need to conduct an individualized probe - | will trade old Archie comix - private replies please" and someone could | respond. Of course; that is a good example of a way we can help one another out in addition to answering one another's questions. I asked a bigger favor on this very list this past spring and another member offered the service (which I will need for the last time later this month). | By the way, the suggestion was also made to use Unix "plus addressing", | e.g., From: jsmith+12345@something.com - it's a great suggestion but after | trying it on three separate sites, I haven't gotten it to work. Has | Sendmail 8.9 broken this, perhaps? Hmm. I'll try it from here. When my problem with a member who forwarded to a bad Prodigy address occurred, I had no plus addressing available, but I do now. Results to follow. From list-managers-owner Mon Aug 3 17:59:38 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA14807; Mon, 3 Aug 1998 17:48:30 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA14778 for ; Mon, 3 Aug 1998 17:48:05 -0700 (PDT) Received: from Mars.mcs.net (dattier@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id TAA27262 for ; Mon, 3 Aug 1998 19:54:48 -0500 (CDT) Received: (from dattier@localhost) by Mars.mcs.net (8.8.7/8.8.2) id TAA12150 for list-managers@greatcircle.com; Mon, 3 Aug 1998 19:54:48 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199808040054.TAA12150@Mars.mcs.net> Subject: plus+addressing and probes To: list-managers@greatcircle.com Date: Mon, 3 Aug 1998 19:54:47 -0500 (CDT) In-Reply-To: <000001bdbee2$af2b9fc0$3e686420@newmicronpc> from "Tom Neff" at Aug 3, 98 09:29:04 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Tom Neff wrote, | By the way, the suggestion was also made to use Unix "plus addressing", | e.g., From: jsmith+12345@something.com - it's a great suggestion but after | trying it on three separate sites, I haven't gotten it to work. Has | Sendmail 8.9 broken this, perhaps? Hard to say ... I sent mail to an impossible address with the envelope sender pointing to a plussed address for me on a machine running Sendmail 8.9.0 -- but it will deliver mail for me that I can read on servers in the domain, I cannot log into the machine that runs 8.9.0 and honors plussing. It was bounced to the full plussed address. Then I tried sending mail to an impossible address on the 8.9.0 machine with the envelope directed to a plussed address for me here, where the Sendmail version appears to be 8.8.7. The plussing was honored for the bounce, but the item was refused in consultation and never got into the 8.9.0 machine. Perhaps someone who can log into a machine running 8.9.0 can throw more light on the subject. I'm assuming that the colon in Mr. Neff's "From:" is a typo and he was set- ting the envelope sender to the plussed address, not just the RFC822 From: field. From list-managers-owner Mon Aug 3 20:17:10 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA15782; Mon, 3 Aug 1998 18:59:59 -0700 (PDT) Received: from CU.NIH.GOV (cu.nih.gov [128.231.160.111]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id SAA15775 for ; Mon, 3 Aug 1998 18:59:48 -0700 (PDT) Message-Id: <199808040159.SAA15775@honor.greatcircle.com> To: nb@thinkcoach.com cc: list-managers@GreatCircle.COM From: "Roger Fajman" Date: Mon, 3 Aug 1998 22:04:00 -0400 (EDT) Subject: Re: Listserv's violation of RFC821 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > Actually IMHO the most logical place to clarify this matter would not be > the revision of RFC 821, but a revision of RFC 1123. Do you know whether > such a revision is planned or in progress? > > -- NB. None is in progress and I've not heard of any plans. From list-managers-owner Mon Aug 3 23:17:05 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id WAA18814; Mon, 3 Aug 1998 22:57:08 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id WAA18807 for ; Mon, 3 Aug 1998 22:56:47 -0700 (PDT) Received: (qmail 21544 invoked by uid 500); 4 Aug 1998 06:03:21 -0000 To: list-managers@GreatCircle.COM Subject: Re: "probe failed" (was: Re: Unhelpful Bounce Of The Week) References: <2.2.32.19980731024749.01086a74@pop.ma.ultranet.com> From: Russ Allbery In-Reply-To: Stan Ryckman's message of "Thu, 30 Jul 1998 22:47:49 -0400" Date: 03 Aug 1998 23:03:20 -0700 Message-ID: Lines: 23 X-Mailer: Gnus v5.4.66/Emacs 19.34 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Stan Ryckman writes: > Well, the null envelope return address just means that there is nobody > who cares if the message can be delivered; it can be silently trashed. > It is you who CHOSE to examine mail that said "discard if > undeliverable." Its use predates spamming by decades. True, the most > COMMON use is to avoid "bounce loops." If that's the true intention of the null envelope, then that's a *very* bad idea, as a null envelope doesn't actually mean anything of the sort. If a message with a null envelope bounces, that's a double-bounce, which can often indicate a more serious misconfiguration, and some MTAs will deliver the resulting double-bounce to the local postmaster. I find that feature valuable. Using a null envelope sender is not equivalent to saying that if the message can't be delivered it should be silently trashed. If that's the intention, you should use as the envelope sender an address that silently discards all mail sent to it. Most stock sendmail configurations come with an alias "nobody" that does this. -- Russ Allbery (rra@stanford.edu) From list-managers-owner Tue Aug 4 13:30:04 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA03082; Tue, 4 Aug 1998 13:23:32 -0700 (PDT) Received: from www.kxan.com (kxan.com [207.207.6.50]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA03075 for ; Tue, 4 Aug 1998 13:23:22 -0700 (PDT) Received: (from micah@localhost) by www.kxan.com (8.8.5/8.8.b5) id PAA08789; Tue, 4 Aug 1998 15:30:11 -0500 (CDT) Date: Tue, 4 Aug 1998 15:30:05 -0500 (CDT) From: Micah Thompson To: List-Managers@GreatCircle.COM Subject: Fastest List? In-Reply-To: <000801bdbbbc$cb888710$017b7b0a@gillette> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Hello, I just setup a majordomo list for a local weather Email Alert system, and need some tips. I need more speed! The list's objective is this: To get the alert out to all the subscribers in record speed. Actual subscribers cannot post to the list, so it's just a distribution list really. Currently I am running majordomo with a custom perl program written for me by a friend called "splitlist" but it's still too slow. (splitlist takes the subscriber lists, alphabetizes by reverse domain, and spawns off multiple parallel sendmail processes). It is way faster than majordomo alone, but still not enough. Is majordomo the way to go with this, or should I look into something like listserv? Oh, the mailing list must run on an already heavily loaded server which is usually straining to handle all the web traffic being generated by the bad weather (people looking at my online doppler radar). :) If the weather warning expires at 3:30pm, and a subscriber doesn't receive it until 4:30pm, they tend to get irrate. ;) Thanks, Micah Thompson Computer System Manager WebMaster KXAN-TV 36, NBC Affiliate, http://www.kxan.com KNVA-TV 54, WB Affiliate, http://www.knva.com Austin, TX From list-managers-owner Tue Aug 4 17:59:29 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA06433; Tue, 4 Aug 1998 17:42:45 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA06425 for ; Tue, 4 Aug 1998 17:42:37 -0700 (PDT) Received: from quill (norbert@gate3-2.cyberlink.ch [195.246.74.72]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id CAA29482; Wed, 5 Aug 1998 02:49:24 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id DAA00561; Wed, 5 Aug 1998 03:47:39 +0200 Date: Wed, 5 Aug 1998 03:47:39 +0200 Message-Id: <199808050147.DAA00561@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: Detailed Revision/Update of Message Standards Cc: list-managers@greatcircle.com Subject: Clarification request: limits on use of null reverse-path Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Greetings, In the replacement for RFC821 I would like to see the issue clarified of when it is appropriate to use a null reverse-path. As I understand RFC821 and also draft-ietf-drums-smtpupd-07, the intended meaning is that a null reverse-path should only be used in certain circumstances, namely when an entity A has sent an e-mail message to B, then B may use a null reverse-path when sending a notification about this message back to A. What I would like to see clarified is that it is not appropriate to use a null reverse-path merely because the sender does not want to be bothered with non-delivery notifications. Norbert Bollow (Zuerich, Switzerland) suggested additions to draft-ietf-drums-smtpupd-07 ================================================== Add the following at the end of the second paragraph in section 4.1.1.2: : ... However, a null reverse-path SHOULD NOT be used merely because the : sender does not want to be bothered with non-delivery notifications. See : section ##6.4 for a discussion of when a null reverse-path is appropriate : and when it is not. Add the following after section 6.3: : 6.4 The importance of the null reverse-path for debugging mail problems : : There are several types of notification messages which are required by : the relevant standards to be sent with a null reverse path, namely : non-delivery notifications as discussed in section ##3.7, other kinds : of Delivery Status Notifications (DSNs, see [RFC 1894]) and also : Message Disposition Notifications (MDNs, see [RFC 2298]). All of these : kinds of messages are notification about a previous message, and they : are sent to the reverse-path of the previous mail message. If the : delivery of such a notification message fails, that usually indicates : a problem with the mail system of the host to which the notification : message is addressed. For this reason, at many hosts the MTA is set up : to forward such failed notification messages to someone who is able to : fix problems with the mail system, e.g. via the postmaster alias. This : is a valuable tool for debugging mail problems. : : For messages where the recipient address has been obtained from any : source other than the reverse-path of a previous message, a null : reverse path SHOULD NOT be used, so that the mail administrator of the : destination host will not be needlessly alerted if the message is : undeliverable. From list-managers-owner Wed Aug 5 05:51:38 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id FAA16112; Wed, 5 Aug 1998 05:36:17 -0700 (PDT) Received: from MAINE.maine.edu (maine.maine.edu [130.111.39.100]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id FAA16105 for ; Wed, 5 Aug 1998 05:36:03 -0700 (PDT) Received: from polaris.umpi.maine.edu [130.111.208.87] by MAINE.maine.edu (IBM VM SMTP Level 310) via TCP with SMTP ; Wed, 05 Aug 1998 08:41:56 EDT Received: from POLARIS/MERCURYQUEUE by polaris.umpi.maine.edu (Mercury 1.21); 5 Aug 98 08:43:04 EST Received: from MERCURYQUEUE by POLARIS (Mercury 1.21); 5 Aug 98 08:42:55 EST From: "Anthony J. Albert" Organization: University of Maine at PI To: List-Managers@GreatCircle.COM Date: Wed, 5 Aug 1998 08:42:49 EST MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fastest List? X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <3F5678287D@polaris.umpi.maine.edu> Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On 5 Aug 98 at 1:00, List-Managers-Digest wrote: >Date: Tue, 4 Aug 1998 15:30:05 -0500 (CDT) >From: Micah Thompson >Subject: Fastest List? > >Hello, > >I just setup a majordomo list for a local weather Email Alert system, and >need some tips. > >I need more speed! The list's objective is this: To get the alert out >to all the subscribers in record speed. Actual subscribers cannot post >to the list, so it's just a distribution list really. >If the weather warning expires at 3:30pm, and a subscriber doesn't >receive it until 4:30pm, they tend to get irrate. ;) > Well, one possible speed improvement would be to take Majordomo out of the loop entirely. Just set up an account on the machine which has the sole purpose of running a job every five or ten minutes, which can then distribute the mail in its inbox, if there is any. Admittedly, this is the next nearest thing to re-writing Majordomo, so that may not be the way to go. Also, you would lose the ability for people to subscribe themselves to the list, most likely, so, on second thought, this may really _not_ be the way to go. The real strategy here is to first determine what the bottleneck is. It could be one of a number of things: network connection(s), the load the machine is carrying for other tasks, or the time it takes to process the mailing lists via the perl script you mentioned. If possible, I would suggest having the perl script modified slightly so that when the next alert went out, it put the time-stamp for each message into a file. Then you could examine the file to see how long after the alert was first sent to majordomo it took for the mail to start to be distributed. The next thing to do would be to examine the logs for the httpd program. See if you can get information about how many hits it is getting during the time that the weather warning is being emailled. If it's getting lots of hits during the email distribution time, then you might begin to think about getting another machine to handle the email. If the machine is getting few or some hits during the email distribution, it might be a network limitation, and you might investigate to see where the limiting factor in network bandwidth is. Hope this helps, Anthony J. Albert ============================================================== Anthony J. Albert albert@polaris.umpi.maine.edu Systems and Software Support Specialist Postmaster Computer Services - University of Maine, Presque Isle "The World Wide Web is just like its namesake, the spider's web - full of dirt and bugs!" From list-managers-owner Wed Aug 5 06:36:44 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA16510; Wed, 5 Aug 1998 06:25:17 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA16490 for ; Wed, 5 Aug 1998 06:25:05 -0700 (PDT) Received: from quill (norbert@gate3-7.cyberlink.ch [195.246.74.77]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id PAA32487; Wed, 5 Aug 1998 15:31:44 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id QAA00735; Wed, 5 Aug 1998 16:09:40 +0200 Date: Wed, 5 Aug 1998 16:09:40 +0200 Message-Id: <199808051409.QAA00735@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: drums@cs.utk.edu, list-managers@greatcircle.com In-reply-to: (message from Philip Hazel on Wed, 5 Aug 1998 10:04:19 +0100 (BST)) Subject: Re: Clarification request: limits on use of null reverse-path Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I wrote: > What I would like to see clarified is that it is not appropriate to use > a null reverse-path merely because the sender does not want to be > bothered with non-delivery notifications. Philip Hazel replied: > That would leave no simple mechanism for a sender to achieve that > effect. I am not convinced that there are any situations where this effect is really appropriate except when sending some kind of notification to the return path of a previously-received message. However _if_ you really want to send a message so that you won't see any notifications about it (and I'm assuming that you have a legitimate reason for this, i.e. you're not a spammer), you can always set your envelope sender to a 'nobody' alias at the originating host which forwards to /dev/null or the equivalent. > (DSN is not simple, nor widely deployed.) The increasing use of > autoresponders means that is it important to have such a mechanism, as > otherwise the chance of autoresponder<=>autoresponder loops is > increased. If you're talking about an autoresponder which sends its response to the envelope sender of the incoming message, the text which I'm proposing does not forbid the autoresponder to use a null return path. (The "SHOULD NOT" in the proposed addition to section 4.1.1.2 does not apply because in this case the intention is to prevent loops and not just that someone does not want to be bothered. The "SHOULD NOT" in the proposed new section 6.4 does not apply either. If you're talking about an autoresponder which sends its response to the header From: address of the incoming message, then the appropriate action will _not_ be to use a null reverse path, but to use a non-null reverse-path that is a valid e-mail address at the host with the autoresponder, but which is guaranteed not to lead to such an autoresponder, e.g. something like . In my opinion the appropriate way to handle mail to this address would be a little perl script which checks incoming messages with null return path if there is a large number of such notifications from the same host (in which case postmaster would be alerted about the potential problem) and discards notifications otherwise, while messages with non-null return path would be forwarded to a human who is responsible for the autoresponder. However if you do not agree with this opinion and you prefer to handle all mail manually, or discard it all unread, there is nothing in my proposed text which would forbid either of those two options. Note that from the perspective of debugging obscure problems, an e-mail robot which sends messages with a reverse path like is better than one which uses a null reverse path not only because the reverse path helps avoiding unneccessary double bounces, but also because the reverse path helps with distinguishing between maillog entries from bounces and those from messages sent by an e-mail robot. The only reason why I have not included this point in my proposed text is that I don't think that a reverse path (which forwards to /dev/null and nowhere else) will ever be really appropriate. Loops between various e-mail rebots (not only autoresponders) should be fought with methods that do not make it impossible for the e-mail robot to look at bounces of messages which they send. It is true that the methods which are currently employed for preventing loops between various e-mail rebots are somewhat ad-hoc and unsatisfying. They could be greatly improved by a new, standardized Robots: header which would specify what kind of action an e-mail robot should take if the message is processed by one. The possible actions could be "discard", "bounce" or "process", with a default of "process" if the header is not there. > > : For messages where the recipient address has been obtained from any > > : source other than the reverse-path of a previous message, a null > > : reverse path SHOULD NOT be used, so that the mail administrator of the > > : destination host will not be needlessly alerted if the message is > > : undeliverable. > > In many cases it is the mail administrator of the sending host who would > be alerted, True. I will need to revise my proposed text a little. If there is a rough consensus in the DRUMS working group to include something similar in meaning to the "SHOULD NOT" which I'm proposing, I will be willing to work a little more on the explanatory text, at least to correct the minor error which you pointed out. (I currently feel that trying to discuss e-mail robots, or spam, automated bounce-handling in any detail would be outside of the intended scope of the document, though.) > but it does depend on the way the destination's MTA is > configured. Yes. > When the volume of mail on any system gets at all > substantial, mail administrators tend simply to ignore undeliverable > messages whose senders are "<>". 99% of those I see are the result of > spam. However if you take precautions not to expose most of the email addresses of your network on the Web or Usenet or in unprotected mailing list archives (i.e. those places where spammers go to harvest e-mail adresses) and you make sure that the addresses which you need to expose will never become invalid, you will not have this problem. (Of course another, and probably much more important, benefit of such a policy is that you can then install a spam filter on those addresses which you expose). -- NB. From list-managers-owner Wed Aug 5 07:20:54 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA16791; Wed, 5 Aug 1998 06:58:21 -0700 (PDT) Received: from beltway.cd.com (beltway.cd.com [204.217.30.66]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id GAA16784 for ; Wed, 5 Aug 1998 06:58:14 -0700 (PDT) Received: from bif.cd.com by beltway.cd.com (5.x/SMI-SVR4) id AA12343; Wed, 5 Aug 1998 09:04:36 -0500 Received: by bif.cd.com (SMI-8.6/SMI-SVR4) id JAA08467; Wed, 5 Aug 1998 09:01:36 -0500 From: richardm@cd.com (Richard Masoner) Message-Id: <199808051401.JAA08467@bif.cd.com> Subject: Re: Fastest List? To: micah@kxan.com (Micah Thompson) Date: Wed, 5 Aug 1998 09:01:36 -0500 (CDT) Cc: List-Managers@GreatCircle.COM In-Reply-To: from "Micah Thompson" at Aug 4, 98 03:30:05 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Micah Thompson asked about ways to speed up distribution of his wx alert list: > Is majordomo the way to go with this, or should I look into something > like listserv? Oh, the mailing list must run on an already heavily > loaded server which is usually straining to handle all the web traffic > being generated by the bad weather (people looking at my online doppler > radar). :) The list-admin FAQ at ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq appears to answer your question. Here's an excerpt from the relevant section: --------------------------------------------------------------- Subject: 2.05 Performance and system-load issues related to mail deliver The main issue in distributing to large lists is, how quickly can you get the mail out? Most MLM's leave routing and optimization decisions up to the MTA (Mail Transport Agent, usually Sendmail under Unix), but some other systems -- notably ListProc, LISTSERV, and SmartList -- take a more active approach in managing network load. To illustrate, let's look at the path mail takes to delivery in each of these four systems. --------------------------------------------------------------- Your technique of organizing recipients by domain and starting multiple sendmail processes is similar to what Listproc and SmartList (part of procmail) do. I've used Listproc, majordomo, and procmail; I'm not all that familiar with Listserv other than being on some lists served by Listserv. You'll want to read the FAQ for details, but from what I understand all Listserv servers cooperate with one another and list mail is distributed to other listserv servers for further distribution (if my explanation is messed up somebody please correct me). A few things to consider: 1) Use exploders. For example, if you have several subscribers at foo.com, send one message to an alias at foo.com, and let the MTA there handle distribution to multiple users @ foo.com. This requires the cooperation of the admin at foo.com, of course. 2) sendmail isn't exactly the quickest MTA in the world. Look at some of the alternative MTAs. 3) The time it takes to deliver a message is affected by factors other than the time it takes to leave your system. Your network connectivity can be a BIG factor if you have a large list, especially if you have a popular web server. I'm on the the tornado warning list hosted at the University of Illinois. It typically takes three or four minutes for a notice to get to me once it has left the UofI then through Chicago, mae-west, PSI.NET, and finally to my desktop. 4) Check your network connectivity with your upstream, ALTER.NET. I hear UUNET does things like sell you a T1, then overload it by sticking three other customers on the same T1. The small print will let you know what kind of bandwidth you have. IANAL and other disclaimers apply. 5) Does Austin have some sort of local NAP, and does your provider participate in it? That can also help in distribution to local customers. > If the weather warning expires at 3:30pm, and a subscriber doesn't > receive it until 4:30pm, they tend to get irrate. ;) If they require some sort of real-time notification, well, they need to understand that email is not a reliable method of notification. Richard Masoner Champaign Illinois USA From list-managers-owner Wed Aug 5 08:17:03 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA17831; Wed, 5 Aug 1998 08:03:33 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA17821 for ; Wed, 5 Aug 1998 08:03:16 -0700 (PDT) Received: from quill (norbert@gate3-0.cyberlink.ch [195.246.74.70]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id RAA21480; Wed, 5 Aug 1998 17:09:55 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id SAA00892; Wed, 5 Aug 1998 18:00:41 +0200 Date: Wed, 5 Aug 1998 18:00:41 +0200 Message-Id: <199808051600.SAA00892@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: ph10@cus.cam.ac.uk Cc: drums@cs.utk.edu, list-managers@greatcircle.com In-reply-to: (message from Philip Hazel on Wed, 5 Aug 1998 14:53:46 +0100 (BST)) Subject: Re: Clarification request: limits on use of null reverse-path Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I wrote: > > However if you take precautions not to expose most of the email > > addresses of your network on the Web or Usenet or in unprotected mailing > > list archives (i.e. those places where spammers go to harvest e-mail > > adresses) and you make sure that the addresses which you need to expose > > will never become invalid, you will not have this problem. Philip Hazel replied > I am sorry, but that is totally unrealistic. > > We are a University of over 20,000 people. There is no way we can stop > our users exposing their email addresses to the world. Several thousand I'm sorry that the words I used may indeed be read as sounding a little arrogant, or even insulting. I assure you that they were not meant like that! In fact I did not intend to claim that this scenario would be realistic for everyone or for you in particular. However there are situations (in more corporate environments) where it is possible to do this. The point which I wanted to make is that since in some situations it is possible to control the effects of spam (so that spam does not cause you to be flooded with masses of pointless double bounces) it makes sense to include a statement in the RFC which will prevent software packages from causing pointless double bounces. -- NB From list-managers-owner Wed Aug 5 11:46:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA20968; Wed, 5 Aug 1998 11:36:40 -0700 (PDT) Received: from cli.computerlogic.com (cli.computerlogic.com [204.216.123.193]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA20961 for ; Wed, 5 Aug 1998 11:36:29 -0700 (PDT) Received: from jporter2.computerlogic.com (jporter2.computerlogic.com [204.216.123.126]) by cli.computerlogic.com (8.8.5/SCO5) with SMTP id OAA03501 for ; Wed, 5 Aug 1998 14:43:58 -0400 (EDT) Message-Id: <199808051843.OAA03501@cli.computerlogic.com> X-Sender: jporter@pop.computerlogic.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Wed, 05 Aug 1998 14:38:02 -0400 To: List-Managers@GreatCircle.COM From: "Jimmy D. Porter" Subject: Re: Fastest List? In-Reply-To: References: <000801bdbbbc$cb888710$017b7b0a@gillette> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk At 03:30 PM 8/4/98 -0500, Micah Thompson wrote: >Hello, > >I just setup a majordomo list for a local weather Email Alert system, and >need some tips. > >I need more speed! The list's objective is this: To get the alert out >to all the subscribers in record speed. Actual subscribers cannot post >to the list, so it's just a distribution list really. In your list-name.config file there should be a line: # Put a precedence header with value into the outgoing # message. precedence = bulk I am not sure what the other options are but you may could try Priority or just comment the line out. This should/may cause the messages to spend less time in the queue. - ---------------------------------------------------------- - Jimmy Porter - - Internet Information Services Div. of: ComputerLogic, Inc. - jporter@computerlogic.com http://www.computerlogic.com - 912-474-5593 Ext 370 From list-managers-owner Wed Aug 5 12:45:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA21581; Wed, 5 Aug 1998 12:29:42 -0700 (PDT) Received: from monkman.org (cpu1787.adsl.bellglobal.com [206.47.37.18]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id MAA21574 for ; Wed, 5 Aug 1998 12:29:34 -0700 (PDT) Received: from george ([192.168.66.27]) by monkman.org (8.8.7/8.8.7) with SMTP id PAA15618 for ; Wed, 5 Aug 1998 15:28:36 -0400 (EDT) (envelope-from brian@monkman.org) Message-Id: <199808051928.PAA15618@monkman.org> From: "Brian Monkman" To: List-Managers@GreatCircle.COM Date: Wed, 5 Aug 1998 15:36:47 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fastest List? Reply-to: brian@monkman.org In-reply-to: <3F5678287D@polaris.umpi.maine.edu> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: list-managers-owner@GreatCircle.COM Precedence: bulk One possible bottle neck is the receiving mail relay. If you are running sendmail I think it spawns a single process to deliver a message regardless of the number of recipients. I have had the same sort of problem you are experiencing and while my mail is not as time critical as yours I wanted to figure out a workaround. What I did is send out a few test e-mails and ran a tail -f on the maillog file. By doing that I could tell what mail servers were delaying things. Doing it a number of times over the course of a few days eliminated - to some degree - temporary problems. What I then did was edit the list file and moved the offending e-mail addresses to the bottom of the file and I contacted the admins of the mail server. I know this isn't very technical but it did work for me. Probably not too helpful for a high volume, large subscriber list. Brian From list-managers-owner Wed Aug 5 17:31:00 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA24604; Wed, 5 Aug 1998 16:13:19 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA24596 for list-managers@greatcircle.com; Wed, 5 Aug 1998 16:13:14 -0700 (PDT) Received: from bigtime.blank.org (bigtime.blank.org [139.167.64.222]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id HAA04450 for ; Mon, 3 Aug 1998 07:50:39 -0700 (PDT) Received: (qmail 29140 invoked by uid 500); 3 Aug 1998 14:57:08 -0000 Message-ID: <19980803105708.I12173@blank.org> Date: Mon, 3 Aug 1998 10:57:08 -0400 From: "Nathan J. Mehl" To: Norbert Bollow , list-managers@GreatCircle.COM, Eric Thomas Subject: Re: Listserv's violation of RFC821 References: <18600.901841159@monkeys.com> <199807311728.TAA00282@quill> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: <199807311728.TAA00282@quill>; from Norbert Bollow on Fri, Jul 31, 1998 at 07:28:36PM +0200 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk In the immortal words of Norbert Bollow (nb@thinkcoach.com): > > I am surprised to see you leave the list-managers list in reaction > to Ron's criticism. He would hardly be the first to leave a list because rfg's presence rendered the signal-to-noise ratio untenable. List-managers would probably not be the first list it happened to, either. -n, who foolishly thought it was safe to come back after the _last_ rfg-centered pissfest. ------------------------------------------------------------ "Cyberterrorists may be difficult to capture in the act, but from what I know about people who are highly skilled with computers, they should be easy to beat up." (--The Onion) ------------------------------------------------ From list-managers-owner Wed Aug 5 17:45:52 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA24554; Wed, 5 Aug 1998 16:12:53 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA24544 for list-managers@greatcircle.com; Wed, 5 Aug 1998 16:12:50 -0700 (PDT) Received: from Thinkage.On.CA (thinkage.thinkage.on.ca [192.102.11.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id DAA00285 for ; Mon, 3 Aug 1998 03:57:09 -0700 (PDT) Received: from thinkage.on.ca (ppp1.thinkage.on.ca [192.102.11.31]) by Thinkage.On.CA (8.9.1/Thinkage980518-8.9.0) with ESMTP id HAA15265; Mon, 3 Aug 1998 07:03:17 -0400 (EDT) Message-ID: <35C598D7.64405974@thinkage.on.ca> Date: Mon, 03 Aug 1998 07:02:47 -0400 From: Ken X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Grant Neufeld CC: list-managers@GreatCircle.COM Subject: Re: The List- headers are now an RFC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Grant Neufeld wrote: > > This is a request for you to implement support for the List- header > fields defined in RFC2369. This will make mail list access easier for > your users. > List-Subscribe: Body=subscribe%20list-managers> i do subs/unsubs manually. and intend on keep doing so for my own reasons. how do i set the above header to say i require the following: your email address (because i dont believe headers work reliably enough) your human name (ie: firstname lastname, whatever) your contact phone number, including area/country codes and best time of day(including timezone info) also, i dont see the point of subscribe info, if the person is already a subscriber (by virtue of getting messages from me) oh okay, the rfc sez the user may want to resubscribe using an old copy of a message.... however on my list going away for temporary absences is done by requesting 'vacation status' not unsubscribing. for unsubscribing loses their posting-quota seniority. bring up the obvious thought: since i cant specify my unique "on vacation/suspend me for a while" ability in the headers, then placing a unsub header would encourage folks to use the *wrong behavior* for my lists... hmmmmmm... > List-Unsubscribe: Body=unsubscribe%20list-managers> how do i set the above to require the users unique PIN. --> ie: in general how do i tell those alleged automated conveniences i want information *specific to the user* rather than static string text? perhaps a generic prompt-get-answer syntax. oh well, i am the minority who doesnt use the prepackaged 'style' of list management. but i do wonder if others require user-specific info during regular admin functions... or *will* they be doing so as the future unfolds. many concepts i've implemented over the years got 'invented' by majordomo,etc 9 months later. quite often. -ken ps: no, my software is not packaged for public consumption. perhaps i should be evil and do so... thus making me less a minority :) From list-managers-owner Wed Aug 5 18:01:21 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA24816; Wed, 5 Aug 1998 16:15:14 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA24784 for list-managers@greatcircle.com; Wed, 5 Aug 1998 16:14:59 -0700 (PDT) Received: from mail.gcnet.com (mail.gcnet.com [206.252.184.11]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA29578 for ; Tue, 4 Aug 1998 08:35:37 -0700 (PDT) Received: from pop.gcnet.com (pop.gcnet.com [206.252.184.10]) by mail.gcnet.com (8.8.7/8.8.7) with SMTP id KAA23479; Tue, 4 Aug 1998 10:42:18 -0500 Date: Tue, 4 Aug 1998 10:42:18 -0500 (CDT) From: Chris Owen To: Tasos Kotsikonas cc: sales@emailsol.com, list-managers@GreatCircle.COM Subject: Re: Your Company's Press Releases (fwd) In-Reply-To: <35C712B0.F4DCE4BE@emailsol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Tue, 4 Aug 1998, Tasos Kotsikonas wrote: > Chris Owen wrote: > > > Are you related to this? We just blackholed the address and the > > enewsworks.net domain, but I'd hate to lose the listproc mailing list > > because banning the emailsol.com domain. > > Chris, this was a legitimate letter from our president. You've got to be kidding (I hope). You are condoning this blatent (and really, really indiscriminate, since half the addresses it was sent to don't even exist) spam? As a mailing list company you should be particularly sensitive to crap like this. This address was roboted off a web site and clearly was not solicited in any way. I love listproc (and have gone against the tide in not replacing it), love your work, and looked forward to the new product. However, if this is the type of company that is going to be releasing it, we definitely won't want to work with it. Chris > > ---------- Forwarded message ---------- > > Date: Mon, 3 Aug 1998 19:37:17 -0400 > > From: EWorks > > Reply-To: sales@emailsol.com > > To: sales@lists.hubris.net > > Cc: webmaster@lists.hubris.net, newsletter@lists.hubris.net, > > marketing@lists.hubris.net > > Subject: Your Company's Press Releases > > > > Hi; > > > > I just visited your web site and saw that you have your press releases > > on line. My company is about to release a software product that can > > automate your process of disseminating press releases and would > > dramatically enhance your customer relations. > > > > If you feel that your press release process is a critical function and > > potent marketing activity of your company then you will probably share > > these passions with other professionals in our field: > > > > o You don't want to depend on anyone to update your web site when > > an important press release needs to go out. > > > > o You have felt the pain of managing a growing list of editors and > > interested parties you want to distribute press releases to. > > > > o You realize that there will be times when your press release > > process is going to be under pressure to function rapidly and > > reliably. > > > > o You realize that if there were a way to efficiently manage the > > list of interested parties, that you could use your press > > releases as a vehicle to improve your customer and investor > > relations. > > > > o You are ready to aggressively deploy new internet technology to > > give you a competitive edge in your customer and investor > > relations. > > > > My company's new product, ENewsWorks, is a combination Web Server and > > Email List Management Program which can give your company the most > > advanced Press Release distribution capability in the world. Whenever > > your press release is ready, you simply submit it to ENewsWorks. > > ENewsWorks will then take that document and email out copies of it to > > everyone who is on the email distribution list. At the same time > > ENewsWorks will install that document into your Web site archive of > > press releases that it maintains and automatically update the index to > > those archives. > > > > What is revolutionary about ENewsWorks is the automated process that > > it embodies for distributing your press releases. You do not have to > > manage who gets your press releases because your interested editors, > > investors and customers can subscribe and unsubscribe themselves, and > > when each press release goes out it can automatically reach tens of > > thousands of people directly and simultaneously. You can use your > > press release process to build customer and investor loyalty. What is > > revolutionary about ENewsWorks is that it embodies both "Push" and > > "Pull" internet technology in one complete solution. On a individual > > basis, your investors and customers can opt to have you "Push" press > > releases to them by email, or "Pull" the information themselves by > > visiting your automatically updated, indexed and searchable web site > > archives. > > > > My vision is that ENewsWorks is the first of a new type of Internet > > application that will transform the very nature and function of Press > > Releases. Press Releases are poised to evolve from announcements made > > to broadcast media organizations into a direct communication between > > corporations and interested individuals (who will include > > representatives of the mass media). The internet and the systems > > embodied in ENewsWorks are the enabling technologies for this change. > > > > ENewsWorks Web Server Features: > > > > o Optional password protection allows you to control access to the > > Web Archives of past press releases. > > > > o Built-in search functionality allows your Web visitors to search > > your archive of press releases for phrases or keywords. > > > > o An index of Press Releases is automatically generated. Optional > > additional hierarchy into the Press Releases archive can be > > generated by time period of your choice: yearly, quarterly, > > monthly, etc. > > > > o Subscribers to your Press Release list can view and modify their > > preferences for how they receive your press releases. > > > > o The web site look and feel can be easily modified to match your > > corporate web site with selectable text color, text background, > > background image, your company logo image and your company > > banner image. > > > > ENewsWorks Email Features: > > > > o Your customers, editors and investors can specify how they want > > to receive your press releases. They can receive HTML or plain > > text versions by email, they can receive email notification with > > links only, or if you are generating a high volume of press > > releases, they can opt for compiled digests to be sent to them > > at regular intervals. > > > > o You can configure the email distribution list to be public or > > closed. > > > > o Public distribution lists can be subscribed, unsubscribed and > > configured by the public over your web site. You no longer need > > to manage the list of who gets your press releases, and because > > of this you can open it up to anyone who is interested, which > > will include important investors and customers. We have built > > in a process that assures that individuals can only subscribe > > and unsubscribe themselves: When a person subscribes to receive > > your press releases over the Web, they are automatically sent a > > confirmation to their email address which they have to respond > > to before their subscription goes into effect. > > > > o Closed Distribution lists can only be modified only by the > > people you designate to have Subscription Manager Privileges. > > Subscribers to these lists will not only get their press > > releases emailed to them, but they will also have password > > protected access to the archives over the Internet. > > > > You can read about the specifications of ENewsWorks, subscribe to our > > company press releases, subscribe to our company newsletter, or try > > out a running version of ENewsWorks by visiting our web site at: > > http://www.enewsworks.net > > > > You can email us at: sales@enewsworks.net. > > or call us at: (617) 868-9770 > > > > If you're interested in joining a community of industry professionals > > in your field, come join The Press Release Discussion List being > > hosted on our site at http://www.enewsworks.net. We also host the > > Corporate Newsletter Discussion List. > > > > I hope we can be of service to you. > > > > Sincerely, > > > > Robert Anue > > President, > > Email Solutions Inc. > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Lottery: A stupidity tax PO Box 1985 ~ owenc@gcnet.com Garden City, KS 67846 ~ http://www.gardencity.net/~owenc/ Voice: (316) 275-1900 ~ ftp://ftp.gardencity.net/pub/owenc/ Fax: (316) 275-0313 ~ 88 FA CF C6 65 23 63 C1 6E 80 AE 0B 51 C0 22 36 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From list-managers-owner Wed Aug 5 21:02:49 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA28352; Wed, 5 Aug 1998 20:42:24 -0700 (PDT) Received: from koobera.math.uic.edu (koobera.math.uic.edu [131.193.178.247]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id UAA28345 for ; Wed, 5 Aug 1998 20:42:10 -0700 (PDT) Received: (qmail 27571 invoked by uid 666); 6 Aug 1998 03:49:32 -0000 Date: 6 Aug 1998 03:49:32 -0000 Message-ID: <19980806034932.27569.qmail@cr.yp.to> Mail-Followup-To: list-managers@GreatCircle.COM From: "D. J. Bernstein" To: list-managers@GreatCircle.COM Subject: Re: The List- headers are now an RFC References: <35C598D7.64405974@thinkage.on.ca> Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Ken writes: > ie: in general how do i tell those alleged automated conveniences > i want information *specific to the user* Put the List-* fields into that user's confirmation message. It's up to the MUA to remember the latest List-* instructions for each mailing list. ---Dan Binary qmail distributions are allowed! http://pobox.com/~djb/qmail/dist.html From list-managers-owner Mon Aug 10 15:12:06 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA18736; Mon, 10 Aug 1998 14:10:03 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id OAA18723 for list-managers@greatcircle.com; Mon, 10 Aug 1998 14:09:58 -0700 (PDT) Received: from www.kimminau.org (dosgod.mi.org [207.158.154.4]) by honor.greatcircle.com (8.8.5/Honor-980202-1) wit