Re: nmh and diary-mail-entries
Arthur wrote: > Using OpenBSD -current and emacs-29.4 I am trying to get > diary-mail-entries to work. What I get is: > > post: no mailbox in address, only a phrase (July 21,) July 21, continuing... > Sunday: loses; [USER] 550 Invalid recipient: > 2024: loses; [USER] 550 Invalid recipient: <2...@eddie.fios-router.home> > post: 1 address unparsable, 2 addressee undeliverable > send: message not delivered to anyone > > I am wondering if this could have anything to do with nmh moving from > 1.7 to 1.8 as diary-mail-entries worked at one time in the distant past. Perhaps. Can you send messages to the recipients listed in the error message above? David
Re: folders which are numerical names
George wrote: > That would be great. commit da1e630f2c0d6196d949b99b35f5a0771e9cdb3b Author: David Levine Date: Sat Jul 6 07:56:33 2024 -0400 Added message number to scan "botch" error message. Formatted it as "scan() botch (%d) attempting to read `%d'" to be consistent with other error messages. David
Re: folders which are numerical names
That would be great. G On Mon, 1 July 2024, 22:35 Ken Hornstein, wrote: > >Hi David, > > > >> How about this simple addition to identify the offending directory: > > > >Passes the ‘First, do no harm’ test. +1. > > Also +1 from me. > > --Ken > >
Re: folders which are numerical names
>Hi David, > >> How about this simple addition to identify the offending directory: > >Passes the ‘First, do no harm’ test. +1. Also +1 from me. --Ken
Re: folders which are numerical names
Hi David, > How about this simple addition to identify the offending directory: Passes the ‘First, do no harm’ test. +1. -- Cheers, Ralph.
Re: folders which are numerical names
Ralph wrote:
> We report the problem better in other cases.
Agreed.
How about this simple addition to identify the offending directory:
diff --git a/uip/scan.c b/uip/scan.c
index 00992b3d..80846630 100644
--- a/uip/scan.c
+++ b/uip/scan.c
@@ -224 +224 @@ main (int argc, char **argv)
- die("scan() botch (%d)", state);
+ die("scan() botch (%d) attemptimg to read %s", state,
fnp);
@@ -347 +347 @@ main (int argc, char **argv)
- die("scan() botch (%d)", state);
+ die("scan() botch (%d) attemptimg to read %d", state,
msgnum);
That would report a directory named 33 as follow:
scan: unable to read: Is a directory
scan: scan() botch (-3) attemptimg to read 33
David
Re: folders which are numerical names
Hi Ken, > This happens because open() failing is considered a "soft" error and > scan will continue, but read() failing is considered a hard error. > I'd be willing to consider read() failing with EISDIR a soft error. > Thoughts from others? It compounds the flaws. The original one was not barring an all-digit filename from being a folder. Code just didn't check as much back then. We should state what makes a wise folder name, e.g. /^[[:alpha:]][-_[:alnum:]*$/ in the user's locale. We report the problem better in other cases. $ td /home/tmp/1719392294.254317947 $ cp `mhpath .` 1 $ scan +. 1 24-06-26 Ken Hornstein Re: folders which are numerical names >I'm w $ mkdir ,1 $ rmm 1 rmm: unable to rename 1 to ,1: Is a directory, continuing... $ scan 1 24-06-26 Ken Hornstein Re: folders which are numerical names >I'm w $ mv 1 ,1 $ scan scan: no messages in /home/tmp/1719392294.254317947 $ scan @,1 1 24-06-26 Ken Hornstein Re: folders which are numerical names >I'm w $ -- Cheers, Ralph.
Re: folders which are numerical names
>I'm willing to bet if I look back in the prior 3 decades I'll find myself >asking the same question and the infrequency of it bugging me, is a strong >indication of how (un)important it is. > >maybe I'd move my marker and ask if it could become a "soft" error on scan: > >% ls -F | sort -n | tail -5; >586 >587 >588/ >589 >590 >% scan +sent >... > 584 2024/06/17 To:Leo Li > 585 2024/06/18 To:APNIC Office > 586 2024/06/18 To:Dan Fidler > 587 2024/06/18 To:Joao Damas >scan: unable to read: Is a directory >scan: scan() botch (-3) This happens because open() failing is considered a "soft" error and scan will continue, but read() failing is considered a hard error. I'd be willing to consider read() failing with EISDIR a soft error. Thoughts from others? --Ken
Re: folders which are numerical names
Hi George, > So I work around it by having archives like sent/y2021 and it works > fine. I have sequences for years within a folder, e.g. y98, and y24. They have to have a prefix to avoid clashing with message numbers as sequences don't have a sigil whereas folders have ‘+’ or ‘@’. But even if context or something else meant I could drop the ‘y’, I'm not sure I would as it's a clue to the reader than 98 isn't a message number. So I wonder if you should move to prefixing with ‘y’ more widely to give consistency; then the difference wouldn't niggle. :-) -- Cheers, Ralph.
Re: folders which are numerical names
I'm willing to bet if I look back in the prior 3 decades I'll find myself asking the same question and the infrequency of it bugging me, is a strong indication of how (un)important it is. maybe I'd move my marker and ask if it could become a "soft" error on scan: % ls -F | sort -n | tail -5; 586 587 588/ 589 590 % scan +sent ... 584 2024/06/17 To:Leo Li 585 2024/06/18 To:APNIC Office 586 2024/06/18 To:Dan Fidler 587 2024/06/18 To:Joao Damas scan: unable to read: Is a directory scan: scan() botch (-3) % i would think the file/dir name is available at point of fail so we could get a botch message identifying the culprit and .. move on? Not going to die on the hill. Things are working fine otherwise. -G On Tue, Jun 25, 2024 at 12:07 PM Ken Hornstein wrote: > >if your folder is a primary directly under $MAILPATH/ it works fine, as a > >pure numeric > > > >so folder +2021 is fine -and I do this for archives by year. > > > >if your folder is sub-folder under another folder like +sent/2021 it only > >kind-of works. Any function which performs scan functions looks to pure > >numeric objects as files, and barfs on the directory. So I work around it > >by having archives like sent/y2021 and it works fine. > > The exact case is that there isn't a problem as long as something that > is a folder doesn't contain a non-file who's name consists of all decimal > digits. So in theory 'scan +$MAILPATH' probably won't work so well (but > maybe that's not that useful in practice). > > >the other path out here is to do folder +2021/sent and subfolder sent > >inside the archive year which works fine. > > > >I just wondered if a stat() on the object to skip (sub)folders in contexts > >which demand files would work? Might be a pain to implement without > >unwanted side-effects. > > This comes up occasionaly, most recently here: > > https://lists.nongnu.org/archive/html/nmh-workers/2023-03/msg0.html > > Unfortunately, there are no good answers. stat()ing every possible > message would be very expensive. dirent->d_type is not always reliable > (and it's not easy to figure out when it will be reliable). The consensus > in the past has been "don't do that". I am open to suggestions of course. > > --Ken >
Re: folders which are numerical names
>if your folder is a primary directly under $MAILPATH/ it works fine, as a >pure numeric > >so folder +2021 is fine -and I do this for archives by year. > >if your folder is sub-folder under another folder like +sent/2021 it only >kind-of works. Any function which performs scan functions looks to pure >numeric objects as files, and barfs on the directory. So I work around it >by having archives like sent/y2021 and it works fine. The exact case is that there isn't a problem as long as something that is a folder doesn't contain a non-file who's name consists of all decimal digits. So in theory 'scan +$MAILPATH' probably won't work so well (but maybe that's not that useful in practice). >the other path out here is to do folder +2021/sent and subfolder sent >inside the archive year which works fine. > >I just wondered if a stat() on the object to skip (sub)folders in contexts >which demand files would work? Might be a pain to implement without >unwanted side-effects. This comes up occasionaly, most recently here: https://lists.nongnu.org/archive/html/nmh-workers/2023-03/msg0.html Unfortunately, there are no good answers. stat()ing every possible message would be very expensive. dirent->d_type is not always reliable (and it's not easy to figure out when it will be reliable). The consensus in the past has been "don't do that". I am open to suggestions of course. --Ken
Re: whatnow: problems with edit--draft left
Hi kre, Thanks for setting me straight. > > I'm puzzled why g/x/= prints 3 twice rather than 1, 3. > > Add an extra line at the end (not containing x) and you'll see it > prints 4 4, which makes what happened obvious. I realised = was doing its normal thing of the number of lines in the file because its address defaulted to $; I should have given a better example, sorry. > g/x/.= > > would do what you intended. (Most commands that you'd use with a g// > prefix default to '.' if no address is given, '=' happens to be one > which doesn't.) Yes. Before writing, I checked various documents and saw ($)= and already knew the default address was the last line of the file. I leapt from ed(1p)'s description of g, Then, going sequentially from the beginning of the file to the end of the file, the given command list shall be executed for each marked line, with the current line number set to the address of that line. to thinking that ‘the current line set’ would override the $ default. Wrong, of course. ‘.’ is being set to each matching line which is different to ‘.’ being implicitly given as an address to what g executes. Thanks again. -- Cheers, Ralph.
Re: whatnow: problems with edit--draft left
Date:Tue, 11 Jun 2024 14:41:21 +0100 From:Ralph Corderoy Message-ID: <20240611134121.46dd522...@orac.inputplus.co.uk> | I'm puzzled why g/x/= prints 3 twice rather than 1, 3. Add an extra line at the end (not containing x) and you'll see it prints 4 4, which makes what happened obvious. The = command with no address prints the number of lines in the file, which in your case happened to be 3 (that line 3 contained x was a coincidence). g/x/.= would do what you intended. (Most commands that you'd use with a g// prefix default to '.' if no address is given, '=' happens to be one which doesn't.) kre
Re: whatnow: problems with edit--draft left
Hi Marcin, > I think GNU ed introduced this at a (possibly misguided) attempt to > remove isatty at the very beginning. I agree with your analysis having read all of ed(1p). GNU seem to have this wrong. I'm puzzled why g/x/= prints 3 twice rather than 1, 3. $ ed -p': ' : a x y x . : 1= 1 : 3= 3 : g/x/n 1 x 3 x : g//= 3 3 : q ? : q $ -- Cheers, Ralph.
Re: whatnow: problems with edit--draft left
Hi Andy, > .Ex -std ed > > I'm no man page expert but it seems that .Ex is a macro that loads > a standard string that is used commonly between commands where 0 is > success and >0 is error. And it takes the name of the utility as an > argument. > > Indeed it is found in mdoc_validate.c in the definition of post_ex(): ... > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_validate.c?rev=1.306=text/x-cvsweb-markup Oh, it's not a man page but a mdoc page. https://man.openbsd.org/mdoc.7#Ex Thanks for digging for the answer. -- Cheers, Ralph.
Re: whatnow: problems with edit--draft left
On Sun, 9 Jun 2024, Ralph Corderoy wrote: Some historical implementations returned exit status zero even if command errors had occurred; this is not allowed by this volume of POSIX.1‐2008. Here is what I think it means: it is an error to exit with zero in case the error occurred, i.e. right away after an error. This needs to be read in the context of a CONSEQUENCES OF ERROR section (quoting 2017 version from [1]): ONSEQUENCES OF ERRORS When an error in the input script is encountered, or when an error is detected that is a consequence of the data (not) present in the file or due to an external condition such as a read or write error: If the standard input is a terminal device file, all input shall be flushed, and a new command read. If the standard input is a regular file, ed shall terminate with a non-zero exit status. The whole concept to have a temporary variable to taint the future exit status is wrong (cleanup code executed before the exit does not count). If there is an error that you consider serious enough to exit and set an exit code, the systems EXITS and sets the code. If there is a heuristic that determines the program to be interactive enough to allow the execution to proceed and ask the user to re-enter a possibly new command, no exit code should be determined - simply because we do not, er, exit. I think GNU ed introduced this at a (possibly misguided) attempt to remove isatty at the very beginning. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html Marcin smime.p7s Description: S/MIME Cryptographic Signature
Re: whatnow: problems with edit--draft left
Thus said Ralph Corderoy on Sun, 09 Jun 2024 22:16:25 +0100: > What am I doing wrong? I don't see 'success' in That's interesting, I'm not sure why the source wouldn't have it. You can see the rendered man page here: http://man.openbsd.org/ed However, I'm now confused why the man page as rendered doesn't match the sources as you have discovered. It seems that it us using the Ex macro: .Sh EXIT STATUS .Ex -std ed I'm no man page expert but it seems that .Ex is a macro that loads a standard string that is used commonly between commands where 0 is success and >0 is error. And it takes the name of the utility as an argument. Indeed it is found in mdoc_validate.c in the definition of post_ex(): http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_validate.c?rev=1.306=text/x-cvsweb-markup roff_word_alloc(mdoc, n->line, n->pos, "on success, and\\~>0 if an error occurs."); Andy
Re: whatnow: problems with edit--draft left
Hi Andy,
> Man page for OpenBSD's ed:
>
> EXIT STATUS
> The ed utility exits 0 on success, and >0 if an error occurs.
What am I doing wrong? I don't see ‘success’ in
https://cvsweb.openbsd.org/src/bin/ed/ed.1?rev=1.77=text/x-cvsweb-markup
> Does this statement mean that there was an error during the sequence
> of ed commands or does it mean that there was an error in saving?
Without a tighter definition, we can't tell.
OpenBSD's ed, and NetBSD's which I had already looked at before your
email, lists some ‘OMISSIONS’ in
https://cvsweb.openbsd.org/src/bin/ed/POSIX?rev=1.8=text/x-cvsweb-markup
> So, in my case, ed exited 0. Is this a bug in OpenBSD's ed which
> claims to be "compliant with the IEEE Std 1003.1-2008 ("POSIX.1")
> specification", or a bug in the man page?
I'd say OpenBSD's ed. ed(1p) here says
It shall be an error if a search for a BRE fails to find a matching
line.
and
Some historical implementations returned exit status zero even if
command errors had occurred; this is not allowed by this volume of
POSIX.1‐2008.
--
Cheers, Ralph.
Re: whatnow: problems with edit--draft left
Thus said Ralph Corderoy on Thu, 06 Jun 2024 11:15:43 +0100:
> My guess is you're imperfect in your ed-ing. :-)
Or perhaps the ed utility is poorly implemented. Man page for OpenBSD's ed:
EXIT STATUS
The ed utility exits 0 on success, and >0 if an error occurs.
Does this statement mean that there was an error during the sequence of
ed commands or does it mean that there was an error in saving?
At any rate, observe:
$ ed /tmp/foo
/tmp/foo: No such file or directory
a
foo
.
wq
4
$ echo $?
0
$ ed /tmp/foo
4
/bar
?
$a
bar
.
wq
8
$ echo $?
0
So, in my case, ed exited 0. Is this a bug in OpenBSD's ed which
claims to be "compliant with the IEEE Std 1003.1-2008 ("POSIX.1")
specification", or a bug in the man page?
Andy
Re: whatnow: problems with edit--draft left
On Thu, 6 Jun 2024, Ralph Corderoy wrote: I thought you'd get a copy of my reply from the list as you were a subscriber. Perhaps it just crossed with your second copy to the list. So many embarrassing things at once, including my attempt at writing C, a language I knew once. And yes, I was checking the archives, but the June 2024 wasn't there until I reloaded the page really hard after reading your second email. What is going on? ed(1) is behaving as documented. :-) Now I remember I must have run into this before. https://lists.gnu.org/archive/html/bug-ed/2014-12/msg9.html explains this is desired behaviour of GNU ed(1). They have even added a funny "loose exit code" option, probably out of the guilt feeling Since I spend most of my tty time on BSD, their ed behaves in a nice way -- if the input is a terminal, it will not exit with an exit code > 0 in case of a non-fatal error. Even POSIX says, If the standard input is a terminal device file, all input shall be flushed, and a new command read. If the standard input is a regular file, ed shall terminate with a non-zero exit status. although they say also say, The following exit values shall be returned: 0 Successful completion without any file or command errors. I have just built GNU ed 0.1 (the first version I can find from 1994) and it does exit with 0 if an error has been made in the interactive session. They have changed it in GNU ed 0.2 to do the following: what is supposed to be an EXIT status is kept in the variable until the program decides to exit anyway. Strange. But this is not an mh topic. Thank you for your time, Marcin smime.p7s Description: S/MIME Cryptographic Signature
Re: whatnow: problems with edit--draft left
Hi saper, > (resending, 1st attempt) Your first one was delayed for moderator approval because it was your first email to the list. It got approved and reached the subscribers. I replied to the list. Here's the archive so you can see the reply. https://lists.nongnu.org/archive/html/nmh-workers/2024-06/threads.html I thought you'd get a copy of my reply from the list as you were a subscriber. Perhaps it just crossed with your second copy to the list. > What is going on? ed(1) is behaving as documented. :-) -- Cheers, Ralph.
Re: whatnow: problems with edit--draft left
Hi Marcin,
> After saving the file I mostly (not always) get the following error:
>
> whatnow: problems with edit--draft left in /home/saper/Mail/drafts/,1
https://git.savannah.nongnu.org/cgit/nmh.git/tree/uip/whatnowsbr.c#n760
760 if ((status = pidwait (pid, NOTOK))) {
761 if (((status & 0xff00) != 0xff00)
762 && (!reedit || (status & 0x00ff))) {
763 if (!use && (status & 0xff00) &&
764 (rename (file, cp = m_backup (file)) !=
-1)) {
765 inform("problems with edit--draft left in %s",
cp);
766 } else {
767 inform("problems with edit--%s preserved",
file);
768 }
769 }
770 status = -2;/* maybe "reedit ? -2 : -1"? */
771 break;
772 }
773
The inform()s are poor as they don't pass on the detail, e.g. ed(1)'s
exit status.
My guess is you're imperfect in your ed-ing. :-)
$ man 1p ed | sed -n '/^EXIT STATUS/,/^[^ ]/p'
EXIT STATUS
The following exit values shall be returned:
0Successful completion without any file or command errors.
>0An error occurred.
CONSEQUENCES OF ERRORS
$
Here's an example.
$ ed /tmp/foo
/tmp/foo: No such file or directory
a
foo
.
wq
4
$ echo $?
0
$ ed /tmp/foo
4
/bar
?
$a
bar
.
wq
8
$ echo $?
1
$
Consider having a shell-script wrapper for ed which does its own checks,
if you can think of some, before returning its own exit status.
> $ diff orig/nmh-1.8/uip/whatnowsbr.c nmh-1.8/uip/whatnowsbr.c
Can we have a ‘diff -u’ another time please.
> 760a761
> > fprintf(stderr, "status = 0x%04x use = 0x%02x reedit = 0x%02x");
fprintf() is not being passed the parameters to print so it printing
what it finds on the stack.
> By the way, the system is not very reliable in counting comma files
> - it managed to overwrite my ",1" once.
nmh doesn't count comma files; the presence of ,1 doesn't make it use ,2
instead. Email 42 is moved to ,42 even if a previous 42 was moved to
,42 and it is still sitting there. A better scheme can be used by
setting rmmproc to what you prefer; see mh_profile(5).
--
Cheers, Ralph.
Re: Review code changes for handling huge lines?
Thus said David Levine on Sun, 07 Apr 2024 12:09:05 -0400: > Just to note that we would need a test suite addition that shows what > the change fixes. Yes, that's on the todo list. I'm not very familiar with the test harness but it should definitely be done if we're going to include it. > Also, there are these gcc warnings with these settings (from > build_nmh -d), based on what Fedora has used: Ok, I'll have to look into the warnings. I didn't see any when I built it on OpenBSD, but then I used OpenBSD's ports infrastructure to build it, not "build_nmh -d" Andy
Re: Nmh on MacOs
Hi Eric, > I have mu, nmh, dape, and slime on my emacs I think Emacs users like the MH-E interface to nmh: https://mh-e.sourceforge.io. > Every time I press inc, I get this message This is quite common. https://lists.nongnu.org/archive/html/nmh-workers/2023-03/msg3.html was one ‘recent’ short discussion. There is a text file which tracks your ‘current’ version and when nmh realises it's more new then it says ‘Welcome’. To locate that file, replicate my commands but with the output you get. $ mhparam path context path: mail context: context $ $ cat ~/mail/context Current-Folder: inbox Version: nmh-1.7+dev $ > I know one mistake I made was running inc while in root, but I don’t > know how to fix it. Can you write to that context file? Perhaps nmh is having trouble storing the new version after it has said welcome. I'd expect ~/mail downwards to be owned by you, not root. Or whatever your ‘path’ is shown to be with the above mhparam(1) command. $ cd $ find `mhparam path` ! -user $LOGNAME $ You'll see in the above thread that Ken gives a way of disabling the welcome message but I wouldn't rush to do that in case your problem is a symptom of a mess left by running inc as root. You'd just be disguising the underlying cause and hit a new problem instead. -- Cheers, Ralph.
Re: Nmh on MacOs
You don't press inc. You run inc from your user account in the terminal. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Wed, 17 Apr 2024, Eric Arillo wrote: > Hi All, I’m Eric. Here is my dilemma: New to emacs and nmh. I have nm-h > version 1.8 installed. I’ve read and re-read the mail documentation in emacs, > and tried to read the nm-h man, but lost my way a little. I am on a macOS > 14.4.1 , Sonoma. I have mu, nmh, dape, and slime on my emacs, I also have a > gui (emacs 30) and a cli emacs 29.3. Every time I press inc, I get this > message ,” > > Welcome to nmh version 1.8 > > See the release notes in /opt/homebrew/Cellar/nmh/1.8_1/share/doc/nmh/NEWS > > Send bug reports, questions, suggestions, and patches to > nmh-workers@nongnu.org. That mailing list is relatively quiet, so user > questions are encouraged. Users are also encouraged to subscribe, and > view the archives, at https://lists.gnu.org/mailman/listinfo/nmh-workers > > This message will not be repeated until nmh is next updated. “ > > > But the message is repeated. I can send mail, but not receive it. > I used the simplest setting, where the mail gets handed off to gmail, I > haven’t set up any back end beyond installing mu, and nmh. > > I know one mistake I made was running inc while in root, but I don’t know > how to fix it. > > Any help would be greatly appreciated, > Eric A. >
Re: inc and non-compliant long lines redux
Hi, Ken wrote: > Andy wrote: > > Precisely. Though in my current patch proposal, the problem isn't > > with CR/LF but with the two .. signal terminator coming from POP. > > The two dots must be getting split and the first dot is at the end > > of a buffer and the second is at the beginning of the next buffer. > > Yeah, I was realizing this. I think the logic has to be something > like: > > - netsec_read() into buffer 'b'; > > - Loop over 'b': > > If ! CR && ! LF > putc() > > If CR > check to see if next character is LF. If it is, skip over CR. > If it is not, output CR. If at the end of the buffer, read > more and restart loop. > > If LF > If at the end of buffer, read more and loop back to top. > > Output LF. If the next character is ".", make sure not at end of > buffer (must have at least two more characters). If are, read more > and loop back to top. > > If the next character is "." and the characters AFTER "." is not > CR-LF, skip over ".". If the next characters ARE ". CR LF", then > terminate multiline response. > > I ... think that's correct? This kind of thing gets messy once there starts to be multiple booleans tracking state. Have all cases been considered? I find it easier to have states and events with a table which shows what happens in every S*E cases. So roughly starting like this. Roughly as I don't know the protocol so don't know my aim. But I do know I can shuffle my way through the table, one input byte at a time, finding out the action(s) and possible new state. ══╤═══ │ Event State│ CR LF . else ──┼─── start│ →cr put(LF) put(.) put(*) cr │ put(CR) put(LF),→crlfput(.),→start put(*),→start crlf │ →cr put(LF),→start →crlfdot put(*),→start crlfdot │ put(.),→cr put(.LF),→start →crlf2dot put(.*) crlf2dot │ ... ──┴─── An ‘->err’ can cause an ‘all engines stop’. This doesn't need to be implemented as a big switch statement with an enum for state. If the range of actions is small, it's often possible to use an array of strings, one per state, with the printable chars being a small instruction code. This remains readable, with some study, and represents the table instead of the table ending up unmaintained in a comment and the switch statement spread over screenfuls. -- Cheers, Ralph.
Re: Review code changes for handling huge lines?
Andy wrote:
> There was some interest but I believe it got lost in the nmh 1.7.1
> shuffle. After patching up my OS to the latest, I found that it was now
> running nmh 1.8, but was missing the code and so I tried applying that
> patch locally against my system and have been running it since then
> (January of this year 2024) without issues.
> Any interest in renewing a discussion about this?
I'd be interested in hearing from Ken and Ralph, at least, if they're
available.
Just to note that we would need a test suite addition that shows what the
change fixes. Also, there are these gcc warnings with these settings
(from build_nmh -d), based on what Fedora has used:
CFLAGS="-g -std=c99 -pedantic -Wformat -Werror=format-security
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -fasynchronous-unwind-tables -fno-omit-frame-pointer
-fstack-clash-protection -fcf-protection -O0"
../../uip/popsbr.c: In function ‘traverse’:
../../uip/popsbr.c:592:43: warning: pointer targets in passing argument 2 of
‘netsec_read’ differ in signedness [-Wpointer-sign]
592 | len = netsec_read(nsc, buffer + inoffset, unused, );
|~~~^~
| |
| char *
In file included from ../../uip/popsbr.c:14:
../../h/netsec.h:169:64: note: expected ‘unsigned char *’ but argument is of
type ‘char *’
169 | ssize_t netsec_read(netsec_context *ns_context, unsigned char *buffer,
| ~~~^~
../../uip/popsbr.c:593:21: warning: comparison of unsigned expression in ‘< 0’
is always false [-Wtype-limits]
593 | if (len < 0) {
| ^
David
Re: Review code changes for handling huge lines?
Thus said "Andy Bradford" on 04 Apr 2024 16:45:29 -0600: > Any interest in renewing a discussion about this? Also, I have found at least one contact mechanism that I'm pursuing but I'm not very hopeful that it will result in any kind of resolution---there is a "Send Feedback" option, however, I've utilized it in the past and received no confirmation. The bug still exists because the messages are still being sent with huge lines. There is no rush to get this code in, but I just wanted to bring this up again just in case anyone else has an opinion (assuming we have new subscribers since I last mentioned it). Sadly, I agree with Ralph's comments here: https://lists.nongnu.org/archive/html/nmh-workers/2022-11/msg00014.html The best option is to have the sender comply with RFC 5322, Section 2.1.1 which clearly restricts line lengths. We'll see where my efforts to contact end up. Thanks, Andy
Re: Review code changes for handling huge lines?
Thus said "Andy Bradford" on 04 Apr 2024 16:45:29 -0600: > A day later I also provided a patch against master: > > https://lists.nongnu.org/archive/html/nmh-workers/2022-11/msg7.html And that link is actually not the latest---I found some bugs along the way and addressed them in a separate patch. Here is the actual latest: https://lists.nongnu.org/archive/html/nmh-workers/2022-11/msg00028.html Andy
Re: Symbolic link to mhmail
Thomas Dupond wrote in <7c469bc6-ad63-48c0-9afb-0d6c06d5d...@dupond.eu>: ... |Wow thanks for this fix! Being able to use nmh as a mailx replacement \ |in Debian will be very useful to me. Sheer unbelievable. New version up in summer, will be called "Mountains O' Things". And has! (More than three years of development.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Symbolic link to mhmail
Le 4 avril 2024 03:43:56 GMT+02:00, David Levine a écrit : >I wrote: > >> Thomas wrote: >> >> > For the reason given above I don't think this would solve it. I think >> > these results might be even more explicit: >> > >> > $ echo $PATH >> > /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin >> > $ cp /usr/bin/mh/mhmail ./test >> > $ ./test >> > ./test: 1: /home/thomas/mhparam: not found >> > ./test: 95: exec: /home/thomas/inc: not found >> >> The root cause of the problem is that mhmail uses, in effect, `dirname $0` >> to find the location of the nmh executables. >> >> Because /usr/bin/mh is on your PATH, it could instead use `mhparam bindir`. > >I just committed that fix to mhmail and sendfiles. > >Thank you, Thomas, for reporting this. Starting with the current HEAD, you >can symlink mhmail. > >David Wow thanks for this fix! Being able to use nmh as a mailx replacement in Debian will be very useful to me. Thank you again, have a nice day. -- Thomas
Re: Symbolic link to mhmail
I wrote: > Thomas wrote: > > > For the reason given above I don't think this would solve it. I think > > these results might be even more explicit: > > > > $ echo $PATH > > /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin > > $ cp /usr/bin/mh/mhmail ./test > > $ ./test > > ./test: 1: /home/thomas/mhparam: not found > > ./test: 95: exec: /home/thomas/inc: not found > > The root cause of the problem is that mhmail uses, in effect, `dirname $0` > to find the location of the nmh executables. > > Because /usr/bin/mh is on your PATH, it could instead use `mhparam bindir`. I just committed that fix to mhmail and sendfiles. Thank you, Thomas, for reporting this. Starting with the current HEAD, you can symlink mhmail. David
Re: Symbolic link to mhmail
Thomas wrote: > For the reason given above I don't think this would solve it. I think > these results might be even more explicit: > > $ echo $PATH > /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin > $ cp /usr/bin/mh/mhmail ./test > $ ./test > ./test: 1: /home/thomas/mhparam: not found > ./test: 95: exec: /home/thomas/inc: not found The root cause of the problem is that mhmail uses, in effect, `dirname $0` to find the location of the nmh executables. Because /usr/bin/mh is on your PATH, it could instead use `mhparam bindir`. Or instead of trying to find the location at runtime, configure could be used to at build time to insert the path into the mhmail script. And the same could be done with etc/sendfiles. Thoughts? David
Re: Symbolic link to mhmail
HEllo, Thank you Robert and Ralph for your quick answers. Le 2024-03-27 à 14:39, Ralph Corderoy a écrit : Hello Thomas, kre has given a good answer and I'd do what he suggested, but... This issue comes from the fact that I wanted to use the unattended-upgrades package on Debian which uses mailx to send reports. Since only nmh is detected as providing a compatible mailx program, mailx redirects to /usr/bin/mh/mhmail. Are you saying that Debian puts in the symlink from /usr/bin/mhmail to /usr/bin/mh/mhmail when selecting nmh as one of the alternative packages to provide a virtual package which unattended-upgrades depends upon? Yes. To be extra clear, /usr/bin/mailx is a symlink to /etc/alternatives/mailx which itself is a symlink to /usr/bin/mh/mhmail. That sounds flawed for the reason you gave. Does Debian have a central place to manipulate PATH to append /usr/bin/mh for unattended-upgrades? unattended-upgrade(8) is configured via /etc/apt/apt.conf.d/50unattended-upgrades. In this file it is noted that to send email reports, mailx is used: // Send email to this address for problems or packages upgrades // If empty or unset then no email is sent, make sure that you // have a working mail setup on your system. A package that provides // 'mailx' must be installed. E.g. "u...@example.com" Unattended-Upgrade::Mail "root"; I discovered the mailx issue while trying to use mailx with my user account which does have /usr/bin/mh in its PATH. apt-file(1) here suggests there's a /lib/systemd/system/unattended-upgrades.service so perhaps a local file to override its PATH? For the reason given above I don't think this would solve it. I think these results might be even more explicit: $ echo $PATH /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin $ cp /usr/bin/mh/mhmail ./test $ ./test ./test: 1: /home/thomas/mhparam: not found ./test: 95: exec: /home/thomas/inc: not found Which version of Debian is this? ‘lsb_release -a’ shows this. $ uname -a; lsb_release -a Linux nuage 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm Thank you for your help, -- Thomas
Re: Symbolic link to mhmail
Hello Thomas, kre has given a good answer and I'd do what he suggested, but... > This issue comes from the fact that I wanted to use the > unattended-upgrades package on Debian which uses mailx to send > reports. Since only nmh is detected as providing a compatible mailx > program, mailx redirects to /usr/bin/mh/mhmail. Are you saying that Debian puts in the symlink from /usr/bin/mhmail to /usr/bin/mh/mhmail when selecting nmh as one of the alternative packages to provide a virtual package which unattended-upgrades depends upon? That sounds flawed for the reason you gave. Does Debian have a central place to manipulate PATH to append /usr/bin/mh for unattended-upgrades? apt-file(1) here suggests there's a /lib/systemd/system/unattended-upgrades.service so perhaps a local file to override its PATH? Which version of Debian is this? ‘lsb_release -a’ shows this. -- Cheers, Ralph.
Re: Symbolic link to mhmail
Date:Tue, 26 Mar 2024 15:59:35 +0100 From:Thomas Dupond Message-ID: <5130a4e4-b808-4d19-9a45-4e35b25bc...@dupond.eu> | I wanted to know how could I make a symbolic link to mhmail from | /usr/bin/mailx. Try not doing that. Instead make mailx into a script (with just one meaninful line): #! /bin/sh exec /usr/bin/mh/mhmail "$@" Of course, turn on 'x' permission. kre
Re: Setting send(1)'s draftfolder breaks mhmail.
Ralph wrote: > Or perhaps use -nodraftfolder to cancel any profile setting when send is > being used and carry on as before. Though I don't know if > -nodraftfolder completely undoes a profile's -draftfolder. Good idea. And good call about not completely undoing -draftfolder. As explained in the commit message: commit 5718396d9c51c6e41d13c2548cd3ced591d3a028 Added -nodraftfolder to send(1) args when mhmail(1) is invoked with -profile. mhmail uses a tmp file. If the user has a -draftfolder switch in the send component of their profile, send interpreted the tmp filename as a message number. That caused send to fail. Fixed by squashing any send -draftfolder switches by appending the -nodraftfolder switch. The handling by send of "-draftfolder folder_name -nodraftfolder" is not the same as if that sequence of switches was not used. With it, the filename is processed by m_maildir(). Because mhmail provides an absolute path to send as the filename, m_maildir() returns the path unchanged. send therefore works properly with the absolute path argument from mhmail. Thanks to Ralph for reporting the bug and providing the fix. David
Re: Trivia: space before '(others)' from 'folder' command
Thus said "Andy Bradford" on 20 Jan 2024 08:48:36 -0700: > I think it would be nice if it's aligned properly like other nmh > commands try to accomplish. Time to backpedal my comment a bit as it's not about proper alignment per se; I was distracted by the folders output which aligns multiple folder names. I suppose in this case, the argument is that because there is no current message, the presence of the extra spaces in the context of "folder" (without the 's') is distracting, or unnecessary because "folder" only deals with one folder at a time. Not only that, it's unlikely that one folder command needs to be aligned with a previous folder command, so a condition on all could make sense. Andy
Re: Trivia: space before '(others)' from 'folder' command
Thus said Ralph Corderoy on Sat, 20 Jan 2024 16:00:46 +:
> folders +OpenSourceML | awk '{l=length($1)}l>m{m=l;p=$0}END{print p}'
I see, I have one folder name that is fairly long and as a result, this
double-space shifted things just enough to make it wider than 80:
https://git.savannah.nongnu.org/cgit/nmh.git/tree/uip/folder.c?h=1.8-release#n588
But, as you say, it does appear to be just coincidence. If I run folders
against the longer folder name, clearly all of the subfolders in there
cause the lines of output to exceed the 80 character wide display and
wrap in the terminal.
Thanks for the nifty awk command to sort things out.
Andy
Re: Trivia: space before '(others)' from 'folder' command
Hi Andy,
> Is this perhaps an off-by-one error?
I don't think so.
Try
folders +OpenSourceML | awk '{l=length($1)}l>m{m=l;p=$0}END{print p}'
That it's 81 wide when ‘tput cols’ is 80 is coincidence.
--
Cheers, Ralph.
Re: Trivia: space before '(others)' from 'folder' command
Thus said Ken Hornstein on Fri, 19 Jan 2024 22:33:54 -0500: > Yeah, that is exactly why it happens. Honestly it doesn't personally > bother me, but what do others think? While I've never noticed it in the context of "folder -pack" (because I don't use it) I think it would be nice if it's aligned properly like other nmh commands try to accomplish. Not sure if this is related, but I have a similar experience with the folders command. For example, I have a folder OpenSourceML where I stuff various subfolders of things I'm subscribed to and on my 80 character wide terminal it seems to be having trouble figuring out the width. It seems to be generating a line that is exactly 81 characters long and so in my terminal it wraps the output exactly on the final period (.) leaving a much longer (visually) list of output than otherwise is necesary that looks like: $ folders +OpenSourceML FOLDER# MESSAGES RANGE; CUR(OTHERS) OpenSourceML+ hasno messages ;(others) . OpenSourceML/Bind has 338 messages (1- 338); cur= 338; (others) . OpenSourceML/OpenBSD hasno messages ;(others) . OpenSourceML/fossil has 16425 messages (1-16425);(others) . OpenSourceML/nongnu hasno messages ;(others) . Is this perhaps an off-by-one error? Aside from that everything seems to be impressively aligned just fine. Andy
Re: Trivia: space before '(others)' from 'folder' command
Hi Ken, > > Possibly this could be conditional on the 'all' flag which gets > > turned on if the command name ends in 's'? > > Yeah, that is exactly why it happens. Honestly it doesn't personally > bother me, but what do others think? It seems a bit of a nit which could be groomed out. It was probably just coded like that without considering the multiple uses of the code, as suggested earlier. -- Cheers, Ralph.
Re: Where is my editor?
Thus said Ken Hornstein on Fri, 19 Jan 2024 16:45:18 -0500: > Like many threads involving ancient greybeards, it kind of devolved > into a discussion about the "true" vi and how vim wasn't vi enough It wouldn't be a good devolution if it didn't involve vi vs emacs or another editor! > And the consensus of everyone was prompter was fine as a default. lso, > Andy, you later said in that thread: > > Sounds like I might have to add something to my profile now after > this change is made to avoid prompter. Now that you quote it, I definitely remember saying it. And as I most recently hinted, I still don't have EDITOR/VISUAL set; I've now set the editor in the mh profile. > But to be fair, we did have a reasonable discussion about this change > (that it seems we all forgot about). Yes, indeed we did. Thanks for reminding me. It's amazing that it only took 6 years for me to finally get impacted by the results of the discussion! Watch out debian, if you think you have stable releases that live on forever, watch out for nmh as a contender. Andy
Re: Trivia: space before '(others)' from 'folder' command
>.. note the weird spacing before '(others)' in the second. I'm guessing >this is (line 613 of ./nmh/uip/folder.c on master, I think) because >'folder' and 'folders' ?maybe? share the same binary and the extra >'curmsgdigits + 6' spacing is to keep columns aligned in 'folders' >output. Possibly this could be conditional on the 'all' flag which gets >turned on if the command name ends in 's'? Yeah, that is exactly why it happens. Honestly it doesn't personally bother me, but what do others think? --Ken
Re: Where is my editor?
>Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700: > >> That's "prompter" - has always been mh's default. > >Not always: > >https://git.savannah.nongnu.org/cgit/nmh.git/log/sbr/geteditor.c?h=1.8-release > >Looks like it was changed in 1.8 (if I read that correctly). > >I wasn't aware of "prompter" before, thanks for the education. I was curious and went back and looked. This was apparantly prompted (pun intended) by Fedora packaging and was discussed in this email thread, which, oddly enough Andy, you DID participate in: https://lists.nongnu.org/archive/html/nmh-workers/2018-03/msg5.html Like many threads involving ancient greybeards, it kind of devolved into a discussion about the "true" vi and how vim wasn't vi enough, but I guess part of this change is my fault since I went back and dug around to find out the original behavior of MH, which was to use "prompter" (the details are a little more complicated): https://lists.nongnu.org/archive/html/nmh-workers/2018-03/msg00037.html And the consensus of everyone was prompter was fine as a default. Also, Andy, you later said in that thread: Under what conditions will this change? I have neither EDITOR/VISUAL nor profile settings for editor, but maybe that won't matter because my usage patterns will never invoke prompter? Right now, when I run comp from the command line, I get a vi editor with with components in it. Is this where prompter comes in? Sounds like I might have to add something to my profile now after this change is made to avoid prompter. David replied to you and said: Yes, it does. Add this to your profile to preserve your current behavior: Editor: vi I'm not dragging you because it was almost 6 years ago and I forgot until now that I made that change, much less everything behind it. But to be fair, we did have a reasonable discussion about this change (that it seems we all forgot about). --Ken
Re: Where is my editor?
Sorry for the off-topic reply, but the mention of OpenBSD took me back. I probably have a dozen OpenBSD shirts. (I doubt I can fit in them anymore LOL!) I have a pile of CDs of OpenBSD and FreeBSD releases. When I started my last job in 2000, the first thing I did was fix the company email server. I ran FreeBSD with Postfix on a Compaq rack mount server. (So much easier than sendmail.cf!) I had an uptime of over three years at one point. Boy are those days gone. I just received a copy of Kernighan's Unix A History and a Memoir. While I knew most of the stories already, it was fun to see some pictures I hadn't seen before, and reading it took me back to those heady Doctor Dobb's and Microcornucopia days of my computer career youth... From: nmh-workers-bounces+doug=dougwellington@nongnu.org on behalf of Andy Bradford Sent: Friday, January 19, 2024 7:28 AM To: Robert Elz Cc: nmh-workers@nongnu.org Subject: Re: Where is my editor? Thus said Robert Elz on Fri, 19 Jan 2024 15:10:26 +0700: > Yes, I have had the "editor" line in my profile since MH days, (I have > been a user since almost forever) so what nmh did as default I never > knew, which is why I avoided saying that... >From looking at the past sources it used to use a C macro defined in h/nmh.h: #define DEFAULT_EDITOR "vi" I'm curious now how many installations of nmh do not have vi available... that being said, I do know Linux based OS developers make a lot of strange decisions about what is in the "base" OS, so it's entirely possible that vi may not exist in some flavors of Linux. How many non-POSIX systems is nmh running on? > I hope it is back working like you expected it now. It is now, thanks. I was able to figure out that EOT was what ended my experience with prompter and changed the default editor in .mh_profile and then I could just use "edit vi" at the "What now?" prompt. That's how I composed my original email starting this thread. It wasn't completely foreign (being a long-time Unix user I assumed it was just reading stdin and EOT would end it), just unexpected. I suppose I could set EDITOR but I've never had to on OpenBSD. Andy
Re: Where is my editor?
Hi Andy, > I suppose I could set EDITOR but I've never had to on OpenBSD. POSIX says EDITOR used by more(1) and crontab(1) defaults to vi if not set. But for mailx(1), the default is unspecified unless it's an XSI system when it's ed. mailx's default for VISUAL is vi, XSI or not. That's based on the section-1p man pages here. -- Cheers, Ralph.
Re: Where is my editor?
Thus said Robert Elz on Fri, 19 Jan 2024 15:10:26 +0700: > Yes, I have had the "editor" line in my profile since MH days, (I have > been a user since almost forever) so what nmh did as default I never > knew, which is why I avoided saying that... >From looking at the past sources it used to use a C macro defined in h/nmh.h: #define DEFAULT_EDITOR "vi" I'm curious now how many installations of nmh do not have vi available... that being said, I do know Linux based OS developers make a lot of strange decisions about what is in the "base" OS, so it's entirely possible that vi may not exist in some flavors of Linux. How many non-POSIX systems is nmh running on? > I hope it is back working like you expected it now. It is now, thanks. I was able to figure out that EOT was what ended my experience with prompter and changed the default editor in .mh_profile and then I could just use "edit vi" at the "What now?" prompt. That's how I composed my original email starting this thread. It wasn't completely foreign (being a long-time Unix user I assumed it was just reading stdin and EOT would end it), just unexpected. I suppose I could set EDITOR but I've never had to on OpenBSD. Andy
Re: Where is my editor?
Le 2024-01-19 à 09:10, Robert Elz a écrit : Date:18 Jan 2024 23:20:11 -0700 From:"Andy Bradford" Message-ID: <20240118232011.1679.qm...@angmar.bradfordfamily.org> | Ahh, I didn't read the fine print... you said "mh's default", but I | misunderstood it for "nmh's default". Yes, I have had the "editor" line in my profile since MH days, (I have been a user since almost forever) so what nmh did as default I never knew, which is why I avoided saying that... I assume the change you indicated happened is to avoid building a choice of default editors into nmh - prompter is part of the MH world, so always exists, even though ex/vi is POSIX std, there really is no guarantee it will exist on every system in the world (even less for emacs/jove/nano/vim/...) and having "ed" as the default would simply irritate people. Unfortunately, even ed is not on every system, eg. Debian by default has vi/ex but not ed. -- Thomas
Re: Setting send(1)'s draftfolder breaks mhmail.
Hi David, > mhmail currently uses a tmp file, always, for the draft. I think the > fix should depend on if mhmail has been instructed to use send and > send has a draftfolder switch in the profile. In that case it should > create the draft as a new draft message in the draftfolder, instead of > as a tmp file. Or perhaps use -nodraftfolder to cancel any profile setting when send is being used and carry on as before. Though I don't know if -nodraftfolder completely undoes a profile's -draftfolder. -- Cheers, Ralph.
Re: Where is my editor?
Date:18 Jan 2024 23:20:11 -0700 From:"Andy Bradford" Message-ID: <20240118232011.1679.qm...@angmar.bradfordfamily.org> | Ahh, I didn't read the fine print... you said "mh's default", but I | misunderstood it for "nmh's default". Yes, I have had the "editor" line in my profile since MH days, (I have been a user since almost forever) so what nmh did as default I never knew, which is why I avoided saying that... I assume the change you indicated happened is to avoid building a choice of default editors into nmh - prompter is part of the MH world, so always exists, even though ex/vi is POSIX std, there really is no guarantee it will exist on every system in the world (even less for emacs/jove/nano/vim/...) and having "ed" as the default would simply irritate people. I hope it is back working like you expected it now. Another profile entry worth having is prompter-next: vi (or perhaps even ed, or horrors, emacs) There are odd occasions where starting with prompter can be easier that a real editor, then you just end the prompter session (send EOF), and when it asks "What now?" you just "e" and then you get your real editor (prompter-next) to finish. comp -editor prompter will do that once you have the "editor" profile entry and so prompter is no longer the default. kre
Re: Where is my editor?
Thus said "Andy Bradford" on 18 Jan 2024 23:05:09 -0700: > Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700: > > > That's "prompter" - has always been mh's default. Ahh, I didn't read the fine print... you said "mh's default", but I misunderstood it for "nmh's default". So it's a change to align with mh default behavior, and of course since I've never used mh I wouldn't know. Andy
Re: Where is my editor?
Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700: > That's "prompter" - has always been mh's default. Not always: https://git.savannah.nongnu.org/cgit/nmh.git/log/sbr/geteditor.c?h=1.8-release Looks like it was changed in 1.8 (if I read that correctly). I wasn't aware of "prompter" before, thanks for the education. Andy
Re: Where is my editor?
Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700: > That's "prompter" - has always been mh's default. Well, I'm confused. If it was always the default, why am I only now seeing it after upgrading to 1.8? I haven't changed anything in my .mh_profile in years: $ ls -l ~/.mh_profile -rw-r--r-- 1 amb amb 788 Aug 16 2019 /home/amb/.mh_profile I'll update ~/.mh_profile with your suggestion for editor, but I'm confused how it ever worked with my editor. I've been using nmh for years now and never had any dealings with "prompter". Thanks, Andy
Re: Where is my editor?
Date:18 Jan 2024 21:19:39 -0700 From:"Andy Bradford" Message-ID: <20240118211939.36652.qm...@angmar.bradfordfamily.org> | type this email I typed comp, and then it entered some kind of | interactive dialog asking me for the To header, the Subject, and other | headers, That's "prompter" - has always been mh's default. | What can I do to get the original behavior back? put editor: vi in your .mh_profile kre
Re: Setting send(1)'s draftfolder breaks mhmail.
Andy wrote: > Thus said Ralph Corderoy on Thu, 18 Jan 2024 15:22:28 +: > > > The suggestion was to duplicate the setting by adding "send: > > -draftfolder drafts". I think this breaks mhmail(1). > > Except, according to the man page for mhmail: > > PROFILE COMPONENTS >mhmail does not consult the user's .mh_profile > > Perhaps it breaks send? The fault is with mhmail. When its -profile switch was added to use send instead of post, this interaction wasn't considered. mhmail currently uses a tmp file, always, for the draft. I think the fix should depend on if mhmail has been instructed to use send and send has a draftfolder switch in the profile. In that case it should create the draft as a new draft message in the draftfolder, instead of as a tmp file. David
Re: Setting send(1)'s draftfolder breaks mhmail.
Thus said Ralph Corderoy on Thu, 18 Jan 2024 15:22:28 +: > The suggestion was to duplicate the setting by adding "send: > -draftfolder drafts". I think this breaks mhmail(1). Except, according to the man page for mhmail: PROFILE COMPONENTS mhmail does not consult the user's .mh_profile Perhaps it breaks send? Andy
Re: Strange problem replying to message
>It is quite possible. I guess I am a LITTLE surprised this is the first instance you've ever seen where a text part was encoded with base64; I get those all of the time (and not just in work emails either). Maybe you get those more often than you think and this is just the first time you wanted to reply to such a message? But yes, nmh out of the box does not handle that well and it doesn't sound like there was any configuration change on your side. Note that I don't think anybody thinks that the current default nmh behavior is optimal by any means, but fixing this natively is ... complicated. >Perhaps I am losing it but when I first looked at the header fields >for the message that was giving me problems I could have sworn it said >"Content-Transfer-Encoding: Base64". Now when I look at it instead of >base64 it says 8bit. Am I confused or is that what mhfixmsg did, changed >the message from base64 to 8bit? As others have indicated, yes, that is exactly what it does. >I also notice looking thru other messages that most say 7bit. That is the "standard" encoding for ASCII email. If people send text parts with 8bit characters the encoding format varies. I suspect you probably see quoted-printable a fair amount, as my unscientific impression is that encoding is a lot more common for text parts with 8bit characters. --Ken
Re: Strange problem replying to message
Thus said aalin...@riseup.net on Mon, 15 Jan 2024 08:57:51 -0500: > Now when I look at it instead of base64 it says 8bit. Am I confused or > is that what mhfixmsg did, changed the message from base64 to 8bit? According to the manpage for mhfixmsg, it's supposed to make a backup copy of the original message before making alterations. Hopefully that worked, and hopefully the backup hasn't yet been overwritten, and then you can inspect the backup to see what the original looked like. If you are unaware, a backup is the same message number prefixed with a comma (,) in the folder where it is found. So for example, if your message number was 1234, you should have a ,1234 in the folder that you can look at. Andy
Re: Strange problem replying to message
> Perhaps I am losing it but when I first looked at the header fields for the > message that > was giving me problems I could have sworn it said "Content-Transfer-Encoding: > Base64". > Now when I look at it instead of base64 it says 8bit. Am I confused or is > that what mhfixmsg did, > changed the message from base64 to 8bit? mhfixmsg changed the encoding of the message content. There are other ways to reply to base64-encoded messages. One is explained in the "Convert Interface" section of the mhbuild(1) man page. David
Re: Strange problem replying to message
It is quite possible. Perhaps I am losing it but when I first looked at the header fields for the message that was giving me problems I could have sworn it said "Content-Transfer-Encoding: Base64". Now when I look at it instead of base64 it says 8bit. Am I confused or is that what mhfixmsg did, changed the message from base64 to 8bit? I also notice looking thru other messages that most say 7bit. Thank you Arthur In message <2024011458.8a00b1c7...@pb-smtp2.pobox.com>, Ken Hornstein writes: >>Yesterday everything worked. Today, trying to reply to a message I get: >>[...] >>I am running OpenBSd 7.4 and nmh-1.8. My ~/.mh_profile contains the >>line: >> >>repl: -query -annotate -nocc me -filter mhl.reply >> >>and the mhl.reply filter is: >>[...] > >I don't see anything in this setup that would undo a base64-encoded >text message body. Is it simply possible you haven't seen one of those >recently? > >--Ken
Re: Strange problem replying to message
>Yesterday everything worked. Today, trying to reply to a message I get: >[...] >I am running OpenBSd 7.4 and nmh-1.8. My ~/.mh_profile contains the >line: > >repl: -query -annotate -nocc me -filter mhl.reply > >and the mhl.reply filter is: >[...] I don't see anything in this setup that would undo a base64-encoded text message body. Is it simply possible you haven't seen one of those recently? --Ken
Re: Strange problem replying to message
Thank you, that worked. And I actually manaaged to impress myself by being able to use mhfixmsg(1) to correct it. In message <9036-1705244612.226...@catk.gddq.exge>, David Levine writes: >Arthur wrote: > >> Yesterday everything worked. Today, trying to reply to a message I get: >> >> >> In message mail.com>, >> "B. William via Remind-fans" writes: >> >SG1tbW0gdGhpcyBsaW5lIGRvZXMgVEhJUyBXRUVLLCArIDMgTU9SRSBXRUVLUyBhbmQgZ2l= >2ZXMg >> >dGhlIGRhdGVzOgoKcmVtaW5kIC1zKzQgLXEgLXIgfi8ucmVtaW5kZXJzIHwgY3V0IC1jNi0= >xMCwx > >It looks like the text part of the message that you're replying to was >not base64-decoded. You could verify that by viewing the message with >"show -nocheckmime -showproc less". > >If the text part is still encoded, you could decode it in the message itse= >lf, >or a copy, with mhfixmsg(1). > >I don't know why it would have worked yesterday but not today. > >David >
Re: Strange problem replying to message
Arthur wrote: > Yesterday everything worked. Today, trying to reply to a message I get: > > > In message > , > "B. William via Remind-fans" writes: > >SG1tbW0gdGhpcyBsaW5lIGRvZXMgVEhJUyBXRUVLLCArIDMgTU9SRSBXRUVLUyBhbmQgZ2l2ZXMg > >dGhlIGRhdGVzOgoKcmVtaW5kIC1zKzQgLXEgLXIgfi8ucmVtaW5kZXJzIHwgY3V0IC1jNi0xMCwx It looks like the text part of the message that you're replying to was not base64-decoded. You could verify that by viewing the message with "show -nocheckmime -showproc less". If the text part is still encoded, you could decode it in the message itself, or a copy, with mhfixmsg(1). I don't know why it would have worked yesterday but not today. David
Re: Macintosh for nmh?
George wrote: > Orbiting back, It looks to have only been deployed in anger with Google POP. > And, in NEWS and the code it's marked as deprecated/unsupported for various > reasons. But I would imagine it still works fine on the SMTP side. Nmh's XOAUTH2 support was implemented generically to support both SMTP and POP. It was instantiated for both to work with Google. However, Google changed things such that neither will work with it now. I expect that it wouldn't take much effort to get them to work with O365, but I haven't tried. David
Re: Macintosh for nmh?
Orbiting back, It looks to have only been deployed in anger with Google POP. And, in NEWS and the code it's marked as deprecated/unsupported for various reasons. But I would imagine it still works fine on the SMTP side. for O365 I am using mbsync with the python oauth2 external proxy, because I need to coordinate MH with imap and this mechanism maintains a smallish statefile on the MH side, which tracks the current IMAP message store state. Its "handle this imap store in a way which inc can read from, but inc is now dependent on 3rd party code" hell. A hell I am comfortable in, its the one with Banjos and Accordions but the food is good. It very probably works, and works well if your inc use-case is POP, and works for SMTP. I haven't tested this. -G On Sun, Dec 31, 2023 at 10:25 AM George Michaelson wrote: > I will have to find out why I couldn't get things to work before. I would > love less components in my supply chain, so to speak. > > G > > On Sun, 31 Dec 2023, 10:21 am Ken Hornstein, wrote: > >> >If you're on a mac and using O365 you may need >> >https://github.com/simonrob/email-oauth2-proxy >> > >> >Using it for a year, happily. >> >> We DO support XOAUTH2 natively, BTW. >> >> --Ken >> >>
Re: mysterious c0 80
Hi David, > > > > nmh shouldn't comp(1) a new email today with a NUL in the body, > > > > but it should be able to read and show(1) one. > > > > > > I'm thinking of removing the support in post(8) for sending NULs. > > > Any disagreement? It's not a lot of code so could be easily > > > restored in the future if conditions change. > > > > > > > Now, how about dist(1) of that old email? I'd have thought it > > > > should send the old email verbatim, NUL and all. If that causes > > > > a bounce then the sender can MIME-forward instead with a single > > > > message/rfc822 part. > > > > > > Agreed. > > > > But doesn't dist → send → post so if you remove post's support for > > sending NULs then dist won't be able to send the old email verbatim. > > Yes, but isn't that required by RFC 5322? Yes, RFC 5322 says do not send NULs. > I don't object to violating it in this case, so I'm fine with whatever > we can agree on. I was confused by your ‘Agreed’ above which agreed dist should be able to send and post NULs. -- Cheers, Ralph.
Re: mysterious c0 80
Michael wrote: > David Levine wrote: > > > I'm thinking of removing the support in post(8) for sending > > NULs. Any disagreement? It's not a lot of code so could be > > easily restored in the future if conditions change. > > Does that mean an error, or does that mean just skipping it? The old code relied on fprintf(3) and fputs(3), so it truncated at the first NUL. > I'm fine with skipping the NUL, but I'll live with the error; I'll > just have to fix my end :-) As Ken noted, it would be nice to understand the root cause. Ken wrote: + It is not clear to me that any of the OTHER nmh programs could + actually even receive a message with NUL in it, and plenty of other + programs fail if a message contains a NUL. Here's some messages + when I brought this up last year: In one of those messages, I noted that m_getfld and the MIME parser do handle NULs. I haven't tried inc(1). Ralph wrote: # But doesn't dist → send → post so if you remove post's support for # sending NULs then dist won't be able to send the old email verbatim. Yes, but isn't that required by RFC 5322? I don't object to violating it in this case, so I'm fine with whatever we can agree on. David
Re: mysterious c0 80
David Levine wrote: >> nmh shouldn't comp(1) a new email today with a NUL in the body, but it >> should be able to read and show(1) one. > I'm thinking of removing the support in post(8) for sending NULs. Any > disagreement? It's not a lot of code so could be easily restored in the > future if conditions change. Does that mean an error, or does that mean just skipping it? I'm fine with skipping the NUL, but I'll live with the error; I'll just have to fix my end :-) signature.asc Description: PGP signature
Re: mysterious c0 80
>> So while I agree post would fail with this hypothetical dist(1) of a >> message containing a NUL, it's not clear you could inc(1) such a >> message in the first place. > >Today or historically? Historically is a long time. I can't say that I know every single line of nmh and MH code since the dawn of time, but I've been in and out of it a lot. The assumption that you can represent email lines as C strings has been embedded in nmh and MH for as long as I can tell. Such emails don't work with nmh, and they probably don't work well with other MUAs either. Okay, fine, "don't work" is a bit of an oversimplification; it seems like those lines will be silently truncated at the NUL character, so they probably "work" fine and you just don't notice the NULs. --Ken
Re: mysterious c0 80
Hi Ken, > It would be nice to understand the root cause of the bug, though. Yes. > So while I agree post would fail with this hypothetical dist(1) of a > message containing a NUL, it's not clear you could inc(1) such a > message in the first place. Today or historically? Historically is a long time. -- Cheers, Ralph.
Re: mysterious c0 80
>> I'm thinking of removing the support in post(8) for sending NULs. Any >> disagreement? It's not a lot of code so could be easily restored in >> the future if conditions change. I think this makes sense, and it does seem to cause some kind of problem as reported in Cy's message. It would be nice to understand the root cause of the bug, though. >> > Now, how about dist(1) of that old email? I'd have thought it >> > should send the old email verbatim, NUL and all. If that causes a >> > bounce then the sender can MIME-forward instead with a single >> > message/rfc822 part. >> >> Agreed. > >But doesn't dist → send → post so if you remove post's support for >sending NULs then dist won't be able to send the old email verbatim. It is not clear to me that any of the OTHER nmh programs could actually even receive a message with NUL in it, and plenty of other programs fail if a message contains a NUL. Here's some messages when I brought this up last year: https://lists.nongnu.org/archive/html/nmh-workers/2023-02/msg00029.html https://lists.nongnu.org/archive/html/nmh-workers/2023-04/msg00031.html So while I agree post would fail with this hypothetical dist(1) of a message containing a NUL, it's not clear you could inc(1) such a message in the first place. --Ken
Re: mysterious c0 80
Hi David, > > nmh shouldn't comp(1) a new email today with a NUL in the body, but > > it should be able to read and show(1) one. > > I'm thinking of removing the support in post(8) for sending NULs. Any > disagreement? It's not a lot of code so could be easily restored in > the future if conditions change. > > > Now, how about dist(1) of that old email? I'd have thought it > > should send the old email verbatim, NUL and all. If that causes a > > bounce then the sender can MIME-forward instead with a single > > message/rfc822 part. > > Agreed. But doesn't dist → send → post so if you remove post's support for sending NULs then dist won't be able to send the old email verbatim. -- Cheers, Ralph.
Re: mysterious c0 80
Ralph wrote: > nmh shouldn't comp(1) a new email today with a NUL in the body, but it > should be able to read and show(1) one. I'm thinking of removing the support in post(8) for sending NULs. Any disagreement? It's not a lot of code so could be easily restored in the future if conditions change. > Now, how about dist(1) of that old email? I'd have thought it should > send the old email verbatim, NUL and all. If that causes a bounce > then the sender can MIME-forward instead with a single message/rfc822 > part. Agreed. David
Re: mysterious c0 80
Hi Ken, > According to RFC 5322, a NUL in a message body is not permitted. > From §3.5: > >body= (*(*998text CRLF) *998text) / obs-body > >text= %d1-9 /; Characters excluding CR >%d11 / ; and LF >%d12 / >%d14-127 obs-body is what allows the NUL. obs-body= *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) §4: Though these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver. nmh shouldn't comp(1) a new email today with a NUL in the body, but it should be able to read and show(1) one. Now, how about dist(1) of that old email? I'd have thought it should send the old email verbatim, NUL and all. If that causes a bounce then the sender can MIME-forward instead with a single message/rfc822 part. -- Cheers, Ralph.
Re: mysterious c0 80
Ken Hornstein wrote: > However, it seems like Mike's problem is NOT that; the last two bytes of > his draft file are 00 a0. Cy's bug report said that can happen anywhere, > though. ! > I know this change was to handle NUL bytes in outgoing messages, but I am > wondering if maybe we should reject such drafts? Seems like any message > actually sent with a NUL in it would be rather unfriendly. That might > break things for people using MH-E, though, and as we've seen before that > has a very long release cycle. yeah, it's not so much that it does not get releases, as people do not install them often. This break, if it has a good/clear error would get fixed, I think. signature.asc Description: PGP signature
Re: mysterious c0 80
>> ...draft file does NOT contain a '\n' as the last character? My >> memory is that for some strange reason Emacs like to default to doing >> that. I suspect we do not test for that. > >A POSIX text file is zero or more lines where a line is zero or more >bytes terminated by '\n'. I don't make the news, I just report it. My vague memory is that this is centered around Emacs having it's roots in a pre-UNIX operating system. However, it seems like Mike's problem is NOT that; the last two bytes of his draft file are 00 a0. Cy's bug report said that can happen anywhere, though. I know this change was to handle NUL bytes in outgoing messages, but I am wondering if maybe we should reject such drafts? Seems like any message actually sent with a NUL in it would be rather unfriendly. That might break things for people using MH-E, though, and as we've seen before that has a very long release cycle. According to RFC 5322, a NUL in a message body is not permitted. From §3.5: body= (*(*998text CRLF) *998text) / obs-body text= %d1-9 /; Characters excluding CR %d11 / ; and LF %d12 / %d14-127 Obviously if you are sending binary, you can (RFC 2045 explicitly disallows NUL when sending 8bit). I realize that I started this whole mess last time I asked about this. Sigh. --Ken
Re: mysterious c0 80
Hi Michael, > hexdump of this draft folder before I hit send: > > 520 2074 6f66 2072 6874 7461 0a2e 430a 756f > 530 646c 6220 2e65 0a0a 000a > > Note 00 0a. If one wrongly encodes NUL as two-byte UTF-8, intended for U+0080 to U+7fff, one gets c0 80. This is the bastard https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 -- Cheers, Ralph.
Re: mysterious c0 80
Ralph Corderoy wrote: > Hi, > Ken wrote: >> ...draft file does NOT contain a '\n' as the last character? My >> memory is that for some strange reason Emacs like to default to doing >> that. I suspect we do not test for that. > A POSIX text file is zero or more lines where a line is zero or more > bytes terminated by '\n'. Sure. Why mh-e/emacs would wind up writing a nul in there is a mystery, but at least it's a mystery that I can track down to the right place. > We shouldn't pander to alien ‘text’ editors and their non-text files. :-) This email does not have a nul in it. Maybe it will after I sign it. signature.asc Description: PGP signature
Re: mysterious c0 80
Ken Hornstein wrote: > Stupid question time: is it possible this bug is only triggered if the > draft file does NOT contain a '\n' as the last character? My memory is > that for some strange reason Emacs like to default to doing that. I suspect > we do not test for that. Could be. hexdump of this draft folder before I hit send: 520 2074 6f66 2072 6874 7461 0a2e 430a 756f 530 646c 6220 2e65 0a0a 000a Note 00 0a. signature.asc Description: PGP signature
Re: mysterious c0 80
Hi, Ken wrote: > ...draft file does NOT contain a '\n' as the last character? My > memory is that for some strange reason Emacs like to default to doing > that. I suspect we do not test for that. A POSIX text file is zero or more lines where a line is zero or more bytes terminated by '\n'. We shouldn't pander to alien ‘text’ editors and their non-text files. MH-E would presumably ensure or warn if the configuration isn't suitable for Unix? -- Cheers, Ralph.
Re: mysterious c0 80
Ken Hornstein wrote: >> It certainly includes that commit above. >> I updated just last week before starting this thread actually. >> Looking at my outbox, I think it did start when I upgraded. >> >> I tried "git revert 8f897f65", but it results in a bunch of conflicts, which >> I decided not to investigate. > Could you just do a 'git checkout 8f897f65^' and try that? Done. Using that in this email. obiwan-[/sandel/src/nmh](2.6.6) mcr 10007 %mhparam -version mhparam -- nmh-1.8+dev 1.8-RC1-29-g82b04d31 built 2024-01-02 13:37:27 + on obiwan This starts to seem like it's a buffer overread and c0 80 just happens to be consistent garbage. signature.asc Description: PGP signature
Re: mysterious c0 80
Stupid question time: is it possible this bug is only triggered if the draft file does NOT contain a '\n' as the last character? My memory is that for some strange reason Emacs like to default to doing that. I suspect we do not test for that. --Ken
Re: mysterious c0 80
>It certainly includes that commit above. >I updated just last week before starting this thread actually. >Looking at my outbox, I think it did start when I upgraded. > >I tried "git revert 8f897f65", but it results in a bunch of conflicts, which >I decided not to investigate. Could you just do a 'git checkout 8f897f65^' and try that? --Ken
Re: mysterious c0 80
David Levine wrote: >> === >> All 101 tests passed >> (19 tests were not run) >> === > That's good. Though I'm surprised that 19 tests weren't run. That happens > when nmh isn't configured with some options. 19 seems high to me. could be. It would be some library test, as I basically just --prefix=/sandel >> I tried running "test/post/test-post-basic" manually, and it seemed to just >> install stuff to test/testdir/inst, but I couldn't tell if it actually ran a >> test. Do I need some arguments to the test? > No, the tests don't take arguments. Some require helper programs. To make > sure those are built, it's best to run a single test this way: > make check TESTS=test/post/test-post-basic make[1]: Entering directory '/sandel/src/nmh' PASS: test/post/test-post-basic = 1 test passed = make[1]: Leaving directory '/sandel/src/nmh' In pretty green. signature.asc Description: PGP signature
Re: mysterious c0 80
Michael wrote: > === > All 101 tests passed > (19 tests were not run) > === That's good. Though I'm surprised that 19 tests weren't run. That happens when nmh isn't configured with some options. 19 seems high to me. > I tried running "test/post/test-post-basic" manually, and it seemed to just > install stuff to test/testdir/inst, but I couldn't tell if it actually ran a > test. Do I need some arguments to the test? No, the tests don't take arguments. Some require helper programs. To make sure those are built, it's best to run a single test this way: make check TESTS=test/post/test-post-basic If the test succeeds, it exits with 0 status. And that test shouldn't produce any output if it succeeds. David
Re: message-Id has localhost
Ken Hornstein wrote: > To Mike's question: >> Can we just use "localname" from mts.conf? > We COULD, it would just be wrong for some people. Agreed, but it was the first place that I looked to fix things. > That's the "local" hostname, and is used for a bunch of things INCLUDING > constructing the default hostname for email addresses. But here's a > thought experiment: let's say you set it to 'gmail.com' because your > email is hosted at gmail. There's no way you could guarantee your > Message-ID isn't going to be used by gmail.com already. Yes, you could I think that's reasonable, but is there actually anything anyone could do here? They really need to pick something else which is not gmail.com. > things. We could add another knob, but honestly I'd rather people just > use 'random' if the existing logic doesn't work for you. That's fair enough. I can live with random as well. > Well, technically, it's constructing the Message-ID based on the value > of the 'j' Sendmail macro, which is used for a ton of things; that macro > value is configurable and in my limited sendmail experience you usually > do explicitly configure it (I do not know what that defaults to). Yes, exactly, I was going to quibble at your analysis, but it wasn't worth it. All I'm saying is that gethostname() is probably better default than whatever it was that you posted that canonicalized it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: mysterious c0 80
David Levine wrote: >> >> What version of nmh are you using? There was a recent bug reported >> >> by Cy Schubert that may be the cause of this: >> >> >> >> http://savannah.nongnu.org/bugs/?65002 >> > >> >Interesting. Can anyone replicate this bug? Michael, are you running >> >on FreeBSD or something else? >> >> I haven't tried yet; it was on my list to look at. > test/post/test-post-basic should catch it. I tried make check. === All 101 tests passed (19 tests were not run) === I tried running "test/post/test-post-basic" manually, and it seemed to just install stuff to test/testdir/inst, but I couldn't tell if it actually ran a test. Do I need some arguments to the test? signature.asc Description: PGP signature
Re: mysterious c0 80
David Levine wrote: > Interesting. Can anyone replicate this bug? Michael, are you running > on FreeBSD or something else? Linux "debian 12" (actually systemd-free devuan 4).
Re: mysterious c0 80
David Levine wrote: > Ken wrote: >> What version of nmh are you using? There was a recent bug reported >> by Cy Schubert that may be the cause of this: >> >> http://savannah.nongnu.org/bugs/?65002 savannah keeps saying that I didn't pick a group, even after logging and going to the nmh bug list. I can't seem to even copy the stupid summary with that commit id... 8f897f65. > Interesting. Can anyone replicate this bug? Michael, are you running > on FreeBSD or something else? I am presently running 1.8+dev, commit fefdea3fd1b29686418df45063854ed2e3880488 which is Dec.3 origin/master. (Your commit) It certainly includes that commit above. I updated just last week before starting this thread actually. Looking at my outbox, I think it did start when I upgraded. I tried "git revert 8f897f65", but it results in a bunch of conflicts, which I decided not to investigate. signature.asc Description: PGP signature
Re: mysterious c0 80
Ken wrote: > >> What version of nmh are you using? There was a recent bug reported > >> by Cy Schubert that may be the cause of this: > >> > >>http://savannah.nongnu.org/bugs/?65002 > > > >Interesting. Can anyone replicate this bug? Michael, are you running > >on FreeBSD or something else? > > I haven't tried yet; it was on my list to look at. test/post/test-post-basic should catch it. David
Re: mysterious c0 80
>> What version of nmh are you using? There was a recent bug reported >> by Cy Schubert that may be the cause of this: >> >> http://savannah.nongnu.org/bugs/?65002 > >Interesting. Can anyone replicate this bug? Michael, are you running >on FreeBSD or something else? I haven't tried yet; it was on my list to look at. --Ken
Re: mysterious c0 80
Ken wrote: > What version of nmh are you using? There was a recent bug reported > by Cy Schubert that may be the cause of this: > > http://savannah.nongnu.org/bugs/?65002 Interesting. Can anyone replicate this bug? Michael, are you running on FreeBSD or something else? David
Re: message-Id has localhost
Hi Andy, > I also find it hard to beleive that someone wants the MUA to have a > specific Message-ID for their email People do all kinds of odd things. Like fully justify text on a media with coarse adjustment. :-) Wanting to specify the whole message-ID field is distinct from wanting to set the trailing ‘@...’ part. - The whole field could just be given as yet another field in the header, though currently nmh will complain it's an ‘illegal header line’. - Setting just the domain part is a more common need. It's tied in to adjusting the From field, and which party takes on the email for delivery. Otherwise, emails from foo.com leak the bar.com identity. -- Cheers, Ralph.
Re: message-Id has localhost
Hi Ken, > I do not believe there is solution to this that will universally work, > or even work in a large majority of cases considering the > configuration of the modern Internet. Agreed. That's why I suggested allowing ‘@...’ in addition to ‘local’ and ‘random’. It allows the user to route around the imperfect heuristics. -- Cheers, Ralph.
Re: message-Id has localhost
tl;dr: old man grouses at clouds On Sun, Dec 31, 2023 at 11:57 AM Ken Hornstein wrote: > [...] Sendmail, > yes, it looks like you could change it if you really want to; it also > defaults to something based on the local hostname. I am personally > skeptical that people actually configure this. > FWIW, MIT's campus computer network (Athena) did this for a long time, because that network was composed of thousands of workstations that did not normally receive mail and all wanted to send mail that came from, for example, rather than something like < yand...@w20-575-77.mit.edu>. I imagine that they stopped doing this when MIT moved to centralized (Office 365-based, gack) mail infrastructure rather than running their own (with the attendant large reductions in overhead, functionality, stability, etc.) That said, this is probably the exception that proves the rule, as keeping the sendmail.cf changes up to date was a constant sink for work even before the advent of dkim/dmarc/spf/eieio. ~Chad
Re: message-Id has localhost
>I also find it hard to beleive that someone wants the MUA to have a >specific Message-ID for their email, but there is at least one software >that I'm aware of that does act upon the contents of it: > >http://smarden.org/qconfirm/qconfirm-check-mid.1.html I mean, yes, it looks for messages based on Message-IDs in the References header; I think it would work fine with 'random'. >> My personal feeling is that the people who (a) care about generating a >> local Message-ID, and (b) actually care WHAT appears right of the '@' >> either need to configure their system appropriately or write code to >> change nmh behavior. > >I think that's reasonable. I don't see anything necessarily wrong with >nmh being able to generate a Message-ID so I'm sure patches would be >considered if someone offered. Just so I'm clear, I'm fine with people submitting patches to change the current behavior. --Ken
Re: message-Id has localhost
Thus said Ken Hornstein on Sun, 31 Dec 2023 15:00:38 -0500: > >Can we just use "localname" from mts.conf? > > We COULD, it would just be wrong for some people. I definitely don't want nmh generating Message-ID unless I ask it to do so as my MTA is already correctly configured. The MTA that I use, qmail, does not use the hostname, it uses one of 2 configuration files... /var/qmail/control/me by default unless /var/qmail/control/idhost exists in which case it uses that. However, that only allows me to customize the right-side of the Message-ID. The left-side is predetermined and uses basically what the RFC recommends (a timestamp and a PID). Andy
Re: message-Id has localhost
Thus said Ken Hornstein on Sun, 31 Dec 2023 11:56:38 -0500: > I am personally skeptical that people actually configure this. I also find it hard to beleive that someone wants the MUA to have a specific Message-ID for their email, but there is at least one software that I'm aware of that does act upon the contents of it: http://smarden.org/qconfirm/qconfirm-check-mid.1.html It seems reasonable to believe that I may want control over the Message-ID for the purpose of making this work, however, it's definitely not required that the MUA be responsible for this. > My personal feeling is that the people who (a) care about generating a > local Message-ID, and (b) actually care WHAT appears right of the '@' > either need to configure their system appropriately or write code to > change nmh behavior. I think that's reasonable. I don't see anything necessarily wrong with nmh being able to generate a Message-ID so I'm sure patches would be considered if someone offered. Andy
Re: message-Id has localhost
>> [...] Sendmail, >> yes, it looks like you could change it if you really want to; it also >> defaults to something based on the local hostname. I am personally >> skeptical that people actually configure this. >> > >FWIW, MIT's campus computer network (Athena) did this for a long time, >because that network was composed of thousands of workstations that did not >normally receive mail and all wanted to send mail that came from, for >example, rather than something like < >yand...@w20-575-77.mit.edu>. What you're talking about is a very common way of configuring Sendmail and I've personally done that many times; I call that a "site" configuration where all email that is submitted to the main Sendmail server with an internal hostname (or no hostname) is re-written to have the 'site' domain name. But what I was specifically talking about was that I am skeptical that anyone specifically configures a Message-ID header to be added by sendmail that is different than the default, which is based on the 'j' macro. I just looked in my wife's Sendmail 'bat' book and it says j holds the FQDN of the local machine, which probably means it does something similar to what nmh does; you can override that value if Sendmail gets it wrong, _HOWEVER_ it's used by a bunch of things and not just for Message-ID generation. So to one of Ralph's earlier points, it seems like we are using some MTA prior art, it just that it doesn't work for everybody. --Ken
