As of now, the library uses name field to identify inline attachments. As in, it expects the user to have the body in the format <img src="cid:{name} ...> and the attachment to be mail.File{name: <name>}.
This limitation is currently because the fact that we get the contentID based on the name here and also does replaceCIDs on the body.
There are a few drawbacks for this approach:
One cannot attach different files with the same name inline
With the currently implementation, I'm forced to use cids and names(the values of cids and names are out of my control) in mail.File, but Outlook does not like certain names (for example ones that ends with .com).
Proposal for a fix: We can optionally accept CID in mail.File and if a CID is provided, use that instead of name in the code locations I have mentioned earlier. I can send you a PR if you are interested.
As of now, the library uses name field to identify inline attachments. As in, it expects the user to have the body in the format
<img src="cid:{name} ...>
and the attachment to bemail.File{name: <name>}
.This limitation is currently because the fact that we get the contentID based on the name here and also does replaceCIDs on the body.
There are a few drawbacks for this approach:
mail.File
, but Outlook does not like certain names (for example ones that ends with.com
).Proposal for a fix: We can optionally accept
CID
inmail.File
and if aCID
is provided, use that instead of name in the code locations I have mentioned earlier. I can send you a PR if you are interested.