[ale]OT It begins...

[Jim Popovitch]

Robert, 

While all of your points are valid.. they do underline the complexity
and requirements necessary to pull something like that off.  Yet, all it
would take to thwart this is one newbie member (or someone like me who
doesn't care :) to reply with an email address in the body of an email. 
Just one.  

I don't think anyone will find one sizable, archived, public mailinglist
that has solved this probem.  If you do, please post the URL to their
archive, I would be interested in seeing it.

Thanks,

-Jim P.

On Tue, 2004-01-27 at 12:32, Robert Reese wrote:
> On 1/27/2004 at 1:26 AM Jim Popovitch wrote:
> 
> >There is no feasible way to do what you are asking for, short of
> >removing the sender's email address entirely.
> 
> True.  But that is entirely feasible.
> 
> 
> >  Even then... it is
> >ineffective because the body of the email may contain email
> >addresses from a reply or forward, and the diversity of email
> >clients makes it  
> 
> Not exactly, since forwards are almost always editable to remove
> email address of others.  While you won't get 100% compliance, you
> will find that those that are 'clued in' will happily remove other
> people's email addresses from their forwarded messages.  In fact,
> given the technical ability of those on this list, it would seem
> trivial for us to adjust our email client's forwarding scheme to not
> include email addresses.
> 
> 
> >near impossible to determine where a client may inject the original
> >posters email address (headers included).  
> 
> First, headers could be eliminated altogether in an archive if you
> wish.  Most people probably would like at least the message IDs to
> remain, however.  Neither of these presents much of a technical
> problem, as each line in the headers begins with a title.  Filtering
> these prior to posting to the archive should be relatively easy,
> especially since it is the product of the mailing list engine and
> therefore should be fairly uniform.  The individual client additions,
> IIRC, should all begin with "X", so filtering those out ought to also
> be easy enough.
> 
> 
> >Given the use of email addresses in sigs, RFCs, announcements, and
> >code samples (not to mention emails containing valid addresses that
> >posters are trying to share, i.e. Congressmen, etc), it would
> >require human
> >intervention (i.e. a moderator, also not perfect) to scan each email
> >and decide what email addresses should remain. 
> 
> For email addresses in the body, the human intervention is already
> there; it's proper position in the sequence is just prior to sending
> the message.  It shouldn't happen in the processing phase. ;c)   As
> for 'sigs' that is up to the individual that inserts the signature. 
> If they wish to share their unadulterated email address within the
> body of an email, that is their choice; they won't get upset if it
> ends up in another email (or shouldn't, anyway).
> 
> Email addresses being shared are often done so with the shared
> addressee's knowledge that it is exposed.  Government email addresses
> are already assumed to be exposed, by their nature.
> 
> 
> >If you don't want your address public, get a diff email account for
> >public lists.
> 
> I do.  Doesn't mean I shouldn't work to protect it as long as
> possible, however.  ;c)  I'd rather it take four years, not four
> weeks, to get a dozen messages a week.  ;c)
> 
> 
> It can be done.  I've seen it over and over.
> 
> Cheers,
> Robert Reese~
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
> 
> iQA/AwUBQBafzbw8BOWncaQMEQJbwQCgv3opaCN23R7j24PL6Y4gyMgoRgEAoIA9
> Xazoda8HGp6Ek4Pj/mRj7IJf
> =R22G
> -----END PGP SIGNATURE-----
> 
> 
> Type: DH/DSS 4096/1024 AES-256
> Key ID: 0xA771A40C
> Fingerprint: CAE2 81CA A7CD 6681 341C  E3A9 BC3C 04E5 A771 A40C
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale