Hi Eric,
On Sat, Jan 09, 2021 at 10:54:28PM +, Eric wrote in
<20210109225428.GA27462@dcvr>:
So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
(I noticed this in mutt 2.0.2 on FreeBSD)
Encoding mmddHHMMSS into the Message-ID doesn't hurt users
privacy in cases where mutt is gen
On 10-11-2020 22:10, Paul Keusemann wrote:
Hello,
I just downloaded mutt-2.0.0 and attempted to build it on Solaris 10
(SPARC and i86) and ran into the following problem:
mutt_random.c:32: error: syntax error before 'z'
mutt_random.c:32: warning: type defaults to 'int' in declaration of 'z
Please find (in seperate emails to follow shortly) three proposed
patches to address this issue that I and others have raised. All three
patches have the use of (some of) the other patches I sent today as a
prerequisite.
Patch #1 generates ID's in the form:
<1590350694.yJEHqG0ie/TbuynV@settler>,
On Wed, May 06, 2020 at 01:38:35PM -0700, Kevin wrote in
<20200506203835.ga30...@afu.lan>:
On Wed, May 06, 2020 at 04:12:27PM -0400, Kurt Hackenberg wrote:
From reading the ticket, I suspect the problem is in msmtp, an SMTP
client, a replacement for one function of sendmail. Sounds like msmtp
do
On Fri, May 08, 2020 at 06:42:57AM +0200, Claus wrote in
<20200508044257.ga20...@kiel.esmtp.org>:
On Thu, May 07, 2020, Remco Rijnders wrote:
- dprint (1, (debugfile, "WEED is %s\n", (flags & CH_WEED) ? "Set" : "Not"));
+ dprint (1, (debugfile,
---
recvcmd.c | 4
1 file changed, 4 deletions(-)
diff --git a/recvcmd.c b/recvcmd.c
index e6fd0e67..d7e18319 100644
--- a/recvcmd.c
+++ b/recvcmd.c
@@ -648,7 +648,6 @@ static void attach_forward_msgs (FILE * fp, HEADER * hdr,
if (cur)
{
- /* mutt_message_hook (cur->hdr, MUT
---
copy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/copy.c b/copy.c
index 5e84b717..b6c9d781 100644
--- a/copy.c
+++ b/copy.c
@@ -141,7 +141,7 @@ mutt_copy_hdr (FILE *in, FILE *out, LOFF_T off_start,
LOFF_T off_end, int flags,
}
}
- dprint (1, (debugfile, "WE
On Sun, Apr 19, 2020 at 09:26:46AM -0700, Kevin wrote in
<20200419162646.gj29...@afu.lan>:
However, I have opened a placeholder ticket #222 for future
consideration.
For the same future consideration, please find attached a proposed patch.
Deterministic it is not (unless you want to save the s
On Sun, Apr 19, 2020 at 02:20:33PM -0700, Kevin wrote in
<20200419212033.gk29...@afu.lan>:
On Sun, Apr 19, 2020 at 04:28:02PM -0400, Remco Rijnders wrote:
When converting binary values to Base 64 encoding, we go from a 8 bit
representation to a 6 bit representation. As a result, we need
I ran into this while trying to figure out why a very short binary value I
was trying to Base 64 encode came back short. With this change, the code
runs as expected for me. Nonetheless, I would appreciate it if someone can
check if there is no error in my reasoning when I changed this value.
When converting binary values to Base 64 encoding, we go from a 8 bit
representation to a 6 bit representation. As a result, we need extra space
to store the result compared to the input value being converted.
In the current implementation, the requirements on the size of the output
buffer are too
On Sat, Apr 18, 2020 at 06:54:36PM -0700, Kevin wrote in
<20200419015436.gi29...@afu.lan>:
On Sat, Apr 18, 2020 at 08:00:24PM -0400, Remco Rijnders wrote:
These might all seem far fetched, but the point is, information is
being disclosed that is of no value to be included in the Mess
On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in
<20200419021334.go19...@bladeshadow.org>:
OK I'm getting pretty bored with this, it's already been decided by
Kevin it won't be accepted, but I'll answer this last message since it
attempts to directly address a challenge I made.
Your ini
On Sat, Apr 18, 2020 at 06:23:53PM -0500, Derek wrote in
<20200418232353.gm19...@bladeshadow.org>:
i'm sure one could come up with other data points if one is inclined
so.
This is not a compelling argument, and I'm equally sure that you can't.
"Ah... All this time you've been saying you do no
On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
<20200418172634.gi19...@bladeshadow.org>:
Using a standard method for generating IDs is one I would support in
general, as I believe in standards conformance in absentia of a good
reason not to conform. Gowever in this case, it appears the
---
INSTALL | 5 +
1 file changed, 5 insertions(+)
diff --git a/INSTALL b/INSTALL
index dc410d54..fc41ac40 100644
--- a/INSTALL
+++ b/INSTALL
@@ -92,6 +92,11 @@ to ``configure'' to help it out, or change the default
behavior:
--enable-imap
enable IMAP support
+--enable-sidebar
+
rmation being
leaked even when these concerns might be considered tiny or pointless by
you/Derek/some/most. The random() function is already seeded in s_init.c
anyways.
Kind regards,
Remco Rijnders (*over and out*)
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek wrote in
<20200418005901.gb19...@bladeshadow.org>:
This is utterly pointless. This may come off as harsh but please
understand that's not intended. I just want to be completely clear
hee so there is no misunderstanding or equivocation.
Well, poi
The Message-ID that mutt generates is supposed to be unique. Up till now
mutt would generate this ID based on the current date and time, followed by
".G". followed by a letter A to Z (A for the 1st and 27th email sent, Z for
the 26th, etc.), followed by the pid of the active mutt process, followed
Hi,
All pages on trac I try to visit (http://dev.mutt.org/trac/) are returned
an error message:
=-=-=
Error
TracError: The Trac Environment needs to be upgraded.
Run "trac-admin /home/mutt/trac upgrade"
=-=-=
Anyone around who can do just that?
pgpxDR347sAR1.pgp
Description: PGP signature
From http://www.mutt.org/ the following:
Development
Mutt 1.5.21 was released on September 15, 2010. The most notable
user-visible change (aside from bug fixes) is the new $mail_check_recent
flag to partially address NewMailHandling (the major blocker for 1.6). It
also contains a larger than
eral IP in their
> editor, mutt will say "No recipients are specified!" when trying to send.
>
> Remco Rijnders informed me that it should be
> "anyth...@[ipv6:2001:470::::1]", but even then it has the same
> error (it malforms when mutt puts it
On Sat, Sep 11, 2010 at 04:01:27PM +0200, Remco Rijnders wrote:
> I'm hoping to use an S/MIME certificate issued by StartSSL to sign and
> encrypt my mail. When trying to add the certificate I get the following
> error:
>
> re...@silvertown:~$ smime_keys add_p12 startssl.cert
On Sun, Sep 12, 2010 at 10:43:22AM -0700, Michael Elkins wrote:
> >While trying to resolve my struggle with adding a S/MIME key to my account
> >(see post on mutt-users) and by manually tinkering with files, I got mutt
> >to segfault repeatedly.
> >
> >The attached (tiny) patch should prevent this
.
I realise the fix is a trivial one, but hopefully it'll still be of some
use to you.
Sincerely,
Remco
# HG changeset patch
# User Remco Rijnders
# Date 1284268564 -7200
# Branch HEAD
# Node ID 10069d5277ad29b73764cebc3bbe53eea55286c8
# Parent 0f962f1a6bbba4684f8ca0d29916b54be852421b
25 matches
Mail list logo
