.
However, I'm still thinking about the cases for %{} and %t. Those are
not prefixed with anything. On the other hand, use of those would tend
to be as part of an option, (e.g. --charset=%{charset}). I'm reluctant
to modify $mailcap_sanitize if not necessary though.
--
Kevin J. McCarthy
GPG
* working towards contributing. I would
be delighted if you want to poke around the code and suggest some
patches. Feel free, even, to prove me wrong about the quoting idea;
perhaps there is something inbetween worth considering.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308
, maildir, mh);
* the markup of the header fields and whether the ":" is present.
By all means, feel completely free to tackle that if you would like to.
:-)
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
ould simply lead to the wrong filename being in the invocation.
This is also why the existing sanitization can't be put inside for %s.
If $tmpdir is set to "~/déchets", none of the resulting $tmpdir files
would be readable, because the whole path is passed in.
--
Kevin J. McCarthy
GPG Finger
On Sat, Jun 22, 2019 at 07:05:58AM -0700, Kevin J. McCarthy wrote:
On Sat, Jun 22, 2019 at 06:49:03AM -0700, Kevin J. McCarthy wrote:
No, the setup code is complicated, as you can see from the above
listed functions. Send mode directly uses the filename if a
nametemplate isn't required
,
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
ink
that this would require the use of C99 designators for the MuttVars
initialization).
Okay, I will work on this. I think it's better to fix this the right
way now then get bitten by this later.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signa
On Sat, Jun 22, 2019 at 06:49:03AM -0700, Kevin J. McCarthy wrote:
No, the setup code is complicated, as you can see from the above
listed functions. Send mode directly uses the filename if a
nametemplate isn't required.
And interestingly, it looks like the print command would fail in send
e double-checked here to be sure and potentially avoid
future security bugs.
No, the setup code is complicated, as you can see from the above listed
functions. Send mode directly uses the filename if a nametemplate isn't
required.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5
On Fri, Jun 21, 2019 at 02:09:53PM -0700, Kevin J. McCarthy wrote:
The issue, though, is that the filename isn't always under the user's
control. It has been a very long time without issue, but is there a
possibility of program argument abuse that could lead to a security
issue here?
Bah
. %{charset}), and %t (content type). Both of
these can have "-" in them.
The issue, though, is that the filename isn't always under the user's
control. It has been a very long time without issue, but is there a
possibility of program argument abuse that could lead to a security
the filenames of
attachments.
Does your concern still apply in those circumstances?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Fri, Jun 21, 2019 at 12:09:19PM -0700, Kevin J. McCarthy wrote:
<https://gitlab.com/muttmua/mutt/issues/151> noticed that a leading
'-' is not stripped from filenames, which could lead to them being
interpreted as command arguments.
Just to be clear, the ticket is actually advo
d" behavior is putting '--' before the %s, but
neither the sample mailcap or manual mention that. So I would think
it's a good idea to add the protection to mutt instead.
Is this an oversight, or am I missing something?
Thanks,
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 530
ng
toward adjusting the documentation.
Obtaining the behavior you desire can be accomplished by unsetting
$realname and instead putting the name inside the various $from / my_hdr
settings you use.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
looking at it
everytime. I added a section to the manual
<http://www.mutt.org/doc/manual/#compose-flow> but I'm not sure if it
helps.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Sat, Jun 08, 2019 at 02:41:40PM -0700, Kevin J. McCarthy wrote:
On Sat, Jun 08, 2019 at 02:20:49PM -0700, Kevin J. McCarthy wrote:
I think it's a reasonable expectation, but would like to confirm
that opinion with others before I merge the patch.
Sorry, I forwarded this to the list a bit
On Sat, Jun 08, 2019 at 02:20:49PM -0700, Kevin J. McCarthy wrote:
I think it's a reasonable expectation, but would like to confirm that
opinion with others before I merge the patch.
Sorry, I forwarded this to the list a bit too quickly. After just a bit
more thought I realized the patch
ddress was missing a name,
the reply From address should be the exact same: missing a name too.
I think it's a reasonable expectation, but would like to confirm that
opinion with others before I merge the patch.
Thanks!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADE
If this looks okay, I'll push it tomorrow.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
If we're using GNU Make, the FORCE target allows automatically
updating the version number after each commit.
See commit 22c6df82
---
Makefile.am | 12
uot;fix" added the version.sh
prerequisite and appended to the version.h explicitly just to match the
target below, reldate.h.
If there is something to be gained by using the Makefile variables I'm
all ears, but personally I find the recipe less readable with that way.
--
Kevin J. McC
On Sat, Jun 01, 2019 at 02:16:24PM +0200, Vincent Lefevre wrote:
On 31May2019 17:36, Kevin J. McCarthy wrote:
On Fri, May 31, 2019 at 11:19:27PM +0200, Vincent Lefevre wrote:
How about using AM_CONDITIONAL in configure.ac, setting a variable
GNU_MAKE when GNU Make is used (based on "
On Fri, May 31, 2019 at 11:19:27PM +0200, Vincent Lefevre wrote:
On 2019-05-31 09:37:02 -0700, Kevin J. McCarthy wrote:
Of course, if anyone has an idea how to do this in a way that works
portably, we can revisit. But for now I consider their build issues
more important than the minor
issues
more important than the minor convenience for developers.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Hat/Fedora
based systems. Since this is just another documentation format, it
certainly isn't worth stopping the build over.
If anyone has more program names or package names, please let me know
and I'll add it.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684
ike the docbook2texi issue may
still end up being a common problem on Fedora. One thing I could try
doing is to add an echo statement asking Fedora users to install
docbook2X if that step fails.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.
On Sun, May 19, 2019 at 02:28:09PM -0700, Kevin J. McCarthy wrote:
It looks like RedHat's docbook-tools is even older than docbook2x. I'm
not sure if docbook-tools is commonly installed. Do either of you
think this approach is feasible?
I've added a commit to the 'kevin/gpgme-build-fix
On Sun, May 19, 2019 at 11:03:17PM +0200, Moritz Barsnick wrote:
On Sun, May 19, 2019 at 12:46:07 -0700, Kevin J. McCarthy wrote:
I've checked upstream, <http://docbook2x.sourceforge.net/>. The 0.8.8
release includes docbook2texi as a perl script, and it clearly supports
the --string
On Sun, May 19, 2019 at 10:32:34AM -0700, Kevin J. McCarthy wrote:
On Sun, May 19, 2019 at 01:02:16AM +0200, Eike Rathke wrote:
One is the call
/usr/bin/docbook2texi --encoding=utf-8 \
--string-param output-file=mutt \
--string-param 'directory-category=Email-software' \
--string-param
a call to AM_PATH_GPG_ERROR(1.33), and appends $(GPG_ERROR_LIBS)
to the library list.
Please give this a try and let me know if it works okay.
If not, then I'l merge your fix, but I'd rather stick with the GPGME
versions if possible.
Thank you!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3
. :)
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
, and actually contains all changes I wanted to submit
I'm still not leaning towards accepting :-) , but since you're getting
the patch fixed up, you should also add a line to mutt_free_envelope().
Sorry I missed that earlier.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308
All that said, my impression is that this is too specific. The header
you are referencing is non-standard, and varies based on the MTA.
Others gave suggestions in the threads you mentioned for various
workarounds. I'm -1 on this, but I'll give it some more thought.
--
Kevin J. McCarthy
On Wed, May 15, 2019 at 12:00:52PM -0500, Derek Martin wrote:
I noticed there are a number of other cases where Mutt is using atoi()
instead of mutt_atoi():
Thanks Derek. I'll put that on my todo list for post-release.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF
On Wed, May 15, 2019 at 01:14:18PM +0200, Vincent Lefevre wrote:
I've just fixed an undefined behavior that can occur in an invalid
message, such as the attached one.
Thanks, Vincent!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Hi Everyone,
I've just emailed the mutt.pot file to the translators mailing list.
From now until the release (planned for the weekend of May 25-26),
please restrict commits to bug fixes or documentation updates only.
Thank you,
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C
and sample muttrc to use
/usr/local/share.
The other issues and suggestions, I will look at more closely after the
1.12 release. I don't want to create an unexpected issue with the
freeze tomorrow.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
On Sun, Apr 28, 2019 at 12:07:57PM -0700, Kevin J. McCarthy wrote:
For those able and willing, now would be a good time to check out and
build from master. I'll try to add notes to the UPDATING file in the
next few days, so you know what to test, but overall "day-to-day use"
tes
ze strings with dynamic
buffers. External patches relying on some of the changed data
structures may not compile or function properly. I would suggest taking
a look at how your patches to git master apply as soon as you can.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684
On Tue, Apr 23, 2019 at 10:30:04AM -0700, Kevin J. McCarthy wrote:
On Wed, Apr 24, 2019 at 03:04:05AM +1000, Naveen Nathan wrote:
This is to fix an annoyance where the imap browser may inaccurately
display hierarchical visual cues ('+') to folders that have no
children. This happens when
Kevin for figuring this out).
I'll take a closer look at the patch later today, but one quick thing to
note is the bracket style does not match : please use Allman style:
if (foo)
{
bar;
}
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
On Mon, Apr 15, 2019 at 02:38:27AM +0200, Eike Rathke wrote:
The reason is that some processor architectures can't access words like
int or long on odd addresses and doing so would result in a violation.
Thanks Eike, that makes sense. I appreciate the explanation.
--
Kevin J. McCarthy
GPG
reason for the declaration.
If it turns into an issue then later on we can figure out the correct
thing to do.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
ble manner. I'll let others chime
in if they have more to say here.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Thu, Apr 11, 2019 at 07:20:37AM -0700, Kevin J. McCarthy wrote:
On Wed, Apr 10, 2019 at 07:44:46PM -0400, aaron+m...@schrab.com wrote:
I've been using this in my personal build for a long time, according to
the author date on the commit it's been at least since 2012. I've
submitted it once
from git back when the official version control was
still in mercurial. I figure that it's pays to resend it.
Thanks. I will take a look at this.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
warnings to be shown if these are
incorrect.
AKAIK this is a GCC extension. Mutt thus far has tried to remain
compiler agnostic, so I'm -0 to this.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
be
horrific, it is still a technical burden for an already deprecated
non-standardized scheme.
Unless Microsoft has indicated they have no intention of implementing
OAUTHBEARER support, I would lean against the change.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF
and it doesn't have any issues
with a pinentry-tty prompt. So maybe it's a curses program (mutt)
forking out to a tty program?
Yes, to support the tty pinentry, we would have to exit curses (endwin)
every place a prompt could occur.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308
irectory", so I changed it to be that.
Thanks again for the patch!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Thu, Jan 31, 2019 at 09:22:18AM -0800, Kevin J. McCarthy wrote:
Second, once you trigger force_descend_dir it looks like it stays on,
modifying subsequent behavior of .
Sorry, I should have added: so I might recommend just checking if (i ==
OP_DESCEND_DIRECTORY) instead.
--
Kevin J
bject to testing), it looks fine with me.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
only when the color number is in the
range 0-7.
Excellent work, Vincent! Thank you very much.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
.
Thank you Arnt!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
sh up to master if you'd like. If it still needs tweeking we can
iterate. :)
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
quot; with x >= 8. So, the patch is a
bit incorrect (but so is the current code for the background
colors). And "brightdefault" should be incorrect too.
Agreed, but I don't think it's a big enough deal to worry about, since
it's been that way forever. :)
-
when I have a
chance.
My only comment right now is that we shouldn't change behavior for
existing xterm/urxvt users. If we can "fix" gnome-terminal without
breaking those users, I'm fine with adding additional keywords such as
"bright" and "boldbright".
--
Kev
commits. Mac's ports libraries are notoriously out of
date.
So I'd like to stay conservative on the _hard_ system requirements. I
think 1.4.0 is pretty reasonable, but I start to get nervous about
requiring newer than that.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308
() inside crypt-gpgme.c?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
the patches,
but didn't want the list to think I was ignoring them].
-Kevin
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
, after which I will be happy to review and commit patches from
you.
Thank you!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
I've just sent the mutt.pot file to the translators for updates. So,
starting now, commits should be bug-fix or documentation updates only.
I plan on working on the release 11/23-25.
Thank you,
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
essage composition, so
generally choosing "yes" during message composition is the safe answer!
For your case, you may want to try setting $abort_noattach to "yes", and
then adding a 'Y' macro to override:
macro compose Y 'set abort_noattach=no\
set abort_noattach=yes'
--
Kevin
gt; [2018-10-28 09:41:36] 4< * LIST (\HasNoChildren) "." "unrelated"
> [2018-10-28 09:41:36] 4< * LIST (\HasChildren) "." "foo"
In this line, the IMAP server is telling mutt that foo has children.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
11 release moving along. I'd
like a couple weeks to finish a few things, so let's set the freeze date
for November 9th. As usual I'll give the translation team a couple
weeks, and so will plan on releasing during the weekend of November
23-25th.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3
ntinue them in
the next development cycle.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
. A discussion there may find a solution for you, or
perhaps will illuminate a deficiency in Mutt that needs addressing.
Off the top of my head, I would suggest looking into address groups.
Maybe a group would be easier to use when limiting,
e.g. "~p !%f mylists"
--
Kevin J. McCarthy
GPG Fi
ticularly have the inclination to put keepalive
code in them.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Sat, Sep 15, 2018 at 06:33:29PM -0700, Kevin J. McCarthy wrote:
> Yeah, I don't like to add in the extra timeouts all over the place if
> it's not really necessary. But maybe you're right, I'll think about it
> when I have more time this week.
I've pushed up a fix in 4350694b tha
"is_pipe" case for
> > mutt_view_attachment(). Please give me a few days to look into that
> > first.
>
> Err, the "use_pipe" case.
Sorry yes, (!use_pager && use_pipe) was what I was thinking. I'm a bit
short on time today, so am just replying quickly. :-)
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
development cycle though.
> Sure. It's easy enough to address if a user hits it--probably worth
> documenting (in the code) though, if nothing else.
I've added a comment about that as a breadcrumb if needed in the future.
Thanks again.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3
On Tue, Aug 28, 2018 at 03:27:51PM -0500, Derek Martin wrote:
> On Sun, Aug 26, 2018 at 06:48:46PM -0700, Kevin J. McCarthy wrote:
> > Here's a first try at a patch to check for the historically documented
> > "link() returning -1 but succeeding" case for NFS.
>
&
it's documented, both historically and in the man page, and
so it deserves handling. Your sample code and the man page for rename()
also both mention the problem of leaving the oldpath if it is a hard
link to newpath.
So, I will attempt and post a patch for that fix in a new thread.
--
Kevin
nk __succeeds__.
There is already failure handling code - reverting to trying a rename()
for certain errno values. It was merely Vincent's hypothesis that the
check was in the wrong place, but I don't believe that is correct.
Your point about stat vs lstat sounds important, but let's first resolve
y's Law says eventually someone would hit it, and logically
there is no need.
Steffen's cautions apply to dotlock code, which is a different case and
is not affected by this change.
I'm inclined to keep the commit unless a regression appears or someone
can show proof the change is unsafe.
--
Kevin J.
On Wed, Aug 22, 2018 at 07:13:21AM +1000, Cameron Simpson wrote:
> On 21Aug2018 07:07, Kevin J. McCarthy wrote:
> > On Tue, Aug 21, 2018 at 11:30:03AM +0200, Vincent Lefevre wrote:
> > > But as I understand it, this means that the link got created, but the
> > > s
prevent a disastrous link-creating infinite loop in Mutt; and to do so
without making Mutt less safe.
I don't like removing 20-year old safety checks, but I think it's okay
to do so for the case where link() returns 0. I've been slow to act in
order to give others a chance to chime in, and I greatly app
On Fri, Aug 03, 2018 at 07:57:48AM +0200, Vincent Lefevre wrote:
> On 2018-07-26 18:39:30 -0700, Kevin J. McCarthy wrote:
> > My question is about the merit of performing the lstat double-check.
> > Does mutt need to be doing this? Does this work around some strange bug
&
On Mon, Aug 13, 2018 at 08:21:50AM -0700, Kevin J. McCarthy wrote:
> On Sat, Aug 11, 2018 at 09:00:10PM -0700, Kevin J. McCarthy wrote:
> > I've just pushed CONDSTORE and (experimental) QRESYNC IMAP support into
> > master.
> >
> > If you run against an IMAP server tha
On Sat, Aug 11, 2018 at 09:00:10PM -0700, Kevin J. McCarthy wrote:
> I've just pushed CONDSTORE and (experimental) QRESYNC IMAP support into
> master.
>
> If you run against an IMAP server that supports QRESYNC, I would
> greatly appreciate help testing.
I just realized I left a
On Sun, Aug 12, 2018 at 12:08:34PM +0300, Consus wrote:
> On 21:00 Sat 11 Aug, Kevin J. McCarthy wrote:
> > I've just pushed CONDSTORE and (experimental) QRESYNC IMAP support into
> > master.
> >
> > If you run against an IMAP server that supports QRESYNC, I would
Gmail down.)
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Fri, Jul 27, 2018 at 01:07:42PM -0500, Derek Martin wrote:
> On Thu, Jul 26, 2018 at 06:39:30PM -0700, Kevin J. McCarthy wrote:
> > My question is about the merit of performing the lstat double-check.
> > Does mutt need to be doing this? Does this work around some strange bug
&
merit of performing the lstat double-check.
Does mutt need to be doing this? Does this work around some strange bug
with certain filesystems or NFS?
Would another possibility be to skip the lstat double check, or to fail
without setting EEXIST if the lstat check doesn't match?
Thanks for any advice o
On Tue, Jul 24, 2018 at 04:47:43AM +0200, Vincent Lefevre wrote:
> On 2018-07-22 09:54:44 -0700, Kevin J. McCarthy wrote:
> > I think the second time is okay. The routine is just resorting, and
> > updating the virtual and v2r fields with the assumption that the actual
> > v
eset vsize too.
I think the second time is okay. The routine is just resorting, and
updating the virtual and v2r fields with the assumption that the actual
visible headers hasn't changed.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
On Tue, Jul 03, 2018 at 10:06:43AM -0700, Kevin J. McCarthy wrote:
> On Tue, Jul 03, 2018 at 01:34:40AM +0200, Vincent Lefevre wrote:
> > I sometimes use a limited view with: ~(~asome_address)
> >
> > But in such a case, incoming messages that match this pattern
On Mon, Jul 09, 2018 at 01:57:08PM -0700, Brandon Long wrote:
> On Thu, Jun 28, 2018 at 9:15 PM Kevin J. McCarthy wrote:
>
> > On Tue, Jun 26, 2018 at 05:02:11PM -0700, Brandon Long wrote:
> > > Ok, this patch updates the current head to have
> > > (imap|p
s mean that WKD would always be enabled?
The quadoption would allow the user to set to automatic (yes), prompt
(ask-yes/ask-no), or disable (no). I'd like feedback from everyone, but
I am disinclined to default-enable something that send http requests
out without the user fully understanding what's g
first perform a "gpg --locate-key", and then requery.
There is an existing $pgp_getkeys_command config variable, that supports
some kinds of pre-fetching. contrib/gpg.rc doesn't specify a value, and
I wonder if this could be repurposed?
I'd appreciate any and all input.
Thanks!
--
K
patterns?
It's probably some technical difficulty. I'll try to poke around and
see if I can figure out why.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
d)
ilen = strlen (oauthbearer) + 30;
ibuf = safe_malloc (ilen);
- snprintf (ibuf, ilen, "AUTHENTICATE OAUTHBEARER %s", oauthbearer);
+ snprintf (ibuf, ilen, "AUTHENTICATE OAUTHBEARER f%s", oauthbearer);
Was the added "f" prefix intentional?
--
Kevin J. McC
On Thu, Jun 28, 2018 at 08:36:10PM -0700, Kevin J. McCarthy wrote:
> On Tue, Jun 26, 2018 at 05:02:11PM -0700, Brandon Long wrote:
> > Ok, this patch updates the current head to have
> > (imap|pop|smtp)_oauth_refresh_command, consolidates the code for executing
> > the co
op.
Brandon, this patch doesn't apply for me - specifically the auth_oauth.c
and pop_auth.c parts. Would you mind double-checking? I'll try to
have a faster review turn-around time next time!
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
s
On Thu, Jun 28, 2018 at 10:31:05AM +0900, Anton Lindqvist wrote:
> On Wed, Jun 27, 2018 at 01:08:20PM -0700, Kevin J. McCarthy wrote:
> > Hi Anton,
> >
> > I have a few comments inline below. With those changes, I'm fine with
> > the patch.
>
> Great! Comm
Anton and Brandon, I'll try to get your patch reviews done tonight -
still juggling a bunch of things right now! :-/
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
anual.xml.head
> index 8ac8fd9d..e78d9ec5 100644
> --- a/doc/manual.xml.head
> +++ b/doc/manual.xml.head
> @@ -953,6 +953,20 @@ In addition, the index and
>
>
>
> +
> +
> +check-stats
> +
> +
> +
> +Calculate statistics for all monitored mailboxes declared us
On Tue, Jun 26, 2018 at 05:24:39PM +0900, Anton Lindqvist wrote:
> Don't know if this patch is considered tailored too much for my own
> needs but any feedback would be much appreciated.
I think the idea is fine. Please give me a couple days to review the
patch.
--
Kevin J. McCart
On Tue, Jun 26, 2018 at 08:08:10AM -0400, Vincent Lefevre wrote:
> On 2018-06-25 14:02:33 -0700, Kevin J. McCarthy wrote:
> > On Mon, Jun 25, 2018 at 04:39:19PM -0400, Vincent Lefevre wrote:
> > > It seems that a recent change has broken PGP decryption:
> > > I n
would you mind invoking debug '-d 2' and posting the section
starting with 'pgp_check_decryption_okay:'?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
301 - 400 of 1070 matches
Mail list logo
