I will be happy to exploit that offer 
Since I do not have SCALE to play with myself I took a look through the docs for exim and according to what I found it can be setup such that only specific users (not necessarily root) can use external relays and I have seen others say that there is a Debian-exim and a Debian-snmp user; do you (or anyone) know if sending external mail is restricted to these (or another such) users?
I did d/l the PDF of the help manual and it talks about running a program to set up the config file. The 567 page help document talks about running a program to configure the config file :).
# dpkg-reconfigure exim4-configI tried this code but dpkg-reconfigure is not installed (or not in the path).
There is also this write up about hooking exim up for gmail. I am not sure if debian / truenas are compatible.
That would likely require enabling dev mode, which I wouldnāt recommend on anything but a throwaway install.
I changed the corresponding value to āinternetā in update-exim4.conf.conf and than ran I update-exim4.conf. That got rid of the error message, I think exim connected to the mail provider alright, but I think it tried to send it via root, and said root@ ist not a proper domain.
But I guess using the existing way truenas itself sends mails is the right way, instead of fiddling with settings.
In the api documention are severla entries with āmailā
mail.config.
no info given, self explanatory?
mail.send (job)
two columns of arguments like to from subject etcā¦
mail.update
Update Mail Service Configuration.
fromemail is used as a sending address which the mail server will use for sending emails.
outgoingserver is the hostname or IP address of SMTP server used for sending an email.
security is type of encryption desired.
smtp is a boole an value which when set indicates that SMTP authentication has been enabled and user/pass are required attributes now
It is possible to call eg. mail.send like this, but it just returns a number, I guess it is the job.
sudo midclt call mail.send
Unfortunately,t I have not idea how to āpass onā the possible arguments, and if that is possible via a script anyway.
I saw the returned number as well yesterday when I ran the command, I believe it is also a job number but I havenāt had a lot of time to do much, with it being the holidays and family. I have to run out again to the store, it never stops. Eventually I will have a few minutes to sit down and look at this more. Hopefully I will figure it out however we do have iXsystem involved as well now thanks to @Captain_Morgan so with some luck, maybe they can provide a simple solution that we can utilize without much rework to our scripts.
This is an example using midclt:
midclt call -job mail.send '{"subject": "foo", "html": "<b>bar</b>", "to": ["foo@gmail.com"]}'
7 Likes
Great 
Sending from the shell worked for me!
@william That is very promising. That command works in SCALE but not CORE, however that is an easy thing to account for so it is really not an issue when someone just checks to see what version of TrueNAS is being run.
I was able to send myself an email with the HTML code, things are looking up.
The next two hurdles are:
- Attaching one or more files.
- Replacing the
"html": "<b>bar</b>"with a file which contains the assembled html text file. I tried using a file name, a variable name, and I get a Dict error. Iām sure there must be a way to pass a variable fo the data. Right now I pipe the file into sendmail, I doubt I can pipe into this midclt function.
In my current $logfile_headers variable, it contains mixed part content, where it includes links to the file attachments. Iām not sure if the mail.send call can handle that data as-is, so I could reformat the data to a simple HTML file, but I still need the ability to add attachments. So before I go through all the changes to make it a simple HTML file, I need to address the two listed issues above.
And with all that said, my time will be minimal here in the forums for the next 2 days due to the holidays. I hope everyone has a fantastic holiday period. Those are the politically correct words to say. But for the not as politically correct, Happy Hanukkah, Merry Christmas, or whatever you celebrate, and a Happy New Year to everyone. My wife has her new Christmas Car, she is very happy, she might not hit me in the ribs tonight while Iām snoring 
. I will get a few pair of socks, and that is okay.
3 Likes
Replacing html with a file content is something like this:
midclt call -job mail.send "$(echo '{"subject": "foo", "to": ["foo@gmail.com"]}' | jq --rawfile f /tmp/mail '.html = $f')"
Doing attachments is somewhat more complicated since it requires the use of _upload API endpoint, I will need to draw an example.
4 Likes
Attachments example:
curl -v -u admin:password -F 'data={"method": "mail.send", "params": [{"subject": "foo", "to": ["foo@gmail.com"], "html": "foo", "attachments": true}]}' -F "file=@/tmp/attachment" http://127.0.0.1/_upload/
/tmp/attachment is a json:
[
{
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "test.txt"
}
}
],
"content": "dGVzdAo="
}
]
Granted, not straightforward at all, but definitely easier in some language like python than shell script
5 Likes
I can confirm that this also worked for me on all three servers (2 production and one test VM). I sshād into each as admin and ran the command after changing the email address to send to. It also generates the correct fault if you donāt change the email address from foo.
An update from my testing (it wasnāt Christmas Presents that woke me up early, it was the kitten attacking the dogs, the dogs donāt know what to do, they are use to less playful cats around the house, I wish one of the dogs would just nip the kitten once to say āback offā but they are not aggressive towards cats) this early morning:
I have been able to send emails, but adding attachments has been tricky. I can add an attachment, sort of.
Here is the data Iām using (of course Iām not Santa but my wife might think so with that new car):
curl -v -u truenas_admin:SantaClaus1 -F 'data={"method": "mail.send", "params": [{"subject": "foo", "to": ["Santa@msn.com"], "html": "<b>foobar</b>", "attachments": true}]}' -F "file=@attachment" http://127.0.0.1/_upload/
where truenas_admin:SantaClaus1 is the user account and password for that account. It must be a privileged account.
and the file called āattachmentā:
{
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "config_file.txt"
}
}
],
"content": "/mnt/farm/scripts/multi_report_config.txt"
}
]
With this format I receive an email with an attachment named config_file.txt however that file contains the text /mnt/farm/scripts/multi_report_config.txt, not the actual config file.
I have tried a lot of variations for the ācontentā line:
"content": "'/mnt/farm/scripts/multi_report_config.txt'"
"content": "=/mnt/farm/scripts/multi_report_config.txt"
"content": "=</mnt/farm/scripts/multi_report_config.txt"
"content": "</mnt/farm/scripts/multi_report_config.txt"
"content": "@/mnt/farm/scripts/multi_report_config.txt"
"content": "=@/mnt/farm/scripts/multi_report_config.txt"
The one thing I figured out, you must have double quotes around the text, it fails to send any attachment without those.
The data it does send is encoded, the email account which sends the file have the text encoded (odd I thought as I canāt see what really was transmitted and sendmail did preserve the original expected sent format), but it shows up at the receiver side readable.
I have referenced the curl manual, how to send email using curl in python (which looked promising, until it wasnāt).
Iām certain there is some proper data to enter into the content line for one or multiple attachments, it just alludes me so far.
I will be testing if I can place variables into the subject, to, ,html, and user account sections of the command line as this is very important to have work.
Have a happy crazy day 
7 Likes
The ācontentā must be a base64 encoded string of the file
Can you please help Joe out a bit more than that? He is not a programmer and itās amazing heās gotten this far. Many users rely on his continued support of this script. You sound like you have the answerā¦ could you please share so he can move on with his life? Thanks for any help in this project.
1 Like
base64 is installed by default and can work on standard input:
% echo dGVzdAo= | base64 --decode
test
1 Like
With the help of @neofusion I was able to, or think I created a base64 encoded file. I used the command base64 /mnt/farm/scripts/multi_report_config.txt > multi_report_config.enc
Then I changed the attachment file content to: "content": "multi_report_config.enc"
And I still received a file with the the text of content, not the actual file.
Lastly I resorted to copy/paste the entire encrypted file as text into the attachment file. I did not receive an email this time, if failed, so that didnāt work either.
Iām still looking for how to attach one to multiple files into a single email.
Hereās a command that works for me:
curl -v -u santa:hohoho -F 'data={"method": "mail.send", "params": [{"subject": "testtest", "to": ["santa@icepole.net"], "html": "<b>This is just a merry test.</b>", "attachments": true}]}' -F "file=@/mnt/icepool/home/santa/attachment1.json" http://127.0.0.1/_upload/
The contents of the attachment1.json-file is:
[
{
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "testfile1.txt"
}
}
],
"content": "IyB+Ly5wcm9maWxlOiBleGVjdXRlZCBieSB0aGUgY29tbWFuZCBpbnRlcnByZXRlciBmb3IgbG9naW4gc2hlbGxzLgojIFRoaXMgZmlsZSBpcyBub3QgcmVhZCBieSBiYXNoKDEpLCBpZiB+Ly5iYXNoX3Byb2ZpbGUgb3Igfi8uYmFzaF9sb2dpbgojIGV4aXN0cy4KIyBzZWUgL3Vzci9zaGFyZS9kb2MvYmFzaC9leGFtcGxlcy9zdGFydHVwLWZpbGVzIGZvciBleGFtcGxlcy4KIyB0aGUgZmlsZXMgYXJlIGxvY2F0ZWQgaW4gdGhlIGJhc2gtZG9jIHBhY2thZ2UuCgojIHRoZSBkZWZhdWx0IHVtYXNrIGlzIHNldCBpbiAvZXRjL3Byb2ZpbGU7IGZvciBzZXR0aW5nIHRoZSB1bWFzawojIGZvciBzc2ggbG9naW5zLCBpbnN0YWxsIGFuZCBjb25maWd1cmUgdGhlIGxpYnBhbS11bWFzayBwYWNrYWdlLgojdW1hc2sgMDIyCgojIGlmIHJ1bm5pbmcgYmFzaAppZiBbIC1uICIkQkFTSF9WRVJTSU9OIiBdOyB0aGVuCiAgICAjIGluY2x1ZGUgLmJhc2hyYyBpZiBpdCBleGlzdHMKICAgIGlmIFsgLWYgIiRIT01FLy5iYXNocmMiIF07IHRoZW4KCS4gIiRIT01FLy5iYXNocmMiCiAgICBmaQpmaQoKIyBzZXQgUEFUSCBzbyBpdCBpbmNsdWRlcyB1c2VyJ3MgcHJpdmF0ZSBiaW4gaWYgaXQgZXhpc3RzCmlmIFsgLWQgIiRIT01FL2JpbiIgXSA7IHRoZW4KICAgIFBBVEg9IiRIT01FL2JpbjokUEFUSCIKZmkKCiMgc2V0IFBBVEggc28gaXQgaW5jbHVkZXMgdXNlcidzIHByaXZhdGUgYmluIGlmIGl0IGV4aXN0cwppZiBbIC1kICIkSE9NRS8ubG9jYWwvYmluIiBdIDsgdGhlbgogICAgUEFUSD0iJEhPTUUvLmxvY2FsL2JpbjokUEFUSCIKZmkKCiMgQ3VzdG9tIGNoYW5nZSBzZXQgUEFUSCBzbyBpdCBpbmNsdWRlcyBzeXN0ZW0gYmlucwpleHBvcnQgUEFUSD0iL3Vzci9sb2NhbC9zYmluOi91c3Ivc2Jpbjovc2JpbjokUEFUSCIK%"
}
]
In the above example I base encoded my sacrificial .profile using:
base64 --wrap=0 .profile
And then I copy/pasted that output as a value to the ācontentā-property in the json, as shown above.
The result is a mail like follows:
In theory it should be a simple matter of just adding another pair of -F "file=@/mnt/icepool/home/santa/attachment2.json" or similar, but I havenāt gotten that to work, I still only get a single attachment.
If you put 2 different file in the attachment1.json, It works? The JSON structure Is an array of JSON objectā¦ But probably iām still drunk from holidays 
1 Like
So far no luck doing that. The json has no obvious way of numbering attachment or differentiating them from each other.
These, among others, both failed:
[
{
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "testfile1.txt"
}
}
],
"content": "<base64_encoded_string_from_file1>",
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "testfile2.txt"
}
}
],
"content": "<base64_encoded_string_from_file2>"
}
]
[
{
"headers": [
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Type",
"value": "application/octet-stream",
"params": {
"name": "testfile1.txt", "name": "testfile2.txt"
}
}
],
"content": "<base64_encoded_string_from_file1>",
"content": "<base64_encoded_string_from_file2>"
}
]
When they donāt error out because I messed up delineation they still only result in a single attached file in the email, and that attachment is not a composite of the two files.
I am starting to suspect that middlewared only looks at the first file it finds and then stops, but thatās just a gut feeling at this point.
Fallbacks, if this canāt be made to work, is to tar/gzip the files before attaching them, or sending two emails I guess.