Re: does anyone use nmh's Google OAuth mechanism?

[Bob Carragher]

On Fri, 09 Sep 2022 18:48:40 -0700 David Levine  sez:

> Bob wrote:
>
> > On Thu, 08 Sep 2022 06:29:32 -0700 David Levine  sez:
> > >
> > > OAuth can also be used to send.  It would be enabled using these nmh
> > > send(1)/post(8) switches:
> > > -saslmech xoauth2 -authservice gmail
> > >
> > > after logging in with mhlogin(1).
> > >
> > > David
> >
> > I too use fetchmail(1).  (Too lazy to change.  B-)  But I use it
> > _just_ to fetch email from Gmail to my laptop, not to send.  I
> > never knew it had that capability 
>
> Whoops, I should have said that OAuth can be used to
> authenticate when sending.  fetchmail can't send.
>
> David

Oh, phew!  I know my manpage-comprehension skills aren't the best
and my google-fu isn't top-notch, but I was really worried there
for a while.  B-)

Bob

Re: does anyone use nmh's Google OAuth mechanism?

[Bob Carragher]

On Thu, 08 Sep 2022 06:29:32 -0700 David Levine  sez:

> Michael wrote:
>
> > David Levine  wrote:
> > > If you use nmh's mhlogin(1) to login to Gmail, then you
> > > use nmh's Google OAuth mechanism.  Please let me know
> > > if you use it.
> >
> > I try do, but I think that I fell back to fetchmail on my
> > laptop.
>
> Glad to hear that.
>
> OAuth can also be used to send.  It would be enabled using these nmh
> send(1)/post(8) switches:
> -saslmech xoauth2 -authservice gmail
>
> after logging in with mhlogin(1).
>
> David

I too use fetchmail(1).  (Too lazy to change.  B-)  But I use it
_just_ to fetch email from Gmail to my laptop, not to send.  I
never knew it had that capability 

Bob

Re: Surprising MIME Type from Android.

[Bob Carragher]

Hi Ralph,

Checking email going back to 2013, I could not find a single
occurrence of that pattern.

Bob

On Mon, 25 Jul 2022 10:28:52 +0100 Ralph Corderoy  sez:

> Hi again,
>
> > I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename.
> ...
> >  2 image/*  2985K
> ...
> > I haven't checked yet, but I assume it violates the RFCs.
>
> It does by my reading of
> https://datatracker.ietf.org/doc/html/rfc2045#section-5.1
>
> Something for mhfixmsg(1) to correct?
>
> > _com.samsung.android.email_135816585189000
> > Content-Type: image/*; name="20220721_180552.jpg"
> ...
> > which suggests a Samsung Galaxy S9 took the photo but that doesn't meant
>
> Has anyone else got an example?
>
> pick -sea 'content-type.*\*'
>
> Note, don't use ‘--content-type’ as that only searches the header's
> fields.
>
> -- 
> Cheers, Ralph.

Re: In Memoriam: Norman Z. Shapiro 1932-2021

[Bob Carragher]

This sounds like a wonderful gesture, and I would like to help
out if I can.

Bob

On Sat, 29 Jan 2022 07:14:08 -0800 David Levine  sez:

> Conrad wrote:
>
> > > Two thoughts... Should we send condolences back to David,
> > > not the announce list, highlighting the impact Norm's
> > > concept has had on a small bunch of people still using his
> > > Mail Handler program to this day, and that he chipped in
> > > with useful history to the end?
> >
> > Fully support this.  It's an amazing achievement.
>
> Agreed.  And I like your suggestion, Ralph, of thanking (or
> dedicating to?) = Norm in the next release.
>
> David



On Sat, 29 Jan 2022 09:57:09 + Ralph Corderoy  sez:

> Hi,
>
> Norm's son-in-law wrote:
> > On October 14, 2021, Norman Shapiro passed away from natural
> > causes at the age of 89 years.
>
> Sad news, though a good innings.  Norm was last active on the
> list in the middle of July.
>
> Two thoughts... Should we send condolences back to David, not
> the announce list, highlighting the impact Norm's concept has
> had on a small bunch of people still using his Mail Handler
> program to this day, and that he chipped in with useful history
> to the end?  They might like to be reminded that something he
> designed in the '70s is still in use all these years later.
>
> And how about we thank Norm publicly with the next nmh release
> which is spit-and-polished enough to be worthy?
>
> -- 
> Cheers, Ralph.

Re: Message header formatting

[Bob Carragher]

On Sun, 06 Jun 2021 10:22:38 -0700 Jon Steinhart  sez:

> Ken Hornstein writes:
> > >Out of curiosity, then what is the value of "extras?"  Was there
> > >a time it provided value, before header content exploded?
> >
> > Well, I don't mean to crap on anyone, Robert Elz in particular, but
> > you can kind of see what I would call the original MH thinking here:
> >
> >https://lists.nongnu.org/archive/html/nmh-workers/2014-06/msg00084.html
> >
> > But I think Robert comes from an era BEFORE everyone started cramming
> > non user-readable metadata into email headers.  Whether or not that is a
> > good idea is not really relevant at this point ... that ship has sailed.
> > Honestly I'd be up for changing the default mhl file at this point, but
> > I am sure there will be objections :-)
> >
> > --Ken
>
> I would be in favor of removing the extras from the default files.
> Most of what I'm seeing in headers is stuff like spam filter rankings.
> Never understood what I was supposed to do with this except use it to
> tune spam to get through.  Also piles of versioning information for
> microsoft projects which is also useless to me, like what would I as
> a recipient do with x-ms-office365-filtering-correlation-id?
>
> Jon



On Sun, 06 Jun 2021 20:30:09 +0300 Greg Minshall  sez:

> fwiw, i'm up to 732 ignored components.  but, i'm happy adding them as
> needed -- always the optimist that some day, some vital, otherwise
> un-acknowledged, header will show up in an e-mail i am viewing.
>
> cheers, Greg



On Mon, 07 Jun 2021 03:26:42 +0700 Robert Elz  sez:

> Date:Sun, 06 Jun 2021 12:29:15 -0400
> From:Ken Hornstein 
> Message-ID:  <20210606162916.bb968d5...@pb-smtp2.pobox.com>
>
>   | But I think Robert comes from an era BEFORE everyone started cramming
>   | non user-readable metadata into email headers.
>
> That I did.   Back then people occasionally created new and meaningful
> new header fields - not often, but there were some.   That was also a time
> when more users understood e-mail and had more control over what their
> mailers did.
>
>   | Honestly I'd be up for changing the default mhl file at this point, but
>   | I am sure there will be objections :-)
>
> If you're imagining that I am going to be one, then ... I finally gave
> up and deleted the Extras line from my mhl.format back in January.
> These days all the newly invented fields are nonsense (most don't deserve
> to exist at all, much less ever be seen by a human - or anything else).
>
> kre



On Sun, 06 Jun 2021 22:22:31 +0100 Ralph Corderoy  sez:

> Hi,
>
> kre wrote:
> > Back then people occasionally created new and meaningful new header
> > fields - not often, but there were some.
>
> I have ‘extras’ in place from back when it was useful to see the
> occasional new header and decide whether to nuke it.  I've been
> thinking for a while that rather than search for the next /^$/ to skip
> to the meat of the email, I should play around with a new user account
> to concoct an .mh_profile, etc., from scratch for the modern,
> what-are-they-thinking, era.
>
> I see no value in extras being in the defaults for a new user.
>
> -- 
> Cheers, Ralph.

+1 from me for changing the default, and removing ignores/extras.

Thanks for the historical insight, guys!

I did think that that might be the reason to maintain them.  And,
in fact, on rare occasion (maybe 1x/decade) seeing "new" headers
was useful.  One particular example is the mailing list links:
I'm on other lists where I (more) frequently post but am not an
admin, and I sometimes receive direct messages from people asking
me to remove them from the list -- and I point them to similar
links in those messages.

Thus, I felt somewhat loathe to recommend the default be to not
use them at all -- which would making it likely that they are
never used by new users.  That said ... one could also suggest
the current "default" as an alternative in the mhl(1mh) man page.

On the other hand, for a new user, it might be overwhelming to
create their own list of "ignores" directives.  I have 100
entries.  Greg mentioned 732.  I wouldn't be surprised if some
others have even more.  For us old fogeys, who've built this up
over decades, it's not that hard to add another one occasionally.
But that might be a reason for a new user to give up on NMH.

So, I've come around to Robert's reversal ... only 5 months after
him.  B-)  But, I couldn't bear to just delete the entries, so I
commented them out instead.  B-)

Bob

P.S.  +1 to Ralph's idea for looking into what might be a
"better" set of defaults overall for a new user.

Re: Message header formatting

[Bob Carragher]

On Sat, 05 Jun 2021 19:35:40 -0400 Ken Hornstein  sez:

> >> Brilliant idea! I too would use an inverse match logic. Shorter rules,
> >> easier to apply, probably faster.
> >>
> >> G
> >
> >I guess that I should interpret that as no, there isn't such an incantation
> >but since I brought it up then it's my job to write the code so I will when
> >I get a chance.
>
> You don't need to write anything.  From mhl(1):
>
>The component "Extras" will output all of the components of the message
>which were not matched by  explicit  components,  or  included  in  the
>ignore list.  If this component is not specified, an ignore list is not
>needed since all non-specified components will be ignored.
>
> So just remove "extras".

Argh.  -_-###  Thanks for the poke, Ken!  B-)

Out of curiosity, then what is the value of "extras?"  Was there
a time it provided value, before header content exploded?

I've had it in my $MAIL/mhl.format probably from when I first
started using MH -- probably because it came from the mhl(1mh)
man page.  In fact, currently that page specifies the "extras" is
part of the default:

   The default format file is:

; mhl.format
;
; default message filter for `show'
;
:
overflowtext="***",overflowoffset=5
leftadjust,compwidth=9
ignores=msgid,message-id,received,content-type,content-transfer-enco
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
To:
cc:
From:formatfield="%(unquote(decode{text}))"
Subject:decode
:
extras:nocomponent
:
body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust

My file has some additional complications, but otherwise it's a
near copy of this default, with around 50 "ignores" lines, which
I had accumulated over the years -- though, surprisingly, not in
maybe the last 5 or so.  This is not to say that I don't see
"unwanted" components -- Ken's reply came with a bunch of
"X-Spam_*"s that I'd been too lazy to add "ignores" for.  But, my
existing set is large enough that I can ignore this small number
of header "spam."

Bob

Re: Very large folder

[Bob Carragher]

Hi Norm,

On Sat, 05 Jun 2021 22:58:38 +0100 Ralph Corderoy  sez:

> Given those 1,702 messages are precious, you may want to pick them
> and refile them to a dedicated folder.  You could use ‘refile -link
> +newfolder ...’ to keep them in +gone and just create hard links to the
> new folder's version, or without the -link to have them move from +gone.

Note that the default for refile(1mh) is -nolink, which rmm(1mh)s
the message from the source folder (+gone).  It does not rm(1)
it.  The result is that you will still have 2 files with hard
links to the same inode, but the old +gone message file will be
renamed.  If you want to have just 1 (hard) link to those
contents, you'll also need to explicitly specify refile(1mh)'s
-unlink option (because -nounlink is the default).

Also, check your ~/.mh_profile file to see whether you've
specified "refile" options (particularly ones that might conflict
with your expectations).

Yes, this is based on the confusion I was going through a couple
years back that the list (and Ralph) helped me figure out.  B-)
I'm hoping you can avoid that.  B-)

Bob

Re: Bug reported regarding Unicode handling in email address

[Bob Carragher]

On Wed, 02 Jun 2021 17:47:42 -0400 Ken Hornstein  sez:

> >It's early morning for me, and I'm still at least a liter of Diet Mountain 
> >Dew
> >away from being sufficiently caffeinated to be positive, but that looks like
> >"not totally correct, but a lot closer than what we have now".
> >
> >In particular, that will accept overlong and illegal utf-8 codepoints, and
> >probably misbehaves in strange and unusual non-ascii/non-utf-8 things
> >like iso2022-jp.
>
> So, the DETAILS are complicated.

Which is why I have nothing to add to the main thread topic,
other than "sounds good to me!"  B-)

[snip]
>iso2022-jp is
> SO complicated, I don't think we should even try and I get the sense
> everyone is migrating to UTF-8 for email anyway.

I can add one data point here, though:  I, and the folks I
correspond with in Japanese, made that switch by mid-2017.  Prior
to that, we used iso-2022-jp since it was all-ASCII in the years
before MIME-encoding became widely available.

And I know I was late to this party, and the people I correspond
with in Japanese are more likely to use a major "even for
dummies" type mailer (e.g. Gmail) than NMH.  (Sorry.  B-)
Actually _they_ had made that switch before me, and I kept
"complicating" things (a.k.a. "screwing up the email") by
continuing to use iso-2022-jp.  ^_^;;;

Fortunately, we've always used MIME-encoding in the "real name"
portions of our addresses!

Bob

Re: displaying Date using local timezone

[Bob Carragher]

Sounds about right.  B-)  --  Bob

On Mon, 03 May 2021 17:27:25 -0400 Steven Winikoff  sez:

> >I had an inkling that it might be bad for NMH to try to handle
> >DST calculations on its own;
>
> Tom Scott would agree:
>
>https://www.youtube.com/watch?v=-5wpm-gesOY
>
> This is probably the best explanation I've ever seen of why time
> zones and DST calculations induce madness.
>
>  - Steven
> -- 
> ___
> Steven Winikoff  | "Some men see things as they are and ask
> Montreal, QC, Canada |  'Why?'.  I dream things that never
> s...@smwonline.ca |  were and ask, 'Why not?'."
> http://smwonline.ca  |
>  |- Robert F. Kennedy

Re: displaying Date using local timezone

[Bob Carragher]

On Mon, 03 May 2021 09:30:46 +0100 Ralph Corderoy  sez:

> Hi Bob,

Hi Ralph,

This time you're not giving me happy-useful news.  B-D

> > > $ TZ=Australia/Lord_Howe date -d '01 Aug'
> > > 2021-08-01 00:00:00 +1030 Sun
> > > $ TZ=Australia/Lord_Howe date -d '01 Feb'
> > > 2021-02-01 00:00:00 +1100 Mon
> >
> > Wat.  -_-##
> >
> > Why?!  I can see some localities deciding that having their time zone
> > not be an integer number of hours offset can be more representative or
> > useful for them
>
> Yes, India is +05:30 with no DST.  And there are finer-grained ones,
> e.g.
>
> $ tz() { printf '%s  %s\n' `TZ=$1 date +%z` $1; } 
> $ for t in UTC Australia/Eucla; do tz $t; done
> +  UTC
> +0845  Australia/Eucla
> $

I had an inkling that it might be bad for NMH to try to handle
DST calculations on its own; hopefully it's not trying to do any
with time zones (but rather relying on system libraries that are
intended to figure out all that) 

> Perhaps some known-to-fail tests could be added to nmh's test suite.
>
> > but why mess with the DST offset, too?
>
> In Lord Howe's case it's so its time agrees with the mainland half the
> time.  Aussies.

More like "Humans."  B-)

> Why bother with DST in the first place?  Isn't it a relic of the
> pre-industrial era when farm labourers would rise by the sun to maximise
> work on the land?

Nope:  it's a relic of the Industrial Age/WW1:

 https://en.wikipedia.org/wiki/Daylight_saving_time

> I didn't bother adjusting one year, initially by accident, and given
> work was a bit flexible on hours it was quite simple to just adjust ‘my
> truth’ of time to local time for the odd appointment, TV programme
> schedule, etc.  Isn't the sudden switch for those that must live by the
> state's clock meant to harm health?

There are indications that, at least on the Monday after each
switchover, certain problems see spikes, such as car crashes and
heart attacks.  I personally wouldn't mind seeing DST eliminated.

> > At this rate, they might as well just create a server that calculates
> > the sun's position in the sky on a second-by-second basis and send out
> > that time accordingly for people to sync their computers to.  -_-#
>
> That occurred to me on the last switch and Google suggested its been
> done by others.  Though I think it might be better to produce a local
> time so my normal waking clock times are centred around the daylight.
> :-)

Well, that's what I meant:  depending on your longitude, the
server would give you a "local time," perhaps centered around the
daylight.  Though I also heard one proposal for just a universal
time (like UTC) that everyone uses (to avoid issues like "Is my
3pm your 10am or 11am?"), and you always do a conversion to
calculate your local time.  Both of these seem to require
computing devices, making it hard or impossible for us old fogeys
who still use _actual_ clocks.  B-)

> DST is generally odd.  The Yanks mostly have DST.  But not in Arizona.
> Except for Navajo Nation which is inside AZ.  But there's no DST in Hopi
> Nation which is inside Navajo Nation.
>
> $ tz() { printf '%s  %s\n' "`TZ=$1 date '+%z %Z'`" $1; } 
> $ for t in America/{Phoenix,Shiprock}; do tz $t; done
> -0700 MST  America/Phoenix
> -0600 MDT  America/Shiprock
> $
>
> And if you carry on up the Wakhjir Pass in Afghanistan then the clocks
> will switch from +0430 to +0800 as you enter the People's Most
> Democratic Uncensorious Republic of China.

Like I said:  "Humans."  B-)

Bob

Re: displaying Date using local timezone

[Bob Carragher]

Wat.  -_-##

Why?!  I can see some localities deciding that having their time
zone not be an integer number of hours offset can be more
representative or useful for them, but why mess with the DST
offset, too?  At this rate, they might as well just create a
server that calculates the sun's position in the sky on a
second-by-second basis and send out that time accordingly for
people to sync their computers to.  -_-#

Bob

On Sun, 02 May 2021 10:26:24 +0100 Ralph Corderoy  sez:

> Hi,
>
> Bob wrote:
> > I found that (zone) provides you your "standard time" UTC offset (in
> > minutes), regardless of (dst)'s result.
>
> nmh's code seems to assume DST means clocks wind forward sixty minutes,
> which isn't always true, e.g.
>
> $ TZ=Australia/Lord_Howe date -d '01 Aug'
> 2021-08-01 00:00:00 +1030 Sun
> $ TZ=Australia/Lord_Howe date -d '01 Feb'
> 2021-02-01 00:00:00 +1100 Mon
>
> One example is dlocaltime():
>
> #ifdef HAVE_STRUCT_TM_TM_GMTOFF
> tw.tw_zone = tm->tm_gmtoff / 60;
> if (tm->tm_isdst)   /* if DST is in effect */
> tw.tw_zone -= 60;   /* reset to normal offset */
> #else
> {
> static bool deja_vu;
>
> if (!deja_vu) {
> deja_vu = true;
> tzset();
> }
> }
> tw.tw_zone = -(timezone / 60);
> #endif
>
> Of ‘timezone’ in the #else branch, tzset(3p) says
>
>‘The external variable timezone shall be set to the difference, in
> seconds, between Coordinated Universal Time (UTC) and local standard
> time.’
>
> -- 
> Cheers, Ralph.

Re: check if message is in a particular sequence?

[Bob Carragher]

I don't know about others, Ralph, but I would prefer you don't
shut up soon.  B-)  This is how I learn (or am reminded) about
all kinds of features of awk/sed/bash/etc. -- in addition to NMH
stuff I never knew since I'm such a "basic" user -- and I really
appreciate the (perhaps unintended) lessons!  B-)

Bob

> From: Ralph Corderoy 
> To:   nmh-workers@nongnu.org
> Date: Sat, 01 May 2021 12:26:06 +0100
> Subject:  Re: check if message is in a particular sequence?
> 
> Hi Bob,
> 
> > Ah, thanks, Ralph!
> 
> Thanks to you for reminding me of awk's RS which, coupled with knowing
> the only words starting with a positive number are a message range,
> shortens my earlier sed and awk to
> 
> $ mark -list -seq public -seq private -seq notexist
> public: 1-3 42
> private (private): 3141 97057-97059
> notexist: 
> $
> $ mark -list -seq public -seq private -seq notexist |
> > gawk -v RS=' |\n' -F - '
> > $0+0 {u = NF==2 ? $2 : $1; for (n = $1; n <= u; n++) print n}
> > '
> 1
> 2
> 3
> 42
> 3141
> 97057
> 97058
> 97059
> $
> 
> -- 
> Cheers, Ralph.



> From: Ralph Corderoy 
> To:   nmh-workers@nongnu.org
> Date: Sat, 01 May 2021 12:43:27 +0100
> Subject:  Re: check if message is in a particular sequence?
> 
> Hi,
> 
> I wrote:
> > $ mark -list -seq public -seq private -seq notexist
> > public: 1-3 42
> > private (private): 3141 97057-97059
> > notexist: 
> > $
> > $ mark -list -seq public -seq private -seq notexist |
> > > gawk -v RS=' |\n' -F - '
> > > $0+0 {u = NF==2 ? $2 : $1; for (n = $1; n <= u; n++) print n}
> > > '
> > 1
> > 2
> > 3
> > 42
> > 3141
> > 97057
> > 97058
> > 97059
> > $
> 
> Silly me.  No need for gawk's regexp RS as the ‘42\nprivate’ which
> arrives with just the POSIX RS=' ' always has something to discard after
> the linefeed so there's no need to split it off into its own record.
> Thus, the above simplifies further, with the coercing of $1, into
> 
> mark -list -seq public -seq private -seq notexist |
> awk -v RS=' ' -F - '
>   $0+0 {u = NF==2 ? $2 : $1; for (n = $1+0; n <= u; n++) print n}
> '
> 
> -- 
> Cheers, Ralph.



