Microsoft-graph-docs: Is there a way/a plan to support sending emails with attachments > 4MB

[zhiangli]

Issue: We are facing sending emails with attachments > 4mb using v1.0 API

Article: I found some discussions on stackoverflow and it seems like something hasn't been supported yet. Is there a plan to support this functionality? We have quite a few use cases of sending attachments > 4mb but we won't send super big attachment. Guess it should be less than 20MB/30MB.

[mhartvig]

No, not at the moment. There was a comment https://github.com/microsoftgraph/microsoft-graph-docs/issues/85#issuecomment-429196671 that it's being worked on.

[svpsiva]

Thanks for calling this out.
We are actively working on this. Unfortunately, we do not have an exact date of release yet.

-Sivaprakash
Senior PM, Microsoft

[FernandoMerino]

Any update on this?

Thank you!

[Herz3h]

We just had one of our client report us the bug and what a surprise to see that mails can't have attachments over 4MB. I'm surprised such a basic functionality like this doesn't work... Any ETA ?

EDIT: Also It was recommended to use Outlook Rest API as a workaround, problem being we currently use Graph endpoint and apparently token delivered by Graph isn't valid for Outlook endpoint. Is there a way to use same token for both endpoints ?

That way we avoid having to authenticate users twice (once for Graph API and once for Outlook Rest API).

[DrewBuchanan]

Any updates on this yet? I'd rather not implement the Outlook API when we already have a Graph solution functioning outside of this one issue.

[hengwoon]

Is the 4MB limit per-attachment, or is that the limit on the entire API request?

[Zombaya]

@hengwoon, the limit is per API-request, you can attach multiple attachments where the total size is larger than 4MB using POST /me/messages/{id}/attachments, where id is the ID received when creating the draft.

Also, the actual attachment-size-limit is more in the region of 3.1MB since you have to base64-encode it's contents and then respect the 4MB request-size-limit.

Having a higher limit is more than welcome though.

[lievenjanssen]

Could you guys please get your act together and fix this issue which prevents us from implementing a proper mail interface. It's clearly a high priority issue which is actually open since Dec 15, 2015! 😭

[xuxiankun]

Do we have release plan? please share the information with community. thanks.

[omascia]

I just completed our application code migration from EWS to Graph to find that incredible limitation on attachments size. I'm not asking to send multi-GB files, but ~3 MB is a terrible issue and questions the skills of the designers of Microsoft Graph API. Are you working for your customers or against them? :(
Does the 'beta' API have some work-around for that? I can't find any information about it in the beta reference documentation, but I could have overlooked it.

[omascia]

Thanks for calling this out.
We are actively working on this. Unfortunately, we do not have an exact date of release yet.

-Sivaprakash
Senior PM, Microsoft

