On 2023-12-12 15:17:29 -0500, Derek Martin wrote:
> On Wed, Dec 06, 2023 at 03:10:11PM +0100, Vincent Lefevre wrote:
> > The behavior of SIGINT (typically generated by Ctrl-C in the terminal)
> > is not documented.
> >
> > It currently asks whether to exit, w
box?" or
"Exit Mutt without cleanup?", since does
if (Context)
{
mx_fastclose_mailbox (Context);
FREE (&Context);
}
but mutt_query_exit() doesn't.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
s configurable with $message_id_format
(which I'm using), and I don't see any problem with this.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
easons) and my_hdr is not honored,
does not send a copy to myself.
A possible configuration could be to say which my_hdr headers should
be added by . A list of headers could be given with
the same syntax as ignore/unignore.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible v
the links. The current solution is to copy-paste
links from Mutt to the browser.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2022-05-13 21:55:12 +0200, Daan van Rossum wrote:
> * on Friday, 2022-05-13 19:49 +0200, Vincent Lefevre
> wrote:
> > A better tool could be to convert the text to HTML with just
> > URL recognition to generate URL links (and
> > perhaps a bit more), and run a web brow
On 2022-05-13 21:55:12 +0200, Daan van Rossum wrote:
> There is the 'urlscan' tool that does exactly this. It does the job,
> without using the terminal's url detection functionality.
I didn't know it. Mutt's manual mentions "urlview". So I think that
it s
line count without inserting hard line breaks.
Well, it would be necessary when one uses markers. Otherwise, a "+"
is inserted in URLs (or Mutt should have a feature to disable markers
in some regexp's).
> [1] https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb
and run a web browser on it.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
->env->from, h->env->sender, h->env->to, h->env->cc, h->env->bcc,
h->env->return_path, h->env->reply_to, h->env->mail_followup_to.
I'm using ~a for that (as "all addresses").
I've attached the current version.
--
Vincent Lef
On 2022-01-28 15:48:39 +0100, Vincent Lefevre wrote:
> On 2022-01-27 09:12:48 -0800, Kevin J. McCarthy wrote:
> > On Thu, Jan 27, 2022 at 02:38:35PM +0100, Vincent Lefevre wrote:
> > > Don't forget to update the copyright year to 2022 where needed.
> >
> > O
On 2022-01-27 09:12:48 -0800, Kevin J. McCarthy wrote:
> On Thu, Jan 27, 2022 at 02:38:35PM +0100, Vincent Lefevre wrote:
> > Don't forget to update the copyright year to 2022 where needed.
>
> Oh goodness, I did forget, thank you. I'll get that done today.
I think th
successful years!
Same here. Thanks a lot, Kevin.
> > It is the only client I have used for over 20 years, and the only
> > client I can envision using in the future.
>
> I migrated from ELM round '97, and haven't looked back since.
I also migrated from ELM, but
On 2022-01-14 14:36:13 +0300, Jean Louis wrote:
> * Vincent Lefevre [2022-01-14 12:20]:
> > On 2022-01-14 11:05:14 +0300, Jean Louis wrote:
> > > I do not see anything that is "against" the RFC5322.
> >
> > You misread it. See my other replies.
> &
On 2022-01-14 14:30:40 -0600, Derek Martin wrote:
> On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote:
> > On 2022-01-13 15:36:04 -0600, Derek Martin wrote:
> > > So... The only difference between this and hdrdefault is that
> > > hdrdefault's order
point is technical. Without a standard prefix, you could get
accumulated ones, as it occurs in practice due to MUAs not following
the RFC.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
t people do not use it. In my mail archives, I can see
only one message with "Sv:" in the subject, and one can see a start
of accumulation of prefixes:
Subject: Sv: Re: Motion 31: V04.2 Revision of proposed Level 1 text
and that was in an international mailing-list (note that there were
no re
hus must be recognized
by all MUAs, so that its use will avoid accumulating mixed prefixes.
If other MUAs don't recognize "Re: ", complain to them; but to
mitigate that, $reply_regexp can already be used. Alternatively,
Mutt could offer the choice not to use a prefix at all, as allowe
l consensus is that this option is
> a bad idea, I will back it out.
OK, thanks.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
and that in the case where it is present "only one instance ... ought to
> be used", it doesn't specifically say that other prefixes couldn't be
> used.
Using another string breaks something like a "should". Though this
is not strictly forbidden, this is
On 2022-01-14 03:26:36 +0100, Vincent Lefevre wrote:
> I strongly disagree with the addition of $reply_prefix
> (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is
> contrary to RFC 5322, and non-standard prefixes are annoying
> in practice and not necessarily recognized by
automatically
with things like wrappers), but he should not be encouraged to
do so (in particular by making this automatic). End users are not
necessarily aware of RFCs and technical issues behind some choices.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML
erefore it is
> redundant, by definition. If you want to argue that redundant means
> something different, please feel free to contact the fine folks at
> Oxford. In any case this is precisely the meaning I intended when I
> wrote it.
It is not redundant when considering one can run co
arlier in the list.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
ally is what you want, all the time, you can
> just make a shell alias:
>
> alias clear="clear --clear-alternate-screen-also"
That doesn't exist, but a solution to clear the alternate screen
is "tput smcup; tput rmcup" (and you can add "clear" if you want
t
On 2021-10-29 14:19:29 -0500, Derek Martin wrote:
> On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> > I was wondering whether this could occur when switching to the
> > alternate screen. But it seems that this is not the case, at least
> > not with Xt
l terminal, things are safe. Users of virtual terminals
(GNU Screen, etc.) should be careful, as older data are sent back to
the real terminal when switching a window, for instance. However, in
case of any issue, the real solution should be to ensure that the
printing feature is disabled.
--
Vincent
On 2021-10-22 10:30:43 -0700, Kevin J. McCarthy wrote:
> On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote:
> > Following my remark about the privacy reason, I think that the patch
> > would be useful to make sure that data are not silently left on the
> > alter
On 2021-10-22 10:13:01 -0700, Kevin J. McCarthy wrote:
> On Fri, Oct 22, 2021 at 12:41:39PM +0200, Vincent Lefevre wrote:
> > ctime() may be marked obsolescent in the POSIX guide, but it is still
> > specified by ISO C, and AFAIK, not marked obsolescent there, even in
> >
ght thing. But the
description needs a bit more details, as many users might think
that this option is not useful for them (as the alternate screen
is no longer visible), while it could be.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://ww
y no using just that?
... unless there is an issue with asctime(), in which case ctime()
would be affected as a consequence.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmet
ernate screen, note that "clear" will *not* clear the
alternate screen. For instance, with xterm, after quitting Mutt, you
can do a Ctrl-MiddleClick, then click on "Show Alternate Screen", and
this reveals Mutt's contents just before Mutt has quit.
--
Vincent Lefèvre - W
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
So, for Mutt, it should be available everywhere.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
earch=stringop-truncation
I would say that it is better to silence the warning with
-Wno-stringop-truncation rather than trying to avoid it in
the code.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Wor
On 2021-04-29 18:24:30 -0700, Kevin J. McCarthy wrote:
> Thanks Vincent. I'm reluctant to make changes to the sanitizer without
> reports of issues.
Old MacOS versions seem to forbid ":" (colon):
https://apple.stackexchange.com/questions/173529/when-did-the-colon-charac
ing.
Note also that "-" should not be used as the first character of
a filename, otherwise it could be confused with an option.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
As before, please let me know if you
> find any problems. Thank you.
Thanks. Everything works fine now.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2021-02-21 09:50:06 +0100, Rene Kita wrote:
> On Sat, Feb 20, 2021 at 06:51:44PM +0100, Vincent Lefevre wrote:
> > I don't understand how you can get the same gmo file since in
> > ccc18061, the dependency on the OPS* file is gone.
> Because I diffed the _output_ of the
On 2021-02-20 12:48:33 +0100, Rene Kita wrote:
> On Thu, Feb 18, 2021 at 11:28:02PM +0100, Vincent Lefevre wrote:
> > The messages in the help are no longer translated, e.g. previously:
> >
> > [...]
> > ^N next-threadaller à la discussion suivan
ange is:
diff --git a/po/POTFILES.in b/po/POTFILES.in
index c7fdd935..62329627 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -44,6 +44,7 @@ imap/util.c
init.c
init.h
keymap.c
+keymap_alldefs.h
lib.c
listmenu.c
main.c
Indeed, I suppose that without keymap_alldefs.h in POTFILES,
the ass
/mutt.pot and I build keymap_alldefs.h manually, then
everything, I get the same issue.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2021-02-19 00:38:11 +0100, Vincent Lefevre wrote:
> I've reverted the change. With 0.21 as the version, this makes
> autoreconf fail on Debian stable because gettext is too old.
> But gettext 0.21 isn't really required. Lowering the version
> e.g. to 0.19 makes autopoint
On 2021-02-19 00:04:20 +0100, Vincent Lefevre wrote:
> I've just pushed a commit that does that (with 0.21 as the version):
> the warning has disappeared.
I've reverted the change. With 0.21 as the version, this makes
autoreconf fail on Debian stable because gettext is too old.
On 2021-02-18 14:53:24 -0800, Kevin J. McCarthy wrote:
> On Thu, Feb 18, 2021 at 11:28:02PM +0100, Vincent Lefevre wrote:
> > A minor issue: autoreconf gives:
> >
> > autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
> > AM_GNU_GETTEXT_VERSION
>
> I di
On 2021-02-18 23:28:02 +0100, Vincent Lefevre wrote:
> The messages in the help are no longer translated, e.g. previously:
>
> [...]
> ^N next-threadaller à la discussion suivante
> ^P previous-threadaller à la discussion précédente
> [...]
minor issue: autoreconf gives:
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Hi,
** .dt %y .dd current year using 4 digits (GMT)
Any reason not to follow the same notation as strftime() for the
year?
For the 4-digit year, I would rather expect %Y.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.v
..]
> Fwiw, I concur the PID in Message-IDs was a bad idea since it
> does unnecessarily leak information about system usage. I'm no
> security expert, though I seem to remember kernel patches that
> would randomize PID allocation in Linux.
I don't think there's much leak, ma
On 2020-08-11 22:29:41 -0500, Derek Martin wrote:
> On Wed, Aug 12, 2020 at 02:40:16AM +0200, Vincent Lefevre wrote:
> > On 2020-08-06 18:40:50 -0500, Derek Martin wrote:
> > > Are you serious, Vincent? I'm pretty sure you well know that this is
> > > a horribl
On 2020-08-06 18:40:50 -0500, Derek Martin wrote:
> Are you serious, Vincent? I'm pretty sure you well know that this is
> a horrible idea, clearly contrary to best security practices, that no
> competent sysadmin managing servers holding anything vaguely sensitive
> would ever
nly their private files.
On such a system using umask (007) for secondary ids seems logical
and safe.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
ture.
In any case, I think that setting up environment variables (if need be)
is cleaner than using a directory name for each --with-* command.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
lar to
remove locks in some cases. I'd say that in general, helper programs
should be in the same section as the one of the main program.
Note also that the man page for run-mailcap is also in Section 1.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
ubject string would
also introduce ambiguities (so that supporting such localizations
would be a bad idea). For instance, I used "AW" as an English acronym
in the past, thus with a meaning completely different from "Re".
It could be possible to localize it in the interfac
There are some other cases where one may want to modify the subject,
e.g. to remove a mailing-list tag in a private reply or to remove a
"(was: ...)" part (hoping that's possible).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
so disable the
> "IMAP PREAUTH" check.
>
> If changed to "no", then STARTTLS will occur for tunneled imap, pop3, and
> smtp connections (subject to $ssl_starttls and $ssl_force_tls, as it does
> right now) . For "IMAP PREAUTH", it will error out if $ssl_fo
On 2020-06-21 10:59:05 -0700, Kevin J. McCarthy wrote:
> On Sun, Jun 21, 2020 at 07:29:58PM +0200, Vincent Lefevre wrote:
> > Well, there's still something that isn't clear. When the user uses the
> > "imaps" protocol, I assume that the connection needs to be e
ents. I'm plan on making another stable release
> in a couple days and want to get this right.
The $ssl_force_tls option should also be clarified, e.g. when "imaps",
"pops", etc. are used, but also concerning tunnels.
BTW, the $tunnel option should be clarified too. If
n't this need to unset $ssl_force_tls too?
BTW, I don't think that testing $ssl_starttls here is useful, as I've
just said in bug 246
https://gitlab.com/muttmua/mutt/-/issues/246
Its value alone will not prevent a MITM attack, and this test may
annoy users who do not need TLS beca
tise STARTTLS, in which case $ssl_starttls will be ignored. So
I think that the above change does not really solve the security issue.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2020-06-20 09:39:04 +0200, Petr Pisar wrote:
> On Sat, Jun 20, 2020 at 01:39:21AM +0200, Vincent Lefevre wrote:
> > On 2020-06-20 08:48:04 +1000, Cameron Simpson wrote:
> > > On 19Jun2020 07:11, Kevin J. McCarthy wrote:
> > > >On Fri, Jun 19, 2020 at 09:48:32A
On 2020-06-20 08:48:04 +1000, Cameron Simpson wrote:
> On 19Jun2020 07:11, Kevin J. McCarthy wrote:
> >On Fri, Jun 19, 2020 at 09:48:32AM +0200, Vincent Lefevre wrote:
> >>On 2020-06-18 18:14:15 -0700, Kevin J. McCarthy wrote:
> >>+/* L10N:
> >>+ The
the case. I think that this should be documented,
and the manual should advise users to set ssl_force_tls.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Another patch I like very much is Rocco's colored progress bar patch:
http://marc.info/?l=mutt-dev&m=123730077818672
Updated version attached.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work
#x27;ve maintained this patch since 2008 and modified it when need be.
I'm attaching it.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Ly
. Some changes may have been
lost.");
}
[...]
else if (check == MUTT_FLAGS)
mutt_message _("Mailbox was externally modified.");
What's the difference between MUTT_REOPENED and MUTT_RECONNECTED?
And what about the MUTT_FLAGS case?
BTW, I did not find any
On 2020-05-12 12:38:52 -0700, Kevin J. McCarthy wrote:
> On Tue, May 12, 2020 at 02:43:44AM +0200, Vincent Lefevre wrote:
> > * one should be able to specify the location of the dotlock program
> >at run time (so that non-root users could install a more recent
> >ver
On 2020-05-11 20:38:19 +0200, Steffen Nurpmeso wrote:
> Vincent Lefevre wrote in
> <20200510204809.ga71...@zira.vinc17.org>:
> |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
> |dotlocking still used nowadays?
>
> I find yes. Or at least last i look
ched mutt's dotlocking away in their packages (which I pointed out
> in that thread).
>
> https://marc.info/?l=mutt-dev&m=111443331622131&w=2
And I'm still using Tamotsu Takahashi's sysdotlock patch,
which I modified each time this was needed. Attached.
--
available, then dotlocking is
useless. So, IMHO, if still supported, dotlocking should just be seen
as a fallback, and if mutt_dotlock cannot be installed with the right
permissions, the installation of Mutt should not fail.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible val
memory
for something that is not needed in general, but for just 2 messages,
this is very little memory (not noticeable in practice).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer ari
l -ixon -icanon -opost -isig, though I think that in addition
to the -icanon implied by cbreak, the only visible changes would be:
-ixon (disable XON/XOFF flow control)
-isig (disable interrupt, quit, and suspend special characters)
And note that cbreak is just:
cbreak same as -icanon
--
Vi
NT, which is actually triggered by Ctrl-G instead of Ctrl-C.
Moreover, it can itself act as a terminal (even when started as an
editor).
> On Thu, May 07, 2020 at 03:57:37AM +0200, Vincent Lefevre wrote:
>
> > On my Mutt pages https://www.vinc17.net/mutt/index.en.html
> > I mention
xit`. It's only really needed to quit from the line editor and might
> have a slightly different behaviour depending on the `quit` quadoption.
That's bad because it doesn't honor the way the user has configured
his terminal. Moreover, I fear that in case of crash, this may lea
On 2020-04-26 23:32:38 +0200, Gero Treuner wrote:
> Hi Vincent,
>
> On Sun, Apr 26, 2020 at 10:51:51PM +0200, Vincent Lefevre wrote:
> > On 2020-04-26 02:33:00 +0200, Gero Treuner wrote:
> > > The MessageId still starts with the time, but is now included in the
> >
of the Message-Id.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
both years.
The authors are not exactly the same for the two editions, but
anyway, it is the publisher who owns the copyright, and it is
the same one for both editions.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
is a waste of space when both $size_show_bytes and
$size_show_mb are unset.
Moreover, $size_show_mb should be ignored for $status_format, where
the size can typically be from hundreds to dozens of thousands times
larger than the sizes in $index_format and similar.
--
Vincent Lefèvre - Web:
The copyright notice should normally give only the year
of the first publication, which will be 2020 for version 1.14.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
,
which has more or less the same effect (one does not benefit from
Mutt's coloring, but is that important?). Thanks to this pipe
feature, I would not need "exact address" at all.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
t (for cases with bigger impact).
But if this is already broken (and used very little), perhaps it
is not much an issue to drop this feature earlier.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INR
rand() is being
> leaked.
I'm thinking that there are two meanings of "leak".
This can be confusing. :-)
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
mix cases.
But for the local part, I don't see any reason not to do so. There is
already mail software that generates Message-IDs with mixed cases before
the "@".
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
less you bound the number of lines per commit
in your stats).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
messages, the older "user@host (Name)" syntax is only
supported when reading messages. The --enable-exact-address switch can
be given to configure to build it with write-support for the latter
syntax. EXACT_ADDRESS in the output of mutt -v indicates whether it's
supported
On 2020-04-21 23:21:14 +0100, Ian Collier wrote:
> On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote:
> > This is a user-side problem. Users should make sure that their
> > hostname setting is unique (possibly with a very high probability,
> > assuming no attacks
not forbidden to add a "non-existing" host part there, before
the domain. This can be reused by every software on the machine.
This is the idea behind the unique FQDN.
Note that since this is done once and for all, you can take much
time deciding what this hostname is.
--
Vincent Lefè
n this case you need to make sure that such random data cannot be
guessed. This may be difficult without using entropy. Using entropy
each time Mutt is started would not be a good idea, in case a system
would run Mutt several times a second to send mail (e.g. personalized
mail to its users).
--
Vi
so that no
additional entropy would be needed.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2020-04-20 19:08:07 +0200, Gero Treuner wrote:
> On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote:
> > But why not using a cryptographic hash for the full local part, then?
> > This could be based on the full message (including the generated
> > headers
On 2020-04-20 09:14:22 -0700, Kevin J. McCarthy wrote:
> On Mon, Apr 20, 2020 at 04:13:08PM +0200, Vincent Lefevre wrote:
> > BTW, about copyright years, "mutt -v" says:
> >
> > [...]
> > Copyright (C) 1996-2016 Michael R. Elkins and others.
> > [...]
&
21:13
Between 13:23 and 18:23, either Derek didn't send any mail, or he did
send mail (with another Mutt instance). Or perhaps he sent 26 messages
elsewhere with the same instance (though this is unlikely). Really,
what did you learn?
--
Vincent Lefèvre - Web: <https://www.vinc17.
each message (which would waste time).
But in any case, a system that would send personalized messages to
its local users via Mutt would start a different Mutt process for
each message, so that there would be a different PID in general.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
r that cryptographic protocols are
broken, which would be a much more important issue than Message-Id
collisions.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+ (uint64_t) 1) + random();
Since you're interested only in a 64-bit unsigned number, this
should be:
r = r * ((uint64_t) RAND_MAX + (uint64_t) 1) + (uint64_t) random();
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://
On 2020-04-19 19:03:19 -0700, Kevin J. McCarthy wrote:
> On Mon, Apr 20, 2020 at 03:47:51AM +0200, Vincent Lefevre wrote:
> > I have noticed a lack of consistency in message strings:
> > * "GPG key" vs "gpg key" (this should be "GPG key")
tocrypt) like on the official website <https://autocrypt.org/>.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2019-06-28 12:02:30 -0500, Derek Martin wrote:
> On Fri, Jun 28, 2019 at 11:08:06AM +0200, Vincent Lefevre wrote:
> > On 2019-06-26 14:36:01 -0500, Derek Martin wrote:
> > > On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote:
> > > > On 2019-06-25 14:2
On 2019-06-26 14:36:01 -0500, Derek Martin wrote:
> On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote:
> > On 2019-06-25 14:26:16 -0500, Derek Martin wrote:
> > > In some cases it might get cleaned up, but you can just have your
> > > .profile (or whateve
accurate values for small messages. And
huge messages are uncommon enough (and in my archives, I tend to
remove bug attachments).
The scaling factor could be user-configurable if need be.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://w
1 - 100 of 571 matches
Mail list logo
