[nmh-workers] I Could Have Sworn that the inc Command used to work.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[nmh-workers] I Could Have Sworn that the inc Command used to work.

martin McCormick-3
I recently worked on my Debian box and mail began stacking up
from cron jobs that were erroring out because I had temporarily
removed the normal shell environment I use so I began getting the
"you have new mail" message which happens when the system checks
your mail queue as the shell prompt appears.

        I certainly can read the messages if I type mail but I
seem to recall one can type the inc command and all those
messages will slurp right in to nmh.

        When things are normal, procmail calls a small shell
script that sends the bell character to all logged-in sessions
and I put things back to normal and tried inc so all those
/bin/mail messages would become mh messages but nothing useful
happened.

        Should 'inc' manually pull in any messages in
/var/spool/mail/UID?

Thanks for any constructive suggestions.  This is not a major
issue but I'm curious as to whether I am just not remembering
things correctly.

Martin McCormick

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

David Levine-3
Martin wrote:

> I certainly can read the messages if I type mail but I
> seem to recall one can type the inc command and all those
> messages will slurp right in to nmh.

Yes, that should work.  I'd check to see what switches, if any,
you're passing to inc (inc -help will show them).

> Should 'inc' manually pull in any messages in
> /var/spool/mail/UID?

I'm not sure what the default maildrop is on Debian.  I would first
check if you have a MailDrop: entry in your profile that overrides
it.  inc has a -file switch, so you could try specifying your
maildrop explicitly.

I'm also not sure what your cron jobs do, and how procmail gets
called.  Are you using rcvstore?  Even if yes, inc should still
work.

One more thought:  make sure your inbox is writeable and is not
on a full partition.

David

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Bakul Shah
In reply to this post by martin McCormick-3
On Sat, 01 Jun 2019 09:17:16 -0500 "Martin McCormick" <[hidden email]> wrote:
> I recently worked on my Debian box and mail began stacking up
> from cron jobs that were erroring out because I had temporarily
> removed the normal shell environment I use so I began getting the
> "you have new mail" message which happens when the system checks
> your mail queue as the shell prompt appears.

It's the shell that checks $MAIL (or $MAILPATH). If either is
defined, you can your system mailbox

ls -l $MAIL # or $MAILPATH

when the shell informs you have mail.

> I certainly can read the messages if I type mail but I
> seem to recall one can type the inc command and all those
> messages will slurp right in to nmh.

Looks like inc pays attention to $MAILDROP and if it is not
set and profile entry MailDrop is not set, it looks into
/var/mail/$USER. Not sure if it ever checks $MAIL or $MAILPATH.

> When things are normal, procmail calls a small shell
> script that sends the bell character to all logged-in sessions
> and I put things back to normal and tried inc so all those
> /bin/mail messages would become mh messages but nothing useful
> happened.

If you are calling procmail from ~/.forward, mail may not be
left in your system mailbox
>
> Should 'inc' manually pull in any messages in
> /var/spool/mail/UID?

It should pull messages from your system mailbox and zero it.
if use -file some-mbox-file, it won't zero this file.

> Thanks for any constructive suggestions.  This is not a major
> issue but I'm curious as to whether I am just not remembering
> things correctly.

You can always run strace on Linux to see which files are
opened!  On FreeBSD I see it opening ~/.mh_profile,
/usr/ocal/etc/nmh/mts.conf and /var/mail/$USER among others.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Valdis Klētnieks
On Sat, 01 Jun 2019 18:51:35 -0700, Bakul Shah said:

> If you are calling procmail from ~/.forward, mail may not be
> left in your system mailbox

Also true if you've configured your system to skip a step and invoke
procmail as the local delivery agent directly

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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ralph Corderoy
In reply to this post by Bakul Shah
Hi Bakul,

> Looks like inc pays attention to $MAILDROP and if it is not set and
> profile entry MailDrop is not set, it looks into /var/mail/$USER.

That's pretty much right.

> Not sure if it ever checks $MAIL or $MAILPATH.

