Re: Speaking of the Great Subject War?

[Valdis Klētnieks <valdis.kletnieks () VT EDU>]

On Thu, 15 Aug 2019 02:32:09 -0000, Scott Norton said:
> Has anyone come across vendors that are starting to provide tooling or
> functionality to start stripping the proliferation of warnings and such from
> subjects?

On a technical level, If you want to collapse a set of run-away Re: headers,
all that's needed is the ability to do textual substitution.  The devil is in
the details, as a simple regular expression isn't good enough...

The problem is that the regular expression gets very ugly very fast.  You would
*think* that a simple s/Re: (.*) Re: \1/Re: \1/ would work, but noooo..  Let's
look at the Re:'s in the subject line causing the kerfluffle, in order:

Re: [SECURITY] [Ext]
Re: [SECURITY] [EXTERNAL]
Re: [SECURITY]  [EXTERNAL]
Re: [SECURITY] [External] [SECURITY] Duo

We've got 4 different 'external' tags - spelled out/abbreviated, upper/lower
case, and with a different number of blanks. And *of course*, they ended up in
the almost worst possible order for a regexp - only way to make it worse is if
'[Ext]' was on one of the middle ones, or if people had been more inconsistent
in whether they put 'external' in front of or behind 'security'...

To quote Jamie Zawinski:  "Some people, when confronted with a problem, think
"I know, I'll use regular expressions." Now they have two problems".  This isn't a
problem that can be solved at the regular expression level - more understanding
is needed than just textual matching.

Heck, 'Re: Fwd: Re: Fwd: Re: Re:' still happens. This must be harder than it looks :)

> It really seems to me as a matter of etiquette institutions should be cleaning
> up the mess they make before sending their users emails back out.

Well, that simplifies things somewhat- if you know you added something, you
know the format of what you added and can strip it out more easily.  However -
if you are in the habit of adding [EXTERNAL], you have two problems:  1) Do you
add it if the Subject: already contains it? 2) Do you remove it on outbound if
it arrived with one already and it isn't one you added?

> Although I have not seen any substantive work to persuade me of the efficacy of
> the whole �[external]� thing when in sustained use, I do have need to trigger
> IRM based on a user input such as �[Do Not Forward]�.

In general, not really a solvable problem.  Consider that the next text after this
paragraph was the Educause footer:

> Replies to EDUCAUSE Community Group emails are sent to the entire community
> list. If you want to reply only to the person who sent the message, copy and
> paste their email address and forward the email reply.

Yeah.  Copy/Paste. People want to forward something hard enough, they'll find a way.

There's also a deeper problem here.  If the information is sensitive enough that
forwarding it could be a problem, *why is it not encrypted so only the recipient
can read it*, and thus *has* to resort to the copy/paste method to pass it on?

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Attachment: _bin
Description: