the NoCeMs get processed before the spam is received, but I'm not entirely sure what INN does when it receives a cancel for an article that does not exist in the history file.
Thus spake Jesse Rehmer <jesse.rehmer@blueworldhosting.com>
the NoCeMs get processed before the spam is received, but I'm not entirely >> sure what INN does when it receives a cancel for an article that does not
exist in the history file.
"ctlinnd cancel" will add an entry to the history file listing the storage token as /dev/null. If a spam article arrives after the NoCeM message
for the same article, it is rejected as duplicate. I'm running separate transit and reader servers (the Google filter is running on the transit server) and had the opportunity to verify this behaviour using INN 2.8 Current and CNFS storage.
"ctlinnd cancel" will add an entry to the history file listing the storage >> token as /dev/null. If a spam article arrives after the NoCeM messageDoes the null storage token stay in the history database forever, or is it eventually removed with expire operations after the remember time?
for the same article, it is rejected as duplicate. I'm running separate
transit and reader servers (the Google filter is running on the transit
server) and had the opportunity to verify this behaviour using INN 2.8
Current and CNFS storage.
I see reference in old Diablo documentation about configuring two feeds to downstream INN servers, one to send cancels, and the second feed to send everything else, but the second feed is delayed so that the cancels can be processed before the cancelled articles arrive from the delayed feed.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 135:40:25 |
Calls: | 6,857 |
Files: | 12,360 |
Messages: | 5,418,494 |