gmane.comp.gnu.mailutils.bugs

patch applied to version

d.henman — 2013-06-02T22:06:08

Regarding the segmentation fault.  I forgot to mention to which version of mailutils it was applied.

The patch was applied to:   mailutils-2.99.98

  ---

In the meantime, I'd like to fetch my e-mail from my ISP server.
It seems that my ISP's system does not implement the "CAPA command".
Are all of the mailutils applications dependent on using the "CAPA command"?


Regards

Segmentation Fault in gnu-mh part of mailutils

d.henman — 2013-06-02T16:13:39

Sergy,
   I reported that the patch you made worked.  But apparently it doesn't.  I didn't test it well enough.  The problem was that a ISP still uses old mail handingle and the newer something (see the patch you made below.)

  I thought it was strange that I wasn't getting any mail from my isp (I usually use gmail, but SPAM would come in over my ISP account.   I noticed its absense, and also then noticed   "nc.exe.stackdump"  files being created about

  This does not show yp in MH-E in emacs.  It was just reporting "no mail".  I know that you didn't have time to test the code, etc.  It's 1:10 A.M. and I'm going to bed.  I'll take a lot at it tomorrow.  If you have any ideas while I', sleeping please let me know.

Regards,
  Darel






-------------------------------- patch 
diff --git a/include/mailutils/pop3.h b/include/mailutils/pop3.h
index 5e16b5d..1a8199d 100644
--- a/include/mailutils/pop3.h
+++ b/include/mailutils/pop3.h
< at >< at > -55,7 +55,7 < at >< at > int  mu_pop3_apop (mu_pop3_t pop3, const char *name, const char *digest);
 
 int  mu_pop3_stls (mu_pop3_t pop3);
 
-/* It is the responsability of the caller to call mu_iterator_destroy() when
+/* It is the responsibility of the caller to call mu_iterator_destroy() when
    done with the iterator.  The items returned by the iterator are of type
    "const char *", no processing is done on the item except the removal of
    the trailing newline.  */
< at >< at > -82,7 +82,7 < at >< at > int  mu_pop3_pass (mu_pop3_t pop3, const char *pass);
 
 int  mu_pop3_quit (mu_pop3_t pop3);
 
-/* A stream is returned with the multi-line answer.  It is the responsability
+/* A stream is returned with the multi-line answer.  It is the responsibility
    of the caller to call mu_stream_destroy() to dipose of the stream.  */
 int  mu_pop3_retr (mu_pop3_t pop3, unsigned int mesgno,
    mu_stream_t *pstream);
< at >< at > -91,12 +91,12 < at >< at > int  mu_pop3_rset (mu_pop3_t pop3);
 
 int  mu_pop3_stat (mu_pop3_t pop3, size_t *count, mu_off_t *octets);
 
-/* A stream is returned with the multi-line answer.  It is the responsability
+/* A stream is returned with the multi-line answer.  It is the responsibility
    of the caller to call mu_stream_destroy() to dipose of the stream.  */
 int  mu_pop3_top (mu_pop3_t pop3, unsigned int mesgno,
   unsigned int lines, mu_stream_t *pstream);
 
-/* The uidl is malloc'ed and returned in puidl; it is the responsability of
+/* The uidl is malloc'ed and returned in puidl; it is the responsibility of
    the caller to free() the uild when done.  */
 int  mu_pop3_uidl (mu_pop3_t pop3, unsigned int mesgno, char **puidl);
 
< at >< at > -116,7 +116,11 < at >< at > int mu_pop3_user (mu_pop3_t pop3, const char *user);
    the message could be retrieved, but it is up to the caller to do the
    parsing.  */
 int  mu_pop3_response (mu_pop3_t pop3, size_t *nread);
-
+const char *mu_pop3_strresp (mu_pop3_t pop3);
+int mu_pop3_sget_response (mu_pop3_t pop3, const char **sptr);
+int mu_pop3_aget_response (mu_pop3_t pop3, char **sptr);
+int mu_pop3_get_response (mu_pop3_t pop3, char *buf, size_t len, size_t *plen);
+  
 int  mu_pop3_writeline (mu_pop3_t pop3, const char *format, ...)
                                   MU_PRINTFLIKE(2,3);
 
