tracker issue : CF-4203046

select a category, or use search below
(searches all categories and all time range)
Title:

CFPOP CID's processing

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Damian Wright / ()

Created: 07/02/2018

Components: Language, Tags

Versions: 2016,2018

Failure Type: Incorrectly functioning

Found In Build/Fixed In Build: Latest / 2020.0.0.314573

Priority/Frequency: Minor / Few users will encounter

Locale/System: ALL / Win 2016

Vote Count: 0

Problem Description:
CFPOP incorrectly labels CIDs struct with attachment mime ID's instead of inline image CIDs, see cfdump image (capture) of EMail CIDs, also see attached putty (1).log for actual email SMTP download.

Steps to Reproduce:
retrieve email using CFPOP with attachments named the same as the inline HTML images

Actual Result:
Incorrectly labels CIDs - see attached image

Expected Result:
CIDs should match content ID embedded in EMail HTML content.

Note that there are two image001.gif mime encoded inclusions for the email, also note that one is content-disposition :attachment, ACFincorrectly uses this contentID: for the inline image.

Refer RFC2557 https://tools.ietf.org/html/rfc2557 section 8.3 for confirmation that the CID in the embedded HTML must be matched against the CONTENT-ID header of the matching mime encoded file.

CID in html mail
cid:image001.gif@01D40CA4.DFA30640

Mime header for inline image
------=_NextPart_002_005E_01D40D45.B2B83C30
Content-Type: image/gif;
name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01D40CA4.DFA30640>

Mime header for image attachment
------=_NextPart_001_005D_01D40D45.B2B83C30
Content-Type: image/gif;
name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <731E8F99E08C0F4C9DFA8FC570B4A3A9@mediamark.co.za>
Content-Disposition: attachment;
filename="image001.gif"

Attachments:

Comments:

Note that there is also a problem with inline image CIDS also having the same name as file attachments - identified in Lucee as well. suggestion as follows... Given that neither ACF nor Lucee gracefully process multiple file inclusions of the same name (if not using generateuniquefilename ACF returns duplicates) a workflow needs to be defined for preventing inconsistent states. (such as the wrong attachment being displayed) The existing code facilitates multiple file attachments using the same name - as long as they are not inline HMTL. (viz. attachmentsfiles[ position x] always equals attachments[ position x]) However, even were the CIDs correctly labelled, this would not resolve duplication of filenames between inline display and email file attachments. I suggest as follows :- if filename duplication exists between CIDs and attachments AND generateuniquefilenames = NO - throw exception if filename duplication exists between CIDs and attachments AND generateuniquefilenames = YES - rename CID filename, related attachment filename and attachmentfilenames to unique value if duplicated file attachment names exist AND generateuniquefilenames = NO - throw exception if duplicated file attachment names exist AND generateuniquefilenames = YES - throw exception - rename attachment filename and related attachmentfilenames to unique value does this make sense?
Comment by Damian W.
29150 | July 02, 2018 07:18:27 PM GMT
Hi Damian, I have sent an email with attachment and inline image having same name and retrieved it using CFPOP in CF 2016 update 6, I can see that the CID has the correct attachment name i.e., CIDs has the same content ID of embedded image in EMail HTML content. Attaching the screenshot. Am I missing something here?
Comment by HariKrishna K.
29156 | July 05, 2018 09:15:44 AM GMT
See attached missing cid.png inserted an html inline image named image001.png dropped image named image001.png into email as attachment -cfpop shows two image001.png in attachments. -cid for image001.png is missing from cids struct -body shows correct cid for immage001.png though
Comment by Damian W.
29157 | July 05, 2018 10:48:20 AM GMT
Additional comment - Even if the CID is enumerated, it's impossible to isolate which image attachment is being referred to given that they have the same name.
Comment by Damian W.
29158 | July 05, 2018 11:47:32 AM GMT
Hi Damian, Thanks for the info. I was able to reproduce this issue.  Just wanted to understand the requirement of having the attachment name and the inline attachment to image001.png?
Comment by HariKrishna K.
29250 | July 05, 2018 11:52:16 AM GMT
Hi, Sorry for the late reply. There isn't actually a requirement - but in ingesting emails I've found that outlook names inline attachments as Imagexxx.png xnd if users attach screenshots they're named the same way. This naming makes it impossible to reconstruct the original email (in ACF) since the inline and attached aren't necessarily the same image.and it's not possible to determine which is which from the CFPOP implementation. The application I'm working with is ingesting tens of thousands of emails a day and a user raised this as the received email (in the application) was missing an image and was different to the sent email.
Comment by Damian W.
29601 | August 22, 2018 01:04:14 PM GMT