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

[bergman]

In the message dated: Mon, 16 Jan 2012 13:28:22 GMT,
The pithy ruminations from Andreas Wittkemper on 
 were:
=> On 01/10/12 16:56, berg...@merctech.com wrote:
=> 
=> 
=> > It seems as if you're talking about composing a reply based on the
=> > identity of the received message.
=> >
=> > I've been using a wrapper around "repl" for about 5 years that will parse
=> > the original message, match the identity against a list, and populate
=> > the reply (From:, Reply-To:, Fcc:, signature) as needed.
=> >
=> > I'm happy to contribute this code (perl) to the list.
=> >
=> > Mark
=> 
=> Does your extension do anything about the mime and attachments problem when 
you reply to those ?

I try to do a little--tiny--bit of MIME handling:

check for a "text/html" part
check for "application/*" parts

if either is found, use:
/usr/bin/mhshow -type text -type multipart -type message 
-nopause -nomoreproc
to attempt to create a 'clean' message as the basis for the
reply

this is semi-successful, crude, and far from universal.

Mark

=> E.g. when you reply to mail with an attachment you will get everything 
quoted in your reply mail
=> .
=> 
=> Andreas
=> 
=> 
=> Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - 
Amtsgericht Dortmund, HRB 14
=> 952 - Geschäftsführer: Detlef Eppig - Vorsitzender des Aufsichtsrats: 
Dominique Gaillard
=> 
=> 
=> 
=> ___
=> Nmh-workers mailing list
=> Nmh-workers@nongnu.org
=> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=> 
=> 

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Andreas Wittkemper]

On 01/10/12 16:56, berg...@merctech.com wrote:



It seems as if you're talking about composing a reply based on the
identity of the received message.

I've been using a wrapper around "repl" for about 5 years that will parse
the original message, match the identity against a list, and populate
the reply (From:, Reply-To:, Fcc:, signature) as needed.

I'm happy to contribute this code (perl) to the list.

Mark


Does your extension do anything about the mime and attachments problem when you 
reply to those ?
E.g. when you reply to mail with an attachment you will get everything quoted 
in your reply mail.

Andreas


Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht 
Dortmund, HRB 14952 - Geschäftsführer: Detlef Eppig - Vorsitzender des 
Aufsichtsrats: Dominique Gaillard



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Thu, Jan 12, 2012 at 8:07 PM, Ken Hornstein  wrote:
> Alright, I've meditated on this for a while, and I went back and read
> Robert Elz's and Earl Hood's arguments carefully.  And ... I found myself
> more persuaded by Robert's arguments than Earl's (sorry, Earl).

What you did is definitely sufficient.  I looked at the
default replcomps, and realized that what I would
expect as proper behavior would break it and likely
the myriad of local customizations that people are using.

Thanks for making the changes.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jeffrey Honig]

On Thu, Jan 12, 2012 at 21:29, Ken Hornstein  wrote:

> >You are the only person with the fortitude to go near that code lately,
> >so all I can say is 'please document the new regime' ;-)
>
> Well, the new functions are documented in the mh-format man page, and I
> even put in the bits about repl's duplicate supression for formataddr
> since that was news to me!
>
> >More seriously, whatever else you discovered as you got there is worth
> >documenting as well.  It's certainly one of the least understood bits of
> >the code base ...
>
> Maybe I'll add some comments to fmt_compile.c and fmt_scan.c.  It's not
> _terrible_ (other than that code being horribly non-reentrant, but I
> guess that didn't matter too much back then).  Also the memory management
> is pretty much non-existent as well (I guess for single-shot commands,
> it again wasn't a big deal).  But once I got into the middle of it
> you could follow it reasonably well.  And I will note that Oliver Kiddle,
> Josh Bressers, Peter Maydell, and Jeffrey Honig have all been inside of
> that code, so if I get hit by a truck there is still hope for nmh! :-)
>

In other words, no good deed goes unpunished...

Thanks

Jeff

-- 
Jeffrey C. Honig 
http://www.honig.net/jch
GnuPG ID:14E29E13 
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>You are the only person with the fortitude to go near that code lately,
>so all I can say is 'please document the new regime' ;-)

Well, the new functions are documented in the mh-format man page, and I
even put in the bits about repl's duplicate supression for formataddr
since that was news to me!

>More seriously, whatever else you discovered as you got there is worth
>documenting as well.  It's certainly one of the least understood bits of
>the code base ...

Maybe I'll add some comments to fmt_compile.c and fmt_scan.c.  It's not
_terrible_ (other than that code being horribly non-reentrant, but I
guess that didn't matter too much back then).  Also the memory management
is pretty much non-existent as well (I guess for single-shot commands,
it again wasn't a big deal).  But once I got into the middle of it
you could follow it reasonably well.  And I will note that Oliver Kiddle,
Josh Bressers, Peter Maydell, and Jeffrey Honig have all been inside of
that code, so if I get hit by a truck there is still hope for nmh! :-)

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-01-12, at 18:07 PM, Ken Hornstein wrote:

> Comments & bug reports welcome!

You are the only person with the fortitude to go near that code lately, so all 
I can say is 'please document the new regime' ;-)

More seriously, whatever else you discovered as you got there is worth 
documenting as well.  It's certainly one of the least understood bits of the 
code base ...

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

Alright, I've meditated on this for a while, and I went back and read
Robert Elz's and Earl Hood's arguments carefully.  And ... I found myself
more persuaded by Robert's arguments than Earl's (sorry, Earl).

