> > > The Subject: line has a line feed in it. > > > > That's OK - in headers line feeds are allowed, the next line needs to > > be indented and it's treated as a single line *by mail aware programs*. > > Unfortunately dos2unix doesn't know about anything about mail! > > Then we really need a a new save target because it is impossible to > save a mail as it was written, the mbox target always converts NL to > CR+NL
RFC 2822 that defines MBOX format says that the line delimiter is CR/LF - so Evo is doing the correct thing. But you are right in saying that there should be a save target other than MBOX. It's not really something that has ever bothered me as I usually cut and paste from emails rather than saving. > > > > Is that attachment what the message really is? Because it's > > actually > > base64 encoded so line length of the actual content is irrelevant. > > (look at the source of the original message to see if it's text or > > encoded). It's also unlikely that patch will understand a base64 > > encoded email. > > It was sent as plain/text so I guess Evo wrapped it in base64 when I > did a forward ? Actually, again, Evo is doing the correct thing - RFC 4155 says that you should Base64 encode any included email message to avoid any confusion between the outer email message and any included messages. > Anyhow, does it not look like a normal mail when you either view it > in Evo. or > save it as an mbox? It is normal when viewed within Evo. Saving as MBOX or viewing the source shows that it's actually Base64 encoded. P. _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
