Aside from when it would be used to generate an address, which without
modifying them by adding quotes (or otherwise, perhaps by just dropping
the phrase completely) would be improper, what are those other
situations?
I haven't been able to find anything that doesn't work exactly as I
would expect it to -- the one I thought most likely to fail, if anything
was going to, was "pick -from" - but that worked just fine too.
Fair enough, since you're asking (pick doesn't use the address parser,
FWIW).
Most of the issues I've encountered are centered around the format engine.
What I've found is that it's incredibly useful to use scan(1) to extract
message components to make decisions on what to do with messages. For this
to work on address components, however, the parser has to be able to
parse the address.
Normally I use something like '%(addr{from})' to generate the mailbox name
for decisions (like you can have a shell script automatically refile to
a particular folder based on the sender). But this breaks down if the address
can't be parsed. For most cases for display, nmh uses %(pretty), which will
revert to outputting the whole string if the address parser fails. But
AFAICT every other address format function will return a null string if
the address cannot be parsed properly.
Is this a valid use case that meets your requirements? Well, I guess it
depends on your perspective.
But that was a long time ago now (approaching 20 years) - one would have
hoped that with the more precise spec in 2822 (and 5322) that by now
mailers would have been largely cleaned up.
I was unaware that this was actually introduced in 2822, but I see THERE
it says in §4.1 (emphasis mine):
It appears here because the period character is currently used in many
messages in the display-name portion of addresses, especially for
initials in names, and therefore must be interpreted properly. IN THE
FUTURE, period may appear in the regular syntax of phrase.
One could reasonably conclude back then that putting a period in a
phrase was going to be okay sometime later, or at least it wasn't a big
deal. RFC 5322 removed that particular sentence, though. It seems
most MUAs were cleaned up (I think everyone agrees those messages are
rare), but there are a few holdouts (who have no pressure to change,
since all other MUA authors apparently read all of RFC 5322).
Of course, should nmh be improved to be able to make a correctly formed
address when presented with obsolete (or for that matter, any other
incorrect forms) and produce a correctly formed (and the wanted) address
to use in replies, etc, then I am not going to object.
Well ... I guess my feelings are pretty straightforward:
- People are seeing these messages, in the wild, today.
- The syntax is VALID, according to the RFC. I know, the RFC does
say they're obsolete, but parsing them correctly is a MUST, and
we do not parse those messages correctly. Yes, we will DISPLAY
it correctly, but that's because in most places if the address
parser fails we just output whatever junk we have there. Really, I
can't think that qualifies as 'parsing' (an RFC requirement) in any
meaningful sense.
I just don't consider this to be a very high priority task. If I
occasionally get a message to reply to with an address that fails, I
just correct it manually. Fortunately for me that is very rare (so
rare I don't recall the last time it happened.) If that ever became a
regular enough occurrence that it started annoying me, I'd just make a
script that would correct the bad form for me (and at the same time, do
my best to get the problem fixed at the sender's end.)
I would direct you to the other messages on the list; people have tried,
and basically at least in one documented case a co-worker refused to fix
it.
As for it being a high priority ... you know how open source projects
work, right? Everyone works on what they want to.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers