[jira] [Commented] (CAMEL-24432) camel-mail - a single malformed message can permanently stop the consumer

["Andrea Cosentino (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-24432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118279#comment-18118279 ] 

Andrea Cosentino commented on CAMEL-24432:
------------------------------------------

Fixed via https://github.com/apache/camel/pull/26659 (squash commit 687c440f2938aa633256f124207e84d2dbd0ff30), merged to main for 4.23.0. Backport labels set for camel-4.22.x and camel-4.18.x so the backport bot will port it automatically.

_Claude Code on behalf of acosentino_

> camel-mail - a single malformed message can permanently stop the consumer
> -------------------------------------------------------------------------
>
>                 Key: CAMEL-24432
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24432
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-mail
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.23.0
>
>
> Three independent paths turn one hostile or merely unusual message into a consumer that never makes progress again. All are reachable from a mailbox the route polls.
> *1. MailSorter.compareMessageProperty - NPE on legally absent headers.*
> {code:java}
> } else if (property.equals(SortTerm.SUBJECT)) {
>     String sub1 = msg1.getSubject();
>     String sub2 = msg2.getSubject();
>     return sub1.compareTo(sub2);
> }
> {code}
> Subject is optional in RFC 5322, so getSubject() returns null and compareTo throws. The TO/CC/FROM branches index [0] of an array that can be null or empty, and the ARRIVAL/DATE branches call compareTo on a Date that can be null. Client-side sorting is always used for POP3, and for IMAP when the server has no SORT capability, so a single message without the sorted-on header aborts every subsequent poll.
> *2. MailBinding.extractAttachmentsFromMultipart - unbounded recursion.*
> {code:java}
> if (part.isMimeType("multipart/*")) {
>     extractAttachmentsFromMultipart((Multipart) part.getContent(), map);
>     continue;
> }
> {code}
> There is no depth limit, so a deeply nested multipart yields StackOverflowError during extraction, before the message is processed.
> *3. MailConverters.toString(Message) - non-terminating loop.*
> {code:java}
> while (content instanceof MimeMultipart) {
>     MimeMultipart multipart = (MimeMultipart) content;
>     if (multipart.getCount() > 0) {
>         BodyPart part = multipart.getBodyPart(0);
>         content = part.getContent();
>     }
> }
> {code}
> When getCount() == 0 the body of the if never runs, content is never reassigned, and the loop spins forever, pinning the thread. Empty multiparts are reachable when mail.mime.multipart.allowempty is set for interop.
> Proposal: make compareMessageProperty null-safe (treat a missing header, recipient or date as lowest ordering); enforce a maximum multipart nesting depth in extractAttachmentsFromMultipart; and break out of the converter loop when the count is zero. Each wants a test with the corresponding malformed message.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)