It doesn't, and it doesn't use $USER, or $LOGNAME, either.

inc(1) says

    If the environment variable $MAILDROP is set, then inc uses it as
    the location of the user's mail drop instead of the default (the
    -file name switch still overrides this, however).  If this
    environment variable is not set, then inc will consult the profile
    entry “MailDrop” for this information.  If the value found is not
    absolute, then it is interpreted relative to the user's nmh
    directory.  If the value is not found, then inc will look in the
    standard system location for the user's mail drop.

The source says

    -file's argument.
    MAILDROP environment variable.
    maildrop profile entry.
    mmdfldir/mmdflfil from mts.conf.
        mmdfldir defaults to HOME environment variable.
        mmdflfil is ‘unknown’ if getpwuid(3) fails or there's no
            pw_name, else it's the user part of the profile's optional
            local-mailbox, else it's pw_name from getpwuid(3).

Martin, along with all the other suggestions, could you be a mix of
users thanks to su(1) and thus your shell is telling you of mail in one
location, but inc(1) looking in another?

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

[nmh-workers] Fixed! I Could Have Sworn that the inc Command used to work.

martin McCormick-3
In reply to this post by martin McCormick-3
        Thank you to everybody who responded both on and off the
list.   The problem is correctly solved and here is what
happened.

        This is a good example of how long an incomplete
configuration can work perfectly until 0 Day when the right set
of circumstances make it glaringly obvious that something is
terribly wrong. Particulars follow.

        It all started 4 years ago when I retired after 25 years
in IT and I am embarrassed to say that I was supposed to have
known something about unix.  In the environment where I worked,
.mh_profile didn't need a line like:

Local-Mailbox: "Martin McCormick" <[hidden email]>

because any system we were using had a FQDN on the okstate.edu
network.  

        I still wanted to use nmh from home with our ISP, a cable
TV provider which meant a somewhat different setup in that our
home network is the typical  private number-space situation with
a meaningless reverse DNS lookup reference and a mail smarthost
that must make internet email work for each subscriber and it
does so once one's own system authenticates with the pop3 server
which is the reason for the local-mailbox declaration.

        After getting that setup, it has worked perfectly but
only because I also used procmail which did the job of catching
any message that landed in /var/mail/martin before it hit the
ground so to speak.

        Recently, I had to do some work on the system that
handles mail and procmail was temporarily indisposed due to the
normal home directory being absent.  nmh could still run but one
needed to use inc to grab the accumulating messages from the mail
spool.

        I also had put nmh on a Raspberry Pi plus
other aging PC's that run Linux but don't send mail in to the
network.  none of them would do inc either.

        The proper fix was to remove the local-mailbox
declaration I had unwittingly copied from the system that does
send internet mail to the ones that don't and on the one that
does, I now set the $MAILDROP environment variable and, so far,
all is peace and bliss now.

        Putting a

       MailDrop: .mail

line in .mh_profile did not change the wrong lookup but,
according to the man pages for mh-tailor.conf and mts.conf, the
environment variable MAILDROP supersedes .mh_profile settings
and that is what happened.

        Hints:

the strace program is your true and dear friend.  You don't even
need unincorporated mail for testing. Just

strace -e trace=file -o output inc

will tell you when it is good.  

Bad looks like

stat64("/var/mail/martin.m", 0xbfabfd70) = -1 ENOENT (No such file or directory)

Good looks like

stat64("/var/mail/martin", {st_mode=S_IFREG|0660, st_size=0, ...}) = 0

You can see that there was nothing there but it is referencing
the correct mail file.

        Again thanks, everybody.

Martin McCormick   WB5AGZ

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Fixed! I Could Have Sworn that the inc Command used to work.

David Levine-3
Martin wrote:

> The proper fix was to remove the local-mailbox
> declaration I had unwittingly copied from the system that does
> send internet mail to the ones that don't

I don't think that Local-Mailbox should affect inc, see Ralph's
excerpts from the man pages and sources.

