I think the bottleneck must be somewhere else. I'm administering a qmail based mass e-mail system, and we're sending a bulletin to 250.000 members, which takes 6-7 hours, with a single server (a run-of-the-mill Dell PE850). I first had it configured with DKIM but had to turn it off because it was a resource hog. Also, I don't think having a single IP is a problem, I would rather check whether your ISP is capping your bandwidth.
Regs, Alberto 2012/5/23 Eric Shubert <e...@shubes.net> > On 05/23/2012 12:31 PM, F. Mendez wrote: > >> Hi Eric, >> >> 350 per hour is a very low limit. We work as with the lowest standard at >> this matter, offering same or less than big hostings like hostgator. >> > > Perhaps our language isn't consistent. Are you referring to 350 per hour > per domain, or per user? (I'm referring to per user, which I still think is > high, unless your clients are doing email marketing). > > > Cluster is: 5 servers, one IP per server, MX priority from 0 to 40 each. >> > > That's nice to know, but MX won't have anything to do with outbound > messages. > > > All are balanced to reach no more than 8k emails an hour each. >> > > Inbound or outbound, or both? > I'd be interested to know how you manage to throttle this. > > > No VM, real boxes working. >> > > Given your setup, you might configure a round robin for outbound, as I > mentioned previously in reply to CJ's post. This isn't ideal performance > wise, as each messages would be queued in 2 hosts, but I think it would > work adequately. Also, you'll need to be sure that DNS caching doesn't > interfere with round robin rotation (I'd test that first before committing > to this approach). > > Otherwise, you might assign multiple addresses to one (or more) hosts, and > come up with a way to alternate between addresses. One way would be to > modify the qmail-remote program. It might be possible to periodically > modify the routing table to achieve the same result, but I'm not sure about > that. > > There are likely other ways as well. Personally, I like the round robin > solution because of its simplicity. You would need to have all of the > submissions come into one server, and relays go out from the others. I > don't think that a host could perform both roles, although a submission or > relay server could continue to function as an incoming (MX) host as well. > > -- > -Eric 'shubes' > > > >> Regards. >> >> -----Mensaje original----- From: Eric Shubert >> Sent: Tuesday, May 22, 2012 8:14 PM >> To: qmailtoaster-list@**qmailtoaster.com<qmailtoaster-list@qmailtoaster.com> >> Subject: [qmailtoaster] Re: Help request to comunity on tech issue. >> >> Sounds like you've taken great measures to prevent unauthorized use. >> >> I still think that 350 per account is high though. That's an average of >> nearly one every 10 seconds for 60 minutes straight. I think it's safe >> to say that some of these people are sending to lists. They're your >> customers though, so I don't doubt that they're generating the volumes >> you say. >> >> How is your cluster presently configured? Are all hosts sending outbound >> email in a balanced fashion? You've said that you have 5 hosts and 5 IP >> addresses, but haven't told us much about how things are configured. Are >> each of these 5 hosts QMTs? On bare iron or virtual? >> >> On 05/22/2012 05:23 PM, F. Mendez wrote: >> >>> Hi Eric. >>> >>> We have modified our control panel so that when clients create a new >>> email, the can't use their own passwords. It is generated with high char >>> random values. We also had put limits to conections and monitor ip >>> conections during smtp/pop tasks. Not more than 1 conection to smtp or >>> pop, and only same IP on both tasks can be accepted. Any other attemp >>> over 5 times blocks the accounts. We also track ip origin on smtp/pop >>> conection and webmail conection. If the regular base is that ip connects >>> from peruvian ranges, and suddenly there is one conection from any other >>> part of the world, then account is blocked and client is asked to fill >>> secret info regarding its account and the 2nd email he/she registered at >>> signup time. >>> >>> Limit to 350 is not high, as our clients are not home users. Over 99% of >>> them are small medium size companys that use alot of emails during day. >>> We already had done a process to determine this and it is a real usage. >>> In same cases it is even not enought. >>> >>> And as I wrote before: >>> >>> Our clients are 99% enterprises. Small, medium size, and thus their >>> needs to send emails is not comparable to regular home users.. Even 350 >>> mails per hour is in some cases not enought. Thought they don’t want to >>> rise their monthly payment or move to dedicateds. So traffic is high. >>> Having multiple servers or having them on cluster is just the same. As >>> each one only have 1 ip, reputation may be affected due to the high >>> volume. Solution is to split as much as possible with diferent ips over >>> each current server on array. We already talked about this with our tech >>> assesor. So please any answer or contributions regarding this thread I >>> would really appreciate that would be focus to this. >>> >>> >>> >>> Regards. >>> >>> >>> >>> -----Mensaje original----- From: Eric Shubert >>> Sent: Monday, May 21, 2012 6:14 PM >>> To: qmailtoaster-list@**qmailtoaster.com<qmailtoaster-list@qmailtoaster.com> >>> Subject: [qmailtoaster] Re: Help request to comunity on tech issue. >>> >>> On 05/21/2012 03:06 PM, fmende...@terra.com 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. >>> >>> >> >> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > qmailtoaster-list-unsubscribe@**qmailtoaster.com<qmailtoaster-list-unsubscr...@qmailtoaster.com> > For additional commands, e-mail: > qmailtoaster-list-help@**qmailtoaster.com<qmailtoaster-list-h...@qmailtoaster.com> > > -- * [image: HazteOir.org] Alberto López Navarro Director Técnico HazteOir.org alnava...@hazteoir.org +34 662 108 598 Facebook <http://www.facebook.com/albertoln> | @albertczyk<http://twitter.com/albertczyk> | Blog <http://blogs.hazteoir.org/alolejos> ++Sí, quiero <http://hazteoir.org/> recibir regularmente información de las iniciativas de HO ++Cambia el mundo, <http://haztesocio.org/haztesocio> hazte socio. Fácil. ++Colabora <http://haztesocio.org/hazundonativo> con un donativo. En un minuto. ::: HO en Facebook <http://www.facebook.com/HazteOir.org> | @hazteoir<http://twitter.com/hazteoir> | @derechoavivir <http://twitter.com/derechoavivir> | YouTube<http://www.youtube.com/hazteoir> | Flickr <http://www.flickr.com/photos/hazteoir> *
