debian 9 frissites utan exim smtp_ratelimit_rcpt hiba

Fórumok

ha valaki frissitett tegnap es hasznalja eximben az smtp_ratelimit_rcpt-t az biztos tapasztalta hogy max. annyi cimzettel fogadja be a levelet amennyi a threshold-ban meg van adva, tobb cimzett eseten megszakad a kapcsolat ratelimit helyett.

Install: linux-image-4.9.0-6-amd64:amd64 (4.9.82-1+deb9u2, automatic)
Upgrade: libquadmath0:amd64 (6.3.0-18, 6.3.0-18+deb9u1), gcc-6-base:amd64 (6.3.0-18, 6.3.0-18+deb9u1), libgcc1:amd64 (1:6.3.0-18, 1:6.3.0-18+deb9u1), libgfortran3:amd64 (6.3.0-18, 6.3.0-18+deb9u1), linux-image-amd64:amd64 (4.9+80+deb9u3, 4.9+80+deb9u4), libgomp1:amd64 (6.3.0-18, 6.3.0-18+deb9u1), libstdc++6:amd64 (6.3.0-18, 6.3.0-18+deb9u1)

nem a kernelben van a regresszio, kiprobaltam az elozovel.

workaroundkent ki kell kapcsolni a smtp_ratelimit_rcpt-t vagy feljebb venni a threshold-ot.

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_confi…

Hozzászólások

nem a kernelben van a regresszio, kiprobaltam az elozovel.

???? Mi koze a kernelnek egy mta smtp protokoll kezelesehez?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

"When a host matches smtp_ratelimit_hosts, the values of smtp_ratelimit_mail and smtp_ratelimit_rcpt are used to control the rate of acceptance of MAIL and RCPT commands in a single SMTP session, respectively."

A ratelimit a kapcsolat megszakítás, vagy legalábbis próbálja. A kernelnél jóval előremutatóbb lenne, ha az exim logba pillantanál bele. Az könnyen előfordulhat, hogy eddig működött rosszul és mostantól működik jól. A changelog mit mond?

Van egy recipients_max opció is, biztos nem azt szeretnéd?

"A threshold, before which there is no rate limiting.

An initial time delay. Unlike other times in Exim, numbers with decimal fractional parts are allowed here.

A factor by which to increase the delay each time.

A maximum value for the delay. This should normally be less than 5 minutes, because after that time, the client is liable to timeout the SMTP command."

a ratelimitet ezek alapjan en ugy tudom elkepzelni, hogy mielott valaszol a szerver az rcpt to parancsra, - a threshold utan - egyre tobb idot var, hogy lassitsa a klienst. ezzel nem serti a protokolt, ellenben a turelmetlenebb "kliensek" megszakithatjak a kapcsolatot. itt a turelmetlenebb kliensek alatt a spammereket ertem.
mondjuk ezt a parametert kb. 15 eve tettem bele, lehet hogy mar nem hasznal.

"A kernelnél jóval előremutatóbb lenne, ha az exim logba pillantanál bele"

latom valamiert raakadtatok erre a kernel temara, alapos vagyok, egyszerre frissultek, ezert azt sem hagyhattam figyelmen kivul. :)

az exim logban lattam hogy a kapcsolat megszakadt, es ez a cimzettek szamatol fuggott. mivel a frissites a retpoline miatt jott ki, ezert azt feltetelezem hogy regressziorol van szo.

"A changelog mit mond?"

gcc-6 (6.3.0-18+deb9u1) stretch-security; urgency=medium

* Backport of retpoline support by HJ Lu

"Van egy recipients_max opció is, biztos nem azt szeretnéd?"

ha esetleg vannak olyanok akik meg outlookbol oldjak meg az ugyfeleik ertesiteset oly modon hogy egyszere mindenkinek elkuldik a levelet, oket ezzel megakadalyoznam a munkajukban, ezert csak lassitom oket :)

--
neked aztan fura humorod van...

ezert csak lassitom oket :)

bastard operator from hell. Orom is lehet az ugyfelednek lenni, hogy szandekosan szivatod oket. Mondjuk az 1 levelbe 500 cimzettet belepakolo user is megeri a penzet. Azt mondanam, megerdemlitek egymast :-) Btw. nem lenne egyszerubb levlista szolgaltatast eladni nekik? Az valahogy mind muszakilag, mind uzletileg is korrektebb lenne...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...