diff --git a/libmu_auth/ldap.c b/libmu_auth/ldap.c
index c454910..2b7aff2 100644
--- a/libmu_auth/ldap.c
+++ b/libmu_auth/ldap.c
< at >< at > -534,7 +534,7 < at >< at > _mu_ldap_search (LDAP *ld, const char *filter_pat, const char *key,
 
   env[0] = "user";
   env[1] = key;
-  env[3] = NULL;
+  env[2] = NULL;
 
   ws.ws_env = env;
   if (mu_wordsplit (filter_pat, &ws,
diff --git a/libproto/pop/mbox.c b/libproto/pop/mbox.c
index d85c38e..2e7b6a1 100644
--- a/libproto/pop/mbox.c
+++ b/libproto/pop/mbox.c
< at >< at > -179,8 +179,13 < at >< at > pop_open (mu_mailbox_t mbox, int flags)
 break;
 
       status = mu_pop3_capa (mpd->pop3, 1, NULL);
-      if (status)
-break;
+      if (status == MU_ERR_REPLY) {
+  mu_debug (MU_DEBCAT_MAILBOX, MU_DEBUG_ERROR, 
+    ("server rejected the CAPA command: %s",
+     mu_pop3_strresp (mpd->pop3)));
+  /* try to continue anyway */
+      } else if (status)
+return status;
 
 #ifdef WITH_TLS      
       if (!mpd->pops &&
diff --git a/libproto/pop/pop3_response.c b/libproto/pop/pop3_response.c
index 87f9897..9b03a48 100644
--- a/libproto/pop/pop3_response.c
+++ b/libproto/pop/pop3_response.c
< at >< at > -25,8 +25,7 < at >< at >
 #include <mailutils/cctype.h>
 #include <mailutils/cstr.h>
 #include <mailutils/sys/pop3.h>
-
-#define POP3_DEFERR "-ERR POP3 IO ERROR"
+#include <mailutils/util.h>
 
 /* If we did not grap the ack already, call pop3_readline() but handle
    Nonblocking also.  */
< at >< at > -48,21 +47,6 < at >< at > mu_pop3_response (mu_pop3_t pop3, size_t *pnread)
   n = mu_rtrim_class (pop3->ackbuf, MU_CTYPE_SPACE);
   MU_POP3_FSET (pop3, MU_POP3_ACK); /* Flag that we have the ack.  */
 }
-      else
-{
-  /* Provide them with an error.  */
-  if (pop3->acksize < sizeof (POP3_DEFERR))
-    {
-      char *p = realloc (pop3->ackbuf, sizeof (POP3_DEFERR));
-      if (p)
-{
-  pop3->ackbuf = p;
-  pop3->acksize = sizeof (POP3_DEFERR);
-}
-    }
-  if (pop3->ackbuf)
-    strncpy (pop3->ackbuf, POP3_DEFERR, pop3->acksize);
-}
     }
   else if (pop3->ackbuf)
     n = strlen (pop3->ackbuf);
< at >< at > -78,3 +62,57 < at >< at > mu_pop3_response (mu_pop3_t pop3, size_t *pnread)
     *pnread = n;
   return status;
 }
+
+const char *
+mu_pop3_strresp (mu_pop3_t pop3)
+{
+    if (pop3 == NULL)
+      return NULL;
+    if (!MU_POP3_FISSET (pop3, MU_POP3_ACK))
+      return NULL;
+    return pop3->ackbuf;
+}
+
+int
+mu_pop3_sget_response (mu_pop3_t pop3, const char **sptr)
+{
+  if (pop3 == NULL)
+    return EINVAL;
+  if (!MU_POP3_FISSET (pop3, MU_POP3_ACK))
+    return MU_ERR_NOENT;
+  *sptr = pop3->ackbuf;
+  return 0;
+}
+
+int
+mu_pop3_aget_response (mu_pop3_t pop3, char **sptr)
+{
+  char *p;
+  
+  if (pop3 == NULL)
+    return EINVAL;
+  if (!MU_POP3_FISSET (pop3, MU_POP3_ACK))
+    return MU_ERR_NOENT;
+  p = strdup (pop3->ackbuf);
+  if (!p)
+    return ENOMEM;
+  *sptr = p;
+  return 0;
+}
+
+int
+mu_pop3_get_response (mu_pop3_t pop3, char *buf, size_t len, size_t *plen)
+{
+  size_t size;
+  
+  if (pop3 == NULL)
+    return EINVAL;
+  if (!MU_POP3_FISSET (pop3, MU_POP3_ACK))
+    return MU_ERR_NOENT;
+  
+  if (buf)
+    size = mu_cpystr (buf, pop3->ackbuf, len);
+  if (plen)
+    *plen = size;
+  return 0;
+}

Likely bug found in MH C code

d.henman — 2013-04-10T01:59:45

  ..../mh/mh_format.c

I believe there is a logic bug in the mh-format logic.
The function strobj_assign located in the file  ..../mh/mh_format.c 

--- a yanked copy of the function:
strobj_assign (strobj_t *lvalue, strobj_t *rvalue)
{
  strobj_free (lvalue);
  *lvalue = *rvalue;
  rvalue->size = 0;
  rvalue->ptr = NULL;
}
--- end of copy

But, since the lvalue points to the same structure in memory as rvalue, the following two statements also nullify the values in the lvalue and size will always be 0 and ptr = NULL

  rvalue->size = 0;
  rvalue->ptr = NULL;

I applied the following mh-format string to some messages two of which have null subject header fields

%4(msg) : %(comp{subject}) : len=%(strlen) : null=%(null) : str=%(putstr):%20{subject}:

The function 'comp' above should load the string register with the subject's string val.
'strlen' should return that value, but it's always producing a 0.

The result is:
  12 : 1 : len=0 : null=0 : str=:Re: method of autosa:
  13 : 1 : len=0 : null=0 : str=::
  15 : 1 : len=0 : null=0 : str=::
  16 : 1 : len=0 : null=0 : str=:failure notice      :

* strlen should not be zero for all messages only two of them and
* null should not be 0 or false for all of them.
* putstr should be printing the subjects contents and it's not

I believe that this is because strobj_assign is zeroing out and the size and NULLifying the str ptr in strobj_assign. 


Darel

Re: gnu-mh module problem in Mailutils suite

Sergey Poznyakoff — 2013-04-02T18:57:58

Hi Darel,

Returning to this question:


No, it should not.  There are seven possible usage patterns (in the
discussion below "$(Path)" stands for the value of Path variable from
~/.mh_profile):

1. send
(no arguments).  In this case the behavior is:

1.a) If Draft-Folder is set: open that folder and use its "cur" message
as a draft; ask the user if it's ok.

