Setting size for Mail Drop feature

Right! Mail Drop won't work most of the time because of the RECIPIENT's size limit, NOT the sending Mac.

The solution is to set the Size for the Mail Drop feature. That might be anything over 4 Megs causes Mail Drop to be invoked.

If you attach a large file and its over your servers quota, you get a message alerting you.

Send anyway, it will change it to mail drop.

You can set accounts to automatically do it in Mail Preferences > Accounts - Advanced

Hi Tangible,

I understand exactly you points and they have merit.

My comment that you called wrong, was in relationship on how it appears that Mail Drop is currently implemented by Apple when you send an email, not necessarily how you would like it to work in the scenarios you propose.

What I was saying was; If your server does not have any file size limit associated with it, when you are composing a message and Mail compares your attachment size to your server limit (I have no idea how it determines this), then Mail will never use the Mail Drop setting because it doesn't think it needs to. Mail does not check the recipients server to see what, if any, limits exist there. I don't know of any mail client that does that action.

In your situation with no server limits, you would not have seen any different behaviour pre-Yosemite, Mail would have just allowed you to send any attachment as big as you wanted. If your server had a limit set, such as the one I use, I previously just got a failure message that the attachment was too big to send.

IMO, if you are in the business of sending lots of large attachments, I would try to use some other method of sharing the files, such as a DropBox account or similar, that way your recipients can just download when they want.

By all means, request that Apple implement a minimum user selectable file size limit to Mail Drop here https://www.apple.com/feedback/macosx.html and include a detailed description and how you want it to work. If enough users request it, Apple may even implement it.

If that's really the way the system is designed, it's useless except for the limited case in which the user and everyone he corresponds with uses iCloud.

Not quite. To test, I send myself a large attachment to say my work address that is not on Mac or on iCloud. At that end, I get an email with a link to download from iCloud. I don't need to log in to iCloud or even have an iCloud address/account to download the file. In the email, it states that the attachment is automatically deleted after 30 days (whether or not it has ever been downloaded).

Another though would be; Can you ask your service provider to implement a file size limit of your choosing to your account. That way, every time you attach something over that limit, Mail Drop would be invoked.

I submitted feedback and I hope others follow.

Request that Apple implement a minimum user selectable file size limit to Mail Drop here https://www.apple.com/feedback/macosx.html and include a detailed description and how you want it to work.

If enough users request it, Apple may even implement it.

The iCloud limit for attachments is 20MB ( iCloud: Mailbox size and message sending limits - Apple Support ) so I assume that Mail Drop will only be invoked when attachments are this large. This is likely to be much more than some recipient servers and so the feature is very constrained. Send feedback to Apple but don't hold your breath.

defaults write com.apple.mail minSizeKB 10000

1. Hit return and then re-launch Mail app
2. Send any file over 10MB and Mail app will prompt you to use MailDrop (iCloud must be enabled on the Mac)

Same issue here! I would like to set the size for where mail drop kicks in. I sent a 6 meg file to a client and HIS company rejected it as too large, but my 6 meg file is too small for Mail Drop to kick in.

No, that's not it!

It's not MY server that saying it's too big. The file gets sent to the recipient just fine, and then it's HIS server that rejects it (saying file size is over the allowed size). And then it's just dead. If we could specify the file size where Mail Drop kicks in that would solve it (say, 4 meg for example)

Exactly what Tangible said. I'm getting files kicked back all morning now from the RECIPIENT'S servers. Mail Drop needs to kick in the link service at a much smaller file size.

"The error that the other server returned was:

550 permanent failure for one or more recipients :552 5.3.4 Message size exceeds fixed maximum message size)

I get what your saying, but It doesn't look like Apple have designed it that way.

I see no setting anywhere that allows you to set the size unfortunately and if your server has no file size limit, it will never need to use Mail Drop any way.

In your example, if your inbound work server happened to have a smaller limit than your outbound home server, you would have sent the file as a normal attachment, and it would have been rejected. This would be beyond your control. Even if you knew a priori this would be the case, you would be helpless to get the Mail Drop feature to take effect in that situation.

