Re: [Nmh-workers] Dealing with missing From: header during send.

[Ken Hornstein]

>Rather that adding code to fiddle with the cache, potentially breaking things,
>and in any case, making it even harder to use mhl-format than it is now,
>I'll suggest an alternative solution.
>
>Split the implementation of formataddr() into two parts, one which does
>what its name suggests now, and just formats an address, and the other that
>does the duplicate supression (internally I suspect it is pretty much
>like this already).

Alright, I see where you're going.  The (minor) wrinkle is that this
address duplicate supression is only for (formataddr) when it is inside
of repl.  That only makes things mildly more complicated, not terrible.

>The problem with adding something like (clearaddr) is that it makes different
>things happen to other lines in the format file, depending whether than happen
>to come before, or after, the use of this new function, which would make the
>construction of format files even more error prone than it now is.

Yeah, I think you've convinced me.  Earl, you happy with this?  Any
suggestions on what we want to call this new function?  formataddr2
comes to mind, but that seems to be a terrible name to me.  concataddr?

>ps: incidentally, Tethys had a point - no matter what you do, you can't
>figure out what address to use just from addresses in the headers of the
>message you're replying to .. just consider messages on this list (like
>this message) - where are any of your addresses in the headers of this
>message?   If you were subscribed to the list with more than one address,
>how could you tell which one resulted in the copy you're reading now?

I understand his point, but my point is that while in theory it may
be possible to ask Google for some new header, in practice I strongly
think any request like that would just get ignored.  I'd be happy to
be proven wrong, though.  So we have to work with the tools that
we have today.

I've been thinking about this, though, and I think that I'd be happy
enough with being able to list email lists that I subscribe to in
my components file.  So if a message is on nmh-workers, I know which
"role" I want to use for that message.  Now that I think about it,
I can probably do some reasonable wildcard matching that will make
things a lot shorter.  Picking a role for a new message is harder,
but not terrible with some extensions to comp.

>On the other hand, Tethys' X-Envelope-From is just Return-Path and should
>be there already.

Yup, that's true.

--Ken