Bug#545258: heirloom-mailx: fails to set the charset to UTF-8 in From

[Steffen Nurpmeso]

Martin-Éric Racine wrote in :
 |su 1. jouluk. 2019 klo 18.44 Paride Legovini (p...@ninthfloor.org) kirjoitti:
 |> On Sun, 06 Sep 2009  wrote:
 |>> Package: heirloom-mailx
 |>> Version: 12.4-1.1+b1
 |>> Severity: normal
 |>>
 |>> When piping text into heirloom-mailx, it fails to specify the charset \
 |>> used with
 |>> the From: line if the name inherited from /etc/passwd is in UTF-8.
 |>>
 |>> cat file | mail -s "some subject" u...@domain.ltd
 |>>
 |>> q-funk:x:1000:1000:Martin-Éric Racine,,,:/home/q-funk:/bin/bash
 |>
 |> Hello Martin-Éric,
 |>
 |> This bug is now >10 years old, so I somewhat hope it got fixed as the
 |> general adoption of UTF-8 increased in the last years. I tried to
 |> reproduce the issue you described with the latest version of s-nail in
 |> unstable (14.9.15-1), but I'm not sure I'm doing it right. The best
 |> thing would be if you could try to reproduce with a more recent version
 |> on s-nail and report back. Do you think you could give it a shot?
 |
 |All my hosts currently run the traditional bsd-mailx.

Hilko Bengen is possibly sometimes a bit difficult to get on.  If
i read the bugs' thread, he referred to sendcharsets= as the
target character set, and this is correct.  What we need to know
to get your (former) problem right is the input / source character
set.

So as long as your locale (man 7 locale) states the correct
character set (for example doing "export LC_ALL=fr_FR.utf8" in the
shell, before starting this MUA, for example), or you set the
ttycharset variable directly (it is normally derived from the
user's locale), this should just work.  (Iff conversion to
sendcharsets= is possible, iff that is necessary.)
This is true for all programs which adhere to locale(7).

(Note this MUA now supports a mime-force-sendout variable which
can be used to enforce sending out data, even if character set
conversion fails.  For unattended usage on systems which may
generate logs in whatever encoding.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Paride!

Paride Legovini wrote in :
 |Steffen Nurpmeso wrote on 28/06/2019:
 |> Paride Legovini wrote in  r.org>:
 |>|Steffen Nurpmeso wrote on 27/06/2019:
 |>|> Paride Legovini wrote in |> o\
 |>|> r.org>:
 |>|>|Steffen Nurpmeso wrote on 20/06/2019:
 ...
 |>|>|this bug? I would like to have it fixed in buster, but given that we're
 |>|>|so deep in the freeze I'll have to ship only a minimal fix for this
 |>|>|specific bug; an import of a new minor version changing other stuff
 |>|>|won't be accepted. This will mean patching 14.9.11.
 |>|> 
 |>|> Oh-oh, 14.9.11 is a year old! :)  I do not understand that
 |>|> security policy of Debian, for such a small program with a single
 |>|> developer.  So many bugs fixed!  I would even update to [master]
 |>|> or [stable/stable] and use the grappa mode!  Sigh. :)
 |>|
 |>|Yeah I'm sorry for the skipped release, I promise I will backport the
 |>|latest one once buster is released, but for the moment v14.9.11 is the
 |>|version we have to work with.
 |>|
 |>|The policy for acceptable changes during the full freeze period is
 |>|pretty clear:
 |>|
 |>|https://release.debian.org/buster/freeze_policy.html
 |>|
 |>|and I don't think an update to e.g. 14.9.14 will fit.
 |> 
 |> That definetely not, i had to rewrite the entire child process and
 |> job control signal handling to something that i almost like.  And
 |> the rest of the way we will make, too!
 |> 
 |> I was thinking more of the [stable/stable] branch, which is
 |> v14.9.13 plus fixes, and which can be turned into a release with
 |> the grappa mode of mk/make-release.sh (as documented in README).
 |
 |This would totally make sense in my opinion, the problem is we don't
 |have v14.9.13 in Debian, but v14.9.11, and we need two "UPDATE" version
 |bumps (in the MAJOR.MINOR.UPDATE semantic) to get to 14.9.13, on which
 |we can apply the bug fixes in the stable/stable branch. And UPDATE
 |releases are not bugfix-only releases, so not really suitable for
 |inclusion while Debian is in deep freeze.

I see, i had forgotten that 14.9.13 came to late for the Debian
freeze, and it really is v14.9.11.  Yeah, it really is v14.9.11.
Well...

 |I can of course backport the latest stable version of s-nail once Buster
 |is released, and I will, but that's not the same of course.
 |
 |Please let me know if I misunderstood something, and thanks a lot for
 |your feedback.

Nah, it is ok.  But in general i have doubts regarding this Debian
policy, so many bugs have been fixed .. that possibly the few that
came anew count less.  In my opinion.  Of course, if i had more
time i could cherry-pick more bugfixes to even elder releases, but
i think that will not happen.  So, pfff, busted.

Ciao, Paride.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Paride Legovini wrote in :
 |Steffen Nurpmeso wrote on 27/06/2019:
 |> Paride Legovini wrote in  r.org>:
 |>|Steffen Nurpmeso wrote on 20/06/2019:
 |>|> the patch was reversed; here is the right one.
 |>|
 |>|Just to be sure, is your last "ivan.diff" patch all that's needed to fix
 |>|this bug? I would like to have it fixed in buster, but given that we're
 |>|so deep in the freeze I'll have to ship only a minimal fix for this
 |>|specific bug; an import of a new minor version changing other stuff
 |>|won't be accepted. This will mean patching 14.9.11.
 |> 
 |> Oh-oh, 14.9.11 is a year old! :)  I do not understand that
 |> security policy of Debian, for such a small program with a single
 |> developer.  So many bugs fixed!  I would even update to [master]
 |> or [stable/stable] and use the grappa mode!  Sigh. :)
 |
 |Yeah I'm sorry for the skipped release, I promise I will backport the
 |latest one once buster is released, but for the moment v14.9.11 is the
 |version we have to work with.
 |
 |The policy for acceptable changes during the full freeze period is
 |pretty clear:
 |
 |https://release.debian.org/buster/freeze_policy.html
 |
 |and I don't think an update to e.g. 14.9.14 will fit.

That definetely not, i had to rewrite the entire child process and
job control signal handling to something that i almost like.  And
the rest of the way we will make, too!

I was thinking more of the [stable/stable] branch, which is
v14.9.13 plus fixes, and which can be turned into a release with
the grappa mode of mk/make-release.sh (as documented in README).
The [stable/] branch series is exactly for this purpose.  On the
oss-security@ list there was a discussion on using exact the kind
of stable branches that S-nail provides, and Simon McVittie of
Debian said something[1,2].  Especially in the former he says

  If upstream projects have a stable branch that is genuinely stable
  and bugfix-only to minimize the risk of regressions, and encourage
  downstream distributions to align on the latest stable branch during
  their development phase, then I think that goes a long way towards this.

  [1] https://www.openwall.com/lists/oss-security/2019/06/21/3
  [2] https://www.openwall.com/lists/oss-security/2019/06/21/8

So this little MUA already provides for some time what has been
expressed as the desirable policy on OSS development.  To speak
that boldly, that is ^_^
(Hmmm, should i Cc: some parties..  Maybe only our own list, ok?)

As another point the software world progresses.  For example, the
new GAWK 5 produces warnings with v14.9.11, it will not with
[stable/stable] (or master).  There is at least one packager known
who fixed those warnings via a local patch in the package system.
Though he (Jürgen) packages for a compile-yourself distribution,
therefore [stable/stable]+mk/make-release.sh grappa is bad, since
you need (git and) perl installed.  Though: perl is in core!  Hm.
That is not a problem so big for Debian, however, i would guess
most people use the binary packages, anyway.

 |>|The patch doesn't apply cleanly onobs-imap-gssapi.h from v14.9.11 (I did
 |>|fix the paths, of course), but making the same changes manually to
 |>|produce a new patch looks easy. Is it fine if I go this way, or should
 |>|v14.9.11 be patches differently? Of course if you happen to have a patch
 |>|that already applies on v14.9.11 please let me have it!
 |> 
 |> I had to backport it myself; i have not compiled it, but should
 |> do.  Please report any problems Paride, they are real and actual
 |> bugs!  I will spin a VM this evening, i have a FreeBSD with
 |> GSSAPI, if i hit any compile error i will send you an update, ok?
 |
 |Thanks Steffen! I will try to apply the patch tomorrow.

Still had no time, will compile-test on FreeBSD in an hour :).
Yeah, time is a problem.
But i did not answer your question: no, not that alone, but two;
the one i sent to you however includes them both.

Ciao Paride!  Ciao!!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Ivan,

sorry for the late reply, i am just about to come back..

