On Tue, Nov 23, 2021, Aaron Poffenberger wrote:
> > > I know this is related to Message-ID...
>
> I'll back off this claim because I can't prove it beyond doubt. I've
Of course you could. I explained how to do it, but (so far) you
haven't done that -- hence all those replies from people being
sc
On Mon, Nov 22, 2021, Aaron Poffenberger wrote:
> @*sbcglobal.net*: 550 5.7.1 Connections not accepted from
> servers without a valid sender domain.alph758 Fix reverse DNS for 198.51.100.1
Do you have the real DSN? Does it say during which stage this error
happened? Or does your server log show i
On Mon, Nov 22, 2021, Aaron Poffenberger wrote:
> some MTAs reject emails where fqdn of the Message-ID does not have a
> reverse look-up, returning the error:
What do you mean by "reverse look-up" here?
A FQDN might have an A/ or MX record, not a PTR record.
> @*sbcglobal.net*: 550 5.7.1 Con
Why don't you use a wrapper which invokes
clear
after mutt finished? No extra code needed in mutt.
On Fri, Jul 24, 2020, Tom Ryder wrote:
> > > +env->subject = safe_strdup ("Re:");
> Would you or Maxim consider making it a _("translatable string")---or
> perhaps even better, a configurable one---for those who speak other
> languages?
Other than Latin?
"Re:" is a standard that should not b
On Thu, May 07, 2020, Remco Rijnders wrote:
> - dprint (1, (debugfile, "WEED is %s\n", (flags & CH_WEED) ? "Set" : "Not"));
> + dprint (1, (debugfile, "WEED is %s\n", (flags & CH_WEED) ? "Set" : "Not
> Set"));
Save some bytes:-)
dprint (1, (debugfile, "WEED is %sSet\n", (flags & CH_WEED) ? ""
On Wed, May 06, 2020, Kevin J. McCarthy wrote:
> I suspect this is the contention point for opensmtpd. When invoking
> $sendmail directly the headers and delimeter are all just LF. Is this
> expectation that the MSP perform conversion documented anywhere?
Not in an RFC as that's just a local pr
On Wed, May 06, 2020, Kevin J. McCarthy wrote:
> RFC5322 states that headers and the header/body delimiter are supposed to be
> CRLF, but I (and ticket #235) note that mutt is writing them with just LF.
That's for SMTP -- if mutt is talking to an MTA (or MSA) it must
use CRLF (though some MSAs fi
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> I think I would prefer to make "exact address" deprecated in 1.14 and remove
> it for 1.15.
Then I would not upgrade to 1.15 (not that anyone would care...)
I hate it if a program "hides" the actual data and instead presents
some form its authors
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> For now, you can try this patch. I'll think about whether to include it in
That looks good in my simple tests, thanks!
I've added some debugging (see below) and found this:
rfc2047_encode_adrlist: in:M? V?z Garc?a
rfc2047_encode_adrlist:
out:=?iso-8859-1?B?TaogVuF6IEdhcmPtYSA8ckBlc210cC5vcmc+?=
(I set charset=iso-8859-1 for my tests)
So it's encoding the entire address, not just the display name.
I guess some p
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> Claus, I see this is a reply from a 2014 email to the list. Has the problem
> been continuous since then, or did it get fixed and then broken again?
It seems it never got fixed. I guess I ignored it as the problem
happened very seldom. However,
On Thu, Feb 27, 2014, Claus Assmann wrote:
> When replying to an address that used an utf-8 encoded name, e.g.,
>
> From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?=
>
> mutt turned this into
>
> To: Sender =?utf-8?B?V8OkY2g/IDxzZW5kZXJAZXhhbXBsZS5jb20+?=
> instead of
> T
On Thu, Jul 05, 2018, Kevin J. McCarthy wrote:
> I am disinclined to default-enable something that send http requests
> out without the user fully understanding what's going on.
Agreed.
I would patch my copy of the source to not enable such code at all
-- IMHO it does not belong into the MUA but
On Mon, Jun 11, 2018, Bertram Scharpf wrote:
> It was about encryption: If I write a
> message, then encrypt it for the recipient and keep just the
> encrypted copy, I will later not be able to read what I
> wrote myself. I suggested an option that added myself to the
> recipients list when calli
That message irritated me every time I started mutt with a limit
(using push '...') when there are no mails at all.
So I wrote this tiny patch for my mutt version, maybe it is
useful for others too?
diff -r 6ef5ecdbeb84 curs_main.c
--- a/curs_main.c Sun Oct 08 09:36:43 2017 -0700
+++ b/curs_
It seems my mail from yesterday didn't make it to the list?
Date: Sat, 30 Sep 2017 05:03:32 -0700
From: Claus Assmann
To: mutt-dev@mutt.org
Message-ID: <20170930120332.ga27...@x2.esmtp.org>
On Fri, Sep 29, 20
A message with headers like this:
To: Group:;
Cc: Named: user1;
is displayed in mutt as follows when compiled
without --enable-exact-address:
To: Group: ;
Cc: Named: user1
On Mon, Nov 21, 2016, Brendan Cully wrote:
> changeset: 6873:65f180f2904f
> X509_NAME_oneline() always NULL-terminates the string, even when it
Isn't the common terminology:
NULL: NULL pointer
NUL: '\0'
?
> + /* Note that X509_NAME_online will NULL-terminate buf, even when it
On Sat, Aug 13, 2016, Vincent Lefevre wrote:
> On 2016-08-12 07:32:00 -0700, Kevin J. McCarthy wrote:
> > I'm pretty sure this patch didn't change this behavior, and that toggle
> > headers has preserved position for quite a while (at least since
> > 1.5.23). What version were you at before?
> I
On Thu, Aug 04, 2016, Simon Ruderich wrote:
> But that's only true as long as the computer doesn't crash (mutt
> stores mails in /tmp which is either a tmpfs or emptied on
> reboot).
2. Temporary Files
Mutt uses many temporary files for viewing messages, verifying digital
signatures, etc. As lon
On Tue, Apr 05, 2016, Claus Assmann wrote:
> Just noticed this during a full compile:
Oops, please ignore. That's in my branch... Sorry for the noise.
Just noticed this during a full compile:
diff -r 6a8890df7092 rfc822.c
--- a/rfc822.c Sun Mar 13 12:50:49 2016 -0700
+++ b/rfc822.c Tue Apr 05 19:41:36 2016 -0700
@@ -416,7 +416,7 @@
#ifdef EXACT_ADDRESS
# define SET_P_BEGIN(a, v) do { if ((a)) { (a)->a_p_begin = (v); } } while (0)
#else
-# d
Your patch solves the problem for me. Thanks for the fast turnaround!
Just tried 1.6.0 and now I get
Error in .../aliases.mutt, line 1: Warning: Bad IDN 'n...@name.tld' in alias
'NAME'.
Seems this is related to the new IDN code, but since my system
doesn't support ICONV all conversions fail:
mutt_addrlist_to_intl()
-> local_to_intl()
-> mutt_convert_string()
-> mu
FYI:
> [1] http://www.mutt.org/kevin.key
404 Not Found
On Fri, Mar 14, 2014, Derek Martin wrote:
> char *a = "foo";
> char *b = "bar";
> char c[7];
> strlcpy(a, c, 7);
> strlcat(b, c, 7);
I guess you didn't read the man page?
> $ gcc -o sj strjunk.c
> [...]/ccW4BTCh.o: In function `main':
> strjunk.c:(.text+0x38): undefined refe
On Fri, Mar 14, 2014, Derek Martin wrote:
> Unfortunately, sometimes when old code is updated, the maintainer
> forgets to re-check that everything is copacetic. This can still
> happen with the "safe" versions of all these functions too.
Sure, but those functions significantly reduce the risk.
On Thu, Mar 13, 2014, Moritz Barsnick wrote:
> "Release early, release often." ;-)
> (Less than six months this time, instead of three years.)
Thanks to a buffer overflow...
It would have been much better if that didn't happen.
Hmm, maybe it's finally time to get rid of strcat(), strcpy(), etc?
When replying to an address that used an utf-8 encoded name, e.g.,
From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?=
mutt turned this into
To: Sender =?utf-8?B?V8OkY2g/IDxzZW5kZXJAZXhhbXBsZS5jb20+?=
instead of
To: Sender =?utf-8?B?V8OkY2g/?=
which then caused an error when "Sender" replied back to me...
I recently compiled mutt with SMTP/TLS support and provided a client
cert so I can successfully authenticate against my MTA. However, I
was surprised that this doesn't work: mutt asks for an account etc
and then fails with "SMTP server does not support authentication".
Well, yes, the MTA doesn't su
On Thu, Oct 24, 2013, Andras Salamon wrote:
> Which autoconf/automake versions are expected? I am using fairly
README:
If you got the mutt source code from the public Mercurial repository
(http://dev.mutt.org/hg/mutt/), please read doc/devel-notes.txt to make
sure that you have a complete develo
On Thu, Oct 18, 2012, David Laight wrote:
> Why not pipe through tr -cd in order to remove anything not alphanumeric
> or sane punctuation.
Fully agree. It's just a version string. Any characters outside a
"safe" set should be filtered. Nothing fancy needed here.
> Although I suspect that the on
On Fri, Nov 13, 2009, Derek Martin wrote:
> The right solution is most likely to set mark_old. This should make
I tried that some time ago, but didn't like the behaviour. Maybe
it has changed by now; I might try it again when I have some more
time.
> correct). Ripping apart your mail client t
Please ignore, I found mbox_reset_atime() in the source code and
disabled it, now mutt seems to work again in the way I'm used to.
I finally upgraded to mutt 1.5.20 on a new OpenBSD 4.6 box and I
have a problem with folders showing as to have "new mail". The
mail is stored in local mbox format. After I read and delete some
mails in a folder (A) and then switch to another one (B), mutt
claims that there is new mail in A. Check
On Sat, Feb 23, 2008, Alain Bench wrote:
> On Friday, February 22, 2008 at 11:29:05 -0600, Kyle Wheeler wrote:
> > a way to force mutt to *remember* that these [text/plain] messages are
> > [PGP traditionaly] encrypted between sessions.
> This would mean doing some permanent modification to
37 matches
Mail list logo
