[Nmh-workers] [mmh] mmh-0.3 is released! (meillo's mail handler)

[markus schnalke]

Hello everyone,

it is my pleasure to announce the release of mmh-0.3:

http://marmaro.de/prog/mmh/files/mmh-0.3.tar.gz
(md5sum: 880017112da72d7d67856c13a252d436)
http://marmaro.de/prog/mmh/files/mmh-0.3.tar.gz.asc
http://marmaro.de/prog/mmh/files/mmh-0.3.tar.gz.asc2

The most important improvements:

- m_getfld() is replaced by m_getfld2() (i.e. We killed the beast!)
- mmh became portable over stdio implementations, e.g. musl libc
- repl now decodes MIME messages in the quotated text
- send invokes mhbuild automatically on every message
- send became able to send from folders other than +drafts
- inc learned to read from stdin
- mhsign encryption works with aliases
- whatnow2 is included as a probable future replacement for whatnow

See the NEWS file in the tarball for an extended summary of the changes.
Alternatively online: http://git.marmaro.de/?p=mmh;a=blob;f=NEWS;t=mmh-0.3
For the full changelog have a look at the ChangeLog file in the
distribution, use `git log', or view: http://git.marmaro.de/?p=mmh;a=log

You can clone the code with: git clone http://git.marmaro.de/mmh

Mmh's website is: http://marmaro.de/prog/mmh/


An overview on mmh's code base in numbers:

In total, mmh-0.3 has 32,645 SLOC, compared to 32,382 SLOC of mmh-0.2
and 28,757 SLOC in mmh-0.1. Regarding C code only, it's 25,930 (-430)
compared to 26,360 and 25,342. The subdirectories in detail:

SLOCChangeDirectory SLOC-by-Language (Sorted)
19059   (+100)uip ansic=18223,sh=836
6959(-250)sbr ansic=6885,awk=74
3017(+400)testsh=3017
2732  top_dir sh=2732
762   h   ansic=762
92config  ansic=60,sh=32
24man sh=24
0 docs(none)
0 etc (none)

The largest growth again is in the testsuite. The main code in C
shrunk (which is a good sign). The growth in uip comes from
including both, whatnow in C (420 SLOC) and whatnow2 in sh (270 SLOC).
(All numbers calculated by sloccount.)


Thanks to everyone who contributed to this release. Again, it was
Philipp Takacs, who did most of the work. The commits:

 41 Author: Philipp Takacs <phil...@bureaucracy.de>
 39 Author: markus schnalke <mei...@marmaro.de>
 12 Author: m...@arascio.xyz <m...@arascio.xyz>
  2 Author: Vasily Kolobkov <polezaivs...@openmailbox.org>
  2 Author: Dmitry Bogatov <kact...@gnu.org>
  1 Author: Jan Düpmeier <j.duepme...@gmail.com>

Further contributions on the mailing list by: Marcin Cieslak,
Joshua Haase, j...@ssh.bio, Alba Pompeo, and Sören Tempel.


We welcome comments, bug reports, and suggestions. Please send them
to the mailing list at <m...@marmaro.de>.


meillo


pgpKTxVZuL6fa.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] mmh-0.2 is released! (meillo's mail handler)

[markus schnalke]

Hello everyone,

it's my pleasure to announce the release of mmh-0.2:

http://marmaro.de/prog/mmh/files/mmh-0.2.tar.gz
(md5sum: f783e729a25cc3bbe4b856aca89b85b2)
http://marmaro.de/prog/mmh/files/mmh-0.2.tar.gz.asc

The most important improvements:

- Automatic encoding of non-ASCII headers using RFC 2047
- pick(1) works on decoded RFC 2047 header values
- New profile option Default-From, which defines just what it says
- The Dcc header is available again
- dist(1) works again
- A Sender header is inserted as appropriate
- Recipients are passed as command line arguments to sendmail
- rmm(1) uses refile(1)

See the NEWS file in the tarball for an extended summary of the changes.
Alternatively online: http://git.marmaro.de/?p=mmh;a=blob;f=NEWS;t=mmh-0.2
For the full changelog have a look at the ChangeLog file in the
distribution, use `git log', or view: http://git.marmaro.de/?p=mmh;a=log

You can clone the code with: git clone http://git.marmaro.de/mmh

Mmh's website is: http://marmaro.de/prog/mmh/


An overview on mmh's code base in numbers:

In total mmh-0.2 has 32,382 SLOC, compared to 28,757 SLOC in mmh-0.1.
Regarding C code only, it's 26,360 compared to 25,342 (+1020, i.e.
a growth by 4%). The subdirectories in detail:

SLOCChangeDirectory SLOC-by-Language (Sorted)
18953   (+400)uip   ansic=18395,sh=558
7219(+640)sbr   ansic=7145,awk=74
2733  top_dir   sh=2732,ansic=1
2602(+2600)   test  sh=2602
760 (-15) h ansic=760
91configansic=59,sh=32
24man   sh=24
0 docs  (none)
0 etc   (none)

In the sbr directory, the RFC 2047 implementation added 670 lines
itself. The main influence on the code growth, however, is the test
framework. (All numbers calculated by sloccount.)


Thanks to everyone who contributed to this release. It was Philipp
Takacs, who did most of the work. I also like to acknowledge, that
a lot of code was ported from nmh.


We welcome comments, bug reports, and suggestions. Please send them
to the mailing list at .


meillo


pgpp5quhXk5bE.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] m_getfld

[markus schnalke]

[2012-12-09 18:59] Ken Hornstein k...@pobox.com
 Yes, but by different purposes I was thinking how scan
 digs back into the IO buffers.  Though maybe that won't
 be necessary any more.
 
 I had forgotten about that.  Okay, looking at that now  alright,
 that's not as nasty as I thought.  All it does is to use the output
 stdio buffer as the input buffer for m_getfld() so we can avoid an extra
 copy.  Can we all agree that's not necessary anymore, and the resulting
 performance gain is probably miniscule?  If so, I can simply get rid of
 that garbage now.

Just one word about performance:

I've removed the ``dig into internal IO buffers'' stuff in March and
noticed no performance loss. See
http://git.marmaro.de/?p=mmh;a=commitdiff;h=d7b4f0034bc4f5b5c2f990d0984858e9b6f4131a


meillo

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

Re: [Nmh-workers] m_getfld

[markus schnalke]

[2012-12-10 08:40] markus schnalke mei...@marmaro.de
 [2012-12-09 18:59] Ken Hornstein k...@pobox.com
  Yes, but by different purposes I was thinking how scan
  digs back into the IO buffers.  Though maybe that won't
  be necessary any more.
  
  I had forgotten about that.  Okay, looking at that now  alright,
  that's not as nasty as I thought.  All it does is to use the output
  stdio buffer as the input buffer for m_getfld() so we can avoid an extra
  copy.  Can we all agree that's not necessary anymore, and the resulting
  performance gain is probably miniscule?  If so, I can simply get rid of
  that garbage now.
 
 Just one word about performance:
 
 I've removed the ``dig into internal IO buffers'' stuff in March and
 noticed no performance loss. See
 http://git.marmaro.de/?p=mmh;a=commitdiff;h=d7b4f0034bc4f5b5c2f990d0984858e9b6f4131a

Ups sorry. That was just one of the several ``dig into interal IO
buffers'' places. Sorry for the noise. :-/


meillo

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

[Nmh-workers] Experimental version: mmh

[markus schnalke]

Hoi community,

nmh seems to move again -- great!

This pushed me to let you know about my current work.

I had been active on this list, one year ago, trying to improve nmh. I
had to learn that this community is different to others I've seen so
far. I also found out that my view of nmh's future is quite different
to the view of many people here. Nontheless, I still use nmh and still
love to change it to satisfy my wishes.

During the time last year, I came to the conclusion that the best way to
work freely is going my own way. Especially as my wishes are contrary
to yours in the mayor points concerning compatibility and the question
if nmh should be a mail system or only a MUA (without MTA). Therefore, I
decided to create an experimental version (call it ``fork'') of nmh,
named ``mmh'' (``meillo's mh'', but also ``minimalistic/minimized mh'').
For this experiment, I change to achieve small improvements rather
than stay compatible to nmh. Such an approach can only be taken in an
experimental fork, by (temporarily) cutting the connections behind. I
don't intend to steal your man power, but instead, doing my own
experiments to create some result that is even more usable to me than
nmh. Hopefully, this will then improve nmh in some way, too.

I don't know where my work will lead me to, nor do I know if I will
create any useful results at all, but I have ideas and motivation and
a code base to build upon (thank you!).

I'll let you know about my progress.


You care about nmh in the meantime. :-)


meillo

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

Re: [Nmh-workers] non-ASCII message bodies

[markus schnalke]

[2010-12-16 12:59] Ken Hornstein k...@pobox.com
 
 For this reason, I still prefer that changing the behavior be done with an
 option.
 Is it possible to come to agreement on this and move forward?
 
 I personally think we have consensus on this should be changed, and the
 new behavior should be the default; do other agree?

I obviously agree. But I think you already knew. ;-)


meillo

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

Re: [Nmh-workers] unapplied patches

[markus schnalke]

[2010-12-14 12:29] Oliver Kiddle okid...@yahoo.co.uk
 I've had a look through for any pending patches since the last release.
 Mostly, this is Meillo's recent patches. Does anyone know of any further
 patches that we might apply or rework.

 undo of install-mh
   Nobody would ever run an uninstall-mh script and I doubt that the
   person raising the bug was a user looking for it. Most software
   creates a pile of dot files without even asking these days. If
   any fix is necessary, I'd vote for a tiny bit more detail in the
   man page - less than the original patch included.

I agree that the need for a uninstall-mh is low and I had been
convinced that we don't need or even want a program to do the job.

However, I haven't known exactly what install-mh does until I read
through its code. As I think it is worthwhile to know what files do
get installed I vote for extending the man page in this respect. The
mention of `mhpath +` for finding the mail storage had been a very
useful hint for me, thus it may be for others. Remind that users who
run mh-install usually are not very familiar with nmh yet.


 Any objections if I apply those? Doesn't git have some ways to preserve
 details of the actual author of a patch? Or better still, could someone
 give Meillo permissions on the git repository.

I don't need permissions now as I will be offline from Friday on (will
write a mail related to that soon), also I think I don't want
permissions currently. I feel better if you apply patches I propose.

But I do miss my name on stuff I had been involved in. This surely
affects anyone who contributes in any way. Adding names to commit
messages or the changelog is sufficient IMO.


 If I understand correctly, the MIME handling improvments are not yet
 finished?

Rather: It's not yet decided what is considered right for nmh.


meillo

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

