coming into this late, will try to summarize.
On 12/10/2011 11:27 AM, Yoshi Rokuko wrote:
Earl Hood:
Just think of SMIME, PGP, DKIM, et.al. Preserving the original
message is handy whenever one needs to (re)verify the message that
are signed or encrypted.
I disagree, one should break up the MIME parts. There is not value in
keeping MIME beasts in your file system.
i think this debate ended with "we need direct file access to both the
original message as received, and its mime parts". which is not
particularly realistic unless we have lightweight file systems or some
other way to expose as "file names" those mime parts, or unless we keep
both the original and the parts, and name them in a way that shell
scripts can iterate through a folder without seeing both the originals
and the decoded parts.
more on this below. meanwhile:
If it's encrypted MIME there
should be a command that decrypts and detangles mails. Why store a
mail encrypted on your encrypted hard drive, I always decrypt and verify
my mails only once.
i never decrypt in my inbox. if i want to read something later, i'll
decrypt it again. the sender may have encrypted it in order to protect
eavesdropping, in which case there's a short period of time that it will
be on the wire and a really long (infinite, so far as i know) period of
time that it sits in my inbox. it should remain encrypted except when
needed, since my inbox may be on a thrown-away hard drive or backup tape
at some point, beyond my control.
I would love this, obscure mails arrive and the system converts them
into what I prefer - separate files, all text utf8 and so on ... ;-)
so, me too. but if we're considering alternative storage schemes we have
to worry about innovation. as in, will we just adopt Maildir which works
pretty well and is already implemented by a lot of people, or will we
invent something new and have MH be its only user in the early decades.
i'm not up for disruptive innovation in the field of mail storage. what
i could easily imagine is a mime conversion utility that replaced
in-line attachments with external attachments that were just file system
path names like ~/Maildir.parts/$foo where $foo was just a unique
meaningless string similar to Maildir/$foo pathnames. that way if i
decide to view or forward the message it can pick up all the decoded
parts. this would be optional of course, but i believe that even
Maildir-compatible IMAP servers would be able to display such
attachments, yet there they would be for our awk scripts to use if we
wanted to do that.
On 12/11/2011 1:13 AM, Ken Hornstein wrote:
Regarding the other ideas about changing the back-end storage of
messages; I _myself_ am not interested in writing that code. If
someone else wants to write that code, I would be supportive of adding
it to nmh (but we'd have to think about compatibility, etc etc). So
have at it, gentlemen!
as i spake previously, before we can consider different storage formats
we must first abstract out all of the code that understands the current
storage format, into a shared library, and make sure we call that
everywhere. last time i did something like this it was a dns server and
i ended up with code that looked like this:
dns_dom_alltypes(&dti, dom);
while ((rrset = dns_dom_nexttype(&dti)) != NULL) {
int negate = (dns_rrset_getflags(rrset) &
DNS_RRSET_CACHENEGATE) != 0;
if (dns_rrset_gettype(rrset) == ns_t_any) {
assert(negate);
any++;
} else if (!negate) {
pos++;
}
}
dns_dom_lasttype(&dti);
this code would not have has change when the underlying dns cache was
moved out of a recursive malloc-based hash table and into an SQL or
berkeley DB or other system. a lot about the C programming language has
changed since MH was written. for example you can have a pointer to a
type whose size you do not know even if it's a structure whose content
you do not know. opaque interfaces are now reasonable and practical.
and for that, ken, we will need you. implementing other storage schemas
on the underside of the interface can be left as an exercise for the
ambitious, but to move the current schema into an opaque interface, we
will need The MH Guy.
On 12/11/2011 10:17 AM, Jon Fairbairn wrote:
Oliver Kiddle <okiddle(_at_)yahoo(_dot_)co(_dot_)uk> writes:
If you're going to do that, you might aswell name the files using an
SHA hash. It's not like mail files change often.
That would upset things, because mh /does/ change mail files. I
messages to stay in the same place (eg repl -annotate, which I
have as default behaviour for repl).
repl -annotate just calls anno. i think anno is wrong-headed, and
inconsistent with the rest of the MH philosophy. i believe that once a
message has been stored it should never be modified. this has
implications on the abstract storage API, since anno(1) should be
sending messages through that API, which for traditional MH storage
would do what anno(1) has always done (add headers to the top of the
message file) but for other storage systems might put the annotations in
some other storage system, similar to how we'd store decoded
attachments. it's not as if other Maildir-reading mail systems (whether
imap servers or other user agents) will understand anno(1)'s annotations
anyway. thus if only MH can see them, we won't mind.
On 12/11/2011 10:31 AM, Ralph Corderoy wrote:
Hi Valdis,
One more thing, the headers would be made simpler to use. I'm
particularly thinking of having one physical line per header, no
continuation.
procmail to the rescue:
:0 hwf
| formail -c
There ya go.
Thanks. And it seems http://tools.ietf.org/html/rfc5322#section-2.2.3
says long header fields can be unfolded to "be indeterminately long"
i think the message should be stored raw. but disk space has become
horrendously cheap in the decades since we all started using MH. storing
a second copy of the message with header lines folded so as to avoid
continuation and with all MIME attachments made external, would be cheap
to do, if we could do it without auditing every line of code in MH and
modifying everything that depends on there only being one copy of a
given message. thus, again, the need for an abstract storage API.
On 12/11/2011 11:00 AM, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
... if we're doing an overhaul of the code, what system(s) do we want
it to run on? I seem to recall that there's a number of places in the
code where mh does some incredibly bizarre tap-dancing to deal with
the fact that some systems didn't have proper symlinks. I'm *not*
going to go as far as saying "make it work on Linux only and take
advantage of features" - but if there's support for ancient systems in
there that we can heave overboard to make the code simpler we probably
should discuss it. Anybody got a straw-man list of features/systems
they think are deceased and can be tossed?
i'd say that we should avoid #ifdef and depend on pure POSIX. that will
include vax/vms and microsoft win32 as well as all current bsd, mac/os,
and linux systems. we don't need anything fancier than that.
On 12/11/2011 6:04 PM, Jon Steinhart wrote:
I'm pretty happy with nmh as is; I don't want to see the one-message-per-file
thing change as some have mentioned. That's one of the big strengths to me.
i want the one-message-per-file thing to continue but to not be the only
way to access things. no existing shell script that depends on MH should
have to be changed. but other new shell scripts should be developable
that would benefit from having MIME parts and anno(1) metadata stored
outside the unchanging original one-msg-per-file.
and, i am not happy with nmh as is. i can't use it any more for most
things. the world has adopted a whole new way of dealing with e-mail,
such as only putting a newline at the end of a paragraph and using
quoted-printable as necessary to avoid overflowing the 990-character
limits of SMTP. i need to live in THAT world. likewise i need to be able
to access things reliably in IMAP, which means IMAP has to see stable
UID's and stable UID-to-content mappings.
i am willing to reach backward and pull MH along with me into the
future. but i'm not willing to stay behind.
On 12/12/2011 1:02 AM, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Sun, 11 Dec 2011 19:20:10 EST, Ken Hornstein said:
I see a lot of stuff in there for older UNIX systems, but I'm trying
to think of examples for non-UNIX systems; could you provide some
examples?
I'd make the case that SunOS 4.1 from 25 years ago (still mentioned in
the MACHINES file) is sufficiently remote from today's definition to qualify
as "non-UNIX-like" ;)
yea, verily, it is so. in BIND9, circa 1999, we outlawed non-POSIX
systems, including SunOS 4. noone noticed.
sorry for the length of this; you guys all got busy while i was on
family related travel.
paul
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers