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?

@Damian Wright What is the behavior that you expect?

• Keep only "attachment" dispositions?

• Make a unique file name?

• Overwrite the first file name with the subsequent one?

Hi Pothys,

I have confirmed that ACF has the same bug (bug ID logged as CF-4203046)... when names are the same it incorrectly identifies the attachments as the inline images. see attached putty.log (excerpt below)

Note that there are two image001.gif mime encoded inclusions for the email, also note that one is content-disposition :attachment, Lucee incorrectly 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"

Hi @Damian Wright,

I've checked the above comments, Lucee pointing out content id in cid in structs. How the ACF handles this?

Open

Open

I've additionally confirmed that Lucee fails to recognise the difference between inline CID's and attachments with the same name.

see the attached (putty.log) - CID for inline image image001.gif is cid:image001.gif@01D40CA4.DFA30640, Lucee incorrectly labels this as 731E8F99E08C0F4C9DFA8FC570B4A3A9@mediamark.co.za in the cids struct.

731E8F99E08C0F4C9DFA8FC570B4A3A9@mediamark.co.za is the content ID for the image001.gif attachment.