From: gilles@poolp.org Subject: Re: Adding Message-ID to mail(1) (diff UPDATED) To: "Walter Alejandro Iglesias" Cc: tech@openbsd.org Date: Fri, 23 Aug 2024 13:22:16 +0000 Sorry for the noise, this is just for the sake of testing something *plonk* August 23, 2024 10:34 AM, "Walter Alejandro Iglesias" wrote: > Hello Steffen, > > On Thu, 22 Aug 2024 20:25:34 +0200 Steffen Nurpmeso wrote: > >> Walter Alejandro Iglesias wrote in >> : >> >> 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 > #include > #include "pathnames.h" > +#include > +#include > +#include > > #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