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

From: Russ Housley <[email-masked]>
Date: Wed, 14 Mar 2012 19:46:15 -0400

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...

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Mar 2012 00:56:53 +0100

Hello Russ,

IMHO this is a great idea and I fully support it's deployment asap. It 
is well overdue one too not only in IETF but in many other mailing lists 
in the community.

--

The only few maybe too detailed at this point questions:

- what would be (if not infinity) the expiration data of such attachment 
repository ?

- what would be the automated interface to periodically sync such 
repository on a per WG group to a local space ?

- would email contain full link or just a url short cut ?

- would the document as attachments be google indexed and fully searchable ?

- what attachment formats would be supported ?

Regards,
R.

---

From: [email-masked]
Date: Wed, 14 Mar 2012 17:33:20 -0700 (PDT)

> What do you think?

Is this really a big enough problem to be worth solving? I can't recall a
single instance where I received IETF list with a problematic attachment. OTOH,
I routinely get IETF messages with useful attachements - typically a critical
revision to a draft which for whatever reason can't be posted as an I-D - that
I really need to be able see without having to bother with some indirection.
There are also times when I have access to email but no web access. What am I
supposed to do then?

This also creates significant problems for list archiving. Right now I can
easily capture the entire content of the list and preserve it for however long
I want. Do this and that becomes significantly more difficult - I have to
detect these indirections, fetch and stuff the attachments back in, because
regardless of stated policy I cannot assume that web link will be valid for as
long as I need it to be.

I also worry about the ability of mailman to actually know what an attachment
is versus a message constructed in multiple parts. And there's also the issue
of what sort of indirection it uses. Past experience with "advanced" list
manager features like this doesn't give me a whole lot of confidence in their
MIME chops.

I suppose I could live with this - but not actively support it - if the
stripping was limited to abusively large attachments - say ones over 5Mb or
thereabouts. But otherwise it's a TERRIBLE idea, and will simply result in 
everyone including the draft or whatever in the primary message text in order
to avoid this nonsense, which results in a degradation of list quality for all
concerned.

				Ned

---

From: David Morris <[email-masked]>
Date: Wed, 14 Mar 2012 18:26:02 -0700 (PDT)

Sounds like a good idea ... I'd add one more question to the list below 
... How would these attachments appear in the archive? Are they already
linked objects, must be I guess, would that change?

On Thu, 15 Mar 2012, Robert Raszuk wrote:

> Hello Russ,
> 
> IMHO this is a great idea and I fully support it's deployment asap. It is well
> overdue one too not only in IETF but in many other mailing lists in the
> community.
> 
> --
> 
> - what would be the automated interface to periodically sync such repository
> on a per WG group to a local space ?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Mar 2012 14:28:00 +1300

On 2012-03-15 13:33, [email-masked] wrote:
...
> thereabouts. 

+0.9; maybe set the limit a bit lower, for those who still have network
capacity issues. However, it would be extremely inconvenient to have small
attachments stripped.

> But otherwise it's a TERRIBLE idea, and will simply result in 

+1

    Brian

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Mar 2012 21:44:52 -0400

On Thursday, March 15, 2012 02:28:00 PM Brian E Carpenter wrote:
> > stripping was limited to abusively large attachments - say ones over 5Mb
> > or thereabouts.
> 
> > everyone including the draft or whatever in the primary message text in
> > order to avoid this nonsense, which results in a degradation of list
> > quality for all concerned.
> 
> +1

+1 to it's a terrible idea.

Scott K

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Mar 2012 23:48:08 -0400

--On Wednesday, March 14, 2012 21:44 -0400 Scott Kitterman
<[email-masked]> wrote:

>...
>> > But otherwise it's a TERRIBLE idea, and will simply result
>> > in everyone including the draft or whatever in the primary
>> > message text in order to avoid this nonsense, which results
>> > in a degradation of list quality for all concerned.
>> 
>> +1
> 

Let me add to the reasons the observation that there are still
some of us who read IETF mailing lists on airplanes or in other
environments with limited, expensive, or zero connectivity.  If
everything is in the email message then downloading messages
with POP3 or synchronizing a local ("offline") copy with IMAP is
easy and easy to automate.  No need to read those messages at
all before heading for the airport (or whatever).  If some
messages have important stuff in URL references, it creates a
nightmare because the only way to find those is to skim all the
messages before departure.

