Re: Message security; protected header fields

[Kurt Hackenberg]

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. stuffing it at the top of the
message body, which just seems kind of kludgy at best.


This also seems like a perfectly cromulent approach, and again better
than the proposed one which puts nonstandard headers in a place where
no standard says they can be. [Or perhaps the correct wording would
be, "...which nonstandardly puts standard headers in a place where no
standard says they should be."]


Are you both thinking of defining a new MIME type to hold only the 
protected headers?  I thought of that.  It seems cleaner...I see no 
mention of that in the draft we're talking about, not even to reject 
it.  I suppose old mail readers wouldn't know what to do with that new 
body part.  They might display it if it's a subtype of text.


Turns out an earlier way to protect headers was added in S/MIME 3.1.  
It puts the whole message, including the header section, in a body part 
of type message/rfc822, and wraps a crypto body part around that.  So 
the message contains a copy of itself, sort of.


The draft calls that mechanism "wrapped".  The draft wants to replace 
that with this header-stuffing thing because "legacy" mail readers are 
sometimes confused by the wrapped message.  The draft says 
header-stuffing is less likely to confuse mail readers that never heard 
of either scheme.



MIME header blocks are for MIME-specific metadata; even if no mail
clients actually break due to this, it still feels gross.


Agreed.

I would like to hold off on this until the draft becomes an RFC, if it does.

Re: Message security; protected header fields

[Kurt Hackenberg]

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 then reuse the message in some way, perhaps resend 
it?  And you propose to cryptographically sign certain headers to 
detect tampering?


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 them or modifying the message body.


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?


Email authentication: 

DKIM: 

Re: What is a Message-id?

[Kurt Hackenberg]

On Wed, May 24, 2023 at 06:29:31PM +0200, Olaf Hering wrote:

I just had the case "Message-Id: something" in one email, and 
"References/In-Reply-To: " in replies.


As a result mutt failed to recognize that both mails are indeed one 
single thread.


I just looked at the current Mutt source (relevant code is in parse.c).  
Function mutt_parse_rfc822_line(), in a section of it at about line 
1370, parses Message-ID:.  It calls mutt_extract_message_id(); if that 
doesn't find anything, it calls mutt_extract_message_id() again, this 
time with an argument that tells it to accept an ID without angle brackets.


So I tested it.  Sent myself a message, edited it to remove the angle 
brackets from Message-ID:, replied to that, replied to the reply (all 
with Mutt).  That all worked.  References: and In-Reply-To: all contain 
angle brackets, as they should, and Mutt showed all three messages as a 
thread, correctly.


So I guess your problem needs debugging.  What version of Mutt are you 
using?  How do you know Mutt failed?  How did it display the messages?  
Do you have any relevant configuration?  What exactly is in the bad 
Message-ID: -- can you show it to us?  Can you reproduce the test I 
did?  And so on.

Re: [RFC] Remove additional spaces when quoting already-quoted lines

[Kurt Hackenberg]

On Mon, Aug 01, 2022 at 04:08:27PM +0200, ilf wrote:

>IMHO both "> > foo" and ">> foo" are bad, it should be ">> foo".

What? The last two are the same.

Re: [RFC] Remove additional spaces when quoting already-quoted lines

[Kurt Hackenberg]

On Sun, Jul 31, 2022 at 06:09:56PM +0200, Thomas Wei??schuh wrote:

>currently mutt always prepends `$indent_string` verbatim to each line when
>quoting messages.
>When quoting parts of messages that themselves already were quoted this leads
>to additional space characters in addition to the quote characters.
...
>I would like to modify the quoting algorithm to remove those additional spaces.
>
>```
># Quoted twice (new)
>quux
>> baz
>>> bar
 foo
>```
>
>Even if such a patch is not acceptable to the main mutt project because it is
>in maintenance mode, I would like to gather feedback from the list about
>potential issues with interoperability and standards-conformance.

You may not have to modify code.  I have this in .muttrc:

set indent_string = '>'

You can see the results of that above.

You could argue that should be the default value of $indent_string.

I agree there should not be a space after the '>'.  The trouble is,
that space is ambiguous: software can't tell whether it's part of the
quoting or part of the original message.

RFC 3676 (text/plain format=flowed) forbids that space, for that
reason.

If you propose that software add a space after the rightmost '>', but
not after others, I think it's thirty years too late to change that
quoting mechanism.  You'd have to change all the mail readers in the
world, and also RFC 3676.  We know that won't happen.

Re: [PATCH] Change hardcoded subject of replies

[Kurt Hackenberg]

I agree with the proposed change, to reply to an empty Subject: with 
just "Re:" (or whatever, if that reply-marking string is configurable).


My taste says that an empty or absent Subject: is valid, and should not 
be forbidden or "corrected".

Re: LF to CRLF translation responsibility

[Kurt Hackenberg]

On 2020-05-06 15:32, Claus Assmann wrote:


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 problem; the man page of the
MSP should document it.

If it's an MSP on Unix it would be rather "unusual" to expect
anything but the normal Unix line endings, after all, you should
be able to use a text editor to compose a message and just feed
it to an MSP "as is".


Agreed.

I don't know of any expicit documentation of this either, but it seems 
to be standard practice to convert in both directions between the 
network form and the local form at the boundary between the network and 
the local system: in an MTA, a delivery agent, an IMAP server This 
seems to me the most workable approach to an annoying problem.


From reading the ticket, I suspect the problem is in msmtp, an SMTP 
client, a replacement for one function of sendmail. Sounds like msmtp 
doesn't convert local to network in outgoing mail.


Some MTAs accept any kind of newline in incoming mail, even though the 
RFCs don't require that. That would hide a problem in msmtp. Some MTAs 
accept only CRLF, apparently including opensmtpd.


I guess msmtp is obsolete for Mutt users anyway, since Mutt now contains 
an SMTP client.

Re: meaning of number of lines in the message (%l in index_format)

[Kurt Hackenberg]

On 2019-06-23 06:31, Vincent Lefevre wrote:


...the provided "Lines:" header is not necessarily reliable.


Right. I've seen it wrong many times.

Not from Mutt--when Mutt writes a message to an mbox file, it generates 
Lines: and Content-Length:, both correctly. But Mutt is not the only 
program in the world.

Re: meaning of number of lines in the message (%l in index_format)

[Kurt Hackenberg]

On 2019-06-22 16:47, Vincent Lefevre wrote:


The manual says:

%l   number of lines in the message
  (does not work with maildir, mh,
  and possibly IMAP folders)


Seems not very useful if it mostly doesn't work. Maybe mbox read counts 
lines anyway, so this was easy? And originally there was nothing but mbox?