Ivan Vučica wrote in :
 |thanks for the reply and for your work. We can take the discussion off
 |of the list, if you want to continue, but you'll see that I'm not
 |advocating too strongly for anything in particular. I think libsasl2
 |might simplify some things for you (and add features), I think OAuth1
 |and OAuth2 are not terrible ideas, and that's about it. :-)
 |
 |I'm still including 930691 bug address to bring this to a closure;
 |feel free to reply to me directly if you wish.

Yeah, it surely has turned over to a SASL feature request by now.
But that is ok by me ^_^

 |On Thu, Jun 20, 2019 at 5:28 PM Steffen Nurpmeso  \
 |wrote:
 |>|>|No, this is actually success. I kdestroyed the ticket cache
 |>|>|beforehand, and kinited.
 |>|>
 |>|> And isn't that cooler than OAUTH?  And no advertising, neither
 |>|> yesterday nor today and very likely also tomorrow not.
 |>|
 |>|It all comes down to scalability and scoping of non-password
 |>|authentication on larger systems. OAuth2 is simpler than Kerberos, and
 |>|doesn't (as generally implemented) depend on a secret being provided
 |>|to obtain a TGT.
 |>
 |>|But it's not why I brought it up earlier; XOAUTH2 (and other mechanism
 |>|names used to represent this authentication method using a bearer
 |>|token obtained through out-of-channel means, which can be a browser,
 |>
 |> I really dislike being a "lesser secure app".
 |
 |I did not say anything about s-nail being less secure, and I did not
 |mean to imply Kerberos is less-secure. In fact, its

No, but that is the Google naming of programs which do not go the
*OAUTH* way.  And already so before *OAUTH* became a standard for
any protocol but HTTP.  After the people which started the
standardization process split up because of the doubtful target.
If i understood correctly.

 |frequently-expiring credentials are really neat for certain
 |environments where you need to ensure that any stolen credentials are
 |not valid for too long, and where you need to ensure someone obtains
 |the credentials repeatedly.
 |
 |Of course, those credentials don't have to be handled the way Kerberos
 |does it, but I don't particularly see a huge problem there.
 |
 |In fact, looking at what I wrote, let me clarify what I mean by
 |'provide a secret'. You do provide /some/ secret with OAuth2. But by
 |being (usually) web based, the credential provisioning process can be
 |accompanied by whatever flow you want. Username, password + OTP?
 |Username + security key tap, no password? Client cert? Client cert on
 |a smartcard? Sure. It's usually just a piece of web UI. (It could be
 |anything else; you just need to deliver the access/refresh token to
 |the requesting entity.)
 |
 |Can you do that with Kerberos? I suppose you could swap kinit for a
 |secondary process and obtain the TGT that way.
 |
 |I suppose Kerberos service-level scoping is comparable to
 |slightly-more-finegrained scopes in OAuth1/OAuth2. Then again, how do
 |you identify and reduce the audience that can use the token? I don't
 |think anything prevents any software on my machine from using the TGT
 |to obtain a service-specific ticket?

Well.  Whatever is started under your account can, can it.

 |> My passwords are
 |> stored on an encrypted volume (if i would be truly professional
 |> i would have some encrypted key stick instead), which is normally
 |> not even mounted.  They actually exist in a file in netrc syntax
 |> which is encrypted via PGP, and only decrypted on-the-fly.  Why is
 |> this less trustable than some storage system at Google?
 |
 |You still want what you described to store your OAuth2 tokens on
 |client side. Server side (whether it's Google or anyone else that uses
 |OAuth2 or similar scoped, token-based approaches) security has nothing
 |to do with what I'm bringing up; what matters is that the blast radius
 |of token being compromised from a single client (let's say
 |"BlehChatBot" accessing my instant messaging account) through some
 |remote access vulnerability can potentially only mean I need to revoke
 |credentials for that one client.
 |
 |If I share a machine with 10 other people, and I wish to access my
 |chat account for just a tiny bit of time, I can either just use the
 |short-lived access token (and never expose the refresh token), or if I
 |use the refresh token, I can depend on the token being scoped to chat
 |(not allowing access to email), or I can revoke both the short-lived
 |access token and the long-lived refresh token.

I don't know much of *OAUTH*.  I have read about and through it
before it got standardized for non-HTML only.

 |With Kerberos, the only thing I can do is destroy the TGT locally,
 |with kdestroy. I do not believe revocation is possible with Kerberos.
 |Can I even obtain a service token remotely? To my understanding
 |(correct

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Paride.

Paride Legovini wrote in :
 |Steffen Nurpmeso wrote on 20/06/2019:
 |> the patch was reversed; here is the right one.
 |
 |Just to be sure, is your last "ivan.diff" patch all that's needed to fix
 |this bug? I would like to have it fixed in buster, but given that we're
 |so deep in the freeze I'll have to ship only a minimal fix for this
 |specific bug; an import of a new minor version changing other stuff
 |won't be accepted. This will mean patching 14.9.11.

Oh-oh, 14.9.11 is a year old! :)  I do not understand that
security policy of Debian, for such a small program with a single
developer.  So many bugs fixed!  I would even update to [master]
or [stable/stable] and use the grappa mode!  Sigh. :)

 |The patch doesn't apply cleanly onobs-imap-gssapi.h from v14.9.11 (I did
 |fix the paths, of course), but making the same changes manually to
 |produce a new patch looks easy. Is it fine if I go this way, or should
 |v14.9.11 be patches differently? Of course if you happen to have a patch
 |that already applies on v14.9.11 please let me have it!

I had to backport it myself; i have not compiled it, but should
do.  Please report any problems Paride, they are real and actual
bugs!  I will spin a VM this evening, i have a FreeBSD with
GSSAPI, if i hit any compile error i will send you an update, ok?

With the patch as attached i say, ciao Paride,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
diff --git a/obs-imap-gssapi.h b/obs-imap-gssapi.h
index 5d314917..70eeca7f 100644
--- a/obs-imap-gssapi.h
+++ b/obs-imap-gssapi.h
@@ -162,10 +162,7 @@ _imap_gssapi(struct mailbox *mp, struct ccred *ccred)
ok = STOP;
f = a_F_NONE;
 
-   {  size_t i = strlen(mp->mb_imap_account) +1;
-  server = n_autorec_alloc(i);
-  memcpy(server, mp->mb_imap_account, i);
-   }
+   server = savestr(mp->mb_imap_account);
if (!strncmp(server, "imap://", 7))
   server += 7;
else if (!strncmp(server, "imaps://", 8))
@@ -174,9 +171,11 @@ _imap_gssapi(struct mailbox *mp, struct ccred *ccred)
   server = [1];
for (cp = server; *cp; cp++)
   *cp = lowerconv(*cp);
+
send_tok.value = n_autorec_alloc(
- (send_tok.length = strlen(server) -1 + 5) +1);
-   snprintf(send_tok.value, send_tok.length, "imap@%s", server);
+ (send_tok.length = strlen(server) + 5) +1);
+   memcpy(send_tok.value, "imap@", 5);
+   memcpy(&((char*)send_tok.value)[5], server, send_tok.length - 4);
maj_stat = gss_import_name(_stat, _tok, GSS_C_NT_HOSTBASED_SERVICE,
  _name);
f |= a_F_TARGET_NAME;
@@ -300,14 +299,13 @@ jebase64:
/* First octet: bit-mask with protection mechanisms (1 = no protection
 *mechanism).
 * Second to fourth octet: maximum message size in network byte order.
-* Fifth and following octets: user name string.
-*/
-   o[0] = 1;
-   o[1] = 0;
-   o[2] = o[3] = (char)0377;
-   snprintf([4], sizeof o - 4, "%s", ccred->cc_user.s);
-   send_tok.value = o;
-   send_tok.length = strlen([4]) -1 + 4;
+* Fifth and following octets: user name string */
+   in.s = n_autorec_alloc((send_tok.length = 4 + ccred->cc_user.l) +1);
+   memcpy([4], ccred->cc_user.s, ccred->cc_user.l +1);
+   in.s[0] = 1;
+   in.s[1] = 0;
+   in.s[2] = in.s[3] = (char)0xFF;
+   send_tok.value = in.s;
maj_stat = gss_wrap(_stat, gss_context, 0, GSS_C_QOP_DEFAULT, _tok,
  _state, _tok);
f |= a_F_RECV_TOK;

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Ivan!

That is good news!!

Ivan Vučica wrote in :
 |On Thu, Jun 20, 2019 at 12:55 AM Steffen Nurpmeso  \
 |wrote:
 |> Steffen Nurpmeso wrote in <20190619234414.zvcpd%stef...@sdaoden.eu>:
 |>   ...
 |>|Dear Ivan.  If you are willing to test once again, at [1] there is
 |>|a complete ball, but you could also simply apply the attached
 |>|patch instead, which is very much smaller.
 |>|
 |>|I am sorry for the inconvenience, and i hope this fixes GSSAPI.
 |>  ...
 |>
 |> the patch was reversed; here is the right one.
 |
 |You did not quote "the right one", but the master branch seems to use
 |6b070335 from the previous email, so I used that.
 |
 |If you mean the attachment, AFAICT it matches 6b070335 so that was
 |already included. :-)