Not even yet 3 months later? :(

[omascia]

Creating an Upload Session, associated with the Messages instead of OneDrive, might be a path.
Another idea, though less effective due to base64 encoding: have an API mean to append contentBytes to an existing attachment. The outgoing email could be created as a draft with an attachment containing a partial content (so the request < 4 MB), then multiple append could be done to push up the remaining slices. Though I'd prefer the Upload Session feature available out of Files context.
Honestly any idea to overcome neatly this awful shortcoming is welcome... now. Not in X months or next year.

[omascia]

Proposal, if only to check that this is the path you're pursuing in you "active" work on this attachments size limitation.

The idea would be to add /createUploadSession capability as per https://docs.microsoft.com/en-us/graph/api/driveitem-createuploadsession?view=graph-rest-1.0, on the add attachments described ar per https://docs.microsoft.com/en-us/graph/api/message-post-attachments?view=graph-rest-1.0

Those 6 /attachments URI:
POST /me/messages/{id}/attachments
POST /users/{id | userPrincipalName}/messages/{id}/attachments
POST /me/mailFolders/{id}/messages/{id}/attachments
POST /users/{id | userPrincipalName}/mailFolders/{id}/messages/{id}/attachments
POST /me/mailFolders/{id}/childFolders/{id}/.../messages/{id}/attachments/{id}
POST /users/{id | userPrincipalName}/mailFolders/{id}/childFolders/{id}/messages/{id}/attachments/{id}

could be suffixed with:
/createUploadSession

and would allow creating a UploadSession to transmit the attachment content just as it can be done for uploading files to drives.

[omascia]

Well, well, well... Our needs as small companies, our economical realities, cannot wait for mammoths to sit and argue with themselves for months before slowly moving to action. :). So I did a rather quick experiment late last night and its outcome is positive: my software can attach some bigger files to outgoing messages, there still is a size limit (and that's a good thing anyway), but it is reasonably higher than about ~3.1 MB per attachement.

What did I do?
We had rewritten all our code which was previously using EWS (through a .Net client now abandoned) to MS Graph (as native C++ coding) before knowing about that size limitation. We turned last night to:
https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/mail-rest-operations#SendMessageOnTheFly which is the old REST API for interacting with Office online mailboxes.

It took about 20 minutes to make the switch. Do you know what changes there are between the old Outlook REST API v2.0 (now abandoned) and its equivalent within the new (promoted) Microsoft Graph API? Besides the URL prefixes (old https://outlook.office.com/api/v2.0/ or newer https://graph.microsoft.com/v1.0)? All the Json fields within objects start with an uppercase letter in Outlook API and a lowercase letter in Graph API. So it's Message and not message, ToRecipients and not toRecepients, and so on... Still not sure if I want to cry or laugh.
For these next 2 to 4 months we won't need access to other products, exposed through Microsoft Graph, so we will stick with Outlook REST API for now, knowing the transition back to Graph will be easy rather easy, when it will have been fixed.

[maitra]

Any news on this? December 2018 is long gone. Question to MS: why push something that is not ready as the preferred option?

[ssungare]

Any update? We have been waiting for so long. Can you guys provide any time frame?

[jthake-msft]

I appreciate the passion here on GitHub, but this repos issues list is purely for feedback on the Microsoft Graph document contents, not the service itself.

We have a https://microsoftgraph.uservoice.com/ where we manage feature requests such as this. You can see here that @svpsiva has already marked the feature request as started and this is in active development in our engineering team right now. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests/suggestions/37353598-send-message-with-a-larger-than-3-mb-file-attachm

I am going to close this thread and encourage you to pop over there and vote so you are notified when this status changes.

[maitra]

Typical of Microsoft's fifth-rate service to an issue that should have been addressed even before it got to this stage. After all, 3MB has not been a reasonable limit at least for the past 20 years!

The "active development" seems to have gone nowhere with no timeline ever proposed except for being bounced around from one thread to the other, and pretending that everytime, work has "started".

Why are you even in the e-mail business if you can not provide for attachments more than 3MB? Regardless it is hard to see how a change like this is something that should have already taken years, not minutes!

[zhiangli]

@maitra lol. Totally agree. We are shocked when we found this limit...

[jthake-msft]

@maitra @zhiangli and do understand how you perceive this priority. But we also have OneDrive file system where we would much prefer files to be stored and a hyperlink in the email to it. This gives much better story for co-authoring of file attachments, preview experience, storage optimization, versioning story and a security model that you do not get from a email attachment.
As I've stated, we've started the engineering work and it is actually in code review as I'm writing this. A service as globally large as this has a lot of rigor around it as you can hopefully understand.

[maitra]

It is difficult to understand that MS does anything with rigor, as evidenced by your pushing out a preference (Graph API) which can not handle more than 3MB in attachments. You can prefer files to be stored where you want but that is not an option available to a sender in a professional setting. We can not expect that e-mail recipients will want to access files on OneDrive. And of course, many senders to us would not even send in files in e-mails if they expect it to end up on OneDrive.
It is good to note that you have "started the engineering work" but have you considered that this has been started as per @svpsiva for almost two years. Seriously, how much effort can it take to change the code to allow 20 MB (say) instead of 3 MB files? If the code was not sloppy originally, then it can not take more than minutes.

Hopefully, you will stop idling around and deliver on increasing this ridiculous limit. Otherwise, consider reassigning some of your personnel.