Sorry for the noise, this is just for the sake of testing something *plonk*


August 23, 2024 10:34 AM, "Walter Alejandro Iglesias" <wai@roquesor.com> wrote:

> Hello Steffen,
> 
> On Thu, 22 Aug 2024 20:25:34 +0200 Steffen Nurpmeso wrote:
> 
>> Walter Alejandro Iglesias wrote in
>> <ZsbcZ_42h6xQdqih@chancha.roquesor.com>:
>> 
>> But you do it.
>> 
>> |On Wed, Aug 21, 2024 at 09:49:16PM +0200, Steffen Nurpmeso wrote:
>> |> Sven M. Hallberg wrote in
>> |> <87ikvu9rgm.fsf@unruhe.p.khjk.org>:
>> 
>> As he does.
>> But "Unruhe" is a nice German word, thus.
>> 
>> |>|Claus Assmann on Wed, Aug 21 2024:
>> |>|> So if two people on the same system send a message within the
>> |>|> same seccond they get the same Message-ID?
>> |>|
>> |>|Yeah. Just pick 16 bytes (128 bits) of randomness, print them in hex,
>> |>|and be done with it. Anything else is needlessly fanciful.
>> |>
>> |> One of the terrible changes in email practice as i see it.
>> |> I love to see date and time therein.
>> |> I think these 80 or what byte randoms that Gmail and such use are
>> |> totally brain dead and inhuman (to the eye), i see no value, there
>> |> is nothing "to reveal", but a lot to loose (imho).
>> |
>> |I agree with this. Besides of inhuman that's what I see as "needlessly
>> |fanciful". I make mistakes like everyone else, especially with this
>> |since I'm learning, but doing unnecessary or fanciful things, no, that's
>> |not me. Life experience taught me that the best way to be original is
>> |not to try to be original, so my first idea was taken from a wikipedia
>> |article. :-)
>> |
>> |Anyway, even when what Claus says is not easy to acomplish he has a
>> 
>> *He* seems to use mutt and that has a date and time (by default).
>> 
>> |point.
>> 
>> Stir it up!
> 
> Except this one, sent from my patched mail(1), the Message-IDs you see
> in the rest of my messages in this thread are Mutt's. I've been using
> mail(1) in this lists, to test and show that my patches *work* (in case
> this aspect is even considered in this project :-),) but since they
> asked me to split and reduce the size of my diffs (now they are six
> counting the one including all the work), depending on which patch I'm
> working on I cannot use mail(1). I still like the idea of including the
> date string in Message-ID but since the randomness is necessary and, for
> the same reason I explained I try to be as economic as possible I'm
> going to stand in this last option. With one last change, instead of
> only hexadecimal numbers I'll use the whole alphabet with lower and
> upper case (diff UPDATED at the bottom.) So, I stirred it up even more,
> now is a chantilly cream. :-)
> 
> What I'm going to say next is a practical example to explain everyone
> the approach and motivation of my mail(1) patches.
> 
> Speaking of "needlessly fanciful." Surely you also usually visit
> mutt-dev@ and noticed the patches I proposed to be able to change the
> keyboard shortcut of the abort command to 'Esc' which, as happens with
> many ncurses based applications, is deeply hardcoded to the
> emacs-user-friendly Ctrl-G. When I posted there my first proposal, in
> 2017, I received many objections from users (which caught my attention
> being a mailing list for developers,) I dare to say most of them were
> "needlessly fanciful" objections. I don't know how many people took
> care of the maintenance of Mutt back then but it gave me the impression
> that it was only one guy and the same that is still taking care of it
> today. He took advantage of the objections of users to disengage from
> my proposal, he did not even look at my patches. At that moment he was
> very busy with some SSL issue which many would think it's a more
> important matter than adding some key binding to the interface, right?
> Well, if you understand that a MUA is a "user interface", and features
> like SMTP, IMAP, POP2, SSL are (or at least should be) better handled by
> software designed and maintained for that purpose, you see that it's
> exactly the opposite. A MUA maintainer should have more time and space
> to attend to a user interface related issue than a SSL one.
> 
> Which is the current trend, the tackier people are, the more addicted
> they are to accessories. "What, your hammer doesn't have wifi?!" Of
> course, removing the handle from the hammer to make it safer is the
> other extreme of idiocy. Common sense is a rare gem today.
> 
> As a side note. From this it can be deduced what I think of your s-nail
> project. Anyway, I'd expressed my opinion to you privately years ago, I
> hope I didn't offend you with what I said.
> 
> Index: def.h
> ===================================================================
> RCS file: /cvs/src/usr.bin/mail/def.h,v
> diff -u -p -r1.17 def.h
> --- def.h 28 Jan 2022 06:18:41 -0000 1.17
> +++ def.h 22 Aug 2024 11:02:15 -0000
> @@ -55,6 +55,9 @@
> #include <limits.h>
> #include <vis.h>
> #include "pathnames.h"
> +#include <sys/types.h>
> +#include <sys/socket.h>
> +#include <netdb.h>
> 
> #define APPEND /* New mail goes to end of mailbox */
> 
> Index: extern.h
> ===================================================================
> RCS file: /cvs/src/usr.bin/mail/extern.h,v
> diff -u -p -r1.30 extern.h
> --- extern.h 21 May 2024 05:00:48 -0000 1.30
> +++ extern.h 22 Aug 2024 11:02:15 -0000
> @@ -129,6 +129,7 @@ int forward(char *, FILE *, char *, int
> void free_child(pid_t);
> int from(void *);
> off_t fsize(FILE *);
> +char* genmsgid(void);
> int getfold(char *, int);
> int gethfield(FILE *, char *, int, char **);
> int gethfromtty(struct header *, int);
> Index: send.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/mail/send.c,v
> diff -u -p -r1.26 send.c
> --- send.c 8 Mar 2023 04:43:11 -0000 1.26
> +++ send.c 22 Aug 2024 11:02:15 -0000
> @@ -525,6 +525,8 @@ puthead(struct header *hp, FILE *fo, int
> fmt("To:", hp->h_to, fo, w&GCOMMA), gotcha++;
> if (hp->h_subject != NULL && w & GSUBJECT)
> fprintf(fo, "Subject: %s\n", hp->h_subject), gotcha++;
> + if (fo != stdout)
> + fprintf(fo, "Message-ID: %s\n", genmsgid()), gotcha++;
> if (hp->h_cc != NULL && w & GCC)
> fmt("Cc:", hp->h_cc, fo, w&GCOMMA), gotcha++;
> if (hp->h_bcc != NULL && w & GBCC)
> Index: util.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/mail/util.c,v
> diff -u -p -r1.2 util.c
> --- util.c 26 Dec 2022 19:16:01 -0000 1.2
> +++ util.c 22 Aug 2024 11:02:15 -0000
> @@ -641,3 +641,44 @@ clearnew(void)
> }
> }
> }
> +
> +/* Generate Message-ID */
> +char*
> +genmsgid(void)
> +{
> + size_t n = 0;
> + char c;
> + static char r[24];
> + struct addrinfo hints, *info, *p;
> + char *fqdn = NULL;
> + static char hostname[NI_MAXHOST];
> + static char buf[sizeof(r) + sizeof(hostname) + 4];
> + int error = 0;
> +
> + while (n < sizeof(r) - 1) {
> + c = arc4random_uniform(173);
> + if (isalnum(c) && snprintf(&r[n++], 2, "%c", c) != 1)
> + errx(1, "snprintf");
> + }
> +
> + if (gethostname(hostname, sizeof(hostname)))
> + errx(1, "genmsgid: gethostname");
> +
> + memset(&hints, 0, sizeof hints);
> + hints.ai_family = AF_UNSPEC;
> + hints.ai_socktype = SOCK_STREAM;
> + hints.ai_flags = AI_CANONNAME;
> +
> + if (getaddrinfo(hostname, NULL, &hints, &info) != 0)
> + errx(1, "genmsgid: getaddrinfo");
> +
> + for (p = info; p != NULL; p = p->ai_next)
> + fqdn = p->ai_canonname;
> +
> + error = snprintf(buf, sizeof(buf), "<%s@%s>", r, fqdn);
> + if (error < 0 || error >= sizeof(buf))
> + errx(1, "genmsgid: snprintf");
> +
> + freeaddrinfo(info);
> + return(buf);
> +}
> 
> --
> Walter