[Nmh-workers] Will be offline soon

[markus schnalke]

Hoi,

it's time to say goodbye. I will leave on Friday for three more month
traveling. Now through Patagonia. :-) I will enjoy being far away from
technology, at the end of the world. Hence you will hardly hear from
me before April.

My work on nmh in the last months had been some kind of internship. I
had to do this for university in order to be able to travel around. It
was great to find Michael Richardson to act as sponsor; he made
everything possible. Michael, thank you very much!

Working on nmh -- a Free Software project that I like -- had been a
wonderful opportunity. The actual goal had been fixing the decoding of
quoted text in replies. This I had not been able to achieve. As you
read the list, you know the reasons. Nonetheless, I feel that my work
improved nmh here and there, which is just as good. For myself, I'm
content with what I achieved, especially because I learned so much
about nmh and its code lost the strangeness and obscurity. That means,
I'm ready for further development. :-)

I'm also very pleased to see that my activity made you active too. The
matter is not who does the work but that nmh gets better.

I like to thank you all for the good time I had with you. It had been
rough sometimes, but in the end it tought me a lot.

Keep staying active and wait for me to return in April.


meillo


P.S.
I'll post some ``open ends'' to the list shortly.

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

Re: [Nmh-workers] about mhpath

[markus schnalke]

I also found some comments I added to the code because I was puzzled.
It would be nice to have it explained by someone who knows the code.


--- a/uip/mhpath.c  Tue Nov 30 15:30:45 2010 -0300
+++ b/uip/mhpath.c  Tue Dec 14 12:43:31 2010 -0300
@@ -97,6 +97,7 @@
  * for all the message numbers from 1 to new since
  * mhpath can select empty slots.  If we are adding
  * space at the end, we go ahead and add 10 slots.
+ * (Why 10 and not 1 for new? meillo)
  */
 if (mp-hghmsg = mp-hghoff) {
if (!(mp = folder_realloc (mp, 1, mp-hghmsg + 10)))
@@ -105,6 +106,13 @@
if (!(mp = folder_realloc (mp, 1, mp-hghoff)))
adios (NULL, unable to allocate folder storage);
 }
+/*
+ * as folder_realloc() checks itself if the realloc really
+ * is necesary, why don't we then:
+ *if (!(mp = folder_realloc (mp, 1, mp-hghmsg+1)))
+ *adios (NULL, unable to allocate folder storage);
+ * ? This at least appears most clear to me. meillo
+ */
 
 mp-msgflags |= ALLOW_NEW; /* allow the new sequence */


For once I would simply like to know, but also I think this could be
a code quality matter. However, the effort needed to dig into it could
be high in contrast to the outcome.

meillo

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

[Nmh-workers] about folder_addmsg.c

[markus schnalke]

Hoi,

Peter told me to test his changes to sbr/folder_addmsg.c some weeks
ago. I had a look at the code and came to the conclusion that
everything is fine with it. I also tested some corner-cases. I wanted
to write an automated test but unfortunately it never came to happen.

While digging through folder_addmsg.c I found the code unclear at some
places and there might also be logical bugs (maybe without effect). I
don't know. I haven't had enough time to dig further.

What I did stumble upon:

/*
 * Check if the file in our desired location is the same
 * as the source file.  If so, then just leave it alone
 * and return.  Otherwise, we will continue the main loop
 * and try again at another slot (hghmsg+1).
 */
if (linkerr == EEXIST) {
if (stat (msgfile, st2) == 0  stat (newmsg, st1) == 0
 st2.st_ino == st1.st_ino) {
return msgnum;
} else {
continue;
}
}

What's the sense of this? It appears to be a check if the link had
already be done. Like if there would exist a second process that tries
to do the same at the same time but one wantes the action to happen
only once. This also could be a safety check from some earlier version
of the code.

The point is that I could not figure out why this check is needed. I
removed it and everything I had testen went still well. However, it
was just manual testing.

The VCS log shows nothing about it. It probably is very old.

Can someone explain?


Further more this code (following the above):

/*
 * If link failed because we are trying to link
 * across devices, then check if there is a message
 * already in the desired location.  If so, then return
 * error, else just copy the message.
 */
if (linkerr == EXDEV) {
if (stat (newmsg, st1) == 0) {
advise (NULL, message %s:%s already exists, mp-foldpath, 
newmsg);
return -1;

Why the check for an existing message there? In all other cases we
would try again with the next number.

Again, the only explanation that sounds logical is that it is code to
handle some ancient cases which I am not aware of.



I also refacored the function heavily in order to make in clearer.
See attached patch. (Don't bug me because of the goto! I am convinced
that it is worthwhile there.)

Again I did some manual testing but can not guarantee that it behaves
exactly the same (modulo the two cases from above). A good test suite
would be helpful. :-)

I like to share this with you because I will be off for so long. Also
it is documented herewith and I can refer to it myself later on.


meillo


P.S.
folder_addmsg() is used in:
- uip/inc.c
- uip/mhstoresbr.c
- uip/rcvstore.c
- and uip/refile.c
diff -r ee0fbbb9f709 sbr/folder_addmsg.c
--- a/sbr/folder_addmsg.c   Tue Nov 30 15:30:45 2010 -0300
+++ b/sbr/folder_addmsg.c   Tue Dec 14 12:55:30 2010 -0300
@@ -14,6 +14,40 @@
 #include errno.h
 
 /*
+ * Copy the file if the link failed because of different devices.
+ * returns 1 on success, 0 on failure
+ */
+static int
+copymsg(char *msgfile, char *newmsg, int deleting, char* from_dir)
+{
+int infd, outfd;
+struct stat st1;
+char oldmsg[BUFSIZ];
+
+if ((infd = open (msgfile, O_RDONLY)) == -1) {
+advise (msgfile, unable to open message %s, msgfile);
+return 0;
+}
+fstat (infd, st1);
+if ((outfd = creat (newmsg, (int) st1.st_mode  0777)) == -1) {
+advise (newmsg, unable to create);
+close (infd);
+return 0;
+}
+cpydata (infd, outfd, msgfile, newmsg);
+close (infd);
+close (outfd);
+
+if (deleting) {
+(void)snprintf(oldmsg, sizeof (oldmsg), %s/%s, from_dir, msgfile);
+(void)ext_hook(ref-hook, oldmsg, newmsg);
+} else
+(void)ext_hook(add-hook, newmsg, (char *)0);
+
+return 1;
+}
+
+/*
  * Link message into a folder.  Return the new number
  * of the message.  If an error occurs, return -1.
  */
@@ -22,198 +56,170 @@
 folder_addmsg (struct msgs **mpp, char *msgfile, int selected,
int unseen, int preserve, int deleting, char *from_dir)
 {
-int infd, outfd, linkerr, first_time, msgnum;
+int linkerr, msgnum;
 char *nmsg, newmsg[BUFSIZ];
 char oldmsg[BUFSIZ];
 struct msgs *mp;
-struct stat st1, st2;
+struct stat st1;
 
-first_time = 1;/* this is first attempt */
 mp = *mpp;
 
 /*
+ * What number for the new message?
+ */
+if (preserve  (msgnum = m_atoi (msgfile))  0) {
+   /* keep the same number */
+   ;
+} else if (mp-nummsg == 0) {
+   /* we are adding to an empty folder */
+   msgnum = 1;
+} else {
+   /* else use highest message number + 1 */
+   msgnum = mp-hghmsg + 1;
+}
+
+/*
  * 

[Nmh-workers] Missing `/' in the result of m_mktemp2()

[markus schnalke]

Hoi,

I was moving my newest, and personally modified, version of nmh to a
different system. Now I encountered an error:

mhbuild: unable to rename output /home/meillo/Mail/sendwvJV2J to
 /home/meillo/Mailmhbuild29ELnc: Invalid cross-device link

The cross-device link error comes from ~/Mail being a symlink to
another device:

lrwxrwxrwx [...] /home/meillo/Mail - /data/mail/

The point is, the second path (`/home/meillo/Mailmhbuild29ELnc') is
missing a slash.

I tracked the problem down.

uip/mhbuild.c in main():

357 /* output MIME message to this temporary file */
358 strncpy(outfile, m_mktemp2(compfile, invo_name, NULL, fp_out),
359 sizeof(outfile)); 

If you print `outfile' you see the wrong path.

The problem comes from sbr/m_mktemp.c in m_mktemp2():

122 if ((cp = r1bindex ((char *)dir_in, '/')) == dir_in) {
123 /* No directory component */
124 return m_mktemp(pfx_in, fd_ret, fp_ret);
125 }
126 n = (int)(cp-dir_in-1); /* Length of dir component */
127 snprintf(buffer, sizeof(buffer), %.*s%s, n, dir_in, pfx_in);
128 return m_mktemp(buffer, fd_ret, fp_ret);

`cp - dir_in - 1' excludes the trailing slash.


I don't know, and unfortunately don't have time to find out, where to
fix.


If the mail storage is no symlink to another device, one might not
notice this bug at all.

Maybe it is present in any use of m_mktemp2(), maybe only in those
with the first argument non-NULL.


A trivial hack to fix the problem is `126s/-1//' in sbr/m_mktemp.c.
But I have not clue if this solves the problem right, it just made
things work again for me.


Would be great if someone goes for the problem. I think I will be able
to test a fix.


meillo


P.S.
Both files were not modified by my modifications.

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

Re: [Nmh-workers] Missing `/' in the result of m_mktemp2()

[markus schnalke]

[2010-12-14 22:41] markus schnalke mei...@marmaro.de
 
 A trivial hack to fix the problem is `126s/-1//' in sbr/m_mktemp.c.
 But I have not clue if this solves the problem right, it just made
 things work again for me.

The hack fixes only part of the problem. Now ~/Mail fills with
`mhbuildX' files and the like. And the message draft does not get
included into the posted message.

No quick hacking but a close and thorough look is needed.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Hoi,

discussing these things hadn't been easy sometimes, but the points and
arguments became clear and now we reached some kind of consensus. For
me, the discussion had been worthwhile.


[2010-12-03 11:33] Jon Steinhart j...@fourwinds.com
 
  o  Nobody objects to markus addressing this issue.  The objections are that
 his implementation breaks things, and handling illegal body content is
 not a compelling enough reason for breaking things.

 So, I think that enough has been said on this topic.  markus, can you outline
 for us an implementation that doesn't break things?  I think that everyone 
 will
 bless your changes if you do.

I agree with you here. Hence I created a new patch that concentrates
on the fourth case, explained in the other mail. AFAIS it does not
break anything.

Let me explain:

As it only modifies your attachment system now, everything is the same
if -attach is not specified.

For -attach being specified, the situation is such:

  no attachment hdr  +  body contains only ASCII  -  sent as is
  attachment hdr +  body contains only ASCII  -  MIMEified
  attachment hdr +  body contains non-ASCII   -  MIMEified
  no attachment hdr  +  body contains non-ASCII   -  MIMEified

The fourth case is different.

Additionally, the body text will be sent with a correct mime-type in
any case. Currently it was sent as application/octet-stream in the
third case.


The relation to `mime' at the whatnow prompt:

One surely wants to unset automimeproc when using -attach.

Running `mime' at the whatnow prompts is usually not needed as Jon's
attachment system handles it automatically.

Collisions only occure if an attachment header is present in the mail
and one runs `mime' at the whatnow prompt. If the body text contains
non-ASCII chars or not is irrelevant, it works as expected in both
cases.

As long as one does not add attachment headers to a specific draft,
one is able to use any mhbuild directives (/^#/) when running `mime'
at the whatnow prompt afterwards.


Further work:

The documentation currently does not cover my changes. Not much to
change, and I like to do that if the proposed changes are accepted.

More complex MIME structures than ``text followed by attachments'' are
not possible with Jon's attachment system. (Like they are not with
most MUAs.) One needs to create them with mhbuild directives and run
`mime' manually. (For forwarding messages, see below.)

Jon's attachment system still needs mhshow-suffix- entries or it will
be really dumb. This is something that should be covered separately,
maybe by a conceptional redesign (automatic detection, mailcap, ...).

Forwarding messages in MIME format could be added to Jon's system in a
way similar to what I proposed initially. I believe this would be
possible without breaking stuff. We would need to add -attach to
forw(1).


meillo


 P.S.  I'm trying to honor the way that you're name appears in your mail 
 header.
   Do you really want it to be markus or should it be Markus?

Usually, I prefer ``meillo'' because that's a nearly unique
identifier. If you want to use my real name, I don't care if you spell
it in lower-case or with capital `M'. More important is honoring my
work by mentioning my name in the ChangeLog or commit messages. ;-)

