[GH-ISSUE #94] [Enhancement] Compose emails with custom From: field

kerem commented

2026-03-03 01:19:37 +03:00

Owner

Originally created by @krackout on GitHub (Feb 1, 2022).
Original GitHub issue: https://github.com/d99kris/nmail/issues/94

Originally assigned to: @d99kris on GitHub.

Multiple identities / smtp addresses is it possible, will it be added?

Originally created by @krackout on GitHub (Feb 1, 2022). Original GitHub issue: https://github.com/d99kris/nmail/issues/94 Originally assigned to: @d99kris on GitHub. Multiple identities / smtp addresses is it possible, will it be added?

kerem closed this issue

2026-03-03 01:19:38 +03:00

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Feb 5, 2022):

No, multiple identities is unfortunately out of scope for nmail.

The question / request has come up before (#4) but there are no plans to add it to the roadmap. Will proceed to close this issue.

@d99kris commented on GitHub (Feb 5, 2022): No, multiple identities is unfortunately [out of scope](https://github.com/d99kris/nmail#not-supported--out-of-scope) for `nmail`. The question / request has come up before (#4) but there are no plans to add it to the roadmap. Will proceed to close this issue.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@krackout commented on GitHub (Feb 5, 2022):

Actually I'm not asking about multiple accounts; sorry if I didn't phrase it correctly, I used Thunderbird's terminology (identities). The request is for different aliases - smtp addresses, on the same account. To be able to send using my registered aliases on the same account. Receiving apparently works.

I've already implemented multiple accounts the way you suggested, using multiple configurations - multiple instances of nmail and it's working great. Probably I'll implement multiple aliases the same way, but it's a bit awkward to have the same mailbox opened three times in my case (3 aliases), just to be able to send with a different alias.

@krackout commented on GitHub (Feb 5, 2022): Actually I'm not asking about multiple accounts; sorry if I didn't phrase it correctly, I used Thunderbird's terminology (identities). The request is for different aliases - smtp addresses, on the same account. To be able to send using my registered aliases on the same account. Receiving apparently works. I've already implemented multiple accounts the way you suggested, using multiple configurations - multiple instances of `nmail` and it's working great. Probably I'll implement multiple aliases the same way, but it's a bit awkward to have the same mailbox opened three times in my case (3 aliases), just to be able to send with a different alias.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Feb 6, 2022):

Ah sorry, I misunderstood. So is this for just using different sender name and from-address, but the SMTP host, port, username and password stay the same?

(Or separate multiple SMTP accounts - which could be different SMTP server host, username, etc?)

@d99kris commented on GitHub (Feb 6, 2022): Ah sorry, I misunderstood. So is this for just using different sender **name** and **from-address**, but the SMTP host, port, username and password stay the same? (Or separate multiple SMTP accounts - which could be different SMTP server host, username, etc?)

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@krackout commented on GitHub (Feb 6, 2022):

Exactly, different sender name and from-address, but the SMTP host, port, username and password stay the same.

Usually the way implemented on MUAs is, when composing a new mail, you can edit from field, when replying, the from field is already filled in (but editable) with the receiving alias/smtp address.

@krackout commented on GitHub (Feb 6, 2022): Exactly, different sender **name** and **from-address**, but the SMTP host, port, username and password stay the same. Usually the way implemented on MUAs is, when composing a new mail, you can edit **from** field, when replying, the **from** field is already filled in (but editable) with the receiving alias/smtp address.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Feb 7, 2022):

Ok, got it! Yes this makes sense to support, assuming a simple user interface. Currently nmail compose editor supports toggle of editing "rich headers" with ctrl-r. It currently just unhides Bcc: field, but I suppose we could show an editable From: field in rich header mode too. Aside from manual editing, it could support lookups in the normal address book initially, and possibly eventually having its own "address book" remembering only old from-addresses used. Or lookups from some config file. I assume it's kind of key not to need to repeatedly type out the custom from-address to use.

I don't have time to look into this right now, but I'll leave the feature request here and hopefully come to it soon.

Usually the way implemented on MUAs is, when composing a new mail, you can edit from field

Thanks, yeah it rings a bell - I have manually edited the From: field when editing emails in emacs once upon a time. :)

@d99kris commented on GitHub (Feb 7, 2022): Ok, got it! Yes this makes sense to support, assuming a simple user interface. Currently `nmail` compose editor supports toggle of editing "rich headers" with `ctrl-r`. It currently just unhides `Bcc:` field, but I suppose we could show an editable `From:` field in rich header mode too. Aside from manual editing, it could support lookups in the normal address book initially, and possibly eventually having its own "address book" remembering only old from-addresses used. Or lookups from some config file. I assume it's kind of key not to need to repeatedly type out the custom from-address to use. I don't have time to look into this right now, but I'll leave the feature request here and hopefully come to it soon. > Usually the way implemented on MUAs is, when composing a new mail, you can edit from field Thanks, yeah it rings a bell - I have manually edited the `From:` field when editing emails in emacs once upon a time. :)

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Mar 5, 2022):

Support for custom from: field has been added in above commit.

The field is shown when rich headers is enabled in the compose editor. Rich headers are toggled on/off with ctrl-r.

@d99kris commented on GitHub (Mar 5, 2022): Support for custom from: field has been added in above commit. The field is shown when rich headers is enabled in the compose editor. Rich headers are toggled on/off with `ctrl-r`.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@krackout commented on GitHub (Apr 11, 2022):

