MarkMail access to IP list archives --- a challange

[David Farber <dave () farber net>]

Begin forwarded message:

From: Dave Crocker <dcrocker () bbiw net>
Date: August 17, 2008 3:11:35 PM EDT
To: David Farber <dave () farber net>
Cc: "Tim O'Reilly" <tim () oreilly com>, Stewart Baker <stewart.baker () gmail com 
>
Subject: Re: [IP] MarkMail access to IP list archives

David Farber wrote:
> All on travel etc get returned to Stew. That vio;ates IP privacy
>
> From: Stew
>
> Dave,
>
> I sent this to you, but from the volume of "out of office" messages
> I'm getting back, I suspect that it was treated as a reply all.
> That's the first time that's happened to me.  It's no big deal to me,
> but it does disclose some of the recipients of your valuable emails,
> so you may want to see what happened.
>
> Stewart



Dave,

This is a toughie.

If the original author is shown in the rfc2822.From field, then yes,  
various automated responses will go to them.

There are two different reactions one can choose to have to this:

  1) The automated responses are configured by the owners of the  
responding systems.  If they disclose their existence, that's their  
choice.  In other words, the privacy issues are the same as if the  
human who owns the responder did a manual reply.  I assume you have no  
problem with a recipient consciously and manually replying to the  
original author.

  2) Recipients do not know enough about, or do not have enough  
actual control over, their email software.  So an automated response  
really constitutes a violation of privacy and the mediating publisher  
needs to take (extra) steps to prevent disclosures that are not  
explicitly the result of direct human action.

Much of the mess of Internet Mail comes from trying to fix systemic  
problems with local hacks.  As a consequence, my own view is that #1  
should apply, since I view #2 as really being a hack around  
unfortunate vacation software.  But I certainly see the legitimacy of  
a view which views privacy protection of the recipient list as so  
important, pragmatics have to win out over efforts to clean up the  
system.

I note that old and new IP messages do not set the rfc2822.Sender  
field.  It's possible some of the auto-responding software would use  
it, in preference to the From: address, but I can't say I'm all that  
hopeful. In general, vacation programs and are not consistent in their  
behavior, and they certainly are not designed with a concern about  
privacy.

Ultimately, that means that the goal of preventing an original author  
from seeing any final recipient addresses requires keeping the  
original author address out of any of the standardized rfc2822 address  
header fields in the IP message.  Hence, subscribers to IP are  
prevented from seeing the actual author's name in the From field.

Personally, I really prefer seeing the author's name.  And I really  
prefer being able to do a direct reply to them, although of course it  
should be equally easy to include you (ie, the IP admin) in the  
reply.  But, then, I'm not personally all that hung up about this  
particular privacy issue.  (I'm expressing a personal preference, not  
a judgment about others' preferences.)

There are only three paths I can think of to resolve this:


1.  Simple Standardized:  Send messages to IP with yourself as the  
author, and affix the forwarded message as a MIME attachment.  
(Thunderbird gives you this choice.)  This preserves all of the  
original message's structured identification information, but buries  
it inside a MIME attachment.  Recipients will see Farber as the  
author, but analysis software can be expected to find the embedded  
message and process its structured information, since the structure is  
standardized. Mail software typically can show the attachment as if it  
were inline; so there is no special effort to see the contents.  They  
also will usually allow 'opening' the attachment with a click, which  
then enables direct replying.

(The long-standing IP approach is to embed the message inline, but  
with no MIME demarcation.  Hence analysis software would need  
heuristics to find the embedded message.  Yuck.)


2.  Author hack: Send messages to IP with all of the original  
messages' headers preserved EXCEPT to replace the author's email  
address with IP's.  So the author Display Name is preserved but the  
email address is IP's.  The Display Name will show nicely for  
recipients, but all replies will go to IP.  While this has a bit of  
prettiness, I would expect serious follow-on problems for recipients  
actually trying to contact the original author.  Once can imagine  
further hacks, but my own experience is that layered hacking falls  
under its own weight.


3.  Subject hack: Put the original author's name as part of the  
subject line, such as:

 Subject: [IP] Stewart Baker - Re: Searching a laptop not same as  
searching...

This format will defeat threading mechanisms, since the Subject line  
for each message in the thread will be different.  But then, IP has  
never been all that thread-friendly, so I'm not sure how terrible this  
would be.

You could combine this method with #1, so that the the original  
message is preserved in a structured and standardized manner.

Hmmm.  I suppose #2, the Author Hack, could be used only for the From:  
field while doing #1 for the actual original message.  That shows the  
original Author's display name, causes automated replies to go to IP  
admin, and retains the structured message benefits for analysis and  
replying.  On reflection, I vote for this, since it's still only a one- 
level hack...


All in all, the requirement that a participant in a group exchange be  
excluded from received any automated replies sent by final recipients  
is certainly challenging, if the other display and user commands are  
to be preserved.

d/




--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com