Aeh, ok. :--)

 |>|No, this is actually success. I kdestroyed the ticket cache
 |>|beforehand, and kinited.
 |>
 |> And isn't that cooler than OAUTH?  And no advertising, neither
 |> yesterday nor today and very likely also tomorrow not.
 |
 |It all comes down to scalability and scoping of non-password
 |authentication on larger systems. OAuth2 is simpler than Kerberos, and
 |doesn't (as generally implemented) depend on a secret being provided
 |to obtain a TGT.

 |But it's not why I brought it up earlier; XOAUTH2 (and other mechanism
 |names used to represent this authentication method using a bearer
 |token obtained through out-of-channel means, which can be a browser,

I really dislike being a "lesser secure app".  My passwords are
stored on an encrypted volume (if i would be truly professional
i would have some encrypted key stick instead), which is normally
not even mounted.  They actually exist in a file in netrc syntax
which is encrypted via PGP, and only decrypted on-the-fly.  Why is
this less trustable than some storage system at Google?  It
crosses the wire, maybe.  But that uses the same encryption method
that i would have to use when creating the OAuth originally.  That
is once, maybe.  So then why not being able to use an account
master and a secondary per-service key regulary?

My thought is just that with Kerberos i can have a local ticket
that is initialized once, via a local password.  Any further
communication is then based upon this temporary ticket.  They may
call it bearer token instead.

But my real critic lies about twenty years in the past, once
Germany got a new passport.  I have never understood why they did
not ship a PGP and a SSL key/certificate with a usage notice, also
for the most common applications alongside that.  And a rather
cheap chip reader which could optionally have been bought
bundled.  They should have placed a chip directly on it maybe
even.  I mean, what am i without my passport, on a border, in
a foreign country, in a police control?  The FreeBSD developers
recommended RSA 4096 already by then, which should still be worth
a decade or even longer, as i understand things.

I dedicated all my being to my people/country naturally, just by
being born like that, and if i can be selective upon that, i'd
rather not give mobile phone identity or whatever to large
companies if possible.  That much is plain.  I am pretty much
anti-capitalistic in that sense.  But it is not that i really
care, all that can't be helped and has been addressed in
literature and films for more than half a century.  The pain comes
when it hits you personally, and i do not see why i am treated as
a lesser secure app.

 |but don't have to be) is just one of many SASL mechanisms you'd get
 |for free.

