[rfc-i] rfc-info needs your help!

[Henrik Levkowetz]

Hi Aaron,

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 
> rfc-info.

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.

	Henrik