I agree that Mail Drop has no effect in this situation, but that was also the case before Mail Drop existed. I thought I had said that previously. 😕

Yes, one could certainly use Dropbox instead, as you suggest, but I think Apple would be disappointed to learn that this easily-fixed limitation was driving people into the arms of a competitor. After all, the whole iCloud Drive system is clearly designed to allow Mac and iOS users to remain "in the family" rather than defecting to Dropbox, OneDrive, Google Drive, etc.

I don't think I necessarily agree with your statement here, Apple have offered an additional feature of its mail client and it may not be as simple to fix as it sounds. I doubt Apple are willing to or want to temporarily store, potentially ever single attachment, every single OS X 10.10 and beyond users decides to send from their computer, whether or not they are using an iCloud account.

I don't think that Apple it's attempting to stop users from using any other service if they wish to, and many, many already do just that.

By the way, Dropbox itself is now in the Mac email client business. Their subsidiary, Mailbox, has been very popular on iOS, and they're now in Beta on the Mac. They handle the attachment situation very elegantly, in my opinion. If an attachment lives within the Dropbox folder hierarchy on the sending computer, it automatically gets sent as a link. If it's elsewhere, it goes as a normal attachment. So the user can control the behavior by moving the file into or out of his local Dropbox folder before sending. Additionally, the link is hot, i.e. if the sender changes the file after sending the recipient sees the newest version each time he uses the link. This may be good or bad, depending on the situation.

Dropbox's implementation is definitely one way to attack the problem and good on them for doing so. Although, without using the app/service, it sounds to me that there is a slight difference going on too. It sounds like they are allowing a recipient limited access to your secure structure and files are where as Mail Drop is not. My understanding of it is, in Mail Drop while the files are stored in iCloud, it is not in your personal iCloud storage area. I don't know if I personally would be comfortable on relying on Dropbox, or any other service including Apple's, to allow others limited access to my data. But that could simply be my own paranoia kicking in there. 😁

It also sounds like Dropbox is not attempting in anyway to seek out what the recipients attachment limits are, just like Apple isn't and I think that is the centre of the issue. It's easy for any mail client to know what limits you have you on your server as you already have a secure connection enabled. It's a completely different story for any mail client to know what the recipients server limits are and I would suggest that if any mail client attempted to ask, the security at the recipient's end would promptly reject any such inquiry.

With regard to your other suggestion, my ISP, ICDSoft, is proud of their no-limits approach, and has no interest in implementing quotas.

Good on them, but that is also part of the problem. They also don't care if a recipient can actually receive the mail you send them.

I don't even know if this would really work for general imap implementations, i.e. whether there is a protocol for an imap sender to ask a recipient what it can handle. My guess is no, as this would require the receiving server to always be online and available synchronously to the sending server, which is a clear violation of the basic store-and-forward structure of email.

Agreed, this is in addition to my previous above.

Anyway, I will certainly take your advice to send this as a suggestion to Apple, though it grates on my nerves to do so since, in my heart, I know it's a bug not a feature!

And I think this is where we don't agree, I don't see it as a bug. I would see it as a bug, if there was a setting for a file size and it wasn't working, but as there is not actually a setting for it, it's not broken. That's why I see it as an addition feature request.

At the end of the day, Mail is simply an app for sending and receiving emails. It is one of many and each tend to excel in different features over the other. That's the good thing about choice. Apple doesn't force you or me to use Mail and as users we have the choice to use any app that it fit for our purposes, which will differ from user to user, just like any other app out there.

Thanks for the great discussion,

A

Great. Another feature that's flashy, but the implementation of which falls woefully short of expectations, and indicates that Apple increasingly doesn't get it. I use @icloud.com for my outgoing mail, and that attachment size limit is very high. So, my problem, like the original post's problem, is with RECIPIENTS' low limits on attachment sizes. Think about it: I'm still having severe problems with emails getting bounced back because the attachments are too large, and Mail Drop is useless in solving the problem.

Even worse, as Mail Drop enables the use of outgoing mail hosts with low attachment size limits, Apple is shooting itself in the foot by giving an advantage to other email providers over iCloud.com.