[rfc-i] rfc-info needs your help!
henrik at levkowetz.com
Wed Mar 31 11:39:59 PST 2004
Wednesday 31 March 2004, Aaron Falk wrote:
> 1. Use a tool like SpamAssassin to reduce the assault on the inbox.
> This is an obvious improvement, if not a solution, but is challenging
> for several reasons. The rfc-info service is over 12 years old and
> currently runs on an old OS (SunOS 4.1.4) that is marginally supported
> by our IT department. For example, the app is built on perl 4.0 and
> the system doesn't have procmail. Moving it to another platform could
> be quite painful as more modern versions of the OS & apps may break
It seems to me that the easiest way of keeping the current application
and adding Spamassassin (or Dspam) would be to run the spam filter on a
separate box before sending the mails on to the old SunOS box, rather
than moving the application to a new box.
> 2. Find and integrate a more modern email-based document retrieval
> system. I.e., start from scratch with another app. Suggestions for
> candidate apps would be welcome. This may be the path of least pain,
> if such a replacement application is available.
Hmm. Might be possible. I'm checking up some leads.
> 3. Drop the service all together. Let people use the RFC Editor web
> and ftp services to retrieve documents. This seems undesirable as the
> service does get used and there are places where web access is limited.
> We'd strongly like to preserve email as a method of retrieving RFCs.
Not personally sure it's worth the effort, but fair enough.
> 4. Use scripts to purge all backed up messages when backups grow beyond
> a certain level. This is about what we're doing now (except without
> the scripts). The problem here is that valid messages get discarded
> along with spam during the purge/reset. This solution is crude,
> somewhat effective, and ultimately, makes an unreliable service.
Stopgap, not a solution.
> 5. Modify rfc-info so that it silently discards messages it doesn't
> understand. This may be the most elegant solution but requires an
> understanding of Perl beyond mine. :)
It's probably just as easy to put together a new implementation of the
service with the state of the code you indicate.
So in summary, I'd suggest 1. above, with filtering on a second machine
as a short-term solution, and possibly 2. as a longer-term one. I'll
check on some options for that.
More information about the rfc-interest