On 06-May-98 Hubert Mantel wrote:
On Tue, 5 May 1998, Braden N. McDaniel wrote:
Would refusing non-subscriber submissions curb this at all?
Yes, but this would cause other problems: Several people are posting from another account than they subscribed, so this would become impossible.
Agreed! I co-run a list where for "political" reasons we have to impose this constraint. We regularly have to rescue people who find themselves unable to post (usually because their local sysadmins have altered their email alias or the like -- why DO these guys keep moving the furniture around?). Not a reasonable option for an "ordinary" list (unless you get heavy spam).
Yeah, I know this isn't you guys' fault--but nonetheless, it's gotten rather ridiculous. I seem still to be receiving the backed-up notifications even now.
Yes, it's bad. But there are not only mails in our queue but also at surf.be
I've known much worse -- remembering one night when the Linux-Development-Apps (IIRC) digest got into a loop with a screwed site in Australia which sent the whole digest (about 200K in the first instance) back to the digestifier which then ... (in ever-larger copies)! My local Univ mailhost then normally had about 20MB free space on /var/spool/mail which soon filled up with this stuff. After unsubscribing from the digest I then sat up until about 4am deleting further copies until the backlog was cleared. The digest manager later wrote to me that his own mail spool filled with over 100MB until his server folded under the weight. On a practical note: suse-linux is served by majordomo, and I don't know if MD has the facility: but the above "political" list runs on LISTSERV which can be set to detect the presence of the list address occurring later in the message, resulting in the message then being returned to the originating site as a "possible mailloop", and it doesn't get sent to the list. This has its own problems (if a user's mailer incorrectly quotes headers in the included message-copy in a reply, then the same happens -- which is not what the replier intended, but since they shouldn't do that in the first place it's only right that it should bounce back to them so that they can get it put right at their end). This resource is very effective at detecting attempts to send a message back to the list. It also means that such cases can be forwarded to the postmaster at the offending site, which is where they should end up: let the manager of the bad site get a full mailbox, instead of everybody else. However, I noticed that someone's attempt to cc: to postmaster@surf.be also got bounced on the grounds that it couldn't be delivered to that address either, even though the bounce was apparently sent back by "postmaster@surf.be". That is some mean site ... On another practical note: All you guys who mailed to the list while this was in full swing only made the problem worse since all your messages joined the mail-loop stream! Mail-loops are rare, but when they occur it is a VERY unstable situation. Correct action is inaction: good-humouredly, do nothing; and wait for the managers to clear it up. If (as in the case I described above) you feel you HAVE to unsubscribe, then take care to send your command to the admin service of the list (in this case majordomo@suse.com, as appended to all the suse-linux mails ... ). Even then, it may be some time before the backlog runs dry. Remember that even list managers sometimes sleep: disasters can build up unnoticed overnight (in some other timezone than your own ... ). Detection and correction may take a little time. A mail-loop is almost always arises through someone else's fault, so don't blast off blame to the wrong address. Best wishes to all, and thanks to Bodo Bauer and colleagues for breaking the loop. Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Date: 06-May-98 Time: 12:40:45 -------------------------------------------------------------------- -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e