On Thu, 9 May 2024 19:15, Derek Martin said:
> This is fine, though AFAICT it still suffers from the same problems as
> autocrypt:
as well as attaching keys to a mail and the still common way to pick a
key from a keyserver. Sure you should not trust this key but it allows
to start encryption
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 w
On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote:
> Hi,
>
> On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:
>
> > Probably fine for preventing casual eavesdropping, but for genuinely
> > sensitive applications, should not be considered good enough, unless
> > I'm missing so
Hi,
On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:
> Probably fine for preventing casual eavesdropping, but for genuinely
> sensitive applications, should not be considered good enough, unless
> I'm missing some important detail...
If you can't trust but need to, then verify. The fi
On Wed, May 08, 2024 at 03:49:12PM +0200, Werner Koch wrote:
> Hi!
>
> Thanks for the summary. I fully agree add these 2 cents:
Thanks.
> In particular using a fixed subject is not going to work in any real
> business because you are not able to ignore mails. For my part, I even
> use a auto-r
Werner Koch wrote in
<875xvoza5j@jacob.g10code.de>:
|Thanks for the summary. I fully agree add these 2 cents:
|
|In particular using a fixed subject is not going to work in any real
|business because you are not able to ignore mails. For my part, I even
|use a auto-responder to tell tha
Hi!
Thanks for the summary. I fully agree add these 2 cents:
In particular using a fixed subject is not going to work in any real
business because you are not able to ignore mails. For my part, I even
use a auto-responder to tell that mails with a three-dot subject are
ignored.
There is a simp
On Mon, Apr 29, 2024 at 10:53:38PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
> |> 1. https://github.com/autocrypt/protected-headers
> |> 2. https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
> |
> |Neat. But this feature seems like a misfeature, making you
> |im
Derek Martin wrote in
<20240429203624.ge19...@bladeshadow.org>:
|On Fri, Apr 26, 2024 at 06:45:57PM +0200, ilf wrote:
|> The Autocrypt project worked on a draft for "Protected Headers for
|> Cryptographic E-mail" [1]. That became the IETF draft "Header Protection \
|> for
|> Cryptographically
On Fri, Apr 26, 2024 at 06:45:57PM +0200, ilf wrote:
> The Autocrypt project worked on a draft for "Protected Headers for
> Cryptographic E-mail" [1]. That became the IETF draft "Header Protection for
> Cryptographically Protected E-mail" [2]. draft-ietf-lamps-header-protection
> is an Active Inter
I don't have the time or the nerve to dig into all the details of this
thread. But I want to add some history and context:
The Autocrypt project worked on a draft for "Protected Headers for
Cryptographic E-mail" [1]. That became the IETF draft "Header Protection
for Cryptographically Protected
On Fri, Apr 26, 2024 at 01:19:44AM +0200, Alejandro Colomar wrote:
> Yeah, most people don't even use PGP
Exactly. On top of that, you have to use one of the small handful of
clients that support it, and then (for at least some of those) you
have to turn it on. Like I said, virtually no one. Or
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 don't have major
> > br
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 don't have major
> breakage.
Who are you to decide what the most important clients are? If my
favori
Derek Martin wrote in
<20240425215214.gb19...@bladeshadow.org>:
|On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
|> You talk to the wrong person given that other people added that
|> mechanism and put it into practical use.
|
|Yeah unfortunately, as Kevin admitted, this feat
On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
> You talk to the wrong person given that other people added that
> mechanism and put it into practical use.
Yeah unfortunately, as Kevin admitted, this feature was never
discussed here when it was implemented, so those who care abo
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 e
Derek Martin wrote in
<20240425190214.ga19...@bladeshadow.org>:
|On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote:
|> Sirius via Mutt-dev wrote in
|>|I would worry less about the users and more about breaking clients. The
|>|method of "be liberal about what you receive and cons
On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote:
> Sirius via Mutt-dev wrote in
> |I would worry less about the users and more about breaking clients. The
> |method of "be liberal about what you receive and conservative about what
> |you send" is apt. Being standards-compliant i
Hello.
Apologizing for the very late reply..
Sirius via Mutt-dev wrote in
:
|In days of yore (Sat, 20 Apr 2024), Steffen Nurpmeso thus quoth:
|> Kurt Hackenberg wrote in
|>|Agreed.
|>
|> I do not, actually. Especially since it already is actively used.
|> The question always is "how do
In days of yore (Sat, 20 Apr 2024), Steffen Nurpmeso thus quoth:
> Kurt Hackenberg wrote in
> |Agreed.
>
> I do not, actually. Especially since it already is actively used.
> The question always is "how do receivers act upon this", of
> course, and this especially means the graphical, even
> br
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
>
Steffen Nurpmeso wrote in
<20240420230154.HauOMF4V@steffen%sdaoden.eu>:
...
|But i thing we refer to different drafts now. I think you are all
|talking about draft-autocrypt-lamps-protected-headers-02, whereas
...
And i want to reiterate that i myself dislike autocrypt as yet one
another way
Steffen Nurpmeso wrote in
<20240420191646.ZD-tN3eo@steffen%sdaoden.eu>:
|Kurt Hackenberg wrote in
| :
||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 suppor
Kurt Hackenberg wrote in
:
|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 p
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 everyone with more than a
single key and in particular when several smartcards. As a BCC
recip
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 ever
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 e
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 protected headers vs.
On Fri, Apr 19, 2024 at 05:07:17PM -0400, Derek Martin wrote:
On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:
On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.
Fair en
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 it'
On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> > However, saying that mutt adds those headers by accident or as a bug seems a
> > bit uninformed.
>
> Fair enough.
But--and I s'pose I may have just missed it--I d
On Fri, Apr 19, 2024 at 10:10:13PM +0200, Alejandro Colomar wrote:
> 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
> > > encapsulati
On Fri, Apr 19, 2024 at 09:58:42PM +0200, Alejandro Colomar wrote:
> I think these days MIME is not so frowned upon as it once was. But you
> have a point. patatt(5) actually implements an idea like yours for
> signing patches including header fields, precisely for avoiding MIME.
To be clear, I
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
On Fri, Apr 19, 2024 at 09:30:27PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
> <20240419191717.ge2...@bladeshadow.org>:
> ...
> |Secondly, there is a standard mechanism for adding non-standard
> |headers to e-mail: use the string "X-" before the thing, and add it
>
> Not anymore
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
> > by
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 protected headers vs. stuffing it at the top of the
> message body, which just se
Derek Martin wrote in
<20240419191717.ge2...@bladeshadow.org>:
...
|Secondly, there is a standard mechanism for adding non-standard
|headers to e-mail: use the string "X-" before the thing, and add it
Not anymore since RFC 6648.
--steffen
|
|Der Kragenbaer,The moon bear,
|der
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
> by GPG. I'd prefer something more direct, that signs headers without
> copying the
On Fri, Apr 19, 2024 at 06:51:20PM +0200, Alejandro Colomar 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 protected headers vs. stuffing it at the top of the
> > message body,
p;m=171352201829360&q=mbox>. You'll see
that the protected header fields are in the header area of the first
MIME part.
From mutt-dev Fri Apr 19 10:22:49 2024
From: Alejandro Colomar
Date: Fri, 19 Apr 2024 10:22:49 +
To: mutt-dev
Subject:
On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
>
> DKIM already exists, and signs header fields. It publishes a key
> through DNS, and so is used by the administrator of the sending domain
> rather than by the end user. Is that acceptable?
Agree about DKIM, and about the gener
On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.
Fair enough.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an inva
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,
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 every MUA
>
> So th
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 actually protect
> >
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, so that it can be
> > verifie
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, sorry, it was originally added in the 1.12 release (5/2019)! The
2.0 release added add
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 actually protect
some header fields precisely in the way that I implemented them in
neomutt(1), with the
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 every MUA
So the main security vulnerability is that a recipient can tamper with
header fields, and th
On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users. It requires the attacker have superuser
> access to the mail system so
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 actually protect
> some header fields precisely in the way that I implemented them in
> neomutt(1), with
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, so that it can be
> verified against tampering. It's not about encrypting them.
You can already do this in
ference that mutt(1) does it on accident.
I use
$ mutt -v | head -n1
Mutt 2.2.12+68 (841caf1c) (2023-10-25)
See the reply that I sent you in the list archives, which I sent with
mutt(1), and you'll find the protected headers
<https://marc.info/?l=mutt-dev&m=171347742508069&q=m
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 re
On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> Hi mutt(1) and neomutt(1) developers!
>
> I reported around a month ago a couple of security vulnerabilities to
> neomutt(1), but which are also present in mutt(1) and every MUA
> (probably, I didn't do an exhaustive research).
57 matches
Mail list logo