diff --git a/uip/sendsbr.c b/uip/sendsbr.c
index 57ef007..8f5f2e1 100644
--- a/uip/sendsbr.c
+++ b/uip/sendsbr.c
@@ -196,6 +196,7 @@ attach(char *attachment_header_field_name, char *draft_file_name,
 int			c;			/* current character for body copy */
 int			has_attachment;		/* draft has at least one attachment */
 int			has_body;		/* draft has a message body */
+int			non_ascii;		/* msg body contains non-ASCII chars */
 int			length;			/* length of attachment header field name */
 char		*p;			/* miscellaneous string pointer */
 
@@ -228,29 +229,36 @@ attach(char *attachment_header_field_name, char *draft_file_name,
 	if (strncasecmp(field, attachment_header_field_name, length) == 0  field[length] == ':')
 	has_attachment = 1;
 
-if (has_attachment == 0)
-	return (DONE);
-
 /*
- *	We have at least one attachment.  Look for at least one non-blank line
- *	in the body of the message which indicates content in the body.
+ * Check if body contains at least one non-blank char (= not empty)
+ * and if it contains non-ASCII chars (= need MIME).
+ * We MIMEify the message also if the body contains non-ASCII text.
  */
 
 has_body = 0;
+non_ascii = 0;
 
 while (get_line() != EOF) {
 	for (p = field; *p != '\0'; p++) {
-	if (*p != ' '  *p != '\t') {
+	if (*p != ' '  *p != '\t')
 		has_body = 1;
+	if (*p  127 || *p  0) {
+		non_ascii = 1;
 		break;
 	}
 	}
-
-	if (has_body)
+	if (non_ascii)
 	break;
 }
 
 /*
+ * Bail out if there are no attachments and only ASCII text.
+ * This means we don't need to convert it to MIME.
+ */
+if (!has_attachment  non_ascii == 0)
+	return (DONE);
+
+/*
 

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 08:27] Jon Steinhart j...@fourwinds.com
 Sounds good.  Is the patch that you sent out complete?  I don't see an option
 that enables/disables this behavior and I think that there should be one.

I believe it's correct that there is no switch.

If one wants to deactivate it, do not specify -attach.

If -attach is given, I believe the changes are fixes for broken
behavior. Your attachment system lacks some awareness for non-ASCII
text, which you probably don't deal with much. This is improved with
my patch.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 09:10] Jon Steinhart j...@fourwinds.com
  [2010-12-07 08:27] Jon Steinhart j...@fourwinds.com
   Sounds good.  Is the patch that you sent out complete?  I don't see an 
   option
   that enables/disables this behavior and I think that there should be one.
  
  I believe it's correct that there is no switch.
  
  If one wants to deactivate it, do not specify -attach.
  
  If -attach is given, I believe the changes are fixes for broken
  behavior. Your attachment system lacks some awareness for non-ASCII
  text, which you probably don't deal with much. This is improved with
  my patch.
 
 OK.  I think that there should be a switch.  I guess it bugs me to see the
 character-by-character examination of the message body on by default.

The char-by-char examination is ugly, yes.


 I understand that my attachment system does not handle non-ASCII message
 bodies, but again, that's because non-ASCII message bodies are not legal.
 I think that you have justified extending nmh to handle illegal message
 bodies.  I'm just nitpicking on the implementation details.

With MIMEification, they are legal.

I want nmh to convert illegal draft messages to legal messages.
Currently nmh sends illegal messages if the user composes such ones.
With my patch nmh cares to only send legal messages. Programs should
support humans if possible.


 Could you please explain again how you get the character set information
 for non-ASCII message bodies?  Sorry that I didn't save your original
 message on this.  I seem to recall that you got it from the profile; I
 would rather see you get this from the LANG environment variable.

I just leave it up to buildmimeproc to find out. :-) We don't need to
do it at several places. I only say it's text/plain but nothing about
the encoding.

The man page of mhbuild(1) writes:

If a text content contains any 8-bit characters (characters with the
high bit set) and the character set is not specified as above,  then
mhbuild will  assume  the character  set  is  of  the type given by
the environment variable MM_CHARSET.  If this environment variable is
not set, then the character set will  be  labeled  as “x-unknown”.

If  a  text  content  contains  only 7-bit characters and the
character set is not specified as above, then the character set will
be labeled as “us-ascii”.

This information probably is outdated, but generally it hits the
point, probably the code is already better (in respect to MM_CHARSET).


 BTW, I would suggest using isascii() rather than (*p  127 || *p  0).

I just kept what you once wrote. ;-P

But, yes, you are right.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 12:33] Jon Steinhart j...@fourwinds.com
 Still trying to understand this.  Decided to finally look at the code instead 
 of
 relying on my fading memory.

:-) Thanks.


 The existing code takes a non-ASCII message body and sends it as an attachment
 of type application/octet-stream.
 
 Your patch changes this behavior so that it is sent as type text/plain with 
 the
 appropriately chosen character set.

Both correct.

 In order to do this, you test the message body for non-ASCII characters in
 attach().  If you find any, you write an entry directly into the composition
 file instead of calling make_mime_composition_file_entry().

Correct.

 This is changing existing behavior if I understand it correctly.

Behavior in what gets generated, yes, but this is of need when fixing
things.

Examples for what gets generated from mail *body text*:

The old code generates ...

... for ASCII:

  Content-Type: text/plain; name=sendKi9x7j; x-unix-mode=0644;
  charset=us-ascii
  Content-ID: 4962.128958967...@argentina.foo
  Content-Description:   ASCII text 

  foo

... for non-ASCII (only if at least one attachment is present):

  Content-Type: application/octet-stream; name=sendbRaV8T;
  x-unix-mode=0644
  Content-ID: 5209.128958999...@argentina.foo
  Content-Description:   UTF-8 Unicode text 
  Content-Transfer-Encoding: base64

  d2l0aCBKb24


With my patch such MIME parts are generated ...

... for ASCII:

  Content-Type: text/plain; charset=us-ascii
  Content-ID: 5048.128958978...@argentina.foo

  foo

... for non-ASCII:

  Content-Type: text/plain; charset=UTF-8
  Content-ID: 5260.128959006...@argentina.foo
  Content-Transfer-Encoding: quoted-printable

  Umlauts: =C3=A4 and =C3=B6 and =C3=BC.


The function make_mime_composition_file_entry() gives us nothing but
information we don't need/want (temp file names, file permissions) and
it definately does not use the best possible CT and CTE for the body
text.


 This is fine
 with me provided that users must explicitly enable the change using an option.

An option to activate a fix???


 Now that I'm actually looking at the code, I would suggest an option
 (choose a better name) of binary-body-content-type.  You could change the
 make_mime_composition_file_entry() line
 
   content_type = binary ? application/octet-stream : text/plain;
 
 to replace the application/octet-stream with the option value, or the 
 existing
 value as a default if the option is not specified.
 
 A user wanting this behavior would have a profile entry of
 
   binary-body-content-type: text/plain
 
 I think that this would be a simpler code change that would accomplish your 
 goal.

Sorry, but I really think you don't get the point. We don't need
config options if we already have the facilities to do it right
automatically. Why should any user need to tell nmh what content type
to use for the text he writes? The mhbuild facility can already find
out which is appropriate. My patch also divides between mail text and
attachments for which different things are relevant. Your comment
above does this not and would then use binary-body-content-type for
any non-ASCII attachment also.

I read your mails and ask myself if you really read what I write and
if you have had a look into the code we are talking about.

I very much value the work you did for nmh and you see that this patch
bases on what you created, but now it may be to point to either have a
close look at the problem and code or step back and let other people
talk. I do think you don't understand the situation and the relavant
code good enough (presumably due to lack of time).

Of course, I may be wrong. Currently, however, it rather seems to me
as if it's not me who is not understanding the whole thing. I really
spent much time in the code and doing tests. And I did my best
explaining everything.


I ask other people to take a look and express their opinion.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Jon, sorry for the harsh mail. I really had been in rage. :-/

In a recent mail, you said:

 The current behavior was the best idea that I had
 at the time and nobody has said anything about it until recently.

I really don't blame you for what we have; quite the opposite: I am
very gretaful for what we have.



[2010-12-07 22:45] markus schnalke mei...@marmaro.de
 
 I ask other people to take a look and express their opinion.

Thanks to everyone speaking up.


meillo

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

Re: [Nmh-workers] SMTP/IMAP/POP Support

[markus schnalke]

[2010-12-03 09:09] ben+...@benjaminsummers.net
 What do people use SMTP/IMAP/POP features for?  Don't fetchmail and
 sendmail cover this?

You probably want to read this thread:
http://www.mhonarc.org/archive/html/nmh-workers/2010-01/msg00055.html

It explains the common thinking on the topic.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 18:48] Lyndon Nerenberg (VE6BBM/VE7TFX) lyn...@orthanc.ca
 
 And MH, by its very intent, is a highly flexible tool.  When you understand
 the value of its tool-based approach to handling mail, you'll realize that
 most of the functionality you want you can add yourself by writing shell
 scripts around the existing commands; there no need to add everyone's
 pet functionality into the core.

But you cannot switch to, in this modern email world, more appropriate
concepts this way. I'm thinking about MIME handling in general. Yes,
MIME support had been added back then, but nmh's concepts did not
change in respect to MIME. Probably a lot of stuff had been done
right, but some may not.

 Which isn't to say things don't need to be changed.  But the die-hard MH
 user community has been using this software for over two decades, and most
 of us are unimpressed by the Linux way of doing 'software development.'

Do you think that the then taken conceptual decisions will be correct
forever? One thing I learned from, what you call the Linux way of
doing 'software development' is that later you'll always know better
and hence you should change. Nothing remains the same.

Note that I do not declare that I know better than you how to do
everything, but I think about change and how better concepts could
look like.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 07:43] Jon Steinhart j...@fourwinds.com
 
 Sorry, seems like my comments offended you.  nmh is a community project.  To 
 me
 that means that anybody can propose things but those things are subject to 
 review
 by the larger community.  The result usually turns out to be better.  This 
 doesn't
 mean that your efforts aren't appreciated.  It helps to have a thick skin; 
 it's
 easy to get offended when people you've never met make comments.

Thanks. Yes, the thick skin is something I often lack.


 Maybe I don't understand your proposed changes.  Apologies if I get this 
 wrong;
 I didn't save a copy of your original email and the archives are currently 
 down.
 
 There are currently -attach options on send and whatnow to support the 
 non-standard
 attachment header.  I don't even think about this because my .mh_profile 
 includes:
 
   send: -alias aliases -attach X-MH-Attachment
   whatnow: -attach X-MH-Attachment
 
 My understanding is that your change would be to remove the -attach options 
 and to
 have the .mh_profile include something like this instead:
 
   attach: X-MH_Attachment

That's only the minor change I made (in order to enable any program to
take part without the need to add the -attach switch to all of them).
I did it because it reduces overall complexity and simplifies the
configuration (which currently is very complex; you can hardly use nmh
without spending weeks in setting everything up once).

This change, AFAIS, only breaks with the versions since you added your
attachment system and only in the way that the -attach switch is not
recognized. One hardly wants to define some non-standard attachment
header anyways, therefore my version adds a default one. The
attachment format needs to be specified differently if one likes to
change it.

Where compatibility does get broken is that my attachment system would
always be active, while your's by default would not. But that's the
crucial point!

As I said above, currently nmh can hardly be used (for modern emailing,
that people probably like to do) with the default setup. Everyone of
us, of course has his rather complex setup which does what he likes,
so you don't see this problem anymore. I needed about two month until
nmh had been well configured. This included Jerry Peek's book or
course, the man pages and the pretty old FAQ. I needed lots of time to
figure out all the stuff. You often don't know if it is broken or if
you just haven't found out where you need to configure what.

Hence I would like to see nmh do the most likely thing per default.
This for instance includes converting foreign charsets to the native
one on show. This also includes the definition of the attachment
header. I asked myself why a user or system administrator should need
to set it manually. I fould no answer besides some corner cases where
the behavior would change.

If no such header is present and all text is ASCII then the behavior
is the original.

If a header is present or non-ASCII is used then the message is
MIMEified. This very likely is what is intended.  For sending
non-ASCII text without MIME I don't know. My patch MIMEifies in any
case if it's non-ASCII.

Therefore my patch removes the need to run `mime' at the whatnow
prompt. Why does the user need to decide if he needs MIME or not?
Mostly he does not know an will MIMEify always. Then plain ASCII
messages are MIMEified too which is not necessary. My patch does the
more reasonable thing.

Further more it does not require the user to know about mhbuild(1)
directives and makes /^#/ non-special (that's what your system
provided). Running mime at the whatnow prompt to early had been a
pain too as one was not able to modify the draft later one. It also
removes the problems that can occure when mixing automimeproc:1,
/^#/-lines, and your attachment system. In fact, instead of having two
attachment systems, we only have one. It includes MIME forwarding too,
which seems to be only too logical.

Of course there still are problems which need to be solved. The two
mayor ones are:

(1) Less flexibility there are MIME structures that are not possible to
create. We should carely evaluate which ones are really needed and how
to access the full flexibiliy of mhbuild with the proposed system.

(2) MIME type guessing is very dumb. I'd like to see a system here
that works out-of-the-box, in order to avoid heavy configuration on
setup. Adding douzends of mhshow-suffix- lines in the profile appears
merely as a workaround. GNU file(1) provides -i which provides the
information needed, but this is not portable (actually SUSv3 requires
-i to mean something else).


 Here are my unfiltered thoughts on this; maybe seeing them you can craft a 
 more
 compelling rationale for your proposed change:
 
  1.  It doesn't fix anything because the current mechanism isn't broken.

It's not broken but it is still clumpsy from the user's perspective.

  2.  It doesn't simplify anything from a user perspective.

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 21:39] Jon Steinhart j...@fourwinds.com
 
 Sorry if I sound like an asshole here, but a while
 back the sending of attachments bugged me so I fixed it (without breaking
 anything).

I do believe that do did a very good work with your attachment system,
in fact it had been the inspiration and basis for my work.


meillo

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

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 23:21] Ken Hornstein k...@pobox.com

 And if your
 email provider goes to an IMAP solution, you'll get to a point where
 nmh simply won't work for you anymore unless you're really hardcore
 and willing to cook up a bunch of crazy solutions ... and those
 people are becoming rarer and rarer.

(This quote only as a general starting point. If you take IMAP as
working in the remote mail storage with IMAP commands, then nmh's
basic mail storage concept would likely need to be abandonned. But
that's a different topic.)

Although you don't like to hear it, moving from being a complete mail
system that tries to handle everything about email to an only MUA
would solve many future problems.


Let me tell a story:

MH had been a large and common company with good, active employees
(developers) and good business (relevance). It covered everything
people needed to do emailing; emailing had been quite easy then.

Later, as the work of the employees decreased and email became more
difficult to handle (both may be connected) MH's business got worse
but still had been good enough. Then nmh came and took over the work
with partly new and motivated employees. They worked hard on covering
all this new email stuff. This had been an improvement for the
business.

Now we're back at the same poiint. The employees are less and work
less while emailing became even more complex. The business is quite
low currently, actually most people don't choose nmh anymore, although
it tries to provide everything for emailing, they just cannot use it
for ``normal'' (= modern) emailing. That's really sad. Unfortunately,
sad gets us nowhere.

In business the situation is clear: A heavy change needs to take place
in order to save the company from dying. Free Software is a bit
different but many of the general principles are similar.

What companies would do: Strip all the parts of the firm that are not
the core business. Then concentrate on the core/niche and try to gain
relevance there again. If this goes well, the company can grow its
product portfolio again.


Emailing is so complex and nmh has only few active development. We
simply cannot keep up. We cannot still provide a whole emailing
system; we have problems in each part. Nmh falls back behind more and
more and the effort that we are able to do is too small because of the
large code base that we want to maintain with few development power.


Of course nmh can go along like it did, but how vivid will it be in
some years? Of course there exists a lot of projects with ancient code
in order to provide compatibility, but that's almost dead code. Next
generations will have read of it in their history books ... great!

I would understand if you some of you want to have nmh stay as it is
because that's all they need and all the kind of emailing they do and
will do for the rest of their life. But for the others, I really do
believe that we need to figure out how to go for the future. And that
might include general changes, maybe a fork. (I'm really thinking
about forking myself and developing an experimental version as a show
case.)


I am young and I have my life in front of me and I am enthusiastic to
develop Free Software and I do want to use nmh still in many years and
I do want to be able to tell friends to use nmh without adding that
the really need to be able to suffer hard if they want to try.


meillo


P.S.
I had been in emotion writing this. I do not want to put up all this
discussion that keeps you from developing. Though, it seems to me as
if we need to think about the future some day do. It will not happen
tomorrow or next week, but somewhen we're in the future, suddenly.

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

[Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

Hoi nmh community,

our relationship is a bit special. I came in February and it resulted
in a big discussion on MTAs and the like. I came again recently, had
been active, proposed improvements, but feel like running agains
walls.

The point is, we collide at any point. It's the community on the one
side and me on the other. At least this is how it feels to me. I
realize that my opinions and point of view is quite different from
your's (at least of those who speak up).

The main topic of our disagreement is compatibility. I like to point
this out here, quoting replies to my proposal:

Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
[2010-11-12 17:55] Jon Steinhart j...@fourwinds.com
 
 I have difficulty seeing this as enough of a savings to be worth breaking
 backward compatibility.  If you really have to do this then you should
 provide an upgrade script so that users don't get their stuff broken when
 they upgrade.

(On the former sentence, see below. On the latter sentence, I agree.)

Subject: Re: [Nmh-workers] MIME questions, and followup to my earlier email
[2010-11-12 19:50] Jon Steinhart j...@fourwinds.com
 
 On my earlier email, I guess that I'm unhappy that meillo is making changes
 that break things, even if those are minor things.  Comments on my proposed
 MIME-reading changes indicated that they should be optional for compatibility
 reasons.  I took that approach when I implemented the MIME-sending changes.
 I think that we should only break existing code for clear and compelling
 technical reasons.

It seems to me as if you would be doing compatibility for
compatibility's sake. This is sticking to old cruft. Caring to much
for some old userbase likely keep you from getting new users while old
ones slowly vanish. This also includes frontends. It is a dead end.

I value clearer and simpler solutions above compatibility in any case.
I understand the importance for compatibility in case of a backend,
but it should never be for it's own sake, but this is what I feel here
again and again.

Is nmh just good enough for you and therefore better not changed? Is
updating your setups once a year more effort than the improvements of
modernization? It could be and I would understand. The point is:

What is the goal of nmh?

That's what I don't understand. No matter what I try to do, I conflict
with you. This indicates that we probably have too different views of
nmh.


With pleasure I see the discussion of nmh2 which could finally be a
step in my direction. But before I cheer too much up, I'd better know:

What's the goal for nmh2, if it should come to happen?

Having the goals clearly stated would allow me to figure out if it's
worthwhile for me to try to add value to this community and project.
If someone has personal opinions on this subject, I welcome them too.

Nmh is clearly your project and not mine, besides being Free Software.
I don't want to sail in your waters if you don't like.


meillo


P.S.
In any way do I appreciate the new activity on the project. :-)

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

Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments

[markus schnalke]

I'm back.

[2010-11-13 11:31] valdis.kletni...@vt.edu
 On Sat, 13 Nov 2010 00:09:21 +0100, markus schnalke said:
 
  - I changed Jon's attachment system to get the attachment header name
  and format from the profile and not from command line arguments. This
  made the involved commands and functions less bulky because the values
  need not to be passed through all the time. It also makes this data
  avaliable to any program who ``likes to take part''. This alone I
  regard as an improvement.
  
  The new profile names are: `attachment-header' and
  `attachment-format'. (attach_fmt should likely be a char* too.)
 
 Wrong way to approach it.

No. I really think that my approach is the better one.

 What if exmh (which uses nmh under the covers)

Of course, the changes will break compatibility but for a saner
solution.

 wants to add 3 attachments to a note - one an image/jpg called 'fallout.jpg',
 an Excel spreadsheet called 'estimates.xls', and a Word document called
 'coverstory.doc'?  You *really* need to be able to specify the name, the
 mime-type, and possibly the mime-encoding of the attachment on a
 per-attachment basis.

This means every frontend for nmh needs to incorparate code to figure
out what mime type and encoding to use for any given attachment. This
truly is to be done by the backend. That's what my approach changes.

 If you don't specify mime-encoding, it must be
 intuited by looking at the mime-type (it's pointless to use anything other
 than base64 for an image/jpg, for instance), and possibly having to
 scan the attachment (a text/plain should be defaulted to no encoding
 if it's ascii, but will need quoted-printable if it contains the occasional
 non-ascii Latin chars, and may benefit from base64 if it's entirely in
 one of various non-Latin charsets).

I did mention that this part is still very poorly covered by my
proposal. But if it is once done in the backend, it's done for all.


You can't really (still) want to compose MIME parts manually, these
days? That's a task software can cover so let it do the programs.
Humans should write text (without special /^#/) and tell which files
to attach, the rest is up to the machine.


meillo

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

[Nmh-workers] [patch] snapshot of my MIME handling improvments

[markus schnalke]

Hoi,

I will be out of town for about ten days. Maybe I can read my emails
at times.

Before I go off, I like to share what I worked on the last two days.
It's neither cleaned up nor much tested. Please see it as code in
development. It may though be interesting for people who work on nmh
currently, for not doing the same work twice. (I'm looking at you
Peter. ;-) )


During the last week I thought a lot about how to do the MIME stuff
right. My studies of send(1) and Peter's mail with this thoughts were
the basis.

From my current knowledge I believe that Jon Steinhart's attachment
system (read docs/README-ATTACHMENTS) is the way to go for sending
MIME messages.

It can cover comp(1) and the MIME part of forw(1), and in fact any
other sending of mail because is sits in send(1). Peter already
pointed out that he believes that that's the right point for it.


What I did:

- I changed Jon's attachment system to get the attachment header name
and format from the profile and not from command line arguments. This
made the involved commands and functions less bulky because the values
need not to be passed through all the time. It also makes this data
avaliable to any program who ``likes to take part''. This alone I
regard as an improvement.

The new profile names are: `attachment-header' and
`attachment-format'. (attach_fmt should likely be a char* too.)

The -attach and -attachformat cmdline options of whatnow(1) and
send(1) vanished.


- The main change was done in uip/sendsbr.c:attach(). The message gets
now MIMEified if it has attachment headers or (this is new) contains
any non-ASCII character. Also handling of the body and forwarded
messages is done directly. Until now if the body contained non-ASCII
chars it would have gone as application/octet-stream if attachment
headers had been present. This is fixed. (The content-typing of
unknown attachments is still poor, but that's a different task.)


- In uip/forw.c the action of the -mime switch was changed. Instead of
inserting a mhbuild directive (#forw) it now inserts an attachment
header that looks similar to the #forw directive. Therefore I replaced
copy_mime_draft() with add_forw_hdr() which uses annotate(). The
header will get converted to a #forw directive in sendsbr.c. This
prevents /^#/ from being special, thanks to Jon's system.


- I updated parts of the man pages but not very carefully and not
well.


Notes:

The mime action of whatnow must not be used as it will collide with
send's MIME facility. Thus automimeproc should not be set. I think
whatnow's `mime' action should probably be removed then.

If one does not use attachments (Jon's system) and mails include
only ASCII chars then no MIME will be used and everything is like
it had been. If either one is used then MIME will be used, which
probably is what is wanted. (Peter pointed to the direction that
nmh should behave just reasonable.)

The space-tab-mixture of the indentation may be non-standard, by
accident.



You may test the patch if you like, but please see it as work in
progress. I publish it now because it's good to release often, also
now it's hot and I still know what I did ;-) . I very much like to
clean every thing up when I'm back.


meillo


Diffstats:

 config/config.c  |7 +++-
 h/mh.h   |2 +
 h/prototypes.h   |2 -
 man/send.man |   40 -
 man/whatnow.man  |2 -
 sbr/readconfig.c |2 +
 uip/forw.c   |   21 ++---
 uip/mhparam.c|2 +
 uip/send.c   |   31 +--
 uip/sendsbr.c|   86 ++-
 uip/viamail.c|2 -
 uip/whatnowsbr.c |   79 +-
 12 files changed, 101 insertions(+), 175 deletions(-)
diff -r f306353298cc config/config.c
--- a/config/config.c	Wed Nov 10 13:18:11 2010 -0300
+++ b/config/config.c	Fri Nov 12 20:02:06 2010 -0300
@@ -166,6 +166,12 @@
 char *mh_seq = .mh_sequences;
 #endif
 
+/*
+ * Default attachment header field name and attachment format.
+ */
+char *attach_hdr = X-MH-Attachment;
+int attach_fmt = 0;
+
 /* 
  * nmh globals
  */
@@ -365,4 +371,3 @@
  */
 
 char *msgprot = DEFAULT_MESSAGE_MODE;
-
diff -r f306353298cc h/mh.h
--- a/h/mh.h	Wed Nov 10 13:18:11 2010 -0300
+++ b/h/mh.h	Fri Nov 12 20:02:06 2010 -0300
@@ -299,6 +299,8 @@
  * their values and reloading the various modules, nmh will run
  * on any system.
  */
+extern char *attach_hdr;
+extern int attach_fmt;
 extern char *buildmimeproc;
 extern char *catproc;
 extern char *components;
diff -r f306353298cc h/prototypes.h
--- a/h/prototypes.h	Wed Nov 10 13:18:11 2010 -0300
+++ b/h/prototypes.h	Fri Nov 12 20:02:06 2010 -0300
@@ -162,7 +162,7 @@
 int distout (char *, char *, char *);
 void replout (FILE *, char *, char *, struct msgs *, int,
 	int, char *, char *, char *);
-int sendsbr (char **, int, char *, struct stat *, int, char *, int);
+int sendsbr (char **, int, char *, struct stat *, int);
 int what_now (char 

Re: [Nmh-workers] The test system does not install

[markus schnalke]

[2010-11-11 10:27] Josh Bressers j...@bress.net
 
 You either need to run make clean, or run it on a fresh checkout.

That is correct. When I did so, it went well.


meillo

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

[Nmh-workers] The test system does not install

[markus schnalke]

Hoi,

seems as if test systems, if they exist at all, aren't used regularly.
Because if they would, then people would have noticed that nmh's test
system is broken. I can't set it up. Too bad because I really wanted
to write some new tests. ;-)

If I understood correctly, it has to be done this way:

cd test
./setup-test

The output then ends with:

/usr/bin/install: cannot stat `scan': No such file or directory
/usr/bin/install: cannot stat `send': No such file or directory
/usr/bin/install: cannot stat `show': No such file or directory
/usr/bin/install: cannot stat `sortm': No such file or directory
/usr/bin/install: cannot stat `whatnow': No such file or directory
/usr/bin/install: cannot stat `whom': No such file or directory
make[1]: *** [install-cmds] Error 1
make[1]: Leaving directory `/tmp/nmh-test-zGqLqrdc/bld/uip'
make: *** [install] Error 1

The temporary test build directory /tmp/nmh-test-zGqLqrdc/bld contains
man pages and Makefiles, but no sources nor compiled files are there.

I don't feel able to solve the issue.


meillo

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

[Nmh-workers] [patch] slocal.man

[markus schnalke]

Hoi,

slocal.man misses a .TP line which the patch adds.

I also feel the need for a bit more description of the `destroy'
action. I would have added some myself but I don't use slocal and the
code is to complicated to gather enough knowledge in reasonable time.
It is surely different for people who have experience with slocal.

Questions that came to my mind, when reading this part:
- What does `destroy' really do? (The man page only says that it
  succeds.)
- Is `destroy' together with `R' a no-op?

Please add answers to the man page (maybe also to the example section)
if you knows about it. :-)


meillo
diff -r 7e963436013a man/slocal.man
--- a/man/slocal.manFri Nov 05 10:56:54 2010 -0300
+++ b/man/slocal.manWed Nov 10 19:05:45 2010 -0300
@@ -194,6 +194,7 @@
 .TP \w'qpipezorztzzz'u
 .I destroy
 This action always succeeds.
+.TP \w'qpipezorztzzz'u
 .IR file ,  mbox , or  
 Append the message to the file named by
 .IR string .
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] [patch] Exchange of MD5 implementation due to license

[markus schnalke]

[2010-11-05 21:43] Peter Maydell pmayd...@chiark.greenend.org.uk
 markus schnalke wrote:
 Could be that the license changed since then, because it reads:
 
  * This software was written by Alexander Peslyak in 2001.  No copyright is
  * claimed, and the software is hereby placed in the public domain.
  * In case this attempt to disclaim copyright and place the software in the
  * public domain is deemed null and void, then the software is
  * Copyright (c) 2001 Alexander Peslyak and it is hereby released to the
  * general public under the following terms:
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted.
  *
  * There's ABSOLUTELY NO WARRANTY, express or implied.
  *
  * (This is a heavily cut-down BSD license.)
 
 That just means that the license depends on whether your local
 jurisdiction thinks public domain exists and what deemed null
 and void means legally under local law. The author should just
 have put the thing under a reasonable license in the first place,
 then we'd know where we stood.

I had private conversation with Solar Designer. He said:

 Peter has a valid point, but:
 
 - Yes, the terms are conditional, but so what.  Peter does not show
 how this is a problem for their use of the code.  I think that it is
 not.
 
 - If they want unconditional BSD license, they can place their copy of
 my code under that, without having to ask me.  This is possible because
 it is a valid change in _either_ case.  It is valid if the code is in
 the public domain - because they can license it any way they like then
 -
 and it is also valid because the fallback license I provided is cut-down
 BSD.  So just remove the public domain part of my permission text.
 No GPL-like license virus here. :-)
 
 - I dislike including a copyright+license only, with no public domain
 option (for those who find it acceptable for their use/redistribution).
 This is because I dislike forcing people to list me as a copyright
 holder in their copyright statements for their larger products.


