Email-Traps

Mail trap messages are automatically generated by industrial systems for information and status reports. Retrieved and evaluated by a corresponding recipient they are very useful inside semi- or fully-automated infrastructures. The difference to a normal email is that there is no option to enter custom text or define a different recipient.

Information included in the Email Trap is typically only useful for the UNMS II system. The email content includes: MAC address, UPS model, UPS location, IP address, IPv6 address, Actual event as well as a .json and a .xml file in the attachment.

A valid mail account must be deposited to send mail traps.

For details, please refer to the article Configuration of a UPS in the Help Center or to the corresponding Chapter Configuring UPS in the CS141 manual

If you want to use the same account that you have already set up under "E-Mail", you can simply transfer the data using "Copy from E-Mail".

"Copy from Email" duplicates your mail account data for Mail trap services. The only manual task is confirming passwords. In case of an alternative mail account is in use, specify the according access data.

Tutorial: Email-Traps

Trap messages are a very popular way to automatically get information from a network. The concept provides that a device sends its status in the form of a standardized data packet as soon as its current status changes. Among other things, the transmitted data strongly depends on the device and its function.

The key feature of a trap message:

The type of transmission is unidirectional - the packet is sent and there is no acknowledgment of receipt. If the device can send the packet, the task is completed. Since messages are only sent when a status changes, the target program assumes that the last received status remains valid. 

Especially in weaker networks or in networks where many messages of this kind are sent, this is an advantage, particularly when a large number of devices need to be monitored or the network is poorly developed.

Both the required computing power and the amount of status data inside a network can be minimized:

The CS141 is capable to send trap messages to a monitoring software like the UNMS II in order to indicate a status change of a UPS.

However, a problem may arise:

As the network grows, some segments may not be able to provide a permanent network connection for technical reasons—at least not until costly major network installation work has been completed.

Does the argument of a better connectivity justify the costs of a network implementation or is there a better solution?

With Email-Traps, the CS141 offers an interesting way to meet this situation:

The CS141 uses the e-mail function to send an according message if the system status changes - a timestamp ensures that an outdated data package will be noticed but not used for the current system status monitoring. The mail server holds the e-mail until a connection is possible - and forwards this mail to a custom e-mail address a UNMS II can access.

The UNMS II is the recipient. It will look for incoming mails and handle them like trap messages.

Note:

The advantage is the fact that local connection options can be used to ensure basic communication between a device and a monitoring system. The focus is set on ensuring communication - the communication speed depends on the local infrastructure that is available:

The UNMS II displays incoming information directly on arrival but can not determine when a valid e-mail arrives from a remote system.

How many mail addresses are possible with Mailtraps?

There are 2 different ways of looking at-

The mail distributor / vendor

The UNMS connects to a mailbox, downloads the mail intended for it, and deletes them from the server. A UNMS key provides two installations within a network:

Once is a blind or dummy system for the configuration work, and a "production system“. This option provides testing the configurations extensively before using on the production system via backup/restore functions. Now, if both UNMS packages access the same e-mail mailbox, the general uptime and the time of incoming e-mails will decide which of the two UNMS installations will fetch the e-mail and delete it from the e-mail server.

As a result, e-mails seem to "disappear" from the view of the productive system.  The remedy here is a distribution list:

The mail server receives the mail at unms@beispieladresse.net and then distributes it to two different mail addresses:

UNMS 1 "Dummy" fetches its mails exclusively from unms1@beispieladresse.net

UNMS 2 "Production" fetches its mails exclusively from unms2@beispieladresse.net

Different mail receiver
This scenario is interesting if service contracts exist, and there is the need to receive UPS data in parallel to serving maintenance contracts:

To use this function, just configure at E-Mail to: mail1@receiver1.com,mail2@receiver2.com,....

In this way, the service provider and the customer can refer to the same data situation and plan corresponding maintenance windows together.

Which of the two possibilities should be used in this case depends on the operating scenario of the UNMS / CS141 combinations.