> and on the one that
> does, I now set the $MAILDROP environment variable and, so far,
> all is peace and bliss now.

Glad to hear that!

> Putting a
>
>        MailDrop: .mail
>
> line in .mh_profile did not change the wrong lookup

I would think that it should be:

  MailDrop: /var/mail/martin

I assume that you use that value in your MAILDROP environment variable.

David

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Bakul Shah
In reply to this post by Ralph Corderoy


On Jun 2, 2019, at 3:15 AM, Ralph Corderoy <[hidden email]> wrote:

Hi Bakul,

Looks like inc pays attention to $MAILDROP and if it is not set and
profile entry MailDrop is not set, it looks into /var/mail/$USER.

That's pretty much right.

Not sure if it ever checks $MAIL or $MAILPATH.

It doesn't, and it doesn't use $USER, or $LOGNAME, either.

Er... that is what the inc man page says!

       If the environment variable $MAILDROP is set, then inc uses it as the
       location of the user's mail drop instead of the default (the -file name
       switch still overrides this, however).  If this environment variable is
       not set, then inc will consult the profile entry "MailDrop" for this
       information.  If the value found is not absolute, then it is
       interpreted relative to the user's nmh directory.  If the value is not
       found, then inc will look in the standard system location for the
       user's mail drop.
...
FILES
       $HOME/.mh_profile   The user's profile.
       /usr/local/etc/nmh/mts.conf
                           mts configuration file.
       /var/mail/$USER     Location of the system mail drop.

But I don't understand why it didn't just follow unix conventions as most users of MH have been on Unix.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

David Levine-3
Bakul wrote:

> Er... that is what the inc man page says!

>            /var/mail/$USER     Location of the system mail drop.

> But I don't understand why it didn't just follow unix conventions as most users
> of MH have been on Unix.

I think it's fine the way it is now (or maybe I'm missing your point).  The "/var/mail/" that you see in your man page was determined by configure:

    checking where mail spool is located... /var/mail

David

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Fixed! I Could Have Sworn that the inc Command used to work.

Ken Hornstein-2
In reply to this post by martin McCormick-3
> The proper fix was to remove the local-mailbox
>declaration I had unwittingly copied from the system that does
>send internet mail to the ones that don't and on the one that
>does, I now set the $MAILDROP environment variable and, so far,
>all is peace and bliss now.

I had written this long note about how there was NO way that that the
local-mailbox entry would affect that, but I am glad I double checked ...
because I would have been wrong.  It totally does!  From
sbr/mts.c:getuserinfo():

    /* If there's a Local-Mailbox profile component, try to extract
       the username from it.  But don't try very hard, this assumes
       the very simple User Name <[hidden email]> form.
       Note that post(8) uses context_foil(), so it won't see the profile
       component. */

If it finds a username in local-mailbox profile component, then it copies
that over to username and that's returned by getusername() which is
eventually used to construct the default maildrop name.  It looks like
that was changed in commit af586ebe59b7, which was back in ... 2012.
Whoops.  So yeah, your Local-Mailbox profile entry made it look in
a maildrop file named /var/mail/martin.m.  That one is on us!

Obviously this was an unintended consequence of this change; I
understand why it was done, so the mh-format functions would work
correctly with a Local-Mailbox profile component, but I think we'd all
be in agreement that the default maildrop name should be based on the
local Unix username and NOT what the user places in their Local-Mailbox
profile entry.  I think the correct change should be what we did to
LocalName(); add an argument that indicates if you want something that
could come out of a config file or ONLY the Unix username.  Thoughts?

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Fixed! I Could Have Sworn that the inc Command used to work.

David Levine-3
Ken wrote:

> It looks like
> that was changed in commit af586ebe59b7, which was back in ... 2012.
> Whoops.  So yeah, your Local-Mailbox profile entry made it look in
> a maildrop file named /var/mail/martin.m.  That one is on us!

Whoops, on me.

> I think the correct change should be what we did to
> LocalName(); add an argument that indicates if you want something that
> could come out of a config file or ONLY the Unix username.  Thoughts?