I don't want to push this too much because I understand that we cannot
work on all ends at the same time.


meillo

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

[Nmh-workers] packf: change of cur

[markus schnalke]

Hoi,

I read through uip/packf.c and came across this:

   177  if (mp-hghsel != mp-curmsg)
   178  seq_setcur (mp, mp-lowsel);

This sets the current message to the first message selected, unless
the last message was the current. This special case is not documented
in the man page.

What's the reason for this special case? I'd rather remove it than
update the documentation.


meillo

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

Re: [Nmh-workers] [patch] undo of install-mh (Debian bug #551704)

[markus schnalke]

[2010-11-05 22:34] markus schnalke mei...@marmaro.de

 A second try for removing only what install-mh(1) installs:
 
 ctx=${MHCONTEXT:-`mhparam context`}
 case $ctx in
 '/*') rm $ctx ;;
 *)rm `mhpath +`/$ctx ;;
 esac
 rmdir `mhpath +`
 rm $MH || rm ~/.mh_profile

I discovered another mistake in this code. Install-mh(1) always stores
the context as ``context'' within the mail directory. This simplifies
the work:

rm `mhpath +`/context
rmdir `mhpath +`
rm $MH || rm ~/.mh_profile


meillo

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

[Nmh-workers] [patch] undo of install-mh (Debian bug #551704)

[markus schnalke]

Hoi,

the attached patch tries to fix Debian bug #551704 [0].

[0] http://bugs.debian.org/551704

Knowing that a uninstall-mh command is surely impossible to create, I
extended the man page instead. I also fixed the CONTEXT section there.


meillo
diff -r 7e963436013a man/install-mh.man
--- a/man/install-mh.man	Fri Nov 05 10:56:54 2010 -0300
+++ b/man/install-mh.man	Fri Nov 05 15:11:47 2010 -0300
@@ -67,6 +67,39 @@
 been installed.
 This can be used by other programs to determine whether or not nmh has
 been installed without their having to know the internals of nmh.
+.PP
+.B Install-mh
+creates the following files:
+.PP
+.fc ^ ~
+.nf
+.ta \w'ExtraBigFileName  'u
+^nmh profile~^\fB$MH\fP or \fI$HOME/.mh_profile\fP
+^nmh directory~^\fI$HOME/Mail\fP or the path specified by the user when prompted
+^context file~^named \fIcontext\fP within the nmh directory
+.fi
+.PP
+(The user's home directory needs not to be $HOME.
+Here, this shortcut is used, although the user's home directory
+might have been determinded differently. See above.)
+.PP
+To undo the effects of
+.BR install-mh ,
+one needs to remove these files.
+ATTENTION:
+The nmh directory might have existed before the invocation of
+.B install-mh
+and thus may contain files not created by nmh.
+.PP
+In most cases the following commands will undo the actions of
+.IR install-mh :
+.RS
+.nf
+cd
+rm .mh_profile Mail/context
+rmdir Mail
+.fi
+.RE
 
 .SH FILES
 .fc ^ ~
@@ -85,7 +118,6 @@
 .fi
 
 .SH CONTEXT
-With
-.BR \-auto ,
-the current folder is changed to
-.RI \*(lq inbox \*(rq.
+The current folder gets initialized to
+.RI \*(lq inbox \*(rq,
+in the case of installation.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] [patch] improvement of folder man page

[markus schnalke]

Hoi,

I clarified the case in which the current message or folder change.
Please read over the new text; it still doesn't feel good enough yet.

Also changed the synopsis: s/msgs/msg/


meillo
diff -r 7e963436013a man/folder.man
--- a/man/folder.man	Fri Nov 05 10:56:54 2010 -0300
+++ b/man/folder.man	Fri Nov 05 16:39:30 2010 -0300
@@ -10,7 +10,7 @@
 .na
 .B folder
 .RI [ +folder ]
-.RI [ msgs ]
+.RI [ msg ]
 .RB [ \-all  |  \-noall ]
 .RB [ \-create  |  \-nocreate ]
 .RB [ \-fast  |  \-nofast ]
@@ -169,10 +169,17 @@
 .BR \-norecurse )
 or list all sub-folders under the current folder recursively (with
 .BR \-recurse ).
-In this case, if a
+.PP
+If
 .I msg
-is also supplied, it will become the current message of
-.IR +folder .
+is supplied, together with
+.IR +folder
+or without
+.BR \-all ,
+it will become the current message of
+.IR +folder
+(if it had been supplied)
+or the current folder.
 .PP
 The
 .B \-recurse
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] [patch] undo of install-mh (Debian bug #551704)

[markus schnalke]

[2010-11-05 20:46] Peter Maydell pmayd...@chiark.greenend.org.uk
 markus schnalke wrote:
 the attached patch tries to fix Debian bug #551704 [0].
 
 [0] http://bugs.debian.org/551704
 
 Knowing that a uninstall-mh command is surely impossible to create, I
 extended the man page instead. I also fixed the CONTEXT section there.
 
 Well, you could undo the effects:
  * if there's no profile file, we're not installed anyway
  * if there is, then it will tell us where the Mail
directory is

That's the point I missed.

  * so rm -rf Mail (with a big fat warning!)
  * and delete the profile file
 
 In fact (modulo the warning and checking we were installed in
 the first place!) it's a shell one-liner:
rm -rf ${MH:-~/.mh-profile} $(mhpath +)

(The tilde does not get expanded this way.)

This assumes that $MH and $MHCONTEXT are still the same. Seems as if
we always need to assume this.

But yes, you are right that it's not as impossible as I thought. Also
I didn't realize that it is very clever to use nmh's own tools as
helpers.  *shame*


 I'm not totally sure we want to provide an easy way for
 the user to blow away their mail, though :-)

We should at least not remove any mail.


 However, if you're going to document in the manpage
 how to clean things up you should document the
 correct way that doesn't rely on assumptions about
 the directory name and so on. 

Right.

A second try for removing only what install-mh(1) installs:

ctx=${MHCONTEXT:-`mhparam context`}
case $ctx in
'/*') rm $ctx ;;
*)rm `mhpath +`/$ctx ;;
esac
rmdir `mhpath +`
rm $MH || rm ~/.mh_profile

