Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ripMIME: general

default mail body text?

 

 

ripMIME general RSS feed   Index | Next | Previous | View Threaded


sz at szasz

Jan 31, 2003, 4:05 PM

Post #1 of 4 (1603 views)
Permalink
default mail body text?

Hi,

Is there a reliable way to extract the "mail body text"
from mails? The text people write to my mailing list
(and attach stuff to), sometimes goes into textfile0,
sometimes (usually) into textfile1.

I bet it depends on several factors, but is still there
a reasonable method to always handle it intelligently,
or is this is a hopelessly heuristic problem?

Thanks,
Sab


pldaniels at pldaniels

Jan 31, 2003, 5:11 PM

Post #2 of 4 (1487 views)
Permalink
Re: default mail body text? [In reply to]

> I bet it depends on several factors, but is still there
> a reasonable method to always handle it intelligently,
> or is this is a hopelessly heuristic problem?

The rule is basically this ( from RFC's )

If the email is multipart ( ie, has MIME headers ), then the first text body ( textfile0 ) will contain the normal "This is a MIME encoded email, if you are reading this...", thus textfile1 will be the body.

If the email is strictly plain-text, then textfile0 will be the body.

I -could- put in a facility which will allow the body to be written out to a specifically named file (ie, --body_name=some_file_name ), because obviously the MIME decoding module will know if the email is multipart or not.


Regards.

--
Paul L Daniels http://www.pldaniels.com
Linux/Unix systems Internet Development
ICQ#103642862,AOL:cinflex,IRC:inflex
A.B.N. 19 500 721 806


sz at szasz

Feb 9, 2003, 5:16 AM

Post #3 of 4 (1517 views)
Permalink
Re: default mail body text? [In reply to]

> If the email is multipart ( ie, has MIME headers ), then the first text body ( textfile0 ) will contain the normal "This is a MIME
encoded email, if you are reading this...", thus textfile1 will be the body.
>
> If the email is strictly plain-text, then textfile0 will be the body.
>
> I -could- put in a facility which will allow the body to be written out to a specifically named file
(ie, --body_name=some_file_name ), because obviously the MIME decoding module will know if the email is multipart or not.


That would be a nice thing, but maybe also an overkill.
As to my understanding, a much simpler, solution is readily
available, by changing 1 single (wel,l OK, probably a
few more... ;) ) char:

It is already a very nice thing in Ripmime to call the
almost never used root part of mime messages "textfile0".

Now, simply declaring that non-multipart messages go to
"textfile1" (instead of textfile0), would magically align
unipart messages with the most frequent case of multipart
messages, where also "textfile1" is the actual mail message
text.

This would break compatibility somewhat (which is better
to so earlier then later), but would save some extra
work for both Ripmime and its clients once and for all.

Cheers,
Sab


sz at szasz

Feb 9, 2003, 5:28 AM

Post #4 of 4 (1510 views)
Permalink
Re: default mail body text? [In reply to]

> It is already a very nice thing in Ripmime to call the
> almost never used root part of mime messages "textfile0".
>
> Now, simply declaring that non-multipart messages go to
> "textfile1" (instead of textfile0), would magically align
> unipart messages with the most frequent case of multipart
> messages, where also "textfile1" is the actual mail message
> text.

Another quite handy property of this, just came up:

Currently, there is no easy way for us, clients, to
recognize if the mail was multipart or not.

Now, the presence or absence of "textfile0" would be
a clear indicator for the difference, so the client
can see the case easily.

(Some natural sugaring to this approch would be
perhaps not even calling it "textfile0", remembering
the changeable prefix and numbering, but e.g. simply
"mime" or anything alike.)

BTW, thanks for this VERY COOL piece of stuff being
made available for us!!

Sab

ripMIME general RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.