Re: Compatibility with mailx aliases

Hi Walter, On Sat, Jun 22, 2024 at 10:36:52AM GMT, Rene Kita wrote: > On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote: > > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for > > aliases: > > > > alias john"John Dou " How about addresses

Re: Message security; protected header fields

Hi Derek, On Mon, May 13, 2024 at 10:10:50AM GMT, Derek Martin wrote: > On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote: > > If you can't trust but need to, then verify. The fingerprint over > > a trusted channel. This has been part of PGP since the beginning. > > Indeed, but that's

Re: [PATCH v1] Don't introduce spurious blank lines in protected blocks

Hi наб, On Sat, May 11, 2024 at 05:18:17PM GMT, наб wrote: > With the parts that remove leading newlines ‒ > > On Sat, May 11, 2024 at 01:27:09PM +0200, Alejandro Colomar wrote: > > @@ -1196,7 +1196,7 @@ int mutt_signed_handler (BODY *a, STATE *s) > >rc = mu

[PATCH v1] enter.c: Use wmem*() functions with wide-character strings

This avoids an explicit size multiplication, which can overflow the calculation. Signed-off-by: Alejandro Colomar Cherry-picked-from: neomutt.git 7df621a105e2 ("Use wmem*() functions with wide-character strings") Link: <https://github.com/neomutt/neomutt/pull/4296> [a

Re: Message security; protected header fields

Hi Derek, On Thu, Apr 25, 2024 at 07:03:48PM -0400, Derek Martin wrote: > On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote: > > While I don't have proof that no clients have major breakage with these > > header fields, I can say that the most important ones d

Re: Message security; protected header fields

Hi Derek, On Thu, Apr 25, 2024 at 03:02:14PM -0400, Derek Martin wrote: > Absence of evidence fallacy. For this to be a non-concern (logically > speaking) you would need to prove that NO client has this problem. > Proving a negative is not always impossible, but given the number of > clients in

Re: Message security; protected header fields

Hi Steffen, On Sun, Apr 21, 2024 at 01:01:54AM +0200, Steffen Nurpmeso wrote: > Steffen Nurpmeso wrote in > <20240420191646.ZD-tN3eo@steffen%sdaoden.eu>: > |Kurt Hackenberg wrote in > | : > ||I would like to hold off on this until the draft becomes an RFC, if \ > ||it does. > | --End of >

Re: Message security; protected header fields

Hi Werner, On Sat, Apr 20, 2024 at 02:10:28PM +0200, Werner Koch wrote: > Hi, > > I only had a brief look into this thread but stumbled upon this: > > > *7: BCCs should be hidden recipients. > > [BCCs shold be separate mails of course.] > > Using a hidden recipient is a major hassle for

Re: Message security; protected header fields

Hi Kevin, On Sat, Apr 20, 2024 at 11:39:17AM +0800, Kevin J. McCarthy wrote: > What I did do was a minimal implementation of the spec at the time, so that > Mutt could read messages from other clients that started sending with a > hidden Subject header, for interoperability. > > Writing was not

Re: Message security; protected header fields

Hi Derek, On Fri, Apr 19, 2024 at 04:56:30PM -0400, Derek Martin wrote: > You're missing the point: All software has bugs. This would be a > bug, but it's forseeable that mailers would have this bug. For > example, if the header parser you implement differentiates where to > put the headers

Re: Message security; protected header fields

Hi Derek, On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote: > On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote: > > It's odd to me that, since OpenPGP and S/MIME both support MIME > > encapsulation that the draft standard wouldn't use a separate MIME part > > to handle the

Re: Message security; protected header fields

Hi Derek, On Fri, Apr 19, 2024 at 03:17:17PM -0400, Derek Martin wrote: > On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote: > > Signing header fields sounds reasonable, but I don't entirely like an > > implementation that puts a copy of them in the message body, to be covered > >

Re: Message security; protected header fields

of the MIME part. They are not part of the body area. Below is a message, which you can find on mutt-dev@'s archives at <https://marc.info/?l=mutt-dev=171352201829360=mbox>. You'll see that the protected header fields are in the header area of the first MIME part. From m

Re: Message security; protected header fields

Hi Kevin, On Fri, Apr 19, 2024 at 11:43:20AM +0800, Kevin J. McCarthy wrote: > On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote: > > However, I'd like to point out that mutt added basic support for > > Protected Headers in the 2.0 release, following the Autocrypt project > > Ah,

Re: Message security; protected header fields

Hi Kurt, On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote: > On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote: > > > I reported around a month ago a couple of security vulnerabilities to > > neomutt(1), but which are also present in mutt(1) and

Re: Message security; protected header fields

Hi Kevin, On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote: > On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote: > > BTW, now that I remember, while developing these things for neomutt(1), > > I found that mutt(1) has a bug (?) by which it does a

Re: Message security; protected header fields

Hi Derek, On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote: > On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote: > > Protecting the recipients and the in-reply-to doesn't mean hiding it. > > It means providing a copy inside the signed part,

Re: Message security; protected header fields

Hi Derek, On Thu, Apr 18, 2024 at 11:59:29PM GMT, Alejandro Colomar wrote: > Hi Derek, > > On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote: > >g. Protecting the recipients is problematic for potentially several > > reasons--it prevents people from

Re: Message security; protected header fields

Hi Derek, On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote: >g. Protecting the recipients is problematic for potentially several > reasons--it prevents people from interacting normally with > threads and their recipients. The SMTP envelope needs at least > the

Message security; protected header fields

these changes, I could adapt the patches for mutt(1) too. Here's an overview of my initial idea, using ASCII art. Please scroll to the right of the screen to see it all. I've removed some bits that I've discarded. Date: Sat, 30 Mar 2024 12:22:13 +0100 From: Alejandro Colomar

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

Hi Darek, On Wed, Nov 15, 2023 at 01:25:29PM -0500, Derek Martin wrote: > On Wed, Nov 15, 2023 at 07:10:52PM +0100, Alejandro Colomar wrote: > > On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote: > > > Hi! > > > > > > On Fri, 10 No

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

Hi Werner! On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote: > Hi! > > On Fri, 10 Nov 2023 01:41, Alejandro Colomar said: > > > This is breaking behavior, so it needs some more justification than just > > the above. > > FWIW, I am using another

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

On Fri, Nov 10, 2023 at 01:41:41AM +0100, Alejandro Colomar wrote: > This is useful for signing patches with git-send-email(1). Here's a > working configuration for that: > > In <~/.gitconfig>, add this section: > > [sendemail] > sendmailcmd = m

[PATCH] send.c: Allow crypto operations in batch and mailx modes.

ferent configuration for such cron jobs that doesn't ask mutt(1) to use PGP. Link: <https://github.com/neomutt/neomutt/issues/1471> Link: <https://github.com/neomutt/neomutt/pull/1476> Co-developed-by: Jenya Sovetkin Cc: Signed-off-by: Alejandro Colomar --- Hi! I've been trying th