1.b) If Draft-Folder is not set: use $(Path)/draft ad a draft;
ask the user if it's ok.

2. send -draft

Use $(Path)/draft without prompting.

3. send FILE

Use $(Path)/MSG as a draft, without prompting.

4. send -draftmessage FILE

Same as (3).

5. send -draftfolder DIR

Use the "cur" message from folder DIR as a draft.

6. send -draftfolder DIR MSG

Use MSG from folder DIR.

7. send -draftfolder DIR -draftmessage MSG

Same as (6).

As you see, Draft-Folder is used only in scenario (1).

Regards,
Sergey

MH "message does not exist" errors

Sergey Poznyakoff — 2013-04-01T22:35:09

Hello,

The bug in question should be fixed by commit d9ddd27a[1]. For those
who have difficulties building from Git sources, the test tarball
mailutils-2.99.98-20130402.tar.{gz,bz2,xz} is available from the usual
location[2]. Please give it a try.

Please note that I haven't yet disabled the error message in case of
delete operations, as Bill proposed. This means that `mark' can still
issue spurious errors, if there are any sequences left over from the
previous operations (which is pretty likely). To avoid this, remove such
"stale" sequences beforehand.

Regards,
Sergey

[1] http://git.savannah.gnu.org/cgit/mailutils.git/commit/?id=d9ddd27acef16ebbb44a0fc096fe86fedab5399d
[2] http://download.gnu.org.ua/alpha/mailutils

Re: (no subject)

Sergey Poznyakoff — 2013-04-01T13:27:05

For what it's worth, I managed to track down the reason for that
particular message.  I'll be able to provide a solution in a
couple of days.

Regards,
Sergey

(no subject)

Sergey Poznyakoff — 2013-04-01T09:33:47

Hi Darel,

Speaking about operation speed, you wrote in your message to mh-e-users:


Can you please supply more info about that? What exactly is slow:
marking the messages (k) or deleting them afterwards (d)? If the
latter, the patch I've just posted should help. If the former:
how many messages are there in the mailbox being operated upon?
How many messages subject to removal (i.e. having the same subject line
as the selected one) are there? How much time does it take to mark them?

Regards,
Sergey

MH: message removal speedup

Sergey Poznyakoff — 2013-04-01T09:28:32

Hi,

To the attention of those who use MU MH 2.99.98: please try the attached
patch.  It should speed up the message removal operations.

Regards,
Sergey

_______________________________________________
Bug-mailutils mailing list
Bug-mailutils< at >gnu.org
https://lists.gnu.org/mailman/listinfo/bug-mailutils

Re: Problems with new mailutils mh programs

Sergey Poznyakoff — 2013-04-01T04:06:47

d.henman <dhenman< at >gmail.com> ha escrit:


As I have already explained, there is no such built-in list in
Mailutils.  You should explicitly create one to avoid this message,
like that:

  mark +inbox -sequence unseen -zero -add
  

It's used internally by MU.

Regargs,
Sergey

Problems with new mailutils mh programs

d.henman — 2013-04-01T03:30:31

The communications portions of the gnu-mh is working for me, but there is some inter-operability problem between the newer mailutilities gnu-mh and emacs's MH-E.

#1 On MH-E start-up I'm always getting a "scan: bad message list `unseen'" message.

 ~/mh_profile contains:
   
