nospam Email Address for Tin

This is a brief description of how to have your return email address modified on articles posted to Usenet through the Chebucto Community Net and associated VCN's. This modification replaces what is posted as your usual email address (i.e "ak219@chebucto.ns.ca") with one that has a "Spam Catcher" in it, (in this case "ak219nospam@chebucto.ns.ca"). The idea being that automated email grabbing software used by advertisers to generate lists of email addresses will grab an invalid email address instead of your actual address.

Technical Assumptions:

• I am assuming you are familiar with Unix Environment Variables.
• I am assuming you realize what Usenet is.
• I am assuming you read and post to news discussion groups.
• I am assuming you can find ccn.tech-talk.

Instructions:

This feature requires the existance of the file "$HOME/.tin/munge" in order to be activated. When you run tin, the script you run will check for the existance of this file, and if there, munge your email address (as described in the Premise).

To create this file you will need to:

1. Goto your "$HOME/.tin" directory: (you can type "gfile:///~/.tin" to do this).
2. Create a new file named "munge".

This only need be done once; the script will check for this file each time you enter tin. To disable the email replacement, you can simply remove this file and your address will not be munged.

Limitations:

This simple feature is not without limitations. Here are a couple obvious ones:

• A very simple AI algorithm can detect the "nospam" in an email address as an obvious attempt at slightly adjusting the return address to avoid spam. This is certainly not the definitive anonymizer for usenet posting. :)
• The user must be responsible for providing instructions to readers to contact them, should the poster so choose. Any reply to the munged email address may or may not* generate an error indicating that it was an invalid address.
  * See Related Comments below

Technical Discussion:

The technical details of this feature are simple and are contained in a single if statement.

if [ -f "$HOME/.tin/munge" ]
then
  echo "Munging return email address."
  USER="$USER"nospam ; export USER
fi

For those of you who are not familiar with the Bourne Shell, this has the following pseudo code equivalent.

If the file "$HOME/.tin/munge" exists
	Put a small message on the screen indicating what we're doing.
	Add a "nospam" postfix to the user's USER enivonment variable.
End of if statement.

Now the difficulty here is not understanding the code itself, but why it works so well. By exporting the USER environment variable, the environment after leaving tin should retain the modified value. However, experiments have shown me that it does not. The USER value appeared to "reset" to it's proper value.

The reason is this (and it's somewhat obvious when you think about it). When lynx runs a lynxprog: command, it does something similar to a fork and the child process exec's the lynxprog: script. The script itself in turn exec's the program, (in this case "tin") which runs until completion. At that time however, the process finishes (because of the exec's, which, as you will remember, replace the current process in memory, instead of spawning a new one). This means that the modified USER variable is lost and when the original parent takes control back, the environment appears to be "reset" to normal when in actuality, it was never changed. All the changes occured on a different "shell".

Disclaimer:

I want to make clear what my position is on this feature. While I do not expect to have any problems from it, or expect any other users to either, I want to refine my position on "Advanced User Features". Should I implement any more, some may require that I make my opinion clear before they are used.

• There is no support for this feature. The HelpDesk Team is (as far as I'm concerned) not required to try assist users who experience problems deriving from using this.
• I will not provide assistance in setting this up. It is a very basic proceedure and one which is meant for "Advanced Users".
• I will not respond to discussions over email about this particular feature, please use the ccn.tech-talk forum for comments and questions.
• Remember that you, (as the poster) are responsible for ensuring that other readers know how to contact you, should you want to receive replies to your post.

Related Comments:

If not already done so, we will probably be configuring out mail server to disregard all mail where the user name has a "nospam" postfix. This mean that no errors will be generated, no reply sent. All mail destined for "usernospam" (e.g. mail for ak219nospam@chebucto.ns.ca) will be redirected to the nearest convienient bit bucket. Please be aware of this.

Due Credit:

Brandon Hume mentioned (in ccn.tech-talk) that tin used the $USER variable as the username in the return email address. I had forgotten this, but with the reminder and a spare 15 minutes, I implemented this little feature. I hope that the "nospam" tricks a spammer for you, and I hope you learned something from the Technical Discussion.

James Fifield
CCN Technical Gremlin @ Large
May 7, 1998.