To that end, I've just pushed some code to master that implements
the %(concataddr) function.  This adds an email address to the str
register without involving the duplicate supression cache in any
way.  In my testing it works exactly like we talked about, and I
believe with this we have a more useful tool for making decisions
on which From: line to use (I just discovered that one of my mail
accounts uses the Delivered-To: header, which is just about perfect).

I also added a %(putlit) function, since in my conversations with Mark
Bergman that's what we decided would be useful for him (adds the output
of str to the message, without any space compression or control conversion).

Comments & bug reports welcome!

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Wed, Jan 11, 2012 at 9:50 AM, Ken Hornstein wrote:

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

I think I like a function to clear the cache instead.  I think
there is use to have duplicates removed (which concataddr would
not do).  Those that use clear cache function use at their
own risk and its existence does not affect existing components
files.

Of course, having names str registers would be an alternative,
but that is likely more work.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Tethys]

Ken Hornstein writes:

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

Agreed, to a point. It's not the tools that you have to work with
that are the problem but the data. You need to find out the recipient's
address before you can reply using the same address. Looking at the
envelope is the best way to get that. In a "normal" mail message, that
information simply isn't present, so we need some way of approximating
it. Once we have an address, putting it into the composed message is
trivial.

Google might actually be receptive to adding an appropriate header.
Who knows? But even if they are, there will be plenty of others that
aren't, and we need a solution to deal with those cases. How about using
X-Envelope-To if it's present (I didn't make the header name up, it
was already in widespread use with that name[1]). If it's not, you could
possibly attempt to parse the Received headers, or maybe look for the
last Delivered-To header if present. Neither are ideal, but lacking the
envelope addressee, they'll probably give you a reasonable best guess[2].
Or at least a better guess than looking at the To/Cc headers. Maybe
allowing a user to hardcode an address to use with regexps to select
from a list would be good enough for most. Personally, I use over 500
addresses, so it wouldn't work well for me without a fair amount of
work :-)

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

Yep. I added it for symmetry because I was adding X-Envelope-To at
the same time, without thinking about whether the information was
already there in another header.

Tet

[1] And any other similar headers in common use that do the same thing.

[2] But parsing Received headers correctly is *hard*.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

ken wrote:
 > >allowing for very general purpose substitution lets the user use
 > >almost any tool they want to do their scripting -- if mh forgets to
 > >provide some parameter the user needs (time of day?  is it a holiday? 
 > >am i on my laptop?), then they still have access to that information
 > >via external mechanisms.  limiting me to regexps in the components
 > >file seems, well, limiting.
 > 
 > Well Paul, you know where the code is ... have at it, my friend!

of course.  i'm still in brain-storming mode.  :-)

paul

 > 
 > In all seriousness ... yes, I'd like that as well.  But I'm limited
 > in time and energy.  If we add one function to the components that
 > makes this workable for me, then I'm happy.  This is what Lyndon &
 > I were talking about earlier in terms of an embedded scripting
 > language available for use in the components file.  Adding one
 > format function, I can do now.  Figuring out a more general solution ...
 > well, that's complicated, because that will involve some significant
 > design work to make it useful enough.  I'm not afraid of complicated,
 > but I realize that for ME, "complicated" means, "probably won't get
 > done for a year or two, if I'm lucky".  But please, if you or anyone
 > else wants to tackle this work don't let me stand in your way.
 > 
 > --Ken
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 34.0 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>allowing for very general purpose substitution lets the user use
>almost any tool they want to do their scripting -- if mh forgets to
>provide some parameter the user needs (time of day?  is it a holiday? 
>am i on my laptop?), then they still have access to that information
>via external mechanisms.  limiting me to regexps in the components
>file seems, well, limiting.

Well Paul, you know where the code is ... have at it, my friend!

In all seriousness ... yes, I'd like that as well.  But I'm limited
in time and energy.  If we add one function to the components that
makes this workable for me, then I'm happy.  This is what Lyndon &
I were talking about earlier in terms of an embedded scripting
language available for use in the components file.  Adding one
format function, I can do now.  Figuring out a more general solution ...
well, that's complicated, because that will involve some significant
design work to make it useful enough.  I'm not afraid of complicated,
but I realize that for ME, "complicated" means, "probably won't get
done for a year or two, if I'm lucky".  But please, if you or anyone
else wants to tackle this work don't let me stand in your way.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

ken wrote:
 > 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
 ...
 > ...  Picking a role for a new message is harder,
 > but not terrible with some extensions to comp.

these ideas would both be improvements on the status quo, but
i really don't want to have to list my mailing lists in my components
file.  i'd like the From: address, the Fcc: header, maybe Reply-to:,
etc, all to be fillable/replaceable using script output.  (i'm
thinking in the spirit of command expansion using $(...) in the shell.)

allowing for very general purpose substitution lets the user use
almost any tool they want to do their scripting -- if mh forgets to
provide some parameter the user needs (time of day?  is it a holiday? 
am i on my laptop?), then they still have access to that information
via external mechanisms.  limiting me to regexps in the components
file seems, well, limiting.

paul

 > 
 > >On the other hand, Tethys' X-Envelope-From is just Return-Path and should
 > >be there already.
 > 
 > Yup, that's true.
 > 
 > --Ken
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 31.1 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Robert Elz]

