subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+1 vote
1,227 views 1 comments

right now, many built-in features can send emails for events. Each individual feature tries to send emails locally. But if given target of email (the configured "remote" email server) cannot be reached, each feature needs persistence and retry function for waiting and retransmitting. Also it's hard to trace the email content and change the retry interval for this.

It would be really comfortable, if RUT9x firmware includes a SMTP/POP3/IMAP email server (like some NAS devices does).

With this server, listening on localhost, you can configure all local features to send their emails to this local email server which is always up and reachable.

This local server provides
- a unified local persistence for all data, emails and attachments
- also it provides local routing & forwarding options for emails
- you can then define nice content depending forward rules to send the received emails to (one or many) remote server(s) to alert somebody
- this remote sending tasks are stored in the outbox and outbox can be easily configured e.g. the retry intervals if target is not reachable

Another big advantage would be that external devices (e.g. in local (W)LAN) can send emails to RUT9xx also to use the perfect avilability (it's always up and in local network) this persistence and the routing/resend capabilities.This is a common usecase for surveillance cams connected by (W)LAN to RUT9x sending emails in case of motion alarm. The FOSCAM FI9903P for example has no local persistence, so in case of an motion alert, video or picture data is instantly transmittetd by EMail (or FTP) (as an attachment) to another device.

Without local email server, we have to confirure a VPN to push the emails from IP cam via RUT VPN to a remote server online which is fine unless the remote host is temporarily not reachable. This leads than to a data loss and/or weak and uncontrollable resent tries within IP cam. Each IP cam firmware does its own mess here . This szenario is not relieable enough.

Alternatively, RUT9xx could provide at least a FTP server where IP cams can put their data to. But FTP has no nice automatic routing/resending feature of received data like email has

Best regards, Mat72

1 Answer

0 votes
by anonymous

Thank you for the suggestion! I'll be sure to give this info to Teltonika for research.

However, I'm not sure if RUT9's flash capabilities are enough to support an email or FTP server. But adding configurable retry intervals is more than possible. Am I correct in assuming that you're using Input rules to send emails? Because Events Reporting has the retry count option, but I can see that Input rules do not.

Also, if you're using RUT955, you can configure an FTP server on a USB flash, HDD or SD card.
Best answer

thank you for your answer. As you assumed I use input rules but also other devices connected to RUT by LAN/WLAN which are able to send emails or have a build-in FTP client. For this, the RUT should offer a FTP server and (even better) a MTA like Postfix. As you mentioned, I use a mounted USB stick for persistence, to save internal RUT flash memory.

The home of the FTP users and the MTA storage could be located to USB storage and everything is fine.

If you add an MTA by default, all your build-in retry count & interval configurations at each event source (like input rules) will be obsolete if you configure localhost as SMTP server. The same for all devices in RUT network, they use RUT as SMTP server. It is always available :-)

Then, in the outbox of the MTA (the sendmail part) needs a retry config only, not every event source any more. Also the MTA outbox can be configured to forward incomming mails to specific destinations. This email routing option is also centralized now and don't need to be implemented at every mail source again and again...