Config mail.smtp.useSenderForSmtpMailFrom not working
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: solstag, Unassigned)
Details
Steps to reproduce:
Set 'mail.smtp.useSenderForSmtpMailFrom' to 'False' and send an e-mail with an alternative identity for the sending account.
Actual results:
Message on receiving end shows 'Return-Path:' with the 'From:' identity instead of the main account identity.
Expected results:
The sending account should have been used as the "envelope from", so that the message on the receiving end shows the sending account in 'Return-Path:' instead of the alternate identity.
This config was introduced here: https://bugzilla.mozilla.org/show_bug.cgi?id=1294027
Current anti-spam measures produce cases where it is desirable to keep the SMTP server account in the envelope when sending mail with an alternate identity.
Personally, I have noticed that (at least) Gmail will systematically send my messages to the Spam folder when using a non-Gmail sending account with an alternate address, even tough the headers show that it passes SPF.
If I use Mutt instead of Thunderbird, which can be configured to use the sending account as the "envelope from", my emails are not sent to Spam by Gmail. Thunderbird already advertises this capability, but it is not working, which is a pity.
Let me know if I can help testing a fix. Obrigado!
|
||
Comment 1•1 years ago
|
||
It looks like that should still be operational. See https://searchfox.org/comm-central/rev/e370deefa7c17a7a657c512fe460f758f5faff12/mailnews/compose/src/SmtpService.sys.mjs#115,122,134
Please try Thunderbird 115+
|
Reporter | |
Comment 2•1 years ago
|
||
Ni! Thank you for looking into this Magnus,
It seems to me that sender in this context is actually being assigned values from the identity or the header.
On first sight, the code for sendMailMessage you linked to gets called here:
https://searchfox.org/comm-central/source/mailnews/compose/src/MessageSend.sys.mjs#1155,1159
Which in turns gets called in a few places that themselves seem to call C++ code, such as here:
https://searchfox.org/comm-central/source/mailnews/compose/test/unit/test_createAndSendMessage.js#121-123,130
Now, in C++ code all usages related to ".*CompFields->SetFrom()" seem to get values from either an identity or from email headers:
https://searchfox.org/comm-central/search?q=compfields-%3Esetfrom&path=&case=false®exp=false
Could that be?
|
|
Reporter | |
Comment 3•1 years ago
|
||
PS: And I'll test with 115+ once I get a chance. My distro is stuck on 102 for now, but I guess I can use the one from flatpak. Thanks again :)
|
|
Reporter | |
Comment 4•1 year ago
|
||
Ni! Alright, took me a while but I have now tested with the latest Thunderbird from Flatpack (115.12.1). The option still did not work as I intended. That is, the "Return-Path" is always the "email address" set for the identity and not that set for the account.
However, reading once more through the whole of https://bugzilla.mozilla.org/show_bug.cgi?id=1294027 , I have now better understood what the option actually does. It only affects modifications to the "From:" field of a single email message, that is, when clicking on the message composition identity selector and choosing "Customize From Address". So the present issue is indeed not a bug, but a feature request, since what I'd need is to be able to set the "MAIL FROM" when sending mail with a permanent identity.
I would argue there's a real case for this feature, since at least Gmail is silently refusing messages from (some?) other providers if the "MAIL FROM", and thus currently any permanent identity, doesn't correspond to the provider's account address. If it does correspond, which we can test by setting mail.smtp.useSenderForSmtpMailFrom to false and modifying the address of a single email as described above, then Gmail accepts the message and displays the sender to the user as "Their Name via provider.tld". Which suggests their clear intention that clients behave like that: using the provider's address as "MAIL FROM" regardless of what address is in the "From:" field.
Since this value is based on the SMTP provider, it should likely be an option specific to each identity. Perhaps something like
- [ ] Replace MAIL FROM with: ______
at the end of the identity page and inactive until one clicks the checkbox.
Anyways, I suppose it would be better that I open a new bug and mark this one as 'invalid', right? Or is it fine to continue here?
Hoping this feature could be taken into consideration.
Best
Description
•