Email Delivery Failure
June 13, 2009 3:00 PM Subscribe
I'm trying to send a .PDF file to multiple recipients. The file is 12,275k, but I'm getting a delivery failure saying the file size is too big. I'm using gmail and I know that the file size is not too big. What gives? How do I send it?
I know the file is not too big. I get the following error: "Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 message size exceeds maximum size (state 18)."
When I google this all I find is advice saying the file is too big, but it's not, as evidenced by other emails I've sent with larger attachments. I really need to send this email (actually. it's for my girlfriend, but whatever), how do I overcome this. I'm using gmail and it's going to about 17 recipients who among them are using many different email services. All deliveries fail. I need to send this out, what do I do?
I know the file is not too big. I get the following error: "Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 message size exceeds maximum size (state 18)."
When I google this all I find is advice saying the file is too big, but it's not, as evidenced by other emails I've sent with larger attachments. I really need to send this email (actually. it's for my girlfriend, but whatever), how do I overcome this. I'm using gmail and it's going to about 17 recipients who among them are using many different email services. All deliveries fail. I need to send this out, what do I do?
It's not too big for Gmail, but most other email servers limit attachments to 10MB or even less. The error message you've received is pretty definite; at least one of your recipients cannot accept a message that large.
posted by dreadpiratesully at 3:03 PM on June 13, 2009
posted by dreadpiratesully at 3:03 PM on June 13, 2009
Try a service like Rapidshare (I've never used them, but they do what you need) instead.
posted by dreadpiratesully at 3:05 PM on June 13, 2009
posted by dreadpiratesully at 3:05 PM on June 13, 2009
Best answer: Re-generate the PDF using the "smallest file possible" option. Or, zip the file.
posted by elle.jeezy at 3:06 PM on June 13, 2009
posted by elle.jeezy at 3:06 PM on June 13, 2009
Best answer: Split the file in half, and send two seperate emails.
Many recipients have a 10mb receive limit, and due to the way email compresses files, that really only means 7mb.
The other option would be to post it to your website -- or a file sharing website such as yousendit.com, sendthisfile.com, transferbigfiles.com.
posted by SirStan at 3:11 PM on June 13, 2009
Many recipients have a 10mb receive limit, and due to the way email compresses files, that really only means 7mb.
The other option would be to post it to your website -- or a file sharing website such as yousendit.com, sendthisfile.com, transferbigfiles.com.
posted by SirStan at 3:11 PM on June 13, 2009
dreadpiratesully has it.
In the circles I run in, sending attachments that large is very bad form. Put the file somewhere on the web and send a link.
posted by doowod at 3:11 PM on June 13, 2009
In the circles I run in, sending attachments that large is very bad form. Put the file somewhere on the web and send a link.
posted by doowod at 3:11 PM on June 13, 2009
Best answer: Agree with the recommendation to use a web site and allow recipients to download it as needed, instead of sending to multiple recipients.
Other services:
yousendit.com
drop.io
posted by yclipse at 3:28 PM on June 13, 2009 [2 favorites]
Other services:
yousendit.com
drop.io
posted by yclipse at 3:28 PM on June 13, 2009 [2 favorites]
Quick point of email etiquette: it is probably not a cool move to send enormous attachments. When the mailer daemon tells you that you can't do something, there's usually a good reason for it. Be a lamb and put the PDF up on a website, or use some other, better way to send the mail than clogging up someone's mailbox. Anything over a meg is probably better to not send through email.
Love,
Former E-mail server administrator, who limited attachment size to 5 megs.
posted by Geckwoistmeinauto at 3:33 PM on June 13, 2009
Love,
Former E-mail server administrator, who limited attachment size to 5 megs.
posted by Geckwoistmeinauto at 3:33 PM on June 13, 2009
It's also one thing to be receiving large files as attachments at home - but sometimes when checking in on the phone or handheld device, they're too big.
posted by peagood at 3:39 PM on June 13, 2009
posted by peagood at 3:39 PM on June 13, 2009
Seconding yousendit.com. They have a very nice little program you can install (PC) which allows you to easily send files up to 100Mb in size to multiple recipients. Free.
posted by cyniczny at 3:45 PM on June 13, 2009
posted by cyniczny at 3:45 PM on June 13, 2009
To clarify, sending an attachment that large to multiple recipients...
(1) Uses a lot of bandwidth, which for some people is a metered and/or precious commodity.
Say you send that email to 10 people @somecompany.com. somecompany.com has a 1.5MBit/s net connection and runs their email servers at their office. You have likely just ground the office net connection to a halt for 10+ minutes while they download 120MB of identical PDFs (that they didn't necessarily ask for).
(2) Uses a lot of server storage space. Email servers are rarely upgraded because it is such a critical function. They usually have a very finite amount of space that is considerably less than your average 1TB hard drive. Large attachments eat away at this space very quickly.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it. If they're using a system that stores email on the server (IMAP), that space is gone forever unless someone decides to delete your mail (most people don't delete email, though).
The reasons given above are why some recipients mail servers are refusing to download and deliver your message.
From personal experience...
At a previous employer (large company), the sysadmins frequently had to sit people down and tell them why it was bad to send large attachments, especially to multiple recipients. The people who sent the emails took on "that guy" status, as in "that guy who attached a 20MB PDF newsletter and sent it to an office of 300 people". Don't be "that guy", on any scale.
On preview, Geckwoistmeinauto has good advice. Anything over 1MB should be linked. I'll also add that you should be extra careful when dealing with large numbers of recipients, as that 1MB will multiply quickly.
posted by doowod at 3:50 PM on June 13, 2009 [4 favorites]
(1) Uses a lot of bandwidth, which for some people is a metered and/or precious commodity.
Say you send that email to 10 people @somecompany.com. somecompany.com has a 1.5MBit/s net connection and runs their email servers at their office. You have likely just ground the office net connection to a halt for 10+ minutes while they download 120MB of identical PDFs (that they didn't necessarily ask for).
(2) Uses a lot of server storage space. Email servers are rarely upgraded because it is such a critical function. They usually have a very finite amount of space that is considerably less than your average 1TB hard drive. Large attachments eat away at this space very quickly.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it. If they're using a system that stores email on the server (IMAP), that space is gone forever unless someone decides to delete your mail (most people don't delete email, though).
The reasons given above are why some recipients mail servers are refusing to download and deliver your message.
From personal experience...
At a previous employer (large company), the sysadmins frequently had to sit people down and tell them why it was bad to send large attachments, especially to multiple recipients. The people who sent the emails took on "that guy" status, as in "that guy who attached a 20MB PDF newsletter and sent it to an office of 300 people". Don't be "that guy", on any scale.
On preview, Geckwoistmeinauto has good advice. Anything over 1MB should be linked. I'll also add that you should be extra careful when dealing with large numbers of recipients, as that 1MB will multiply quickly.
posted by doowod at 3:50 PM on June 13, 2009 [4 favorites]
I always use http://www.yousendit.com when doing this. I have a couple of clients with AOL accounts. Many of these people can barely deal with normal, no attachment email, and all have been able to retreive my files.
posted by imjustsaying at 4:36 PM on June 13, 2009
posted by imjustsaying at 4:36 PM on June 13, 2009
Say you send that email to 10 people @somecompany.com. somecompany.com has a 1.5MBit/s net connection and runs their email servers at their office. You have likely just ground the office net connection to a halt for 10+ minutes while they download 120MB of identical PDFs (that they didn't necessarily ask for).
Wha? Not so. The sending MTA will combine these emails into a single transmission that is sent to @somecompany.com as long as the sender cc's them all together.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it
Most corporate mail systems will combine these emails into a single email (ie, Exchange), so again, not a real concern.
Its 2009 -- If your mail server is running on a 36gb SCSI hd .. its time to reconsider your system. 10mb emails shouldn't be any concern to a properly managed system.
posted by SirStan at 4:53 PM on June 13, 2009 [1 favorite]
Wha? Not so. The sending MTA will combine these emails into a single transmission that is sent to @somecompany.com as long as the sender cc's them all together.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it
Most corporate mail systems will combine these emails into a single email (ie, Exchange), so again, not a real concern.
Its 2009 -- If your mail server is running on a 36gb SCSI hd .. its time to reconsider your system. 10mb emails shouldn't be any concern to a properly managed system.
posted by SirStan at 4:53 PM on June 13, 2009 [1 favorite]
nth'ing bad practice for attachments that size. Even when I'm expecting them, it's very annoying to have to WAIT as my client downloads megs of mail. I'd much rather a lean, trim email that gives me a link to where I can get it. I run my own personal email server, and have it set to reject anything larger than 2MB... Anything larger is just annoying to wait for.
posted by frwagon at 5:32 PM on June 13, 2009
posted by frwagon at 5:32 PM on June 13, 2009
It's 2009, and your mail server is supporting hundreds of people on a shoestring budget because your last grant didn't quite come in yet, and your previous admin quit to move to the financial sector, and .. well .. Sorry Stan, but just because you might be able to support an irresponsible influx of data doesn't mean that the guy on the other end of the link can.
That said, depending on how the mail is transmitted, the MTA may handle it differently, and Not Everyone Runs Exchange. In fact, I can't think of any major open, RFC complaint MTAs (Postfix, Qmail, Sendmail) that would have the sort of behavior you describe.
To the OP: if you want to guarantee your recipients get your messages, keep your messages small. How small? I guess you have to figure that out for yourself, but as I said earlier, under a meg is best.
posted by Geckwoistmeinauto at 5:34 PM on June 13, 2009
That said, depending on how the mail is transmitted, the MTA may handle it differently, and Not Everyone Runs Exchange. In fact, I can't think of any major open, RFC complaint MTAs (Postfix, Qmail, Sendmail) that would have the sort of behavior you describe.
To the OP: if you want to guarantee your recipients get your messages, keep your messages small. How small? I guess you have to figure that out for yourself, but as I said earlier, under a meg is best.
posted by Geckwoistmeinauto at 5:34 PM on June 13, 2009
Say you send that email to 10 people @somecompany.com. somecompany.com has a 1.5MBit/s net connection and runs their email servers at their office. You have likely just ground the office net connection to a halt for 10+ minutes while they download 120MB of identical PDFs (that they didn't necessarily ask for).
Wha? Not so. The sending MTA will combine these emails into a single transmission that is sent to @somecompany.com as long as the sender cc's them all together.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it
Most corporate mail systems will combine these emails into a single email (ie, Exchange), so again, not a real concern.
I'm not an admin, I'm a programmer. This was the explanation our admins gave to the (many) people who would cc the office with a large attachment. My guess is that these behaviors are MTA/configuration dependent, but I'm not an email admin (I just drank beers with them).
Its 2009 -- If your mail server is running on a 36gb SCSI hd .. its time to reconsider your system. 10mb emails shouldn't be any concern to a properly managed system.
(1) Again, from what I've seen mail servers (along with DNS) were very rarely upgraded. So yes, you will frequently have ridiculously outdated hardware. FWIW, we had mail and DNS servers with 5 year+ uptimes when I left the company. We had business critical databases running on VAX/VMS machines from the 80s/90s. We had revenues of ~$800 million/year with expenses of ~$40 million/year. Any changes to this well oiled machine had to be approved by a very skeptical committee with a strong bias towards leaving things the way they were. Successful businesses know that critical infrastructure is not the place for ZOMG NEW SHINY SERVER, despite the pleadings of whatever wrongheaded salesman or consultant happened to be in the office that week.
(2) Assuming that a majority (or even a significant minority) of mail systems are properly managed is a giant leap. I don't buy it.
posted by doowod at 6:06 PM on June 13, 2009
Wha? Not so. The sending MTA will combine these emails into a single transmission that is sent to @somecompany.com as long as the sender cc's them all together.
Continuing the earlier example, somecompany.com's email server now has 120MB of identical PDFs on it
Most corporate mail systems will combine these emails into a single email (ie, Exchange), so again, not a real concern.
I'm not an admin, I'm a programmer. This was the explanation our admins gave to the (many) people who would cc the office with a large attachment. My guess is that these behaviors are MTA/configuration dependent, but I'm not an email admin (I just drank beers with them).
Its 2009 -- If your mail server is running on a 36gb SCSI hd .. its time to reconsider your system. 10mb emails shouldn't be any concern to a properly managed system.
(1) Again, from what I've seen mail servers (along with DNS) were very rarely upgraded. So yes, you will frequently have ridiculously outdated hardware. FWIW, we had mail and DNS servers with 5 year+ uptimes when I left the company. We had business critical databases running on VAX/VMS machines from the 80s/90s. We had revenues of ~$800 million/year with expenses of ~$40 million/year. Any changes to this well oiled machine had to be approved by a very skeptical committee with a strong bias towards leaving things the way they were. Successful businesses know that critical infrastructure is not the place for ZOMG NEW SHINY SERVER, despite the pleadings of whatever wrongheaded salesman or consultant happened to be in the office that week.
(2) Assuming that a majority (or even a significant minority) of mail systems are properly managed is a giant leap. I don't buy it.
posted by doowod at 6:06 PM on June 13, 2009
ender6574: I know the file is not too big. I get the following error: "Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 message size exceeds maximum size (state 18)."
Well, what this error message means is that Google tried to deliver your message, but it was rejected by the recipient domain, who said that the message size exceeds their maximum size. You should probably contact the other email provider and ask them what their maximum message size is.
posted by koeselitz at 2:41 AM on June 14, 2009
Well, what this error message means is that Google tried to deliver your message, but it was rejected by the recipient domain, who said that the message size exceeds their maximum size. You should probably contact the other email provider and ask them what their maximum message size is.
posted by koeselitz at 2:41 AM on June 14, 2009
Best answer: Nthing YouSendIt.com or MailBigFile.com. The issue is on the recipient's side, not your side.
If you're sending a file to one recipient, and you know that recipient is online right now, my preference is to use JetBytes.com, which is considerably faster than the other two sites.
posted by lexfri at 6:25 AM on June 14, 2009
If you're sending a file to one recipient, and you know that recipient is online right now, my preference is to use JetBytes.com, which is considerably faster than the other two sites.
posted by lexfri at 6:25 AM on June 14, 2009
Most corporate mail systems will combine these emails into a single email (ie, Exchange), so again, not a real concern.
If all of the recipients are on a LISTSERV list, Exchange will do no such thing.
posted by oaf at 9:57 AM on June 14, 2009
If all of the recipients are on a LISTSERV list, Exchange will do no such thing.
posted by oaf at 9:57 AM on June 14, 2009
« Older Help me find this song and the compilation album... | How much do I need to make in Seattle? Newer »
This thread is closed to new comments.
posted by nitsuj at 3:01 PM on June 13, 2009