Dotaz: Postfix - vice emailu jedno spojeni

[MP]

Zdravim,

nevi nekdo, jak nakonfigurovat postfix tak, aby dokazal poslat jednim spojenim vice emailu? Vim, ze by default by mel pouzivat cache spojeni, pokud je v aktivni fronte email na stejnou domenu, ale kdyz si vypisu scache z logu, tak v 99% tak mam 0% success i kdyz jsou ve fronte stovky emailu. Proc to resim - mame problemy se seznam.cz, jakmile nastavim:

turtle_destination_concurrency_limit=1

turtle_initial_destination_concurrency=1

Tak emaily chodi, pomalu, ale nejsme v temp banu.

Ale:

turtle_destination_concurrency_limit=2

turtle_initial_destination_concurrency=1

nas po chvili zablokuje.

Pouziva se primarne TLS spojeni. Mame od seznamu zhruba obecne nastaveni, aby to mohlo fungovat, ale nejak se nam to nedari naroubovat na postfix, ktery ma nektere moznosti rate limitu nenaprogramovane ci co.

Ta nastaveni od seznamu jsou ve stylu:

1] connection/time

2] mails per connection

3] use longer time to delivery

Diky.

---

---

Odpovědi

[NN]

TUNING_README. Vsechno tam mas..

[MP]

Tohle mam prohledany odshora dolu a proste ne a ne, nemuzu na vhodne nastaveni prijit. A to jsem zkousel i manipulovat s smtp_connection_cache_*.

[Filip Jirsák]

Souběžné doručování na jeden server ovlivňují parametry initial_destination_concurrency, default_destination_concurrency_limit případně smtp_destination_concurrency_limit speciálně pro SMTP klienta. Předpokládám, že jde o různé e-maily (ne jeden e-mail pro více adresátů), takže parametr default_destination_recipient_limit se vás netýká.

[MP]

To ja ale vim. Tyto parametry ale urcuji pocet spojeni najednou na server. A ja potrebuji to omezit na jedno spojeni, ale aby jim slo vice emailu.

Feb 2 09:03:16 posftif postfix-4/scache[22798]: statistics: start interval

Feb 2 09:00:26

Feb 2 09:03:16 postfix postfix-4/scache[22798]: statistics: domain lookup hits=0 miss=456 success=0%

Pokud ale mam ve fronte treba 200 emailu a mam to omezene na jedno spojeni, proc to nejde tim jednim spojenim?? Vzdyt pisu, ze jakmile mam "*_destination_concurency_limit" > 1, tak dojde k tempbanu. Ale kdyz tam mam =1, tak to zase posila zdlouhave dlouho.

[NN]

Jak, presne, vypadaji podminky Seznamu?

[MP]

Presne podminky nam nesdelili. Pouze nam dali obecne doporuceni, jak bychom se mohli pohybovat:

1] XX spojeni/5min

2] vhodne XXX mailu na 1 spojeni

3] hromadne newslettery - rozlozit na delsi dobu

[Filip Jirsák]

Neznáme vaši konfiguraci, dokonce ani verzi Postfixu, nevíme, jaké jsou výsledky doručování. Takže těžko něco radit. Cache spojení nelze použít nemůžete, když používáte TLS, takže pokud to chcete řešit tímto způsobem, pomůže jedině vypnout TLS pro Seznam.cz.

[MP]

Verze 2.11.3-3 (Debian Jessie). Vypnout TLS neni reseni.

Konfiguraci, vysledky dorucovani znat nemusite. Ja se sakra ptam, zda existuji parametry v postfixu kterymi jde takovyhle rate limiting nastavit, nebo to proste out of box postfix neumi a je nutne pouzit dodatecne moduly a pak, ktere. Pokud jste to nikdy neresil, tak vubec nereagujte, protoze to nemate vyzkousene, zda neco takoveho jde s postfixem udelat.

[NN]

Ktera firma dorocuje hromadnou postu do Seznamu? Resis nesmysl uz principu veci tak si laskave nestezuj. GTFO a vyres si to ze Seznamem sam..

[MP]

Takova, ktera ma zakazniky, jejichz klienti jsou v drtive vetsine cesti spotrebitele s uctem na seznamu.

[Filip Jirsák]

Čemu nerozumíte na větě „cache spojení nelze použít, když používáte TLS“? Architektura Postfixu je prostě taková, že to neumožňuje – cache spojení je sdílena napříč procesy a pak nelze sdílet informace z TLS. Pokud byste to chtěl řešit dodatečným modulem, ten modul by musel řešit kompletně celé odesílání e-mailů (musel byste nahradit SMTP klienta smtp). To byste toho z Postfixu moc nevyužil.

Konfiguraci, vysledky dorucovani znat nemusite.

Pokud bych vám měl poradit s řešením vašeho problému, tyhle informace by se dost hodily. Ale máte pravdu, že řešit váš problém opravdu nemusím.

