[rfc-i] rfc-info needs your help!
housley at vigilsec.com
Wed Mar 31 09:51:51 PST 2004
It would be interesting to see if Spam Assasin and Virus Scanning would
eliminate enough of the bogus message traffic. This could probably be done
If that is not sufficient, then it is probably not worth much more effort
to preserve the service.
At 08:56 AM 3/31/2004 -0800, Aaron Falk wrote:
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.
--aaron (for the RFC Editor)
More information about the rfc-interest