Add support for custom sender without exposing original sender

[krackout]

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

[d99kris]

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.

[krackout]

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.

[d99kris]

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?)

[krackout]

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.

[d99kris]

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]

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.

[krackout]

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.

[d99kris]

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.

[Kabouik]

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.

[krackout]

@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.

[d99kris]

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]

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

[d99kris]

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

[d99kris]

The remaining improvement to look into is whether nmail can adapt similar behavior as Thunderbird which puts the custom sender address in From: and Return-Path: fields (and does not include a Sender field).

[d99kris]

Updating title from Add support for custom sender address without exposing original sender via Sender: and Return-Path: headers to Add support for custom sender without exposing original sender.

[d99kris]

I just conducted a test on a recent Thunderbird on macOS and when sending using a custom from:-address there is no difference in the headers between Thunderbird and nmail. Both resulting headers expose the actual sender (although the receiver doesn't see it unless they inspect the headers) - which I guess makes sense. I will proceed to close this feature request. In case someone can find a current client that manages to send emails with a custom address and leaving no trace of the actual sender address, please share the details and we can consider re-opening this request. Thanks!