Bring back the Unicode discussion

From: Tex Texin (texin@bedford.progress.COM)
Date: Wed Jul 16 1997 - 16:24:49 EDT

I changed the subject from "Re: Bring back the return address" to
"Bring back the Unicode discussion".

We can't get people to send subscribe and unsubscribe messages to the
right place, so I find it hard to believe the suggestion below would

I was able to cope with the maillist as it was before, and I can cope
with it as it is now. Workarounds have been suggested for the problems
raised by the change.
Changing, or not changing, would have caused discomfort for some. Let's
move on and get back to Unicode issues.

On Jul 16, 12:17pm, Glen Perkins wrote:
> Subject: Re: Bring back the return address
> Peck, Jon wrote:
> >
> > I liked it better the old way too, as my mail system has a filtering
> > scheme that allowed me to put automatically the Unicode mail into a
> > folder. Now I can't do that, since the rules engine doesn't see the
> > entire header.
> >
> and Steve Bossie wrote:
> >
> > I agree. I also use a filter that worked nicely before but now >
> >
> Yes, this brings me back to an idea I have for smarter email. It would
> solve this problem, mostly solve the problem of spam, and give users a
> lot more control over their email.
> I'd like to see an email server protocol that gave mail clients a
> standard way to maintain a list of valid "access keywords" on the mail
> server. (Thanks to Harald Alvestrand for suggesting that this could
> use of the "+convention" in email names.)
> It would work this way. Email addresses would use "+" extensions, such
> as "", where the access keyword is
> "rosebud". Email clients would have the power to maintain a list on the
> server of which +extensions were to be considered valid. Messages sent
> to the address with a valid extension would be accepted. Those with an
> invalid extension would be returned as undeliverable. The user could
> decide whether the case of "no extension" would be considered a valid
> invalid extension. Any desired change to the list of valid extensions
> could be made by the user himself in the mail client, and it would be
> sent to the user's mail server via a standard protocol, where the
> would implement the change.
> For example, I could post a question to,
> telling my news client to use the access keyword "rosebud" It would
> my article with the reply-to: set to
> "". I would go to my List of Access
> Keywords in my mail client's, or news client's, preferences/settings
> dialog and add a new keyword "rosebud" to my list of valid extensions.
> would also put a checkmark in the checkbox that said something like
> "automatically expire after..." and fill in "2 weeks". When I hit the
> "OK" button, the "rosebud" extension would be sent to the server, where
> it would be added to my list.
> There would be no need to discuss this with the system admin. The
> control of access keywords would be in the hands of the user (who could
> use it or just leave everything at the default settings.)
> For the following two weeks, anybody who sent mail to me using
> "" would have their mail accepted.
> After the two weeks timed out, my mail client, remembering its
> instructions for this keyword, would send another message to the server
> asking that "rosebud" be removed from the list of valid access
> Simple as that. From that point on, anyone who sent a message to
> "" would have their message bounced
> back as undeliverable. After two weeks, after all, most responses would
> be from spammers, but the timing would be entirely up to me. I could
> leave "rosebud" active as long as I wanted and manually remove it when
> didn't think it was worth having any longer.
> Each time I posted something publicly, I could use a different
> time-limited access keyword. The spammers' databases would fill up with
> useless mailing addresses because most people would be likely to time
> out any extension used in a public posting. I know people who keep
> changing email addresses after they attract too much spam, or they have
> a "public" email address and one or more "private" email addresses.
> always requires the assistance of the sysadmin, which sometimes costs
> money. My proposal would eliminate the need for this, and put the power
> of access control into the users' hands directly.
> The mail client would then, of course, use these access keywords to
> the mail. The advantages over the current "sort by From: or Sender: or
> Reply-to: or Subject:" methods include being able to sort people's mail
> on the basis of who they are to you, not what there current email
> address is, and not having to convince a list maintainer to "do things
> my way" with the headers.
> The way it would solve the Unicode mailing list dilemma is that you
> would subscribe to the mailing list using an access keyword you, the
> user, chose to mark mail from that list. I could sign up for the
> list, for example, and tell it that my email address was
> "". Then, it wouldn't matter what
> the headers were in the message, except for the "To:" header, of
> which the subscriber could completely control.
> You could create access keywords for your family members, for close
> friends, put a general business keyword on your biz cards, etc., and
> your mail would be sorted accordingly. You wouldn't have to keep a
> database of all the return addresses of everyone you'd ever given your
> card to (and maintain it as they changed jobs) in order to correctly
> sort messages from them. Anyone whose mail you wanted instantly
> delivered to you could be given a "better keyword". You could change
> those keywords any time you wanted, without having to ask the sysadmin
> to do it for you. Mail from your spouse marked "urgent" could interrupt
> you in the middle of a meeting, no matter what account it was sent
> and if somebody else somehow got hold of that keyword, you could
> change it, like changing the locks on your house with the click of a
> mouse.
> Since "no extension" was just one of the extensions, you could also
> choose whether you wanted mail with no access keyword to be bounced
> by the server as undeliverable (which eventually gets it off the spam
> lists) or whether you wanted it let through. Your email client could
> them put it in a "general delivery" box that you could skim through
> every few weeks, in case an old friend was trying to contact you. You'd
> make that choice by clicking a checkbox in the "Preferences..." on your
> client, so you could change your mind any time.
> Some people are already using the "+ convention" to their advantage,
> this is a very small percentage of the market and almost requires that
> you run your own mail server to do it, because it's not controllable
> from the client. It seems to me that if a standard protocol for access
> keyword-based acceptance or rejection of mail, and maintenance of the
> list by clients were introduced, it would be a big hit. People are sick
> to death of spam, tired of worrying about the consequences of publicly
> posting their email address when they really have questions they'd like
> to ask, looking for ways to sort their business mail without
> long lists of addresses (that frequently change), and annoyed by issues
> of how to get list administrators to do things "their way" so that they
> aren't overwhelmed by their email.
> This scheme wouldn't replace the current sorting methods, it would just
> be a great additional method that included access control as well as
> allowing useful sorting based on the "To:" header.
> Anyone who finds this suggestion interesting and enjoys the process of
> formal standards proposals is more than welcome to take it, modify it,
> claim all credit for it, or do whatever else it takes to make it, or
> some superior version of it, a reality.
> __Glen__
>-- End of excerpt from Glen Perkins

Tex Texin                    
International Development Mgr.   Fax:   +1-617-280-4949
Progress Software Corp.        Voice:   +1-617-280-4271
14 Oak Park           
Bedford, MA 01730  USA
11th International Unicode Conference: Sept. 3-5, San Jose!

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:35 EDT