Terrible, terrible, idea with a high likelihood of a significant
reduction in productivity.

    john

---

From: Ross Callon <[email-masked]>
Date: Thu, 15 Mar 2012 00:00:28 -0400

I don't like this proposal for two reasons: I frequently read email while not connected; When connected, bandwidths have gotten high enough that attachments on the most part are not slowing things down in an uncomfortable way. 

It might be okay for really large attachments, as long as only a few messages are affected. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, March 14, 2012 7:46 PM
To: IETF
Subject: Issues relating to managing a mailing list... 

What do you think?

Russ

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Mar 2012 02:44:47 -0400

> Is this really a big enough problem to be worth solving? I can't
> recall a single instance where I received IETF list with a problematic
> attachment.

i travel to places with very poor bandwidth.  it is a problem.

and the vast majority of users just do not get it.  "we send 20mb
documents around the office all the time.  suck it up."

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Mar 2012 02:48:00 -0400

> I suppose I could live with this - but not actively support it - if
> the stripping was limited to abusively large attachments - say ones
> over 5Mb or thereabouts. But otherwise it's a TERRIBLE idea, and will
> simply result in everyone including the draft or whatever in the
> primary message text in order to avoid this nonsense, which results in
> a degradation of list quality for all concerned.

i prefer not to get 1MB without my consent.  and i will leave to your
imagination what i think of multi-megabite internet-drafts in general.

randy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Mar 2012 08:16:09 +0100

Hi Russ,

> needs to consider this potential policy change.

-1.  Offline readers would find it difficult to deal with such messages.

Eliot

---

From: Francesco Gennai <[email-masked]>
Date: Thu, 15 Mar 2012 08:07:49 +0100 (MET)

> documents around the office all the time.  suck it up."

for who has problem in attachment downloading the solution should be
at the delivery Message Store level, where the strip of the attachment could be
done accordingly to an user configurable mailbox parameter
(as we do on our server, where we call it Easy Delivery).

Francesco

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 15 Mar 2012 10:49:50 +0100

> (as we do on our server, where we call it Easy Delivery).

A proposal: what about something configurable?  Everyone already has a
personal "setup" page for his/her own mailman account.  It would
suffice to add an option "send attachment as link," possibly with a
configurable threshold.  Honestly, I do not anything about the
internal structure of mailman, so I do not know if this would be a
huge change (wrt the "pure link" solution) or not.  But, you know,
"nothing is impossible if you do not have to do it..." :)

For me, I like the idea of using the link since, depending on where I
am, I work with different PCs.  Because of this, I read the mail via
web services and I do not download it on my local disk.  Large
attachments clog up my quota (do you see why I am using a gmail
account?).  However, I understand the "dual" situation where people
download the mail on local disk and the "physical" attachment would
allow them to have the attachment even when offline.

Letting each one doing his/her choice looks like a good compromise to me.

Riccardo

---

From: Hector <[email-masked]>
Date: Thu, 15 Mar 2012 06:55:38 -0400

It will be more work, but going to mixed connectivity solution 
addresses the old, current and new.  Going online will serve better 
the rebirth on online connectivity, mixed bandwidths and smaller 
devices.  Using forums via web, newsgroups with email components has 
long been part of the RFC-based MUA.

But even for companies that have gone with mixed connectivity with RFC 
based and Online Web forums, going to Online web access may be 
inevitable. Microsoft is a prime example after nearly 30 years it 
abandoned the newsgroups for online forums early last year.  To help 
with the transition, several NNTP Bridges were written to allow for 
users familiar with their favorite MUA Email/News Readers to use the 
online forums.  That is what I did when Microsoft migration NNTP 
bridge was too poor. So I wrote WcLEX (Wildcat! Live Exchange) 
http://opensite.winserver.com/wclex

There is plenty of open source BBS forums for the web that offers a 
wide degree of group ware support features. Some many already have 
component to allow members to receive list mail via email accounts 
which came after much request to offer the "legacy" mode.