Pokud jste to nikdy neresil, tak vubec nereagujte, protoze to nemate vyzkousene, zda neco takoveho jde s postfixem udelat.

Tak daleko jsme se zatím nedostali. Zatím řešíme to, že jste pravděpodobně ani nečetl dokumentaci, nebo jí z nějakého důvodu nevěříte. Na to, abych přečetl dokumentaci za vás, ještě stačím.

[lertimir]

Myslím, že se snaží dosáhnout toho, že když pošle mail.

MAIL FROM:
RCPT TO:
DATA

...

sekvence <cr><lf>.<cr><lf>

aby postfix neukončil spojení příkazem quit ale, aby sekvencí MAIL FROM: zahájil další mail v tom samém TCP spojení.

[Filip Jirsák]

To já vím. Nejspíš to ale nebude cíl, kterého chce dosáhnout, ale jenom nástroj k dosažení nějakého jiného cíle. Přičemž tenhle nástroj je s Postfixem a zasíláním přes TLS nedostupný.

Postfix neseskupuje zprávy podle cílového serveru. Má zprávy jednoduše ve frontě, klienti odebírají jednu zprávu po druhé a odesílají je. Takže odeslání více e-mailů jedním spojením je implementováno pomocí cache spojení. Po odeslání e-mailu klient spojení neukončí, ale vrátí ho do cache – odkud si ho může vyzvednout jiný klient připojující se na stejný server. Jenže tohle nejde použít s TLS, protože údaje z TLS jsou dostupné jenom tomu klientovi, který spojení navázal, ale není možné je předat jinému klientovi, který by si to spojení vyzvednul z cache.

Je ale možné (a dost pravděpodobné), že požadovaného cíle lze dosáhnout i jinou cestou, než sdílením spojení. To bychom ale museli vědět, co MP (nebo JP?) doopravdy řeší.

[Jooky (inactive)]

Tiez si to myslim ... s velkou pravdepodobnostou je toto dosledok problemu, nie jeho zdroj ... a bez dalsich informacii sa len tazko da pomoct.

[lertimir]

Chápu. trochu je překvapivé, když by to měly být cílové seznamové účty. Postfix tedy neumí je poslat maily jedním spojením, i když by je měl za sebou ve frontě v případě TLS. Pamatuji si dobu, kdy se ještě používal příkaz TURN SMTP protokolu, který vyměnil roli klienta a servery a přes stejné spojení dvě BBS si poslaly maily postupně oběma směry.

[Jooky (inactive)]

Ja neviem co sa rozculujete. Zatial ste stale nepovedali:

- co sa snazite dosiahnut ?
- ako to mate nastavene ?
- akou chybou skonci dorucovanie ?
- co znamena 200 emailov v queue ?
- co znamena tempban od seznamu ?

Do servisu tiez nevolate, ze auto "nejde", ale nestartuje / chyba na pristrojovke / divne zvuky / etc. Takze bud preformulujte otazku, alebo doplnte chybajuce udaje.

FYI: dorucovanie na sesnam.cz(sk) je by default pomale a s tym nic nespravite. Ja osobne si stale myslim, ze seznam pouzivaju len ludia, co si nevedia zabezpecit lepsi email ...

[MP]

1] zlepsit odesilani lepsim vyuzitim limitu od seznamu, aby bylo mozne dorucovat dorucovat s mensi casovou prodlevou (nyni i 5h) viz 3]

2] zakladni nastaveni je standardni postfix, modifikace jsou per domain z postfix tunning manpages, viz uvod

3] dorucovani pri soucasnem nastaveni konci odeslanim, ale z duvodu vyrazneho zpomaleni odesilani dochazi k hromadeni vysokych objemu mailu na seznam v active queue -> dochazi k vyraznemu zpomaleni serveru protoze v queue je rekneme 95% mailu pro seznam, pricemz fronta jde i pres 10k mailu aktivne. Zvyseni poctu spojeni z hodnoty 1 -> bod 5]

4] 200 emailu v queue je priklad, davkove zpracovani z klientskych systemu generuji kolem 1000/min mailu, 70%+ adresatu je na seznamu

5] 421 "You have been temporarily banned. Try again later or report to ."

[Petr Šobáň]

Co s tím chceš dělat?

Jak ti psaly s TLS to nejde.

Takže jediné řešení je komunikovat s seznamem aby tvůj SMTP daly na bílou listinu a neodmítaly od tebe poštu.

Ovšem to nepůjde seznam tě pošle někam - vlastní skutečnost kdy se mi na seznamu strácely maily a když jsem seznamu dokázal že je chyba u nich (logem sz SMTP serveru) že mail jejich SMTP korektně přijal a do schránky nikdy nedorazil tak pro jistotu se mnou přestaly komunikovat.

Na to jsem se nasral a zařídil si vlastní placený e-mail a později vlastní VPS pro mail....