Or do you think we should only provide prose text?


meillo

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

Re: [Nmh-workers] [patch] Exchange of MD5 implementation due to license

[markus schnalke]

[2010-11-05 21:01] Peter Maydell pmayd...@chiark.greenend.org.uk
 markus schnalke wrote:
 Attached is a patch which exchanges the reference code with the public
 domain implementation of the RFC by Solar Designer of the Openwall
 project [1].
 
 I'm not sure there's much point replacing one MD5 function with
 a theoretically questionable license with another one which also
 has a theoretically questionable license. See
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293932#85
 and responses and note that public domain is a rather US
 specific idea.

Could be that the license changed since then, because it reads:

 * This software was written by Alexander Peslyak in 2001.  No copyright is
 * claimed, and the software is hereby placed in the public domain.
 * In case this attempt to disclaim copyright and place the software in the
 * public domain is deemed null and void, then the software is
 * Copyright (c) 2001 Alexander Peslyak and it is hereby released to the
 * general public under the following terms:
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted.
 *
 * There's ABSOLUTELY NO WARRANTY, express or implied.
 *
 * (This is a heavily cut-down BSD license.)


meillo

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

Re: [Nmh-workers] Fixing decoding of quoted messages in replies

[markus schnalke]

[2010-11-05 21:27] Peter Maydell pmayd...@chiark.greenend.org.uk
 
 So send should: 
  * check for non-ASCII characters
  * when present: pick an encoding (first usable one from
 a user-configurable list like us-ascii,iso-8859-1,utf-8)
  * encode body and headers as per MIME, adding MIME headers
