Re: Issues relating to managing a mailing list...

I am responding to Russ' original message, because it is too hard to pick one 
of the 52 responses received so far. A quick count is something like <10 
thinking this is a good idea with the remainder thinking this idea ranks 
somewhere between really bad and evil.

Apps Area people who have thought deeply about the topic over the last 25 years 
are in near unanimous agreement this idea is on the evil end of the spectrum.  
While Apps Area folks do not have a monopoly on email ideas, I would offer we 
listen carefully.  This idea brings out a whole host of very old (and solved!) 
issues:
   o  What constitutes a message? (if you strip stuff, you will break 
signatures)
   o  What is an attachment? (is it useless cruft like TNEF or is it S/MIME? 
What about the next part type?)
   o  What about using 15-year-old solutions like HTTP on the composing side?
   o  What about using 10-year-old solutions like IMAP 4?
   o  ...

If another vote in the Nay column is needed, here it is. Nay.
--
- Eric

On Mar 14, 2012, at 7:46 PM, Russ Housley wrote:

> Some suggestions have been made about the IETF mail lists.
> There is a way for mailman to strip attachments and put them
> in a place for downloading with a web browser.  This would be
> a significant change to current practice, so the community
> needs to consider this potential policy change.
>
> What do you think?
>
> Russ
>
>
> > > > > The only bug in the soup is that it seemed to me that we might
> > > > > want to look into an alternative approach.  We have asked people
> > > > > to post large documents somewhere and only send a pointer.  Not
> > > > > everyone can do that, lots of people forget, and some people are
> > > > > just not willing to take the extra step.
> > > > >
> > > > > Plus, we cannot expect people to keep things posted on their own
> > > > > personal, or their company's, web-site indefinitely.  If they
> > > > > don't keep it there, then the pointer in the archive will become
> > > > > stale, and information that should probably be there is lost.
> > > > >
> > > > > So we need a solution to the issue with really big email messages
> > > > > sometime.
> > > > >
> > > > > One solution might be to simpy strip attachments off, put them
> > > > > in the archive and replace them with a pointer.  That shouldn't
> > > > > be that hard, since a lot of anti-virus software does something
> > > > > similar with suspect attachment types.
> > > > >
> > > > > Or we could - once again - ask people to post attachments and use
> > > > > a pointer in their mail, only provide them with a place to post
> > > > > them in the same general area as the mail archive.
> > > > >
> > > > > If there is already something like this in place, please let me
> > > > > know what it is and I will add a pointer to it in my "too big"
> > > > > rejection messages.
> > > > >
> > > > > The thing about threaded messages getting too big is a slightly
> > > > > different issue, brought about by the increasing use of HTML
> > > > > format email.  I talked years ago about this with Scott Bradner
> > > > > because I really think that HTML format messages are useful and
> > > > > relatively easy to read when compared to plain old text.
> > > > >
> > > > > But using HTML leads to messages that are deceptively big.
> > > > >
> > > > > Possibly the right answer in that case is to bump the size limit
> > > > > up to maybe 100K.  Even with HTML format, people will many likely
> > > > > realize that nobody is going to read past the 10th back message
> > > > > in any case (or if they do want to, they can look at the thread
> > > > > in the archive).
> > > > >
> > > > > But even that approach is not fool proof, and there are a lot of
> > > > > resourceful fools out there.
> > > > >
> > > > > Just trying to be creative, and help out...

smime.p7s
Description: S/MIME cryptographic signature