Date:Tue, 10 Jan 2012 18:36:59 -0500
From:Ken Hornstein 
Message-ID:  <201201102337.q0anaxcx019...@hedwig.cmf.nrl.navy.mil>

  | >My question is: If the str buffer is zeroed, or set, via %(lit), should
  | >the cache be automatically cleared?
  | 
  | I am leaning towards no; does anyone else have an opinion?

You're right, it shouldn't, and none of the existing functions should
do that (I was behind in reading list e-mail, when I read the earlier
messages on this thread I could see you were running into the duplicate
address supression code, but then I see you had worked it out before I
got around to mentioning it).

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).

For compat, the (formataddr) function needs to do both halves, then we just
add a new user callable function, that simply formats an address and sticks
it in the buffer, without duplicate supression.

Then, when you're just formatting an address to use it in a match test,
you'd use the new function, and when you're formatting an address to put
in a header, you'd use (formataddr).

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.

kre

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?
This is not an nmh bug, and it requires MTA assistance to handle - I wouldn't
be surprised if google already has a solution to this (perhaps not 
X-Envelope-To, but perhaps something) and if not, asking them to provide one
would not be unreasonable - you should be told which delivery address resulted
in the message being placed in your mailbox (otherwise how do you ever
find out which of your addresses is the one the spammers have found?)

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


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Valdis . Kletnieks]

On Tue, 10 Jan 2012 18:36:59 EST, Ken Hornstein said:

> regression.  Okay, I would agree that it's a bit bogus to send email from
> yourself and cc'ing yourself, but I can see it happening.

Actually, I know a lot of people who will cc: or bcc: themselves on important
mail, specifically so that they know their mail did in fact at least make it to
the MTA for delivery.



pgpjFOvo3PsOJ.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Bill Wohler]

I would be content with a default that is something like this:

  From: `mhparam Signature` <$USER@`cat /etc/mailname`>

/etc/mailname is a Debianism. While I'm not advocating that nmh rely on
/etc/mailname, I think it would be handy to allow the Debian developer
to configure nmh in a way to make use of it.

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/
GnuPG ID:610BD9AD


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>I would assume that if I use %(lit) to clear the str buffer, it
>should clear the cache.

Well, it's not like this is documented anywhere, so I think we're in uncharted
territory :-)

>This may be acceptable.  I'm not sure if there are components files
>that depending on the caching, even after %(lit) is used.

Well, I think they ALL depend on it.

Right now if you have duplicate email addresses (like on a From: and
a cc: line) they get silently cleaned up.  Seems to me this is the "right"
behavior.  But if %(lit) cleared out the address cache, then you could get
duplicates there.  Okay, that's not tragic, but to me it feels like a feature
regression.  Okay, I would agree that it's a bit bogus to send email from
yourself and cc'ing yourself, but I can see it happening.

>My question is: If the str buffer is zeroed, or set, via %(lit), should
>the cache be automatically cleared?

I am leaning towards no; does anyone else have an opinion?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Tue, Jan 10, 2012 at 2:19 PM, Ken Hornstein  wrote:
> Ow.  Damn your eyes, Earl ... I now have a headache from staring at the
> damn mh-format code.

I'm glad you decided to look at the code since I was not
looking forward to it myself.

> But, on the upside ... I figured out the issue here.
>
> The problem is not technically with accessing the same component
> again.  It's actually accessing the same _ADDRESS_ again via
> %(formataddr).  Let me explain.
>
> There is a cache inside of replsbr.c of addresses that were seem by
> the %(formataddr) function; if you try to insert the same email address
> twice, it will silently stop you from doing so.  This is obviously to
> prevent duplicate email addresses from appearing in To: and cc: lines.
>
> So what is happening to you is when you try to use the "to" component
> again to make the decision to construct your From: line, it doesn't
> get addded to the list because formataddr considers it a duplicate.

I would assume that if I use %(lit) to clear the str buffer, it
should clear the cache.

> So, possible solutions?
>
> - Have %(putaddr) clear out the address cache via a callback to replsbr.c.
>  This is a behavior change, and could result in duplicate addresses
>  appearing in a cc: line (for example).

I do not like this.  I would think %(lit) should clear the cache
since it empty the str register.

> - Create a new mh-format function (perhaps %(clearaddr) ?) that explicitly
>  clears out the address cache.

This may be acceptable.  I'm not sure if there are components files
that depending on the caching, even after %(lit) is used.

> The first one is easy, but might have unintended consequences.

Agreed.

> The second
> is more complicated, but not terrible and is arguably more correct.  Thoughts?

My question is: If the str buffer is zeroed, or set, via %(lit), should
the cache be automatically cleared?

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>I'm currently using Claws Mail as my principle interface to nmh, largely
>for threading and some other interface improvements vs. exmh. One huge
>'win' of Claws Mail over bare nmh is that it makes the selection of
>identity (From:, Reply-To:, Fcc:, signature) very simple when composing a
>new message.  Having said that, I still use comp directly for much of my
>mail, so I'm also in the position of editing headers to set my identity
>per-message.

As an aside ... does Claws use any of nmh underneath of the hood?  I confess
I've not heard of it until now.

>Because of this, I think that nmh should continue to permit the absence
>of any defined From: at all phases until "send" is called.

I think we're all in agreement here; if you want to have a component file
which doesn't include a From: by default, we're not proposing to change
that.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Yes, that works, but as I noted, when in a replcomps, further
>attempts to access {to} and other components return empty
>values.

