feature request: "compose as new" #176

New Issue

Closed

opened 2026-09-01 15:58:15 +00:00 by unknown · 2 comments

unknown commented

2026-09-01 15:58:15 +00:00

The original description was not recovered.

Referenced by commits

coffey-labs/ihasmail@02c0332d8f 2026-09-01 Send a message again as a new one

_{Rebuilt from: notification email, session transcript. Opening date is approximate.}

*The original description was not recovered.* **Referenced by commits** - coffey-labs/ihasmail@02c0332d8f98 2026-09-01 Send a message again as a new one <sub>Rebuilt from: notification email, session transcript. Opening date is approximate.</sub>

jcoffey-dev commented

2026-09-01 16:11:00 +00:00

Owner

Done in #179 — merged, and it'll go out with the next deploy rather than immediately.

Compose as new sits with Reply and Forward, both in a message's own menu and in the list's right-click menu. It keeps the recipients (To, Cc and Bcc where the server kept one), the Reply-To, the subject with nothing prefixed to it, the body with nothing wrapped around it, and the attachments.

Your "things not to keep" list turned out to be the important half. Two of those omissions are load-bearing rather than cosmetic: the composer's link to a stored draft has to stay empty, or sending would delete the message the copy was made from, and the "related message" link has to stay empty too, or sending would mark the original as answered or forwarded by a mail that is neither. The Message-ID and date needed no work at all — the server assigns the one and we stamp the other at send time, so both are new as long as nothing copies them, and nothing does.

Identity works as you asked: a message you sent is composed as the identity you sent it as, and one somebody else sent falls back to your default. I agree with your reasoning there — matching on who it was addressed to would put a resend behind an alias that was only ever the receiving end.

Two judgment calls where I'd welcome a second opinion, since neither is spelled out in the report:

No signature is added. The body being reused already ends in whatever signature went out with it, so adding the identity's would give it two.
Priority and the read-receipt request are kept. I read your "other headers" as being about the ones identifying the old message — Message-ID, Date, threading — whereas those two are your intent as sender, and the case you describe is sending the same mail again. If you'd rather they reset to the defaults, that's a one-line change.

Bcc is carried when the server kept one, which for most stores means messages in Sent and not much else — as you predicted.

Done in #179 — merged, and it'll go out with the next deploy rather than immediately. **Compose as new** sits with Reply and Forward, both in a message's own menu and in the list's right-click menu. It keeps the recipients (To, Cc and Bcc where the server kept one), the Reply-To, the subject with nothing prefixed to it, the body with nothing wrapped around it, and the attachments. Your "things not to keep" list turned out to be the important half. Two of those omissions are load-bearing rather than cosmetic: the composer's link to a stored draft has to stay empty, or sending would *delete* the message the copy was made from, and the "related message" link has to stay empty too, or sending would mark the original as answered or forwarded by a mail that is neither. The Message-ID and date needed no work at all — the server assigns the one and we stamp the other at send time, so both are new as long as nothing copies them, and nothing does. Identity works as you asked: a message you sent is composed as the identity you sent it as, and one somebody else sent falls back to your default. I agree with your reasoning there — matching on who it was addressed to would put a resend behind an alias that was only ever the receiving end. Two judgment calls where I'd welcome a second opinion, since neither is spelled out in the report: 1. **No signature is added.** The body being reused already ends in whatever signature went out with it, so adding the identity's would give it two. 2. **Priority and the read-receipt request are kept.** I read your "other headers" as being about the ones identifying the old message — Message-ID, Date, threading — whereas those two are your intent as sender, and the case you describe is sending *the same mail* again. If you'd rather they reset to the defaults, that's a one-line change. Bcc is carried when the server kept one, which for most stores means messages in Sent and not much else — as you predicted.

mbunkus commented

2026-09-01 16:44:03 +00:00

Thanks!

I concur with both of your judgement calls. Signature doesn't make sense.

As for headers, I might have been clearer with something like "keep headers that the origin sender might have set personally, discard headers that might be set by intermediate servers". To discard are things such as the ones we've already mentioned, plus e.g. Received-By, DKIM-related stuff, ARC-related stuff, anything by anti-spam/anti-virus systems. As with every load-bearing system only a list of headers to be kept should be used instead of a list of headers to discard — the usual "discard by default unless explicitly allowed" rule of robust systems.

Thanks! I concur with both of your judgement calls. Signature doesn't make sense. As for headers, I might have been clearer with something like "keep headers that the origin sender might have set personally, discard headers that might be set by intermediate servers". To discard are things such as the ones we've already mentioned, plus e.g. `Received-By`, DKIM-related stuff, ARC-related stuff, anything by anti-spam/anti-virus systems. As with every load-bearing system only a list of headers to be kept should be used instead of a list of headers to discard — the usual "discard by default unless explicitly allowed" rule of robust systems.

This repo is archived. You cannot comment on issues.

3 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#176