> From: Ralph Corderoy 
> To:   nmh-workers@nongnu.org
> Date: Sat, 01 May 2021 12:59:16 +0100
> Subject:  Re: check if message is in a particular sequence?
> 
> I'll shut up soon.
> 
> > mark -list -seq public -seq private -seq notexist |
> > awk -v RS=' ' -F - '
> > $0+0 {u = NF==2 ? $2 : $1; for (n = $1+0; n <= u; n++) print n}
> > '
> 
> I thought I may as well create this and see if it gets used.
> 
> $ cat ~/bin/mhinseq
> #! /bin/sh
> 
> # Successfully exit only if the message is in the sequence.
> # usage: mhinseq seq 42
> 
> mark -list -sequence "${1?}" |
> awk -v RS=' ' -F - -v msg="${2?}" '
>   $0+0 &&
>   ((NF == 1 && $1+0 == msg) ||
>(NF == 2 && $1 <= msg && msg <= $2)) {f=1; last}
>   END {exit !f}
>   '
> $ 
> 
> -- 
> Cheers, Ralph.

Re: check if message is in a particular sequence?

[Bob Carragher]

Ah, thanks, Ralph!  So, if in one's use case one typically makes
use of the output of mark(1mh) immediately, then one is fine, as
it'll check for the message files' current statuses.  Or, at
least if one is really careful about it.

That is, until you're using Paul's enhancement to mark(1mh).  B-)

Bob

On Fri, 30 Apr 2021 22:23:11 +0100 Ralph Corderoy  sez:

> Hi Bob,
>
> > but would suffer compared with Ken's approach in that deleted messages
> > would still be reported
>
> I don't think they would; mark(1) doesn't output removed messages,
> whether by rmm(1) or through the filesystem.
>
> $ p -seq bob last:3
> 3 hits
> $ mark -list -s bob
> bob: 96916-96918
> $ rmm 96917
> $ mark -list -s bob
> bob: 96916 96918
> $ rm `mhpath 96918`
> $ mark -list -s bob
> bob: 96916
> $
>
> -- 
> Cheers, Ralph.

Re: check if message is in a particular sequence?

[Bob Carragher]

On Thu, 29 Apr 2021 12:49:40 -0400 Ken Hornstein  sez:

> >What's the fastest/easiest way to check if a particular message
> >is a member of a particular sequence?
> >
> >I thought I'd be able to compare the message number against the output
> >of "mark -list", but since sequences can be abbreviated with range
> >notation, that gets complicated quickly.  For example, message 6 is in
> >the sequence todo, but it's hard to tell from this:
>
> You can get the expanded list of messages in a sequence by doing this:
>
>   scan -format '%(msg)' sequence-name
>
> I think from there, it's easy.  I do not know of a better way, but it
> wouldn't surprise me if someone came up with something better.

I don't know that it's better, but my first thought was awk(1) to
parse the mark(1mh) sequence and search for the message number in
there.  It saves on filesystem access, but would suffer compared
with Ken's approach in that deleted messages would still be
reported -- which may or may not be what Paul wants.  Also, I'm
making assumptions about mark(1mh)'s output format, which is
wholly unnecessary (and more brittle than) if you use scan(1mh).

Checking for message # 6:

 $ echo 'todo: 1 3 5-8 13 16 46 49 52-53' | awk -v MY_MSG=6 -v RS=" " 
'BEGIN{missing=1;} /^[0-9]+$/{if (MY_MSG==$0) {missing=0; print "in sequence 
entry"}} /^[0-9]+-[0-9]+$/{split($0,ss,"-"); if (MY_MSG>=ss[1] && 
MY_MSG<=ss[2]) {missing=0; print "in sequence range"}} END{if (missing) print 
"not in sequence"}'
 in sequence range

Checking for message # 49:

 $ echo 'todo: 1 3 5-8 13 16 46 49 52-53' | awk -v MY_MSG=49 -v RS=" " 
'BEGIN{missing=1;} /^[0-9]+$/{if (MY_MSG==$0) {missing=0; print "in sequence 
entry"}} /^[0-9]+-[0-9]+$/{split($0,ss,"-"); if (MY_MSG>=ss[1] && 
MY_MSG<=ss[2]) {missing=0; print "in sequence range"}} END{if (missing) print 
"not in sequence"}'
 in sequence entry

Checking for (out-of-sequence) message # 99:

 $ echo 'todo: 1 3 5-8 13 16 46 49 52-53' | awk -v MY_MSG=99 -v RS=" " 
'BEGIN{missing=1;} /^[0-9]+$/{if (MY_MSG==$0) {missing=0; print "in sequence 
entry"}} /^[0-9]+-[0-9]+$/{split($0,ss,"-"); if (MY_MSG>=ss[1] && 
MY_MSG<=ss[2]) {missing=0; print "in sequence range"}} END{if (missing) print 
"not in sequence"}'
 not in sequence

Bob

Re: displaying Date using local timezone

[Bob Carragher]

On Tue, 16 Mar 2021 18:38:11 -0400 Ken Hornstein  sez:

> >Oh, sure.  I guess I was thinking of a more robust solution, that
> >wouldn't require editing that line when my timezone changes twice a
> >year.  :-)
>
> Boy, EVERYONE's a critic :-)
>
> You could use the %(dst) function to do the appropriate
> branching; you might need to duplicate a fair amount of the
> format instructions, though.  But ... maybe not.
>
> %<(dst{text})%(void(zone{text}))%(void(ne 
> -300))%|%(void(zone{text}))%(void(ne -240))%>
>
> I mean, substitute the correct values for -300 and -240.  I
> think that should set num to 1 or 0 depending if the timezone
> is equivalent to your local timezone, and then you can go from
> there.
>
> I think ... aside from that, we'd need a new format instruction
> that tests if a particular timestamp is in your local timezone.
> Related question:  HOW do we determine that?  I guess what nmh
> does is conver the time to a time_t, and then calls localtime()
> on it.  If the timezone offsets don't match, then it's not
> local.
>
> I understand what you're trying to do; but it's kind of
> limiting with the format language since you only have two
> variables and comparisons have to be done against literal
> values.

I ... MAY ... be able to finally contribute on this list.  B-)

If the problem is that you're trying to account for the two
Daylight Saving Time changeovers each year, then you don't
actually need to use (dst).

This thread and Ken's suggestion tempted me to fiddle with this
stuff, and I found that (zone) provides you your "standard time"
UTC offset (in minutes), regardless of (dst)'s result.  So, this,
grabbed from my mhl.format file, or something like it might
suffice for you:

 %(void(zone{text}))%<(eq -480)\
  (%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text})\
  %02(hour{text}):%02(min{text}):%02(sec{text}))%>

The "-480" bit is because my timezone is US Pacific.  As long as
the Date: header's timezone is the equivalent of PST or PDT, it
Just Works (TM).  Examples follow, using last Sunday morning's
DST switchover moment.

 *  These are all PST or PDT (should produce text):

% fmttest -format '%(void(zone{text}))%<(eq -480) 
(%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) 
%02(hour{text}):%02(min{text}):%02(sec{text}))%>' -raw 'Date: Sun, 14 Mar 2021 
01:59:59 -0800'
 (2021-03-14 01:59:59)
% fmttest -format '%(void(zone{text}))%<(eq -480) 
(%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) 
%02(hour{text}):%02(min{text}):%02(sec{text}))%>' -raw 'Date: Sun, 14 Mar 2021 
03:00:00 -0700'
 (2021-03-14 03:00:00)
%

 *  These are not PST or PDT (should produce nothing):

% fmttest -format '%(void(zone{text}))%<(eq -480) 
(%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) 
%02(hour{text}):%02(min{text}):%02(sec{text}))%>' -raw 'Date: Sun, 14 Mar 2021 
01:59:59 -0700'
% fmttest -format '%(void(zone{text}))%<(eq -480) 
(%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) 
%02(hour{text}):%02(min{text}):%02(sec{text}))%>' -raw 'Date: Sun, 14 Mar 2021 
03:00:00 -0800'
% fmttest -format '%(void(zone{text}))%<(eq -480) 
(%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) 
%02(hour{text}):%02(min{text}):%02(sec{text}))%>' -raw 'Date: Sun, 14 Mar 2021 
02:00:00 -0800'
%

As Ken mentioned before, just edit the number in the equality
check (the "eq -480" part) to be your timezone's # of minutes
away from UTC during "standard time."

Bonus:  no need to duplicate formatting instruction!  B-)

Hope that helps!

Bob

Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

On Sun, 14 Mar 2021 14:00:01 -0400 Ken Hornstein  sez:

> >Right.  I was hopeful that even that could be hidden.  For
> >example, if I use the Gmail web interface, the Received: headers
> >indicate that it came from Gmail itself (which makes sense).  I
> >was thinking it'd be useful to replicate that, even when I'm
> >actually sending it from my laptop _via_ the Gmail servers.
>
> Unfortunately, that decision is up to Gmail; that's not
> something we have control over.

Yeah ... it makes sense!

> >I use the "clientname" option because otherwise it is set to
> >"localhost.localdomain" (since I don't use "localname"), and that
> >has been shown to be a huge red spam flag.
> >
> >But, I think I should not use the "localname" option.
> >
> >If I correctly understand the implication of using it --
> >specifically, "the hostname nmh considers local" -- then I think
> >this would be problematic, as the alternative "local hostname"
> >I'd want to specify would be "gmail.com."  But then, any time I
> >email "f...@gmail.com," NMH would try to deliver that locally
> >instead of sending it to the Gmail server, no?  That'd result in
> >100% bounces, since not even my own Gmail username, "dnc2dnc," is
> >a valid login ID on my laptop.  I suppose "b...@gmail.com" would
> >work, except I don't know them and so don't email them except by
> >accident.  B-)
>
> So, we don't really do a wonderful job of explaining what
> "localname" does, because ... it's kind of complicated.  But,
> since you asked ...

I should know by now that nothing is ever simple with NMH.  B-)
But that's because it's to handle _email_.

> There's a function called "LocalName()" in nmh.  It returns ...
> the local name of the host.  It takes a single argument, an
> integer flag.  If the flag is 0, it will return the local
> hostname, EXCEPT if localname is configured.  Then it returns
> the value of localname.  If the flag is non-zero, then it
> returns the fully qualified local hostname (the output of
> gethostname() run through getaddrinfo() with AI_CANONNAME set).
> If for some reason you have localdomain set, then that will be
> appended to the local hostname.
>
> LocalName() is called with a flag value of '0' in all
> instances, with the exception of two cases:
>
> -  When a default value is used for clientname
> -  When a message-id is constructed (and you haven't overriden
>how message-ids are generated).
>
> The most consequential result of "localname" is the
> construction of email addresses.  Nmh's default idea of your
> email address is %(me)@%(myhost); if you change localname, that
> changes "myhost".  It's also used in the address parser as
> "default" host in a few places.  But that's the biggest change.
>
> But ... it doesn't affect mail delivery _at all_.  Unless you
> explicitly configure it (and doing that is possible, but it can
> be complicated; you would have had to do some extra work), nmh
> does not distinguish between "local" and "remote" messages.  If
> you tell it to deliver your email to gmail, that's what it's
> going to do regardless of how you configure "localname".  Once,
> very long ago, nmh (and MH) tried to be a little more
> intelligent about this sort of thing but it just made the
> address parser more complicated and caused many problems, so
> now unless you do extra work everything is delivered via your
> chosen submission method.  So feel free to use localname if you
> really want to (but I would personally recommend using
> Local-Mailbox in your .mh_profile).

Thanks for this (long) explanation, Ken!  That helped clarify a
couple of things for me.

I do use "Local-Mailbox" in my ~/.mh_profile, which was a change
recommended by this list a few years back (probably by you, Ken).
To be clear, I do _not_ use either "localname" or "clientname."

I also misstated my _current_ setup, based on my memory of what
it was for a long time -- which was to have some emails that I
would send to myself to be processed 100% locally (i.e. sending
it to user "bob" -- no "@" -- and using sendmail).  I
don't do that anymore, at least not when using NMH (and even then
I was sending via Berkeley mail and sendmail, and not NHM).

But it helps to know that if, for some reason, I did try using
NMH to send email to "bob" that it would still (based on my
configuration, which is to send emails via SMTP to Gmail) not do
any special "local user" processing, that it would send that to
the Gmail servers (and probably be rejected, or be sent to
"b...@gmail.com" ... which I've mistakenly done before B-).

_sigh_  Email is _so_ complicated.  Why did I ever agree to be my
own sysadmin?  B-)

Bob

Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

On Sun, 14 Mar 2021 13:32:07 -0400 Ken Hornstein  sez:

> >Documentation is usually the last thing to receive any love ...
> >if it receives much/any at all.  In that vein, would it make
> >sense to focus that "love" on mh-profile(5mh), and then provide
> >minimal information plus a "see mh-profile entry XYZ" for the man
> >page portion of any switch that provides a command-line mechanism
> >for an mh-profile entry that is precisely a duplication?  (One
> >bonus is that there's less sync-ing/harmonizing required across
> >multiple man pages.)
>
> Hm, that's not a bad idea.  We'd just need to spend the time ...

Always a question of time   B-/

Bob

Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

On Wed, 10 Mar 2021 08:39:18 -0500 Jerry Heyman  sez:

> On Wed, 10 Mar 2021 06:53:34 -0500, David Levine  wrote:
>
> > Bob wrote:
> > 
> > > I do see in the headers of your reply that the first "Received:"
> > > header uses "HiddenHostname" ... but also the FQDM(?) of your

Oops, that should've been FQD_N_.  B-)

> > > Verizon connection
> > 
> > FQDN, in this case for a dynamically assigned address so not
> > very useful to anyone other than Verizon.  Though they choose
> > to provide a geographic hint, and "fios", in the name.

Right.  I was hopeful that even that could be hidden.  For
example, if I use the Gmail web interface, the Received: headers
indicate that it came from Gmail itself (which makes sense).  I
was thinking it'd be useful to replicate that, even when I'm
actually sending it from my laptop _via_ the Gmail servers.

But:

> > > So, while I could hide the hostname of my laptop, I wouldn't be
> > > able to hide its "public"/ISP-assigned name (and IP address).
> > 
> > Right, as Tom noted:
> > 
> > Received: lines are generally added by each MTA that the message
> > passes through.  In this case it was smtp.gmail.com that added that;
> > it's not under your control.  You can probably modify the "Hikaru"
>
> Not sure this is helpful, but for years I've hidden my actual
> host I send mail from which is
>
> unix.hobbeshollow.com
>
> by putting the following entries in my mts.conf
>
> localname: hobbeshollow.com
> masquerade: draft_from mmailid username_extension
>
> This allows me to send email as je...@hobbeshollow.com.
> hobbeshollow.com is my domain.
> I pay a 3rd party to connect for my outbound mail from
> hobbeshollow.com a nominal fee annually because ATT turned off
> that capability about 18 months ago.
>
> > David
> > 
> > https://lists.nongnu.org/archive/html/nmh-workers/2021-03/msg00012.html
> > 
>
> jerry
> -- 
>  // Jerry Heyman   | The first law of economics is scarcity of
> //  Amigan Forever :-) | resources.  First law of politics, ignore
> \\ //   heymanj at acm dot org | the first law of economics
>  \X/   | -- Thomas Sowell



On Wed, 10 Mar 2021 12:10:18 -0500 Jerry Heyman  sez:

> On Wed, 10 Mar 2021 11:34:21 -0500, Ken Hornstein  wrote:
>
> > >by putting the following entries in my mts.conf
> > >
> > >localname: hobbeshollow.com
> > >masquerade: draft_from mmailid username_extension
> > 
> > Just FYI ... we got rid of all masquerade support ... 9 years
> > ago?  Definitely in nmh 1.4.  Now, we didn't get rid of the
> > FUNCTIONALITY.  Basically there were all these bizarre rules
> > around setting your "From" header that you could use the
> > masquerade entry to relax and we finally agreed that was
> > dumb, so we got rid of them and you can set your From header
> > to anything now.  That line isn't harming anything, but you
> > can safely remove it if your nmh is reasonably up to date.
>
> Ken,
>
> My nmh is 1.7, so reasonably current :-)
>
> Since I created during the nmh/mh early days, I've not noticed
> the masquerade support was incorporated.  the mts.conf file had
> served me well for all these years, and I just migrate the same
> one from upgrade to upgrade.  Since no longer necessary, I'll
> remove it!

(If it helps, my NMH is also version 1.7.)

I use the "clientname" option because otherwise it is set to
"localhost.localdomain" (since I don't use "localname"), and that
has been shown to be a huge red spam flag.

But, I think I should not use the "localname" option.

If I correctly understand the implication of using it --
specifically, "the hostname nmh considers local" -- then I think
this would be problematic, as the alternative "local hostname"
I'd want to specify would be "gmail.com."  But then, any time I
email "f...@gmail.com," NMH would try to deliver that locally
instead of sending it to the Gmail server, no?  That'd result in
100% bounces, since not even my own Gmail username, "dnc2dnc," is
a valid login ID on my laptop.  I suppose "b...@gmail.com" would
work, except I don't know them and so don't email them except by
accident.  B-)

Bob

> Thanks!
>
> jerry
>
> > 
> > The use of localname is fine; there are other ways to
> > accomplish that, but that's certainly one way of doing it.
> > 
> > --Ken
> > 
>
>
> -- 
>  // Jerry Heyman   | The first law of economics is scarcity of
> //  Amigan Forever :-) | resources.  First law of politics, ignore
> \\ //   heymanj at acm dot org | the first law of economics
>  \X/   | -- Thomas Sowell

Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

Documentation is usually the last thing to receive any love ...
if it receives much/any at all.  In that vein, would it make
sense to focus that "love" on mh-profile(5mh), and then provide
minimal information plus a "see mh-profile entry XYZ" for the man
page portion of any switch that provides a command-line mechanism
for an mh-profile entry that is precisely a duplication?  (One
bonus is that there's less sync-ing/harmonizing required across
multiple man pages.)

Bob

On Wed, 10 Mar 2021 03:39:56 -0500 Ken Hornstein  sez:

> >Ken:  I would not be opposed to documenting this particular
> >undocumented switch, though I can imagine why it was left
> >undocumented in the first place.
>
> Well, ABOUT that.  While it seems that -client was never
> documented, clientname (in mts.conf) was always documented, but
> not very well, back in the MH-6.8 days (I thought maybe
> clientname did something else, but no ... that's all it ever
> did).  Now, why was -client undocumented?  No idea!  The code
> has been there for approximately forever and we've just been
> bringing it forward.  Honestly, I think every switch to every
> MH/nmh program warrants SOME kind of documentation, because
> otherwise poor schmucks like me are puzzling over it years
> later.  Yes, put some documentation in for -idanno!  Maybe
> someone else will make use of it!
>
> And in CASE you're wondering ... -idanno is a special flag used
> to communicate annotation information up from post(8) to higher
> level programs.  It means, "Write annotation information to the
> file descriptor given as the argument to -idanno".  What that
> really means is that if you give post(8) something like
> "-idanno 8", then post will write a list of email addresses
> that it is sending to, one per line, to whatever is opened on
> file descriptor 8.  And then ... well, what actually happens
> AFTER post(8) does that is kind of complicated and involves
> some magic environment variables, and we should really document
> that all.  It's kind of documented in mh-profile, but not very
> well.
>
> --Ken

Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

