[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Weird behavior with non-ascii code in headers
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] Weird behavior with non-ascii code in headers |
Date: |
Wed, 26 Jun 2013 21:52:17 -0400 |
>Clearly, you need to be more opinionated. :-) nmh is already happy to
>inc malformatted, see what I did there, emails, e.g. sortm later
>complains about unparsable dates, and I think that should continue.
So, as long as we're talking about things ... here's my feelings:
- inc should continue to be able to incorporate any sort of random crap
without failing, like it does now.
- The other utilities should try to "continue" as much as they can, while
providing reasonable feedback to the user.
>I'd expect and like repl to complain and not present me with a draft to
>edit. I can then investigate based on the error message. This suggests
>the failed attempt to parse the To header should ripple back up; longjmp
>FTW. ;-)
>
>Whether a template that didn't refer to To would spot the problem
>depends on if the existing code parses all interesting headers up front
>or only upon reference. I wouldn't expect this to change, just be
>documented.
Doing that would require some more smarts to the format engine; that's
possible, we've slowly been making it smarter. Might have to figure
out how much smarter it needs to be. But how will that interact with
higher-level front-ends to nmh?
>It's a rare enough occurence that investigation should result, not some
>stab at automated DWIM fixing. It Outlook starts doing this every
>weekday then we'd have more evidence upon which to do the right thing.
I am wondering what other MUAs do when presented with these messages, though.
--Ken