poti sa-ti faci si singur patch-ul ala, numai ca tre sa ai mare incredere in cunsotintele tale de programator
in exim.conf pui dupa driver=smtp si
interface=ALT-IP.DE.PE.MASINA-RESPECTIVA
si iti faci X exim.conf-uri, unde X= nr de ip-uri de pe masina respectiva, si pui un cron care sa le schimbe si sa dea restart la exim. Este o solutie total aiurea, dar cel putin nu dai banii pe ea
nu stiu daca exim.conf suporta include-uri, si daca suporta daca sunt citite la fiecare trimitere de mail, sau numai o data la exim reload. Oricum, restartarea lui exim la 10 minute nu e o solutie prea buna.
Eu am aplicat alta solutie, in special pt newsletere (care evident sunt contin multe mailuri catre yahoo)
am definite 4 A-uri identice in DNS
sa zicem
hostname 4 IN A 192.168.0.1
hostname 4 IN A 192.168.0.2
hostname 4 IN A 192.168.0.3
hostname 4 IN A 192.168.0.4
4 ala reprezinta TTL-ul, adica 4 secunde.
am 4 masini (momentan sunt masini separate fizic, in curind vor fi niste vps-uri) care sunt configurate identic, si nu au decit qmail-send pe ele.
fac relay numai pt alte servere de la mine, evident
clientii care trimit newsletere sunt rugati respectuos sa foloseasca trimiterea prin smtp, nu prin mail() - majoritatea folosesc phpmailer, care stie de smtp, deci nu e f. complicat.
ideea e ca pe serverele care trimit newsletere este pus un resolver care nu face caching, iar hostname.etp.ro de exemplu se rezolva round-robin. Prin urmare, pt un numar destul de mare de conexiuni la smtp, cele 4 servere care trimit mailuri sunt destul de balansate.
Solutia am aplicat-o de curind, cand m-am trezit cu 38.000 mailuri catre yahoo intr--o coada de qmail, si din 10 conexiuni la yahoo 9 dadeau fie retry fie timeout. Am estimat ca cele 38k mailuri s-ar fi trimis in fro 12 ore, ceea ce era inacceptabil. Asa, cu solutia asta, au plecat in 2 ore.
Inca mai experimentez (o alta solutie ar fi pathcuirea qmail-ului pt a rula cozi separate pe ip-uri separate), dar momentan asta functioneaza ok pana gasim altceva mai bun.
