I am facing attachment error with Amazon SES service. Normal pdf or jpg files are attached properly. But when i attach a .ics file which is a calender file. I got this error.
554 Transaction failed: Illegal filename 'file_name.ics'
I am using aws-ses gem with rails 3.2.2
Is there any limitation from Amazon? And how can we request them to allow this mime type to our account?
The actual issue was that the email has content type multipart/mixed and the part which holds the ics file has the cotent type text/plain, According to Amazon MIME Types, text/plain must have extensions txt, diff, text. But in my case it was having .ics extension.
So i have to change the code from this.
attachments["file_name.ics"] = #model.to_ical
to this.
attachments["file_name.ics"] = {:mime_type => 'text/calendar',
:content => #model.to_ical}
and it solved my problem.
While Amazon SES does not accept every MIME type indeed, Content Type text/calendarand Extension ics are properly supported as per their respective Appendix: MIME Types.
Without looking at their source, I suspect this to be a limitation of the aws-ses gem eventually (the list of MIME types supported by SES has grown over time) and suggest you give the official AWS SDK for Ruby (AWS Ruby Gem) a shot instead, which should nowadays provide more consistent and properly maintained development/usage experience for all already supported AWS services.
Good luck!
Related
I have deployed an AWS Lambda function, written in Python, and AWS API Gateway structure to cause POST requests to an API endpoint to be redirected to my function. I want to upload a PDF document to my function and have it store the document in a S3 bucket. The problem I have is that the payload of any POST request to my API is being UTF-8 encoded. I don't want that but can't figure out the magic mojo to disable encoding of the request payload.
I am testing using curl, with the following command line:
curl -XPOST https://xxxxxxxxxx.execute-api.us-west-1.amazonaws.com/test -H 'content-type: application/pdf' --data-binary #document.pdf
UPDATE: I just found the following article describing how API Gateway and Lambda support uploading binary data:
https://aws.amazon.com/blogs/compute/handling-binary-data-using-amazon-api-gateway-http-apis/
This article suggests that all of the complexities that I discussed in the initial formation of my question (still provided below) should not be necessary. All I should need to do to upload binary content to my Lambda function is insure that my request includes an appropriate Content-Type header. I was already doing that, but I massaged my Curl command a bit (modified above) to define my request in exactly the way that is done in this article. I still get UTF-8 encoded data and NOT base-64 encoded data. I tried uploading a jpeg file rather than a PDF so I was doing exactly what was done in the article. Still no love. I don't get it. This article demonstrates exactly what I'm doing. But I don't get the result it suggests I should. Ggggrrrr.
ORIGINAL POST:
I am using Terraform to define my deployment. I want to cause the PDF to not be encoded/mangled at all. This is my first time using API Gateway, and I'm obviously missing some bit of config. The one thing I'm doing specifically right now to say that I want incoming payloads to be treated as binary is via the binary_media_types argument to my API definition in Terraform:
resource aws_api_gateway_rest_api proxy {
...
binary_media_types = [
"application/pdf",
"application/octet-stream",
"*/*"
]
This sets the Binary Media Types configuration associated with the API I've defined. I've confirmed via the AWS Console that this setting is having the desired effect...I can see these types in the console. I should need just the first item in the list, but I've added the others while I try to figure out the problem here. By adding that wildcard item, I believe that it shouldn't matter what the incoming Content-Type is...all payloads should be being treated as binary.
The other bit of config that I know about that might be important is the "integration contentHandling property". Here is the key bit of AWS docs that seems to explain all this:
I think the case that applies to me here is the one I've highlighted, per what I say above. This says to me that I shouldn't need to do anything else, per the "unspecified" value in the table for "contentHandling. I've tried setting the "contentHandling" argument on the integration record of my Terraform config, like this:
resource aws_api_gateway_integration proxy {
...
passthrough_behavior = "WHEN_NO_MATCH"
content_handling = "CONVERT_TO_BINARY"
}
I first tried only specifying the content_handling value. I've also tried setting that value to "CONVERT_TO_TEXT", hoping to then get base64-encoded data. Neither of these has any effect. I've tried adding the passthrough_behavior value as shown. I've also tried replacing "WHEN_NO_MATCH" with "WHEN_NO_TEMPLATES". Nothing I do changes the behavior. I haven't been able to figure out where these settings would show up in the AWS console. If I knew they were necessary, I'd explore this further. But I don't think I need to set these.
What am I missing? How can I POST a PDF document to my AWS Lambda function through API Gateway and have the payload of the request not be converted in any way? TIA!
NOTE: I am aware of this Q/A: PDF Uploaded via AWS API Gateway getting corrupted. The answer there doesn't apply to me, as I need to avoid having to form-encode the upload. The client code that will eventually be doing the upload is set in stone and sends a POST request with a payload that is just the bytes of the PDF.
How to get MIME content of Outlook template file? I need to create an email from file and send it using Graph REST API. In Microsoft Docs I found only different examples.
OFT file is in the same format as MSG. Neither format contains any MIME data - it is simply not native to Outlook.
You would need to convert the file to the MIME format - see Convert Outlook.Mailitem to MIME type without saving or sending the mail.
I'm trying to read emails from Outlook (desktop client on macOS) installation programmatically.
For Thunderbird I only need to read the files stored in /Users/xxxx/Library/Thunderbird/Profiles/xxxx.default-release/ImapMail/someemailaccount/.
Each file on that directory is named after the name of each folder on the email account (INBOX, Sent, etc.) and it contains all the emails (header, body and attachments). So all I have to do is to read that file with some programming language and apply the right decoder depending on the Content-Transfer-Encoding header.
For Outlook I found this file: /Users/xxxx/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile/HxStore.hxd but it looks doesn't look to be readable, is it on a binary format? it is compressed or encrypted?
I tried to see its contents using Hex Field app and it displays that the file contains some blocks of data but those blocks look to be broken or encrypted/compressed (more info about that file here https://boncaldoforensics.wordpress.com/2018/12/09/microsoft-hxstore-hxd-email-research/):
<html><head>
<meta http-equiv="Content-Type" cp="text/;ñ; charset=utf-8"></Lð<body><div dir="ltr">1234567890ñ>
...
As you can see above, the contents look to be there but there are some strange characters on it. Also, the file has a lot of sections with no characters or random ones.
Does anybody know how can I read this file?
If you use the older outlook interface (or switch back to it) you can access the underlying sqlite database pretty easily.
However this will be discontinued at some point and Outlook will completely switch to the new interface based on Core Spotlight.
I am also looking for a way to access emails from the new interface, and yes the data seems to be in this file. Anybody else have pointers on how to access?
I use the Windows Azure Blob Storage to keep files there.
To download files i create urls with Shared Access Signature.
It works fine, but there is one problem.
Some files (blobs) have the header "Content-Type" set during upload and other no.
if a file has no Content-Type than on request to Azure the response will have the header Content-Type: application/octet-stream . This is exactly what i need, because in such case a browser will show "Download dialog" for a user.
But for files where this header was set on upload, it is returned and sometimes it makes a problem. For example, Content-Type: images/jpeg makes a browser to show this image, but not download it (does not show Download dialog)
So, my question is
is there a way on download with presigned url from WIndows Azure to force to use some specific response header?
I want it behave like there is no Content-Type saved for a file, even if it is saved
So, after some time browsing i finally found the documentation about it.
There are references.
https://nxt.engineering/en/blog/sas_token/
https://learn.microsoft.com/en-us/rest/api/storageservices/service-sas-examples
https://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas
For me it was needed to up the version of the API (i used the 2012 API version).
Also one useful note. It is very sensetive to a date format. The expiraton time must be in the format like "2021-11-16T04:25:00Z" .
I have added 2 new arguments
'rscd=file;%20attachment&rsct=binary&'.
and both of the must be in the signature string to sign on their correct places
So, my question is is there a way on download with presigned url from
WIndows Azure to force to use some specific response header? I want it
behave like there is no Content-Type saved for a file, even if it is
saved
Yes, you can override Content-Disposition response header in your SAS Token and the blob will be always downloaded regardless of it’s content type.
You can override this header to a value like attachment; filename=yourdesiredfilename and the blob will always be downloaded with yourdesiredfilename name.
I want to send email using mailto tag with a single pdf file as attachment.
mailto tag opens the mail window with passed arguments like to and subject using:
Mail to Manager
But, attachments as a parameter isnt working.
Please suggest how to send pdf attachment in rhomobile.
Thanks
I think that you need to add the physical path to the PDF file for it to work (otherwise it may not know where the file is). This post on a forum says as follows:
The only problem is that this "mailto" command executes on the
client machine, therefore it tries to locate the attachment file by
a physical path, and not by a virtual path.
That is,
Using mailto:iudith.m#zim.co.il?subject=my report&body=see attachment&attachment="\myhost\myfolder\myfile.lis"
works ok, but only for local users (those connected to the same
network as the "myhost" machine).
Using mailto:iudith.m#zim.co.il?subject=my report&body=see attachment&attachment="http://myhost:myport/my_location_virtual_path/myfile.lis"
does not work, it does not recognize such a syntax as valid for
the attachment file.
In your case you would properbly need to look at this part of the Rhomobile docs (on file system access) to get the right path to your file.
EDIT:
From you comment I can see that you are trying to make it work on iOS (due to the iOS specific path).
In this discussion (from Rhomobile's Google Group) it is explained that mailto doesn't support attachments on iOS. It says as follows:
Don't know about other platforms, but you cannot do this on iOS. mailto: does not support attachments on iOS.
You can do it using a native API, MFMailComposeViewController.
This is a complete controller with UI, so you would have to write a Native View Extension to use it:
http://docs.rhomobile.com/rhodes/extensions#native-view-extensions
EDIT 2:
I've looked around and it seems that mailto doesn't support attachments on Android either. This is because Android supports the RFC 2368 mailto protocol, which doesn't include attachments. Here is a reference to the Android mailto url parser.
I would suggest that you do as suggested for iOS, write a native extension. I think this post would be relevant for you.