+1

David

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ken Hornstein-2
In reply to this post by Bakul Shah
>$HOME/.mh_profile The user's profile.

So, we will use $HOME if it is set.

>/var/mail/$USER Location of the system mail drop.

But we don't actually use $USER (we call getpwuid(getuid()) and use that).

I personally interpreted the use of $USER as "the username goes here",
not "we use the value of the $USER environment variable".  But I admit
that this is not clear.

>But I don't understand why it didn't just follow unix conventions as
>most users of MH have been on Unix.

See my previous email; turns out that it was a bug.

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ralph Corderoy
Hi Ken,

> > /var/mail/$USER Location of the system mail drop.
>
> But we don't actually use $USER (we call getpwuid(getuid()) and use
> that).

And even then it's not that simple.

> I personally interpreted the use of $USER as "the username goes here",
> not "we use the value of the $USER environment variable".  But I admit
> that this is not clear.

I'd interpret it as being able to do `USER=notme inc'.

Should we simplify the code to demand $LOGNAME exists and use that?
POSIX, he say

    LOGNAME
        The system shall initialize this variable at the time of login
        to be the user's login name.  See <pwd.h>.  For a value of
        LOGNAME to be portable across implementations of POSIX.1-2017,
        the value should be composed of characters from the portable
        filename character set.

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Bakul Shah
On Mon, 03 Jun 2019 09:08:16 +0100 Ralph Corderoy <[hidden email]> wrote:

> Hi Ken,
>
> > > /var/mail/$USER Location of the system mail drop.
> >
> > But we don't actually use $USER (we call getpwuid(getuid()) and use
> > that).
>
> And even then it's not that simple.
>
> > I personally interpreted the use of $USER as "the username goes here",
> > not "we use the value of the $USER environment variable".  But I admit
> > that this is not clear.
>
> I'd interpret it as being able to do `USER=notme inc'.
>
> Should we simplify the code to demand $LOGNAME exists and use that?
> POSIX, he say
>
>     LOGNAME
>         The system shall initialize this variable at the time of login
>         to be the user's login name.  See <pwd.h>.  For a value of
>         LOGNAME to be portable across implementations of POSIX.1-2017,
>         the value should be composed of characters from the portable
>         filename character set.

You can use getlogin(3) or getlogin_r(3) as per ISO/IEC 9945-1:1996.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ralph Corderoy
Hi Bakul,

> > Should we simplify the code to demand $LOGNAME exists and use that?
>
> You can use getlogin(3) or getlogin_r(3) as per ISO/IEC 9945-1:1996.

That seems worse.  Linux's getlogin(3) says in Description that $LOGNAME
is often more useful, and its Bugs section is an amusing read.
getlogin(3p) from POSIX is also available for detail.

getlogin() copes with multiple usernames for the same ID and finds the
one used on this controlling terminal, checking FDs 0-2 until ‘success’
and crawling utmp.  That's overkill for our purposes.  $LOGNAME is in
our memory and a function call away, plus it's easy to document and
useful to override.

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ken Hornstein-2
>That seems worse.  Linux's getlogin(3) says in Description that $LOGNAME
>is often more useful, and its Bugs section is an amusing read.
>getlogin(3p) from POSIX is also available for detail.

I'm not so crazy on using getlogin() since this function can be called
by nmh programs that do not have a controlling terminal.

>getlogin() copes with multiple usernames for the same ID and finds the
>one used on this controlling terminal, checking FDs 0-2 until ‘success’
>and crawling utmp.  That's overkill for our purposes.  $LOGNAME is in
>our memory and a function call away, plus it's easy to document and
>useful to override.

It sure does seem like the overarching lesson from this is "think carefully
about any change you make to nmh since unintended consequences abound".

getusername() (the nmh function) is called by programs like slocal and
rcvtty, which may not have a controlling terminal and I am unclear what
LOGNAME would mean in their environment as well.  We could do something
like call isatty(0) before falling back to LOGNAME, but then I'd have to
ask "exactly WHY are we doing that?".

