Re: [PATCH] Remove double newline between headers and multipart body.

"Kevin J. McCarthy" <[email protected]> Tue, 7 Apr 2026 07:50:50 +0800

Newsgroups	gmane.mail.mutt.devel
Message-ID	<adRG2uEJ_ErWW19l@qinghai>

On Mon, Apr 06, 2026 at 05:59:23PM -0400, Derek Martin wrote:
>On Mon, Apr 06, 2026 at 02:38:34PM +0800, Kevin J. McCarthy wrote:
>> I've added comments around the change, to hopefully make it clear why 
>> the change was made to long standing behavior in mutt.

Thanks for replying Derek!  I was hoping some old-timers would chime in 
for this kind of change.

>I don't quite find the intent clear from the comments... is the issue 
>ONLY that there's an extra line between the message headers and the 
>first multipart boundary?

Yes, that is correct.

>If so, I think the change is fine, but totally unnecessary.

Okay.  The ticket submitter was forthright that he did not believe there 
was a bug in mutt, and that RFC 2046's BNF showed the initial "extra" 
newline was attached to the delimiter.

The issue was that an MTA along the way was "helpfully" removing the 
unneeded extra line from his email, and in doing so, invalidating his 
DKIM signature.

Given that we're well past the time where non-MIME mail readers are in 
use, and that none of the "big" mail generators are adding the extra 
line anymore, he asked if Mutt would consider removing it too.

>In a multi-part message, the bits that immediately follow the message 
>headers are the "preamble" section of the message.  This part exists so 
>that if your (very ancient) mail reader doesn't know how to handle 
>multi-part messages, the sender can put a message there to inform you 
>that you are an antiquated fart (or at least your mail reader is).  Any 
>mail reader which understands multipart messages should ignore all text 
>(even just an extra blank line) between the messge headers and the 
>first multi-part boundary.  See e.g. RFC 2049, Appendix A, and also RFC 
>2096 section 5.1.1.  That would not be a bug per se (i.e. that behavior 
>is allowed and has no effect on modern MUAs), except perhaps that the 
>message contains an extra superfluous CRLF pair.  Note that the message 
>parts should NOT end with an extra EoL which was not part of the 
>message part.

This is great, especially the example in 2049 Appendix A.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

signature.asc (application/pgp-signature, 833 B)