NMS-8099: MailTransportMonitor steps all over itself

[dino2gnt]

Typing up a very old loose end...

When multiple nodes have a configured MailTransportMonitor service all sharing the same destination mailbox, the email subject is not sufficiently unique and collides with emails from other nodes. The deletion logic will then delete emails that actually belong to other pollers, causing those services to be marked down. This change tacks the nodeId of the polled node onto the subject and the MTM header, keeping each node's subjects distinct, so they will not collide and step on each other's test emails.

This is probably extremely low risk - I don't think the MailTransportMonitor has many (or maybe any) users. (hello, fellow graybeards, here wondering why your MTM subjects changed!)

Ancient history trivia - this was the first time I ever attempted to write Java, and might be the first jira issue I ever created. I ran this modification in production, monitoring mail transport latency between internal Exchange servers in different countries.

All Contributors

• Have you read our Contribution Guidelines?
• Have you (electronically) signed the OpenNMS Contributor Agreement?

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-8099

[marshallmassengill]

Ship it.

[indigo423]

If you use the MailTransportMonitor with perspective monitoring, the NodeID wouldn't be sufficient enough and you need also the monitoring location.

[dino2gnt]

If you use the MailTransportMonitor with perspective monitoring, the NodeID wouldn't be sufficient enough and you need also the monitoring location.

There are limitations to this fix, but this is an improvement over the original state.

If the service is on two interfaces of the same node, it's also insufficiently unique.

[cgorantla]

LGTM!