Re: [Nmh-workers] Dealing with missing From: header during send.
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
t...@example.com%
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.
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 e...@earlhood.com, 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
[Nmh-workers] extraneous header lines
mhshow outputs a lot of (too many) extraneous header lines.
mhshow -form mhl.null outputs no header lines.
so, i used to keep putting ignores= entries in ~/Mail/mhl.headers and use
mhshow -form mhl.headers
now, i've given up, and my mhshow is filtered by an intelligent version of
perl -ane 'if($_=~/^\S+: \S+|^\t \S+/){next}else{print}'
two ideas for improvement:
1) mhshow -form mhl.null should display Date, To, From and Subject
2) allow for globs like ignores=X-* and ignores=List-*
?
steve
--
___
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.
It's already fairly easy to do this with replcomps:
From: %{X-Envelope-To}Tethys %{X-Envelope-To}%|Tethys
t...@example.com%
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.
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 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.
In the message dated: Mon, 09 Jan 2012 20:56:07 CST, The pithy ruminations from Earl Hood on Re: [Nmh-workers] Dealing with missing From: header during send. 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.
On Tue, Jan 10, 2012 at 4:56 AM, Ralph Corderoy ra...@inputplus.co.uk 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.
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.
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
[Nmh-workers] request for mh-format printf operator
In the message dated: Tue, 10 Jan 2012 15:19:34 EST,
The pithy ruminations from Ken Hornstein on
Re: [Nmh-workers] Dealing with missing From: header during send. were:
= 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.
=
Well...as long as you're already looking at that mess...
I'd like to see the addition of a new mh-format function %(printf).
Building and customizing message parts using %(putstr) somewhat
works, but is seriously ugly, because %(putstr) compresses repeated
whitespace within a string and doesn't parse printf formatting such as
\n.
A new function that simply passes it's input string to printf would be
very helpful.
Thanks,
Mark
___
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.
On Tue, Jan 10, 2012 at 2:19 PM, Ken Hornstein k...@pobox.com 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.
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] More autoconf poo: BSD42
On Mon, 09 Jan 2012 15:12:43 -0500 Ken Hornstein k...@pobox.com wrote: This code has two purposes: if you have a in the GECOS field, it substitutes in your login name in to your real name field. Personally I always found this feature a bit dubious, and from my experience not much supports that. I propose we just junk this support. since none of my other tools support '' expansion in the gecos field i can't use it even if nmh did keep doing it. so, i am +1 for removal. The other use of BSD42 seems to be in msh.c; basically, if we get interrupted in a signal, longjmp() out of the signal handler back to the main command loop. I guess this code was before signals interrupted system calls? Anyway, I am thinking that this can be junked as well. Any objections? no objection from me on that. if a system lacks posix signals it will likely also lack an ansi c compiler. (Okay, for purists; BSD42 also controls the use of the MIME content cache, for reasons I do not pretend to understand). maybe just remove the #ifdef :-) ? -- Paul Vixie ___ 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.
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.
Date:Tue, 10 Jan 2012 18:36:59 -0500 From:Ken Hornstein k...@pobox.com 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