(I've combined replies, but used the message ID of Tom's first
reply; hopefully that doesn't break the archive.  B-)

Thank you Tom, David, Krullen, and Ken, for your helpful replies!

Tom:  good point about false-looking Received: headers!  I
definitely want to avoid making my email look even more spammy
than it already is deemed by certain institutions.  B-[  Thanks
also for finding the "clientname" entry in mts.conf -- which I
had previously set to "Hikaru" because, without it, my emails
would use "localhost.localdomain" and look even more spammy.
(This was a fix that folks on this mailing list kindly gave me
back in 2018.  B-)

David:  thanks for the pointer to the "-client" option to
send(1).  (Actually, it's probably a reminder -- I feel like it
was mentioned back when someone gave me the "clientname" fix.)
I do see in the headers of your reply that the first "Received:"
header uses "HiddenHostname" ... but also the FQDM(?) of your
Verizon connection (and its IP address):

 Received: from HiddenHostname (pool-74-104-144-20.bstnma.fios.verizon.net. 
[74.104.144.20])
 by smtp.gmail.com [...]

So, while I could hide the hostname of my laptop, I wouldn't be
able to hide its "public"/ISP-assigned name (and IP address).

Ken:  I would not be opposed to documenting this particular
undocumented switch, though I can imagine why it was left
undocumented in the first place.

        Bob

On Sun, 07 Mar 2021 11:14:44 -0500 Tom Lane  sez:

> Bob Carragher  writes:
> > In emails that I send, if you look at the Received: header chain,
> > you'd find a line that resembles,
>
> >  Received: from Hikaru (x.comcast.net. [IP-address])
> > by smtp.gmail.com [...]
>
> Received: lines are generally added by each MTA that the message
> passes through.  In this case it was smtp.gmail.com that added that;
> it's not under your control.  You can probably modify the "Hikaru"
> part, as I believe that just comes from the HELO command your mail
> client uses.  I'm not sure which part of the nmh configuration
> that comes from, but it can't be too hard to find.
>
> Keep in mind that Received: lines that look falsified in any way
> are universally treated as a sure sign of spam.
>
>   regards, tom lane



On Sun, 07 Mar 2021 11:56:31 -0500 Tom Lane  sez:

> David Levine  writes:
> > Tom wrote:
> >> Received: lines are generally added by each MTA that the message
> >> passes through.  In this case it was smtp.gmail.com that added that;
> >> it's not under your control.  You can probably modify the "Hikaru"
> >> part, as I believe that just comes from the HELO command your mail
> >> client uses.  I'm not sure which part of the nmh configuration
> >> that comes from, but it can't be too hard to find.
>
> > It derives from the (hidden/undocumented) client switch to send(1).
> > I'll try sending this message with "send -client HiddenHostname".
>
> Ah.  And after digging around a bit, I found this on my own machine:
>
> $ cat /etc/nmh/mts.conf
> # nmh mail transport interface customization file.
> ...
> # Name shown in HELO header:
> clientname: sss1.sss.pgh.pa.us
>
> which you can match up against the first Received: line in my own
> outgoing mails.  So that's probably a better place to configure
> it than messing directly with send(1) switches.
>
>   regards, tom lane



On Sun, 07 Mar 2021 20:43:51 -0500 Ken Hornstein  sez:

> >It derives from the (hidden/undocumented) client switch to send(1).
> >I'll try sending this message with "send -client HiddenHostname".
>
> We should document that switch, I think.  Even internal switches probably
> should be documented.
>
> --Ken

Hiding one's email source username/hostname/ISP

[Bob Carragher]

A bit of Ken's reply on the recent "Is nmh suitable for managing
multiple email accounts?" thread got me wondering about one
aspect of Tim's potential needs -- namely, is there a way to hide
one's username, hostname, and even ISP in the email headers?

Here's the bit from Ken's reply:

On Sat, 06 Mar 2021 16:23:44 -0500 Ken Hornstein  sez:

[...snip...]
> The other school of thought (and obviously the one I subscribe to) is
> have nmh automatically figure out where to submit email and let it
> do it for you when you run "send".  This is, of cours, assuming that
> you are in a situation where you need to submit email to your email
> provider's submission host; today that is very common.  There are a
> bunch of ways to do that, but the simplest is to use nmh's "sendfrom"
> facility.  This is documented in send(1), and the way THIS works is
> nmh will automatically add specified switches to the post(8) command
> when it finds an appropriate entry in your profile based on your From:
> header (send(1) calls post(8) to do the actual sending).  So in your
> .mh_profile, you'd have entries like:
>
> sendfrom-u...@work.com: -server smtp.work.com -user u...@work.com -tls
> sendfrom-u...@personal.com: -server smtp.personal.com -user user -sasl
[...snip...]

In emails that I send, if you look at the Received: header chain,
you'd find a line that resembles,

 Received: from Hikaru (x.comcast.net. [IP-address])
by smtp.gmail.com [...]

(I'm not sure whether the mailing list will strip that out, so
you may or may not see it in this posting.)

"Hikaru" is my laptop's hostname, and Comcast is my ISP (the rest
is the dynamic IP address I'm assigned).

I'd much rather that people only know that I am a Gmail user,
using the "dnc2dnc" account.  I would like to not "leak" the
other information through the Received: chain.  (As far as I can
tell, the username I use to log onto my laptop is not revealed,
but I'll explicitly note that I'd want to hide that too.)

Would one use Ken's suggestion (or similar) to suppress that in
outgoing emails?

Or is there some more basic part of my setup that I should fix,
especially if I wanted to suppress this in _all_ my outbound
emails, and not just ones from a particular account?

Thanks!

Bob

Re: [PATCH] Make test-mhical pass with BSD yacc.

[Bob Carragher]

Speaking as an NMH leech-user B-), I think the NMH developers and
maintainers should get to specify what the preferred development
and build dependencies should be.  (Which, of course, has no
direct bearing on a user that's obtaining pre-built binaries via
a package, like I do via Ubuntu.  But it might make development,
or just building, on "limited" systems harder or impossible.)

Making use of a more modern scripting language for testing,
especially if it brings a comprehensive set of testing tools,
seems like it would be a win, if it makes it easier to create
better or more or more rigorous testing.  Would we expect a
theoretical new developer to insist on using only older tools?

Bob

On Sun, 20 Sep 2020 19:01:52 -0400 Ken Hornstein  sez:

> Sigh.  This is one of those tough ones.  It is nice to have a
> minimum dependency set, but   I see where you are coming
> from.  If we are voting I'd still rather write a simple C
> program to do what we need here, but I recognize that may be a
> minority view.



On Sun, 20 Sep 2020 18:02:58 -0400 David Levine  sez:

> And it could probably handle at least some of what's in the
> accessory test programs.  On the other hand, using an LCD of
> POSIX has advantages of portability and minimizing
> dependencies.



On Sun, 20 Sep 2020 16:01:01 -0500 Eric Gillespie  sez:

> If we're going to look at additional requirements imposed on
> developers, I would suggest that imposition would bring far
> more bang for the buck if it were a proper scripting language
> we can write the tests in.  This would not only have made this
> test-mhical problem easier to fix, but also the other one I
> fixed.  As Ralph says, we just don't see a way to have derive
> two different timestamp formats from a single source of truth
> with the tools available to us.  But with Perl or any of its
> competitors, it would be trivial.

Re: Default file processing for refile -- mv or ln?

[Bob Carragher]

Hi guys,

Sorry to take so long to follow up on this!  Ralph:  thank you
very much for this explanation!  This clarified for me what was
going on with -link/-nolink/-unlink (and -nounlink).  And it was
as you wrote (and the man page describes).

I have a theory as to why it seemed like the default combination
of flags -- -nolink -nounlink -- seemed to be doing different
things, which I suspect folks on this mailing list probably
figured out long ago:  newer messages that I rmm(1)-ed overwrote
the refiled message's old inbox inode, thus removing that hard
link (and leaving only the link for the inode in the
refile-folder) ... but only sometimes.

So, for example, I would refile a message and see:

 $ refile +SaveFolder 5
 $ ls -i Mail/inbox/,5 Mail/SaveFolder/1
 12345 Mail/inbox/,5
 12345 Mail/SaveFolder/1
 $ 

And sometimes, inc(1) would recreate that same message number,
and rmm(1)-ing it would overwrite the existing inode:

 $ inc
 Incorporating new mail into inbox...
 
   5+ 20/05/08 Ralph Corderoy Re: Default file processing for refile -- 
mv or ln?
 $ rmm 5
 $ ls -i Mail/inbox/,5 Mail/SaveFolder/1
 98765 Mail/inbox/,5
 12345 Mail/SaveFolder/1
 $ 

But because I don't "pack" my inbox, or auto-delete NMH-removed
files, some NMH-removed files (e.g. ",5") may never be
overwritten in this way.  Thus some NMH-removed files would still
be linked into refile(1) folder files, and others wouldn't -- and
so creating my confusion.

Again, thank you for your help!

Bob

On Fri, 08 May 2020 13:51:28 +0100 Ralph Corderoy  sez:

> Hi Bob,
>
> > What might make refile(1mh) apply the non-default ln(1) to
> > refiled message files -- as if the -link switch had been
> > specified -- instead of the default mv(1) -- as if -nolink had
> > been specified?  And only sometimes; not always.
>
> refile(1)'s -nolink doesn't stop link(2) being used IIRC.
> link() is always attempted, falling back on copying if source
> and destination folders are on different filesystems.
> strace(1) should confirm this.
>
> -link/-nolink alters whether the inode which is the source is
> left alone afterwards or removed.  And removing is the normal
> method of renaming or rmmproc.
>
> -unlink actually removes the source inode rather than ‘rmm’ it.
>
> Perhaps that will allow you to spot a pattern.
>
> -- 
> Cheers, Ralph.

Re: comp man page

[Bob Carragher]

On Wed, 29 Jul 2020 11:02:49 -0400 Ken Hornstein  sez:

> >As a user who _barely_ uses more than the basic features of NMH,
> >I was completely unaware of all this.  (That is my fault, of
> >course.  B-)  The SYNOPSIS section does not show that "-use"
> >optionally takes an argument.
>
> Well, so, here's the thing ... -use doesn't actually take an optional
> argument.
>
> If you look at the SYNOPSIS, the beginning is:
>
>comp [-help] [-version] [+folder] [msg] ...
>
> So when you say "comp -use 1", you're setting the -use flag, and "1"
> is the optional "msg" argument.

I _thought_ that that might be the case, but was confused when
(due to the -use flag) providing the "msg" argument wasn't
generating a new draft based on that message.  I'm guessing that
the effect of the -use flag overrides any conflicting behavior
from supplying a message argument.

> >Maybe add a (possibly
> >parenthetical) sentence to the end of the current -use
> >explanation paragraph -- e.g.
> >
> >   The switch -use directs comp to continue editing an
> >   already started message.  That is, if a comp (or dist,
> >   repl, or forw) is terminated without sending the draft,
> >   the draft can be edited again via “comp -use”.  Note:
> >   consult also the mh-draft(5) man page if using the draft
> >   folder facility.
>
> Ooof, Bob ... can we talk?  Your message was sent out using the
> character set iso8859-1, but the bytes you sent in the above paragraph
> were UTF-8.  Which makes me think that your local character set is UTF-8
> but for some reason you have configured nmh to only use ISO8859-1,
> which is just a recipie for problems in the long run.  It looks like
> those were supposed to be left & right double quotation marks
> (U+201C & U+201D).

Oops!  Sorry about that!  Yes, I forgot to change the outgoing
message's character set to UTF-8 (from my default iso-8859-1).

And you're correct, Ken, that my system (Ubuntu 18.04) is set up
for UTF-8:

 $ echo $XTERM_LOCALE
 en_US.UTF-8

> >> And sigh, the handling around the draft file vs a draft folder
> >> is a confusing mess.  In a perfect world I'd just switch
> >> everything to draft folders and toss draft file handling in the
> >> trash can.
> >
> >I can see how that might make things more uniform.  B-)  I'd need
> >to change my muscle memory, but I wouldn't mind.
> >
> >On that note, and for folks and Norms curious about -use, lack of
> >Draft-folder, etc., I provide the following anec-data.
>
> So, I was kind of in the same boat, except ... as a long-time exmh users,
> I was forced to use a Draft-folder entry a few decades ago so I am used
> to the draft-folder behavior.

Every (long) once in a while, you guys change the behavior of NMH
in a way that forces me to update my procedures -- almost always
correcting something based on a misunderstanding.  B-)  And, to
be very clear, I'm very grateful that you're still doing that!
I'll adapt.  B-)

> >As far as I can tell, comp(1) is just verifying that the message
> >exists.  It doesn't use it to construct a new reply (and thus
> >overwrite what's already in ~/Mail/draft), or change the current
> >message.  In particular, if the number or list doesn't exist,
> >comp will complain about it:
> >[...]
>
> _Huh_.  Boy, talk about a confusing mess.  I wouldn't have expected
> that from reading the code.  So ... I guess this is happening in
> m_draft().  Maybe?  Ugh.
>
> This is SO confusing.  Again, the weird handling of the special "draft"
> file is such a mess; if it was just a regular nmh folder/message it would
> be much simpler.

I know this would be a (very low) priority fix, but I would not
object to it.  (I'm also fine with it the way it is.  B-)

Bob

Re: comp man page

[Bob Carragher]

On Tue, 28 Jul 2020 16:40:07 -0400 Ken Hornstein  sez:

> >There is a nice feature for comp that I can't find in its man
> >page.  If the user's ~/.mh_profile has a Draft-folder: entry
> >(I don't know what happens if it doesn't.) then if comp has a
> >"-use" flag, comp takes on optional argument:  A message
> >number in the folder designated by ~/.mh_profile from which to
> >start.
>
> Hm, I guess I knew about this, and "-use" IS in the man page,
> but it doesn't explain what happens when you have a draft
> folder.  (If you don't have one then "-use" will ise the draft
> file).  The comp(1) man page refers to mh-draft(5) and that
> DOES explain how -use works.  I am unsure if more detail should
> be put into comp(1); thoughts?

As a user who _barely_ uses more than the basic features of NMH,
I was completely unaware of all this.  (That is my fault, of
course.  B-)  The SYNOPSIS section does not show that "-use"
optionally takes an argument.  Maybe add a (possibly
parenthetical) sentence to the end of the current -use
explanation paragraph -- e.g.

   The switch -use directs comp to continue editing an
   already started message.  That is, if a comp (or dist,
   repl, or forw) is terminated without sending the draft,
   the draft can be edited again via “comp -use”.  Note:
   consult also the mh-draft(5) man page if using the draft
   folder facility.

> And sigh, the handling around the draft file vs a draft folder
> is a confusing mess.  In a perfect world I'd just switch
> everything to draft folders and toss draft file handling in the
> trash can.

I can see how that might make things more uniform.  B-)  I'd need
to change my muscle memory, but I wouldn't mind.

On that note, and for folks and Norms curious about -use, lack of
Draft-folder, etc., I provide the following anec-data.

I'm a user who _probably_ saw "-draftfolder" in the man pages at
some point over the years, but never paid it much attention.  (As
a result, I have come up with my own draft message/file system --
a.k.a. badly reinventing the wheel.  B-)  This means that I do
not have an entry for "Draft-folder" entry in my ~/.mh_profile
file.  Here's what happens when I use the "-use" flag.

(Note:  I do have a "Path" entry -- set to "Mail" -- though.)

When I want to edit a draft message that I have previously quit
editing in the middle of, I have always done:

 $ comp -use

This brings up ~/Mail/draft in my editor, as expected.  (I rarely
use the "-file" option; like I said "reinventing the wheel."  B-)

I just tried it with an argument, and it appears comp(1) treats
that like a message number or list:

 $ scan +inbox 4
   4+ 20/07/28 Ken Hornstein  Re: comp man page<<>There is a nice 
feature
 $ comp -use 4
 [... opens up an editor session on ~/Mail/draft ...]

As far as I can tell, comp(1) is just verifying that the message
exists.  It doesn't use it to construct a new reply (and thus
overwrite what's already in ~/Mail/draft), or change the current
message.  In particular, if the number or list doesn't exist,
comp will complain about it:

 $ comp -use blah
 comp: bad message list blah
 $ show 9
 show: message 9 doesn't exist
 $ comp -use 9
 comp: message 9 doesn't exist

This seems like an unintentional "feature."  (It seems harmless.)

Bob

Default file processing for refile -- mv or ln?

[Bob Carragher]

Hello,

What might make refile(1mh) apply the non-default ln(1) to
refiled message files -- as if the -link switch had been
specified -- instead of the default mv(1) -- as if -nolink had
been specified?  And only sometimes; not always.

Note:  I have no entry for refile(1mh) in my .mh_profile file.
Nor do I specify any switches on the command line, or use a
script or alias that supplies it (so far as I know).

There are certain messages that I refile directly from my inbox
to a save-folder.  I usually do something like this:

 $ scan +inbox
 [... output elided ...]
 $ show 5
 [... output elided ...]
 $ refile +SaveFolder

