Hi all, I am also a small ISP but I don't have such problems and I don't use a cluster yet. The easiest solution is normall the best one. If you have a Storage try to implement a Load Balance with multiple mail servers instead of a cluster. This way you will be able to answer smtp/pop3 requests using multiple IP addresses. But before that you should check your bandwidth and delay also. Many problems occur on the transmission side.
Regards On 22 May 2012 01:14, Eric Shubert <[email protected]> wrote: > On 05/21/2012 03:06 PM, [email protected] wrote: > >> Hello Eric, thanks for your reply. >> >> We do not have spam issues with our customers, what we have is a high >> volume due to large clients number. >> > > With so many clients, the probability of compromised passwords is fairly > high. I wouldn't be very quick to dismiss this as a possibility. Do your > anti-spam measures have any effect on authenticated smtp sessions? > > > All meassures to void spam sending are taken, but the blocks are being >> generated for large volume send from just a bunch of IPs (5) which are >> the number of mta's qmt in our cluster. As all you may know, having 9k >> clients with at least 4 email accounts per client and a limit of 350 per >> hour per account, it is still a big traffic generated. >> > > 350 per hour per account seems like a high limit to me for typical email > use. In any case, how are you enforcing this limit? > > > So I am looking forward to have better service on delivery having in >> mind that custmer number is growing fast and anti-spam messures do its >> job preatty good. But of the lack of IP on each mta in cluster, it is >> affecting delivery. >> >> Hope someone around may share a solution. >> > > Are all machines in the cluster going out on the the same public IP? If > so, I presume you have NAT in effect. If that's the case, you should look > into implementing SNAT along with NAT, so the source IP changes according > to which machine behind the NAT is the source of the packets. This is > something your NAT router needs to do. > > >> Thanks. >> > > A little more detailed description of your current setup might be helpful > for us to know what might be most effective for you. > > -- > -Eric 'shubes' > > >> On lun 21/05/12 4:55 PM , Eric Shubert [email protected] sent: >> >> I don't know if rotating addresses is the best solution or not. It's >> certainly not practical for small QMT installations. >> >> I think in many (if not all or most) of these cases, the user's >> password >> has been compromised. This is especially likely if it's possible to >> configure a client insecurely (plain text password with no TLS/SSL). >> I've seen this happen on more than one occasion, on a small domain. >> Password sniffing does happen. >> >> First step is to ensure that clients cannot attempt to authenticate >> with >> clear text passwords. This can be enforced with dovecot, but we don't >> have a way yet to enforce it on the sending/smtp side. I'm hopeful that >> Sam will get this feature built into spamdyke in the near future. >> >> Another good defensive weapon is a script I came across on the spamdyke >> list today, and hope to make available in some form with QTP in the >> future. It's a script that periodically checks the logs for accounts >> which have sent more messages in a given interval than some allowed >> limit. When it finds such an account, it changes the password, removes >> messages from that account still in the queue, and notifies the >> postmaster with an email. I think this is very practical, because >> passwords do become compromised on occasion, even with full encryption >> (human action). The script is written in python, and will need a little >> tweaking for the QMT environment, as it's presently written to scan a >> spamdyke log (the author wasn't using the submission port at all). I >> think it'd be better to scan the send log if that's feasible. >> Anywise, I >> think this approach is promising. >> >> If anyone has any thoughts on this, please chime in. It's in everyone's >> interest to be protecting our public IP addresses so they don't get >> blacklisted. >> >> Thanks. >> >> -- >> -Eric 'shubes' >> >> On 05/21/2012 01:42 PM, [email protected] >> <mailto:[email protected]> wrote: >> >> > Hello everyone >> >> > >> >> > >> >> > I am the owner of a growing hosting enterprise in my country >> (Perú), and >> >> > we are facing big rise on our client number. >> >> > >> >> > As an efect of this we are seeying a rise in mail outbound in our >> >> > servers. Even thoug we put limits to hourly sending, having more >> than 9k >> >> > clients, all delivering through the same cluster, it lacks of >> >> > efectiveness because each server in cluster uses only one ip for >> sending >> >> > tasks. We are now seeying blocking issues because of the many clents >> >> > generated traffic. >> >> > >> >> > We talked to some people at godaddy and hostgator, as we know they >> use a >> >> > cluster system that includes on each server a list of IPs that >> rotates >> >> > in a random fashion, so even with high demand quality service on >> mail >> >> > delivery from client accounts is always achieved. >> >> > >> >> > I would like to ask for some guidance and help to this comunity on >> how >> >> > can we could implement such solution to rotate in a random or >> other way >> >> > the IPs for sending clients mails. >> >> > >> >> > I hope you people can see my situation and can help me with this. We >> >> > used to work with exim, but since we changed to QMT it was the best >> >> > desition we ever made on this matters. Now we need to push it to a >> next >> >> > level. >> >> > >> >> > >> >> > >> >> > Thanks a lot. >> >> > >> >> > >> >> >> >> >> ------------------------------**------------------------------** >> --------------------- >> Qmailtoaster is sponsored by Vickers Consulting Group >> (www.vickersconsulting.com) >> Vickers Consulting Group offers Qmailtoaster support and installations. >> If you need professional help with your setup, contact them today! >> ------------------------------**------------------------------** >> --------------------- >> Please visit qmailtoaster.com for the latest news, updates, and >> packages. >> >> To unsubscribe, e-mail: >> >> qmailtoaster-list-unsubscribe@**qmailtoaster.com<[email protected]> >> <mailto:unsubscribe@**qmailtoaster.com <[email protected]>> >> For additional commands, e-mail: >> >> qmailtoaster-list-help@**qmailtoaster.com<[email protected]><mailto: >> [email protected]> >> >> >> >> > > > ------------------------------**------------------------------** > --------------------- > Qmailtoaster is sponsored by Vickers Consulting Group ( > www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > ------------------------------**------------------------------** > --------------------- > Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: qmailtoaster-list-unsubscribe@** > qmailtoaster.com <[email protected]> > For additional commands, e-mail: qmailtoaster-list-help@** > qmailtoaster.com <[email protected]> > > >
