Dotaz: Rozeslání většího počtu mailů

[jan.rok]

Dobrý den,

máme aplikaci, která umí vygenerovat logy pro jednotlivé uživatele a rozeslat jim je mailem (jde o logy z měřidel). V aplikaci je zadán SMTP server a ověřovací údaje, port.

Funguje to bez potíží, pokud vyberu několik málo uživatelů najednou. Ale v okamžiku, kdy vyberu všechny (cca 1800 mailů), dojde k tomu, že aplikace maily vygeneruje, pošle ven na port 25, což způsobí zablokování odesílání ze strany providera. Ten si hlídá SMTP provoz a omezuje odesílání na tuším max. 5 mailů/s - chrání se tím proti tomu, aby se nedostal na blacklisty.

Nechci jeho omezení obcházet, spíš by mě zajímalo, jak frontu mailů z té hloupé aplikace nějak pozdržet, rozkouskovat a odesílat postupně. I kdyby to mělo trvat celý den. Na aplikaci vliv nemám, autor je asi už nedohledatelný.

Napadlo mě nainstalovat vlastní mailserver a nějak ho nakonfigurovat tak, aby posílal třeba 1 mail/s.

Je ještě nějaké jiné řešení?

Děkuji. JR.

---

---

Odpovědi

[X]

Pokud se jedna o uzivatelskou postu je to interni mail, ktery nikam neodchazi a je omezeny jen nastavenim tveho vlastniho postovniho serveru. Nebo ma snad kazdy uzivatel soukromy mail na soukrome domene?

[jan.rok]

Uživatelé asi nebylo správné označení - spíše klienti. A ano, mají maily různě mimo naši doménu.

[jiwopene]

Posílá-li to sendmailem, resp. sendmail-kompatibilním rozhraním (např. ssmtp), což tyto „hloupé“ aplikace zpravidla dělají, nebude problém sendmail nahradit skriptem, který zapíše zprávu do souboru a budou se potom postupně rozesílat.

Opravdu není možné tu aplikaci upravit, popř. řešit rozesílání jinak – třeba skriptem se sendmailem?

[jan.rok]

Upravit to bohužel nejde. Je to stará věc. Uvažujeme o novém systému, ale zatím je to jen v plánu. Aplikace umí ještě vygenerovat okno s novou zprávou přes výchozí poštovní program, ale to je při tomto počtu nepoužitelné.

[jiwopene]

… přes výchozí poštovní program, …

Máte na mysli sendmail, nebo GUI aplikaci?

[jan.rok]

GUI aplikaci

[jan.rok]

Otvírá spojení souběžně, nebo po odeslání zprávy otrvře další?

Pokud platí druhá možnost, šel by vytvořit tento server:

ncat -klp2525 -c 'sleep 5; ncat provider-hostname.cz 25'

2525 je port, kde tento server poslouchá, 25 a provider-hostname.cz je adresa providera. ncat je zpravidla buď ve stejnojmenném balíku, nebo v balíku nmap.

Server výše po otevření spojení počká pět sekund a až potom začne komunikovat s protistranou. Nebylo otestováno.

[jiwopene]

A se SSL/TLS by to mělo fungovat také.

Pokud by si klient stěžoval na to, že server těch pět sekund neodpovídá, možná by šlo přesunout čekání na konec spojení a zapnout --no-shutdown, popř. něco sofistikovanějšího – pustit ze serveru jeden řádek, počkat 5 sekund a potom plně otyevřít spojení.

ncat má také volbu -d, která nastavuje čas mezi odeslanými řádky.

[jan.rok]

Paráda, řídit to otevíráním/zavíráním portu, by mě tedy nenapadlo.

To by mohlo fungovat. Díky.

[jiwopene]

Nejde o otevírání a zavírání, ale o přidanou latenci na začátku spojení, tj. před odesláním prvního bajtu¹. ncat spouští obsluhu klientů paralelně (klasický nc/netcat, tedy alespoň ta implementace, kterou používám, začne obsluhovat další klienty až po uzavření spojení, ale neumí spustit skript²), takže to nebude fungovat, pokud tento server bude používat více klientů – čas mezi spojeními bude pro každého klienta těch 5 s. Volba -m ncatu umožnuje omezit počet klientů, ale to funguje tak, že jim odmítne spojení, což asi nechceme. Pokud by je to nechalo jen čekat, bylo by to asi lepší řešení.

---

¹ Po tom sleepu je rychlost spojení ± normální.

² Musím se podívat na to, co jsem si to vlastně nainstaloval. Implementace netcatu z busyboxu to umí, takže by šlo použít místo ncat jen nc, je-li to ten z busyboxu.

[Josef Kufner]

Mnohem lepší řešení by bylo spustit si lokálně vlastní SMTP server, který by aplikace používala k odeslání pošty a ten SMTP server by používal jako relay ten současný SMTP server u poskytovatele, ale aplikoval by omezování provozu. Tedy aplikace by nasypala 1500 mailů do fronty lokálnímu serveru a ten by to pomalu předával k poskytovateli. Tím, že se použije relay je konfigurace vlastního serveru velice snadná a bezproblémová.