I'm using this feature, it works. But checking on the headers of the e-mail received at the other end, I notice that Sender: and Return-Path: fields point to the original, not to the custom e-mail address.
On the contrary, using custom From: in Thunderbird, the receiver end e-mail has no Sender: field, just From: and Return-Path: which are filled with the custom e-mail address, not the original.

I tested using the same mail account and custom e-mail.
The sent e-mails either in nmail or Thunderbird sent folder, sent by either MUAs, present no noticeable differences. It's in the receiver's inbox that the difference appears.

For example, sending using nmail, original e-mail, original@mail.com, custom, custom@mail.com.
The e-mail received will have these headers:

From: custom@mail.com
Sender: original@mail.com
Return-Path: original@mail.com

Sending using thunderbird,

From: custom@mail.com
Return-Path: custom@mail.com

(no Sender: field)

The latter is preferable (for me at least) - perhaps it's not desirable in some cases both addresses to be revealed in headers. I'm not reopening the issue, the main goal is achieved. Yet if you think it's easy to be done and not out of scope why not.

@krackout commented on GitHub (Apr 11, 2022): I'm using this feature, it works. But checking on the headers of the e-mail received at the other end, I notice that `Sender:` and `Return-Path:` fields point to the original, not to the custom e-mail address. On the contrary, using custom `From:` in Thunderbird, the receiver end e-mail has no `Sender:` field, just `From:` and `Return-Path:` which are filled with the custom e-mail address, not the original. I tested using the same mail account and custom e-mail. The sent e-mails either in `nmail` or `Thunderbird` sent folder, sent by either MUAs, present no noticeable differences. It's in the receiver's inbox that the difference appears. For example, sending using `nmail`, original e-mail, original@mail.com, custom, custom@mail.com. The e-mail received will have these headers: ``` From: custom@mail.com Sender: original@mail.com Return-Path: original@mail.com ``` Sending using `thunderbird`, ``` From: custom@mail.com Return-Path: custom@mail.com ``` (no `Sender:` field) The latter is preferable (for me at least) - perhaps it's not desirable in some cases both addresses to be revealed in headers. I'm not reopening the issue, the main goal is achieved. Yet if you think it's easy to be done and not out of scope why not.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Apr 11, 2022):

Hi @krackout - thanks for the feedback. Let me re-open the issue and do some investigation to see what is considered best practise and whether nmail can support similar to thunderbird.

@d99kris commented on GitHub (Apr 11, 2022): Hi @krackout - thanks for the feedback. Let me re-open the issue and do some investigation to see what is considered best practise and whether `nmail` can support similar to `thunderbird`.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@Kabouik commented on GitHub (Jun 10, 2022):

It is a nice addition but I would prefer if nmail wouldn't focus on this new field first when composing a new email. There can't be as many users wanting to edit their default identity (< 100% of users) as users wanting to fill a recipient email address (basically 100% of users), so I believe it would be better if the cursor defaulted to the To: field when composing a new message.

@Kabouik commented on GitHub (Jun 10, 2022): It is a nice addition but I would prefer if `nmail` wouldn't focus on this new field first when composing a new email. There can't be as many users wanting to edit their default identity (< 100% of users) as users wanting to fill a recipient email address (basically 100% of users), so I believe it would be better if the cursor defaulted to the `To:` field when composing a new message.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@krackout commented on GitHub (Jun 10, 2022):

@Kabouik it's a good point, but from: field is shown only when Rich headers are enabled (^R shortcut). You can disable them and problem solved. Unless you need bcc: to be available for all e-mails.

@krackout commented on GitHub (Jun 10, 2022): @Kabouik it's a good point, but `from:` field is shown only when `Rich headers` are enabled (^R shortcut). You can disable them and problem solved. Unless you need `bcc:` to be available for all e-mails.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Jun 18, 2022):

I put From: before To: for "compose" to be consistent with the "message view", and I didn't really consider the default cursor position.

I agree with @Kabouik it makes sense to default the "compose" cursor position to the To: field. Let me take a look at adjusting that - hopefully a minor fix.

@d99kris commented on GitHub (Jun 18, 2022): I put `From:` before `To:` for "compose" to be consistent with the "message view", and I didn't really consider the default cursor position. I agree with @Kabouik it makes sense to default the "compose" cursor position to the `To:` field. Let me take a look at adjusting that - hopefully a minor fix.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Jun 25, 2022):

With commit f19c6fd the default cursor position for rich headers is now the To: field.

@d99kris commented on GitHub (Jun 25, 2022): With commit f19c6fd the default cursor position for rich headers is now the `To:` field.

kerem commented

2026-03-03 01:19:39 +03:00

Author

Owner

@d99kris commented on GitHub (Nov 29, 2022):

Will proceed to move all feature requests into Discussions section, for a clearer separation of bugs and feature requests.

@d99kris commented on GitHub (Nov 29, 2022): Will proceed to move all feature requests into Discussions section, for a clearer separation of bugs and feature requests.

kerem referenced this issue

2026-03-03 01:20:09 +03:00

[PR #107] [MERGED] Imap bug fixes #146

Rows
Columns

[GH-ISSUE #94] [Enhancement] Compose emails with custom From: field #80