My point is - it should have never MADE it as far as Declude if your Imail is configured according? Your users wouldn't be able to attempt email delivery in the first place, because their own SMTP process would be unable to hand it off at all.
It seems as if some process time out trying handle your 20 GB file. And you are quite SURE about it being 20 GIGAbyte, right? Attachments in Emails are an afterthought and are meant for incidental small add-ons. Email is NOT a file transfer tool. Here is how I explain it to my users who wonder why my system rejects their super-sized attachments: - A file transfer will copy all those bytes of data precisely ONCE from the sender to the storage host (such as an FTP host or a could service), and ONCE from there to the recipient's workstation. Both parties know the size of the file and can "schedule" their time and resources to potentially wait for a few hours (depending on their connection speed) for this file transfer to succeed. - Email is delivered by storing and forwarding it from hop to hop. It's not unusual for an email to go through 7 or more intermediate systems, each time copies are being stored, scanned and re-transmitted. From the users' workstation to their in-house mail server, from the in-house mail server to their outbound mail gateway, from their in-house mail gateway to their ISP's incoming mail server, from their ISP's incoming mail server to and outgoing delivery queue. From their ISPs outgoing mail server to the recipients incoming mail gateway/firewall, for the recipient's incoming mail gateway to their in-house mail server, from their in-house mail server to the recipients mail box - which will likely be UNABLE to hold a message of that size - in which case the whole processes repeats in reverse... Worse - the recipient may be off-site and wondering why their Outlook is stuck trying to download the same 20 GB message and keeps timing out every 5 minutes (after the first 100 MB or so). Now you have an upset recipient with a broken Outlook who can't get to ANY of their emails! So this 20 GB message becomes a 140 GB bandwidth hog - and potentially a denial of service attack to the person they are trying to send it to. The CORRECT way to do this is use a proper file transfer service - many of them are free. Such as: http://MediaCenter.email Upload your files, type your email message and the recipient is sent your email with a download LINK. The email is small and will be delivered without wreaking havoc on EVERYONE's infrastructure. -----Original Message----- From: Andy Schmidt [mailto:[email protected]] Sent: Thursday, January 08, 2015 9:19 PM To: '[email protected]' Subject: RE: [MBF] Re: Large email files are not getting completely processed Don - don't you have a maximum message size configured? Imail you should advertise that size in the EHLO string so that the sending system can reject the message to its own user and not even attempt delivery to Imail. Also, a well behaved sending system should supply the msg size in the MAIL FROM command, permitting Imail to reject the message outright, which allows the sending system to alert its own user. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Don Winsauer Sent: Thursday, January 08, 2015 5:41 PM To: [email protected] Subject: [MBF] Large email files are not getting completely processed We are experiencing an issue on our Imail server that maybe someone can shed some light on. We have had a few customers on different domains send very large emails (over 20gb). These are typically either drawing file or proof files. The email makes it to our server and gets checked by Declude. Our customer's are getting an "Undeliverable Mail" bounce back email saying that there is "No message body". There are no errors in the log files (Sys, Dec, Vir and Blkl). The Dec file shows that the user is whitelisted due to authentication. The Blkl has a type of IGNORE for these emails. The large smd file is being left in the proc\work folder with the extension D*.smd.tmp. For some reason, it's not being transferred back into the spool folder for delivery. This explains the "Undeliverable" and "No message body" bounce email. There is several GB free space on the spool drive. Has anyone seen this or have a solution I can try? Thanks in advance, Don Net1 Media ________________________________________________________________ Sent via the WebMail system at net1media.com ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]>
