LOG: MAIN
<= root@tnsbuilds01.tn.ixsystems.net U=root P=local S=1183
root@ScalePROD:/mnt/SnappitySnap/TrueNASInfo/Scripts/zemailData# delivering 1tOcw6-0002ph-1q
R: nonlocal for myNASEmail@gmail.com
LOG: MAIN
** myNASEmail@gmail.com R=nonlocal: Mailing to remote domains not supported
LOG: MAIN
<= <> R=1tOcw6-0002ph-1q U=Debian-exim P=local S=2508
LOG: MAIN
Completed
delivering 1tOcw6-0002pk-1y
R: system_aliases for root@tnsbuilds01.tn.ixsystems.net
R: nonlocal for myNASEmail@gmail.com
LOG: MAIN
** myNASEmail@gmail.com <root@tnsbuilds01.tn.ixsystems.net> R=nonlocal: Mailing to remote domains not supported
LOG: MAIN
Frozen (delivery error message)
… which basically boils down to …
Mailing to remote domains not supported
Some googling lead me to change update-exim4.conf.conf under /etc/exim4
You can check the status by using cat /var/log/mainlog which will show you the log file vice waiting on an email that doesn’t show up.
I still get R=nonlocal: Mailing to remote domains not supported as the error message.
I am unsure what the equivalent command is for exim, I thought it was exim -i -t < myfile.txt but it still gets blocked. I searched the internet a good portion of yesterday and tried a lot of different things (config file changes and different exim switches), still no luck.
If you uncover something, I of course am greatly interested as I’m sure many others who have scripts that send them emails. And I also attach files to my emails periodically so that for me is also important.
Good hunting!
P.S. This is a security update, so sendmail will not be coming back.
As mentioned before, I have a few homemade rclone backup scripts that send mail reports on completion; they use the mail utility at /usr/bin/mail, with said path hardcoded in the script.
This works, even on 24.10.1, but is probably too inflexible for your script, as I have not found a way to do attachments.
I will be spinning up a seperate VM of TrueNAS 24.10.1 to test with, I’m tired of changing my real system back and forth.
I will investigate the /usr/bin/mail on that VM. I may need to make a big change to the script to make it work, but first I need to be able to send myself an email form 24.10.1. Any email other than the GUI test.
This is enough to send me the body of the report (piped to $summaryfile) and a variable subject, with the result of the rclone run.
It is a very simple script - the $summaryfile is just a plain text report collated from the output of rclone, but still it works in 24.10.1 and keeps me updated regarding my backups.
The lucky dogs at iXsystems of course can make it happen, they are the ones who added the security restriction. Yesterday I had to take a break from this project and instead started to learn more about 3-D printing (for the new printer I have). I have completed that for now, time to turn my focus back to this email issue.
Ah ha! That at least explains why I didn’t get my report this morning. And seeing as Joe’s script has already saved me once when a 6 month old drive failed last week…
I would have expected something as standard as sendmail in all/most distributions being removed would have been flagged well in advance with workarounds before release. It’s hardly a rarely-used function of *nix.
@Stux Thanks, I will give that a very hard look in the morning and see what it provides. I do not recall this being listed as an API in the docs, in the morning I will look at the API docs to this version. And please understand that I don’t know python, but I am trying to learn it. Dictionaries are new to me but at least I recognized it is a dictionary.
Here is some documentation at https://www.exim.org/docs.html. There is also a PDF copy that I will download in the morning and scan for ‘no external mail relaying’.
Thank you for the kind words. We can’t fault anyone for a security fix, it would have been nice to know in advance that this fix was coming so those who run scripts can figure out the workaround before it becomes a problem for the many whom it affects. And I have no idea how iXsystems would have communicated something like that, it would not be an easy task.
As for a NAS ticket, here is the ticket I submitted a few days ago: Jira
I can open a new ticket is needed.
In order to replicate the issue, (again from my perspective) just run Multi-Report version 3.07 script in TrueNAS 10.24.0.2 to see what it should look like, then in 24.10.1 to see that the email get stopped by TrueNAS.
I do not fully understand how the fix was made but it appeared to me that ‘root’ had some interaction that could be exploited.
I think the easiest resolution would be if there is a direct command replacement for sendmail -t -oi. This is what I am specifically looking for however if that can be fixed, I am hopeful it will fix all sendmail usage. We will see.
It has been suggested that maybe exim was not incorporated properly into TrueNAS. I’m not a software engineer nor a programmer (weekend warrior at best) but that is way outside my current skill set. I do know when to ask for help, basically when I have exhausted everything I can think of, hence 3 days later now asking. I do have a few things still to try, one is thanks to @Stux.
I struggled (due to personal ineptitude) to u/g to EE; having finally succeeded yesterday after three attempts spread over the last few weeks, I then came across this thread. Typical that I found it after the event! My fault, not a complaint.
I decided to downgrade back to DF yesterday, staying with it for the time being until hopefully some form of fix is discovered. I am happy to be a guinea pig if it would help anyone.
The fact that TN has implemented different boot environments means that trying again, or reverting again, is a five minute task so it isn’t any problem.