to match

Just one quick thought: What about signed and encrypted messages?
Where and how would this be done and would it interfere?


meillo

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

Re: [Nmh-workers] cleaning out the cobwebs

[markus schnalke]

[2010-11-03 10:07] Jon Steinhart j...@fourwinds.com
  While reading much nmh code these days, I also feel that parts of the
  code are ancient. I'd like to support any effort in renewing it.
  
  Autoconf is something I dislike.
 
 I suppose that I'm willing to do some work here too if I'm not alone.

Great! I'm at your side. :-)

About my time: I have free time until Christmas, which I put into the
quoted reply thing, as already announced. Then I'll travel again and
will be offline until April. From April until summer I like to work on
nmh again, besides my studies.


 My main
 interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is
 really doing and rewrite it so that I can add additional functionality without
 breaking anything.

How performance optimizations haunt you after so many years ...


 The functionality that I want to add is better handling of attachments.  Even
 though there have been some complaints long after the fact, I think that my
 code that simplified sending attachments was a success.  But, it's my opinion
 that receiving attachments still needs work.

The current attachment approach collides with running `mime' on the
whatnow prompt. But this is only one other problem originating in the
approach that was taken to implement MIME support.


 And I really don't like what happens when I show a
 message with a lot of attachments and they keep on popping up even though I 
 want
 to move on to the next message.

I'd like to have show(1)/mhshow(1) redesigned. The programs should be
merged when MIME support is not something sitting on top anymore. IMO
show(1) should per default display:
- for non-MIME: the whole message
- for MIME: the first text/plain part and the output of mhlist(1)


 I'd like an option to scan that would give me
 something like this:
 
 590110/28 X XXX  Re: Coming down your way soonBoob cancer. 
 Prog
 590410/28 XXX XX FW: 
 Hallowe'en2010--_000_1D0D56EB54ECF6428182E
 590610/29 X XXX  Re: Coming down your way soonThanks. I am 
 doin
 5907+   10/29 XXX X  Election editorial 
 cartoons--Apple-Mail-19-856
  .1   text/html  I decided to stick to just one topic, since 
 the
  .1.2 image/gif  JGPfwdtoon.gif
  .1.3 image/jpg  Lukovich - election 2010.jpg
  .1.4 image/jpg  Kirk GOP no solutions-1.jpg
  .1.5 image/jpg  Luckovich - Money - Republicans - Obama.jpg
  .1.6 image/gif  toles - Public voted out.gif
  .2   text/plain I decided to stick to just one topic, since 
 the
 590810/30 X XX XX  Re: 2010 bring a friendOn Sat, Oct 30, 
 2010 at

I, in contrast, would like to have scan(1) only work on message
headers and not deal with any body data. This could ease things as
more clear separations (which tools deal with files, headers, body
(=MIME)) could be made.


 I'd then like the ability to do something like
 
   show 5907.1.2
 
 or maybe if 5907 is the current message just the ability to do something like
 
   show .1.2

I agree.

Currently MIME support is just put upon MH. IMO we should fully
integrate MIME into nmh. This would remove several ugly (nonintuitive)
parts.


 Then, I'd like the ability to do something like
 
   next -part

Here I'm not so sure. Because we would have three states then: folder,
msg, and part. But I'm not decided on this yet.


 Let me know what you think.  I don't want this to be like the attachment 
 sending code
 where nobody had anything to say until a few years after it was done and then 
 started
 complaining.

:-)


 Again, the stumbling block here is m_getfld.c and my not wanting Van 
 Jacobson, his
 children, and my children cursing me as per the comments.

I don't want to blame Van Jacobson, as this might had been a very
valuable improvement back then. The point is simply that the
optimization drove m_getfld.c into a dead end for further development.
Perhaps it's best to start with the code before he optimized it and
track the changes since.


 Separate from the above, I would like to see as much as the pre-Posix 
 gratuitous
 stuff removed from sbr.  It's fine with me if going forward, new versions of 
 nmh
 only run on Posix-compatible systems.

I think a lot about all this these days. The difficulty is always the
compatibility.


 I too am a hater of autoconf/automake;  I
 like elegance, not the ugliest sledgehammer in existence.  That said, I'd 
 rather
 use these than create new ones.

Many alternative approaches have their problems too. I like best how
it is done by the suckless project [0] and the heirloom tools [1].
This involves a bit of manual configuration but saves a lot of
complexity therewith.

[0] http://suckless.org
[1] http://heirloom.sf.net


 In my mind, the best way to start a clean-up project is for people to go into 
 the
 existing code and add good comments.

In the view of usability for developers, 

Re: [Nmh-workers] cleaning out the cobwebs

[markus schnalke]

[2010-11-03 11:05] Lyndon Nerenberg lyn...@orthanc.ca
 
  Again, the stumbling block here is m_getfld.c and my not wanting Van 
  Jacobson, his
  children, and my children cursing me as per the comments.
 
 The day of the VAX is long gone, and with it, the need for this sort of
 bowing down to the necromancer.  When a piece of code gets this
 disgusting the best path forward is to throw it out and rewrite it.

 Here we disagree.  It's a waste of time commenting code that's just
 going to be ripped out.

Have you had a look into m_getfld.c?

Quoting: ``This module has a long and checkered history.''

Doesn't seem as if the code was so easy to write the first time. It
probably will not be the second time.


meillo

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

Re: [Nmh-workers] Fixing decoding of quoted messages in replies

[markus schnalke]

[2010-10-26 19:18] Peter Maydell pmayd...@chiark.greenend.org.uk
 markus schnalke wrote:
 during the next weeks I intend to fix the annoying problem of still
 encoded message text in quoted replies.
 
 That would certainly be a cool thing to have working.

I'm still becoming familiar with the code base, in order to find out
how everything works and how to do it in a fairly good way.


 You might be interested in this:
 http://www.mail-archive.com/nmh-workers@nongnu.org/msg01508.html

The referenced mail helped a lot, thanks.


 Basically there are a number of intertwined problems. My major
 concern would be that in fixing de-encoding when composing
 replies we don't accidentally paint ourselves into a corner
 for the UI/config settings for getting the larger issues right.

Right.


meillo

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

Re: [Nmh-workers] Fixing decoding of quoted messages in replies

[markus schnalke]

[2010-10-31 19:22] Ralph Corderoy ra...@inputplus.co.uk
 
 I was thinking of a scan(1) replacement that would colour-code the
 results, if I wanted.

You can do this by piping the output through a highlighter program, or
even by using a customized format file for scan.

 To begin with, I'd be happy with configuration
 being in Python.

I hope you don't find supporters for that. ;-)

 And then an mhshow(1) that assumes a UTF-8 terminal
 and converts headers and body to that for one seamless less(1)

It should surely not assume anything but find out (MM_CHARSET) what is
wanted. Also not less(1) but moreproc.

But on the seamless output, I agree.

 instance
 without a Press return to show content... prompt.

-nopause fix that, or?


meillo

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

Re: [Nmh-workers] Fixing decoding of quoted messages in replies

[markus schnalke]

[2010-10-26 21:03] Oliver Kiddle okid...@yahoo.co.uk
 markus schnalke wrote:
 
  (1) Showing messages with different charsets requires a line like
  mhshow-charset-iso-8859-1: iconv -f iso-8859-1 | %s
  in the profile if your terminal is on UTF-8. It might be worth to
  include such processing directly into nmh in order to make it more
  usable out-of-the-box. Iconv is already available (if compiled in).
 
 That would be good but you lose some flexibility. In some cases, I use
 the //TRANSLIT option on iconv. Also, I actually treat iso-8859-1 as
 windows-1252 because mails from Windows systems are sometimes
 incorrectly identified as iso-8859-1.

mhshow-charset- entries should have precedence, of course. Then
everything would be like now but text in foreign charsets gets
converted to the native charset if nothing else is said.


meillo

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

Re: [Nmh-workers] vmh

[markus schnalke]

As we are at front ends.

During a web recherche I also found vmail, which is:
Copyright  1987  J. Zobel, j...@mulga.oz.au

You can fetch it as shar from:
http://cd.textfiles.com/itools/MAIL/MH/VMAIL/

But it seems it needs some effort to get it built.


meillo

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

Re: [Nmh-workers] cleaning out the cobwebs

[markus schnalke]

[2010-11-01 20:57] Lyndon Nerenberg (VE6BBM/VE7TFX) lyn...@orthanc.ca
 The JLR question prompted me to take a quick scan through the code
 base.  A lot of the conditional compilation is leftover from the pre-
 or early-POSIX days (e.g.  string and network related functions that
 are now standardized), SMTP client hacks that are no longer
 applicable, and support for obsolete features (e.g.  KPOP).
 
 At the least I think it's worthwhile to make a pass through the
 source, eliminating the HAVE_* conditionals that are no longer
 necessary in the age of ANSI/POSIX.  It's also long overdue to clean
 up the SMTP client code to bring it into line with the current port
 587 submission regime.  Between the two I think we can get most of the
 way towards no longer depending on autoconf, which would be a big win
 for those of us building the code on lighter-weight hardware and OSes.

While reading much nmh code these days, I also feel that parts of the
code are ancient. I'd like to support any effort in renewing it.

Autoconf is something I dislike.


 I have the tuits to do this, as it relates to a work project for which
 I'll have to do it anyway.  Game?

(Could you explain ``having the tuits'', please.)


meillo

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

[Nmh-workers] JLR

[markus schnalke]

Hoi,

just one question for better understanding:

Who or what is ``JLR''?

There are several #ifdefs for JLR in code which is related to scan(1).
There is also a comments which appears to be written by JLR and
docs/ChangeLog_MH-3_to_MH-6.6 lists changes done for JLR.


meillo

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

[Nmh-workers] packf: asks user on file creation

[markus schnalke]

Hoi,

for becoming familiar with nmh's code base I read a lot of code, today
also uip/packf.c .  packf(1) asks the user for confirmation if the
output file is to be created but appends non-interactively if it
already exists.

Why is the behavior such?

What are the reasons behind the confirmation question on creation? I'd
rather have the question for appending to an existent file. But best
would be to be completely non-interactive, which is the Unix way to do
things, or am I wrong?

If the reason is to know where the file went, printing a message would
be enough.

The relevant code is uip/packf.c:114-125:

/*
 * Check if file to be created (or appended to)
 * exists.  If not, ask for confirmation.
 */
if (stat (file, st) == NOTOK) {
if (errno != ENOENT)
adios (file, error on file);
cp = concat (Create file \, file, \? , NULL);
if (!getanswer (cp))
done (1);
free (cp);
}

Actually, the comment is at least unclear, due to the words in
parenthesis.


Comments?


meillo

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

[Nmh-workers] Paper and talk about the Unix Philosophy

[markus schnalke]

Hoi,

about a week ago, I asked you to take a look on my draft version of a
paper on the Unix Philosophy. It is finished now.

I want to thank you for your comments, which improved my paper and my
understanding of the topic.

You find the final version on my website:
http://marmaro.de/docs/studium/unix-phil/

There is also a talk I did on the topic at the local CCC, in March. It
was video and audio recorded. The slides are in English, but I spoke
in German.
http://marmaro.de/docs/chaosseminar/unix-phil/
http://ulm.ccc.de/ChaosSeminar/2010/03_UnixPhil/

I hope you enjoy the stuff.


meillo


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

[Nmh-workers] Please proof-read chapter about MH/nmh

[markus schnalke]

Hoi,

I wrote a term paper about the Unix Philosophy. It includes a chapter 
with a case study of MH/nmh. Could you please have a look at it and 
check if it contains faults. I need your comments by the end of the 
week.

http://tmp.marmaro.de/unix-phil_draft.pdf


meillo


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

Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)

[markus schnalke]

[2010-01-27 18:01] valdis.kletni...@vt.edu
 On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said:
  TLS seems to be already solved. However, why does nmh need TLS?
  Doesn't it delegate mail transfer to an MTA?
 
 You may need it to talk to a remote MTA that insists on doing TLS.  And
 there's valid use cases for it.
 
 Half the time my laptop is at home, so letting my local sendmail do the
 delivery isn't workable, lot of sites whinge at the fact that it's a 
 cablemodem
 address. So if I want my mail delivered, my easiest is to forward through the
 MTA here at work.  And it was easier to just tell nmh to forward rather than
 have it point at the local sendmail and reconfig that to forward.

Use a simple forwarding MTA (like nullmailer or ssmtp) instead.

Instead of having one program inside nmh to forward, use one external
program to forward. The external program will surely do the job better
than the internal one. (Do you need reasons for this statement?)

For the user, shipping an own forwarder is not much different than
providing a good tutorial on how to use an external program for the
job. And if it is a problem, then this user is hardly a user of nmh
anyway.


meillo


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

Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?

[markus schnalke]

[2010-01-28 10:39] Ken Hornstein k...@pobox.com
 
  And as for it being _easier_ ... well, literally, configuring the SMTP
  MTS is as simple as placing this in your .mh_profile:
 
 I personally, don't care much about easy, but I care about right.
 (Especially, as this is what nmh does better as any other MUA.)
 
 My response to this is twofold:
 
 - Right is an extremely nebulous term, and you've basically proclaimed
   that not having nmh submit messages via SMTP is right, somehow,
   without providing really any justification for this point (Do one
   thing and do it well ... you could interpret that a hundred different 
 ways).

Interpret it as it is done by the tools of the Unix toolchest. (Not
the GNU utils but the ones from Bell Labs.) You know ``cat -v
considered harmful'' [0] ?

[0] http://harmful.cat-v.org/cat-v/

If not, read it!

My ``right'' is what (I think) the Unix Philosophy tells.


 - Nmh isn't just some exercise in architectural purity, right?  We _want_
   more people to use nmh, to contribute to it and expand it's use, right?
   We don't want to make things _harder_ for users, do we?

I agree that making it harder for users to switch to nmh is bad.
But why should a users switch to nmh if he wants it just to be easy?
He'd take some monolithic MUA instead.

Nmh enables users to do some things better than possible with other
MUAs. This mostly results from nmh's one-tool-for-one-job approach. I
think there are places where we can go one step further. Then we might
gain possiblities we do not think of yet.

Have you read ``The Cathedral and the Bazaar''? Especially the part
when esr realized he could make it simpler by speaking only one
protocol, is interesting [1].

[1] http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html


 Fetching mail is also the job of a different tool.
 
 So, just so we're clear ... you want to remove the existing support for
 POP in inc as well?

I think it would be better to not have it, yes.

BUT:

This is what I personally think about it. I *really* don't plan to
change all that stuff in an gsoc project.

It's much more your software than mine (no matter that it's free).  I
know that you are miles ahead of me. I will *not* tell you what you
have to do.

What I try, however, is to show you a point of view, you might not
have taken. It may seem extreme, but Unix itself is extreme. In the
end, most stuff I tell you bases on what I read in books like:

- Ganzarz: ``The Unix Philosophy''
- Brooks: ``The Mythical Man-Month''
- Kernighkan  Pike: ``The Unix Programming Environment''
- Kernighkan  Pike: ``The Practice of Programming''
and similar literature

These are not my ideas, these are the ideas of very clever people.


 ``Write programs to work together.''
 
 Okay, nmh consists of many programs that work together, but nmh should
 not strive to be self-contained. Don't let the NIH syndrome rule!
 
 Nmh should work on a mailbox in the local filesystem. Incoming mail
 should enter as plain-text through inc. Outgoing mail should leave as
 plain-text to an MTA.
 
 I understand the toolbox approach, but I don't actually see the problem
 here.
 
 In my mind, the power of nmh is that you have (relatively) simple,
 individual shell commands that each perform a specific task, rather
 than one monolithic interface.  But the backend details of how they
 perform those tasks?  Not really that important to me.

From the user's POV, I agree that nmh is very nice. But conceptionally
it could be improved, I think.

You might say, that ftp is nicely handled under Unix. I would have
agreed, just a few years ago. But when you met Plan9 and see how they
simply mount the external storage, via an ftp layer, into the
filesystem, then you can never want the ftp command back.


 inc brings messages from some external mail store into nmh.  Sure, it
 can work on a local file, and that might have been good enough ... 20
 years ago.  But nowadays the standard has moved toward retrieving your
 messages via POP or IMAP.  Sure, you _could_ have some external tool
 perform this mail retrieval operation ... but really, what are you
 gaining here?  Clearly the original designers of MH didn't see any
 reason to force the use of an external tool ... they saw no problem
 with POP support in inc.  The idea that somehow POP support in inc
 violates some basic MH design philosophy is completely ridiculous.

It violates the Unix Philosophy: Do one thing, and do it well!

Inc might do the POP stuff not badly, but it would be better done it a
tool which does only POP retrieval. If you can concentrate on one
thing, you will do it better, than if you concentrate on two things.

You say, emailing has changed through the years. Thus inc needed to be
improved to to authentication or whatever. Send needed also to be
improved. If these improvements would not have been done, then nmh
would be usable anymore.

But if nmh (that means MH) would have always communicated to the
outside 

Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)

[markus schnalke]

[2010-01-28 10:43] Ken Hornstein k...@pobox.com
 Instead of having one program inside nmh to forward, use one external
 program to forward. The external program will surely do the job better
 than the internal one. (Do you need reasons for this statement?)
 
 Actually, you're going to have to provide some reasons ... I looked at
 the examples you provided (nullmailer and ssmtp), and they lack
 functionality that nmh provides, today (that's not to say that nmh
 can do everything those programs can, but my point is that nmh can
 do things that they cannot).

I just took two programs that came to my mind.

If nmh's mail forwarding code is good, then it might be worth to
exclude it into a standalone program, and have it as a dependency for
nmh (just like some library).


 And I guess I really don't understand
 your fundamental reasoning about external programs always being better
 than an internal one.

As I wrote in the other mail: I assume that you will do one job at a
time always better than two jobs at the same time.


 For the user, shipping an own forwarder is not much different than
 providing a good tutorial on how to use an external program for the
 job. And if it is a problem, then this user is hardly a user of nmh
 anyway.
 
 So, you don't care about unsophisticated users, then?  You need a certain
 level of Unix configuration knowledge to use nmh?

Unsophisticated users will install nmh with a packaging system. Then
the appropriate external tools get installed automatically.

If one likes to install nmh from source, then the dependency on an
external tool is like the dependency to an external library.


meillo


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

Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)

[markus schnalke]

[2010-01-28 09:48] Michael Richardson m...@sandelman.ca
 
  markus == markus schnalke mei...@marmaro.de writes:
 markus Use a simple forwarding MTA (like nullmailer or ssmtp)
 markus instead.
 
   okay. That would work for me.
   The work would still be there to essentially:
   a) rip out everything else.
   b) adjust packages such that nullmailer/ssmtp is a dependancy.

Yes.

Note, that I don't think that it is good to do this within a day.
Changes need time. But generally, this is what I think is good.

   c) provide an interface to collect the user's various
  relay authentication tokens and configure said mailer.

The needed data for the configuration would be not different from what
is needed for the nmh send facility. One needs to write a different
file in a different format.


   We have several graphical MUAs that sit on top of it, and I'd like to
 see more of them, not fewer.  I do not want thunderbird and all the like
 to have to reinvent everything.

But nmh reimplements functionality that is already available in other
software (e.g. MTA), that could be used.

I'm not quite sure, maybe you mean the transition problems. The
``user'' interface of nmh would not change, thus tools on top of nmh
don't need to change. The nmh package would depend on an external tool
(like if it would depend on an external library).


meillo


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

Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?

[markus schnalke]

[2010-01-28 10:28] Earl Hood e...@earlhood.com
 On January 28, 2010 at 10:55, markus schnalke wrote:
 
  Nmh should work on a mailbox in the local filesystem. Incoming mail
  should enter as plain-text through inc. Outgoing mail should leave as
  plain-text to an MTA.
 
 Not sure about this statement, especially plain-text.
 
 MH was written at a time when security considerations were
 not given much thought.  I think TLS support for submitting
 email to an MTA has become more of an essential function
 of MUAs (and the common GUI-oriented MUAs do support this).

I talk about the transfer from nmh's send command to
/usr/sbin/sendmail for example. That means from one local command to
another local command via a pipe. There is no network involved.

The local MTA will then care about encryption and authentication for
the transfer over the network.


 I'm not sure it is safe to assume that someone is able
 to install and run a third-party program on their local
 system to work as a secure submission proxy for nmh.

See it as dependency to the nmh package, like a library.


However, I don't want to discuss against you on how exactly to realize
this. You could probably tell me better. But I want to tell you, that
you should *freely* think about it.

Currently, I mostly hear: ``No it can't be done''.

Doing unusual things is always hard, but nmh is unusual too, and we
all love it because of that.

(Read the SMTP-only decision in ``The Cathedral and the Bazaar''!)


meillo


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

Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)

[markus schnalke]

[2010-01-28 10:37] Earl Hood e...@earlhood.com
 On January 28, 2010 at 11:04, markus schnalke wrote:
 
  Use a simple forwarding MTA (like nullmailer or ssmtp) instead.
 
 IIRC, ssmtp is a command-line replacement of sendmail vs
 running as a daemon.  MH/nmh communicate with sendmail via
 the -bs option, something ssmtp does not support I believe.
 
 I have not looked at nullmailer.  First I've heard of it.
 Does it support -bs mode of sendmail?  Can it run as
 a daemon and accept SMTP connections directly?

-bs mode was what I would like to avoid because this is where SMTP is
involved. Piping the mail (= the output of `list' in the whatnow
prompt) to /usr/sbin/sendmail (= the compatibility interface) is what
I would prefer.