I suggest to keep the current mode, and look at Online BBS forums as a 
migration, and it may also using calendaring many always come with and 
also probably be able to augment the Online IETF Meeting efforts.

Go West.

---
Hector Santos, CTO
http://www.santronics.com

Riccardo Bernardini wrote:
>>> i travel to places with very poor bandwidth. �it is a problem.
>>> and the vast majority of users just do not get it. �"we send 20mb
>>> documents around the office all the time. �suck it up."
>>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2012 09:18:04 -0400

>>>>> "ned" == ned  <[email-masked]> writes:
    ned> Is this really a big enough problem to be worth solving? I
    ned> can't recall a single instance where I received IETF list with
    ned> a problematic attachment. OTOH, I routinely get IETF messages
    ned> with useful attachements - typically a critical revision to a
    ned> draft which for whatever reason can't be posted as an I-D -
    ned> that I really need to be able see without having to bother with

I regard those situation as a violation of process.
If that ID can't go on an HTTP site, then something is missing.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2012 09:27:31 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:
    Russ> Some suggestions have been made about the IETF mail lists.
    Russ> There is a way for mailman to strip attachments and put them
    Russ> in a place for downloading with a web browser.  This would be
    Russ> a significant change to current practice, so the community
    Russ> needs to consider this potential policy change.

I like it.

    Russ> What do you think?

Is text/html an attachment?
What about text/plain that hasn't got format=flowed, but has lines
longer than 77 lines?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Mar 2012 06:37:18 -0700

> needs to consider this potential policy change.

It is an entirely reasonable idea.

However has some very core operational problems that are being nicely listed by 
others already.  IMO, they are all real and serious.  They decrease the flexible 
usage styles of IETF mailing lists that is now possible.

Ultimately, as at least Ned noted, the major problem with the suggestion is that 
is seeks to solve a problem that we don't have.

So concerning the proposal:  -1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Mar 2012 09:41:35 -0400

Hi,

> messages before departure.

Along those lines how about setting up an IETF IMAP server with mailboxes 
for each mailing list hosted by the IETF? That way anyone with a capable 
IMAP client (one that can separately download text and attachments as 
preferred by the user on a per-mailbox basis) can choose to sync the 
messages as they prefer based on their own circumstances. What is more, if 
people use the IMAP server as their main way to access to the mailing lists 
there are other big benefits: the mailboxes provide a comprehensive 
searchable archive of messages directly within the email client, users can 
subscribe with an option to not have list email delivered to their own 
account - that would remove the need to deliver lots of messages.

Yes, this would be a fairly big infrastructure change, but there are 
significant benefits and flexibility to using IMAP as a shared mailing list 
repository.

-- 
Cyrus Daboo

---

From: Dave Cridland <[email-masked]>
Date: Thu, 15 Mar 2012 13:44:27 +0000

> capacity issues. However, it would be extremely inconvenient to  
I'd be against this - any cut-off picked would be an arbitrary  
number, and given there exist well-deployed, well-supported  
specifications for accessing internet message stores without  
downloading all parts of a message, I see no need for this at all.

I'd prefer rejecting outright particularly large messages, to  
mangling them in unpredictable ways - however, I have been reading  
IETF lists over expensive and slow networks for years without running  
into any such messages.

> > to avoid this nonsense, which results in a degradation of list  

Right, we're merely introducing damage for people to route around.

If we're seriously making a statement that messages with attachments  
cannot be handled properly in the deployed network due to Technical  
Reason X, then I would be very interested to hear what X is. The  
message Russ quotes merely suggests that large messages are a problem  
in themselves - if they are genuinely a problem, how? And why on  
earth are they a problem in this group?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Mar 2012 09:47:57 -0400

--On Thursday, March 15, 2012 00:00 -0400 Ross Callon
<[email-masked]> wrote:

> I don't like this proposal for two reasons: I frequently read
> email while not connected; When connected, bandwidths have
> gotten high enough that attachments on the most part are not
> slowing things down in an uncomfortable way. 
> 