But:

 $ ls -i Mail/inbox/,5
 12345678 Mail/inbox/,5
 $ ls -i Mail/SaveFolder/* | tail
 12345678 Mail/SaveFolder/25

 $ find Mail/SaveFolder/25 -type f -printf '%n %i %p\n'
 2 12345678 Mail/SaveFolder/25

I also sometimes provide the message numbers -- e.g.

 $ refile +SaveFolder 5 6 7

but that doesn't seem to make a difference.

It seems that the default -- -nolink/mv(1) -- is performed the
vast majority of the time.  But about 5% of the time the other
operation -- -link/ln(1) -- is performed.  The first message file
that this happened to is dated 2014 May 26, though my save-folder
has message files dating to a year before that.  The latest file
is from last night.  I don't see any pattern in the files (like
maybe this happens only on Thursday nights).

I did not do anything special to my system on 2014 May 26.  (Or
yesterday.)  In fact, there are messages that I refiled earlier
on May 26 and on May 27 that were not ln(1)-ed.

Note:  I tried adding the following to my .mh_profile, to force
the -nolink operation:

 refile: -nolink

Initially, that seemed to solve the problem.  However, an hour
later, even _with_ that entry in the .mh_profile file, the
-link/ln(1) procedure occurred again.  B-(

I would greatly appreciate any suggestions as to what I might
fix, or at least investigate.

Thanks you!

Bob

P.S.  this is not a big deal, as I can just periodically run the
find(1) command on my save-folder to find all inodes with more
than 1 hard link, and then delete the unneeded path.  But of
course I'd rather not need to do that.

Re: send bcc: wierdness?

[Bob Carragher]

Thank you for this explanation, Robert!  I now understand a huge
chunk of the -snoop output to post(1) ... that admittedly I
hadn't been paying close attention to.  B-)

Bob

P.S.  and, apologies to those who explained it before, when I
still wasn't paying close attention.  B-)

On Mon, 13 Apr 2020 13:04:07 +0700 Robert Elz  sez:

> Date:Mon, 13 Apr 2020 01:05:54 -0400
> From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" 
> Message-ID:  <477754.1586754354@turing-police>
>
>   | But if it already knew that it would need two transactions, why did it 
> bother
>   | with the first transaction?
>
> To verify that both addresses are OK.   Whatever sequence it uses,
> 3 SMTP transactions are needed, one to validate the first address,
> (and optionally the second), one to deliver to the second address
> (also validating it if that wasn't done in the first) and one to
> deliver to the first addr.
>
> There could be one less RCPT TO transaction than is currently used,
> but only when there are just 2 deliveries needed, add a 2nd Bcc
> recipient, and now 3 separate delivery SMTP connections are needed,
> plus verification - if all 3 addresses are verified in the first
> connect, a total of four, any other sequence and more are required.
>
> Hence, verify everything in the first transaction, and once we know
> all addresses are OK, deliver to them in one transaction for all visible
> recipients (if all are, this can be a continuation of the verification
> connection - which is the usual case) and one more for each bcc recipient.
>
>   | Or is the problem that if the first transaction sends 1 bcc note
>   | and succeeds, and the second sends 3 successful and one failed,
>   | error recovery gets difficult?
>
> Yes.   Whichever order those two are done.I believe though that
> the three and one case ends up in no deliveries - I think you'll find
> that if there are any failures (even temporary ones) to any of the
> RCPT TO commands (or MAIL FROM obviously) then MH's SMTP agent quits,
> and never sends a DATA command.   It sends to everyone or no-one.
>
>   | (Though even if you have no bcc's, and 2 recipients to 1 mx,
>   | and 2 recipients to a different mx, and one fails, you still
>   | have the same problem...)
>
> Yes, but recall than when MH was developed, for 99% of e-mails, all
> recipients were on the local system, networking was still (mostly)
> a coming thing, for the vast majority of users.
>
>   | Or has it been doing a pre-test all along and I've just never
>   | caught it at it? :)
>
> Yes, always - but when there are no BCC recipients, then there's no
> need for separate SMTP transactions, and once the pre-test is done,
> we can simply complete the transaction with a DATA command,   This
> separate SMTP series is only needed when we're hiding recipient addresses,
> so one SMTP transaction cannot be shown all of them.
>
> kre

Re: [nmh-workers] Handling empty components

[Bob Carragher]

Sorry to take so long to do this!

I'm actually having trouble building the sources on Ubuntu 18.04
(Bionic Beaver).  This is clearly not impossible, since 1.7.1 is
the version of the NMH package built for 18.04, but there are
some odd hangups.

For example, build_nmh is failing during the "configuring" step
because one of the checks, which builds a small program that
includes "gdbm-ndbm.h", fails because that include file is no
longer provided with the libgdbm-dev package (only "gdbm.h" is).
Thus, even the "configure" script under the 1.7.1-4 tree on
sources.debian.org would fail at this point (because it is
expecting "gdbm/ndbm.h").

 https://sources.debian.org/src/nmh/1.7.1-4/configure/

I was wondering if the person who builds the Ubuntu package can
point me to which patches -- and packages, as Ubuntu has reduced
what gets installed by default, like the curses package -_-## --
need to be applied to get it built?  (I can probably work this
out myself, but I don't want to make changes/assumptions that
might be wrong.  Also, I'm hoping I can be lazy.  B-)

Thanks!

Bob

On Sat, 23 Mar 2019 11:07:18 -0400 Ken Hornstein  sez:

> >... Though, if you would like me to test this (and see if I can
> >come up with format code that is not ridiculously complex/long)
> >to see if it solves my particular issue (which it seems like it
> >should), I'm happy to pull down and build from sources!
>
> If you want to build from HEAD, that's an option (we don't run
> that through testing like we do for a release, though).  But
> you could always pull down the sources from 1.7.1 and apply the
> patch; it really is one line (see below).  I think wrapping
> every component in a %(trimr) function would do it.
>
> --Ken
>
> commit 9530e8f7f96f79ebe9afaeeecf0f2a2b373bb429
> Author: Ken Hornstein 
> Date:   Fri Mar 22 11:59:04 2019 -0400
>
> Add support for %(trimr) format function
> 
> Add support for a %(trimr) format function, which behaves exactly
> like %(trim) but also returns a string.  Turns out this is literally
> a one-line change that does not require a new format instruction.
>
> diff --git a/man/mh-format.man b/man/mh-format.man
> index 104b8212..8b43eda6 100644
> --- a/man/mh-format.man
> +++ b/man/mh-format.man
> @@ -285,6 +285,7 @@ decodeexprstring  decode \fIstr\fR as RFC 2047 
> (MIME-encoded)
>   component
>  unquote  exprstring  remove RFC 2822 quotes from \fIstr\fR
>  trim exprtrim trailing whitespace from \fIstr\fR
> +trimrexprstring  Like %(trim), also returns string
>  kilo exprstring  express in SI units: 15.9K, 2.3M, etc.
>   %(kilo) scales by factors of 1000,
>  kibi exprstring  express in IEC units: 15.5Ki, 2.2Mi.
> diff --git a/sbr/fmt_compile.c b/sbr/fmt_compile.c
> index e8a80279..3ada1d41 100644
> --- a/sbr/fmt_compile.c
> +++ b/sbr/fmt_compile.c
> @@ -160,6 +160,7 @@ static struct ftable functable[] = {
>   { "decodecomp", TF_COMP,FT_LS_DECODECOMP, 0,
> TFL_PUTS },
>   { "decode", TF_EXPR,FT_LS_DECODE,   0,  
> TFL_PUTS },
>   { "trim",   TF_EXPR,FT_LS_TRIM, 0,  0 },
> + { "trimr",  TF_EXPR,FT_LS_TRIM, 0,  
> TFL_PUTS },
>   { "kilo",   TF_EXPR,FT_LS_KILO, 0,  
> TFL_PUTS },
>   { "kibi",   TF_EXPR,FT_LS_KIBI, 0,  
> TFL_PUTS },
>   { "compval",TF_COMP,FT_LV_COMP, 0,  
> TFL_PUTN },

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Handling empty components

[Bob Carragher]

Wow, thanks a lot, Ken!

I won't pick up the new %(trimr) function until Ubuntu pulls in
that version of NMH, so not before 20.04 (because it's the next
LTS release).

... Though, if you would like me to test this (and see if I can
come up with format code that is not ridiculously complex/long)
to see if it solves my particular issue (which it seems like it
should), I'm happy to pull down and build from sources!

Bob

On Fri, 22 Mar 2019 09:31:07 -0400 Ken Hornstein  sez:

> >Thanks guys for the quick reply and suggestions!
> >
> >Ken:  yeah, I can see how messy that's going to be; alas that
> >%(trim) indeed doesn't return its result.  Although I'll probably
> >see this again, it'd be maybe 1x/year for the next couple years.
> >(And, who knows, maybe their IT department will fix it?  B-)  Not
> >worth complicating my replcomps; easier to just manually add the
> >"To:" field in vim.  B-)
> 
> I thought initially that %(trim) was recent, but no, it isn't
> ... it existed back in MH 6.8, and I am kinda surprised that
> the authors of %(trim) didn't make it return a value, because
> they actually knew the format engine pretty well (it has a
> number of subtle bits of behavior that I have only learned
> about after staring at the code for a while, and I wrote
> fmttest(1) because it is so confusing).
>
> We can't really change the behavior of %(trim), but we COULD
> easily add a new function (maybe %(trimr) ?)  that would return
> a value and be easier for you to use in this case.  But it
> wouldn't appear until a new nmh was released.
> 
> --Ken



On Fri, 22 Mar 2019 12:03:04 -0400 Ken Hornstein  sez:

> >We can't really change the behavior of %(trim), but we COULD
> >easily add a new function (maybe %(trimr) ?)  that would
> >return a value and be easier for you to use in this case.  But
> >it wouldn't appear until a new nmh was released.
>
> It turns out adding a %(trimr) function was literally one line
> of code, so I added it.  Caveats about it not appearing until a
> new release still apply, unfortunately.
>
> --Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Handling empty components

[Bob Carragher]

Thanks guys for the quick reply and suggestions!

Ken:  yeah, I can see how messy that's going to be; alas that
%(trim) indeed doesn't return its result.  Although I'll probably
see this again, it'd be maybe 1x/year for the next couple years.
(And, who knows, maybe their IT department will fix it?  B-)  Not
worth complicating my replcomps; easier to just manually add the
"To:" field in vim.  B-)

Thanks!

Bob

On Thu, 21 Mar 2019 07:01:47 -0400 David Levine  sez:

> Ralph wrote:
> 
> > Hi Bob,
> >
> > > Is there a concise way to specify "if X is not present or is just
> > > white space?" in one's replcomps?
> >
> > I'd look into applying function `trim' first;  see mh-format(5).
> 
> If this command is of any use, I started to use it to explore that but
> ran out of time:
> 
>   fmttest -format '%<{reply-to}%|%<{from}%>%>%(void(width))%(putaddr To: )\n'
> 
> A msg or -file switch can be added.
> 
> David
> 
> -- 
> nmh-workers
> https://lists.nongnu.org/mailman/listinfo/nmh-workers



On Fri, 22 Mar 2019 00:02:47 -0400 Ken Hornstein  sez:

> >Is there a concise way to specify "if X is not present or is just
> >white space?" in one's replcomps?
>
> We covered this ground a few years ago, here:
>
>   http://lists.nongnu.org/archive/html/nmh-workers/2015-02/msg00139.html
>
> Priescently, I said back then:
>
> >Mind you, a header consisting of nothing but white space will be read
> >as "true" in the sense of mh-format(5) tests
>
> And just to be sure:
>
> % fmttest -raw -format '%<(nonnull{text})Non-null%|Null%>' ''
> Null
> % fmttest -raw -format '%<(nonnull{text})Non-null%|Null%>' ' '
> Non-null
>
> But I see:
>
> % fmttest -raw -format '%(trim{text})%<(nonnull)Non-null%|Null%>' ' '
> Null
>
> So Ralph was right, %(trim) does what you want.  But ... %(trim) does
> not have a return value (that was probably a mistake), so you cannot use
> it directly as a condition for %<. You'll have to make sure your first
> test is against the str register rather than Reply-To, and making it work
> for all components is actually going to be a bit messy.
>
> You know, since this the first one you've encountered in 30 years, maybe
> it is better just to let it go?
>
> --Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[nmh-workers] Handling empty components

[Bob Carragher]

Is there a concise way to specify "if X is not present or is just
white space?" in one's replcomps?

The "X" in my case is the "Reply-To" component, and I recently
received for the first time ever a message that contained an
_empty_ one (and that I wanted to reply to) -- i.e.

 From:  f...@bar.com
 To:  dnc2...@gmail.com
 Reply-To: 
 [...]

Note:  there is a space character after the "Reply-To:" above.
(If I remove the space, then the "Reply-To" component is seen as
empty, as expected.)

My replcomps is (I think) pretty standard, and starts with:

 %(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
 %<(nonnull)%(void(width))%(putaddr To: )\n%>\

This results in NMH generating a reply with _no_ "To:" header
because of the "(nonnull)" check.  At least, that is my guess --
the mh-format(5mh) man page says that nonnull checks whether the
str register is "non-empty."

I'm guessing I can add a bunch of "(nonnull)" checks when trying
to find the address for the "To:" header, but I'm wondering if
there is a better, more compact option.  Also, this is the first
time in nearly 30 years of using (N)MH that I've encountered this
situation, and I don't want to complicate my setup for such a
rare problem.

Thanks!

Bob

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Bob Carragher]

I'm definitely in favor of, by default, disabling anything that
causes automatic external data fetches to sites I might be
unaware of!

Bob

On Sun, 27 May 2018 10:15:29 -0400 Ken Hornstein  sez:

> >> I don't know.  History, probably.
> >> We used to assume everyone played nice.
> >
> >nmh-access-{ftp,url} were added less than 4 years ago.  Ken,
> >should we revisit?  I don't have strong feelings, the only
> >messages I've received that use it are from you and Ralph.
> 
> So, I read Anthony's email, and while I don't agree with all of
> his concerns I do understand where he is coming from.
>
> My reading of the historical MH code is that it would always
> try to fetch external-body content.  But ... the assumption in
> MH 6.8 was that MIME content was rare and presumably a human
> would look at it before they would run "mhn".  The
> external-body methods supported in MH 6.8 were "afs",
> "anon-ftp", "ftp", "local-file", and "mail-server".  I think
> "ftp", "anon-ftp", and "mail-server" probably were at a similar
> level of danger to "url" today.
>
> Thinking about the history ... along the way we moved towards
> always parsing MIME messages (because most messages nowadays
> are), which meant that external-body content would always be
> displayed (BTW, "turns out "mhn-access-ftp" was supported even
> back in MH 6.8).  I added the URL support and my motivation
> there was really just updating the MIME support to more modern
> stuff, I went along with how the ftp support worked and didn't
> think about the larger concerns.
>
> I think maybe the smartest thing to do would be to default to
> NOT displaying any external content in nmh when viewing content
> with show(1)/mhshow(1), but instead just show the MIME
> paramters to the user.  Then a user could chose to display that
> with -showexternal (or whatever).  A more trusting user could
> add -showexternal to their profile.  That might have to wait a
> while, though.  Thoughts?
> 
> --Ken
> 
> -- 
> nmh-workers
> https://lists.nongnu.org/mailman/listinfo/nmh-workers

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Bob Carragher]

On Fri, 25 May 2018 20:39:26 -0400 Ken Hornstein  sez:

> >Count  me as  another one  of  those few  people who  actually uses  the
> >text/plain content. :-) For the most  part, I don't read emails that are
> >HTML only  unless I  absolutely have  to and if  there's a  text/plain I
> >manage with that unless it's terrible.
> 
> My original draft of that email said "you're probably the only person
> who uses the the text/plain content", but then I remembered what mailing
> list I am on :-)

Guilty as charged.  ^_^;;;

> My larger point is that, sadly, I've seen a distressing number of times
> when the text/plain version of a multipart/alternative message is not
> useful.  I really wish people who have a shitty text/plain part would
> simply NOT bother and just generate text/html; I don't know why they
> even bother to generate such a lousy text/plain part, but this is the
> world we live in.  I suspect we (nmh users) might be the only users who
> actually look at the text/plain content versus the text/html content.

It's almost certainly the case that the percentage of people that
see the crap-HTML is tiny.  Otherwise outfits like Yahoo! would
be overwhelmed with complaints.  B-[

Bob

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

[Bob Carragher]

I think this would be a great idea.  How much (volunteer!) time
is being wasted chasing down memory leaks?  If we have the
resources to do so, of course 

(Of course, it's easy for me to say, "Go for it!"  I still
haven't found time to contribute even a regression test.  B-)

Bob

On Mon, 12 Feb 2018 09:27:04 + Ralph Corderoy  sez:

> Hi Paul,
> 
> > i just don't know whether MH can attract new users through a rewrite.
> 
> That wouldn't be the aim.  The aim would be for the existing users to
> have a code base that allowed more rapid, stable development of new
> features, deprecating old warts, and improving consistency.
> 
> For example, whilst I like the Unix idiom of one command to do one thing
> well, I do find myself doing a series of picks, marks, and scans to
> whittle down emails whereas having a consistent, planned, notation that
> can be used wherever a message number can be given would lessen the
> iterations a lot.  `seq=-3' is nice, but I can't do `seq:-3:2', for
> example.  And overall it's warty, so warty no one replied to my
> http://lists.nongnu.org/archive/html/nmh-workers/2017-09/msg00014.html
> :-)
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy
> 
> -- 
> Nmh-workers
> https://lists.nongnu.org/mailman/listinfo/nmh-workers

-- 
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] OT: Arch Linux.

[Bob Carragher]

Hi Ralph,

Thanks for all your information and explanations on Arch Linux!

On Tue, 01 Aug 2017 11:40:05 +0100 Ralph Corderoy  sez:

> > I have a sufficiently non-standard install.  Specifically, I prefer to
> > use ctwm instead of any of the modern "desktops"
> 
> Arch Linux's install media leaves one at a VT with a shell.
> https://wiki.archlinux.org/index.php/Installation_guide runs
> through the next steps, Internet access, partitioning,
> installing the core packages, and finishes with references to
> other wiki pages about common packages.  So you get to choose
> if X might be useful, what window manager, etc.  There are
> packages that just depend on lots of others so Gnomers can get
> their fix easily.

Oh, that's very nice!  Most importantly for me, example shell
commands are given in the guide.

The 3 major and 1.5 minor reasons I use the Gnome tools (and
panel) are:

 1.  Update management -- I *really* don't want to be a
 full-time sys-admin again, and the major reason I liked
 Ubuntu was that it took care of all that for me.  I just
 logged into the "update" user I created for myself,
 clicked on the "Update Manager" icon in the Gnome
 session, and let it do its thing.  If Arch Linux makes
 it that easy (or there's a way to configure it to do so,
 so that I control *whether* an update happens, but
 otherwise it's automatic), then that works for me!
 2.  Network management -- specifically, for WiFi access.
 3.  Printer management -- specifically, to change printer
 configuration (e.g. double-sided vs. single-sided) prior
 to a print job.

 4.  Hardware temperature monitoring -- for which I use the
 psensor(1) application that is launched by Ghome panel,
 although anything that provides me a running visual
 would suffice.
 4.5  gkrellm(1), the Gnome GUI for the Krell hardware
  monitors.  There's probably some other GUI I can use.

One complication of this is that the certain Gnome applications
can be randomly restarted when some monitoring daemon is poked,
which in my situation sometimes leads to gnome-screensaver(1)
being restarted.  If I then suspend my laptop, when I awaken it,
the appropriate hooks are not in place, and thus *none* of my
input devices (keyboard, mouse, trackpad) does anything -- and I
need to hard-reboot.  (I've created scripts to prevent this and
similar Gnome-annoyances.)  Not having to deal with this would be
a *very* nice bonus!

> > I need to see what has changed since my last OS update, which usually
> > means figuring out the new way to do XYZ -- and that's what typically
> > causes this to balloon to days
> 
> With a rolling release, this tends to be a steady trickle of
> incremental package upgrades, most don't bother me, and when
> one does other users are in the same boat *now* so the solution
> is normally easy to find, e.g. top thread on the forum, rather
> than digging about for something from months ago when "testing"
> users first encountered it.

Woot!  B-)

> > is it trivially easy to undo a package's upgrade?
> 
> As a rolling release, a package can assume your other packages
> are up to date so there's not the "pinning" of one package at
> an old version whilst the rest move on.  I think you can do it,
> but it's explicitly not supported.
>
> The repo has the current packages.  There's an
> https://wiki.archlinux.org/index.php/Archive that has the
> previous ones, and I used that once for the Nvidia problem that
> stopped graphics working.

Hmm ... this gives me *slight* pause, but probably as long as my
shell and NMH don't unexpectedly change then I can probably deal
with it.  B-)  Since there's a repo of packages, I can (probably)
just install an older version and cross my fingers that the newer
versions of libraries it depends on won't break the older build.

Bob

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

Re: [Nmh-workers] Volunteer Capacity.

[Bob Carragher]

On Sun, 30 Jul 2017 11:42:01 +0100 Ralph Corderoy  sez:

> Hi Bob,
> 
> > (I originally intended to use 13.10 until 14.04 LTS came out.
> > Laziness.  B-)
> 
> Erm, I was Ubuntu 10.10 until 2016-02-13 when this Arch Linux
> took over.  :-)  Finding the block of time to do the Ubuntu
> upgrade was a chore, and the next one would pile up behind it.

Sounds exactly like me.  ^_^;;;

> With Arch, it's a rolling release with a steady stream of
> package updates, about half a dozen a day, though that would
> depend on the range of packages installed.  "core" packages
> have passed through "testing" repositories that mean they've
> been signed off by Arch's developers before reaching me.

This sounds like what happens with my smart phone, although I
care a lot less if an upgrade bricks my phone than if one bricks
my laptop.

But even assuming things go smoothly, the other thing that stops
me from simply upgrading when new Ubuntu versions come out is
that I have a sufficiently non-standard install.  Specifically,
I prefer to use ctwm instead of any of the modern "desktops"
because I've spent decades developing a work flow around it.
(Example:  I use all 32 workspaces.  I'm not just lazy regarding
OS upgrades.  ^_^;;)  Since I'm not a "real" sys-admin -- I
haven't really kept up with all the changes in what program does
XYZ or what files need to be touched to do PDQ since I admin-ed
on Solaris 2.6 -- I still make use of Ubuntu admin tools, but
their operation is partially broken since I'm launching X
directly and only some of the Gnome stuff (like gnome-panel,
nm-applet), and I never figured out how to do so so that access
control works (without launching all of Gnome, which would mean
not using ctwm).

So although a fresh install would only take a couple hours, I
need to see what has changed since my last OS update, which
usually means figuring out the new way to do XYZ -- and that's
what typically causes this to balloon to days, if not weeks.
(This is not to say that my laptop is bricked for that whole
time; just that I end up with lots of papercuts to deal with.)
I don't mind having to relearn how to do stuff on my phone, but
that's because I don't spend hours on it doing complex work.

> I've had very little breakage.  It's always been due to my old
> Nvidia hardware IIRC, and the fix has followed along promptly.
> It's nice to find up to date software to hand as packages, and
> to report an issue on, say, Github and have the fix in a
> package update within a week.  Quite a contrast to a nine or
> twelve month wait with Ubuntu, if I'm lucky, and if I bothered
> to upgrade.

This would be quite nice, if the breakage is minimal indeed.

You mention that there's usually a fix that follows along pretty
quickly.  If the breakage in my case is that they've changed how
to do XYZ in a way that I don't want (c.f. Apple removing support
for playlist folders, something I'll never forgive them for), is
it trivially easy to undo a package's upgrade?

Thanks!

Bob

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

Re: [Nmh-workers] Volunteer Capacity.

[Bob Carragher]

Okay, thanks guys!

I'll start with at least seeing if I can get things to work for
me.  I'm familiar with git(1) for straightforward usage -- I'm in
charge of a couple of simple projects where development is very
linear (though we still use merge requests to keep folks from
stomping on each others' stuff), and we don't use tags.  I
shouldn't have any problems creating new development branches,
and am happy to wait for project veterans to approve/merge them
into "master."  I'm also fine with generating patch(1) output for
someone else to toss into a git branch for proper committing.

I'll look at .../test/README and trying "make gcov" to start,
after I've managed to configure things properly.  I'll also look
specifically at .../test/forw/test-forw-coverage for an example
of recent test coding (though not necessarily as defined template
for all aspects of testing going forward -- in particular, that
just checking the exit status is sufficient).

Note:  I've not yet upgraded from the ancient (and unsupported)
Ubuntu 13.10.  I'm planning to upgrade to the latest LTS
soon-ish.  Do you think that will pose issues that I should
investigate (and deal with) before getting too far into things?

Bob

On Sat, 22 Jul 2017 13:23:48 +0100 Ralph Corderoy  sez:

> Hi Bob,
> 
> > Out of curiosity, would it help to have "micro-volunteers" to update
> > the testing?
> 
> I'd have thought so, though David is, I think, the main person behind
> the test suite.
> 
> > namely having (sufficient) test coverage,
> ...
> > If enough of us do that, maybe we could significantly improve
> > coverage?
> 
> Yes, I think so, even if it's just a few plugging away steadily.
> 
> I played about with gcov(1) coverage testing on nmh a while
> back and should do so again and write up how to do it this
> time.  Because I was just trying to get more lines executed by
> the tests, I added command-invocation tests that didn't check
> standard output or error, just the exit status.  An example is
> http://git.savannah.nongnu.org/cgit/nmh.git/tree/test/forw/test-forw-coverage
>
> Knowing the tests cover more lines makes running them under
> valgrind(1) more useful.
>
> The idea was to chase the low-hanging fruit by looking at
> gcov's annotated source and spot the easy bits to get coverage
> on.  It may seem that it's only an if statement and an error
> message, but they're often calling routines and so have a
> knock-on effect for coverage.  I thought once that "easy" outer
> veneer was exercised we could look again at gcov's results and
> pick a chunk of "library" routines on the next level down and
> work backwards to see what caller we can run.  At this point,
> we'll probably be more interested in the command output
> matching expectations, i.e. did the library routines not just
> run but work correctly, so the added tests would be more like
> the existing ones.
> 
> > Of course, one of the main developers still needs to "approve" any
> > commits, so that doesn't completely eliminate work on testing.
> 
> I think a few canned git(1) commands, for those that don't know
> it, would get you a long way, and they can prepare a patch for
> email that those with commit rights can easily apply whilst
> still attributing the original author.  Once they've got the
> hang of it and want to keep going then the tester can sign up
> on nongnu.org themselves.



On Sun, 23 Jul 2017 08:07:12 -0400 David Levine  sez:

> Ken writes:
> 
> > Ralph has already given you specific answers, but more
> > generally ... yes!  If you or anyone want to volunteer to do
> > ANYTHING for nmh, it would help!  No task is too small.
>
> I agree completely.
>
> And I agree that the test suite is a good place to start, and
> "make gcov" within that.  tests/README has some guidelines.
>
> The existing tests could use a general cleanup, including
> picking one way to do something, such as starting an individual
> check, naming output files, or reporting failure.



On Sun, 23 Jul 2017 09:13:55 -0400 David Levine  sez:

> I wrote:
> 
> > tests/README has some guidelines.
> 
> That should be test/README

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

Re: [Nmh-workers] Volunteer Capacity.

[Bob Carragher]

On Fri, 21 Jul 2017 11:51:51 -0400 Ken Hornstein  sez:

> >It's bad because nmh's source needs a lot of clean up, at
> >small and large scale, due to decades of changing
> >expectations, conventions, and bit rot.  And tests to help
> >spot regressions in doing that.
>
> Ralph has hit the nail on the head.  It seems a large part of
> nmh development is cleaning up old crap from 30 years ago.  At
> least, larger than I would like.  Also, bringing nmh forward
> really means retooling a bunch of internal stuff.  I've done
> that for some things, but it's a big job and we still have more
> to do.
>
> Now, perhaps people would argue that nmh doesn't need to be
> brought forward that much; I would respectfully disagree, but
> there are some small things people ask for all of the time that
> really need larger changes to happen.  I wish I had more time
> to work on those things.

Out of curiosity, would it help to have "micro-volunteers" to
update the testing?

I'm thinking specifically of something that's been brought up
several times before, namely having (sufficient) test coverage,
both for better testing but also to give developers more
confidence about changes, especially big ones.  While it might be
daunting for most of us lurkers to take on something even on the
order of Larry Hynes' man page updates earlier this year, we
might be happy to contribute a test here and there.  (If nothing
else, it would help assuage some of the guilt some of us might be
feeling for using such a great tool for so many decades without
having contributed any code.  B-)  If enough of us do that, maybe
we could significantly improve coverage?

Of course, one of the main developers still needs to "approve"
any commits, so that doesn't completely eliminate work on
testing.  And, we probably need guidance in terms of what kinds
of tests and what areas of NMH to prioritize, which at the very
least would be a "startup cost."

But perhaps that might make "retooling" and similar big projects
more potentially doable?

Bob

P.S.  yes, I'm willing to be a "micro-volunteer."  B-)

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

Re: [Nmh-workers] %(timenow) -- does it have a purpose?

[Bob Carragher]

On Fri, 30 Jun 2017 00:29:57 -0400 Ken Hornstein  sez:

> >Does %(timenow) have a purpose?
> 
> Yeah, although probably not what you're thinking of.
> 
> The idea is that you could use that in calculations against a
> date header.  (e.g., %(timenow) - %(clock) would give you an
> offset, although there is %(rclock that does that for you).

That's what I thought (both using it in a calculation, and that
the most obvious one is already handled by %(rclock)).

> Things like %(month) are designed to parse a date header, since
> that's hard to do from the shell.  I could see the value of
> maybe doing something to break out a inside of mh-format, but
> ... what would that look like?  Maybe take a strftime() format
> string?  Might need some thought.  Not sure we could use
> existing functions since they really want a component.

These days, at least with GNU date(1), it's pretty trivial to
parse and (re)print a (valid) date string in any format your
heart desires -- e.g.

 % date -d 'Fri, 30 Jun 2017 00:29:57 -0400' +"Year %Y, month %B, day %-d"
 Year 2017, month June, day 29

Given that no one has asked for this in the decades (N)MH has
been around, that means it's (likely) one of those things that
only 1 person (me B-) wants or needs.  After all, the more
"general" solution might be to create conversion functions -- in
the vein of the existing %(compval) function -- for the various
registers, (e.g. %(strtodate), which would (almost) bridge the
gap for me, which would then tempt you to bring in more features
that are better done using existing Unix commands.  Very deep,
this rabbit hole appears.  B-)

> >Separately, does anyone have a suggestion for generating the
> >current date in a reply?
> 
> Sure.  Have a wrapper script shove it into an enviroment
> variable and use %(getenv).

Thanks!  I keep forgetting about %(getenv).

Bob

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

[Nmh-workers] %(timenow) -- does it have a purpose?

[Bob Carragher]

Does %(timenow) have a purpose?

I was trying to create a form file for repl(1) that automatically
inserts the current date, and the only function I could find for
that purpose was %(timenow).  Unfortunately, it returns an
integer ("seconds since the UNIX epoch," according to the
mh-format(5) man page), which isn't the type of argument the
date-related functions (e.g. %(month{}) expect.

Separately, does anyone have a suggestion for generating the
current date in a reply?

Thanks!

Bob

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

Re: [Nmh-workers] scan doesn't appear to understand language encodings

[Bob Carragher]

Whoa.  Mind blown.  B-)

Thanks for the recipe!

Bob

On Fri, 02 Jun 2017 10:45:55 -0400 valdis.kletni...@vt.edu sez:

> On Fri, 02 Jun 2017 09:19:25 -0400, Paul Fox said:
> > ken wrote:
> >  > scan can't decode the body of a message; you get the raw text output.
> >  > Which is why you see the beginning of the MIME multipart marker if your
> >  > message is a multipart.  Why can't scan do that?  Because no one made it
> >  > do that.  SHOULD it do that?  Yes, ...
> >
> > i'm not sure i agree.  frankly, the first-line snippet that scan
> > provides instead of a subject is hardly useful enough to be worth it.
> > i'd be just as happy if scan <> or somesuch.
> 
> The tail end of my usual scan format:
> 
> %(decode{subject})\
> %(void{content-type})\
> %<(match multipart)\
> %?(match text/html)\
> %|%<{body} <<%{body}%>\
> %>
> 
> In other words, if the outermost MIME time is multipart/* or text/html,
> don't bother with using %body to display the first 10-50 chars of the
> body (depending how long the  Subject: line was).  That deals with 99% of
> the problem.
> ___
> 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] Forward/backward references in mail-aliases file

[Bob Carragher]

I see it in the repo.  Thanks, Ralph!  --  Bob

On Sat, 15 Apr 2017 14:30:51 +0100 Ralph Corderoy  sez:

> Hi Bob,
> 
> > The example shows the correct order in defining sgroup and fred,
> > though the explanation below the example is incorrect (and is
> > identical to the latest version in Savannah).
> 
> Thanks for the research.  I've pushed
> d8c4005c956790595943210509eb8daace570470 that fixes the
> example's order and once again documents `news.*:  news'.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy
> 
> ___
> 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

[Nmh-workers] Forward/backward references in mail-aliases file

[Bob Carragher]

I'm confused by this paragraph in the mh-alias(5) man page:

 Since the mh-alias file is read line by line, forward
 references work, but backward references are not recognized.

Immediately below, an example is provided, part of which
illustrates the referencing, partially reproduced below:

 [...]
 fred: frated@UCI.example
 sgroup: fred, fear, freida
 [...]

There follows an explanation, which for the relevant bit is:

 [...]  Following this, “fred” is defined as an alias for
 “frated@UCI.example”, and “sgroup” is defined as an
 alias for the three names “frated@UCI.example”,
 ”fear”, and ”freida”.

Isn't this actually a *backward* reference, and that forward
references are the ones not recognized?  (In other words, the
sentence I quoted at the top of this message has "backward" and
"forward" exchanged?)

Forward referencing is also referenced in the first sentence of
the BUGS section:

 Although the forward-referencing semantics of mh-alias files
 prevent recursion, [...]

Note:  I took the man page text from the latest version in the
git repository at Savannah, which I cloned at 20:30 PDT today,
2017 April 12.

Thanks!

Bob

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

Re: [Nmh-workers] Format function to create wrapped header lines?

[Bob Carragher]

On Mon, 05 Sep 2016 19:15:03 -0400 Ken Hornstein  sez:

> >FWIW, when I see a draft with References that is getting a bit
> >long, I just (manually) delete all the stuff in the middle) -
> >that is, leave in the oldest (one or two) and the most recent
> >(one or two) and delete everything in between - no-one has
> >ever complained about my messages breaking any threading
> >schemes (in fact, does anyone actually use References for
> >that, rather than just In-Reply-To and Subject ?)
> 
> Actually ... yes.  At least some of the complainers are on this
> list!
> 
> http://lists.nongnu.org/archive/html/nmh-workers/2015-08/msg00047.html
> 
> (And that's not the only message regarding that).

Hm, you might want to start counting me as someone using the
References: header.

It hadn't occurred to me before, but I might start using this to
try to defeat a particularly overly zealous spam filter.  Folks
might remember me whining about Stanford University's mail filter
assigning high spam scores to emails that I send there.  At
present, I use a lorem ipsum generator to make them look less
spammy.  But I'm wondering if I can't also take one of the
reference IDs generated by the Stanford mail server for the same
purpose (and save folks the trouble of ignoring my lorem)?

(Strictly speaking, I wouldn't *need* the References: header for
that, as I could just "harvest" IDs from the "In-reply-to"
headers of messages I've already sent.  But a single References:
header from a single message is also useful those times when I
need to start multiple new threads at once.)

> >If it isn't already done though, this header (and all others)
> >ought to be wrapped if it (they) ends up being too long for
> >the std when the message is posted (and that needs to happen
> >regardless of what format the message was in when created as a
> >draft, as the user may have added thousands of references on a
> >single header line - or made a huge Subject: or Comments:
> >header as one line, or listed the whole club's e-mail
> >addresses in the From:  or ...)
> 
> Hm.
> 
> This actually suggests to me that having this done in the
> format engine is wrong, and the RIGHT place to do it is inside
> of mhbuild, which is the tool that converts a draft file (which
> doesn't technically have to be in RFC 5322 format) into a valid
> RFC 5322 message, and we should do that for a number of
> headers.  I suspect that might be too much for 1.7, though.
> Due to liberal use of %(formataddr), we're mostly fine for
> address headers.
>
> Would people be happy with that?

I would *love* something that splits up that line in draft
messages I'm editing.  I participate in some very long threads,
and I've managed to reach the point in some of them where my
80x80 xterm does not contain enough characters to display the
entire References: header.  B-)  (At least it hasn't managed to
crash vim(1) on me.  B-)

I've thought about doing this automatically, but was concerned
that that would create an RFC 5322 non-compliant messeage.

Thanks!  B-)

Bob

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

Re: [Nmh-workers] Sending Binary Attachments

[Bob Carragher]

On Fri, 13 May 2016 10:21:09 -0400 Ken Hornstein  sez:

> >First of all, *thanks* for the note about the 998 max.  I've
> >updated my .mh_profile.
> 
> Just so we're clear ... I hope you either removed it
> completely, or upgraded to 1.6 and changed it to 998.  Also, I
> think that there's mostly no reason you should worry about
> sending stuff out that is encoded quoted-printable.  I mean,
> you were able to reply to my message that was encoded as
> quoted-printable and the world did not end.  Although you might
> want to consider upgrading to 1.6, as the message you sent out
> was actually not MIME-compliant and 1.6 would have fixed that.
> For reasons I cannot explain, my message contained a NO-BREAK
> space in it, but it looks like the mailing list software
> helpfully re-encoded your reply to it as quoted-printable.
> (Huh, I guess the answer is I get a no-break space if I hold
> down the "Option" key when I hit the space bar).

Hopefully I'll upgrade to 1.happen soon -- it's part of the
Ubuntu upgrade that's on my To-Do. In the meantime, I changed the
value to 998 in my .mh_profile.  It's harmless for now, provided
I don't try anything I normally wouldn't.

I prefer avoiding sending email that's encoded quoted-printable
because it makes it a little harder to "grep" through my outbox
folder.  I'd rather not need to decode a bunch of messages first.

Oops!  Yeah, missed that NBSP character.  B-[

Bob

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

Re: [Nmh-workers] Sending Binary Attachments

[Bob Carragher]

Not sure if this is a possible heads-up or just me running an old
version of MH ("comp -version" returns "comp -- nmh-1.5 [compiled
on batsu at Sat Dec 1 11:08:10 UTC 2012]"), but I use a large
value for -maxunencoded in my $HOME/.mh_profile to prevent MH
from base64-encoding my (100% 7-bit text) messages when they
include long lines.  Specifically:

 mhbuild: -maxunencoded 

This has not been a problem for me until I used the "attach"
option suggested by this thread:  when I then used "send" I get:

 What now? s
 mhbuild: -maxunencoded unknown

If this has been fixed in version 1.6, then my apologies for
noting this.

Otherwise, is this a possible bug?

Thanks!

Bob

On Thu, 12 May 2016 14:57:35 -0500 "Martin McCormick"  
sez:

> Ken Hornstein  writes:
> > The simplest way is to run the "attach" command at the
> > WhatNow? prompt.  This will choose a MIME type and create an
> > set of MIME parameters that will be appropriate 95% of the
> > time.
> >
> > But all that "attach" really does is add the Attach: header
> > to the message; other programs take care of the magic.  You
> > can also add the Attach header directly to your message.  The
> > arguments to the Attach header are a single filename.  You
> > can have multiple Attach: headers.  So really, think of the
> > "attach" command and the "Attach" header as doing the same
> > thing, because they do.
> >
> > The final way is to create mhbuild directives; see mhbuild(1)
> > for more detail.  This lets you specify the exact MIME
> > structure of a message.  This gives you a great amount of
> > control; the downside is you need to be relatively
> > knowledgable about MIME if you want to use this functionality
> > effectively.  Your question makes me think you probably don't
> > really want to use this; I only mention it for the sake of
> > completeness.
> >
> > So, in summary:  use the "attach" command at WhatNow?, or the
> > Attach: header if you want to do something a little more
> > intelligent (like Paul Fox's script).
>
> I'd like to thank everybody who provided an answer to this
> question.  As seldom as I need to send attachments, I was
> looking for the easiest way to do this.  Thanks for the help.
> 
> Martin McCormick
> 
> ___
> 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] (n)mh tip of the day

[Bob Carragher]

Cool!

I don't manage multiple mailboxes, but I sometimes change my
"real name" in the header.  For that, I've set up a bunch of
commands that are basically

 repl -form 

I have a bunch of form files as well.

That requires that I have a message to reply to, which is
usually the case.  But even when I'm composing a message, I
always have at least 1 message in my inbox (sigh), so I just
delete the In-reply-to: stuff from the header.  Yes, I have to
edit the To: and Subject: fields, but I would need to do that
anyway.  Just a different set of editor keystrokes.

Pretty low-rent.  B-)

Bob

On Tue, 20 Oct 2015 13:56:32 -0400 Ken Hornstein  sez:

> I just came up with this, and I thought it might be useful to
> people.
>
> I put in my components file the following line:
> 
> %<{from}%?(getenv MH_FROM)%|%(void(localmbox))%>%(void(width))%(putaddr From: 
> )
> 
> That lets me, in priority order, set my From: header as the
> following:
> 
> - The -from switch to comp(1)
> - The value of the MH_FROM environment variable
> -  Nmh's idea of my local mailbox (configured via
>Local-Mailbox, or if that's missing taking a guess based on
>the local username and hostname).
>
> I have a few shell aliases which set MH_FROM to useful values.
> I find myself juggling multiple identities more and more, and I
> finally got tired of editing my From:  header by hand.  That's
> not the only piece of the puzzle, though ... I have a postproc
> which submits the email to the 'correct' SMTP server and my
> replcomps has a number of contortions to choose the correct
> From: header (that works actually surprisingly well in
> practice).
>
> As a question to everyone else:  how do others who juggle
> multiple email identities make it work?
> 
> --Ken
> 
> ___
> 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] (n)mh tip of the day

[Bob Carragher]

On Wed, 21 Oct 2015 05:56:54 +0700 Robert Elz <k...@munnari.oz.au> sez:

> Date:Tue, 20 Oct 2015 14:33:19 -0700
> From:Bob Carragher <dnc2...@gmail.com>
> Message-ID:  <5626b320.4816430a.b973e.f...@mx.google.com>
> 
>   | I don't manage multiple mailboxes,
> 
> I do.
> 
>   | but I sometimes change my "real name" in the header.
> 
> But I almost never want to do that.   But ...
> 
>   | For that, I've set up a bunch of commands that are basically
>   |  repl -form 
> 
> I do it that way as well, except ...
> 
>   | That requires that I have a message to reply to,
> 
> I do the same for comp & forw (with components files, and
> forwcomps files).  I never bothered to set this up for "dist" -
> in general, what's in the Resent-From: matters not in the
> slightest to anything...
> 
> From a usability point of view, whether using an alias (or sh
> function, which is more common for me), or setting MH_FROM in
> the env, really makes no difference.  My (our) way does mean
> that there are multiple *comps files to edit whenever a

Same for me.

> systematic change is required, which can be a nuisance, but it

Fortunately, systematic changes have been rare (for me).

> also means that it is trivial to change more than just the
> From:, eg:  when I send from hostmaster@ I almost always want a
> Fcc: to a particular folder inserted, so the *comps files for
> it can have the Fcc ready in it.  (and more similar).  For
> replcomps files, the way I generate the To: and Cc: addresses
> varies (slightly) based upon which file I'm using (even when
> the From: doesn't alter.)

This is a key feature, and something I didn't mention.  Different
replies may be archived in different folders (so, varying Fcc:s),
I usually want to just reply to the mailing list and not Cc the
poster of the message I'm replying to (so, To:, Cc:, and Bcc: are
hard-coded in these).

> On odd occasions, *comps files can be generated on the fly for
> one off use.
>
> Part of what's great about MH is that we get to combine the
> shell (and all its tools) with the mh commands, to handle
> whatever out own needs happen to be, and aren't restricted to
> just what the MUA authors decided would be sufficient
> facilities.

And so there are many different ways to get the job done!

Bob

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

Re: [Nmh-workers] Stockton Gaines

[Bob Carragher]

Thank you very much, Norman.  --  Bob

On Sun, 18 Oct 2015 08:40:39 -0700 n...@dad.org sez:

> Bob Carragher <dnc2...@gmail.com> writes:
> 
> 
> >Would it be appropriate for someone like me to send flowers?
> >
> >Email is pretty central in my life, and NMH has made it far
> >easier to deal with that than any other mail client.  But would
> >it be reasonable for some unknown user to thank him at his
> >memorial service for his part in that?
> 
> See the attacged which says:
> 
> In lieu of flowers, donations may be made to the John Wayne Cancer
> Institute, 2200 Santa Monica Blvd., Santa Monica, CA 90404.
> 
> 
> Norman Shapiro

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

Re: [Nmh-workers] Stockton Gaines

[Bob Carragher]

Presumably this place?

 15821 Sunset Blvd
 Pacific Palisades, CA.  90272
 http://www.palipres.org/

Would it be appropriate for someone like me to send flowers?

Email is pretty central in my life, and NMH has made it far
easier to deal with that than any other mail client.  But would
it be reasonable for some unknown user to thank him at his
memorial service for his part in that?

Bob

On Fri, 16 Oct 2015 07:52:02 -0700 n...@dad.org sez:

> A memorial service, for Stock Gaines, is planned for 2pm on
> Saturday, November 21, at Pacific Palisades Presbyterian
> Church, in Los Angeles.
> 
> Norman Shapiro
> 
> ___
> 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] mts.conf has me Baffled.

[Bob Carragher]

[De-lurking, if only to show my lack of Bash chops. B-]

On Mon, 27 Jul 2015 22:35:33 -0400 Ken Hornstein k...@pobox.com sez:

 If the goal is to make nmh behave more like popular MUAs, and
 work independently of a properly configured MTA then,
 shouldn't nmh also have a queue?
 
 Well, it's not clear if they all do.  It's hard to have a
 independent queue in the MH command model, since MH/nmh aren't
 monolithic; how would you do that?  But like I said, if you
 have a draft folder doing a queue would actually be very
 simple.  Just create message drafts as usual and use something
 like this to send them (untested):
 
 #!/bin/sh
 
 DRAFTS=$(MHCONTEXT=/dev/null scan +drafts 2/dev/null)
 
 if [ $DRAFTS ]; then
   for message in $DRAFTS
   do
   send -draftfolder +drafts $message
   done
 fi

I have long used something like this.  I have a Pending folder
where I store ready-to-be-sent messages -- that is my queue --
and invoke a script that sends them out one at a time.  (I used
to first copy each message to Mail/draft and then use comp -use
to send, before the kind folks on this ML, including Ken, taught
me about send(1).)

I still use this script, for when I don't have network access.

The one thing my script doesn't have access to is whether the
message posting was successful -- at least in the sense of
whether send (or comp, before it) thinks it completed
successfully.  I don't believe either provides a return value
that Bash could use.  And so I've had to save the output
generated by the script and eyeball it after-the-fact, and if
something failed then manually resend.

But I don't consider that too great an imposition.  Yes, sendmail
has automatic retry, but if it fails after all those retries then
it sends a failure message to you.  That's not that much more
useful unless you've gone to the trouble of writing a script that
is applied to all incoming email, determines whether a message is
just such a failure message, and then grabs the failed message
(assuming it's still available) and tries resending it.  In other
words, most likely you still need to check your email to see if a
message failed to be sent, and then manually resend it yourself.

Bob

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

Re: [Nmh-workers] Stanford disliking my emails -- update + question

[Bob Carragher]

On Sat, 25 Apr 2015 06:30:10 +0700 Robert Elz k...@munnari.oz.au sez:

[...]
 I would also note that it is possible it is the mailing list exploder on
 nongnu,org that's doing it - detecting a To/Cc header with an address that's
 also on the list, and dropping that address from the list expansion.  That
 would be (just slightly) less broken than having the receiving MTA drop
 a message because it assumes a later one will arrive, and I'd actuually
 give a higher probability than the gmail hid it hypothesis.

Andy's experiment makes this look like the likely explanation.

At least, it doesn't appear that GMail's doing it, which is a
huge relief for me!

[...]
 Incidentally, the reason for the delay is most likely a local problem here,
 mail to gmail would normally be transferred over an IPv6 connection, but
 someone local has installed some broken firewall (or something) that is
 affecting SMTP over IPv6 in weird ways - connection attempts start to work,
 late enough that sendmail doesn't fall back to other addresses, but without
 allowing messages through.  The copy that was delivered eventually went via
 IPv4, so v6 must have been (for whatever reason) even more down at that
 instant, preventing even the SNY/SYN-ACK from succeeding, and allowing
 fall back to gmail's v4 addresses.   In any case, this isn't something to
 blame on Stanford's, or gmail's, spam filtering...   This issue is known
 here, and being worked upon, it just isn't fixed yet...

Yay!  One less (email) problem for me to need to deal with!  B-)





On Fri, 24 Apr 2015 19:50:01 -0400 Ken Hornstein k...@pobox.com sez:

 I would also note that it is possible it is the mailing list exploder on
 nongnu,org that's doing it - detecting a To/Cc header with an address that's
 also on the list, and dropping that address from the list expansion.  That
 would be (just slightly) less broken than having the receiving MTA drop
 a message because it assumes a later one will arrive, and I'd actuually
 give a higher probability than the gmail hid it hypothesis.
 
 That is possible, but I've personally received duplicate messages from the
 mailing list and a local copy, and having nongnu.org delete a message it
 thinks is duplicate strikes me as broken as well.  Would be interesting
 if we could see what happened on the gmail side.

I also used to receive duplicate messages, and also copies of
messages that *I* sent -- not only from this mailing list but
also from others (like the problematic Stanford ones).  Did some
listserv update go out in the recent past that suppresses this
behavior?  (I prefer seeing them, as they function as nice
acks, though I can believe that that's a minority opinion in
the wide world.)





On 24 Apr 2015 17:57:01 -0600 Andy Bradford 
amb-sendok-1432511821.pbliaglkkmpigabea...@bradfords.org sez:

 Thus said Robert Elz on Sat, 25 Apr 2015 06:30:10 +0700:

[...]

  His concern  was the delay  - he'd seen replies  to a message  that he
  didn't receive  for days (and if  I'd noticed the holdup,  and dropped
  that copy of  the message - expecting him to  receive, or have already
  received, a copy via the list - might never have seen).
 
 I see. The concern was the delay (which at the time probably looked like
 100% delivery failure),  not the duplicate removal.  Personally, I don't
 mind delay---SMTP was designed  for reliable delivery, not instantaneous
 delivery. On the  other hand, a mail system  that ``removes duplicates''
 seems to break the reliability of the system.

Actually, before I finally received a copy, I was concerned that
I would *never* see that message.  Both are ultimately concerns.
(Is the MLM not delivering all postings?  Is there a new problem
delaying emails to me?)  But it looks like only the former is a
(potential) problem.

Bob

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

Re: [Nmh-workers] Stanford disliking my emails -- update + question

[Bob Carragher]

On Wed, 22 Apr 2015 23:22:27 -0400 Ken Hornstein k...@pobox.com sez:

 I think you read that a little differently than I intended - I
 didn't mean to imply that this would be free (just included in
 whatever else you get) though it sometimes is (I suspect
 that's rare) - they're businesses, and will seek a profit from
 whatever avenue they can, which is reasonable - most often
 there will be some additional charge, but often (from the
 commercial pay for use providers, as distinct from google etc.
 who raise revenue other ways) this is a service they offer -
 why wouldn't they - it costs them almost nothing, and they can
 charge for it.

 Fair enough ... but again, my two examples (Verizon and
 pobox.com) don't include it in their service they provide to me
 that I pay for.  But that doesn't really get to my larger point
 - every other MUA manages to send email fine, without requiring
 your own domain.  It seems backwards to tell nmh users this is
 the preferred solution.

Two more examples:  Comcast (a business account -- though they
do offer static IPs, for a fee) and Google Mail.

I, for one, am very glad that there exists a fine and supported
solution that doesn't require me to buy a domain name!

   | Thirdly ... I think it's ridiculous that Stanford's
   | anti-spam rules trawl through Received headers (which are
   | defined as being free-form)
 
 Actually, they're not, they have a fairly strict format (with
 lots of options, true) - but that's not really the point.  The
 real issue is that spammers tend to put in a chain of bogus
 Received headers in messages they send in a rather lame
 attempt to hide the true origin of the message.

 Fair enough, I was wrong about that ... although, really, RFC
 5321 says you can't count on them to have any format, but like
 you said, not really relevant here.  My key point was that
 Bob's message was validated by gmail's DKIM rules; that only
 happens if you authenticated to gmail to submit the message.
 If that happens, you shouldn't need to check the Received
 headers for bogus stuff.

On a related note, initially Stanford IT said it was GMail's
fault, though they were never precise with their reasoning.  My
guess is that they were saying, Yes, GMail is providing a valid
DKIM entry, but the sending node uses 'localhost.localdomain' --
which means GMail is in effect validating what is, in our
opinion, 'spam.'

I can see that that is not 100% impossible.  But, given the
presence of the DKIM signature, is it an unreasonable statement?

 Detecting that series of bogus Received headers is one way to
 determine that a message is probably spam - it is not at all a
 useless technique (your most windows users MUAs don't tend
 to add Received headers at all - and nor should they - nor
 does nmh, which it also shouldn't - but if you deliver via a
 local sendmail/postfix/exim/... which I personally believe is
 the best way to config nmh, then it will (and should) and you
 need a domain name for that.
 
 I know we're never going to agree on the best way to configure
 mail submission, but you have admitted in the past that your
 have an unusual amount of control over your local domain, to a
 degree that I think very few people have nowadays.  Also,
 you've been around long enough that you probably remember
 having to deal with sendmail.cf directly rather than having it
 generated by m4 templates.  For you, registering a domain isn't
 a big deal because you did that already and of course sendmail
 configuration is easy.  But ... for the person who has a more
 traditional setup (e.g., has a residential ISP and submits to
 gmail), making that a requirement is overkill, and like I said
 earlier if they have to ASK how to configure sendmail here then
 they shouldn't be using it.  Their world will be easier if they
 submit email like everyone else does (and really, if they're at
 that level of sophistication then they won't get any of the
 advantages of having their own domain).

I also remember editing sendmail.cf files.  I also have an old
copy of the O'Reilly sendmail book, from the mid-1990s.  But to
say I did more than copy the sendmail.cf file from elsewhere,
edit the hostnames, and cross my fingers, would be to give me far
more credit than I deserve!  B-)  And it sent me down the wrong
track for years, something that more-or-less worked (though there
were significant limitations) until this issue with Stanford's
anti-spam tool finally forced the realization that (a) I didn't
have a proper host/sendmail setup and (b) there are proper tools
to do the job without needing to use or understand sendmail or
break one's /etc/hosts file!  (And I would be still be lost
without this wonderful mailing list and the people here!)

The average NMH user probably has more *nix and sysadmin
knowledge than the average Ubuntu user, but if I'm at all
representative of that average NMH user then we have enough just
to be dangerous to ourselves.  B-)

Bob

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

[Sorry, inadvertently sent an early version of this reply while
 testing the script!]

On Thu, 12 Mar 2015 20:47:10 -0400 Ken Hornstein k...@pobox.com sez:

 Hi Bob,
 
  with:  for some reason, bash seems to only save C-1
  characters of output, where C is the number of columns in the
  xterm in which I'm running the script.
 
 No, I don't think bash does that.
 
 As Ralph pointed out, bash simply does not have anything to do with
 truncating the output ... if it's a Unix pipe it's not even involved
 (after the file descriptors are established).

Ah, good.  I was quite confused on this point!

 Now, there is a wrinkle here.  _IF_ you're using scan(1), by
 default it will truncate output at the terminal width.  See the
 -width option to scan(1) to change that.  Buuu  IF
 you're doing whom(1) on the draft, then a) every email address
 ends up on it's own line, and b) whom(1) (really, post(8)) does
 NOT truncate the output at the terminal width.  I looked at the
 code AND I just double-checked that to make sure.  So it sure
 would be interesting to understand exactly what is happening.

That was it!  It was scan(1), under the default width (because I
was not using -width).

And, confession time: I didn't check to see whether the problem
was also occurring with whom(1), since I had already spent more
than an hour unsuccessfully trying to solve the problem and was
going to be late for an appointment.

Thanks!

Bob

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

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

On Wed, 11 Mar 2015 09:28:37 - Ralph Corderoy ra...@inputplus.co.uk sez:

 Hi Bob,
 
   scan -format '%{to},%{cc},%{bcc},%{dcc},' $draftname |
   grep -iq '@stanford\.edu[,]'
 ...
  apparently MH aliases are expanded *after* this script is invoked.  I
  emailed someone that I have aliased, so that in my draft it is
  
   To:  foobar
  
  and in my aliases file it expands based on the entry
  
   foobar:  foo...@stanford.edu
  
  But the script only sees foobar and not the expanded address.
 
 This should give an easier format to grep anyway.
 
 whom $draftname |
 grep ...

It does, but then I can't use whom(1) since that will invoke the
script, leading to infinite recursion (at least, until the kernel
runs out of file descriptors B-).

Bob

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

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

On Tue, 10 Mar 2015 10:25:30 -0400 Ken Hornstein k...@pobox.com sez:

 I never even knew this was a possibility.  I've always put the
 filename last.  I'm definitely in favor of limiting it this way.
 Hopefully nobody has created a script that depends on this level
 of flexibility.  B-)  (It's highly likely that anyone using a
 custom postproc wrote it.  Is there some way to warn such users
 and prevent post(8) from completing, so that they can update
 their postproc without losing their draft or the draft being
 incorrectly post(8)-ed?)
 
 Considering that it has been that way for several decades, and
 literally every caller of post(8) would do that (depending on
 arguments) up to a few days ago ... I do not think that would
 be wise.  I think the best we can do change all of the callers
 to put the filename last and live with that.
 
 As for the man page ... sigh.  I understand your point, but
 like I told Ralph almost every nmh man page is like that, and
 has been like that forever.

Okay, so ixnay on the warning part.

As for the man pages, true it would be a lot of busywork, but why
not push new users toward specifying the arguments the preferred
way, with a warning at the bottom that the old way is still
supported but that support will disappear in the future?  You've
made major changes before, and recently -- e.g. MIME support.
The man pages this decade, and then the actual code next.  B-)

Bob

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

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

On Fri, 06 Mar 2015 11:49:12 + Ralph Corderoy ra...@inputplus.co.uk sez:

 Hi Ken,
 
   Though I still think it should be the last argument,
   otherwise every postproc author has to solve the same
   problem.
  
  I don't have strong feelings about this one; thoughts from
  others?  Fixing it is a simple change.

I never even knew this was a possibility.  I've always put the
filename last.  I'm definitely in favor of limiting it this way.
Hopefully nobody has created a script that depends on this level
of flexibility.  B-)  (It's highly likely that anyone using a
custom postproc wrote it.  Is there some way to warn such users
and prevent post(8) from completing, so that they can update
their postproc without losing their draft or the draft being
incorrectly post(8)-ed?)

 I also find
 http://git.savannah.gnu.org/cgit/nmh.git/tree/man/post.man#n10
 confusing in that it ends
 
 [-notls] file [-version] [-help]
 
 Assuming -version and -help have post exit before doing
 anything else, a more comman man page arrangement might be
 
 post ... [-notls] file
 post -version
 post -help
 
 This would make clear the one single file is the large argument
 in the common case.

+1!

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

On Tue, 03 Mar 2015 20:56:11 -0500 David Levine levin...@acm.org sez:

 Bob wrote:
 
  Funnily enough I was just starting to think about how to deal
  with this.  My first thought was to maintain 2 .mh_profile files
  and alias commands to set a soft link to the appropriate
  depending on the recipient.  Essentially, I just need to comment
  out the send entry in my .mh_profile.
 
  I take it that there's an NMH-way to do this?
 
 As Ken mentioned, that would be a postproc wrapper.  If you go the
 multiple profile route, it might be cleaner (than using a symlink)
 to set the MH environment variable to the one you want to use.

I agree.  And I finally figured out the (clearly-documented) way
of installing a custom postproc wrapper.  B-)

Bob

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

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

Thanks for the proposed localpostproc, Ken!

Unfortunately, I don't think I can use it, due to a lack of a
looping mechanism -- or, at least, a there-exists mechanism.
I need something that checks the recipients' host(s), which
means potentially checking more than 1 string.  The pseudo-code
would be roughly

 if @.*stanford.edu in {%(host{to}), %(host{cc}), %(host{bcc})}
 postflags=
 else
 postflags=-server smtp.gmail.com -port submission -tls -sasl -user 
dnc2dnc

I could break up the if-clause into 3 scan(1) invocations, but
things break down when there's more than 1 address in a given
component since, quoting from the mh-format(5) page:

 The return value of functions noted with `*' is computed
 from the first address present in the header component.

 [...]
 hostaddr string   the host domain*

Am I missing an obvious solution?

Thanks!

Bob

On Wed, 04 Mar 2015 12:25:41 -0500 Ken Hornstein k...@pobox.com sez:

 So after testing it for a day, I found a problem.
 Specifically, if you're using annotations on replies my simple
 script broke.  The reason is that the arguments ended up being:
 
   [...] draft filename -idanno N
 
 Where N was the file descriptor to write the annotation to;
 my previous iteration assumed the last argument to post was the
 filename.
 
 I ended up having to do this code (complete script appended at
 the end):
 
 find_draftmessage() {
 skip_next=0
 
 for arg; do
 case $arg in
 -al* | -filt* | -wi* | -client | -idanno | -server | \
 -partno | -saslmaxssf | -saslmech | -user | -por* | \
 -file* | -mhl* | -mt* | -cr* | -lib* | -oauth)
 skip_next=1
 ;;
 -*) skip_next=0;
 ;;
 *)
 if [ $skip_next -eq 0 ]; then
 draftmessage=$arg
 return 0
 fi
 skip_next=0
 ;;
 esac
 done
 
   echo Cannot find draft message name in argument list
 exit 1
 }
 
 I am just wondering out loud if there is a better way than
 putting knowledge in the script of whether a particular switch
 takes an argument.  It just seems brittle to me.  Ideas?  Other
 approaches?
 
 --Ken
 
 



 #!/bin/sh
 #
 # localpostproc - decide where to send email based on the draft message
 #
 
 #
 # Find out which message is the draft message; yes, this sucks
 #
 
 find_draftmessage() {
   skip_next=0
 
   for arg; do
   case $arg in
   -al* | -filt* | -wi* | -client | -idanno | -server | \
   -partno | -saslmaxssf | -saslmech | -user | -por* | \
   -file* | -mhl* | -mt* | -cr* | -lib* | -oauth)
   skip_next=1
   ;;
   -*) skip_next=0;
   ;;
   *)
   if [ $skip_next -eq 0 ]; then
   draftmessage=$arg
   return 0
   fi
   skip_next=0
   ;;
   esac
   done
 
   echo Cannot find draft message name in argument list
   exit 1
 }
 
 realpost=$(mhparam libdir)/post
 
 if [ $# -eq 0 ]; then
   echo Usage: [post switches] filename
   exit 1
 fi
 
 find_draftmessage $@
 
 fromhost=$(scan -format '%(host{from})' -file $draftmessage)
 
 if [ $? -ne 0 ]; then
   echo Unable to run scan on draft file $draftmessage, aborting
   exit 1
 fi
 
 if [ -z $fromhost ]; then
   echo Could not determine hostname of From: address
   exit 1;
 fi
 
 case $fromhost in
   *.some.other.host)
   postflags=-server some.other.server -sasl -port submission
   ;;
 
   pobox.com)
   postflags=-server smtp.pobox.com -sasl -tls -port submission
   ;;
 
   *)
   echo Don't know how to send email from $fromhost
   exit 1
   ;;
 esac
 
 exec $realpost $postflags $@

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

Re: [Nmh-workers] Multi-homed postproc, v2

[Bob Carragher]

On Thu, 05 Mar 2015 22:47:34 -0500 David Levine levin...@acm.org sez:

 Ken wrote:
 
  Have the interface to post(8), and thus postproc, include the
  `file' parameter as an environment variable as well.  True, this
  means post has two places to get the data, but it also keeps simple
  filter scripts simple.
 
  Seems reasonable to me; any objections?
 
 I'm not a fan of environment variables, especially when they're
 not really needed.  And one place to get the data is better than
 two.

I also am not a fan of environment variables.  They've bitten me
way too many times.  Limiting data input to just 1 mechanism is
more preferrable.

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

On Thu, 05 Mar 2015 10:41:30 -0500 Ken Hornstein k...@pobox.com sez:

 My current theory is that my email address is now strongly
 associated with spam, or at least suspicious email, and so any
 email I send there has a high base score.
 
 That, to me, does not explain why your email was being mangled (from
 what I remember, your recipients complained about your mangled email
 address).  If you unmangle the body of that message it passed the DKIM
 signature, so that wasn't something you did.  If it was me, I'd focus
 on that.

No, it doesn't.  But so far there has only been 1 message (that
I'm aware of) where the mangling took place.  All other copies
of headers that I've received from @stanford.edu recipients
have not shown that weird effect.  (I'm still having people
forward spam-tagged message headers to me.)  So, until I see
that again, I'm going to cross my fingers and hope it was a
one-time, unrelated blip.

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

The saga is not yet over.  One domain in particular, @stanford.edu,
is now tagging my emails even more strongly as spam.  I'm seeing
replies from folks there with the Subject: line changed to:

 Re: [SPAM:#] original-subject

with the number of #s indicating how strongly the tagging is.
(This had happened previously, but the number of #s never
exceeded 3.) Also, their list servers are now silently rejecting
my posts, whereas that had never occurred previously.  (If I
switch back to using sendmail, then the posts go through to the
mailing lists.)

I'm asking people I'm emailing to forward me copies of my
messages, hoping the headers contain clues.  Any suggestions from
the folks here would be greatly appreciated!

On Sun, 01 Mar 2015 22:27:56 -0500 Ken Hornstein k...@pobox.com sez:

 To follow up a bit ...
 
 I checked my install notes, and I didn't note performing any
 configure steps.  I simply apt-get-ed the package (I'm running
 Ubuntu 13.10 -- yes, I'm REALLY behind B-), and then did the same
 for sendmail (which is not installed by default).  The latter
 action may have switched things in mts.conf.
 
 Hm, I guess that decision was made by whoever created that package.
 In that case, sendmail should have been a dependency.

It looks like they had set up a dependency on the postfix
package, instead of sendmail.

 Is submission a port name that is aliased to 587?
 
 Those are listed in /etc/services.

Got it!

 From another email by you:
 
 Also, while I can specify a server in the /etc/nhm/mts.conf file,
 I cannot specify a port.  Is there some way to do so without
 needing to explicitly call send(1) with those options? 
 
 No; we've talked about that, but we haven't come to an
 agreement to do it.
 
 Hate to throw another monkey wrench ... but depending on your
 server, inc(1) might be able to be used instead of fetchmail.

Ha ha, yes, I remember the discussions about using inc directly
instead of going through fetchmail/sendmail.  I also realized
that, if I didn't have sendmail up and running, my current use of
fetchmail would fail.  Given the hiccup, above, with sending
email, I'm going to leave well enough along on the inbound side
for now.  B-)

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

On Mon, 02 Mar 2015 20:57:10 -0500 Ken Hornstein k...@pobox.com sez:

  Re: [SPAM:#] original-subject
 
 with the number of #s indicating how strongly the tagging is.
 (This had happened previously, but the number of #s never
 exceeded 3.) Also, their list servers are now silently rejecting
 my posts, whereas that had never occurred previously.  (If I
 switch back to using sendmail, then the posts go through to the
 mailing lists.)
 
 It looks like Stanford uses Proofpoint:
 
 https://itservices.stanford.edu/service/emailcalendar/email/spam/antispam
 
 And there should be a X-Proofpoint-Spam-Details header that
 should give you some information.  But a quick Googling
 suggests to me that Proofpoint is notoriously stingy on what
 those things mean.

Yep!  Here's 1 set from the header of the above message:

 X-Proofpoint-Virus-Version: vendor=fsecure 
engine=2.50.10432:5.13.68,1.0.33,0.0.
  definitions=2015-03-01_03:2015-02-27,2015-03-01,1970-01-01 signatures=0
 X-Proofpoint-Spam-Details: rule=spam policy=default score=99 spamscore=99 
suspectscore=7 phishscore=0
  adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
  engine=7.0.1-140224 definitions=main-1503010244

It's pretty clear why they tagged my message with 5 #s.

There are three occurrences of the following, associated with
Received: entries, in the header:

 (No client certificate requested)

I'm guessing that those are harmless.

There's also an spf=softfail in there.

 Authentication-Results: mx.google.com http://mx.google.com;
spf=softfail (google.com http://google.com: domain of 
transitioning dnc2...@gmail.com dnc2...@gmail.com does not designate 
171.67.219.78 as permitted sender) smtp.mail=dnc2...@gmail.com 
dnc2...@gmail.com;
dkim=fail header.i=@gmail.com http://gmail.com;
dmarc=fail (p=NONE dis=NONE) header.from=gmail.com 
http://gmail.com

Note that 171.67.219.78 is smtp-grey.stanford.edu.

Might this be the smoking gun?

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

 http://smtp-grey.stanford.edu (Postfix) with 
 ESMTPS id AB17E20B81;
  Sun,  1 Mar 2015 14:04:12 -0800 (PST)
 Received: from pps01.stanford.edu http://pps01.stanford.edu 
 (pps01.stanford.edu http://pps01.stanford.edu [171.67.214.163])
  (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
  (No client certificate requested)
  by mx4.stanford.edu http://mx4.stanford.edu (Postfix) with ESMTPS id 
 9A8DC80CD1;
  Sun,  1 Mar 2015 14:04:12 -0800 (PST)
 Received: from pps.filterd (pps01.stanford.edu http://pps01.stanford.edu 
 [127.0.0.1])
  by pps01.stanford.edu http://pps01.stanford.edu (8.14.5/8.14.5) with SMTP 
 id t21M03ir010851;
  Sun, 1 Mar 2015 14:04:14 -0800
 Received: from mx3.stanford.edu http://mx3.stanford.edu (mx3.stanford.edu 
 http://mx3.stanford.edu [171.67.219.73])
  by pps01.stanford.edu http://pps01.stanford.edu with ESMTP id 1sva6d059f-1
  (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
  Sun, 01 Mar 2015 14:04:13 -0800
 Received: from mail-pd0-f179.google.com http://mail-pd0-f179.google.com 
 (mail-pd0-f179.google.com http://mail-pd0-f179.google.com [209.85.192.179])
  (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
  (No client certificate requested)
  by mx3.stanford.edu http://mx3.stanford.edu (Postfix) with ESMTPS id 
 5585080B25;
  Sun,  1 Mar 2015 14:04:11 -0800 (PST)
 Received: by pdbfl12 with SMTP id fl12so3394322pdb.5;
 Sun, 01 Mar 2015 14:04:10 -0800 (PST)
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com http://gmail.com; s=20120113;
 h=message-id:from:originator:to:cc:reply-to:subject:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding:date;
 
 
 
 X-Received: by 10.70.44.203 with SMTP id g11mr42282044pdm.130.1425247450905;
 Sun, 01 Mar 2015 14:04:10 -0800 (PST)
 Received: from localhost.localdomain (c-71-202-61-143.hsd1.ca.comcast.net 
 http://c-71-202-61-143.hsd1.ca.comcast.net. [71.202.61.143])
 by mx.google.com http://mx.google.com with ESMTPSA id 
 dx6sm10044832pab.14.2015.03.01.14.04.09
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 01 Mar 2015 14:04:09 -0800 (PST)
 Message-ID:  
 From: Bob Carragher dnc2...@gmail.com dnc2...@gmail.com
 Originator: Bob Carragher dnc2...@gmail.com dnc2...@gmail.com
 To:  x...@stanford.edu x...@stanford.edu
 Cc:  y...@gmail.com y...@gmail.com,
  z...@stanford.edu z...@stanford.edu
 Reply-To: Bob Carragher dnc2...@gmail.com dnc2...@gmail.com
 In-reply-to: Message MM 
  from  x...@stanford.edu x...@stanford.edu
  on Sun, 01 Mar 2015 05:05:34 -0800.
 References: MM 
 MIME-Version: 1.0
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: 7bit
 Date: Sun, 01 Mar 2015 14:04:02 -0800
 X-Proofpoint-Virus-Version: vendor=fsecure 
 engine=2.50.10432:5.13.68,1.0.33,0.0.
  definitions=2015-03-01_03:2015-02-27,2015-03-01,1970-01-01 signatures=0
 Subject: [SPAM:#] 
 X-Proofpoint-Spam-Details: rule=spam policy=default score=99 spamscore=99 
 suspectscore=7 phishscore=0
  adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
  engine=7.0.1-140224 definitions=main-1503010244
 X-Grey: yes

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

[Just the spacing bit.  B-]

On Mon, 23 Feb 2015 11:19:06 + Ralph Corderoy ra...@inputplus.co.uk sez:

  Interesting observation.  I've always found it to be the
  opposite and you're actually the first to have mentioned it.
  At least for me, I find that having the text wrapped at odd
  places, or not wrapped at all depending on the
  terminal/software displaying it, is much more difficult.
 
 I'm on the GNU groff mailing list, and there's the odd correspondent
 there that runs their emails through nroff.  :-)  It also fully
 justifies on a TTY, e.g.
 
 tr -dc 0-4a-c /dev/urandom | tr -s a-z \\n | sed 100q |
 nroff | grep .
 
 Thankfully, man(1) has --nj that can be put into $MANOPT.  :-)
 
 A larger space indicates to me a significant break, e.g. end of
 sentence.  Lack of hyphenation means many spaces are becoming two in
 your formatting, creating ugly rivers of whitespace.  These are a
 problem in typesetting of proportional fonts fully justified;
 fixed-width doesn't have a chance.  Subjective, I agree.
 
 It also breaks vim's formatting of the ` ' quotes lines above, i.e. it
 preserves the multiple spaces thinking they're significant.
 
 Cheers, Ralph.

As a vote in the other (or perhaps meh) direction, I've been
reading man pages long enough that fully-justified spacing
doesn't jump out at me anymore, unless it's *really* bad.

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

On Sun, 01 Mar 2015 08:35:02 -0500 David Levine levin...@acm.org sez:

 Bob wrote:
 
   [Ken:]
   If your mts.conf has a setting of sendmail/smtp or
   sendmail/pipe for mts, you can temporarily override that
   via the -mts switch (you want smtp for the MTS).
 
  What program do I use -mts with?  It is not a valid option for
  send(1), at least with version 1.5:
 
   % send -draft -snoop -server smtp.gmail.com -port 587 -tls -sasl -user 
  dnc2dnc
   send: -mts unknown
 
 Because that's a 1.6 feature :-)

I'm s behind.  B-)

 The allowed values for -mts are, without the quotes: smtp,
 sendmail/smtp (or sendmail), and sendmail/pipe, per
 mh-tailor(5). You succeeded with the default of smtp. Ken was
 just pointing out that because you had tailored your mts.conf
 to use another setting, you can override that on the command
 line, with 1.6.
 
 The default of smtp for the mts is coded in configure.  It
 sounds like you're overriding that to be sendmail.

I checked my install notes, and I didn't note performing any
configure steps.  I simply apt-get-ed the package (I'm running
Ubuntu 13.10 -- yes, I'm REALLY behind B-), and then did the same
for sendmail (which is not installed by default).  The latter
action may have switched things in mts.conf.

  Also, while I can specify a server in the /etc/nhm/mts.conf file,
  I cannot specify a port.  Is there some way to do so without
  needing to explicitly call send(1) with those options?  I couldn't
  find anything I could use in ~/.mh_profile
 
 This should work your profile:
 
 send: -draft -server smtp.gmail.com -port 587 -tls -sasl -user dnc2dnc

That worked!  Thanks!

 Or -port submission.  And you could include -snoop, but I expect
 that's just temporary so can be added on the command line.

Is submission a port name that is aliased to 587?

 As a quick check, after adding a send: line to your profile, it should
 show up at the bottom of the output from send -help.

Yes, it did!

 Thanks for posting the details of how you got your direct submission
 to gmail to work.  The setup is common to other providers as well.

You're welcome!  Thank you (all) for all your help!

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

Apologies to Ken and others who replied to this a week ago!  Last
week turned into a very busy week for me.  B-(

Also, I posted this using Ken's suggestion of send(1) below, while
connected to a different ISP than mine (Comcast), so ... success!!
Thank you for this much, Ken!!!



On Sat, 21 Feb 2015 23:25:52 -0500 Ken Hornstein k...@pobox.com sez:

 Good question.  I'm assuming it's because of the different sender
 domain versus From: domain because friends have warned me that
 their mailer is popping up a this email might not have been sent
 by dnc2...@gmail.com warnings.  I also see something similar
 when GMail tags my own messages (that I've Cc-ed myself on).
 
 Yeah, based on what Oliver said, I think my first guess was wrong;
 you're almost certainly being tripped up by the SPF rules gmail is
 using.

I'm guessing that this might be a good document for me to become
familiar with:

 http://www.openspf.org/FAQ/Common_mistakes

 Is there a better domain to use?
 
 Well, I was thinking that probably you should just let someone else
 add the message-id, or create your own (see send(1) and the -msgid and
 -messageid options), but really, I think submitting directly to gmail
 is better.

Submitting directly makes sense to me.  I just never thought I had
the ability to do so, and had to rely on going through my ISP's
mail servers to legitimize my email.  (Thus, when I'm not
connected to my ISP, I post emails using GMail's web interface,
which is a real pain in the ass since I compose them using vim and
must then copy-and-paste component-by-component for each message.)

 Comcast is my ISP, but I don't want sendmail thinking that
 another Comcast user's email address (e.g. foo.u...@comcast.net)
 is a local address, trying (and failing) to send email to a
 non-existent user on my computer.  I also don't want the Sender:
 address that would be generated (b...@comcast.net) to be seen as a
 possible address for mailers to send replies to (see below).
 
 Ah, okay. post(8) will no longer create a Sender: header for what it
 THINKS (and frequently got wrong ) is the email address as of 1.5.  So
 that should not be a concern anymore.

Thanks for pointing that out!  I hadn't noticed that before, but
a quick grep through my outbox shows that a Sender: field hasn't
been inserted into my email headers since around the time I
upgraded to 1.5.  (I did that while I was away from my ISP, so the
last such altered email was from before the trip.)

 Not needing to use Sendmail would probably be a godsend for me,
 as I obviously don't understand it or how to correctly set it up!
 I can try this and see if I'm successful.
 
 Could you point me to a man page, or maybe NMH archives that I
 could read to experiment?
 
 I think you should look at send(1), specifically the following
 options:
 
   -server
   -port
   -tls
   -sasl
   -user
 
 If your mts.conf has a setting of sendmail/smtp or
 sendmail/pipe for mts, you can temporarily override that
 via the -mts switch (you want smtp for the MTS).

Nope, I'm using the default mts.conf file, which specifies
sendmail for the MTS:

 # grep mts /etc/nmh/mts.conf 
 mts: sendmail

This has not changed since the first time I configured MH on my
own computer (as opposed to letting *real* sysadmins do it), so,
for at least 15 years.

What program do I use -mts with?  It is not a valid option for
send(1), at least with version 1.5:

 % send -draft -snoop -server smtp.gmail.com -port 587 -tls -sasl -user 
dnc2dnc
 send: -mts unknown

(I was able to test the above -- successfully, at least in that
I was able to send email, though I don't know if it appears
spammy to recipients other than me -- by editing the
/etc/nmh/mts.conf file to specify smtp for the mts value,
setting up a ~/.netrc file for my GMail account, and then using
send(1) with the above switches.)

Also, while I can specify a server in the /etc/nhm/mts.conf file,
I cannot specify a port.  Is there some way to do so without
needing to explicitly call send(1) with those options?  I couldn't
find anything I could use in ~/.mh_profile, or another user-level
config file, or environment variables.  So right now I'm doing the
following for each message instead of just using comp(1):

 % vim Mail/draft
 % send -draft -snoop -server smtp.gmail.com -port 587 -tls -sasl -user 
dnc2dnc

Is the answer to all the above questions/problems, Upgrade to
version 1.6?  B-)

 Ralph pointed you this web page:
 
 https://support.google.com/mail/troubleshooter/1668960?hl=en#ts=1665119,1665162
 
 Which should point you in the right direction.  You can also
 add -snoop to see what is actually being exchanged between you
 and the gmail servers.  I just want to caution you up front ...
 if, for instance, you run into problems and you want to post
 the output from -snoop, you should be careful as some of the
 exchanges can expose your password (it will be base64 encoded,
 but anyone can undo that).

Thanks for 

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

On Sun, 22 Feb 2015 13:53:41 + Ralph Corderoy ra...@inputplus.co.uk sez:

 Hi Bob,
 
  Here are the (I think) relevant bits of my sendmail.mc file:
  
   FEATURE(masquerade_envelope)dnl
   FEATURE(`genericstable')dnl
   GENERICS_DOMAIN(`localhost.localdomain')dnl
   MAILER(`local')dnl
   MAILER(`smtp')dnl
   define(`SMART_HOST', `[smtp.comcast.net]')dnl
   MASQUERADE_AS(gmail.com)dnl
 
 Stop sending outgoing mail through comcast as the smarthost;
 Gmail is the smarthost instead.  You won't persuade the rest of
 the world that you're really dnc2...@gmail.com unless your
 email eminates from Gmail's servers.  As well as publishing DNS
 TXT records containing SPF, Google also use DKIM.
 
 https://en.wikipedia.org/wiki/Sender_Policy_Framework
 https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
 
 And I wouldn't have thought you'd want a Sender header giving
 another version of events either, so if that's appearing then
 find out what's adding it, e.g.  nmh, or local Sendmail because
 it doesn't trust your user to lie about the From address, and
 stop it.  This might go away if you switch away from sendmail.

You are correct:  I don't want a Sender: field showing different
versions of events.  In fact, I worked hard to try to suppress
that many years ago, but eventually gave up because I couldn't
figure out what was causing it.  That's what led me to making
sure that it always specified a domain of @localhost.localdomain.

But, as Ken pointed out in his reply, this has been stopped as of
NMH 1.5, and I was able to verify that it hasn't been generated
in my emails since I upgraded.

So, that at least is not a problem anymore.

  Please send me details on using Exim.  If that eliminates the need for
  Sendmail, or at least for me to directly configure it, I'm all for it!
  I only use Sendmail to send my own outgoing emails (which always use
  my GMail account).
 
 Is sendmail involved with listening for incoming email to you?
 Or do you pull it down with fetchmail or similar?  If you still
 want a local SMTP server, e.g.  for programs that expect to
 pipe an email to `sendmail' to send it, then you could consider
 something simpler, intended to do just that one job, e.g.
 http://manned.org/ssmtp.8
 https://packages.qa.debian.org/s/ssmtp.html

I use fetchmail to pull down email.  So sendmail is used solely
for outgoing email.  I rarely have need to send (myself) local
email, so all of it is intended to leave my computer.

I know that using sendmail is very much overkill for my needs.
On the other hand, if it's just a matter of a couple of
adjustments in my existing sendmail.mc file, then I'd normally
prefer that over trying something new simply because email
doesn't come with true verification of delivery.  (If the
recipient doesn't reply in a way that lets you conclude the
message was received, then you must play the Did you receive
it? game.)

  but I don't know how to set that up with sendmail.  Would this be a
  good reference (for TLS)?
  
   http://www.sendmail.org/~ca/email/starttls.html
 
 I'd be surprised if it's that much work, but then this is
 sendmail.  :-) Perhaps it's doing all that because it's
 interested in receiving emails too, which you're not bothered
 with.

Entirely possible.  I'll be very happy if I don't need to do
that much work!  B-)

 If you only need nmh email to go out through Gmail, and all
 other local emails to just stay locally, then your ideal might
 be to have nmh send directly to Gmail with no other local
 program involved, and I think it can do that these days;  see
 the send(1) options Ken suggested.

I tried that and succeeded!!!  There are still some things that
need to be set up, but at least the proof-of-concept succeeded.
If I can completely eliminate sendmail, I'll be very grateful to
you for also pushing me to use send(1)!  B-)

Bob

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

Re: [Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

[Note:  this email is being sent directly from the GMail web
 client, so its header should be correct and not spammy.]

On Thu, 19 Feb 2015 15:58:21 -0500 Ken Hornstein k...@pobox.com sez:

 As you can probably see from this message's header, my nominal
 email provider is Google (@gmail.com) but my ISP is Comcast.  In
 particular, they are not the same domain.  Nor are my Google
 account's username and my machine's login ID the same (for
 historical reasons).  So, even though I set up as much of my
 composed message's header to reflect the @gmail.com account, it's
 pretty clear that it's coming from someone else.  Hence, the
 tagging of them by aggressive filters as spam.

 So, it might be useful to figure out exactly what is causing
 the spam tagging, and work on that.  I know that this is
 sometimes hard to discover.

 I can only say that this email has one domain, but is being
 submitted to another domain and AFAIK, I get caught in zero
 spam filters ... at least, that's what I can tell.

Good question.  I'm assuming it's because of the different sender
domain versus From: domain because friends have warned me that
their mailer is popping up a this email might not have been sent
by dnc2...@gmail.com warnings.  I also see something similar
when GMail tags my own messages (that I've Cc-ed myself on).

 Note:  since my machine login ID is a pretty common one, to avoid
 my emails bounces going to someone else accidentally I set up
 sendmail to specify my domain as @localhost.localdomain.  This no
 doubt also contributes to the spam-tagging.

 Well, I guess I would wonder what the effects of that are.
 First off, I see your message-id has @localhost.localdomain
 in it; if I had to guess, I would think that would be one of
 the biggest things that spam filters are being triggered by in
 your case.  Also ... I don't understand why you would need to
 do this to stop email bounces.  Your bounces should be going to
 the envelope-from address, and that looks like it is set
 correctly.

Is there a better domain to use?

Comcast is my ISP, but I don't want sendmail thinking that
another Comcast user's email address (e.g. foo.u...@comcast.net)
is a local address, trying (and failing) to send email to a
non-existent user on my computer.  I also don't want the Sender:
address that would be generated (b...@comcast.net) to be seen as a
possible address for mailers to send replies to (see below).

As for why I'm using @localhost.localdomain, that's for
historical reasons.  In the (dim-and-distant) past, a few friends
complained that replies to my emails would actually be set up to
be sent to the Sender: address, despite my From: and Reply-To:
fields being set to my public email address.  (Other than that
address, I haven't changed my $MH_DIR/components in probably 15
years.)  I used to use mit.edu as my computer's domain (because
I didn't know about @localhost.localdomain), and there really
is/was an active b...@mit.edu email address who actually received
a few of those replies.

 I'm guessing that one simple solution might be to purchase my
 own domain, and then register it with GMail as an equivalent
 address to validate my emails as non-spam.  I'd like to avoid
 this if possible.

 So my configuration is that I do not use sendmail at all; I
 have nmh do authenticated SMTP directly to the mail server I
 send stuff through.  I think that if you did that you'd be in
 much better shape; for starters, your message-id would be a lot
 better.  You might have to do slight tweaking to get that to
 work right with gmail (like enabling your account for
 insecure applications), but I believe it should work fine
 with the stock nmh.

 We have contribued work from Eric Gillespie to support the
 XOAUTH protocol used by gmail; it's on my list of things to
 integrate, but it's kind of complicated and I haven't yet had
 the time to figure it out.

Not needing to use Sendmail would probably be a godsend for me,
as I obviously don't understand it or how to correctly set it up!
I can try this and see if I'm successful.

Could you point me to a man page, or maybe NMH archives that I
could read to experiment?

Thank you very much!!!

Bob

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

[Nmh-workers] Emails being tagged as spam -- NMH solution???

[Bob Carragher]

(I apologize if this has already been answered, or because this
is a more general, non-NMH-specific problem.  I'm guessing that
others on this list have encountered and solved this before.)

Emails that I send are starting to be tagged as spam or potential
spam more frequently these days.  (This has been happening for a
good while, but recently started to reach the pain threshold.)

As you can probably see from this message's header, my nominal
email provider is Google (@gmail.com) but my ISP is Comcast.  In
particular, they are not the same domain.  Nor are my Google
account's username and my machine's login ID the same (for
historical reasons).  So, even though I set up as much of my
composed message's header to reflect the @gmail.com account, it's
pretty clear that it's coming from someone else.  Hence, the
tagging of them by aggressive filters as spam.

Note:  since my machine login ID is a pretty common one, to avoid
my emails bounces going to someone else accidentally I set up
sendmail to specify my domain as @localhost.localdomain.  This no
doubt also contributes to the spam-tagging.

I'm guessing that one simple solution might be to purchase my
own domain, and then register it with GMail as an equivalent
address to validate my emails as non-spam.  I'd like to avoid
this if possible.

Has anyone else dealt with this situation successfully?  Is there
a solution that needs only NMH-level tweaking, or maybe an
adjustment to my sendmail's configuration?

Thanks!

Bob

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

Re: [Nmh-workers] .mh_profile question

[Bob Carragher]

On Mon, 02 Feb 2015 22:08:54 -0500 Ken Hornstein k...@pobox.com sez:

 Maybe someone can see what I'm doing stupidly here as I'm
 going blind.  I have some folders that have ? messages
 that I don't want to break up, so I want to go to a 5 digit
 message number in scan
 
 Others have already answered you, but to expand some more ...
 
 Arguments in the profile (as Robert already said) are processed
 by brkstring(), which just does simple space splitting.  Should
 it do more with quoting and escapes?  Probably.  But I always
 get hung up on what quoting we should support, and then
 actually WRITING that code ... bleh.  Also, this would be an
 incompatible change to the profile format, and I know how much
 you love those, Jon :-)
 
 So the short answer is: yeah, it doesn't work, we should fix
 that, but we haven't yet.  Suggestions to what exactly should
 be implemented would be welcome.

I'm sure others have suggested this before, though I don't recall
seeing it, so just in case not ...

If we had infinite volunteer resources, what about creating a
completely new (and unified across all of MH) language?  It would
be accessed through a new file other than .mh_profile -- say,
.mh_new_profile, but better named.  B-)

This would allow us to make a clean break with the old language(s)
without immediately breaking our existing users and their scripts.
We could add a warning message to top-level MH commands, like
scan, indicating that the old language will not be maintained or
updated anymore (and is on life-support and that the plug will be
pulled at some unspecified point in the future) and that they
should move to the new language (with pointers to a new man page
showing lots of porting examples).  The warning message would be
output by default, although they can add an entry to .mh_profile
to turn it off (at their peril).

For the vast majority of users, who probably use the defaults
with little or no change, this would involve little or no effort,
and might even be a no-op.  For our power users, it could be a
pain, but the goal would be to make being a power user easier.

Like I said, If we had infinite volunteer resources   B-)

Bob

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

Re: [Nmh-workers] Back to Dates

[Bob Carragher]

Thank you very much, Ken, both for this nice recipe and the
detailed explanation of the code!  It actually cleared up a
couple of misconceptions I had!

It has also helped make a monster of my Date: field.  For
example, I now generate the following when viewing this message:

 Date:   Thu, 01 Jan 2015 23:07:40 -0500 (2015-01-01 20:07:40
[2 days ago])

The recipe for it, for the insanely curious, is:

 Date:formatfield=%(nodate{text})%{text}%|\
 %(pretty{text})%(void(szone{text}))%(eq 1) \
 (%(date2local{text})%04(year{text})-%02(mon{text})-%02(mday{text}) \
 %02(hour{text}):%02(min{text}):%02(sec{text})\
 %(rclock{text})\
 %(gt 60) [\
 %(gt 299592000)%(void (plus 15768))%(divide 31536) decade\
 %?(gt 31492800)%(void (plus 15768000))%(divide 31536000) year\
 %?(gt 2548800)%(void (plus 1296000))%(divide 2592000) month\
 %?(gt 84600)%(void (plus 43200))%(divide 86400) day\
 %?(gt 3300)%(void (plus 1800))%(divide 3600) hour\
 %|%(void (plus 30))%(divide 60) minute%%(gt 1)s% ago]%%)%%

I modified the recipe that Ken posted by extending it in the
obvious way (adding months, years, and even decades), but also to
only output when a message is at least 1 minute old.  I also
incorporated the recipe posted a little while back, for displaying
both the sender's date as-is, and my local time (and date).

Bob

 From: Ken Hornstein k...@pobox.com
 To:   nmh-workers@nongnu.org
 Date: Thu, 01 Jan 2015 23:07:40 -0500
 Subject:  Re: [Nmh-workers] Back to Dates

 It occurs to me that it might be useful to break this down a bit, to provide
 some explanation as to what's going on here.  You can use fmttest on it to
 get the instructions this decodes into, but that's not always that useful
 unless you've been inside of the format code a lot.

 - 
 Date:formatfield=%(nodate{text})%{text}%|%(pretty{text})%(date2local{text})
   [\
   %02(hour{text}):%02(min{text})\
   %(rclock{text})%(gt 8596800)%| - \
   %(gt 84600)%(void (plus 43200))%(divide 86400) day\
   %?(gt 3300)%(void (plus 1800))%(divide 3600) hour\
   %|%(void (plus 30))%(divide 60) minute%%(gt 1)s% ago%%]%

 This is the beginning of the line for the mhl file; it refers to any
 date header.  formatfield is the flag that says, Run this header
 through mh-format, and here's the mh-format string.  The wrinkle here
 is that the value of the header is made available via the special {text}
 component; in scan(1), the date header is in {date}.  Other utilitities
 that make use of mh-format(5) do the same thing.

 The decomposed mh-format string is:

 1) %
   If statement, will execute the next statements if the return value
   is non-zero.  Well, if it's a function that returns a string, true
   is if the string has a non-zero length.

 2) (nodate{text})
   Returns true if the {text} component (see above) is NOT a valid
   date.  Note that it does not have a leading '%'; this is because
 the if statement above knows that the following entry has to
 be a function or component, so the '%' is assumed.  Also note
   that the return value of this function is NOT output.

 3) %{text}
   Outputs the value of the {text}component.

 3) %|
   The else statement to 1) above.

 4) %(pretty{text})
   A user-friendly rendering of the date header.

 5) %(date2local{text})
   Converts the internally-stored date for {text} into the local
   timezone.  This requires some additional explanation.

   The first time address and date headers are accessed they are
   run through the respective parsers and internally stored with
   the component information.  So things like %(hour) don't have
   to parse the date header text again; they get it directly from
   the internal date structure.  What %(date2local) does is convert
   the internal date structure to the local timezone, but it does
   NOT change the text.  So in this case, %{text} still has the
   original date header, but things like %(hour{text}) refer to
   the hour in the local timezone.

 6) \n[ 
   Text, output literally

 7) %02(hour{text})
   The hour part of the time (local timezone, see 5)), width of
   2 digits, left padded with zeros.

 8) :
   Text, output literally

 9) %02(min{text})
   The minutes part of the time, in the local timezone, width of
   2 digits, left padded with zeros.

 10) %
   If statement, will execute this branch if 11) returns nonzero.

 11) (rclock{text})
   Returns the number of seconds date is off of the current time.
   Stores the value in the num register.

 12) %
   If statement, will execute this branch of 13) returns nonzero.

 13) (gt 8596800)
   If num is greater than 8596800 (99.5 hours), execute the next
   branch ... which is null.  This is the cutoff that doesn't print
   a date offset if the message is greater than 100 days old.

   A digression here: normally functions 

Re: [Nmh-workers] date math -- format help???

[Bob Carragher]

On Wed, 17 Dec 2014 09:53:07 -0500 David Levine levin...@acm.org sez:

 Bob wrote:

  By the way, there seems to be a formatting bug with zone
  when specifying wide fields with leading zeros.  For example,
  if you specify the Date: field this way
 
   
  Date:formatfield=%(nodate{text})%{text}%|%(pretty{text})%(void(szone{t
  ext}))%(eq
  1) %(date2local{text})%08(zone{text})%%
 
  You get
 
   Tue, 16 Dec 2014 23:24:30 -0500 -480
 
  I'm guessing negative integers were not expected by the
  padding function?  And perhaps it was also fixed with 1.6
  (or afterward)?

 It hasn't been fixed.  1.6 does provide fmttest -trace, which helps
 isolate the problem.  The number formatting function pads after
 inserting the - sign, ooops.  I'll fix it tonight.

Yet another reason to upgrade to 1.6.  B-)  Thanks!

Bob

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

Re: [Nmh-workers] date math -- format help???

[Bob Carragher]

On Tue, 16 Dec 2014 22:37:59 -0500 David Levine levin...@acm.org sez:

 Bob wrote:

  I'm on the US west coast, so the local time (in parentheses)
  should be -0800 (not -480).
 
  Can someone explain why this happens?

 That's working as intended, per mh-format(5):

 zone dateinteger  timezone in minutes

 Try this:

 tzonedatestring   timezone string

Ah, okay, that works!  My man page is for the older NMH 1.5,
and says something critically different at this point:

zonedate integer  timezone in hours
tzone   date string   timezone string

Based on what zone was stated to return, and influenced by
the thread's discussion, I had assumed that tzone would
return a symbolic timezone name.

Thanks!

Bob

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

Re: [Nmh-workers] date math -- format help???

[Bob Carragher]

On Tue, 16 Dec 2014 23:24:30 -0500 David Levine levin...@acm.org sez:

 Bob wrote:

  Ah, okay, that works!  My man page is for the older NMH 1.5,
  and says something critically different at this point:
 
   zone  date integer timezone in hours
   tzone date string timezone string

 Oh yeah, that was fixed after 1.6 went out.  Otherwise, we'd
 be asking you why you're still using 1.5 :-)

Oh, that's a perfectly valid question.  B-)

By the way, there seems to be a formatting bug with zone
when specifying wide fields with leading zeros.  For example,
if you specify the Date: field this way

 
Date:formatfield=%(nodate{text})%{text}%|%(pretty{text})%(void(szone{text}))%(eq
1) %(date2local{text})%08(zone{text})%%

You get

 Tue, 16 Dec 2014 23:24:30 -0500 -480

I'm guessing negative integers were not expected by the
padding function?  And perhaps it was also fixed with 1.6
(or afterward)?

Bob

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

Re: [Nmh-workers] modernizing smtp message submission

[Bob Carragher]

On 7 July 2014 at 19:32, Lyndon Nerenberg lyn...@orthanc.cawrote:

 Here's a survey:
 
 1) How many people customize mts.conf for mail submission?

I do not.

I didn't even know mts.conf existed until joining this mailing
list.  B-)

 2) How many customize that back-end agent?

Not ... *really*.

I use sendmail, and do a small amount of configuring/setup.
But none of that is specific to NMH.

Bob

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

Re: [Nmh-workers] Replying ... but not to me too

[Bob Carragher]

On Tue, 25 Mar 2014 21:09:15 -0400 Ken Hornstein k...@pobox.com sez:

  The (UW) Alpine equivalent is the 'alt-adresses' construct.  BSD Mail
  and SysV mailx both had equivalent settings as I recall.
 
 Sigh.  My only point was ... if b...@local.host.name is not, in fact, a
 valid email address for you, you'd be better served by changing
 Local-Mailbox.  It does more things (things you'd likely want) than
 Alternate-Mailboxes does.

I've tried this while also removing the Alternate-Mailboxes
entry.  It doesn't solve my original problem of suppressing
my (non-local @gmail.com) email address in replies.

Are you suggesting that I add both Local-Mailboxes and
Alternate-Mailboxes entries?

Bob

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

Re: [Nmh-workers] Replying ... but not to me too

[Bob Carragher]

On Wed, 26 Mar 2014 09:27:15 -0400 Ken Hornstein k...@pobox.com sez:

  Sigh.  My only point was ... if b...@local.host.name is not, in fact, a
  valid email address for you, you'd be better served by changing
  Local-Mailbox.  It does more things (things you'd likely want) than
  Alternate-Mailboxes does.
 
 I've tried this while also removing the Alternate-Mailboxes
 entry.  It doesn't solve my original problem of suppressing
 my (non-local @gmail.com) email address in replies.
 
 Are you suggesting that I add both Local-Mailboxes and
 Alternate-Mailboxes entries?
 
 Did you use Local-MailboxES, or Local-Mailbox?  The latter is the
 correct one (it's singular).

Argh, I used the incorrect (plural) one.  Changing to the proper
(singular) one did the trick!

   You could check exactly what nmh thinks is
 your local mailbox by executing the command:
 
 % ap -format '%(localmbox)' null
 
 (ap lives in your nmh lib directory).  That should show you what nmh thinks
 is your local mailbox, and that's what the Local-Mailbox setting changs.

Yep, it's catching the Local-Mailbox update!

 When I first started using MH (in grad school), the default for
 Local-Mailbox (user@host) was my actual mailbox address.  It
 wasn't until much later, when I started using a laptop and
 connecting via commercial ISPs, that my current situation arose,
 where user@host has no use for email purposes.  (In fact, I
 set up my repl*comps at that time to explicitly specify what my
 addresses, for From:, Reply-To:, etc., are.  They do that to
 this day.)
 
 Let me expand on this a bit.
 
 Local-Mailbox is a new feature, created as part of the address handling
 cleanup done for 1.5.  Like you said, the old way MH used to operate
 was that it would synthesize your local email address based on your local
 username and hostname; there was no way to override that (nor was there
 even a way to see what it thought it was).  The world has moved on since
 then, so for 1.5 I created the code that let you override the local mailbox
 setting.
 
 So what exactly does Local-Mailbox _do_?  Well, in addition to matching
 an email address as local (which really means it will match the
 %(mymbox) format function), it will be output by the %(localmbox)
 format function.  This is now used by component templates (components,
 repl*comps, forwcomps, distcomps) to fill in the From field.  Now you
 (and plenty of others) have been papering over this problem for a while
 now by adjusting the relevant components files yourself, but after a bunch
 of thrashing on the mailing list we all decided that we needed a better
 solution.

Just tried this, and it works!  Outstanding!  (I always thought my
solution was a hack, and it's great to know that there's support
for a proper solution.)

 So, Local-Mailbox changes nmh's idea of what your local mailbox is (which,
 in practice, boils down to changing the output of %(localmbox)).  Compare
 that to Alternate-Mailboxes (plural); what that does is simply add to the
 list that %(mymbox) will match.  That, plus a little extra magic, is how
 local email addresses don't end up in replies.
 
 Okay, long digression.  What's the right solution?  IMHO, it's:

But a *helpful* digression (for me)!  B-)

 - If localu...@local.host does not match your email address, add a
   Local-Mailbox line to your .mh_profile that has your complete email
   address (including your real name).

This is correct.

 - If you have additional email addresses that you want nmh to consider a
   local address, add them to Alternate-Mailboxes.

This is not correct, so I will eschew Alternate-Mailboxes.

A fix for a nagging problem, with the bonus of the cleanup of a
longstanding hack:  thanks a lot!  B-)

Bob

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

[Nmh-workers] Replying ... but not to me too

[Bob Carragher]

I think I have a very simple problem, but I've never been able
to solve it.  I want to prevent my public email address from
being included by repl.

I use (as you can see in this message's header) the public
email address dnc2...@gmail.com but on my computer it is
computed as something different (bob@localhost.localdomain).
I want to suppress both these addresses from appearing in my
replies, but -nocc me only catches the second one.

That is, say I received an email from Alice that was sent to
Carol, and Cc-ed to me -- e.g.

 From: Alice al...@foo.bar
 To: Carol ca...@foo.bar
 Cc: Bob dnc2...@gmail.com

Using repl -group -nocc me will still result in

 To: Alice al...@foo.bar
 Cc: Carol ca...@foo.bar,
 Bob dnc2...@gmail.com

Side note:  if I didn't use -nocc me then I'd get

 To: Alice al...@foo.bar
 Cc: Carol ca...@foo.bar,
 Bob dnc2...@gmail.com,
 Bob bob@localhost.localdomain

And, using just plain repl or repl -nocc me would give me

 To: Alice al...@foo.bar
 Cc: Bob dnc2...@gmail.com

Is there a way to also suppress my public email address (or, in
general, an arbitrary email address or set of addresses)?

Thanks in advance!

Bob

P.S.  the above results are generated using the default NMH
replcomps and replgroupcomps.

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

Re: [Nmh-workers] Replying ... but not to me too

[Bob Carragher]

Bingo!  I *knew* it was something simple!  (I wonder what else
in mh-profile I've not been using, but should have been, all
these years?)

Thanks a lot!!!

Bob

On Tue, 25 Mar 2014 14:10:43 -0700 Lyndon Nerenberg lyn...@orthanc.ca sez:

 See the Alternate-Mailboxes entry in the mh-profile(5) manpage.
 It lets you specify a list of addresses that should be treated
 the same as your local primary address.
 
Alternate-Mailboxes: mh@uci-750a, bug-mh*
 Tells repl and scan which addresses are really  yours.   In  this
 way,  repl knows which addresses should be included in the reply,
 and scan  knows  if  the  message  really  originated  from  you.
 Addresses  must be separated by a comma, and the hostnames listed
 should be the official hostnames for the  mailboxes  you  indi-
 cate,  as  local  nicknames for hosts are not replaced with their
 official site names.  For each address, if a host is  not  given,
 then  that address on any host is considered to be you.  In addi-
 tion, an asterisk (`*') may appear at either or both ends of  the
 mailbox  and  host  to  indicate  wild-card  matching.  (profile,
 default: your user-id)
 
 This should do what you want.
 
 --lyndon

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

Re: [Nmh-workers] Replying ... but not to me too

[Bob Carragher]

I did ... about 2 decades ago.  B-)  (I didn't need this option
back then.)  Seems like it's time to read them again.  B-)

Bob

On Tue, 25 Mar 2014 14:46:11 -0700 Lyndon Nerenberg lyn...@orthanc.ca sez:

 On Mar 25, 2014, at 2:37 PM, Bob Carragher dnc2...@gmail.com wrote:
 
  Bingo!  I *knew* it was something simple!  (I wonder what else
  in mh-profile I've not been using, but should have been, all
  these years?)
 
 Manpages are your friends.  Use them ;-)
 
 --lyndon

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

Re: [Nmh-workers] Replying ... but not to me too

[Bob Carragher]

On Tue, 25 Mar 2014 17:27:44 -0400 Ken Hornstein k...@pobox.com sez:

 I think I have a very simple problem, but I've never been able
 to solve it.  I want to prevent my public email address from
 being included by repl.
 
 What version of nmh?  It matters.

Lyndon's reply solved my problem, but here's my version:

 % man nmh | head -1 | awk '{print $2}'
 [nmh-1.5]

Bob

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

Re: [Nmh-workers] Setup help???

[Bob Carragher]

On Fri, 03 May 2013 18:21:42 -0400 valdis.kletni...@vt.edu wrote:

 On Fri, 03 May 2013 14:54:39 -0700, Bob Carragher said:
 
  Hmm, as in inc will do the fetching for me (so that I won't need
  to use fetchmail anymore)?  Oh wow, it does!  (It's been a long
  time since I read the man page for inc   B-)  What are the
  limitations that you hinted at?
 
 For starters, if you currently rely on a fetchmail | procmail | rcvstore
 pipe to presort your mail into folders, that won't work (AFAIK).

Nope, I use it at its most basic:  fetch email from the POP server
and dump it into /var/mail.

Bob

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

Re: [Nmh-workers] Setup help???

[Bob Carragher]

On Sat, 04 May 2013 10:21:26 -0400 Ken Hornstein k...@pobox.com wrote:

 I'd never heard of cyrus-sasl before, but I'd been installing
 openssl for awhile (I forget why).  Yeah, come to think of it, MH
 was never a reason I became tired of maintaining dependencies.  B-)
 
 Cyrus-sasl is a package which provides an API to do various
 sorts of authentication supported by different protocols (like
 SMTP  POP, which are what we care about in our case).  You
 probably wouldn't have heard of it unless you're in the middle
 of that stuff.

Got it.

 Hmm, as in inc will do the fetching for me (so that I won't need
 to use fetchmail anymore)?  Oh wow, it does!  (It's been a long
 time since I read the man page for inc   B-)  What are the
 limitations that you hinted at?
 
 inc can fetch email from POP server ... and in fact, it always
 had that capability going back maybe a few decades.  It wasn't
 always compiled in, though (more recently we made it always be
 compiled in).  I won't bore you with the exact technical
 details, but right now inc _can_ do encryption to the POP
 server _if_ you use a SASL mechanism that supports encryption
 (that's how I use inc).  But most POP servers (including the
 one at gmail) use TLS for encryption which currently inc
 doesn't support.  There is an option to make it work; people
 successfully use the -proxy switch to inc to run a program that
 does the TLS for you.  So yeah, you can make it work, it's just
 not as integrated as I would prefer.
 
 In fairness I must point out that there are a number of nmh
 users who don't feel inc should fetch email from POP servers;
 they prefer using fetchmail or an equivalent.  You can check
 the mailing list archives for the discussions about that; I
 don't think they're worth rehashing again.  Obviously I don't
 agree with that view, but I would be remiss if I didn't mention
 it.

Okay, I see.

Yeah, I would prefer to use the more integrated flows, so I'm not
likely to switch off of fetchmail in this case.

Thanks!

Bob

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

Re: [Nmh-workers] Setup help???

[Bob Carragher]

On Thu, 02 May 2013 21:52:08 -0400 Ken Hornstein k...@pobox.com wrote:

 My apologies!  It's version 1.3-1 (pretty ancient, I guess, but
 that's what's tied to my version of Ubuntu -- something else I
 need to update).
 
 Okay, yeah, that explains a lot.  There are some other features
 in nmh 1.5 that you might be interested in as well (the web
 page has details on the hilights).  The nmh home page is here:
 
   http://www.nongnu.org/nmh/
 
 Also, you _CAN_ always compile nmh on your own; we did try to
 make that as easy as possible.  You shouldn't need to be a
 programmer to do it.  There really shouldn't be too much in
 terms of system dependencies as long as your OS is relatively
 new (and by relatively, I mean, within a decade).

Then my OS (Ubuntu 10.04) will work.  B-)  I've avoided building
my own installs because I got tired of maintaining dependencies,
the main advantage (for me) of using Ubuntu.  (It used to be so
easy:  install GNU, then install X, then install a couple of
etc. software like MH and emacs.  B-)

 Yes, the version I'm using doesn't allow me to configure the
 Sender: field, which was the first thing I try.  NMH gives me
 the following error message:
 
  whom: illegal header line -- Sender:
 
 I wasn't aware that it was NMH that adds in the Sender: field.
 I thought it was sendmail.
 
 AFAIK, sendmail will never add a Sender: field.  MH (and as a
 consequence, nmh) had a very strong idea that your host's FQDN
 and local user account matched your email address; if it saw a
 mismatch between that and your supplied From: header, it would
 add a Sender: field.  That's finally been corrected as of 1.5.
 Now you can add a Sender: if you wish, but otherwise nmh will
 treat what you put in your draft as gospel.

Funny -- I was thinking of downloading the NMH source and hacking
it to stop it doing that, and then I read on some webpage that it
was sendmail that did that.  (Bad information!)

I'm really looking forward to version 1.5!

 In fact, my fix (as I mentioned in
 the other followup on this thread, and after a lot of googling)
 was to reconfigure sendmail to remap my local (illegal) address
 to dnc2...@gmail.com instead.
 
 It looks like from your other message that you're using spost.
 While there are a lot of strong opinions on how you should
 configure nmh for sending email (see the mailing list
 archives), I will point out that you don't even need to use
 sendmail at all; you can configure nmh to have post simply
 submit outgoing mail to the gmail SMTP server.  That would make
 it behave like every other mail program on the planet.  Doing
 that would also require 1.5, though (and you'd need to compile
 nmh with Cyrus-SASL and TLS support).

I wasn't aware I was using spost.  (Actually I wasn't aware of
the existence of an NMH package program called spost before.)

Not having to use sendmail has appeal, although I would still
need it for the incoming email that I fetch from GMail.  Though
I suspect that there's a way to do that as well without needing
sendmail.  (Ah, never needing sendmail again!  B-)

Thanks!

Bob

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

Re: [Nmh-workers] Setup help???

[Bob Carragher]

Thanks for the reply, Jerrad!

I had looked through that before, and tried several of the
options, but none of them worked.  The problem was always
with sendmail.  Even when I used the draft_from option with
the masquerade directive, sendmail would insert the dreaded
X-Authentication-Warning: field into the header.

However, I did finally resolve the issue -- by getting sendmail
itself to do what I wanted (masquerading as gmail.com and
remapping my local address as dnc2...@gmail.com).

Bob

On Wed, 01 May 2013 23:05:26 -0400 Jerrad Pierce belg4...@pthbb.org wrote:

 See the man page for mh-tailor which describes the mts.conf
 options for the address masquerading you wish to do.

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

Re: [Nmh-workers] Setup help???

[Bob Carragher]

Thanks for the response, Ken!

On Thu, 02 May 2013 08:56:03 -0400 Ken Hornstein k...@pobox.com wrote:

 First off ... you didn't mention a crucial piece of information: the
 version of nmh you're running.

My apologies!  It's version 1.3-1 (pretty ancient, I guess, but
that's what's tied to my version of Ubuntu -- something else I
need to update).

 This has generally worked, although (because I use sendmail) this adds
 the line
 
  Sender: laptop-userID@ISP
 
 This makes me think you're running something older than the latest
 version of nmh.  Starting with 1.5, nmh will no longer create Sender:
 header automatically; in fact, if you really want one, you have to add
 it yourself.  Also, there's a much cleaner way of configuring your local
 identity that works better with more modern configurations (like yours).
 Nmh 1.5 was released last June, so it's not exactly brand-spanking new.

I very much look forward to using 1.5, then!

Yes, the version I'm using doesn't allow me to configure the
Sender: field, which was the first thing I try.  NMH gives me
the following error message:

 whom: illegal header line -- Sender:

I wasn't aware that it was NMH that adds in the Sender: field.
I thought it was sendmail.  In fact, my fix (as I mentioned in
the other followup on this thread, and after a lot of googling)
was to reconfigure sendmail to remap my local (illegal) address
to dnc2...@gmail.com instead.

Happily, I was able to do this without needing to reconfigure
NMH (although I recognize that the sendmail solution is really
a hack, and that the configurability you describe with the 1.5
version of NMH would by far be preferred).

Bob

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

[Nmh-workers] Setup help???

[Bob Carragher]

Can someone please point me to resources or provide a simple How-To
for configuring NMH (and related systems, like sendmail)?  My setup:

*  Laptop running (Ubuntu 10.04) Linux.
*  My public address is dnc2...@gmail.com.
   --  I want all my email to appear to come from this address.  I have
   set From: and Reply-To: fields in my components and other
   configuration files.  However, I have problems with the generated
   Sender: field (see below).
   --  I use fetchmail to POP email from this address.  (I mention this
   only in case it changes the setup.)
*  I send mail when connected to my ISP, but fetch/POP mail whenever
   I'm connected to the Internet.  It would be nice to be able to use NMH
   to send mail whenever I'm connected to the Internet, but I will settle
   for continuing to use the Google web interface for that.
*  I added to /etc/hosts a FQDN that I don't normally send email
   to (mit.edu) because some mailers reject email that comes
   from foo@localhost or foo@localhost.localdomain.  I didn't
   add ISP because then any email I send to foo@ISP
   appears to be for a local user; also laptop-userID@ISP
   is taken.

This has generally worked, although (because I use sendmail) this adds
the line

 Sender: laptop-userID@ISP

to all my message headers.  In the last few years, more and more mail
providers are keying off this as an indication of spam, and in recent
weeks my email doesn't even reach some recipients at all (not even
deposited in their spam folder).

This *should* be a relatively common use case amongst NMH users,
so I have to believe that the setup for it should be straightforward.

I am the only user of this laptop, so if it is necessary to hard-code
the sender's ID and/or hostname, then I would be willing to do that.

Can anyone help, or point to help?

Thank you!

Bob

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