Viz http://www.postfix.org/qmgr.8.html a default_destination_rate_delay.

[jiwopene]

To tazatel navrhoval a ptá se na jiné řešení. Se řešením plnohodnotným SMTP serverem souhlasím.

[jan.rok]

Ano, i tazatel se nakonec rozhodl řešit to vlastním SMTP serverem.

Přesto všem děkuji za názory.

[Filip Jirsák]

Tohle je originální způsob, jak o ty e-maily přijít…

Použijte normální poštovní server a v něm nakonfigurujte limit na množství odesílaných zpráv. Třeba v Postfixu je to smtp_transport_rate_delay.Poštovní server zprávy přijme, uloží je do fronty (kde zůstanou i když se server ukončí, restartuje se počítač nebo se e-mail nepodaří napoprvé odeslat) a pak je bude postupně z té fronty odesílat.

[Josef Kufner]

Existují služby na rozesílání hromadných e-mailů. Pokud by ti nestačilo prosté zdržování, tak jich můžeš využít. Oni to pak už za tebe pořeší.

Další možnost je pořídit si malou VPS, která ti bude dělat SMTP server. Vyžaduje to nějaké znalosti k nastavení, základ je sice primitivní, ale je tam dost blbostí okolo (minimálně SPF a DKIM).

Klidně takových VPS můžeš mít i více, aby se omezilo riziko blacklistů. Také můžeš používat několik různých poskytovatelů. Jen je potřeba si pohlídat SPF záznamy, aby tam byly všechny odchozí servery vyjmenované.

[Andrej]

Funguje to bez potíží, pokud vyberu několik málo uživatelů najednou. Ale v okamžiku, kdy vyberu všechny (cca 1800 mailů), dojde k tomu, že aplikace maily vygeneruje, pošle ven na port 25, což způsobí zablokování odesílání ze strany providera. Ten si hlídá SMTP provoz a omezuje odesílání na tuším max. 5 mailů/s - chrání se tím proti tomu, aby se nedostal na blacklisty.

Pak je potřeba se s poskytovatelem náležitě domluvit, protože pouze a jedině tam je příčina problému, kterou je třeba odstranit, nikoliv obcházet. Samozřejmě je klíčové zavést DKIM, ADSP a všechno kolem toho — tak, aby měl mail server (přinejmenším!) v testech na internet.nl 100% skóre. S takovým základním rozumným nastavením pak není důvod dostat se na nějaký blacklist a poskytovatel by si měl přestat hrát na Severní Koreu.

Jestli poskytovatel tvrdí, že by se mohl dostat (celý poskytovatel) na blacklist, pak všeho všudy kecá a vymlouvá se. Na blacklist se dostane tak maximálně /48 rozsah jednoho konkrétního uživatele (případně jedna „veřejná“ IPv4 adresa, pokud ještě někdo takový zastaralý nesmysl používá). Poskytovatele jako celku a jeho ostatních zákazníků se to bude týkat pramálo.

[mmcze]

Ehm, ne.. Jsou i blacklisty, ktere jsou schopne listovat celou /22

[Andrej]

Ehm, ne.

Protože koncoví uživatelé mají /48 a poskytovatelé mají obvykle /32, neexistuje žádný rozumný blacklist, který by listoval /22. To by mohl omylem zakázat opravdu podstatnou část internetu, kdyby se takhle trefil do nějakého většího hostingu.

Pokud by snad existoval blacklist, který by zakazoval rovnou celé /22, tedy pouze 6 bitů nad obvyklým obrovským /16 prefixem typu 2a02::/, každý rozumný provozovatel mail serveru by takový blacklist jistě ignoroval. Pokud ne, je to jeho problém; takovými peer servery nemá smysl se dál zabývat.

[vencour]

Pokud jste něco neviděl, neznamená to, že to neexistuje.
Mimochodem někdo se baví o poště, někoho napadne i něco jiného, třeba více monopolního, kde se řeší "security" (ať je to co je to) nebo v principu "qos" (poskytování zdrojů).
Dále: někdo se baví o IPv4,někdo o IPv6. A co, že?

[trekker.dk]

Tohle neřešte. "Andrej" žije v iluzi, že koncoví uživatelé mají jako běžnou věc nějaké IPv6 a /48 rozsah k tomu. S realitou se zdvořile obcházejí.

[dnes 13:04 mmcze]

Bavím se o ipv4.

Shodou okolností pro jeden "větší hosting" dělám.. A to, jak ty vidíš svět, zákazníky co to nějakým způsobem ovlivní, vůbec nezajímá, ty jeden "je to jeho problém".

[vencour]

Dík za diskusi.
Na linuxu mi to už uš šlape. Musel jsem dát "-C" pro CRLF. Windowsy ještě ladím.