Borrowing a bit from Randy, the solution to really large
attachments is to ban them.  Personally, I'd find it perfectly
reasonable to have any message in the megabyte range or above
(or probably even an order of magnitude smaller) rejected with a
message that amounted to "if you have that much to say, write an
I-D, post it, and point to it".  That is much more plausible
today, when the mean time between I-D submission and posting is
measured in minutes (except during blackout periods) than when
it was in days.  During blackout periods, the last thing the
community needs is people adding to already-overloaded lists by
posting long documents in email.

If people want to use up part of their maximum size quota by
posting html in addition to text, or appending long disclaimers
or autobiographies, that shouldn't the community's problem.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Mar 2012 09:55:37 -0400

--On Thursday, March 15, 2012 09:41 -0400 Cyrus Daboo
<[email-masked]> wrote:

>...
> Along those lines how about setting up an IETF IMAP server
> with mailboxes for each mailing list hosted by the IETF? That
> way anyone with a capable IMAP client (one that can separately
> download text and attachments as preferred by the user on a
> per-mailbox basis) can choose to sync the messages as they
> prefer based on their own circumstances. What is more, if
> people use the IMAP server as their main way to access to the
> mailing lists there are other big benefits: the mailboxes
> provide a comprehensive searchable archive of messages
> directly within the email client, users can subscribe with an
> option to not have list email delivered to their own account -
> that would remove the need to deliver lots of messages.
> 
> Yes, this would be a fairly big infrastructure change, but
> there are significant benefits and flexibility to using IMAP
> as a shared mailing list repository.

Including the traditional argument for eating our own dog food
rather than inventing and using idiosyncratic and non-standard
solutions.

Now, if only I could find a fully-competent IMAP client with a
decent IMAP-oriented UI and support for recently-added features
(not just to IMAP but including good support for current
versions of S/MIME and OpenPGPO, certificate formats, EAI,
etc.).  :-(

       john

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 15 Mar 2012 07:43:25 -0700

On Mar 15, 2012, at 6:47 AM, John C Klensin wrote:

> attachments is to ban them. 

+1

Lixia

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 15 Mar 2012 15:56:35 +0100

>> attachments is to ban them.

Indeed, it is simple, effective and no big changes are necessary.
Moreover, as someone else pointed out, large attachments are very,
very unusual, so a limitation on the maximum attachment size should
not be a problem most of the time.

How do we fix the maximum size?  I just checked that the PDF version
of RFC 3261 (SIP) is 388 K.  Double it and fix the bound to 800 K.
Twice the size of SIP spec should be more than reasonable.

Riccardo

---

From: [email-masked]
Date: Thu, 15 Mar 2012 08:03:50 -0700 (PDT)

> (as we do on our server, where we call it Easy Delivery).

Or better still, don't strip anything. Use a reasonably capable client and
that doesn't fetch attachments unless you tell it to.

I'll again note that implementation of this policy will cause people to send
single part messages in order to avoid attachment stripping, which will make it
impossible for clients to avoid downloading material they do not want. In other
words, it will exacerbate, rather than solve, the problem.

				Ned

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 15 Mar 2012 08:12:57 -0700

On 03/15/2012 07:43 AM, Lixia Zhang wrote:
>>> I don't like this proposal for two reasons: I frequently read email
>>> while not connected; When connected, bandwidths have gotten high enough
>>> that attachments on the most part are not slowing things down in an
>>> uncomfortable way.
>>> 
>> Borrowing a bit from Randy, the solution to really large attachments is
>> to ban them.
> 
> +1
> 
> Lixia
> 

I support the ban of attachments in IETF emails.

On the other hand, one feature that would be very useful is to add in the
email footer a link to the archive in each email forwarded by mailman (mailman
does not support that currently), so referencing a past email in a discussion
does not require having to search the archive.  For example the previous email
should contain a link for
https://www.ietf.org/mail-archive/web/ietf/current/msg72476.html.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Mar 2012 11:24:05 -0400

> that doesn't fetch attachments unless you tell it to.

Yes.  What problem is this proposal to do anything about attachments
trying to solve?  Of all the non-problems around the IETF in search of
a lot of extra rules, at first glance this one seems to me like the
noniest.

A

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked]
Date: Thu, 15 Mar 2012 08:16:29 -0700 (PDT)

