Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[watcher] Message-ID reused in emails generated with foreach parameter #52513

Closed
immon opened this issue Feb 19, 2020 · 5 comments
Closed

[watcher] Message-ID reused in emails generated with foreach parameter #52513

immon opened this issue Feb 19, 2020 · 5 comments
Labels

Comments

@immon
Copy link
Contributor

immon commented Feb 19, 2020

Elasticsearch version (bin/elasticsearch --version): reported in 7.5

Description of the problem including expected versus actual behavior:

When Watcher's email action is run multiple times thanks to foreach parameter, then all generated email messages use the same Message-ID header.

RFC2392 states that Message-ID should be unique:
Both message-id and content-id are required to be globally unique. That is, no two different messages will ever have the same Message-ID addr-spec;

A similar issue was fixed in the past #30112 by adding action_id to Message-ID. With foreach it's not enough since we have one action but generate multiple email messages.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features (:Core/Features/Watcher)

@jgregmac
Copy link

jgregmac commented Apr 3, 2020

Bummer! I am having this problem as well. It is preventing delivery of Watcher alerts to our ticketing system as the receiving system insists on strict adherence to RFC2392 Message-ID uniqueness.

@kkojouri
Copy link

I'm seeing the same issue on our side, getting the same Message-ID even when the body of the messages are different. This results in missing alerts in our ticketing system (which doesn't support Webhook).

@rjernst rjernst added the Team:Data Management Meta label for data/management team label May 4, 2020
@toby-sutor
Copy link
Contributor

This has been addressed here: #56574

@joegallo joegallo added the >bug label Nov 4, 2020
@joegallo
Copy link
Contributor

joegallo commented Nov 4, 2020

Closing since #56574 has been merged.

@joegallo joegallo closed this as completed Nov 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants