[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] repl doesn't like return address

From: Ken Hornstein
Subject: Re: [Nmh-workers] repl doesn't like return address
Date: Thu, 03 Sep 2015 01:35:24 -0400

>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
>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,

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

As for it being a high priority ... you know how open source projects
work, right?  Everyone works on what they want to.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]