Email config, and debugging such config

TrueNAS General
,
1

Running TrueNAS Scale 25.10. I believe the email config was changed from what I used to about 1/4 understand, so now I don’t understand it at all.

I don’t think I’m getting the most basic SMTP server config set up correctly. All the things on the Email Options screen look familiar, I’ve set them up according to my provider’s instructions, I’ve cross-checked that they match what I configured in Thunderbird. They’re working in Thunderbird on my laptop and other places.

But from TrueNAS, clicking the send test mail button pops up a dialog, runs a progress bar, and closes the dialog. But no email shows up anywhere, including the deepest spam directories.

I’ve looked for log entries on my TrueNAS server that might possibly show me something going wrong in the send (though I would hope that a test email sending problem would report in the GUI!). I find some old stuff in the exim log files, nothing at all in messages.

So I’m kind of out of ideas. Any suggestions.

2

If you manually trigger an email from shell:

midclt call mail.send '{
  "subject": "Test",
  "html": "Test Email",
  "to": ["change_me@email.com"]
}'

(Should be correct, if i well remember)

Can you see if the job (you can grab the id after send the command) Is success or not?

Also if you want you could sharebthe actual config:

midclt call mail.config | jq

BUT ENSURE TO HIDE SENSITIVE DATA :smile:

3

Yikes, new tools have grown up when I wasn’t looking! They actually seem like they might be rather cool.

Okay, your command gives me a job number, but the job number isn’t compatible with current PID numbers, so I don’t know what it represents, so I don’t know how to check if it succeeded or not. midclt returned status 0.

The config (minus the password) is:

ddb@fsfs:~/proj/zfsbackup$ midclt call mail.config | jq
{
“fromemail”: “dd-b@fsfs.bpoly.local”,
“fromname”: “fsfs”,
“outgoingserver”: “``smtp.dreamhost.com``”,
“port”: 587,
“security”: “TLS”,
“smtp”: true,
“user”: “``dd-b@dd-b.net``”,
“pass”: “Sensitive Data :-)”,
“oauth”: {},
“id”: 1
}

The “from email” won’t work from outside, but that’s just the envelope sender if I read the doc right.

Outgoingserver and user look like they have spaces around them, but they do not have those spaces in the GUI, and if I omit jq and read the JSON directly, the spaces are not present there. So that seems to be an artifact of jq rather than an actual problem in the config.

4

Job IDs have always corresponded with internal middleware jobs. You can see them in core.get_jobs output, or if you run the midclt command with the -j flag it will stream the in-progress job status to stdout on your terminal.

5

And it looks like the job info was kept since I ran it. The mail send command seems to have succeeded:

  {
    "id": 50545,
    "message_ids": [
      "b7fd5c68-d666-48f9-8947-077531d72c7b"
    ],
    "method": "mail.send",
    "arguments": [
      {
        "subject": "Test",
        "html": "Test Email",
        "to": [
          "dd-b@dd-b.net"
        ]
      }
    ],
    "transient": false,
    "description": null,
    "abortable": false,
    "logs_path": null,
    "logs_excerpt": null,
    "progress": {
      "percent": 100,
      "description": "",
      "extra": null
    },
    "result": true,
    "result_encoding_error": null,
    "error": null,
    "exception": null,
    "exc_info": null,
    "state": "SUCCESS",
    "time_started": {
      "$date": 1774195870000
    },
    "time_finished": {
      "$date": 1774195871000
    },
    "credentials": null
  }

Thank you for the pointers, that was enough to let me find this. Obviously I need to go back and learn about these new tools, they appear to be extremely useful if understood. And they make enough sense that very small increments of knowledge produce immediate improvements in results :slight_smile: .

6

Bingo! I have had a test message from my NAS reach my normal email account.

What I did was change the from address in the config to be a valid email address (the old one was a legit format, “looked like” an email address, but wasn’t valid). I did this hoping that perhaps a bounce would then reach that address and tell me what was wrong.

Now, I don’t know exactly what the process by which the previous config failed was. But I made that one change, ran a new test, and got a positive result, so I’m pretty sure that change was what did it.

Usually the outgoing email address isn’t critical, except for replies. If it’s somehow critical here, maybe that should be documented in the email config instructions?

7

Looking more closely – the email was delivered to the from address I put in the config. The help on the from address confirms that it is the from address. But apparently it’s actually the notification to address? If that’s true, the documentation and GUI help need to be updated to reflect this. (If we conclude that’s really true, I can try to write up a formal report.)

8

Glad you resolve somehow, but

Is not true, most SMTP provider are not tolerant about that. And despite some server allow use a different address, most of the receiver will simply reject the message.

I don’t think Is a lack truenas side, email delivery to me really seems totally out of scope :smile:

9

Email notifications are an important feature in my opinion. And they can’t work unless email gets delivered, and you know how to configure where to deliver it.

As to who checks what and what they allow, my experience seems to be very different from yours. But then my first big email activity was running Bruce Schneier’s Cryptogram email list off a server co-hosted at a local ISP, some time ago (and then later off the same server on a DSL line in my basement).

10

Just to be fair :smiley: it was absolutely not my intention to say that email notifications aren’t important, or that the effectively delivery isn’t important… i totally agree there

but the same, i don’t even consider a problem the fact that the TN documentation not cover (probably at all, didn’t check recently honestly) tip/troubleshooting related to deliverabilty, or not provide any real delivery tracking about emails send… just because this IMHO is totally out of scope for a NAS appliance.
The big problem here, wanting to summarize it, is spoofing; every provider threat this problem with own policy

  • some provider have 0 tolerance and refuse the request
  • some provider just silently drops message
  • some provider overwrite the sender with the owner address (in my experience, like Gmail do)
  • some provider accept the request

and for those message that pass (in my experience, not count on that so much), they are validated also on the receiver

  • they can be accepted (really rare)
  • they get bounce
  • they get marked as spam
  • they get silenty drop

I don’t know the reason why you decided to use a “fake” address, you surely had a good reason for that, and if i may guess is to receive nas messages from a dedicated address… and if i’m right, i would really suggest to use alias instead. I use Gmail for me, mostly for that, it provides the capability to generate an alias just adding + after the local part, so i can quickly understand what system generate the message