> or autobiographies, that shouldn't the community's problem.

You begin by talking about "banning large attachments". You then segue
into a discussion where you talk about a maximum size that includes the
primary message content, not attachments, then you throw in disclaimers,
which may or may not be attachments.

Other have followed up by supporting the limit on attachment size, others
still have talked about banning attachments regardless of size.

Do you see the problem here? The minute you start focusing on specifics
of message content, you're in a rathole. What counts as an attachment?
(And yes, we have a precise definition for what constitutes an attachement,
but following that definition gives people the ability to route around
it.)

It follows that any limit needs to be on overall message size. (Even
this is a little perilous because message sizes can change due to
MIME downgrading or upgrading, both of which happen regularly.) I would
not be opposed to imposing such a limit, although it's going to need to
be higher than some people would probably like - it's surprising how
easily you can approach 1Mb with a single part, plain text message
containing nothing remotely resembling an "attachment".

				Ned

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 15 Mar 2012 10:04:46 -0400

On Thu, Mar 15, 2012 at 09:47:57AM -0400, John C Klensin wrote:
> I-D, post it, and point to it".  [...]
> 

I strong concur with all points (including those elided).  Attachments
which are in open formats and of modest size are often useful; those
which are in closed formats and of enormous size tend not to be.

---rsk

---

From: Pete Resnick <[email-masked]>
Date: Thu, 15 Mar 2012 10:49:25 -0500

On 3/15/12 8:41 AM, Cyrus Daboo wrote:

> Along those lines how about setting up an IETF IMAP server with 
> mailboxes for each mailing list hosted by the IETF?

There has been a discussion under way for some time to get that to 
happen. I believe RFP's are being thought about (or written).

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Francesco Gennai <[email-masked]>
Date: Thu, 15 Mar 2012 17:52:53 +0100 (MET)

> that doesn't fetch attachments unless you tell it to.

Yes, I agree, but we can leave the end user to choose accordingly their own 
no capable/capable clients or maybe accordingly to temporary condition.

> single part messages in order to avoid attachment stripping, which will make 
> it impossible for clients to avoid downloading material they do not want. 

I think that a part in a single part message can be replaced as any other part 
in a multipart message.

> In other words, it will exacerbate, rather than solve, the problem.

Francesco

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 13:54:26 -0400

Russ> What do you think?

I agree with those who believe this would be a bad idea. I often read
IETf mail on airplanes where downloading an attachment would be
problematic.  It is much less common for me to want to download IETF
messages where I have any concerns about bandwidth.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Mar 2012 13:57:43 -0400

Hi Pete,

> happen. I believe RFP's are being thought about (or written).

Right, so isn't this, 
<http://tools.ietf.org/html/draft-sparks-genarea-mailarch-05>, entirely 
satisfiable via IMAP? At the very least I think that draft needs another 
requirement:

* Users must be easily able to reply to archived messages using their email 
client of choice. In particular, replies need to preserve threading 
information in the form of References and In-Reply-To email headers.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Thu, 15 Mar 2012 11:14:16 -0700 (PDT)

> no capable/capable clients or maybe accordingly to temporary condition.

You can as long as attachments remain as attachments, which will no longer be
true if this proposal is implemented. If they don't the "strip attachments"
approach no longer works. You either (a) Only strip attachments, which leaves
you with large messages to deal with, (b) Strip by part size, which will leave
you with empty message, or (c) Cut parts down to a given size, which is
guaranteed to work poorly.

The two list approach, if secondary list proves popaular, may lead to the same
result, BTW. As I commented previously in a private email, it never ceases
to amaze me how people in this community only apply the "route around
problems" mantra when it suits their purpose to do so.

				Ned

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2012 14:24:06 -0400