Ow.  Damn your eyes, Earl ... I now have a headache from staring at the
damn mh-format code.

But, on the upside ... I figured out the issue here.

The problem is not technically with accessing the same component
again.  It's actually accessing the same _ADDRESS_ again via
%(formataddr).  Let me explain.

There is a cache inside of replsbr.c of addresses that were seem by
the %(formataddr) function; if you try to insert the same email address
twice, it will silently stop you from doing so.  This is obviously to
prevent duplicate email addresses from appearing in To: and cc: lines.

So what is happening to you is when you try to use the "to" component
again to make the decision to construct your From: line, it doesn't
get addded to the list because formataddr considers it a duplicate.

So, possible solutions?

- Have %(putaddr) clear out the address cache via a callback to replsbr.c.
  This is a behavior change, and could result in duplicate addresses
  appearing in a cc: line (for example).
- Create a new mh-format function (perhaps %(clearaddr) ?) that explicitly
  clears out the address cache.

The first one is easy, but might have unintended consequences.  The second
is more complicated, but not terrible and is arguably more correct.  Thoughts?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Tue, Jan 10, 2012 at 4:56 AM, Ralph Corderoy  wrote:
> Hi Earl,
>
>>   %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
>>   %(formataddr{to})%(formataddr{cc})%(formataddr(me))\
>>   %<(match example1.com)From: e...@example1.com\n\
>>   %?(match example2.com)From: eh...@example2.com\n\
>>   %|From: e...@earlhood.com\n%>\
>
> Does this shed any light?  match seems to work here.
>
>    $ c='%(lit)%(formataddr 
> %<{reply-to}%?{from}%?{sender}%?{return-path}%>)%(formataddr{to})%(formataddr{cc})%(formataddr(me))'

Yes, that works, but as I noted, when in a replcomps, further
attempts to access {to} and other components return empty
values.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[bergman]

In the message dated: Mon, 09 Jan 2012 20:56:07 CST,
The pithy ruminations from Earl Hood on 
 were:
=> On Mon, Jan 9, 2012 at 8:26 PM, Lyndon Nerenberg wrote:
=> 
=> > And my interpretation of me is:
=> >
=> > 1) No From:, no message gets sent.
=> 
=> Yep.  Not sure if there is a
=> consensus on imposing this behavior, but I fail to
=> see why not.  Sites that want to enforce a specific
=> >From at the MTA/MSA level can always overwrite what
=> the MUA provides (and technically should since nothing
=> forbids an MUA from inserting any mail header it wants).
=> 

I agree with this.

=> > 1a) The 'user' MUST configure the From:.
=> 
=> When using nmh, I occassionally edit the From: in my
=> editor (Vim) to reflect different identities I'm known
=> as, so any default user setting would basically set
=> what is initially inserted into the draft message before
=> the editor is launched.

I'm currently using Claws Mail as my principle interface to nmh, largely
for threading and some other interface improvements vs. exmh. One huge
'win' of Claws Mail over bare nmh is that it makes the selection of
identity (From:, Reply-To:, Fcc:, signature) very simple when composing a
new message.  Having said that, I still use comp directly for much of my
mail, so I'm also in the position of editing headers to set my identity
per-message.

Because of this, I think that nmh should continue to permit the absence
of any defined From: at all phases until "send" is called.

=> 
=> Now, if nmh had the ability to preset the From: based
=> on which identity I received the message under...  Definitely
=> a feature I like about Gmail since there are 3 identities
=> I work under on a daily basis.

It seems as if you're talking about composing a reply based on the
identity of the received message.

I've been using a wrapper around "repl" for about 5 years that will parse
the original message, match the identity against a list, and populate
the reply (From:, Reply-To:, Fcc:, signature) as needed.

I'm happy to contribute this code (perl) to the list.

Mark

=> 
=> I currently deal with the issue by having variant components
=> files and then shell aliases for comp and repl to use
=> which one I desire at the time.  But this requires I know
=> which identity to use beforehand (for repl) vs having repl
=> automatically doing it for me.
=> 
=> --ewh
=> 
=> ___
=> Nmh-workers mailing list
=> Nmh-workers@nongnu.org
=> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=> 


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

ken wrote:
 > Here is my $0.02 on this topic:
 > 
 > - Lyndon is completely correct in assessment of how email has changed; like
 >   he says, nmh is based on how things used to be.  It's time we dealt better
 >   with the new world order.
 > 
 > In that vein, here's what I propose for future changes:
 > 
 > - We supply all of the component templates with the appropriate line to
 >   incorporate nmh's idea of the local mailbox.   This may require an mhl
 >   extension, and we'll need to run "comp"'s template through mhl.
 > - We allow the user to configure a local mailbox name in the .mh_profile.
 > - If this entry doesn't exist, it's constructed like it is done today
 >   (using localname out of mts.conf plus username, falling back to username +
 >   local domainname).  Well, okay, how it was done without REALLYDUMB.
 > - If a draft gets fed to post without a From: header, kick back an error.
 >   This will have to be intelligent to deal with existing users with old
 >   component files.

this is probably obvious, but since we're proposing scripting
solutions to the 'choose correct From:  for a reply" problem, i'd like
to nominate this (i.e., scripting) for new messages as well.  again,
the point being that there often isn't "a local mailbox name" -- there
are many of them, and choosing one can be done in various ways.  asking
the user is one way, running a script another.

