Hi,
Would appreciate some advice on this issue.
I'm running dovecot version 1.0.10 on ubuntu 8.04 LTS.
Recently a user created a draft email in their client (outlook) and added a 4GB attachment. The email was uploaded to the draft imap folder on the server. After this the client would then go into a endless synchronisation loop every time outlook was opened. For example in the most recent case 400GB of data was downloaded to the client when the user left outlook synchronising for 5 days.
I know this may be a bug with the client or client os however I would like to know if there is a way to limit the size of individual emails that can be stored in the imap store to prevent users creating huge drafts. There is no reason they should need an email draft of this size as it can never be sent through SMTP.
Thanks
On 3/12/2013 9:55 PM, Patrick Joy wrote:
Would appreciate some advice on this issue.
I'm running dovecot version 1.0.10 on ubuntu 8.04 LTS.
Ancient and no longer supported. Upgrade to the latest 1.2.x or 2.x that you can get from your distro ecosystem, or install from source if necessary.
Recently a user created a draft email in their client (outlook) and added a 4GB attachment. The email was uploaded to the draft imap folder on the server. After this the client would then go into a endless synchronisation loop every time outlook was opened. For example in the most recent case 400GB of data was downloaded to the client when the user left outlook synchronising for 5 days.
First, beat the user with a heavy clue stick whilst educating said user about sane attachment sizes, and use of things like FTP, burned DVD, thumb drives, etc, for large file transfers.
I know this may be a bug with the client or client os however I would like to know if there is a way to limit the size of individual emails that can be stored in the imap store to prevent users creating huge drafts. There is no reason they should need an email draft of this size as it can never be sent through SMTP.
You cannot limit the size of individual emails written to IMAP folders AFAIK, but you can limit the size of folders. See:
-- Stan
How can you safely upgrad dovecot? I am running an even earlier version.
Re Message Size, if postfix is your MTA, in main.cfg you can set the parameter: message_size_limit = 5242880 #e.g. for 5 megs limit!
HTH
On 3/12/2013 9:55 PM, Patrick Joy wrote:
Would appreciate some advice on this issue.
I'm running dovecot version 1.0.10 on ubuntu 8.04 LTS.
Ancient and no longer supported. Upgrade to the latest 1.2.x or 2.x that you can get from your distro ecosystem, or install from source if necessary.
Recently a user created a draft email in their client (outlook) and added a 4GB attachment. The email was uploaded to the draft imap folder on the server. After this the client would then go into a endless synchronisation loop every time outlook was opened. For example in the most recent case 400GB of data was downloaded to the client when the user left outlook synchronising for 5 days.
First, beat the user with a heavy clue stick whilst educating said user about sane attachment sizes, and use of things like FTP, burned DVD, thumb drives, etc, for large file transfers.
I know this may be a bug with the client or client os however I would like to know if there is a way to limit the size of individual emails that can be stored in the imap store to prevent users creating huge drafts. There is no reason they should need an email draft of this size as it can never be sent through SMTP.
You cannot limit the size of individual emails written to IMAP folders AFAIK, but you can limit the size of folders. See:
-- Stan
Dr Michael Daly MB, BS GradDip(Integrative Medicine), GradCert(Evidence Based Practice), M Bus(Information Innovation), GradDip(Document Management) 03 9521 0352 0413 879 029
Thanks for the reply.
I have been putting off an upgrade as I need to upgrade the complete OS which is not a trivial task unfortunately but is inevitable.
I may need to setup a nightly cron job to check for files bigger than xmb in the mail store for now.
On 13/03/13 15:07, Stan Hoeppner wrote:
On 3/12/2013 9:55 PM, Patrick Joy wrote:
Would appreciate some advice on this issue.
I'm running dovecot version 1.0.10 on ubuntu 8.04 LTS. Ancient and no longer supported. Upgrade to the latest 1.2.x or 2.x that you can get from your distro ecosystem, or install from source if necessary.
Recently a user created a draft email in their client (outlook) and added a 4GB attachment. The email was uploaded to the draft imap folder on the server. After this the client would then go into a endless synchronisation loop every time outlook was opened. For example in the most recent case 400GB of data was downloaded to the client when the user left outlook synchronising for 5 days. First, beat the user with a heavy clue stick whilst educating said user about sane attachment sizes, and use of things like FTP, burned DVD, thumb drives, etc, for large file transfers.
I know this may be a bug with the client or client os however I would like to know if there is a way to limit the size of individual emails that can be stored in the imap store to prevent users creating huge drafts. There is no reason they should need an email draft of this size as it can never be sent through SMTP. You cannot limit the size of individual emails written to IMAP folders AFAIK, but you can limit the size of folders. See:
On 3/12/2013 11:30 PM, Patrick Joy wrote:
Thanks for the reply.
I have been putting off an upgrade as I need to upgrade the complete OS which is not a trivial task unfortunately but is inevitable.
Debian is designed for rolling upgrades, thus Ubuntu should be as well. They're painless on Debian so I would assume the same for Ubuntu. Which begs the question: why have not been doing rolling upgrades given your platform is specifically designed for such a model?
I may need to setup a nightly cron job to check for files bigger than xmb in the mail store for now.
Probably a good idea. As well as educating the user who attached a 4GB file. That's just plain nuts and smacks of ignorance. Honestly I'm surprised Outlook didn't crash when attaching such a file.
-- Stan
On 13/03/13 15:07, Stan Hoeppner wrote:
On 3/12/2013 9:55 PM, Patrick Joy wrote:
Would appreciate some advice on this issue.
I'm running dovecot version 1.0.10 on ubuntu 8.04 LTS. Ancient and no longer supported. Upgrade to the latest 1.2.x or 2.x that you can get from your distro ecosystem, or install from source if necessary.
Recently a user created a draft email in their client (outlook) and added a 4GB attachment. The email was uploaded to the draft imap folder on the server. After this the client would then go into a endless synchronisation loop every time outlook was opened. For example in the most recent case 400GB of data was downloaded to the client when the user left outlook synchronising for 5 days. First, beat the user with a heavy clue stick whilst educating said user about sane attachment sizes, and use of things like FTP, burned DVD, thumb drives, etc, for large file transfers.
I know this may be a bug with the client or client os however I would like to know if there is a way to limit the size of individual emails that can be stored in the imap store to prevent users creating huge drafts. There is no reason they should need an email draft of this size as it can never be sent through SMTP. You cannot limit the size of individual emails written to IMAP folders AFAIK, but you can limit the size of folders. See:
On 13/03/13 16:28, Stan Hoeppner wrote:
On 3/12/2013 11:30 PM, Patrick Joy wrote:
Thanks for the reply.
I have been putting off an upgrade as I need to upgrade the complete OS which is not a trivial task unfortunately but is inevitable. Debian is designed for rolling upgrades, thus Ubuntu should be as well. They're painless on Debian so I would assume the same for Ubuntu. Which begs the question: why have not been doing rolling upgrades given your platform is specifically designed for such a model? My provider has me over a barrel on this one. My server is a large VPS and the provider is running an old kernel that isn't supported by the latest versions of Ubuntu/Debian. To upgrade I need to move to a different platform which costs more and will involve moving everything. The move needs to happen I'm just procrastinating.
I may need to setup a nightly cron job to check for files bigger than xmb in the mail store for now. Probably a good idea. As well as educating the user who attached a 4GB file. That's just plain nuts and smacks of ignorance. Honestly I'm surprised Outlook didn't crash when attaching such a file. It's always hard to educate them when they are paying customers but I will try.
On 3/13/2013 3:38 AM, Patrick Joy wrote:
On 13/03/13 16:28, Stan Hoeppner wrote:
On 3/12/2013 11:30 PM, Patrick Joy wrote:
Thanks for the reply.
I have been putting off an upgrade as I need to upgrade the complete OS which is not a trivial task unfortunately but is inevitable. Debian is designed for rolling upgrades, thus Ubuntu should be as well. They're painless on Debian so I would assume the same for Ubuntu. Which begs the question: why have not been doing rolling upgrades given your platform is specifically designed for such a model? My provider has me over a barrel on this one. My server is a large VPS and the provider is running an old kernel that isn't supported by the latest versions of Ubuntu/Debian. To upgrade I need to move to a different platform which costs more and will involve moving everything.
The move needs to happen I'm just procrastinating.
This is a classic example of why it's almost always better to own your own box and colocate it, especially if you have paying customers. Yes, it costs more, but having full control of the system is worth the added rent. And for a 1U chassis it's actually pretty cheap to colo at many facilities. The problem is finding one within sane driving distance with low prices.
I may need to setup a nightly cron job to check for files bigger than xmb in the mail store for now. Probably a good idea. As well as educating the user who attached a 4GB file. That's just plain nuts and smacks of ignorance. Honestly I'm surprised Outlook didn't crash when attaching such a file. It's always hard to educate them when they are paying customers but I will try.
Your problem here is lack of a TOS agreement. If you're providing a paid service you should already have one. In that TOS you spell out what is/not allowed or supported by your service, such as 4GB attachments.
-- Stan
Thanks great advice, while I don't have the resources to go colo at the moment a dedicated server would work much better, and I will start writing a TOS!
On 13/03/13 20:06, Stan Hoeppner wrote:
On 3/13/2013 3:38 AM, Patrick Joy wrote:
On 13/03/13 16:28, Stan Hoeppner wrote:
On 3/12/2013 11:30 PM, Patrick Joy wrote:
Thanks for the reply.
I have been putting off an upgrade as I need to upgrade the complete OS which is not a trivial task unfortunately but is inevitable. Debian is designed for rolling upgrades, thus Ubuntu should be as well. They're painless on Debian so I would assume the same for Ubuntu. Which begs the question: why have not been doing rolling upgrades given your platform is specifically designed for such a model? My provider has me over a barrel on this one. My server is a large VPS and the provider is running an old kernel that isn't supported by the latest versions of Ubuntu/Debian. To upgrade I need to move to a different platform which costs more and will involve moving everything. The move needs to happen I'm just procrastinating. This is a classic example of why it's almost always better to own your own box and colocate it, especially if you have paying customers. Yes, it costs more, but having full control of the system is worth the added rent. And for a 1U chassis it's actually pretty cheap to colo at many facilities. The problem is finding one within sane driving distance with low prices.
I may need to setup a nightly cron job to check for files bigger than xmb in the mail store for now. Probably a good idea. As well as educating the user who attached a 4GB file. That's just plain nuts and smacks of ignorance. Honestly I'm surprised Outlook didn't crash when attaching such a file. It's always hard to educate them when they are paying customers but I will try. Your problem here is lack of a TOS agreement. If you're providing a paid service you should already have one. In that TOS you spell out what is/not allowed or supported by your service, such as 4GB attachments.
participants (3)
-
Dr Michael Daly
-
Patrick Joy
-
Stan Hoeppner