[
https://issues.apache.org/jira/browse/CAMEL-24434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24434 started by Andrea Cosentino.
------------------------------------------------
> camel-mail - idempotency and POP3 delete are keyed on a sender-chosen
> Message-ID
> --------------------------------------------------------------------------------
>
> Key: CAMEL-24434
> URL: https://issues.apache.org/jira/browse/CAMEL-24434
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> DefaultMailUidGenerator derives the UID from the Message-ID header supplied
> by the sender:
> {code:java}
> private String generateMessageIdHeader(Message message) {
> String[] values = message.getHeader("Message-ID");
> if (values != null && values.length > 0) {
> String uid = values[0];
> return uid;
> }
> {code}
> with a fallback to the message number when the header is absent.
> That UID keys idempotent-consumer state and, for POP3, identifies which
> message to delete on commit. Both are therefore aliasable by whoever sends
> the mail: two messages carrying the same Message-ID collapse to one identity.
> The practical effects are a message that is processed but whose sibling is
> never deleted and is re-consumed on every poll, and replay of a previously
> seen identifier suppressing a legitimate message.
> Message-ID is chosen by the sending client and is not required to be unique
> in practice, so it is not a suitable sole key for either purpose.
> Proposal: disambiguate the UID - for POP3 combine the Message-ID with the
> UIDL, and otherwise with a content hash - and have the delete path target the
> folder entry it actually processed rather than re-resolving by UID. Keeping
> the current behaviour available as an option would ease migration for routes
> that depend on it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