paul

 > 
 > Thoughts?
 > 
 > --Ken
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 36.0 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Errr... no. This has nothing to do with lack of capabilities in nmh.
>I use the envelope addressee because it's the canonical source of
>data that tells you to whom the message was addressed. But if it's
>not available, then no amount of work done by nmh can compensate
>for the missing data. In that case, you could instead match on the
>To/Cc lines and accept that most of the time it will be fine, but
>in some cases it'll get it wrong. You can do this with nmh today
>using replcomps.

I guess my point was that it doesn't seem like we have enough smarts today
in mh-format to do everything I want to do; at least it doesn't seem like
it's possible today, or if it is it would be something that would be very
close to being completely unreadable.  But I could be wrong.  But since
we have a number of people saying they would like to see something new
added to nmh, sounds like we either need to document things better,
fix some bugs or add a few things in mh-format, or add something new.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Tethys]

Ken Hornstein writes:

>>That relies on some sendmail.mc config to add an X-Envelope-To header
>>to my mail on the way through:
>
>So all I have to do is get Google to change their entire server
>configuration to match the (lack of) capabilities in my mailer.
>Problem solved!

Errr... no. This has nothing to do with lack of capabilities in nmh.
I use the envelope addressee because it's the canonical source of
data that tells you to whom the message was addressed. But if it's
not available, then no amount of work done by nmh can compensate
for the missing data. In that case, you could instead match on the
To/Cc lines and accept that most of the time it will be fine, but
in some cases it'll get it wrong. You can do this with nmh today
using replcomps.

If you're proposing adding some new way of achieving the same
functionality that makes it easier for the end user, then I'm
all for that, of course.

Tet

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>It's already fairly easy to do this with replcomps:
>
>   From: %<{X-Envelope-To}Tethys %{X-Envelope-To}%|Tethys 
> %>
>
>That relies on some sendmail.mc config to add an X-Envelope-To header
>to my mail on the way through:

So all I have to do is get Google to change their entire server
configuration to match the (lack of) capabilities in my mailer.
Problem solved!

I hope people can appreciate that while this may be an option FOR SOME,
it is hardly a option we can use as a general solution.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ralph Corderoy]

Hi Earl,

>   %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
>   %(formataddr{to})%(formataddr{cc})%(formataddr(me))\
>   %<(match example1.com)From: e...@example1.com\n\
>   %?(match example2.com)From: eh...@example2.com\n\
>   %|From: e...@earlhood.com\n%>\

Does this shed any light?  match seems to work here.

$ c='%(lit)%(formataddr 
%<{reply-to}%?{from}%?{sender}%?{return-path}%>)%(formataddr{to})%(formataddr{cc})%(formataddr(me))'
$
$ scan -format "$c"'%(putstr)' last
Earl Hood , nmh-workers@nongnu.org, ralph
$ scan -format "$c"'%(match maker)%(putnum)' last
0
$ scan -format "$c"'%(match Hood)%(putnum)' last
1
$ scan -format "$c"'%<(match maker)t%|f%>' last
f
$ scan -format "$c"'%<(match Hood)t%|f%>' last
t

Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Tethys]

Lyndon Nerenberg writes:

>> Now, if nmh had the ability to preset the From: based
>> on which identity I received the message under...  Definitely
>> a feature I like about Gmail since there are 3 identities
>> I work under on a daily basis.
>
>Yes, please!

It's already fairly easy to do this with replcomps:

From: %<{X-Envelope-To}Tethys %{X-Envelope-To}%|Tethys 
%>

That relies on some sendmail.mc config to add an X-Envelope-To header
to my mail on the way through:

LOCAL_CONFIG
HX-Envelope-From: $f
HX-Envelope-To: $u

But that's all there is to it.

Tet

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Mon, Jan 9, 2012 at 9:05 PM, Ken Hornstein wrote:
> I do the same thing as you, and I would like the same thing.  There are
> technical issues (you don't normally have access to the identity you received
> the message at when repl gets it), but we could at least make it work
> better than we do now.

It seems it should be doable via mh-format expressions, but
either I do not fully understand the engine's behavior or
it has some serious bugs.

It seems I am unable to access a component more than once
in some cases.  When I do, the second time, I get nothing.

Here is something that I tried for replcomps (I've added
special lines to highlight the expressions of interest):

  %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
  %<(nonnull)%(void(width))%(putaddr To: )\n%>\
  %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
  %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
  %<{fcc}Fcc: %{fcc}\n%>\
  -  ---
  %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
  %(formataddr{to})%(formataddr{cc})%(formataddr(me))\
  %<(match example1.com)From: e...@example1.com\n\
  %?(match example2.com)From: eh...@example2.com\n\
  %|From: e...@earlhood.com\n%>\
  -  ---
  %<{subject}Subject: Re: %(putstr(trim{subject}))\n%>\
  %<{message-id}In-reply-to: %{message-id}\n%>\
  %<{message-id}References: %<{references}%(void{references})%(trim)%(putstr) %>
  %(void{message-id})%(trim)%(putstr)\n%>\
  
  On %(lmonth{date}) %(mday{date}), %(year{date}) at \
  %02(putnumf(hour{date})):%02(putnumf(min{date})), \
  %<{from}%(friendly{from})%|you%> wrote:

