On Fri, Mar 22, 2013 at 11:48:46AM -0500, David Champion wrote: > * On 22 Mar 2013, Chris Green wrote: > > What should an MTA do if there *isn't* a blank line at the end of > > the current mbox where it is going to append a new message? It > > seems to me that what the Python libraries do guarantees that there > > will always be a blank line before the 'From ' line, if there's one > > already then it doesn't matter too much. > > I don't want to butt heads with Python library people, but I would argue > that the Python library's approach is backwards. This has historically > been mildly problematic with Mailman archives, for example, which > begin with a blank line instead of with 'From ', and are unreadable > without modification using some mail applications. (Mutt was patched to > accomodate this quirk only relatively recently.) > When I looked through a number of my mbox files it seemed to me that there must be quite a few 'deliverers' out there appending or prepending blank lines as there just about always seem to be several between each message.
> > > Mutt itself *doesn't* put a blank line there, if you S[ave] or > > C[opy] messages to a new mbox the messages have no blank lines > > before the 'From '. > > Mutt instead writes Lines: and Content-Length: headers, which are a good > alternative to using '\n\nFrom ' as a message delimiter. If you have > Lines: and/or Content-Length: in your delivery message, your LDA/filter > does not need to place a blank line at all. But unless you're adding > those yourself, you can't depend on having them. It is therefore best > to append a blank line to messages during local delivery. > However not all software will *use* the Lines: and Content-Length: headers so the '\n\nFrom ' should be there as well surely. Apart from anything else someone/something may have modified the message on the way who/which doesn't know about Lines: and Content-Length: so they could well be wrong. -- Chris Green
