>> As for nmh being wrong, well ... it cannot handle email that it seems >> literally every other piece of email software seems to handle just fine. >> What does that tell you? > >I've been thinking more about this... dangerous, I know. > >I'm not sure we know what "handle just fine" means for the rest of the >world. Some of the reports I've seen that are similar to mine suggest >that their mail system handles it by truncating the line thus rendering >the attachment garbage (if it's an attachment). I don't know what those >others are running, but I'm pretty confident it's not nmh.
Well, hm, good question. The OVERWHELMING impression I get is that the vast majority of the email world seems to read and deal with those multi-megabyte messages that appear as a single line just fine. But if you could provide some context about these reports where people experience this truncation it sure would be useful. >Is truncating the line the appropriate thing to do? What should nmh do? > >In another thread we're discussing a patch that will make inc handle the >long lines, but what should inc do with the long lines? Should it >actually make those long lines conform by folding them? Well, in the admittedly rare case of binary content which is exempt from the line length requirement (I believe nmh can read those messages correctly but probably cannot generate them, or store them correctly if they are on a POP server), you can't fold that content at all. I cannot come up with a reason that we should not just store that message as it is presented to us and simply handle it. --Ken