>>>>> "Cyrus" == Cyrus Daboo <[email-masked]> writes:

    Cyrus> Along those lines how about setting up an IETF IMAP server
    Cyrus> with mailboxes for each mailing list hosted by the IETF? That
    Cyrus> way anyone with a capable IMAP client (one that can

How about we use the protocol that was designed for this...  NNTP?

---

From: Robert Sparks <[email-masked]>
Date: Thu, 15 Mar 2012 13:37:26 -0500

The current plan is to investigate both a web based archive access 
mechanism and an IMAP based one.

I split the requirements for them into two drafts so the projects could 
be pursued separately.
See also <https://datatracker.ietf.org/doc/draft-sparks-genarea-imaparch/>

On 3/15/12 12:57 PM, Cyrus Daboo wrote:
> Hi Pete,
>
> --On March 15, 2012 10:49:25 AM -0500 Pete Resnick 
> <[email-masked]> wrote:
>
> <http://tools.ietf.org/html/draft-sparks-genarea-mailarch-05>, 
> entirely satisfiable via IMAP? At the very least I think that draft 
> needs another requirement:
>
> * Users must be easily able to reply to archived messages using their 
> email client of choice. In particular, replies need to preserve 
> threading information in the form of References and In-Reply-To email 
> headers.
Ack.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Mar 2012 11:38:58 -0700

On 3/15/2012 8:49 AM, Pete Resnick wrote:
>
> There has been a discussion under way for some time to get that to happen. I
> believe RFP's are being thought about (or written).

we have just entered the RFI stage.  I see that as progress.

d/
-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Thu, 15 Mar 2012 13:40:56 -0500

> we have just entered the RFI stage.  I see that as progress.

For draft-sparks-genarea-imaparch, or just draft-sparks-genarea-mailarch?

pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 15 Mar 2012 13:45:49 -0500

> For draft-sparks-genarea-imaparch, or just draft-sparks-genarea-mailarch?

Nevermind. I am told it is for the latter. The former is being handled 
separately, and is also making progress.

pr

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Mar 2012 16:18:45 -0400

Since the problem is a relative handful of large attachments, could a
solution just be to provide a repository for
mailing list members to store such files, yielding a URL they could
use in an email ? Then, the usual list feedback
would keep the attachment sizes manageable.

Obviously, there would be some issues about security (e.g., avoiding
hidden porn storage),
but they don't seem insurmountable in context For example, the link
could be non-functional until the URL was
used in an email to the appropriate mailing list. Then, the usual
moderation tools should suffice to take care
of inappropriate content.

Regards
Marshall

---

From: Pete Resnick <[email-masked]>
Date: Thu, 15 Mar 2012 15:40:42 -0500

> would keep the attachment sizes manageable.

(*mumble*) Folks, let's please not try to engineer around user 
silliness. User silliness will occur no matter what tools we provide.

Anybody can get a place on Dropbox or elsewhere and put a URL to their 
stuff into an email message. The problem is not that the tool isn't 
there. The problem is that people don't use it. They attach dumb things 
instead of pointing to them. Or worse they paste them inline, making it 
even harder for people who use tools that can avoid attachments from 
having to deal with them. What we need is better decisions and a bit 
more considerateness by senders of email, not more things to let them 
continue being dumb.

And there is no "one size fits all" solution here: Setting up a separate 
list that strips out attachments and makes them links helps me some of 
the time (when I'm on a low bandwidth device that can't receive mail 
other than in lump-and-dump mode), but it's lousy for me at other times 
(when my device is now zero bandwith and I would have liked everything 
downloaded while I was online so now I can read it offline). Maybe some 
folks are never offline (or are willing to ignore some of the data that 
was sent while they are), or simply don't have access to tools that 
allow them to only download attachments on demand. Maybe a second list 
with this feature would help. But overall, this seems like a social 
engineering problem more than a computer engineering problem to me.

All of this is independent of an IMAP archive. That let's people 
manipulate message in the archive with their favorite email program, 
downloading attachments (or not), replying (and getting all of the 
References: header fields right), etc. That's a good thing for the 
recipient, independent of this issue.

pr

---

From: Hector <[email-masked]>
Date: Fri, 16 Mar 2012 02:29:45 -0400

> needs to consider this potential policy change.

We will never be able to satisfy all unless there an option to do so.

One approach is to keep an focus on what the real issue is as 
presented by the question and just making a change to address this only.

The other, less focus, forward thinking approach is to use the 
opportunity to begin moving the IETF or perhaps "catch up" with new or 
existing Group Ware communications directions the IETF has yet to 
leverage.

So I think it may help to be specific on what we are having to work 
with. If mailman is the only consideration as the current tool, then 
the solution is based on what is it capable of.  Is the question 
dealing with a System Wide policy or does it include the option to 
make it per user (member of a list)?  Off hand, the latter is the more 
democratic solution IFF mailman offers his option.

If it is open ended question, then there are other solutions that 
addresses all the concerns - old and new. However, that is the more 
expensive solution.

---

From: Hector <[email-masked]>
Date: Fri, 16 Mar 2012 03:07:45 -0400

> How about we use the protocol that was designed for this...  NNTP?

+1, I think NNTP should of been long part of the IETF "group ware" 
offerings.

However, NNTP solutions doesn't address the main original posted 
question which I believe related to bandwidth issues.

The RFC5322 solution proposed in the question begins the emulation 
online solutions where the resources (attachments) are in the backend. 
  So this is more about a system wide vs per user option policy of how 
original mail is transformed and distributed.

We make some popular email based list via NNTP as "Public Local 
Newsgroups" such as the IETF-DRAFT list among them at:

     news://news.winserver.com

This is how some of the our users (and myself) interested in IETF 
catch up with the IETF-DRAFTS email submissions. I use a special 
member address ([email-masked]) to redirect these incoming 
emails into the public/open newsgroup storage area.

I've done the same with specific IETF list that only I belong to (have 
access to) so I am use my RFC-based MUA, and here I have to often 
decide on the incoming transformation:

   - if I want WYSIWYG, then I set the Preserve MIME option = YES (no 
changes in storage)

   - if TEXT is all that is important, then the option OFF where 
