Given that I'm the OP of this thread I feel entitled to officially
closing it.
Those interested in my proposal will find my latest version of the
patch in this new thread:
https://marc.info/?t=16961663101=1=2
For my part, what was said in this thread has already been assimilated
and
More changes:
- I changed my overpopulated Message-ID for the function used by
smtpd(8) (generate_uid()). Now the Message-ID generated by mail(1)
is identical to the one generated by smtpd(8).
- Added a conditional to skip adding the Message-ID if the machine
doesn't have hostname
Added random number to Message-ID to get more unique string.
Index: cmd3.c
===
RCS file: /cvs/src/usr.bin/mail/cmd3.c,v
retrieving revision 1.30
diff -u -p -r1.30 cmd3.c
--- cmd3.c 8 Mar 2023 04:43:11 - 1.30
+++
Avoid printing some headers to stdout when responding from the interface
(when you type r or R), especially Conten-Transfer-Enconding and
Content-Type since the values showed before sending are not the ones
that will be used after processing the body when sending.
Index: cmd3.c
On Sun Oct 1 15:19:12 2023, Walter wrote
> I decided to add another header, "Message-ID". Sending mails from my
> patched mail(1) I realized that it's convenient the MUA itself add the
> Message-ID (the one in this message was generated by my patch), if you
> relegate this to the MTA, your MUA
Opening a new clean thread.
First of all, I'm sending this message from my patched mail(1), take a
look at the headers. :-)
I tried what each and everyone suggested to me, the only way to know for
sure what works and what doesn't. If you decide that this modification
is too much for a simple
On Mon, 25 Sep 2023 19:00:15 +0200, Hiltjo Posthuma wrote:
> On Mon, Sep 25, 2023 at 03:13:03PM +0200, Walter Alejandro Iglesias wrote:
> > This new version, when it detects invalid utf-8 in the body saves a
> > dead.letter, prints the following message and exits.
> >
>
This new version, when it detects invalid utf-8 in the body saves a
dead.letter, prints the following message and exits.
$ mail -s hello user < invalid_utf8.txt
Invalid or incomplete multibyte or wide character
. . . message not sent.
Index: send.c
On Sun, Sep 24, 2023 at 11:12:10AM -0300, Crystal Kolipe wrote:
> On Sun, Sep 24, 2023 at 12:37:08PM +0200, Walter Alejandro Iglesias wrote:
> > +static int
> > +not_utf8(FILE *message, int len)
> > +{
> > + int n, ulen;
> > + unsigned char s[len];
>
> P
Hi Stefan,
Do you like this?
Index: send.c
===
RCS file: /cvs/src/usr.bin/mail/send.c,v
retrieving revision 1.26
diff -u -p -r1.26 send.c
--- send.c 8 Mar 2023 04:43:11 - 1.26
+++ send.c 24 Sep 2023 10:33:11
On Sun, Sep 24, 2023 at 09:47:41AM +0200, Stefan Sperling wrote:
> In the UTF-8 locale I can trigger an error message with your program
> by sending the latin1 code for a-acute to stdin. I suppose your test
> command didn't actually send latin1 to stdin for some reason?
>
> $ perl -e 'printf
Hi Ingo,
On Thu, Sep 21, 2023 at 03:04:24PM +0200, Ingo Schwarze wrote:
> In general, the tool for checking the validity of UTF-8 strings
> is a simple loop around mblen(3) if you want to report the precise
> positions of errors found, or simply mbstowcs(3) with a NULL pwcs
> argument if you are
> On Thu, Sep 21, 2023 at 02:12:50PM +0200, Stefan Sperling wrote:
> > Your implementation lacks proper bounds checking. It accesses
> > s[i + 3] based purely on the contents of the input string, without
> > checking whether len < i + 3. Entering the while (i != len) loop with
You surely meant
On Fri, Sep 22, 2023 at 06:57:24AM +0200, Walter Alejandro Iglesias wrote:
> Below, a version without utf8 parser. I added a ASCII check for the
> subject. The day will come when wscons support UTF-8, right? In the
> meantime, just by being careful not to type iso-latin characters whil
Hi Ingo,
On Thu, Sep 21, 2023 at 03:04:24PM +0200, Ingo Schwarze wrote:
> As Stefan says, adding a hand-written UTF-8 parser to mail(1) is
> clearly not acceptable.
Below, a version without utf8 parser. I added a ASCII check for the
subject. The day will come when wscons support UTF-8, right?
On Thu, Sep 21, 2023 at 02:12:50PM +0200, Stefan Sperling wrote:
> On Thu, Sep 21, 2023 at 01:25:01PM +0200, Walter Alejandro Iglesias wrote:
> > I corrected many of the things you pointed me, but not all. The
> > function I use to check utf8 is mine, I use it in a pair of litt
On Thu, Sep 21, 2023 at 11:26:11AM +0200, Omar Polo wrote:
> On 2023/09/21 10:55:47 +0200, Walter Alejandro Iglesias
> wrote:
> > On Wed, Sep 20, 2023 at 08:36:23PM +0200, Walter Alejandro Iglesias wrote:
> > > On Wed, Sep 20, 2023 at 07:44:12PM +0200, Walter Ale
On Wed, Sep 20, 2023 at 08:36:23PM +0200, Walter Alejandro Iglesias wrote:
> On Wed, Sep 20, 2023 at 07:44:12PM +0200, Walter Alejandro Iglesias wrote:
> > And this new idea simplifies all to this:
>
> In case anyone else is worried. Crystal Kolipe already pointed me out
> t
On Wed, Sep 20, 2023 at 07:44:12PM +0200, Walter Alejandro Iglesias wrote:
> And this new idea simplifies all to this:
In case anyone else is worried. Crystal Kolipe already pointed me out
that a better UTF-8 checking is needed, I know, I'll get to that
tomorrow.
On Wed, Sep 20, 2023 at 06:13:10PM +0200, Walter Alejandro Iglesias wrote:
> Now I was investigating exactly that :-) (like Mutt also does): to make
> mail(1) automatically set the appropiate MIME headers when it detects
> any utf8 characters in the body text. So, you don't like
On Wed, Sep 20, 2023 at 05:30:08PM +0200, Ingo Schwarze wrote:
> Hi,
>
> i checked the following points:
>
> * Even though RFC 2049 section 2 bullet point 1 only *requires*
>MIME-conformant MUAs to always write the header "MIME-Version:
>1.0" - and mail(1) is most certainly not
On Wed, Sep 20, 2023 at 10:30:31AM +, Klemens Nanni wrote:
> Except for mandoc(1) and other manuals where "utf8" is a literal keyword,
> our manuals consistently use upper-case UTF-8 for what is an abbreviation,
> so this should do as wlel.
>
> > .It Fl n
> > Inhibits reading
> > .Pa
Hi Ingo,
I did what you suggested me, I investigated a bit and you were right in
that the MIME-Version header was necessary. This new set of patches
add the following headers (hardcoded as you suggested me):
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
On Tue, Sep 19, 2023 at 05:48:01PM +0200, Ingo Schwarze wrote:
> Hi Walter,
>
> i did not look closely at the patch yet, and i did not dig for standards
> documents, which one should almost certainly do before committing such
> a patch unless one knows all the relevant standards by heart (which i
I'd forgotten that adding a "charset" specification to the Content-Type
header is also needed. In the *new* set of patches below, besides I
corrected some other errors, I added a '-y' option to specify utf-8
character set:
$ mail -s Hello -e quoted-printable -y "text/plain;charset=utf-8" \
Hello everyone,
Years ago I made a suggestion here about this, now that I am a little
less ignorant in C I dared with the patches below, they add a '-e'
option to mail(1) to pass a Content-Transfer-Encoding on the command
line. First you convert the text in "message.txt" to quoted-printable
or
Hi Raf,
On Thu, Sep 07, 2023 at 12:08:00PM +0100, Raf Czlonka wrote:
> On Thu, Sep 07, 2023 at 08:04:43AM BST, Walter Alejandro Iglesias wrote:
> > Dear OpenBSD developers,
> >
> > On Aug 2 I reported this bug:
> >
> > https://marc.info/?l=openbsd-bugs
Dear OpenBSD developers,
On Aug 2 I reported this bug:
https://marc.info/?l=openbsd-bugs=169100763926909=2
After fiddling around I found a solution that works for both vi base and
nvi from ports:
https://marc.info/?l=openbsd-bugs=16926218514=2
Since nobody answered me in bugs@ I sent
I'm not an OpenBSD developer but, allow me to share my opinion about
this, please.
On May 15 2023, Okan Demirmen wrote:
> On Mon 2023.05.15 at 10:41 +0200, Matthieu Herrb wrote:
> > Last year I mentionned that I think we should retire twm. It's really
> > too old and missing support for the
Hi Matthiew,
On Nov 11 2022, Walter Alejandro Iglesias wrote:
> On Nov 11 2022, Matthieu Herrb wrote:
> > On Fri, Nov 11, 2022 at 03:17:21PM +0100, Walter Alejandro Iglesias wrote:
> > > On Nov 11 2022, Matthieu Herrb wrote:
> > > > Hi,
> > > >
>
On Nov 11 2022, Matthieu Herrb wrote:
> On Fri, Nov 11, 2022 at 03:17:21PM +0100, Walter Alejandro Iglesias wrote:
> > On Nov 11 2022, Matthieu Herrb wrote:
> > > Hi,
> > >
> > > So the patch provided by Adam Jackson upstreams is completely buggy.
> > >
On Nov 11 2022, Matthieu Herrb wrote:
> Hi,
>
> So the patch provided by Adam Jackson upstreams is completely buggy.
>
> - the logic to setup the new locking function was busted
> - I've observed cases where even the XGetIfEvent() function gets
> re-rentered. So the flags does in fact need to
Hello Matthieu,
On Nov 01 2022, Matthieu Herrb wrote:
> Hi,
>
> here's a libX11 patch that needs some wide testing, especially from
> people who have experienced issues with various applications (fvwm[23]
> from ports, Motif applications with Drag'n'Drop,..) with the upgrade
> to libX11 1.8.1,
Hello Okan,
On Oct 13 2022, Okan Demirmen wrote:
> **incomplete** but i think the right direction to use ascent+descent,
> however i've missed something, so take this with a sea full of salt (and
> yes, i'm still alive...). the menu rect is too big (by a factor of
> entries i think) now and
On Oct 13 2022, Walter Alejandro Iglesias wrote:
> On Oct 13 2022, Klemens Nanni wrote:
> > On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote:
> > > And I keep missing it! I can't reproduce this - can you share the font
> > > you're using maybe?
> >
On Oct 13 2022, Klemens Nanni wrote:
> On Thu, Oct 13, 2022 at 08:28:50AM -0400, Okan Demirmen wrote:
> > And I keep missing it! I can't reproduce this - can you share the font
> > you're using maybe?
>
> Whatever is the default, I never fiddled with fonts in X, no xorg.conf,
> `cwm -c/dev/null'
In the situation you kill a client and it happens the cursor lands in
the root window no window has focus. Then you Alt-Tab to cycle and the
window which gets the pointer is not the last focused but the previous
one.
Index: client.c
Hi Ingo,
In article <20180329235743.ge59...@athene.usta.de> Ingo Schwarze
wrote:
> > Can I do anything to fix this?
>
> Yes.
>
I've always wondered why groff did that nonsense with man pages. I
remember discussing this same issue in groff mailing lists years ago
(with E.
In article <20171013160142.gb48...@symphytum.spacehopper.org> Stuart Henderson
wrote:
> I had an OK from Ingo for mine, but I prefer your version. OK with me!
>
One more (funny) thing.
After reading the man page, besides reading some info in the openssh
site I googled
In article <20171013145400.GA82524@harkle> Jason McIntyre <j...@kerhand.co.uk>
wrote:
> On Fri, Oct 13, 2017 at 02:01:17PM +0100, Stuart Henderson wrote:
> > On 2017/10/13 12:57, Walter Alejandro Iglesias wrote:
> > > In sshd_config(5), to avoid confusio
Hi Stuart,
On Fri, Oct 13, 2017 at 02:01:17PM +0100, Stuart Henderson wrote:
> How about a briefer alternative that points people towards the
> more self-explanatory option keyword?
Or even better, to modify the first paragraph to put it clear from the
very start there are *four* arguments, not
In sshd_config(5), to avoid confusion with PermitRootLogin options.
Original:
If this option is set to *prohibit-password* or *without-password*,
password and keyboard-interactive authentication are disabled for
root.
Proposed:
If this option is set to *prohibit-password* (renamed from
On Mon, Jun 05, 2017 at 10:46:49PM +0200, Ingo Schwarze wrote:
> Hi Walter,
>
> Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 09:21:31PM +0200:
> > On Mon, Jun 05, 2017 at 06:06:34PM +0200, Ingo Schwarze wrote:
> >> Walter Alejandro Iglesias wrote on Mon, Ju
In article <20170605192131.ga60...@server.roquesor.com> you wrote:
>
>Encodings using more bytes than required are invalid. In particular,
>1100 and 1101 are not valid start bytes, the byte after
>1110 must be at least 1010, and the byte after must
>be at
On Mon, Jun 05, 2017 at 06:06:34PM +0200, Ingo Schwarze wrote:
> Hi Walter,
>
> Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 04:50:21PM +0200:
>
> > report (I'm on chapter 2 of K :-)). I wish with time I'll learn how
> > to do it.
>
> IIRC, you
Just to applogize to developers here,
I'm still not skilled enough to make a proper patch or a clear bug
report (I'm on chapter 2 of K :-)). I wish with time I'll learn how
to do it. I came to the ksh utf8 discussion because I've been playing
with some mail mime encoder just to learn C and
in
implementing some utf-8 version of ksh as a package for those who think
they need utf-8 support in console (don't count me among them).
- Forwarded message from Walter Alejandro Iglesias <w...@roquesor.com> -
Date: Fri, 2 Jun 2017 14:47:55 +0200
From: Walter Alejandro Igles
On Mon, May 29, 2017 at 07:28:37PM +0200, Ingo Schwarze wrote:
> Hi Walter,
>
> Walter Alejandro Iglesias wrote on Mon, May 29, 2017 at 06:44:40PM +0200:
>
> > Are those wide char versions of C functions consistent enough to write
> > a separate implementation to be lo
On Mon, May 29, 2017 at 05:59:34PM +0200, Ingo Schwarze wrote:
> So handling multi-byte "r" should probably be treated as a separate
> issue.
>
I'm just a beginner with C, what I'm about to say is purely intuitive.
As far as I can understand you're trying to adapt the code that works
with ascii
In article <20170528160659.GA46003@lol.local> you wrote:
> Hi Walter,
>
> Thanks for the report, please try out the diff below.
>
The diff works as you explained. It replaces correctly utf-8 with
ascii chars.
Thank you.
I forgot to Cc this here.
- Forwarded message from Walter Alejandro Iglesias <w...@roquesor.com> -
From: Walter Alejandro Iglesias <w...@roquesor.com>
To: Anton Lindqvist <anton.lindqv...@gmail.com>
Subject: Re: ksh(1): vi mode UTF-8 bug
In-Reply-To: <20170519121
I'm thinking I should've explained more in detail what this patch does.
With window managers that implement a window list menu, like fvwm, after
cycling using Alt+Tab, previous and new focused windows, both end in the
front (currently cwm lets the previously focused window overlapped.)
This is
I finally learned how to make the diff using cvs :-)
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.234
diff -u -p -r1.234 client.c
--- client.c6 Feb 2017 18:10:28 - 1.234
+++
Raise previous window after cycling on cwm.
--- client.c.orig Mon Apr 10 14:24:11 2017
+++ client.cMon Apr 10 14:29:14 2017
@@ -645,9 +645,11 @@ match:
void
client_cycle(struct screen_ctx *sc, int flags)
{
- struct client_ctx *newcc, *oldcc;
+ struct client_ctx
I don't know if what I read time ago about how to correctly request a CA
to use with original sendmail is still important and applicable
(currently I use opensmtpd).
As far as I understood, you must use your FQDN as the principal name in
your certificate. That's why I use 'server.roquesor.com'
Nick wrote:
> I found that the current man pages and example file for acme-client
> are confusing and leave one with an imperfect certificate setup, with
> the intermediate certs missing. Doesn't generate an error on
> OpenBSD, but does on some other OSs.
Right. It took me some time to realize
Thanks to the stipple pattern I noticed this:
https://marc.info/?l=openbsd-x11=146506160500583=2
I know it's not relevant or if it's useful for discovering some bug, but
I'd still like to know what's that phantom shadow that appears at the
right bottom of my screen. :-)
57 matches
Mail list logo