Okay - I've done a couple of things to work this out, and my changes now are a little better. I've limited the outgoing traffic on port 25 via CBQ so it cannot balloon to fill our bandwidth completely up. This seems to be working great. Reintroducing the messages into the tmp folder also seems to work just fine.
So here's my next tough question - I'm afraid if I move too many at a time back into courier, that any "normal" outgoing mail that people here send will get bogged down behind these large, stupid email. Is there a way to prioritize the queue via an email list, size, etc.? When I backed up the queue, I was able to send messages out, but I can't understand why this should be possible. Does courier make any judgment based on size of the file or something like that? Thanks for your help so far....Hopefully I'll be able to balance what Marketing wants versus keeping my core users in service. Josh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sam Varshavchik Sent: Wednesday, May 28, 2003 12:57 PM To: [EMAIL PROTECTED] Subject: [courier-users] Re: Courier TOO good Josh Remus writes: > « HTML content follows » > > I've got a problem that I encountered this morning. We have a 384 pipe in > and out of here, and one of our marketing people sent out a mass-emailing > (1.31 MB a piece) that completely clobbered our bandwidth. But of course, > courier handled itself just as I had hoped it would, it had no problem > with the number. > > When I got in, people were screaming about the bandwidth. Turning down > the maximum number of ESMTP connections (which doesn't seem to like less > than 40 for that setting) doesn't cut it. So - here's what I had to do: I You are probably tuning the maximum number of incoming smtp connections, which of course doesn't affect outgoing mail. For outgoing mail, you need to twiddle etc/module.esmtp; turning down MAXDELS (but never below MAXHOST), and then restart Courier. > moved the folders under /var/spool/courier/msgs to someplace temporary, > since there were 800 in the queue. This stopped the flood for the moment > & let the normal email go in and out again. > > I don't know if this is kosher at all, but courier seemed to handle those > folders disappearing okay. But I need two things: Well, it's not exactly 100% kosher; you should have a bunch of complaints in syslog somewhere, but that's about it. > 1. I need to reintroduce those messages a little at a time, because > while I could cancel the marketing email, some legit email probably got > moved along with all the marketing junk. > 2. I need to throttle the outgoing connections or something like that > so that the mail server can not normally consume all that bandwidth, or > all that bandwidth for all that time. > > Ideally (which never usually happens) - I could make some changes to the > configs on the mail server and somehow move all the messages back in - > then they would slowly deliver themselves while keeping some of the > bandwidth available for other things. Stop Courier, turn down max # of connections to 8. Make sure that there are no links to the pulled messages in the msgq directory. There are hard links from msgq to msgs, which you didn't do anything about, which is the main problem. Go through all the folders you took out, and make sure that every file has exactly one link. If there are more than one link to a file, the second link is somewhere in msgq. Find it and remove it. Then move all the files in all the removed folders (NOT copy them) to /var/spool/courier/tmp (or /usr/lib/courier/var/tmp, as the case may be). There's going to be one or two numeric subdirectories there. All files should be moved into the last numeric subdirectory. Then restart Courier. Hopefully things will work now. If not, you'll just have to make sure everything's stopped, then blow away everything in msgs and msgq subdirectories (but not the subdirectories themselves) and restart; and write off the lost mail as a learning experience. ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