meillo


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

Re: [Nmh-workers] nmh @ gsoc?

[markus schnalke]

Thanks for the many responses and active discussion.


I agree that MIME support should be improved. For people in
non-English speaking Countries, like me, bad MIME handling is a big
argument against nmh. But also the point of how to handle attachments
in replies should be worked on.

Also, threading is a main point. This must fit into the existing
design.

Hooks (or scripting support) might be a good point too. I can't decide
for me yet. At least, one should give it a try.


TLS seems to be already solved. However, why does nmh need TLS?
Doesn't it delegate mail transfer to an MTA?

IMAP is surely of interest. But I think this should not be the job of
nmh, but of a FUSE layer below, as some already said. There might not
be the danger of too many storage backends, but conceptional, such
stuff does not belong into a MUA. (Because I don't use IMAP, this
would probably not be a good job for me.)


Lyndon said that nmh does not need someone like me to work on it.
Don't get me wrong, I surely don't want to add lots of features. I
don't want to break stuff. I don't think nmh should be changed. In
contrast, I think nmh is great like it is, but there are always things
to work on. This shall be work to support nmh, not to change it or to
blow it up. Nmh bases on the Unix Philosophy -- I am convinced that
this is the right way to design good software.

The development on nmh slowed down much, but nmh is not dead. There
might be few users, but the idea behind nmh is great ... and nmh is
the only MUA to follow this idea. That alone is reason enough.

I see a big chance for nmh in gsoc. Why not go for it?


Appying under NetBSD's umbrella is surely a good way to go. Being an
own mentor organization might make it more difficult to get accepted.
But why not, if there is someone who cares for a good application? In
any case, you have to provide descriptions, a roadmap, a goal, a
vision and similar stuff. Maybe someone has experience.


meillo


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

[Nmh-workers] nmh @ gsoc?

[markus schnalke]

Have you thought about applying for Google Summer of Code 2010?

If you do, I am interessted in working on an nmh task.

I am using nmh since October last year as sole MUA (switched from
mutt). For a great fan of the Unix Philosophy, this was a logical
step, in the end. It would be great to support the nmh project in the
framework of gsoc.


meillo


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