Unseen-Sequence: unseen

$mail/inbox/.mh_sequence  contains:
subject: 24 57 62
cur:  29

#I don't know what the file .mu-prop is for but it contains:
uid-validity: 1364610333
size: 301426

Note: that scan for unseen messages give the following error.

$ scan unseen
scan: bad message list `unseen'

This behavior is also seen on other platforms,  so it it not platform specific.  It seems to be related with sequences.

Please take a look at the behavior.  I have noticed another problem when working with sequences, for example in deleting a sequence with the same subject in emacs MH-E.

The gnu-mh 'burst' program also behaved (or caused MH-E) to behave strangely.
I'm looking into it, so I can report it better.

Thanks

Re: MH Programs

Sergey Poznyakoff — 2013-03-22T10:00:59

d. henman <dhenman< at >gmail.com> ha escrit:


That's highly improbable.  These are two entirely independent protocols
and modules.


Mailer has nothing to do with retrieving mail. A "mailer" is an object
used to send mail (as its name implies), not to receive it. Therefore
this debug level is completely senseless when used with inc. What you
should use instead is this:

   --debug-level=mailbox.prot

It will show you the most detailed information, with the POP session
transcript, including security sensitive data (e.g. password) in
plaintext.  To avoid disclosing them, use:

   --debug-level='mailbox.prot,!trace6'

(notice the quotes, necessary to prevent ! from being interpreted by the
shell). You will find the detailed description of the debug level syntax
and available debug levels here:

  http://mailutils.org/wiki/Debug_level

If you are having difficulties interpreting the produced listing, feel
free to post it either to the list or to me directly (take care not to
disclose your password!). 

Regards,
Sergey

Re: mh programs

Sergey Poznyakoff — 2013-03-22T09:47:37

d. henman <dhenman< at >gmail.com> ha escrit:


FWIW, MU has no knowledge about google at all.  So, "dhenman" is either your
local user name, or it is set explicitly somewhere in MH configuration
files (see below).


There is no such system call. Here is the full set of rules used to
determine the full sender address. The first of them that returns a
non-empty value is used:

1. The "from" parameter in the mailer URL, e.g.

     url: smtp://example.com;noauth;from=me< at >example.net

   See

     http://mailutils.org/wiki/Fetching_Mail_with_Movemail#SMTP_Parameters

   for the full list of smtp parameters.
   
2. The value of the From: header from the message, if any.

3. The username as set in .mtstailor.  The domain part can
   be specified there as well, so that:

   a) $ cat .mtstailor
      username: gray
      
      will produce "gray< at ><hostname>", where <hostname> is the
      name of my computer as returned by gethostname
      
   b) $ cat .mtstailor
      username: gray
      localdomain: org
      
      will produce "gray< at ><hostname>.org", where <hostname> is the
      same as above.

      Finally:
      
   c) $ cat .mtstailor
      username: gray
      localname: gnu
      localdomain: org
    
      will produce "gray< at >gnu.org"
   
4. The username corresponding to the current user ID, as returned
   by getpwuid(getuid()) call.


Sure enough, the server refuses to accept mail from such a sender.  Use
the above rules to supply a correct sender name.

Regards,
Sergey

MH Programs

d. henman — 2013-03-22T05:18:23

The inc program also does not work.  I am thinking that it is the same problem.
The send is more important so mentioned it first, but it might help to
know that inc
is also malfunctioniing.

Here is the result of running it on the command line:

$inc --debug-level=mailer.prot,trace7
inc: cannot open mailbox pop://my-isp-name:***< at >pop.asahi-net.or.jp:
Operation rejected by remote party
$

(I haven't really read about debugging levels, but just thew
mailer.prot.trace7 together and hoped.)

mh programs

d. henman — 2013-03-21T23:47:57

Sergey,
  Thanks for the information.

Re;> > send: mu_mailer_send_message(): using From: dhenman< at >this-machine
But, there is no host user named dhenman.  It is only a gmail user name.
Since you user gethostname, I thought that it would use something like
getusername() to be consistent?

Here is the new information about result of adding the  ';noaut'  in
~/.mtstailor
 $ send --debug-level=mailer.prot drafts/95
send: S: 220 mail2.asahi-net.or.jp ESMTP Postfix
send: C: EHLO this-machine
send: S: 250-mail2.asahi-net.or.jp
....
send: S: 250 DSN
send: mu_mailer_send_message(): using From: dhenman< at >this-machine
send: C: MAIL FROM:<dhenman< at >this-machine> SIZE=195
              --------------------------        Shouldn't the From:
host be < at >gmail.com?

send: S: 250 2.1.0 Ok
send: C: RCPT TO:<dhenman< at >gmail.com>
send: S: 504 5.5.2 <dhenman< at >this-machine>: Sender address rejected:
need fully-qualified

----------------------------------------------------------------
send: C: RSET
send: S: 250 2.0.0 Ok
send: cannot send message: Operation rejected by remote party

--- end

Re: gnu-mh programs

Sergey Poznyakoff — 2013-03-21T16:17:09

d. henman <dhenman< at >gmail.com> ha escrit:


Indeed, --draft does not affect the directory where the message is
searched.  I'll check if it should and fix it if so.


That means that you have compiled MU without GNU SASL. If you don't need
ESMTP AUTH, leave it as is, but add ";noauth" to your SMTP url in
~/.mtstailor, e.g.:

url: smtp://mail.asahi-net.or.jp;noauth


Why should it? The default sender name (unless set explicitly elsewhere)
is composed by concatenating the login name of the user, a "< at >" sign
and the machine name, as returned by gethostname(2).


That's right. It should not have displayed anything.


It has nothing to do with inc. It is configured at the SMTP server (in
your case mail.asahi-net.or.jp). Normally the use of ESMTP AUTH is
optional. That's why I've asked whether you really need it. Since
you did not use it previously (it was not supported by MU 2.x anyway),
then perhaps you don't need it at all. In that case, just disable it as
I described above.

Let me know if it helps.

Regards,
Sergey

gnu-mh programs

d. henman — 2013-03-21T11:04:56

Hi Sergey,
  thanks for getting back to me.  I tried 2.99.98 as you suggested,
but the problem persists. Here's some more information I collected
running mh's send program.  Please look it over.

# Below you can see that using --draft has no effect, even after I
fixed my debug-level
# mistake.

# Want to send a message which is in .../drafts  (Draft-Folder
specified in .mh_profile)
$ send --debug-level=mailer.prot 95
send: stat(/home/djh/mail/95) failed: No such file or directory

$ send --debug-level=mailer.prot --draft 95
send: stat(/home/djh/mail/95) failed: No such file or directory

$ send --debug-level 4 drafts/95
SMTP User:  isp-usr-name
                     --------------------  which is set for inc; inc:
in  /.mh_profile
SMTP Passwd:
send: authentication disabled: Function not implemented
send: cannot send message: Operation rejected by remote party

$ send --debug-level=mailer.prot drafts/95
send: S: 220 mail2.asahi-net.or.jp ESMTP Postfix
             ---------------------  mail2. instead of just mail as in
~/.mh_profile
send: C: EHLO this-machine
send: S: 250-mail2.asahi-net.or.jp
send: S: 250-PIPELINING
send: S: 250-SIZE
send: S: 250-ETRN
send: S: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
send: S: 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
send: S: 250-ENHANCEDSTATUSCODES
send: S: 250-8BITMIME
send: S: 250 DSN
SMTP User: isp-usr-name
           ----------------- given in .mh_profile's  inc: statement
SMTP Passwd:
           ------------------ should this be null?
send: authentication disabled: Function not implemented
send: mu_mailer_send_message(): using From: dhenman< at >this-machine
    --------------------  should be dhenman< at >gmail.com ?
send: C: MAIL FROM:<dhenman< at >this-machine> SIZE=195
send: S: 250 2.1.0 Ok
send: C: RCPT TO:<dhenman< at >gmail.com>
                                -------------------   This is right

send: S: 504 5.5.2 <dhenman< at >this-machine>: Sender address rejected:
need fully-qualified
address-----------------------------------------
send: C: RSET
send: S: 250 2.0.0 Ok
send: cannot send message: Operation rejected by remote party
            ------------------------
Notes:
~/.mtstailor contains:
url: smtp://mail.asahi-net.or.jp
username: dhenman
localname: gmail.com

~/.mh_profile contains:
Draft-Folder: /home/djh/mail/drafts
inc:  --file  pop://<isp-usr-name>:<isp-password>< at >pop.asahi-net.or.jp -truncate

When I ran 'send' on the command line the enter password code did not
display anything
  when I typed in the password.  I was expecting DOTs or * or
something.  Does outgoing mail need usser's name and password or is it
assumed that the inc: statement has it?

Thanks

Re: Release 2.99.94

Sergey Poznyakoff — 2013-03-21T06:19:14

Hi Darel,

Could you please try v. 2.99.98? In more than a year that passed since
the release of 2.99.94 many bugs has been fixed. You can download
mailutils-2.99.98.tar.{gz|xz|bz2} from its usual locations:
{ftp|http}://download.gnu.org.ua/alpha/mailutils or
{ftp|http}://alpha.gnu.org/gnu/mailutils.

Regards,
Sergey

more testing

d. henman — 2013-03-21T06:59:14

The gnu-mh inc and send modules are still not successfully working for me.

I decided to try the 'mail' program to see what it would do.  Here's
the test and results:
----------------------------------------
$ mail --debug-level 4 bozo< at >any.com
Cc:
Subject: test send
Test mail using mu's mail program
Getting auth info for UID 1005
Getting auth info for UID 1005
mu_mailer_send_message(): using From: user< at >hostname
progmailer error: Process exited with a non-zero status
Sending headers...
Sending body...
/usr/sbin/sendmail exited with: 1
cannot send message: Process exited with a non-zero status
-------------------------------------
In the above the sendmail is a wrapper script, which I assume gets
mu's 'sendmail' ran.
Is there anyway to see what sendmail tries or any log for to view
somewhere to help track down the failure.

I know the mh programs use .mh_profile and .mtstailor, but for
the program 'mail' should I make a ~/.mail  or
a ~/.mailutils/.mail  ?

gnu-mh module problem in Mailutils suite

d. henman — 2013-03-20T02:17:22

Here is some more information about gnu-mh module programs in
ver. 2.99.94 not working for me.

Release 2.99.94

d. henman — 2013-03-19T13:47:42

I just upgraded to version 2.99.94 from version 2.1
The source built fine (had to use --without-guile) and I installed it.
 I am looking forward to using it.

But, I tested the gnu-mh module and ran into a problem:

 "inc: cannot open mailbox pop://xxxuser-name:***< at >pop.asahi.or.jp: Success"

I believe that either something changed in the new code or
installing this wrote over some configuration I had been using.

Please send me any advice or ideas on how to get this working.
Thanks

--------------- end of attempt to send you mail, but send error
occurred (see below)


send: authentication disabled: No credentials supplied
send: cannot send message: File too large

Re: -Warray-bounds warning

Sergey Poznyakoff — 2013-02-28T18:42:07

Eray Aslan <eray.aslan< at >caf.com.tr> ha escrit:


Thanks a lot for spotting that. Indeed, it should have been env[2].

Regards,
Sergey

_______________________________________________
Bug-mailutils mailing list
Bug-mailutils< at >gnu.org
https://lists.gnu.org/mailman/listinfo/bug-mailutils