Michael Richardson wrote:
"Cyrus" == Cyrus Daboo <cyrus(_at_)daboo(_dot_)name> 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?
+1, I think NNTP should of been long part of the IETF "group ware"
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:
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 (ietf-drafts(_at_)isdg(_dot_)net) 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.