ezzel csak akkor van gond, ha a felado szervere is hasznal greylistet:
SMTP protokol előírja, hogy a címzetttől érkező bounce -ot fogadni kell, ha ezt megfogja a greylist akkor nem működik jól, ha pedig még is megfogja, akkor majd X perc után átengedi a legtöbb greylist sajnos csak annyit csinál, hogy az első próbálkozást eldobja, viszont én QUEUE -ba állítom és most jelenleg 5x alkalommal tesz kisérletet az ellenőrzésre kb. 10 percenként, de ha nem is tud kapcsolódni az SMTP -re vagy a feladót nem tudja ellenőrízni sem feltétlenül dobja el a levelet, sőt nem is minden esetben megy el odáig a rendszer, hogy visszaellenőrízze a feladót van amikor megelégszik azzal, hogy az MX rendben, SMTP létezik, PTR rendben, SOA rendben az algoritmus az nem machine learning alapú, de valamilyen szinten tud tanulni.
hiaba kuldod te ki baromi gyorsan meg parhuzamosan a DNS es RBL kereseket:
LIBLDNS beágyazva, így a timeout nem rendszer szinten van, különben az /etc/resolv.conf -ba állítható a retry és a timeout, (rendszer szinten) nagyon hasznos tud lenni.
Én is szívtam nagyon sokat, sőt a DNS Kliens pont ezért került bele a C++ frameworkbe.
Ha használsz CACHE -t akkor kb 1-3 parallel ellenőrzésre van szükség realtime, jelenleg 57.920 SMTP host van a DB -ben, amiből 14049 ami megfelelt és ez a szomorú, nem jó már ez az SMTP protocol ideje lenne, már újítani rajta, mert csak a taknyolása folyik.
Ez ilyen 3 másodperc alatt leszokott futni kb 15-20 listán, és lehetne hova optimalizálni, pl: nem futtatom végíg az rbl_lookup funkciót és ott is kibreakelek ha kapás van, egy időben használtam DNSCACHE -t is.
/** RBL_CHECK **/
local ht = htime();
foreach(k2,rbl in rbls)
{
local tmp = netTools.rbl_lookup(row["ip"],rbl["domain"],Config["core"]["dns_ip"]);
if(tmp["listed"])
{
listed = tmp["message"];
break;
}
}
local rbl_listed = "0";
if(listed.len() > 0)
{
rbl_listed = "1";
}
/** RBL_CHECK **/
/** RBL_LOOKUP **/
function rbl_lookup(ip,list,ns_ip)
{
local dns = DNS();
dns.set_nameserver(ns_ip);
local debug = {};
local ret = {};
ip = host2ip(ip);
debug["original_ip"] <- ip;
if(Utils.strstr(ip,":"))
{
ip = expand_ipv6(ip);
debug["ip"] <- ip;
}
else
{
debug["ip"] <- ip;
}
debug["reverse"] <- rbl_reverse(ip);
debug["query"] <- debug["reverse"] + "." + list;
debug["result_a"] <- dns.get_a(debug["query"]);
debug["result_txt"] <- dns.get_txt(debug["query"]);
if("error" in debug["result_a"])
{
ret["listed"] <- false;
}
else
{
ret["listed"] <- true;
}
ret["message"] <- "";
foreach(k,v in debug["result_txt"])
{
ret["message"] <- k;
break;
}
ret["debug"] <- debug;
return ret;
}
/** RBL_LOOKUP **/spammek 99.9%-at meg biztos nem fogod meg igy, mert az utobbi evekben egyre jellemzobb az, hogy adathalaszattal ellopott valos email fiokokbol kuldik a virust vagy spammet:
Valóban előfordul kb. havonta pár alkalommal, hogy "Tudunk utalni levelet" kapnak egyesek, ha ezt megnézem az eldobott és a megjelölt levelekkel akkor benne van a .01 -ben, az elmúlt 72 órában 18,000 levélből csak 5.000 -et fogadott el (kerekítéssel) én személy szerint egyáltalán nem kapok SPAM -et a beérkező mappába pedig mindenhol kint az email címem viszont valóban hazudtam, mert a 99.9% úgy igaz, hogy AMAVISD -al együtt én ezt akkor is nagyon jó teljesítménynek könyvelem el, arról nem beszélve, hogy jelentős terhelést levesz a szerverről és mindenki nagyon meg van vele elégedve.
2019 első negyedévében annyi SPAM érkezett be, hogy már mindenki felsírt és azonnali megoldást akart és pont az ilyen feltört accountok végett, szóval eléggé ideg voltam míg végül kikisérleteztem ezt és egy kis bónusz: azóta egyszer sem került semelyik szerver spamlistára, így eléggé megtérült a belefektett idő és életet mentett.