MHonArc: Anti-Spam Measures (RFC)

1999-06-10 17:15:11
MHonArc Users,

Several MHonArc users have posted concerns about address harvesting
of their archives and what can be done to prevent user addresses from
getting harvested.  Some users have been able to use some MHonArc resources
to reformat pages to not show any addresses.  However, there is still
potential of addresses being exposed unless one knows some certain details
of MHonArc does.

For the next release, I am attempting to make modifications to make
address harvesting not a problem for those concerned.  By default,
MHonArc will do, or support, the following (regardless of resource

    o   The "<!--X-From: ... -->" comment at the beginning of message
        pages will now be "<!--X-From-R13: ... -->" where the value
        will have been passed through a slight variation of ROT13 to
        prevent the address listed from being harvestable.  Note, the
        mha-dbrecover utility will be modified to know how to read
        "<!--X-From-R13: ... -->" and it will also know about
        "<!--X-From: ... -->" for older pages.
        [* Feature implemented in development version *]

    o   Support for $FROMADDRNAME$ and $FROMADDRDOMAIN$, as mentioned in
        earlier posts.  This is to provide archive admins the ability
        to provide custom mail URLs/links without passing having the
        address in a form that is harvestable.
        [* Feature implemented in development version *]

Now, the above is not enough to avoid address harvesting, but are essential
in a complete solution.  In addition to the above, I am currently planning
(with some implementation already done) to have a SPAMMODE resource.  If
active, MHonArc will do the following:

    o   Addresses in message headers and what looks like addresses in
        message bodies will be modified so they are not valid "real"
        addresses but still useable by people.  For example, the
        address "someuser(_at_)corp(_dot_)foo(_dot_)com" will become
        "someuser(_at_)corp(_dot_)BogusPart(_dot_)foo(_dot_)com" (or something 
similiar --
        suggestions welcome).  This will allow user to still have the
        ability to respond to an address by just removing the "BogusPart".
        [* Feature implemented in development version *]

        Note, I did play with the idea of really obscuring the address.
        For example: someuser(_at_)corp(_dot_)foo(_dot_)com -> 
        But I think it would be nice that the addresses are still usable
        by humans.  Thoughts?

        The modification of addresses in converted message bodies is
        done on the final filtered data.  I.e.  The modifications are
        done after the various MIMEFILTERS have already done their
        job.  This is to avoid dependencies on all the filters and
        to avoid the need to pass options to all applicable filters.

    o   The "<LINK REV="made" HREF="mailto:...";>" will not show up
        in message pages.  I.e. The default MSGPGBEGIN resource will
        not include the <LINK> tag if SPAMMODE is on.
        [* Feature implemented in development version *]

    o   The main index listing will only use $FROMNAME$ instead of
        $FROM$ by default.  I.e.  LITEMPLATE will have the default value
        if SPAMMODE is active:

            <UL><LI><EM>From</EM>: $FROMNAME$</LI></UL>

        [* Feature *NOT YET* implemented in development version *]

My goal is to have "mhonarc -spammode ..." provide reasonable protection
from address harverters without the need for the user to do anything else.

I welcome comments on any of the above,


<Prev in Thread] Current Thread [Next in Thread>