(I posted to both SurvPC list and respond on reactions on both:)
A bit more precision for I'm looking for. My question is which Linux
mailer would work with NOT RE-formatted (or what I call "raw" download)
types of files/folders.
Apparently - thanks, Travis ! - "fetchmail" as the mail transport agent
(MTA) would store downloaded mails indeed in that form. While Sylpheed -
thanks, Steven ! - already does some parsing before storing it: It cuts
off the first and last line of a mail item. (It's only logical that it
then has to store each item as a separate file, because the
characteristics of separation between items in a mail download stream get
lost this way.)
Now, what a mail (download) transport agent - not yet necessarily a
full-fledged "client" - gets are four structural elements with each
mail item:
(1) - the header;
(2) - one (at least) empty line which separates the following;
(3) - the mail body;
(4) - the end-of-item marker (in fact the end-of-data of one mail body),
i.e. that "dot-line".
Problems of - later - compatibility of stored ("archived") mail downloads
araise when part of this defining structure is lost in subsequent
handling _before_ storing/saving: Mail handlers ("clients") have their
own ways to order things - thus the clients using a Unix-style "mbox"
format do this peculiar adding of a "From ..." line as separator at a
beginning new mail item (and drop the "+OK [some text" line as well as
the end-of-item marker; but nevertheless they keep lots of mail items in
one and the samer folder-file); while Sylpheed puts each in a proper file
(and drops those two elements too).
It seems obvious that quite a lot of parsing would be needed to already
interchange mail archives between these two; and equally obvious that
this could be avoided by using a mail handler/client which would use
the "raw downloaded" format in the first instance.
It's on of the latter I'm looking for in the Linux World.
(Regrettably, descriptions of the various mailers are fully mute
regarding the archiving format they use. One has to fully set up the
thing and check for what it does, or rather, does not.)
Some REMs:
(1) Send-mail servers add a lot of stuff to the header, for instance
those (variable) "Received: " lines. RFC-mandatory is the very first
line they have to send, which is that "+OK [some text]", followed by
other of their own added stuff and by what's included in the _uploaded_
header of that mail.
Now, it wouldn't be so relevant if the "+OK [some text]" line is
maintained or not, as long as the unique END-OF-ITEM MARKER, that "dot
line", will be.
So there you have the hitch with the "historical" Unix-"mbox" format.
(When items are separated into single files, reconstruction of the
original is somewhat easier as it just implies to add a starting "+OK
[...]" line and the terminating dot line.)
Some information is lost anyway, however, as good/userfriendly SMTP
servers give the number of bytes for the volume of an item on that
first line too, like "+OK 6234 bytes follow".
(2) Any first empty line in the stream from the SMTP is RFC-defined as
separator between header and body.
[BTW, I observe that Steven's posts regularly have even several empty
lines in the header; which makes the following header lines appear as
part of the body in mail readers. Wonder where this comes from ? Do
others receive them in similar form ?]
This rule - unbroken headers, one empty line as separator to the
body - is indeed well maintained in the various mailers/"clients"; as it
is of praramount importance for the whole MIME parts parsing too.
(3) There are stringent definitions of what has to be done with single
dots only on a line _inside_ mail bodies, as this would signal the
end-of-data transmission of a mail item: MTAs uploading have to change
such to double dots, and MTAs downloading should leave to change
double-dots back to single ones as a task of the mail handler/
"client" and for presentation on screen/in print only; regrettably,
quite many a mailer stores such to single-dots re-translated in its
archive, creating another hassle for compatibility of mail archives.
(Those "lost dots" are typically result of bad back-and-forth coding
between HTML and plain text in Microsoft gear. The just wouldn't ever
appear in normal, good text.)
(4) The "(single-)dot line", unique end-of-item/mail marker is
probably the most practical and reliable means to maintain access of
mail archives by different mail handlers/"clients". So that would be a
criterium to look for, searching which Linux mail reader would be most
apt to work with other mail archives (and would produce own archives
compatible for other readers.)
The - apparently minor - strain in these Linux based mail readers which
keeps mail items each in single files does facilitate the task, as the
file items are separated entities by themselves. (But the pertaining
file order with a finely developed tree of threadings poses another
complication.)
The majority "mbox" type school - with oftenly resulting enormous folders
and strictly untransferable indexing systems - constitutes the major
problem.
Once again, "man(ual)s" and other descriptions are not at all helpful
in this regard - they just don't tell.
// Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-11-06
The WebPlace of ReRead - and much to read ==> http://www.revobild.net
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
