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

Aaron Falk falk at ISI.EDU
Wed Mar 31 08:56:14 PST 2004

The RFC Editor maintains a service for the retrieval of RFCs via email 
known as rfc-info.  Instructions for using this service can be found at 
http://www.isi.edu/in-notes/rfc-editor/rfc-info.help.  Before you start 
sending email to rfc-info at rfc-editor.org, you should be warned that you 
probably won't get a response, or at least not for a while.  The reason 
is that the automate retrieval system is totally clogged up with spam 
and worse, spam backscatter, because the mail address for this service 
appears in every RFC announcement and, so, is in the hands of many spam 
generators.  (As of this writing, there are 1200 messages pending 
processing, nearly all spam).

The service generates automated help responses which have the 
vulnerability that they tend to get in loops with other services that 
have automated responses.  (Once, a couple years ago, rfc-info got 
locked into a death-grip battle with the majordomo at ietf.org, each 
one trying vainly to give the other enough help -- by _appending_ it to 
the received message -- information to allow it to successfully 
complete its transaction.  Eventually, the server fell over when the 
log file grew to be 700MB.  We fixed this by manually blocking the 
source address 'majordomo'.  Unfortunately, there are many other 
automated services with other names.)

So, we have a service that doesn't work so well and would like some 
input from the community on what we might do about it.  Here are some 

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 

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.

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.

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.

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. :)

We're interested in opinions on these options, or other suggestions, as 
well as volunteers to help sort this out.  Beware, though, that most of 
this was written circa 1992 and has been tweaked and hacked since then, 
so it's not for the faint of heart.

Best regards,

--aaron (for the RFC Editor)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20040331/6d936bf3/PGP.bin

More information about the rfc-interest mailing list