[
https://issues.apache.org/jira/browse/CAMEL-24432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24432 started by Andrea Cosentino.
------------------------------------------------
> 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)
