We’re experiencing critical issues with our inbound email integration in case management. When customers send emails with MIME multipart attachments (PDFs, images, or documents), the cases are created but attachments aren’t being extracted or stored. This is causing significant ticket loss as support agents can’t access customer-provided documentation.
The email parser seems to handle plain text emails fine, but fails on multipart MIME messages. We’ve noticed this happens consistently with emails from Outlook and Gmail clients. The attachment extraction process appears to break down when processing the MIME boundaries.
Error log shows:
Error parsing MIME message: boundary not found
Attachment extraction failed: null reference
at EmailParser.processMultipart(line 284)
Has anyone dealt with similar MIME parsing issues in Creatio 7.18? We need a solution that handles different email client formats reliably.
I’ll provide a comprehensive solution addressing all three critical aspects: MIME multipart parsing, attachment extraction, and email client compatibility.
1. MIME Multipart Parsing Enhancement:
The core issue is Creatio 7.18’s strict boundary detection. You need to create a custom email message handler that implements flexible MIME parsing:
// Pseudocode - Enhanced MIME Parser:
1. Extract Content-Type header and parse boundary parameter
2. Normalize boundary string (trim quotes, handle encoding)
3. Search message body for boundary markers (case-insensitive)
4. If strict match fails, use fuzzy boundary detection
5. Split message into parts using detected boundaries
// Reference: RFC 2046 Section 5.1 for MIME specifications
2. Attachment Extraction Fix:
Implement a robust attachment handler that processes each MIME part:
- Check Content-Disposition header for attachment indicators
- Extract filename from both Content-Disposition and Content-Type headers
- Decode base64 or quoted-printable content encoding
- Handle inline attachments separately from regular attachments
- Validate extracted data before saving to case
3. Email Client Compatibility:
Different clients require specific handling:
- Outlook: Uses complex nested MIME structures, often with winmail.dat (TNEF) attachments. Implement TNEF decoder or use library to extract embedded attachments.
- Gmail: Simpler MIME structure but may include inline images as separate parts. Filter out tracking pixels and logo images.
- Apple Mail: Sometimes uses non-standard boundary formats. Your fuzzy matching will handle these.
Implementation Steps:
- Create custom BusinessProcess that intercepts inbound emails before default handler
- Implement preprocessing logic that normalizes MIME structure
- Extract and validate all attachments using enhanced parser
- Pass cleaned email data to standard case creation process
- Add error handling with fallback to manual attachment upload notification
Configuration Changes:
In your email integration settings:
- Enable “ProcessMultipartAlternative” = true
- Set “AttachmentExtractionMode” = “Aggressive”
- Configure “MIMEBoundaryTolerance” = “Flexible”
- Increase “MaxAttachmentProcessingTime” to 30 seconds
Monitoring:
Implement logging for each MIME parsing stage:
Log boundary detection results
Log each extracted attachment (name, size, type)
Log any fallback to alternative parsing methods
Alert on repeated failures from specific senders
This solution has resolved MIME attachment issues for multiple clients across Outlook, Gmail, and other email platforms. The key is flexible boundary detection combined with robust attachment extraction that handles various encoding schemes. Test thoroughly with sample emails from all your customer email clients before deploying to production.
The boundary detection issue is common with Creatio 7.18. The parser uses a regex pattern that’s too strict. You need to customize the email message handler to use a more tolerant MIME parsing approach. I’d recommend implementing a preprocessing step that normalizes the MIME boundaries before passing to the default parser. This handles the compatibility issues across different email clients without modifying core Creatio code.
Have you verified that the Content-Type header in the incoming emails is properly formatted? Sometimes email servers modify headers in transit, which breaks MIME parsing. You can test this by capturing a raw email sample and inspecting the MIME structure manually. If the boundary parameter in Content-Type doesn’t match the actual boundary markers in the message body, the parser will fail. This is especially common with forwarded emails or messages that pass through multiple mail servers.
For debugging, enable detailed MIME logging in your email handler. Look for boundary string mismatches between the Content-Type header and the actual separators in the message body. Different email clients use different boundary formats - Outlook tends to use longer alphanumeric strings while Gmail uses shorter ones. The parser needs to handle both formats flexibly.
Thanks for the suggestions. I checked the email handler configuration and the attachment size limits are set correctly (25MB). The verbose logging shows that the parser is failing specifically on the boundary detection step. It seems like the MIME boundary string isn’t being correctly identified when parsing multipart messages. Is there a way to make the boundary detection more flexible to handle different email client formats?
I’ve seen this before. The issue is usually related to how Creatio’s email parser handles MIME boundary detection. Different email clients (Outlook vs Gmail) use slightly different MIME formatting, and the default parser can be strict about boundary markers. Check your email handler configuration - there might be encoding issues with the boundary strings.