In the CODE-OF-INTEREST, I try to gather all the addresses
in the original message into the string register so I
can then do a match against for a given domain so I can
output a different From:.

The problem is that my match checks always fail, even though
that I know the To: of the message being replied to has
example1.com in it.

Adding the following before or after match block, I do NOT
get an XXX: header printed:

  %<(nonnull)%(putaddr XXX: )\n\%>\

If I do not do the nonnull check, repl hangs.

If I put my CODE-OF-INTEREST at the top of replcomps,
then setting of the To: in the repl draft does not work.

Maybe I do not fully get mh-format expressions, but this
behavior is odd.  I would figure that references to
message components are immutable.

As an aside, it would be nice if named registers (i.e "variables")
were supported.  Maybe it is time to come up with a replacement
for mh-format.

--ewh

P.S. I am running a local dev build based on nmh 1.3, so I
do not know if the new nmh 1.4 includes any changes to
mh-format.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Now, if nmh had the ability to preset the From: based
>on which identity I received the message under...  Definitely
>a feature I like about Gmail since there are 3 identities
>I work under on a daily basis.

I do the same thing as you, and I would like the same thing.  There are
technical issues (you don't normally have access to the identity you received
the message at when repl gets it), but we could at least make it work
better than we do now.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-01-09, at 18:56 PM, Earl Hood wrote:

> Now, if nmh had the ability to preset the From: based
> on which identity I received the message under...  Definitely
> a feature I like about Gmail since there are 3 identities
> I work under on a daily basis.

Yes, please!

This is something I face every day.  I contract many companies, and for each 
prefers email from their specific domain.  I get away with this using somewhat 
rude header rewriting in sendmail, but only when I send mail from my primary 
laptop.  In another mail submission system I'm working on, there is a growing 
lua component that hooks in to allow for very intelligent header re-writing.

nmh 3 here we come ...

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Mon, Jan 9, 2012 at 8:26 PM, Lyndon Nerenberg wrote:

> And my interpretation of me is:
>
> 1) No From:, no message gets sent.

Yep.  Not sure if there is a
consensus on imposing this behavior, but I fail to
see why not.  Sites that want to enforce a specific
>From at the MTA/MSA level can always overwrite what
the MUA provides (and technically should since nothing
forbids an MUA from inserting any mail header it wants).

> 1a) The 'user' MUST configure the From:.

When using nmh, I occassionally edit the From: in my
editor (Vim) to reflect different identities I'm known
as, so any default user setting would basically set
what is initially inserted into the draft message before
the editor is launched.

Now, if nmh had the ability to preset the From: based
on which identity I received the message under...  Definitely
a feature I like about Gmail since there are 3 identities
I work under on a daily basis.

I currently deal with the issue by having variant components
files and then shell aliases for comp and repl to use
which one I desire at the time.  But this requires I know
which identity to use beforehand (for repl) vs having repl
automatically doing it for me.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-01-09, at 18:29 PM, Ken Hornstein wrote:

> - If a draft gets fed to post without a From: header, kick back an error.
>  This will have to be intelligent to deal with existing users with old
>  component files.

Yes, this is the right place to do it.  With a reasonable diagnostic message it 
can hint at the user to configure their components file.  And with a non-zero 
exit status, it can hint at cron jobs that something is wrong.  All this 
combined with a reasonable set of release notes makes the whole thing fair game 
as far as I can think it through.

--lyndon




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

Here is my $0.02 on this topic:

- Lyndon is completely correct in assessment of how email has changed; like
  he says, nmh is based on how things used to be.  It's time we dealt better
  with the new world order.

In that vein, here's what I propose for future changes:

- We supply all of the component templates with the appropriate line to
  incorporate nmh's idea of the local mailbox.   This may require an mhl
  extension, and we'll need to run "comp"'s template through mhl.
- We allow the user to configure a local mailbox name in the .mh_profile.
- If this entry doesn't exist, it's constructed like it is done today
  (using localname out of mts.conf plus username, falling back to username +
  local domainname).  Well, okay, how it was done without REALLYDUMB.
- If a draft gets fed to post without a From: header, kick back an error.
  This will have to be intelligent to deal with existing users with old
  component files.

Thoughts?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-01-09, at 18:15 PM, Ken Hornstein wrote:

> And my interpretation is that Lyndon is saying:
> 
> - We should have the user configure their email address at some point
> - We should then use that as the "From:" header.

And my interpretation of me is:

1) No From:, no message gets sent.
1a) The 'user' MUST configure the From:.

It's really not that hard to do.  I don't think there are too many system 
utilities that use MH to inject mail, and if there are, they will just have to 
be updated before they can use nmh 2.  Nothing to see here, move along ...

--lyndon

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>It seems that Lyndon is arguing that it would be better to just have
>From:   lambda
>to prompt the MTA to rewrite the header. I just tried to send a message
>like that and it worked, but nmh added a 
>Sender: lam...@a.g4.wien.funkfeuer.at
>line, which it doesn't do in the other cases. So likely this is not
>equivalent to REALLYDUMB?

My reading of the code is that should only happen if you're not using
draft_from masquerading.

And my interpretation is that Lyndon is saying:

- We should have the user configure their email address at some point
- We should then use that as the "From:" header.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

The days of guessing the construction of local and remote email addresses went 
out the door with the ARPANET, /etc/hosts, and the multiuser VAX.  In this day 
and age of personal workstations, port 25 filters, and MX records, any attempt 
at synthesizing a senders email address from uids, hostnames, or any other 
random bits of the environment is nothing more than wishful thinking.  If it 
works, it's by happy coincidence, not by design.