PS. Nepomohlo by si na seznamu založit schránku a pak použít jejich SMTP s autentifikací kam by jsi sypal maily pro seznam?

Sry, ale tvoje čeština je naprosto otřesná. Aby člověk pracně hádal, co máš na mysli...

[Jooky (inactive)]

Ja som slovak a pochopil som ho :)

[Jooky (inactive)]

1000/min mailu. To mi pride hodne na nejake legitimne pouzivanie, ale budis ... vela moznosti v tomto pripade nemas

1) zmierit sa s tym, ze TLS nebude.
2) neposielat emaile cez jeden server, ale cez viacej. Napr. mx1.example.com, mx2.example.com, .... typ padom poriesis concurency
3) sprav si v seznam.cz konto a skus nastavit postfix aby dorucoval emaile "ako client".

Bohuzial situacia so seznam, je presne ako Peter pise.

V pripade moznosti 2) ani netreba viac servrov, staci viac IP a viac krat pusteni postfix.

[Jesus Jimenez]

Ja tohle se seznam.cz uz vzdal. Zhruba 2000 zakosu tam ma email, zhruba 1500 z nich chce mailem mesicni vyuctovani. Skoncil jsem na tom, ze tech 1500 mailu do seznam.cz musim rozlozit asi do sesti hodin, jinak me zabanujou a maily stoji dva dny v queue...

[MP]

No, cesta bez TLS je trnita (rekonfigurace klientskych systemu, odliseni single/bulk maily, antispam hodnoceni...). Redundantni postfixy uz mame, ale na to mnozstvi je to proste malo. Zvysit jejich mnozstvi znamena jak zahodit IPv4, tak dalsi HW, protoze uz takhle je to na hrane diskoveho pole. A ta treti varianta, ta me nenapadla, to uz si ale rovnou muzeme nasmerovat klientske systemy primo na seznam. Navic nevim, jak by se to seznamu libilo, kdyby mu tam nejaky klient cpal velke objemy mailu :D Navic, mit pak seznam ucet per projektovy zakaznik a nasledna sprava operatory projektu, no...

[Filip Jirsák]

No, cesta bez TLS je trnita (rekonfigurace klientskych systemu, odliseni single/bulk maily, antispam hodnoceni...)

Proč rekonfigurace klientských systémů? Podle mne jenom nakonfigurujete ten Postfix, nastavíte mu smtp_tls_policy_maps a do mapy přidáte seznam.cz → none.

Zvysit jejich mnozstvi znamena jak zahodit IPv4

Zrovna doručování přes IPv6 vám asi pomůže, protože je pravděpodobné, že bude Seznam počítat limity i pro každou IPv6 adresu zvlášť, takže můžete z jednoho stroje odesílat pod více adresami.

[Filip Jirsák]

Myslím, že pro vás platí především to „rozložit odesílání newsletterů na delší dobu“. Píšete o dávkovém zpracování, takže by to nemělo vadit. Otázka taky je, jak moc by vám pomohlo to odesílání většího množství e-mailů najednou – zda byste stejně nenarazili na jiné limity (dovedu si představit, že vám dovolí poslat XXX mailů v jednom spojení třeba třikrát za sebou, ale když to budete opakovat po desáté, stejně vás zablokují, protože sledují i celkový počet e-mailů z dané adresy za nějaký čas). Pokud to chcete otestovat, máte nejjednodušší vypnout dočasně pro Seznam TLS a zjistit, jak moc vám to odesílání více e-mailů najednou pomůže.

Pokud to pomůže, oddělil bych pak provoz na Seznam od ostatních e-mailů. Samostatný transport a samostatnou instanci klienta. Je možné, že už pak Postfix dokáže použít spojení opakovaně v rámci jednoho klienta. Pokud ne, nezbyde asi než směrovat tenhle provoz přes nějakého jiného klienta, nejspíš nějakého určeného pro SMTP relay, který bude optimalizovaný pro odesílání většího množství e-mailů na jeden server.

Pokud vám pomůže i dvojnásobné zrychlení, můžete se inspirovat u spammerů a posílat e-maily i na záložní server (pokud není jen na oko a Seznam nemá kontroly na serverech provázané). Dalšího dvojnásobného zrychlení dosáhnete tím, že budete e-maily odesílat přes IPv4 i IPv6.

5] 421 "You have been temporarily banned. Try again later or report to ."

Předpokládám, že k tomu dochází tehdy, když nové spojení otevřete dříve než za XX/5 minut. Tohle se také bude v Postfixu řešit obtížně. Pokud budete mít pro Seznam samostatnou frontu, můžete ladit parametry, jak často frontu vybírat, ale asi si tím moc nepomůžete.

Každopádně pokud pro vás „rozložení odesílání na delší dobu“ není řešení, hledal bych specializovaného klienta, který bude odesílat e-maily jen na Seznam. Postfix na takovouhle úlohu není stavěný, detailní ladění časování a limitů pro jednoho příjemce je mimo jeho typické použití.