I am thinking that falling back to getpwuid(getuid()) is the most reasonable
approach, for the following reasons:

- My vague impression is that this is what most other programs who want
  this information do.
- It is consistent with MH historical practice and is thus likely to have
  the fewest unintended consequences
- Should generally work across program execution environments
- Even though it might be useful to override the username with an environment
  variable, AFAICT the actual use of the username can be overridden by a
  command line switch in all programs that call getusername().

Thoughts?

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Fixed! I Could Have Sworn that the inc Command used to work.

martin McCormick-3
In reply to this post by Ken Hornstein-2
Ken Hornstein <[hidden email]> writes:

> I had written this long note about how there was NO way that that the
> local-mailbox entry would affect that, but I am glad I double checked ...
> because I would have been wrong.  It totally does!  From
> sbr/mts.c:getuserinfo():
>
>     /* If there's a Local-Mailbox profile component, try to extract
>        the username from it.  But don't try very hard, this assumes
>        the very simple User Name <[hidden email]> form.
>        Note that post(8) uses context_foil(), so it won't see the profile
>        component. */
>
> If it finds a username in local-mailbox profile component, then it copies
> that over to username and that's returned by getusername() which is
> eventually used to construct the default maildrop name.  It looks like
> that was changed in commit af586ebe59b7, which was back in ... 2012.
> Whoops.  So yeah, your Local-Mailbox profile entry made it look in
> a maildrop file named /var/mail/martin.m.  That one is on us!
>
> Obviously this was an unintended consequence of this change; I
> understand why it was done, so the mh-format functions would work
> correctly with a Local-Mailbox profile component, but I think we'd all
> be in agreement that the default maildrop name should be based on the
> local Unix username and NOT what the user places in their Local-Mailbox
> profile entry.  I think the correct change should be what we did to
> LocalName(); add an argument that indicates if you want something that
> could come out of a config file or ONLY the Unix username.  Thoughts?

        Wow!  I am so glad I read all the rest of the messages in
this thread.  It makes me feel less clueless.

        For now, I will consider this problem solved and move on
to creating new ones^H^h^H did I say that?

        Anyway, thanks, everyone.

Martin McCormick   WB5AGZ

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ralph Corderoy
In reply to this post by Ken Hornstein-2
Hi Ken,

> getusername() (the nmh function) is called by programs like slocal and
> rcvtty, which may not have a controlling terminal and I am unclear
> what LOGNAME would mean in their environment as well.

True.  cron(8) here sets $LOGNAME, but does .forward, etc?

> I am thinking that falling back to getpwuid(getuid()) is the most
> reasonable approach

I notice that a setuid inc(1) has various troubles due to the use of
real user ID rather than effective.

So if the code stays as if then the documentation could do with
clarifying.  I'll make a note.

--
Cheers, Ralph.

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Ken Hornstein-2
>> I am thinking that falling back to getpwuid(getuid()) is the most
>> reasonable approach
>
>I notice that a setuid inc(1) has various troubles due to the use of
>real user ID rather than effective.

Like ... what?  I would have though using the real UID would have been the
correct answer.  Also, I didn't even think we supported that; at most
we support setgid to the mail group (and it's a huge pile of code which
I personally would love to get rid of).

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: I Could Have Sworn that the inc Command used to work.

Bakul Shah
In reply to this post by Ken Hornstein-2
On Jun 3, 2019, at 8:06 AM, Ken Hornstein <[hidden email]> wrote:
>
> I am thinking that falling back to getpwuid(getuid()) is the most reasonable
> approach, for the following reasons:

This fails when there are multiple users with the same uid as getpwuid()
will likely fetch the first matching entry. On FreeBSD (& May be other BSDs)
getlogin() is a syscall and works correctly without a controlling terminal.
But I was forgetting about Linux which never disappoints in disappointing.
I think use of $LOGNAME as a fallback may be good enough.

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