Today, and email address identifier is something that is set by site policy, 
independent of the runtime environment.  Sometimes that policy can be set in 
the site's MSA or MTA, which gives the impression to a naïve user that the MUA 
magically figured this out all by itself, when in fact the underlying mail 
transport infrastructure filled in those values based on a header re-write 
policy.
And more often than not, that policy is wrong.

An email address is no longer associated with a specific login on a specific 
host, and this has been the case for nearly two decades now.  An email address 
is an identifier tied to a specific individual or service.  In the case of an 
individual, you carry it around with you.  When you choose to use it, you have 
to configure that identifier into whatever bit of software or hardware you use 
to send email from.  Pretty much every MUA in existence today requires you to 
configure an address for the From: header before you can even use it.  That nmh 
doesn't is simply an artifact of its age.  It is no longer viable for any MUA 
to try to guess at what a From: header should look like, and it's unbelievable 
that having to enter this information, once, is any burden on the end user.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Harald Geyer]

> >I propose quite the opposite: Why not install sane components
> >files on installation but still allow users to rely on header
> >rewritting if they like to?
> 
> Okay, here's my question to you: the draft file has a completely nonexistent
> From: line.  What do we use as the From line in the message, and what
> do we use as the MAIL FROM: message as part of the SMTP transaction?

Well, if we can't come up with anything better, then just whatever we
use now.

Some details:

I write this message without a From line, but
it will be filed in my outbox with a line of
From:Harald Geyer 

I think this is okay.

IIRC to get this I had to add a line to /etc/nmh/mts.conf:
localname: a.g4.wien.funkfeuer.at

Before I knew about mts.conf I got this filed in my outbox:
From:Harald Geyer 

While this might not be ideal, it worked for several years and nobody
ever complained about bad From: headers. People did complain to me
about subtle errors in mime headers, so clearly I'm sending mail to
people, who care about proper message construction.

It seems that Lyndon is arguing that it would be better to just have
From:   lambda
to prompt the MTA to rewrite the header. I just tried to send a message
like that and it worked, but nmh added a 
Sender: lam...@a.g4.wien.funkfeuer.at
line, which it doesn't do in the other cases. So likely this is not
equivalent to REALLYDUMB?

Personally I like the
From:Harald Geyer 
version most and I think it would be ok to force people to properly
configure their localname, but I guess that this question really isn't
important as people, who make use of header rewriting, do so no matter
what the exact form of the From line.

Following the principle of least surprise I'd just go with whatever
was the default in the past. Anybody who wants system wide components
plus header rewriting will need to know what he is doing anyway.

Harald

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>I propose quite the opposite: Why not install sane components
>files on installation but still allow users to rely on header
>rewritting if they like to?

Okay, here's my question to you: the draft file has a completely nonexistent
From: line.  What do we use as the From line in the message, and what
do we use as the MAIL FROM: message as part of the SMTP transaction?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Why not have a check in send/post that if the From: header
>is missing, it reports an error and aborts the operation?

That's clearly one of the things we have to do.

But there are some things to do that aren't so obvious.  Like, what do we
do about setting up someone's default component file?  It would suck to be
a new user to nmh, start typing a message, and discover that you can't
send it with the default configuration.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Harald Geyer]

 
> Why not have a check in send/post that if the From: header
> is missing, it reports an error and aborts the operation?

I propose quite the opposite: Why not install sane components
files on installation but still allow users to rely on header
rewritting if they like to?

I think installing sane personalized components files is largely
uncontroversial. The only drawback I can think of is, that on
updates of the default components files, users with existing
installations won't get these updates without manual intervention.

I guess, this would only affect systems with many users, which are
quite rare these days and on such systems the admin could still
make up his mind how to ensure proper headers in outgoing mail.
 
> I think this will likely be needed regardless since anyone
> could delete out any pre-defined From: header in the
> draft before send/post receives it.

So what? The worst thing that would happen might be that the
message gets discarded somewhere or somebody has to take extra
effort to figure out how to reply to it.

There is already lots of malformed mails out there anyway and
nmh in particular doesn't try much to keep users from sending
bad messages in other cases. (Like sending 8bit messages without
adding mime headers, etc.)

Harald

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Earl Hood]

On Mon, Jan 9, 2012 at 12:39 PM, Paul Fox wrote:

