<p>Also remember that the queue content is just files... Stop ms (and the mta) and move a sizeable bit of 'em out of the way, then start things up and start feeding reasonable amounts back... <br>
Best performance tip: don't do work you don't have to! If you can reject mail, then configure to do so... Unknown recipients (recipient verification), known bad sites (RBLs), RFC violations etc.<br>
Also make sure you don't overcommit your resources (too many children, too memory-hungry SA rules, using wrong clam (module or commandline instead of clamd) etc)... Most of this should be in the wiki...</p>
<p>Cheers<br>
-- <br>
-- Glenn</p>
<div class="gmail_quote">Den 27 aug 2011 08:55 skrev "Martin Hepworth" <<a href="mailto:maxsec@gmail.com">maxsec@gmail.com</a>>:<br type="attribution">> Mailscanner sits between two instances of and mta and suffles emails between<br>
> the queues for delivery. If u look at the mailscanner init script you may<br>> find the option to stop the "incoming" mta depending On how u installed<br>> mailscanner in the first place.<br>> <br>
> But I'd look in the logs and also the performance section of the wiki for<br>> some ideas to speed up ms as well<br>> <br>> Martin<br>> <br>> On Saturday, 27 August 2011, Michael Masse <<a href="mailto:mrm@medicine.wisc.edu">mrm@medicine.wisc.edu</a>> wrote:<br>
>><br>>><br>>>>>> On 8/26/2011 at 4:27 PM, in message <<br>> <a href="mailto:DA838176-A795-4431-BD4B-E265949B8E8D@fluxlabs.net">DA838176-A795-4431-BD4B-E265949B8E8D@fluxlabs.net</a>>, Jeremy McSpadden <<br>
> <a href="mailto:jeremy@fluxlabs.net">jeremy@fluxlabs.net</a>> wrote:<br>>> Stop your mta<br>>><br>>> --<br>>> Jeremy McSpadden<br>>> Flux Labs, Inc<br>>> <a href="http://www.fluxlabs.net">http://www.fluxlabs.net</a> <<a href="http://www.fluxlabs.net/">http://www.fluxlabs.net/</a>><br>
>> Endless Solutions<br>>> Office : 850-588-4626 <tel:850-588-4626><br>>> Cell : 850-890-2543 <tel:850-890-2543><br>>> Fax : 850-254-2955 <tel:850-254-2955><br>>><br>>><br>
>> Ok but how does previously accepted and queued up mail continue to process<br>> and get distributed to appropriate servers if I do that so that<br>> overflowing queues can get caught up? If I simply stop the MTA (sendmail)<br>
> then how does mail flow to appropriate servers?<br>>><br>>> Like I said previously: Mailscanner appears to me like it starts a<br>> separate MTA process for incoming email versus a different MTA process for<br>
> sending email that has been processed. Does MailScanner give the option of<br>> not starting up the incoming MTA and only running the processing/sending<br>> MTA? Using iptables to block port 25 does block incoming emails, but seems<br>
> to cause other problems so that processing/sending already queued up mail<br>> doesn't work either. If I could simply get MailScanner to temporarily not<br>> start up the incoming MTA (Sendmail) that would seemingly solve my problem.<br>
> If MailScanner doesn't give the option per se, can I somehow force<br>> MailScanner to not start up the incoming MTA process? Maybe I'm looking at<br>> this all wrong, but essentially here is what I want to do: I have other<br>
> servers that can respond to the same mx record lookup and when this server<br>> is having problems with it's incoming queue getting overloaded I want to<br>> manually tell it to stop accepting new mail so that it can process what it<br>
> already has accepted. Other servers that respond to the same MX scope<br>> should take up the slack for new email, while hopefully I can get this one<br>> to process an overflowing queue and reduce it to a manageable size.<br>
> Regarding WHY this is happening in the first place is a separate issue that<br>> I'm trying to figure out. In the mean time I need a workaround to keep<br>> email from queuing up on this server and taking forever to process.<br>
>><br>>> -Mike<br>>><br>>>>>> On 8/26/2011 at 4:27 PM, in message <<br>> <a href="mailto:DA838176-A795-4431-BD4B-E265949B8E8D@fluxlabs.net">DA838176-A795-4431-BD4B-E265949B8E8D@fluxlabs.net</a>>, Jeremy McSpadden <<br>
> <a href="mailto:jeremy@fluxlabs.net">jeremy@fluxlabs.net</a>> wrote:<br>>> Stop your mta<br>>><br>>> --<br>>> Jeremy McSpadden<br>>> Flux Labs, Inc<br>>> <a href="http://www.fluxlabs.net">http://www.fluxlabs.net</a><br>
>> Endless Solutions<br>>> Office : 850-588-4626<br>>> Cell : 850-890-2543<br>>> Fax : 850-254-2955<br>>><br>>><br>>> On Aug 26, 2011, at 4:26 PM, Michael Masse <<a href="mailto:mrm@medicine.wisc.edu">mrm@medicine.wisc.edu</a>> wrote:<br>
>><br>>>> I'm having performance issues on one of my incoming email servers, and<br>> while I'm trying to figure out the root of that problem I need to be able to<br>> tell MailScanner to stop accepting incoming mail so that it can get caught<br>
> up on the email it has already accepted and queued up. I have multiple<br>> servers running w/ this mx record, so senders should just find a different<br>> server to send to automatically if this one stops accepting. It appears<br>
> to me that MailScanner starts a secondary sendmail process specifically just<br>> for receiving email vs sending, so hopefully there's some sort of startup<br>> command that would allow me to not accept new email. I've tried just<br>
> blocking port 25 from the outside on this server specifically via iptables,<br>> and it does prevent outside systems from sending mail, it also keeps<br>> MailScanner from properly processing queued up mail for some reason.<br>
> Any help would be greatly appreciated.<br>>>><br>>>> -Mike<br>>>><br>>>> --<br>>>> MailScanner mailing list<br>>>> <a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
>>> <a href="http://lists.mailscanner.info/mailman/listinfo/mailscanner">http://lists.mailscanner.info/mailman/listinfo/mailscanner</a><br>>>><br>>>> Before posting, read <<a href="http://wiki.mailscanner.info/posting">http://wiki.mailscanner.info/posting</a>><br>
> <br>> -- <br>> -- <br>> Martin Hepworth<br>> Oxford, UK<br></div>