Probably a bug: on-error doesn't get triggered for e-mail sending upon DNS failure

RouterOS General
1

Hello,

I have the following code in a script…

:do {
  /tool e-mail send to=noreply@example.com body="Body Message" subject="Sample subject"
}  on-error={ :log error "A friendly message" }

# some other code

If the above code fails due to DNS failure, on-error isn’t triggered. So, I don’t see “A friendly message” in the log. Instead, I see the following…


2025-06-02 07:50:15 dns,error DoH server connection error: while reading - Connection reset by peer
2025-06-02 07:50:15 e-mail,error Error sending e-mail : DNS resolve failed

As a result of this possible bug, the code that follows on-error (“some other code” mentioned in the sample) gets executed.

Update 1: I can reproduce the issue consistently, after removing DNS servers and/or DoH, thus triggering DNS failure (temporarily).
Update 2: I can reproduce the issue with :onerror syntax too.

For now, to avoid email failures (technically DNS/DoH failures), I’ve created the static DNS entries for the email server that is in use.

Anyone else having the same issue (that on-error isn’t triggered for e-mail upon DNS failure)?

2

[:do … on-error] was deprecated and may not work in some cases.

Try using this instead:

:onerror errName in={
  # your code
} do={
  # error handling
}

Keyword “in” can be omitted. Reference to the docs for details on :onerror command (https://help.mikrotik.com/docs/spaces/ROS/pages/47579229/Scripting#Scripting-Commands)

3

Thank you. I wasn’t aware of either info. I will try onerror.

Update: Same issue could be reproduced with onerror too. :frowning:

4

A DNS resolution will get caught if you use /tool/fetch or :resolve. Either using do/on-error=, or newer “onerror/in=/do=”.

However /tool/e-mail is “more asynchronous”, so I think, it gets queued like most MTAs… so any error in SMTP protocol happens after the command returns. That’s kinda how it works, so only indication of e-mail error is in the logs.

Now I agree it should “wait” for error in sending, so may be worth filing a feature request or bug. And, I cannot say if older version behave differently, but I want to say this how /tool/e-mail has worked for a while.

5

Thank you for your insights, Amm0. As suggested, I filed a bug report after consistently able to reproduce the bug (by turning off DNS resolution while testing).

6

You wrap the email send in a function, that checks DNS name.

Something like this should work in ~v7.17+:
:global sendmail do={
:local emailsplit [:deserialize from=dsv $to delimiter=“@” options=dsv.plain]
:if ([:typeof ($emailsplit->0->1)] = “str”) do={
:onerror errtext in={:resolve ($emailsplit->0->1)} do={
:error “failed: DNS $($emailsplit->0->1) got ‘$errtext’, message ‘$subject’ not sent to $to”
}
} else={
:error “failed: email has invalid format, message ‘$subject’ not sent to $to”
}
/tool/email send to=$to body=$body subject=$subject
}

then you can use the function to send email, with the DNS check…

$sendmail subject=“sub” body=“body” to=“bad”
This will parse the email address to get the domain, and then call :resolve “manually” on domain part - which does error if DNS fails. I then wrap the errors to better log it. The function can be loaded once, and then you can use “$sendmail” as many times as needed.

7

That’s a good idea, Amm0.

Technically, checking if DNS resolves for the email server domain used at /tool e-mail get server would do.

So, the following code would work…

:do { :resolve [/tool/e-mail/get server] } on-error={:error "DNS failure before sending the email"}
:do {
  /tool e-mail send to=noreply@example.com body="Body Message" subject="Sample subject"
}  on-error={ :log error "A friendly message" }

# some other code
8

Can you tell me where it is written?

9

I remember that somewhere I have already discussed this issue and for it to work correctly the variable must be defined first, if I remember correctly…
http://forum.mikrotik.com/t/conditional-not-boolean-bug-with-onerror-new-in-7-13/172543/1

10

Said by MT support in one of my tickets, when I had a similar issue.

11

They should write this publicly somewhere rather than reporting it in tickets… :man_facepalming:t2:

12

Yes, they definitely should. And I even asked them in that ticket, but they just replaced some error-catching examples in the docs with the new version.