tneff@bfmny0.UU.NET (Tom Neff) (12/28/89)
Chip Rosenthal recently posted an 'undigestifier' to comp.sources.misc: it takes 'digest' articles (e.g., mail list gateway digests) and breaks them up into individual news articles for feeding to 'inews -h'. There have been other such posted in the past, also. I know Chip means well, and that under appropriately rigid control this can be a useful tool. But the overall effect on the net is pernicious, because *DISTRIBUTION* of the broken-up digest articles is left up to the discretion of each undigestifying site. Unless distribution is forced 'local', the effect of running an undigestifier on a core Usenet newsgroup article in digest format is to inflict a maze of twisty little reposts, all alike, on the rest of the net. All of the Message ID's will be new, so the history file check in B/C news will be of no avail in weeding out the clones. Depending on the time lag of the digest, the MIRV'd articles may disappear during the nightly expire, but probably not before being passed along to neighboring sites. For a given digest, there will be as many MIRV events as there are unprotected undigestifiers running. Given the size of Usenet this could be awesome should programs like Chip's attain widespread popularity. Unprotected undigestifiers could easily lurk for some time on sites where digest articles are not normally seen in most groups received. A 'stray digest' months later could spawn hundreds of unwanted articles. Lest folks suspect I'm being unrealistically alarmist here, exactly this happened in rec.photo a few weeks ago. Someone posted a digest they'd been saving on 3D cameras, and >BOOM<! we were cleaning little twisty sub-postings out of the newsgroup for days afterward, from the half dozen or so sites already running SOMEONE'S undigestifier. At the very least, existing 'undigestify' sources should be patched to force 'Distribution: local' as a default, so that people who don't understand what they're doing don't hurt the rest of us. -- "Nature loves a vacuum. Digital \O@/ Tom Neff doesn't." -- DEC sales letter /@O\ tneff@bfmny0.UU.NET
chip@chinacat.Lonestar.ORG (Chip Rosenthal) (12/30/89)
In article <15037@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Chip Rosenthal recently posted an 'undigestifier' to comp.sources.misc [...] >I know Chip means well, and that under appropriately rigid control this >can be a useful tool. But the overall effect on the net is pernicious, >because *DISTRIBUTION* of the broken-up digest articles is left up to >the discretion of each undigestifying site. I'll cede this point and possibly I didn't consider it strongly enough when posting, but I don't think the problem is quite as extreme as suggested. I'll mention why not in a moment, but right at the start I'll say that the workaround would be to place the line: HDR_ADD Distribution local in the definitions file (or use a newsgroup which is only distributed locally). Realistically, if somebody should install this thing, say on comp.risks, and direct postings to the net, I don't think there will be a major meltdown. First off, "brkdig" is pretty picky about checking the digest format, and dying with complaints when discrepancies are found. So you wouldn't run into a situation where, for example, two sites were bouncing each others postings back into the net. Worst case, I expect that isolated sites will occasionally munch up and spit out a digest. This will probably happen only once, due to the usually efficiency of flame generation on the net! Second, I think the configuration file, a readable text file, is simple enough such that drastic mistakes which cause this sort of problem will be reduced. Finally, I don't know if the risk from "brkdig" is nearly as great as some of the other things out there which hiccup from time to time. Most notable are some of the gateways such as notes->usenet and fido->usenet. There things become aggravating from time to time, but they haven't brought the net to it's knees. At least with "brkdig", you still have accountability because it goes through inews and there provides a "Sender" line. I don't follow rec.photo, so I don't know about the incident there. I'm not sure if such a problem would be created by "brkdig". I would tend to think not. The offending sysadmin would be innundated with messages like: couldn't locate end of digest header ABORTING - please process digest manually from all of the non-digest messages. It's hard to forget that such a thing is there. I think "brkdig" is a useful tool. I'm not sorry I posted it. But in retrospect, maybe a word of caution and a safer example configuration might have been warranted.