On Aug 3, 14:35, Eric Thomas wrote:
} Subject: Re: SCIFAQ errors
} On Tue, 3 Aug 1993 10:56:24 -0800 "Michael C. Berch" <[log in to unmask]>
} said:
}
} >1. Make it possible for the list owner to disable the duplicate
} >suppression code. (Is there some reason this can't be done?) In a
} >moderated newsgroup/list, all postings will some from the same origin (a
} >moderator or gateway site), so mail loops are not likely.
} Mail loops are not the problem. The problem is that mailers sometimes get
} crazy and send 200 copies of the same message to the list. And there are
} time window problems that make it possible for a message to be delivered
} twice if the line fails just at the wrong time, too. You can disable this
} code, but don't complain if some day the 500 people on your list each get
} 200 copies of the same message.
But what's the sense of sending the 200 copies to the originator instead?
They're unlikely to have been the originator's fault either.
} >2. Have the duplicate suppression code use a settable timeout -- mail
} >loops tend to occur within a day or two if at all, but FAQs are rarely
} >posted even as often as weekly. Tuning this parameter should provide
} >protection against duplicates while allowing unchanged periodic postings
} >like FAQs.
} You can control the amount of messages the duplicate checker recognizes.
} By default, this is 50. But the best solution seems to be adding a time
} stamp to the FAQ file automatically. This will be useful to subscribers
} in countries where everything has to go through a 9.6k link because there
} is no money for more bandwidth, as larger messages (such as FAQ's) tend
} to be queued after small ones.
By insisting on adding a date-based bit to the body of the message,
it becomes impossible for you to tell that there's no need to send the
message because was a duplicate of what was sent yesterday. Ie: being
able to tell your gateway "send only stuff that's not been duplicated
in n days".
This doesn't help with anything other than FAQs. There are other more
general news-to-list gateways. If a news site regurgitates an ordinary
USENET article, or, indeed, the news-2-mail gateway does, the originator
of the posting is going to get deluged anyways. Why? It wasn't *his*
fault. There are MANY USENET newsgroups that, by the simple expedient
of posting a message, you get numerous bounces from all over the place.
Some of them listservs. Some of them broken Mac software (PostalUnion
anyone?), some of them mail feeds to people who don't exist any longer,
some of them from idiotic vacation programs. As the network gets larger,
this is only going to get worse. It's time we start doing something about
this, even if we do have to crack open RFC822 or 1036 or whatever.
[I should point out that the USENET RFC, is currently being revised.
Now is a good time to mention this!]
Adding a timestamp is purely a kludge - why should everyone have to compensate
for inadequate software?
Ideally, LISTSERV should be able to tell when a message comes from USENET
or some other "broadcast" media like another LISTSERV, and simply silently
drop "too-soon" duplicates.
In some cases, where you have some control over the news->mail portion of
the gateway, you could insert a header (Sender: or X-Gatewayed: or
something) and have LISTSERV trigger on that.
Frankly, I think the duplicate acknowledge is rather silly anyways.
If the message got through the first time, there's no particular need
to tell the originator about the subsequent duplicates. Just drop
the durn thing. If there were duplicates, it's unlikely to have been
the originator's fault, and unlikely to be something that the originator
can do anything about.
May I suggest some parameterization? A "DuplicateAck" parameter that
can be set to "none" or "list-owner". This allows the list owner to
either silently discard duplicates, or only receive the bounce him/herself.
I'm not suggesting a "originator" value, because it is almost never
useful, and usually a major annoyance.
--
Chris Lewis; [log in to unmask]; Phone: Canada 613 832-0541
Psroff 3.0 info: [log in to unmask]
Ferret list: [log in to unmask]
|
