On Tue, Sep 29, 2009 at 1:03 PM, Barry R Cisna <brcisna@xxxxxxxxxxxxx> wrote: > Paul, > > Thank you much!for the feedback. I am sure you are right. I will attach > below the error message i was getting thrown back after sending, but first > I'll try and explain better my findings. As I said this server has had no > problems sending this number of emails(last two years) with word doc > attachments. I let the secretary edit the global address to delete/add new > teachers for the year. ( I am guessing there may be 5-10 extra users in > the ' All Staff" entry that she uses over what was used last school year). > After she edited the global address book is when these errors started > occuring a week ago. I was even considering there being white spaces in > the address book and everything else imaginable. As I have always done the > editing myself,with Firefox. I found today if I selected all staff about > 220 users then tried adding her word doc attachment, browse then do the > ADD the quicksave dialog would pop as if the message had just been lost. > This has never done this before. This led me to believe it was quicksave > related? This is key. When you explain how the error happens you really have to detail every mouse click. Clicking to "recover" the message via quicksave is a very important ingredient. The problem is that cookie size is also limited (see Quicksave docs). With that many recipients, you have surely exceeded the cookie size limit. That causes confusion for Quicksave and thus the popup. If you click to retrieve what it had saved for you, you get the truncated list of recipients - truncated to max cookie size. You should be able to see the truncated recipient address right there in your compose form - you don't have to send the message to see the issue. > I tried sending and sure enough at the top as soon as i clicked > send I got a 67 error at the top as if I had a wrong email address > entered. This is the error I received. You will see the users > username/email address is "chopped off".the -k should be -kim This would > happen with different users names appearing this way over the last week > FYI. > > he following addresses had permanent fatal errors ----- > strickler-k@localhost > (reason: 550 5.1.1 <strickler-k@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>... > User unknown) > (expanded from: strickler-k@localhost) > > Bottom line, as soon as I disabled quicksave out of the plugins I could > send the (47k) attachment to all users with no bounce errors. > My current php settings are; 32M memory, 2M file upload,8M HTTP post. > What are your thoughts of increasing the values to memory 64M, and HTTP > post to 16M? HTTP POST size limitations are not related to memory in the web server. It's a protocol limitation that you can't change, although it's possible that some browsers might implement it differently. > I have never had to alter these so I don't know if there are behind the > scense ramifications to increasing these? > Sorry for the long post. Beside removing Quicksave, the other solution is never to click to recover a message from Quicksave when working with so many recipients. Quicksave will work fine for your other messages. Note that you are asking for trouble no matter what you do when you try to put this many recipients into a single message. It is very possible that at some point you WILL hit the HTTP POST limit, too, at which point you will be forced to find a better solution than you use now. End users might whine that they don't want to use a mailing list, but they *do* have to be educated. You can also probably set up a simple alias on your system that redirects to all the staff accounts or to the mailing list, so the end users can still use their webmail to do what they want. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