attachments are extracted
     and stored separately.

But for the IETF, it needs to cater to wide range of users, so it will 
need to preserve the originality if it wishes to continue only 
offering an RFC based connectivity method.

When we begin to deviate from standard RFC mail methods, then it has 
to begin to consider the different, new connectivity methods, line 
online web access, etc.

--
HLS

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Mar 2012 09:42:34 +0100

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: "IETF" <[email-masked]>
Sent: Thursday, March 15, 2012 12:46 AM

> needs to consider this potential policy change.

Brilliant idea.

Some WG chairs already limit message size to 40kbyte which is a more basic way
of imposing commen sense on those who post to IETF lists with no awareness of
the damage they do to the work of others by posting successions of megabyte
messages.  Doubtless, the culture they work in is so rich in resources they
cannot conceive of any reason not to and we need to educate them.

The culture to promote is no attachments, zero, zilch.  Anything you cannot send
out through I-D system belongs on an FTP site, something that many WG chairs
recognise and provide as an auxiliary page.  Sadly, automatic stripping would be
a necessary step along the road there.

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Mar 2012 09:19:43 -0400

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:
    Pete> (*mumble*) Folks, let's please not try to engineer around user
    Pete> silliness. User silliness will occur no matter what tools we
    Pete> provide.

    Pete> Anybody can get a place on Dropbox or elsewhere and put a URL
    Pete> to their stuff into an email message. The problem is not that
    Pete> the tool isn't there. The problem is that people don't use
    Pete> it. They attach dumb things instead of pointing to them. Or
    Pete> worse they paste them inline, making it even harder for people
    Pete> who use tools that can avoid attachments from having to deal
    Pete> with them. What we need is better decisions and a bit more
    Pete> considerateness by senders of email, not more things to let
    Pete> them continue being dumb.

+1000.

If they can't figure out to produce a URL, then *I* say, they aren't
tall enough to post to an IETF mailing list.

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2012 17:39:40 -0000

>mechanism and an IMAP based one.

Don't forget NNTP (RFC 3977).  I use it locally, deliver list mail to
local per-list newsgroups, and it works really well.

R's,
John

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 16 Mar 2012 12:59:49 -0500

On 03/16/2012 12:39 PM, John Levine wrote:
> In article<[email-masked]>  you write:

IIRC, mailman has native support for archiving messages via NNTP as well.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Eric Burger <[email-masked]>
Date: Mon, 19 Mar 2012 09:58:27 -0400

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