Yes, SASL is on the TODO list for a long time, at least as an
option.  I really hope for end of 2020 for v15.  This could then
be some kind of (optional) filter on a socket level maybe, if
i recall correctly, usable by all protocols we understand by then,
and any others later on.
I mean it could of course be (rather) hacked in already today, it
would likely not take a week, maybe even not more than two or
three days, i have forgotten (i added the TODO five years and
a month ago ;-)

 |> I should have warned you that the password and credentials will be
 |> included in the debug output.
 |
 |No, it's to be expected if it's obvious that there's raw IMAP protocol
 |being logged. That's why I took care and removed what looked like
 |credentials. (Thankfully, I'm familiar enough with IMAP anyway.)

Good.  We also say "user .. pass", but i did it so that one can
debug whether it is the right one, say.  You can always create
a temporary tty/terminal and/or slock when you are away.
Whatever.

 |> /6b070335d77251308e1910f9efb2e08754a1f176
 |
 |Thank you, this has fixed it.

That is really good news!  I happily skip setting up a GSSAPI test
bed next week then, it is midsummer!!  Thank you, Ivan.

 |I was seeing this, though:
 |
 |```
 |s-nail:  s-nail version v14.9.13.  Type `?' for help
 |+[imap://ivuc...@myhostname.ds.mydomain.net/]INBOX: 3 messages
 |▸O  1 xx2019-01-

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Ach, sigh,

Steffen Nurpmeso wrote in <20190619234414.zvcpd%stef...@sdaoden.eu>:
  ...
 |Dear Ivan.  If you are willing to test once again, at [1] there is
 |a complete ball, but you could also simply apply the attached
 |patch instead, which is very much smaller.
 |
 |I am sorry for the inconvenience, and i hope this fixes GSSAPI.
 ...

the patch was reversed; here is the right one.

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
diff --git a/src/mx/obs-imap-gssapi.h b/src/mx/obs-imap-gssapi.h
index 18d0844a..4a961b2b 100644
--- a/src/mx/obs-imap-gssapi.h
+++ b/src/mx/obs-imap-gssapi.h
@@ -299,14 +299,13 @@ jebase64:
/* First octet: bit-mask with protection mechanisms (1 = no protection
 *mechanism).
 * Second to fourth octet: maximum message size in network byte order.
-* Fifth and following octets: user name string.
-*/
+* Fifth and following octets: user name string */
+   su_mem_copy([4], ccred->cc_user.s, ccred->cc_user.l +1);
o[0] = 1;
o[1] = 0;
-   o[2] = o[3] = (char)0377;
-   snprintf([4], sizeof o - 4, "%s", ccred->cc_user.s);
+   o[2] = o[3] = S(char,0xFF);
+   send_tok.length = 4 + ccred->cc_user.l;
send_tok.value = o;
-   send_tok.length = su_cs_len([4]) -1 + 4;
maj_stat = gss_wrap(_stat, gss_context, 0, GSS_C_QOP_DEFAULT, _tok,
  _state, _tok);
f |= a_F_RECV_TOK;

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello and good evening, Ivan.

Ivan Vučica wrote in :
 |On Wed, Jun 19, 2019 at 2:56 PM Steffen Nurpmeso  \
 |wrote:
 |>> What would be further useful debugging or tracing information to
 |>> share?
 |>
 |> In general our -d or -vv switches would be nice. ^_^
 |
 |Here's with -d:
 ...
 |>>> T2 AUTHENTICATE GSSAPI
 |>>> SERVER: +
 |>>> YIIFhgOMITTING-WHAT-LOOKS-LIKE-CREDENTIALS3tM=
 |>>> SERVER: + YIGVBOMITTING-WHAT-LOOKS-LIKE-CREDENTIALSZIXw=
 |[6655] 1560952720.212835: Read AP-REP, time 1560952720.212831, subkey
 |aes256-cts/B91D, seqnum 73895367
 |>>>
 |>>> SERVER: + BQOMITTINGu58=
 |>>> BQCREDENTIALS8E=
 |>>> SERVER: T2 NO [AUTHENTICATIONFAILED] Authentication failed.
 |IMAP error: [AUTHENTICATIONFAILED] Authentication failed.
 |
 |It is really hard to follow the debug info given, and the amount of
 |info changed between the old and new s-nail. But eyeballing the
 |credentials sent in both versions, there is nothing obviously damaged
 |in authentication lines.

I should have warned you that the password and credentials will be
included in the debug output.
You could of course do "set verbose" twice when in interactive
mode, then the entire load phase would not be logged.
Doing logging right is hard; maybe, some day, it will be possible
to have some log filter, which can select by source, or so.
In days where you can inspect/adjust running kernels via DTrace
and BPF, almost anything is very primitive in comparison.

Hm.  I am sorry, but i think there was another false length
calculation.

Yes, the thing is that i had "implemented" SMTP GSSAPI, and that
uses string buffers etc. and not (sn)printf(3) on a stack buffer
to do simple string concatenations, and when i "fixed" the GSSAPI
token length calculation in commit [384c8e2e] (before we included
the C string terminator NUL, which is not valid according to
GSSAPI standard, yet it worked for almost two decades), i did that
by having the IMAP and the SMTP GSSAPI headers side-by-side.  I am
afraid that i got pi.s.d when seeing the snprintf()s and the
string length calls (even if the length is known) in the IMAP one.
Also, you know, IMAP code had been removed from the codebase for
over a year, it was reinstantiated on user request only.  (Again
signal jumps and blocking I/O, and IMAP being the largest piece of
code going that route.  And that is not the way i want this
software to go, as it means the entire codebase is stuck at
a single place, it is entirely sequential, whereas i want the
possibility to have multiple boxes open at the same time, for
example.  Which does not work, currently.  For example.)

Dear Ivan.  If you are willing to test once again, at [1] there is
a complete ball, but you could also simply apply the attached
patch instead, which is very much smaller.

I am sorry for the inconvenience, and i hope this fixes GSSAPI.
It would be great if you could report success! (I will not be able
to setup a GSSAPI box before the 22nd, when my internet limit is
refreshed.  (I have exceeded my limit and the ISDN that i should
get nonetheless seems to be implemented virtually via some kind of
scheduler, and that is a killer.))

  [1] 
https://git.sdaoden.eu/cgit/s-nail.git/snapshot/s-nail-6b070335d77251308e1910f9efb2e08754a1f176.tar.xz

 |I could be wrong, of course.

No, i think there was another mutilated length involved.

 |>   ...
 |>|ivucica@myhostname:~$ klist
 |>|Credentials cache: FILE:/tmp/krb5cc_501
 |>|Principal: ivuc...@ds.mydomainname.net
 |>|
 |>|  IssuedExpires   Principal
 |>|Jun 19 11:25:37 2019  Jun 19 21:25:37 2019  krbtgt/DS.MYDOMAINNAME.NET@D\
 |>|S.MYDOMAINNAME.NET \
 |>  ...
 |>  fail
 |>  ...
 |
 |No, this is actually success. I kdestroyed the ticket cache
 |beforehand, and kinited.

And isn't that cooler than OAUTH?  And no advertising, neither
yesterday nor today and very likely also tomorrow not.

 |This is the 'krbtgt' - 'kerberos ticket-granting-ticket' which is used
 |to get service-specific tickets.
 |
 |I pasted this to demonstrate that GSSAPI is invoked correctly to
 |obtain the service-specific ticket when launching the newly-built
 |s-nail. That is: GSSAPI manages to get
 |imap/myhostname.ds.mydomain@ds.mydomainname.net ticket, usable to
 |authenticate against Dovecot.

Thank you.  Yes, a pity.  All my fault.

 |>|ivucica@myhostname:~$ klist
 |>|Credentials cache: FILE:/tmp/krb5cc_501
 |>|Principal: ivuc...@ds.mydomainname.net
 |>|
 |>|  IssuedExpires   Principal
 |>|Jun 19 11:25:37 2019  Jun 19 21:25:37 2019  krbtgt/DS.MYDOMAINNAME.NET@D\
 |>|S.MYDOMAINNAME.NET \
 |>|
 |>|Jun 19 11:25:42 2019  Jun 19 21:25:37 2019  imap/myhostname.ds.mydomainn\
 |>|ame@ds.mydoma

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Paride!

Paride Legovini wrote in :
 |Ivan Vucica wrote on 19/06/2019:
 |> Hi Steffen,
 |> 
 |> Thanks for the quick fix!
 |> 
 |> The ticket is now correctly obtained, but the GSSAPI authentication \
 |> still fails.
 |
 |Thanks Ivan for the report and Steffen for looking into it. Once you can
 |confirm the fix is working I'll do my best to have it released in Buster.

I can very well do a complete bugfix release, then you do not need
to do messy patchwork.  We have an important fix for OpenBSD and SunOS
5.9 waiting anyway, as well as direct support for Debian awk and
a GNU awk 5 fix, and some more, so i am defineteley willing to do
that -- i only need some time for normal testing here and there,
then.  Ok?

Ciao, ciao Paride!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Ivan.

Ivan Vucica wrote in <20190619110145.gb3...@badc0de.net>:
 |Thanks for the quick fix!

Thanks for going all the way in return!

 |The ticket is now correctly obtained, but the GSSAPI authentication \
 |still fails.
 |
 |I'd offer a debugging system, but unfortunately I have none available \
 |that I
 |can offer. What would be further useful debugging or tracing information to
 |share?

In general our -d or -vv switches would be nice. ^_^

 |Would you like me to continue interactions here in this Debian bug, \
 |or should we
 |do it elsewhere? I can dedicate some time during an evening via XMPP \
 |or via IRC
 |(I hang out on Freenode), if that would be useful.
 |
 |Here's the current behavior. Note how old s-nail manages to use the ticket.
  ...
 |ivucica@myhostname:~$ klist
 |Credentials cache: FILE:/tmp/krb5cc_501
 |Principal: ivuc...@ds.mydomainname.net
 |
 |  IssuedExpires   Principal
 |Jun 19 11:25:37 2019  Jun 19 21:25:37 2019  krbtgt/DS.MYDOMAINNAME.NET@D\
 |S.MYDOMAINNAME.NET \
 ...
 fail
 ...
 |ivucica@myhostname:~$ klist
 |Credentials cache: FILE:/tmp/krb5cc_501
 |Principal: ivuc...@ds.mydomainname.net
 |
 |  IssuedExpires   Principal
 |Jun 19 11:25:37 2019  Jun 19 21:25:37 2019  krbtgt/DS.MYDOMAINNAME.NET@D\
 |S.MYDOMAINNAME.NET \
 |  
 |Jun 19 11:25:42 2019  Jun 19 21:25:37 2019  imap/myhostname.ds.mydomainn\
 |ame@ds.mydomainname.net\
 ...
 ok
 ...

But say, the succeeding klist shows one more issued principal?
I must admit that for the last four years i have done GSSAPI
changes only according to the "GSS-API Programming Guide" from Sun
Microsystems, rather than via live testing. (._.)
Oh, and i don't think i will find any time to setup a postfix /
dovecot / GSSAPI environment this week.

*Really not ok*???

 |[Sidenote: did you consider using cyrus libsasl2? Since I have a XOAUTH2 \
 |SASL
 |method plugin for libsasl2, that would immediately allow s-nail to \
 |also securely
 |authenticate against Gmail. I have mutt dynamically acquiring the 'passw\
 |ord' --
 |i.e. access token -- through an external binary, but then libsasl2 and the
 |plugin do the auth itself. I'm mentioning this because it would leave fewer
 |chances for bugs like this, as long as there are no assumptions about \
 |password
 |length, like Mutt unfortunately had in the past.]

Do not laugh, but i somehow had the feeling we will touch OAUTH!
Well, in theory i have nothing against SASL, and whatever comes
with it.  But i will not implement it myself in the code as it
currently is, because it is performing longjmp()s and uses
blocking socket I/O.  I will hopefully find the time to rewrite
all that, these v15 changes will bring non-blocking I/O, and on
top of that SASL would be doable.  (Or maybe i will be lazy and
base all network I/O on cURL, which "can" everything.)

Dear Ivan, i would love to know whether it is still not
working.  But if you say it is, then i will do a bugfix release as
soon as possible!

Ciao from Germany,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello dear Ivan Vučica!

Ivan Vučica wrote in :
 |As an update, I've tried 14.9.13-1 from experimental as well, and the
 |bug is present there too.

Very first: thank you very much for reporting this issue!

I am the upstream maintainer, and unfortunately i have been the
one who introduced this length calculation bug over a year ago.
I have pushed a fix to the master branch and all the stable
branches.  If you have a development box then

  $ cd /tmp
  $ curl -O 
https://git.sdaoden.eu/cgit/s-nail.git/snapshot/s-nail-5c4e270d07c05dadfe102a1fa68b7ad006dcfcbf.tar.xz
  $ tar -xf s-nail-5c4e270d07c05dadfe102a1fa68b7ad006dcfcbf.tar.xz
  $ cd s-nail-5c4e270d07c05dadfe102a1fa68b7ad006dcfcbf
  $ make citron # (or "make config build install")

Should get you a working copy, i hope.  The patch itself is pretty
small and should apply to v14.9.13, too; maybe Paride (the Debian
maintainer) is willing to create an updated package (Paride could
have some grappa if he wants to, too).

(I hope with the patch GSSAPI is working fine again, i had a very
restricted environment from the end of 2015 to April 2019, and
still have not found time to create a complete test bed with a lot
of VMs, let alone ones with properly configured GSSAPI.)

Ciao from Germany!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#858080: s-nail does not Provide: mail-reader, mailx

[Steffen Nurpmeso]

Hello Paride and Ben.

Paride Legovini <p...@ninthfloor.org> wrote:
 |On 2018-02-17 19:56, Ben Wong wrote:
 |> On Sat, Feb 17, 2018 at 9:52 AM, Paride Legovini <p...@ninthfloor.org
 |> <mailto:p...@ninthfloor.org>> wrote:
 |> On 2018-02-17 18:30, Ben Wong wrote:
 |>> On Sat, 18 Mar 2017 23:43:45 +0100 Steffen Nurpmeso
 |> <stef...@sdaoden.eu <mailto:stef...@sdaoden.eu>
 |>> <mailto:stef...@sdaoden.eu <mailto:stef...@sdaoden.eu>>> wrote:
 |>>>
 |>>> So here i as the maintainer of the subject jump in and remark that
 |>>> the problem of the bug report you pointed to was a non-standard
 |>>> option of the Debian bsd-mail, our command line is a superset of
 |>>> POSIX mailx.  (Unfortunately v14.9.0 has still not landed, so that
 |>>> we offer no possibility to define custom headers; and it will not
 |>>> be the Debian -a i think it was, which, also if i recall
 |>>> correctly, has been patched into BSD-mail after Heirloom added -a
 |>>> for adding attachments, which i think of as a logical and good
 |>>> decision.)
 |>>
 |>> I see that Buster has s-nail v14.9, which has custom headers. Does
 |> that
 |>> mean we can hope for it to provide /usr/bin/mail?
 |> 
 |> Hello from the new maintainer of the s-nail Debian package.
 |> 
 |> It seems to me that, even if now s-nail supports custom headers, the
 |> incompatibility isn't solved: in bsd-mail the '-a' flag is used to add
 |> custom headers, while in s-nail '-a' is for attaching files.
 |> 
 |> While I'd really like s-nail to provide /usr/bin/main, I don't see an
 |> easy way to solve this issue.
 ...
 |> Any idea what Steffen was thinking of doing?
 |
 |I think he was just saying that 14.9.0 does support custom headers, but
 |still not using the Debian's '-a' flag. So 14.9.0 wasn't really bringing
 |a solution.

I am just jumping in to say that it was very uncomfortable to use
custom headers like that from the command line, and that v14.9.7
finally offered a usable command line interface via -C -- it works
the same, i think, as bsd-mailx -a.

I cannot change -a, even if i would like to (i do not, i think -a
for attachment is good), it is part of the codebase from the very
start, and you will find many internet references which say that
mailx -a can be used to attach files.

 |> It seems this is fundamentally a problem with Debian packages and
 |> scripts relying on a non-standard extension.
 |
 |The point is, as far as I understand: there is no standard, just
 |implementations, and scripts relying on them. So no package or
 |implementation is "wrong".
 |
 |> Perhaps there could be a new program /usr/bin/debian-mailx which is
 |> guaranteed to always work that way, no matter which underlying "mail"
 |> program is installed. For 'mailutils', it would just be a wrapper,
 |> passing the arguments untouched. For 's-nail', it'd convert the -a
 |> syntax to s-nail's customhdr.
 |
 |A s-nail-compat wrapper script could be a solution, although not really
 |a nice one, but such a script at this point doesn't exist...
 | 
 |> Is it possible to identify which Debian packages require mail to use
 |> "-a" to mean custom header?
 |> Something like, grep "mail.*-a"? ¹
 |
 |It is probably not so easy. I think the only possibility here is a
 |wrapper script that implements the bsd-mail interface using s-nail.

With v14.9.7 it should be easy to implement such a thing by simply
using -C where Debian BSD-mailx would use -a.  (I think.)

Thanks for your interest, i hope we serve you well. ^.^
A nice Sunday i wish.
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#877388: RFA: s-nail -- feature-rich BSD mail(1)

[Steffen Nurpmeso]

Hallo.

Hilko Bengen <ben...@debian.org> wrote:
 |Package: wnpp
 |Severity: normal

First: thanks for updating this once again, Hilko!

 |s-nail, previously known as heirloom-mailx and nail, is the classic
 |/bin/mail program, with many modern features added. (Unfortunately it is
 |not suitable as a "mailx" because incompatible differences in command
 |line options with bsd-mailx, see #846062.)

I (still) disagree with the latter one.
It is compatible to POSIX mailx(1), and BSD Mail, it diverges from
Debian patches of bsd-mailx which have been added after Heirloom
mailx (then nail) introduced the command line flag in question.
That caused an issue in a (n imho bad) script sixteen years later.
The v14.9.* series which are landing in Debian now support custom
headers, too.

 |If I remember correctly, it was the first package I adopted after
 |joining Debian as a DD in 2003. After about 14 years and two project
 |forks/renames, I would like to see someone else take over package
 |maintenance.

I am sorry for this.

 |I feel that s-nail is suitable package for people with little packaging
 |experience to adopt. The current upstream author, Steffen Nurpmeso is
 |quite active and very responsive.

I am willing to fix any issues as fast as possible.  Maintaining
it as a package should usually involve nothing but adjustment of
the version number.  In fact anything else looks like a bug to me.
And, further more, it is likely that nothing much happens in the
two years which follow, we (the program and i) just saw the 5th
anniversary of our relationship, and i will spend some time with
other projects next.  Some things here and there, but henceforth
nothing in a hurry no more.

Thanks again Hilko from the snail and myself.

From rainy Germany,
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#876871: Non-empty transitional package

[Steffen Nurpmeso]

Hallo.

Christoph Berg <christoph.b...@credativ.de> wrote:
 |Re: Steffen Nurpmeso 2017-09-26 <20170926152012.hbcvl%stef...@sdaoden.eu>
 |> I am the developer of that program and it seems the Debian
 |> maintainer has quit.
 |
 |Hilko is still around, he's active on other packages.

Maybe the last gasp for air before the giant totally breaks down?
I do not think so.  There was something about go on debian-deb
once i have searched last (verified a second a-go), but how can
anyone be active once broken down?

 |Hilko: Maybe you could RFA/O the package so another maintainer could
 |take over?

I could make the cloned and updated repo public and then all we
need is his private signing key!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#876871: Non-empty transitional package

[Steffen Nurpmeso]

Hello.

Christoph Berg  wrote:
 |Package: heirloom-mailx
 |Version: 14.8.16-1
 |Severity: normal
 |
 |Description-en: feature-rich BSD mail(1) -- transitional package
 | This dummy package is provided to provide a smooth upgrade path from
 | heirloom-mailx to s-nail. It only contains symlinks to the s-nail
 | binary and manpage.
 |
 |The package claims to be a "dummy" "transitional" package, but really
 |contains a compatibility symlink /usr/bin/heirloom-mailx.
 |
 |Please remove the "transitional" and "dummy" keywords. (At least it
 |doesn't say "it can safely be removed", but this is customly implied
 |by "transitional package".)

I am the developer of that program and it seems the Debian
maintainer has quit.  I was getting no response when i sent the
updated recipes for the v14.9.* series which have arrived over two
months ago.  (And, to satisfy the foal(s): after two years of
development, and with lots of improvements.  And fixes.)
He was doing Debian packages for multiple decades, i think.  So.

I was hoping with v14.9.* we become a mailx alternative again,
too, because we are mailx, of course. 

Anyway, i have cloned the Debian tracker repository and updated
that to v14.9.4, some things required polish and updates.  'Did
not reinstantiate that mailx thing, because who am i to decide
that.  But i am not a Debian maintainer anyway so this likely will
disappear in the void unless someone cares for it.

Just drop me a mail.  I am interested in bringing this forward.
Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

[Steffen Nurpmeso]

Norman Ramsey  wrote:
 |>|Sorry, I think I misunderstand something.  I would think that
 |>|participation in update-alternatives would be a packaging issue, not
 |>|an upstream issue.  And I don't see a connection to custom headers...
 |> 
 |> It was my understanding that we have been removed as an
 |> alternative because we did not support custom headers...
 |
 |That's appalling.

Well, maybe that word is a bit excessive for a non-critical
software package.

 |> This -a seems to be a Debian extension to BSD Mail that has been
 |> introduced some months after nail->Heirloom mailx->S-nail
 |> introduced -a for adding attachments, i.e., this usage has always
 |> been broken, then.
 |
 |Oy.  I gather, then, that s-nail cannot be an alternative unless some
 |sort of political settlement is brokered, which may never happen.  Alas.

That was my impression at least.  Of course this MUA is still very
restricted, so in parts i can even understand the trouble.  We are
getting better, but it takes quite a lot of time.

 |Well, thank you for explaining the situation so clearly.
 |It may amuse you to know that I first noticed the substitution
 |(bsd-mailx for heirloom-mailx) because my -a command lines were
 |not working as expected.  Sigh.
 |
 |Good luck getting things sorted out with your colleagues.
 |Perhaps this bug report can serve as evidence that s-nail is an
 |important alternative for mailx, and that the inconsistencies should
 |be sorted out.  I have been using mailx -a at least since jessie and
 |maybe longer...

Thank you.  That would be nice.  I hope the improvements will make
you like it better than ever before.
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

[Steffen Nurpmeso]

Norman Ramsey  wrote:
 |> Norman Ramsey  wrote:
 |>  ...
 |>|I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 |>|
 |>|This is possibly the same bug as 858080, but I don't know enough
 |>|Debian jargon to know for sure.
 |> 
 |> The just released S-nail/mailx v14.9.0 adds support for custom
 |> headers, so one could possibly hope something moves on.
 |> That is all i (as the S-nail maintainer) can do,
 |
 |Sorry, I think I misunderstand something.  I would think that
 |participation in update-alternatives would be a packaging issue, not
 |an upstream issue.  And I don't see a connection to custom headers...

It was my understanding that we have been removed as an
alternative because we did not support custom headers: it seems
some scripts (a pretty bad shell script has been linked to in one
of those Debian issues), i think it had something to do with cron
.. anacron maybe it was?) relied on an -a command line option to
add custom headers.

This -a seems to be a Debian extension to BSD Mail that has been
introduced some months after nail->Heirloom mailx->S-nail
introduced -a for adding attachments, i.e., this usage has always
been broken, then.

And thus, because of this situation, i interpreted those reports
one of which you referred to as social pressure a.k.a. lobbyism to
get custom header support in the thing i maintain.  (Moreover,
a functioning predecessor was available at that time already, in
fact since January 2016, but i was not happy and the environment
as such was absolutely not right to make a release.  And of course
we do not offer -a, because that is taken for attachments, and
i think that makes more sense than -a meaning custom headers.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

[Steffen Nurpmeso]

Norman Ramsey  wrote:
 |I upgraded from jessie to stretch, and I expected to continue using
 |heirloom-mailx as my implementation of mailx.  But my system was
 |somehow switched to bsd-mailx.  Worse, update-alternatives is not
 |capable of changing back:
 ...
 |I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 |
 |This is possibly the same bug as 858080, but I don't know enough
 |Debian jargon to know for sure.

The just released S-nail/mailx v14.9.0 adds support for custom
headers, so one could possibly hope something moves on.
That is all i (as the S-nail maintainer) can do,
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#858080: s-nail does not Provide: mail-reader, mailx

[Steffen Nurpmeso]

Hello.

Hilko Bengen  wrote:
 |> Wasn't heirloom-mailx (the predecessor of s-nail) the primary mailx
 |> provider for Debian? 
 |
 |No, that must have been bsd-mailx.
 |
 |> In any event, h-m originally provided /usr/bin/mail and the upgrade path
 |> causes this to disappear. Scripts breaking due to mail(1) interface
 |> variations is a pain, but scripts breaking due to mail(1) disappearing
 |> altogether is a regression.
 |
 |Oh, I see. There are a number of packages which  depend on
 |heirloom-mailx | mailx... Those packages need some grave bugs reported,
 |then. Damn.
 |
 |> When I read "/usr/bin/mail interface," that implies to me that there is
 |> a /usr/bin/mail executable. Was the description intended to mean
 |> something like "mailx-style interface?"
 |
 |To be honest, I don't know. I read that as the command-line user
 |interface one might know from mailx.

So here i as the maintainer of the subject jump in and remark that
the problem of the bug report you pointed to was a non-standard
option of the Debian bsd-mail, our command line is a superset of
POSIX mailx.  (Unfortunately v14.9.0 has still not landed, so that
we offer no possibility to define custom headers; and it will not
be the Debian -a i think it was, which, also if i recall
correctly, has been patched into BSD-mail after Heirloom added -a
for adding attachments, which i think of as a logical and good
decision.)

I wish a nice weekend nonetheless.

--steffen

Bug#855582: Excellent!

[Steffen Nurpmeso]

Hi, Riccardo!

r.duc...@gmail.com wrote:
 |DearSteffen
 |
 |My  initial suggestion '%F %T' was just tentative, I do not care about it,
 |
 |I' really happy to know that you changed the default to  
 |+.Ql %Y-%m-%d %H:%M

Ok.

 |Thanks a lot for your time

Fantastic.  About four weeks and an enthusiastic Debian maintainer
and you should be able to get it via Debian package management, if
you want to.

 |Riccardo
 |
 |PS No credits needed, it is fine to me!

Is this ok, then?

CommitDate: 2017-02-22 16:08:42 +0100

THANKS: Riccardo Ductor
---
 THANKS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/THANKS b/THANKS
index 5cbdf8e4..8c9c3f38 100644
--- a/THANKS
+++ b/THANKS
...
+Riccardo Ductor   r dot ductor at gmail dot com
...

--steffen

Bug#855582: Wish: ISO default datefield

[Steffen Nurpmeso]

Hello again.

i wrote:
 |So i have dropped the entire "default".rc stuff, because we will
 |provide initial values for *datefield{-markout-older}*:
 |
 |+   ok_v_datefield, /* {i3val="%Y-%m-%d %H:%M"} */
 |+   ok_v_datefield_markout_older,   /* {i3val="%Y-%m-%d"} */
 |
 |I gave you credit for this, the commit is currently (but on the
 |development branch, which will soon change again) [1,credit:2].

So, was that you?  ^.^  I haven't included references to ISO 8601
because that really would get lengthy, i think it should be left
to strftime(3), at least for now.  Is the above an acceptable
solution to you?  And please speak up if you want your entry in
THANKS to include your name.

Thank you!
Ciao,

--steffen

Bug#795258: heirloom-mailx: fails to send mails when called from anacron

[Steffen Nurpmeso]

Hello,

i am the maintainer of S-nail, which is what one gets on a current
Debian when you install heirloom-mailx.  (At least in testing it
is.)

The problem of yours likely is that the *sendwait* variable is not
set, i.e., your invocation should be

  /usr/bin/heirloom-mailx -Ssendwait -s test root@localhost < /tmp/test.txt

because the MTA is otherwise invoked asynchronously, without
waiting for it to return.  That is, we exit to our superviser
(anacron) immediately, but still have a child running (sendmail).
If the superviser just cares enough it may cause all such "garbage
processes" to be terminated, effectively resulting in you message
not being sent.
This conclusion is contradicted by your

 Even /usr/sbin/sendmail is not called in this case.

however.  I don't know what makes you think it isn't called.
Note that the upcoming S-nail v14.9.0 will set *sendwait* in the
global resource file for exactly that reason, by popular demand.

Ciao.

--steffen

Bug#855582: Wish: ISO default datefield

[Steffen Nurpmeso]

Hello.

"r.ductor"  wrote:
 |Package: s-nail
 |Version: 14.8.16-1
 |Severity: wishlist
 |
 |Dear Maintainer,
 |
 |thnaks a lot for thice nice software.

Thank you -- and it is getting better, i hope..

 |You might want to consider changing the default datefield to '%F %T' \
 |or other iso variants.
 |
 |As a complete s-nail/mailx/mail newby I was really scaried by the headers \
 |my firs h showed,
 |the time ordering and year of the messages was compleately unclear.
 |I took me one hour of googling and a lot of patience to dive in the \
 |man to understand how
 |s-nail works. I'm not sure that all other newbies will have the same \
 |patience.

I see, sorry for that!  The manual of v14.8 misses the link to
*datefield*, but v14.9 already includes it, so you will have
a direct reference chain from "On reading mail, and interactive
mode" over *headline* to *datefield*, which i think is ok: it will
be hyperlinked if the output format supports it, so you could get
there really fast.

The global /etc/mail.rc (/etc/s-nail.rc on Debian) includes
a commented-out example for *datefield* and
*datefield-markout-older*, already in v14.8, but now that i look
again there is no link to *headline*, which i will change in
a minute!

Regarding %F and %T...  No, this i cannot do, because these
formats refer to newer ISO C versions (strftime(3)), and S-nail is
C89 compatible.  You would be right to claim that the examples
from mail/s-nail.rc are not so either, however.  And even if
i look at real old C library code you would then still be right
for the %g that i use for *datefield-markout-older*.  Ooops.
So, the old code would actually support %R and %T, but not %F and
%g (and i am talking about @(#)strftime.c  8.1 (Berkeley)
%06/04/93" from CSRG, here).

So i have dropped the entire "default".rc stuff, because we will
provide initial values for *datefield{-markout-older}*:

+   ok_v_datefield, /* {i3val="%Y-%m-%d %H:%M"} */
+   ok_v_datefield_markout_older,   /* {i3val="%Y-%m-%d"} */

I gave you credit for this, the commit is currently (but on the
development branch, which will soon change again) [1,credit:2].
Thank you, and, from grey Germany:

Ciao!

  [1] 
https://git.sdaoden.eu/cgit/s-nail.git/commit/?h=next=21b65e6ef720654fe0a6309a94354c7c9c97f247
  [2] 
https://git.sdaoden.eu/cgit/s-nail.git/commit/?h=next=373025818a3c13355d178565d12673719e711600

--steffen

Bug#846062: s-nail: not a proper mailx alternative

[Steffen Nurpmeso]

Hallo.

Hilko Bengen  wrote:
 |* Bas Zoetekouw:
 |> s-nail/heirloom-mailx is not a proper alternative for mailx/bsd-mailx,
 |> as it uses different command line options (for example on a regulair
 |> mailx, -a means "add header, whereas for s-nail it means "add
 |> attachment").
 |
 |We had some discussion about whether to provide a mailx alternative back
 |in the day when heirloom-mailx was still called nail, see #272256.
 |
 |And at one time there was even a report about a missing -a option
 |although it seems that then the submitter decided otherwise, see #381575
 |
 |> This breaks other packages (for example cron-apt) that rely on a
 |> mailx-dependency to send mails.  Therefore, I'm making this Serious
 |> severity.
 |
 |The -a option was added to bsd-mailx by Debian more than 16 years ago.
 |However, there does not seem to be any clear definition that tells us
 |what to expect from a /usr/bin/mailx program.
 |
 |Is this really s-nail's fault?
 |
 |Steffen, would you consider changing the parameter for adding an
 |attachment to something else?

Rather not, Gunnar Ritter introduced -a already in the first
release of (then) nail, v9.0.0, 21st of March 2000.  Even if not,
-a and attachments smells more sane than -a and header additions..
And also the -a of that patched bsd-mailx seems to be used for
faking MIME headers -- one of my occasional Google searches
regarding S-nail presented a bug report in Debian or Ubuntu that
matches this report here --, and that is pretty useless for
nail/mailx since that handles MIME itself.

Cron-apt, hm.  Ok, that not.  Terrible thing :).  Tja.  It is
possible to differentiate with a check:

  ?64[steffen@wales nail.git]$ mail -V  
 
  v14.8.14
  ?0[steffen@wales nail.git]$ echo|MAILRC=/dev/null mail -n#
 
  At EOF
  ?0[steffen@wales nail.git]$ echo|MAILRC=/dev/null heirloom-mailx -n#  
 
  heirloom-mailx: illegal option -- #
  Usage: heirloom-mailx -eiIUdEFntBDNHRV~ -T FILE -u USER -h hops -r address -s 
SUBJECT -a FILE -q FILE -f FILE -A ACCOUNT -b USERS -c USERS -S OPTION users

e.g.

  ( echo|MAILRC=/dev/null heirloom-mailx -n# ) >/dev/null 2>&1
  ( echo|MAILRC=/dev/null mail -n# ) >/dev/null 2>&1

Likely that this doesn't really hurt this script that much.
(Does it set MAILRC=/dev/null or use -n?  Don't think so.)
For none-MIME header additions (this "a" i realize) we will have
the `customhdr' command and the *customhdr* variable, as used for
sending this message (BlahBlahBlah and OpenPGP headers), which
could be used from the command line with -X (command) or -S
(variable), e.g.,

  echo bla|./s-nail -d -X'customhdr jazz funk' -Scustomhdr=ju:hu du@auch
  ...
  s-nail: >>> MTA: /usr/sbin/sendmail, arguments: sendmail -i -- du@auch
  s-nail: >>> Date: Mon, 28 Nov 2016 22:22:56 +0100
  s-nail: >>> To: du@auch
  s-nail: >>> User-Agent: s-nail v14.9.0-pre2-92-gcdbe3e5
  s-nail: >>> jazz: funk
  s-nail: >>> ju: hu
  s-nail: >>> 
  s-nail: >>> bla

Unfortunately only with v14.9.0 it will be possible to define
rather any header when feeding in via -t, too:

  ./s-nail -:/ -#d -t hey@you >> MTA: /usr/sbin/sendmail, arguments: sendmail -i -- hey@you
  s-nail: >>> Date: Mon, 28 Nov 2016 22:43:04 +0100
  s-nail: >>> From: hey
  s-nail: >>> To: hey@you
  s-nail: >>> User-Agent: s-nail v14.9.0-pre2-92-gcdbe3e5
  s-nail: >>> X-Curs: diet
  s-nail: >>> X-Tea: Chinese
  s-nail: >>> 
  s-nail: >>> Body.
  s-nail: >>> More Body.

Sorry.
I'm afraid we don't have that many command line options available
for use, but -a i think it cannot be.
Ciao.

--steffen

Bug#846062: s-nail: not a proper mailx alternative

[Steffen Nurpmeso]

Hello.

Bas Zoetekouw  wrote:
 |Package: s-nail
 |Version: 14.8.14-1
 |Severity: serious
 |
 |s-nail/heirloom-mailx is not a proper alternative for mailx/bsd-mailx,
 |as it uses different command line options (for example on a regulair
 |mailx, -a means "add header, whereas for s-nail it means "add
 |attachment").
 |
 |This breaks other packages (for example cron-apt) that rely on a
 |mailx-dependency to send mails.  Therefore, I'm making this Serious
 |severity.

I just want to annotate that -a is not a BSD Mail option, but
seems to be a Debian-specific extension.

S-nail v14.9.0 will offer the possibility to add custom headers
via the `customhdr' command (and the *customhdr* variable).
(I am the maintainer of S-nail.)

--steffen

Bug#806982: Left system with no mail alternative

[Steffen Nurpmeso]

Hello on a Friiday ^.^,

Anthony DeRobertis  wrote:
 |Package: s-nail
 |Version: 14.8.5-3
 |Severity: important
 |
 |heirloom-mailx used to provide an /usr/bin/mail on my system. I see

Regarding the overall philosophy behind mail / Mail / mailx and
S-nail it has to be said that compatibility flags like *bsdcompat*
etc. will rather get less than more.  And i'm all for that since
it is true that mail never has been stable and always evolved,
which M. Douglas McIlroy clearly analyses in his article "A
Research UNIX Reader: Annotated Excerpts from the Programmer’s
Manual, 1971-1986":

Electronic mail was there from the start. Never satisfied with its
exact behavior, everybody touched it at one time or another:

Note that v14.9 says more on this (the above is an excerpt of the
README file on the development branch).

S-nail will get more compatible with the actual POSIX mailx
standard (as that becomes possible because of codebase state
changes) and add its own features on top.  (After shrinking to
a healthy state that is.  And what i hope as of today.  Say.)

It is true that i'm removing some compatibility settings, e.g.,
v14.9 will obsolete support of the SUSV3 environment variable,
which sole purpose is to change the default setting of the
*attrlist* variable, which can be helped by doing "? set
attrlist='NU *HMFAT+-$~'".  I think this is an acceptable builtin
complexity reduction, especially given the long obsoletion time.

 |from the postinst that s-nail is supposed to as well... but it didn't
 |work.

O!

 |update-alternatives --auto mailx got it to work. I then purged
 |heirloom-mailx.

Wow.  Thank you!

P.S.:
S-nail has a long way to go.  Until then it will introduce
backward incompatible changes (e.g., colour support changes
completely in v14.9) and will (temporarily) loose features (e.g.,
no IMAP in v14.9+).  The codebase comes from the 70s and has been
designed in and for completely different circumstances.  I hope
i can go that way and that users follow there, too.  It will be
a long and winding road, anyway.
Ciao!

--steffen

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Hallo und guten Morgen!

Jörg-Volker Peetz  wrote:
 |thank you very much for the detailed explanation of your security
 |considerations. The concept looks sound for me.

Yes – i think it really is.

 |And I keep /usr/lib/s-nail/s-nail-privsep SETUID root.

Huh.  No chance against the Space Invaders.

 |And for your next e-mail:
 |
 |My fault. I searched the man-page for "dotlock" but overlooked the "a\
 |"-example.
 |The manual is really elaborated which I value much.

Oh, please.  I realised its terrible english once i've copied
& pasted and the tweak is in the other window.
I really hope S-nail will at some time be a real neat and painless
problem!  Eh!!  _Program_. …

Ciao!

--steffen

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

i wrote:
 |Hello, i'm the codebase maintainer of S-nail,
 |
 |Jörg-Volker Peetz  wrote:
 ||Package: s-nail
 ||Version: 14.8.5-3
 |
 ||trying to read local mails in /var/mail with mailx fails with output as
 ||follows:
 ||
 ||Creating dotlock for "/var/mail/" .
 ||Unable to (dot) lock mailbox, aborting operation: Permission denied
 |
 ||(where I replaced the user name with "").
 ||Any ideas?

Also, because my first response was very short, sorry: in general
S-nail offers some contextual informations when you set the -d
and/or -v command line switches (or interactive via "? set
debug").  E.g., if i strip SETUID and run (the development version
of) S-nail:

  s-nail: user = sdaoden, homedir = /home/sdaoden
  s-nail: Creating dotlock for "/var/spool/mail/sdaoden" .
  s-nail:   Can't create a lock file! Please check permissions
(Maybe setting *dotlock-ignore-error* variable helps.)
  s-nail: Unable to (dot) lock mailbox, aborting operation: Permission denied

Using "$ s-nail -dvv" provides a real dry-run test sandbox and
will also show obsoletion warnings (when features get actively
used which are obsoleted).

Granted the above is very fuzzy, since what is "permissions" here?
The user regarding the mailbox to be locked, the dotlock file
itself, or the privsep program?  Well, the latter at least cannot
be helped for real, since i think it is fine for S-nail to expect
that it has been installed correctly as is documented in its
INSTALL file, which is not a senselessly copied template.
Diversifying the former two in the above output is not necessary
since S-nail should never get that far:

  s-nail: /var/spool/mail/sdaoden: Permission denied

That is not a good message, user experience will hopefully improve
over time.
Hope this helps, and happy for feedback (especially negative),
Ciao,

--steffen

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Hallo Jörg-Volker,

Jörg-Volker Peetz <jvpe...@web.de> wrote:
 |Steffen Nurpmeso wrote on 12/02/2015 12:22:

 |> S-nail ships with a special, privilege-separated program that must
 |> be installed SETUID root; it seems Debian installs this program as
 |> "/usr/lib/s-nail/s-nail-privsep".  Doing "$ ls -latr" on this
 |> should give output like
 |> 
 |>   -r-sr-xr-x  1 root root 21856 Sep 11 16:09 s-nail-privsep*
 |> 
 |This was
 |
 |   -rwxr-xr-x 1 root root 10104 Nov 27 06:08 /usr/lib/s-nail/s-nail-privsep
 |
 |on my system. I upgraded from heirloom-mailx.

Yes that was wrong.  But i'm the wrong person to ask how this
could have happened.

 |May I ask where s-nail tries to write the "dotfile"?

Generic answer is that the Unix dotlock file locking method
creates the dotlock file in the same directory where the mailbox
file is located which is to be locked; e.g. "/var/mail/spool/user"
would need a dotlock file "/var/mail/spool/user.lock".

 |As far as I remember, mailx didn't need the sticky root bit before.

Well the old Heirloom codebase didn't do that very well, as did
S-nail until just the very current release.
The old codebase would have required to install the entire mailx
binary with SETGID to the group of the mail spool, most likely
"mail", and would have tried to create a dotlock file accordingly.
I suspect it was because of the original codebase that noone
i know installed this binary like that – just recall you can start
a shell via `!' and `shell' etc.!

So i've reimplemented that completely, and privilege-separated, so
that only a very small binary that is distinct from mailx itself
needs to be installed SETGID.

It however turned out to be insufficient for modern Unix layout,
e.g., OpenBSD doesn't even have such a group and/or the spool
directory simply belongs root:root and has 0755 permissions.
And, furthermore, mailx allows opening of mailboxes of different
"identities" via $USER (v14.9: also $LOGNAME), -u USER and "? file
%USER" *if* the real user that issues those commands has
sufficient rights to do so – and then the created dotlock file
would be YOU:mail and not USER:mail, so that USER would not be
able to delete the dotlock of his or her own mailbox by herself!

Therefore i came to the conclusion that the only sane and safe way
to implement modern and correct dotlocking would be to have
a SETUID "superuser" privilege-separated dotlock program, which
has the sole purpose of creating a dotlock file with the USER and
GROUP identities of the mailbox file for which the dotlock is to
be created for.

And the dotlock program can hardly be misused since it
(re-)verifies that the executing user has the necessary rights to
be able to read or read/write the target mailbox before it raises
its privileges and creates a dotlock file for that box.  Also it
tries very hard not to leave behind stale lock files: different to
other MUAs (which all only work SETGID as far as i know) the
dotlock program keeps on running (waiting) until the lock is to be
released again, and shall S-nail die or otherwise terminate then
the lock will still be cleaned up by the locker, which will
recognize this condition.  And it is faster since only one process
is ever started.  (In fact i'm a little bit prowd of the solution,
it may be the safest and sanest that is in existence as of today.
But i may be mistaken, of course.)

 |> i.e., SETUID root, executable for anyone, "$ chmod 4555 FILE" as
 |> root (via super / sudo / su as necessary) will do.
 |
 |Yes, with the sticky bit set the mailx command works here.
 |But is it really necessary?

Great!  Well.  In general "yes", but since most non-server
software does it wrong and anything is still all right the answer
may be "no".  ^_^
Ciao,

--steffen

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Hello, i'm the codebase maintainer of S-nail,

Jörg-Volker Peetz  wrote:
 |Package: s-nail
 |Version: 14.8.5-3

 |trying to read local mails in /var/mail with mailx fails with output as
 |follows:
 |
 |Creating dotlock for "/var/mail/" .
 |Unable to (dot) lock mailbox, aborting operation: Permission denied

 |(where I replaced the user name with "").
 |Any ideas?

S-nail ships with a special, privilege-separated program that must
be installed SETUID root; it seems Debian installs this program as
"/usr/lib/s-nail/s-nail-privsep".  Doing "$ ls -latr" on this
should give output like

  -r-sr-xr-x  1 root root 21856 Sep 11 16:09 s-nail-privsep*

i.e., SETUID root, executable for anyone, "$ chmod 4555 FILE" as
root (via super / sudo / su as necessary) will do.
Note that v14.8.5 doesn't take into account readonly filesystems:
v14.9 will special treat errors caused by this condition instead.
It really should work fine otherwise?

--steffen

Bug#806858: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Jörg-Volker Peetz  wrote:

 |May I ask where s-nail tries to write the "dotfile"?
 |As far as I remember, mailx didn't need the sticky root bit before.

I forgot to say that i really put some effort into the manual (and
it will be even better in v14.9).
So the answer for this can also be found in there – the entry for
the `file' command reads:

  MBOX files (flat file-based mailboxes) are generally locked dur‐
  ing file operations in order to avoid inconsistencies against
  concurrent modifications.  Mailbox files which S-nail treats as
  system mailboxes will also be protected by so-called dotlock
  files, the traditional way of mail spool file locking: for any
  file ‘a’ a lock file ‘a.lock’ will be created for the duration
  of the synchronization — as necessary a privilege-separated dot‐
  lock child process will be used to accommodate for necessary
  privilege adjustments in order to create the dotlock file in the
  same directory and with the same user and group identities as
  the file of interest.  Also see mbox-rfc4155[356] for fine-tun‐
  ing the handling of MBOX files.

Ciao!

--steffen

Bug#806258: s-nail: Cannot start "/usr/bin/sendmail": executable not found

[Steffen Nurpmeso]

Hello!

Salvatore Bonaccorso  wrote:
 |Package: s-nail
 |Version: 14.8.5-1
 |Severity: serious
 |Justification: Policy 11.6. Mail transport, delivery and user agents
 |
 |Hi
 |
 |Filling this as serious, as per Policy 11.6 sendmail is from
 |/usr/sbin/sendmail. s-nail though has the problem that during build
 |configures SENDMAIL to '/usr/bin/sendmail'.
 |
 |$ echo test | /usr/bin/s-nail -s 'test' root
 |Cannot start "/usr/bin/sendmail": executable not found (adjust *sendm\
 |ail* variable)

Thanks for the reference, i have adjusted the S-nail build system
to use /usr/sbin as the fallback path when no sendmail(1) binary
can be found.  This change is on the [master] branch.

I have just returned to work regulary (also) in the Linux world,
and on *BSD there is a default sendmail(1); which is why we tested
/usr/sbin first, not taking into account the possibility that
there is no sendmail(1) at all, while keeping that standard path
fallback.  (I.e., i see this issue as a follow-up to [bda59aa]
(MTA execv(2) failure: improve error message (Dominic Meskys)..,
2015-03-09) that shouldn't have been necessary.)  (And the next
release of S-nail will also improve the error message so that it's
clear who generated it when run in a pipe.)
Ciao,

--steffen

Bug#806300: s-nail: FTBFS on arm64,...

[Steffen Nurpmeso]

Hello, i'm the maintainer of the S-nail codebase,

Edmund Grimley Evans  wrote:
 |Source: s-nail
 |Version: 14.8.5-2
 |User: debian-...@lists.debian.org
 |Usertags: arm64
 |
 |It failed to build on several architectures:
 |
 |https://buildd.debian.org/status/package.php?p=s-nail=sid
 |
 |It seems to go into an infinite loop while running tests.

Ah, that's what is going on!

 |This symptom and the pattern of failures is typical of programs that
 |assume that plain char is signed. Fortunately there's a warning in
 |the build log that tells you exactly where the bug is:

:}

 |sendout.c: In function '_outof':
 |sendout.c:1215:33: warning: comparison is always true due to limited
 |range of data type [-Wtype-limits]
 |  while ((c = getc(fin)) != EOF)
 |
 |Just change the type of c from char to int!

The change is already on the [master] branch of S-nail and i have
mailed the Debian maintainer and asked wether he wants a diff.
I'll attach the changeset that has been pushed.
Ciao,

--steffen
commit f43e04e
Author: Steffen (Daode) Nurpmeso 
Date:   2015-11-25 19:27:05 +0100

sendout.c:_outof(): FIX char/int vs. EOF type error
---
 sendout.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sendout.c b/sendout.c
index b302e10..f7f09ba 100644
--- a/sendout.c
+++ b/sendout.c
@@ -1199,7 +1199,9 @@ jcantfout:
  }
  free_child(pid);
   } else {
- char c, *fname = file_expand(np->n_name);
+ int c;
+ char *fname = file_expand(np->n_name);
+
  if (fname == NULL) {
 *senderror = TRU1;
 goto jcant;

Bug#806258: s-nail: Cannot start "/usr/bin/sendmail": executable not found

[Steffen Nurpmeso]

P.S.: sorry for not introducing myself: i am the maintainer of the
S-nail codebase.  Thanks again.

--steffen

Bug#411718: nail

[Steffen Nurpmeso]

Hello,

i'm the maintainer of the codebase of S-nail which seems to be on
its way to replace Heirloom-mailx on Debian.
This should be fixed when upgrading to s-nail.

--steffen