I am having difficulty getting email attachments to work with the Insert From URL script step using cURL options. I'm able to get the body of the message, and all the correct to/from info, but attachments are being difficult. All I get as an attachment is "ATT00001". I'm sure it's some sort of encoding issue, but just can't seem to crack the correct syntax.
Anyone have any suggestions? Thanks!
2 Likes
What version of FileMaker are you using? 18, or something before that?
Hello @ByteTheBullet
Welcome to fmsoup.
I recall that, when the possibility of sending mail via cURL and SMTP first became available in FileMaker, that Soliant had a really nice blog post about this.
I think that this is the one:
(Even if it was not exactly this same blog post, the one listed above looks a lot like I remember.)
If you are already doing something along the lines of that blog post, maybe it would be good to share a few details about how your implementation is set up, and we can all take a look.
The main thing that I think would come as a surprise to many people is that this sort of endeavor requires some mastery of the format of how all the message headers, message content parts, and separators all come together to comprise the SMTP payload -- and that moreover, such mastery is not trivial. In my experience with this, details are important, and complexity rises as the message complexity increases (e.g. more parts, more types of attached content, inline content, etc.).
It is doable, however, and I remember that when I read Mislov's blog post (the one mentioned above), I thought that it was an excellent post.
Hope this helps.
Sincerely,
-steve
3 Likes
That’s interesting. That’s the same result we used to get when sending from a client with Fmp 64 bits and msOffice 32 bits (windows environment)...
We're using 18.
You may (will) find that using the provider's APIs to send emails and attachments is a lot easier and generally more robust. Especially if we're talking about G-Suite or Office365... something to consider.
1 Like
Yep, that blog post has been tremendously helpful.
For some more detail, I'm only working with a local file while I figure out how to make this work. All the relevant information is set to variables in the script. This particular use case is for non-HTML formatted bodies.
I start building the mail "file" in a variable ($mailContents) defined as:
"From: " & $from & "¶" &
"To: " & $to & "¶" &
"Subject: " & $subject & "¶" &
"Content-Type: multipart/mixed; boundary="MixedBoundary"" & "¶¶" &
"--MixedBoundary" & "¶" &
"Content-Type: text/plain; charset="utf-8"" & "¶¶" &
$body & "¶¶"
Then, if there are any attachments to be sent, the variable gets updated for each attachment:
$mailContents &
"--MixedBoundary" & "¶¶" &
"Content-Type: " & $attachmentMimeType[$acounter] & "¶" &
"Content-Transfer-Encoding: base64" & "¶" &
"Content-Disposition: attachment; filename="" & $attachment[$acounter] & """ & "¶¶" &
Email Test::attachmentPath[$acounter] & "¶¶"
And then finally, the variable is updated as follows after the loop for adding attachments is complete:
$mailContents &
"--MixedBoundary--"
The attachment path is saved in a field attachmentPath[], and the mime type for the given attachment is saved in a variable $attachmentMimeType.
The results I get have the correct to, from, subject, and body in the email, and the correct number of attached files, but all attached files are in a format of "ATT00001", "ATT00002", etc.
This is what makes me think I'm missing something with encoding the attachments somewhere, but I just haven't seen the mistake yet.
You can, of course, just use a micro-service with a free Mail API.
That's what I do.
Multiple attachments with FMP 12? No problem.
Send email from other HTTP-enabled applications? No problem.
Very easy to set up and with just a smidgen of coding (free samples online), you're good to go.
Provider is Amazon SES, and their documentation appears to require their SendRawEmail operation to send email with attachments, and that operation looks like it requires one to build out the MIME type, parts, etc., just as what's required using the cURL options for Insert From URL does.
Hello @ByteTheBullet
Thank you for those details.
I can offer something for comparison, which, I believe, hints at what may be going wrong.
Here is an attachment excerpt from some content that I can successfully use as cURL SMTP payload:
--EML__4BD8C9FB-3785-4155-90BD-4E20D5CCE066-63715156851578__EML-MIX
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename= "Attachment A.txt"
ClRoaXMgaXMgYXR0YWNobWVudCBBISEh
--EML__4BD8C9FB-3785-4155-90BD-4E20D5CCE066-63715156851578__EML-MIX
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename= "Attachment B.txt"
ClRoaXMgaXMgYXR0YWNobWVudCBCISEh
--EML__4BD8C9FB-3785-4155-90BD-4E20D5CCE066-63715156851578__EML-MIX--
I believe that the above is very similar to what your code generates.
Here are the differences that I anticipate may exist:
- Not sure if your "filename=" line drops down to a new line
- From what I gather in your notes, after the "filename=" line, you are including path information.
- The code that I am using is not supplying any path-to-attachment information.
- Instead, it is providing the actual attachment file content, as Base64-encoded data.
FWIW:
The reason why the Base-64-encoded data sections are so small in the above excerpt is because I used really small text files as the attachments when I generated the above content.
Upshot:
If you are supplying paths to attachment files in your full email payload composition, I encourage you to try switching to what I am doing above, which is to include the entire file content.
Last comments:
-
I am by no means a SMTP/cURL expert, I am just someone who worked really hard on this back in the days of FMP 15, and I had to work out all the details of how to do this.
-
If it would help to do further comparisons of what SMTP upload-content looks like, feel free to reach out to me. The only place I might not be able to provide an exact example would be a mail message which does not include HTML content. Everything I worked on always focused on HTML content, and I am not sure that my script correctly handles the case where there is plain-text only content.
-
For the record, I feel like I should register my agreement with most everyone else, that using some kind of API for this will be more solid than hand-rolling our own content. Back when I was doing this, I put in a lot of hours to get everything right, and even then, I imagine that I probably got some of the details wrong.
HTH & sincerely,
-steve
5 Likes
Aha! That was the issue. I just needed to change the path/file after "filename=" to just the path, and everything is now working.
Thank you very much for pointing that out.
Now, I am going to take the advice and switch this over to using our mail provider's (Amazon SES) API. With any message that includes an attachment, I'll still have to essentially build all the mime information myself, but I agree that it would probably prove to require less maintenance over time than the current method.
Thanks again!
2 Likes
Note that when interacting with an API like those at AWS, or G-Suite or Microsoft 365, you always have the option to use one of their SDKs in your preferred coding language. All you'd need to do is build your own micro web service, use their SDK in that micro-service code and you'll have the benefit of much of this functionality pre-written. All you'd need to do is add a route to your web service to receive the relevant data to send.
It adds an obvious moving part to the deployment so that factor has to be weighed against the benefit of being able to reduce the development time.
Yep, or use the JavaMail API with the thousands of examples online.
Using the JavaMail API still lets you do nearly limitless customization for a client's needs.
Simple and easy.
Using a micro-service means: NOT FILEMAKER ONLY. (But that may not be important to you "now"...but think ... "later").
Get coding!