> (i just checked, and realized that i'd be affected -- i have scripts
> that sometimes munge the draft to create a From: header based on current
> folder, and i see by the way i wrote them that there's an assumption
> that there's no such header by default.)

Why not have a check in send/post that if the From: header
is missing, it reports an error and aborts the operation?

I think this will likely be needed regardless since anyone
could delete out any pre-defined From: header in the
draft before send/post receives it.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

jeffrey wrote:
 > On Mon, Jan 9, 2012 at 13:09, Paul Vixie  wrote:
 > 
 > > On Mon, 09 Jan 2012 13:01:04 -0500
 > > Ken Hornstein  wrote:
 > >
 > > > >Rather than guess, we should treat the absence of a From: header in
 > > > >an outgoing message as a configuration error and abort the send. This
 > > > >change makes the creation of a components file with a 'From:' header
 > > > >mandatory; the code that initializes the Mail/ folder should
 > > > >probably be extended to prompt for a default From address which is
 > > > >then used to create a minimal components file.
 > > >
 > > > So, what do people think of this idea?  This would be arguably the
 > > > most correct solution, but it would be a significant change from
 > > > the way nmh has behaved in the past.
 > >
 > > i think this is fine. nmh should gradually encourage people to make a
 > > few changes here and there.
 > >
 > >
 > If we are going to change the behavior in any significant way then we
 > should make it a major release (i.e. 2.0).

bear in mind that many people may not normally do their own builds --
i haven't needed to, for years now, thanks to debian/ubuntu
packaging.  if it's a big change, and configuring around it is
difficult (i don't think this one is, particularly), then a run-time
switch for backwards compatibility would be preferable to a build-time
switch.

(i just checked, and realized that i'd be affected -- i have scripts
that sometimes munge the draft to create a From: header based on current
folder, and i see by the way i wrote them that there's an assumption
that there's no such header by default.)

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.2 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>> >Rather than guess, we should treat the absence of a From: header in
>> >an outgoing message as a configuration error and abort the send. This
>> >change makes the creation of a components file with a 'From:' header
>> >mandatory; the code that initializes the Mail/ folder should
>> >probably be extended to prompt for a default From address which is
>> >then used to create a minimal components file.
>> 
>> So, what do people think of this idea?  This would be arguably the
>> most correct solution, but it would be a significant change from
>> the way nmh has behaved in the past.
>
>i think this is fine. nmh should gradually encourage people to make a
>few changes here and there.

Alright, to move things along I'm going to make DUMB and REALLYDUMB
the defaults just to move along on my current work, and we can figure out
what to do regarding the implementation details of this change later.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Valdis . Kletnieks]

On Mon, 09 Jan 2012 08:38:15 PST, Lyndon Nerenberg said:

> Rather than guess, we should treat the absence of a From: header in an
> outgoing message as a configuration error and abort the send. This
> change makes the creation of a components file with a 'From:' header
> mandatory; the code that initializes the Mail/ folder should probably be
> extended to prompt for a default From address which is then used to
> create a minimal components file.

That's probably the only actually correct solution.  Yes, it's not in any
way backward-combatable, but it's probably what we should be doing
going forward.

Jeff's point regarding a 2.0 release is probably moot - I think we got enough
in the pipe already that the next release will have to be a 2.0 anyhow. ;)



pgpfib9EMDtbe.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jeffrey Honig]

On Mon, Jan 9, 2012 at 13:09, Paul Vixie  wrote:

> On Mon, 09 Jan 2012 13:01:04 -0500
> Ken Hornstein  wrote:
>
> > >Rather than guess, we should treat the absence of a From: header in
> > >an outgoing message as a configuration error and abort the send. This
> > >change makes the creation of a components file with a 'From:' header
> > >mandatory; the code that initializes the Mail/ folder should
> > >probably be extended to prompt for a default From address which is
> > >then used to create a minimal components file.
> >
> > So, what do people think of this idea?  This would be arguably the
> > most correct solution, but it would be a significant change from
> > the way nmh has behaved in the past.
>
> i think this is fine. nmh should gradually encourage people to make a
> few changes here and there.
>
>
If we are going to change the behavior in any significant way then we
should make it a major release (i.e. 2.0).

Thanks

Jeff

-- 
Jeffrey C. Honig 
http://www.honig.net/jch
GnuPG ID:14E29E13 
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Vixie]

On Mon, 09 Jan 2012 13:01:04 -0500
Ken Hornstein  wrote:

> >Rather than guess, we should treat the absence of a From: header in
> >an outgoing message as a configuration error and abort the send. This
> >change makes the creation of a components file with a 'From:' header
> >mandatory; the code that initializes the Mail/ folder should
> >probably be extended to prompt for a default From address which is
> >then used to create a minimal components file.
> 
> So, what do people think of this idea?  This would be arguably the
> most correct solution, but it would be a significant change from
> the way nmh has behaved in the past.

i think this is fine. nmh should gradually encourage people to make a
few changes here and there.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Rather than guess, we should treat the absence of a From: header in an
>outgoing message as a configuration error and abort the send. This
>change makes the creation of a components file with a 'From:' header
>mandatory; the code that initializes the Mail/ folder should probably be
>extended to prompt for a default From address which is then used to
>create a minimal components file.

So, what do people think of this idea?  This would be arguably the
most correct solution, but it would be a significant change from
the way nmh has behaved in the past.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-01-08, at 18:36 PM, Ken Hornstein wrote:

> I cannot decide what is the correct behavior here; opinions?  Seems like
> both of these behaviors are wrong in their own way.  I am working
> on the assumption that we will make DUMB the default, unless people really
> want to include code to handle MMDF and UUCP addresses.

They are both wrong in terms of RFC582[12], although the REALLYDUMB case gives 
the submission agent a fighting chance of rewriting the the envelope and 
message From addresses into something that will work in practice.  But there 
are no guarantees that REALLYDUMB+MSA-rewrite will work, either.  E.g. an 
RFC4409 submission agent is free to reject a message with an unqualified MAIL 
FROM.

Rather than guess, we should treat the absence of a From: header in an outgoing 
message as a configuration error and abort the send. This change makes the 
creation of a components file with a 'From:' header mandatory; the code that 
initializes the Mail/ folder should probably be extended to prompt for a 
default From address which is then used to create a minimal components file.

--lyndon

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers