Fórumok
Sziasztok,
leveleket kellene küldenünk a partnereinknek, van egy szerverünk a hetznernél, postfix dovecot. amúgy a nonprofitbiztosito.hu oldalról lenne szó.
nagyon sokszor spam-ben landolunk sajnos, pedig nem küldünk mennyiséget, a szerződéssel kapcsolatban küldözgetünk csak leveleket. a kérdés annyi lenne, hogy a szerver konfiggal nézünk-e el valamit, vagy az a gond, hogy külföldön van a szerver (citromail.hu pl.. hagyjuk is)?
szóval mi lenne a jó irány? a mostani szerver beállítása sánta és azon kellene javítani, vagy hozzuk legalább a levelezés részét magyarországra? van olyan szolgáltató magyarországon, aki levélküldésre van ráállva? alapvetően a cél az volna, hogy nagyobb arányban érjenek célba a leveleink..
köszi,
G
Hozzászólások
Valoszinuleg a konfigban nem stimmel valami (SPF, DMARC hiana is effele gond), maga a szolgaltato kevesbe ad elsore okot (nekem is vannak naluk szervereim), esetleg a konkret IP lehet problemas, ha korabban spammer hasznalta (rosszabb esetben a teljes subnet-et blokkoltak). De a konfiggal kezdenek, vannak erre online tool-ok is, nezz ra, gyorsan kikopik a fobb bajokat (pl. mxtoolbox, mail-tester, hogy csak parat emlitsek).
Spamhaus, MXToolBox szerint nincs DBL listán, valószínűleg konfig lesz a ludas, vagy DNS-ben pl. SPF, TXT rekord.
lol
https://mxtoolbox.com/domain/nonprofitbiztosito.hu/?source=findmonitors
a balcklistig a legtobb spamszuron el se jutnak a leveleid, mar a DMARC hianya miatt landol a Junk mappaba, mondjuk nalunk emiatt akar torolheti is ha nem a megadott ip tartomanyokbol jon vagy a felado nincs a listan
Hello,
A hetznernél szokott olyan lenni, hogy egyes szolgáltatók az egész géptermet banra rakják, mi is szivtunk vele.
A megoldás a postmark.com lett, havi 10.000 levél 10$ az összes külsős levelezésünk rajtuk keresztül fut.
Ezen felül van egy domain@gmail.com -os fiók, hogy pár nagyon macerás gmailes fióknak ezen keresztül küldünk.
Az elmúlt 3 hónapban amióta átálltunk nem jött vissza panasz, hogy ügyfelek nem kapják meg a levelet.
A postmarkot érdemes nézni, mert ha sok a spam panasz hamar felfüggesztik a fiókot.
---...---
TLoF
https://www.mail-tester.com
Ez is segíthet.
Ez mit mond?
https://mxtoolbox.com/deliverability
Mokas, hogy minden emlitett dolgot leirtam egy kommentben, de az valamiert nem eleg jo. :D
Bevallom, amikor email troubleshooting kapcsán születik egy fórumtéma, amiben a kérdező még a headereket sem másolja be, akkor további olvasás helyett automatikusan rá szoktam kérdezni a headerre és/vagy mxtoolbox deliverability reportra. :)
Nem gond, most eppen tenyleg jot mosolyogtam, ertheto a te allaspontod is. :)
Kérdés ami nem merült fel még. Itthoni szolgáltatóval próbáltátok ezt a levélküldés dolgot ? Ha igen, mi lett az eredmény ?
Mivel a domain adott *biztosito.hu* milyen tartalommal küldtök emaileket ? Ezt is érdemes megvizsgálni, mert lehet simán n+1 biztosítói ajánlatnak nézi és jelöli spamnek a címzett rendszere, bayes, egyéb kritériumok alapján. Nálunk a szerver a biztosítós emaileket kb. szinte mindig megjelöli egy *spam* -el kivétel nélkül (már email tartalom alapján).
A többi check meg adott amiket előttem is írtak ^^
Jelenleg az email konfiguráció már-már önálló szakmává növi ki magát, mert annyi mindenre kell figyelni.
Ha napi 2000-2500 levélnél kevesebbről van szó, akkor érdemes átállni Google/Microsoft SMTP relay használatára és akkor nem kell szopni sokat. Ha ennél több levélről van szó, akkor az szopás, de sokat segít például a DMARC bekapcsolása és a forensic információk használata, akár kézzel feldolgozva, havonta akár egy jó kávé áráért például itt: https://easydmarc.com/
https://iotguru.cloud
Röviden: Akkor nem jól van beállítva valami.
Hosszan: Mail szervert jól összerakni nem egyszerű. Ma már baromi komplex és sok dolog kell egy jó mail szerverhez.
"Sose a gép a hülye."
reverse dns?
[Szerk:] De jó irány lehet az is, hogy megkérdezed egy olyan szolgáltató adminjkát, ahol spam-be kerültél, hogy miért. Ha megmondja beljebb vagy.
"A megoldásra kell koncentrálni nem a problémára."
köszönöm szépen mindenkinek a választ!
a beálíltásokkal még lehet előrébb lépni:
https://mxtoolbox.com/deliverability/6bb9a2aa-5f16-405e-83b5-497bf8969f7b
én csak egy mezei fejlesztő vagyok, de futok egy kört a rendszergazdánkkal.
köszi,
G
ha nem jutunk előrébb, akkor postmark
Kíváncsiságból megnéztem:
$ dig mx nonprofitbiztosito.hu +short10 mail.nonprofitbiztosito.hu.
$ dig a mail.nonprofitbiztosito.hu +short
88.99.85.52
$ dig -x 88.99.85.52 +short
static.52.85.99.88.clients.your-server.de.
Ezért is járnak spam pontok... ;)
"A megoldásra kell koncentrálni nem a problémára."
Ezért nem spam pont, dev/null jár.
Azért dev/null csak ne járjon már egy létező reverse címre, ez nem dinamikus IP pool. Szebb lenne nyilván, ha egyedi reverse van beállítva, de technikailag nem különb ez, mintha sajátot állítasz be.
Megnéztem a tegnapi napot, 5104 bejövő levélből 5003 elvérzett azon, hogy nem egyezik meg a reverse DNS azzal, amivel jött, ezeket el is dobtam olvasatlanul, a maradék 101 levél ment spam szűrésre, amiből összesen 14 élte túl a szűrőt és ebből a 14 levélből 10 ment a "Spam" mappába, 4 került végül az "Inbox" mappába.
https://iotguru.cloud
En megengedobb vagyok, megelegszek, ha a reverse ugyanabban a domainben van, mint a bemutatkozo hostnev. From various reasons. Ultem mar a masik oldalon is.
Blog | @hron84
via @snq-
Attól még a fogadó szerverek döntő többségében ez így van és van is némi alapja.
A helyzet az, hogy a spammerbucik ellen mindent is be kell vetni, különös tekintettel az igénytelenségre. Szerintem könnyen belátható, hogy egy relatív egyszerű levelező hosztnév helo/ptr beállítása/mondása, és persze a hosztnév feloldhatósága nem egy nagy feladat 2020-ban, de 2015-ben sem volt nehéz. Őszintén szólva aki ezt nem ugorja meg, és mondjuk egy alap SPF rekordot még, annak nem biztos, hogy kéne leveleznie.
Spamszűrésnél már nem a technikai kunszt számít, hanem hogy állítsa be igényesen, egyszerűen máshogy nem tudod feljebb tenni a lécet. Példul egy partnerünk kis forgalmú néhány domaines levelező szerverén múlt vasárnap másodpercenként 5-6 rejectvolt ilyesmikből kifolyólag. Alapból egy 0,3-0,5/mp.
Rendes reverse DNS, SPF rekord, mukodo DKIM illetve rendes cert az smtp szerveren TLS-hez alapkovetelmeny manapsag.
Ha ezek megvannak es meg mindig spamnak neznek akkor lehet tovabb debuggolni, de a legtobb helyre ennyi eleg szokott lenni.
Akkor szedjük tételesen össze, mi kell ahhoz, hogy szóbaálljon velünk a túloldal és a reputációnk se a béka segge alatt legyen:
- DNS A rekord
- valid PTR rekord
- SPF
- DKIM
- ADSP
- DMARC
- DANE
- MTA-STS
- TLS Reporting
- valid tanúsítvány
- TLSv1.2+
- erős cipher-ek
Ha csak A rekordod van technikailag elég lenne, de vannak már, akik elhajtanak, ha nincs MX külön.
van, aki még nem?
pl én sem mert semmi összefüggés nincs a két dolog között.
Ez hulyeseg. az MX az, ami technikailag eleg, az A az csak fallback. Legyszi, legalabb a szabvanyokat olvasd el, koszi.
Blog | @hron84
via @snq-
azert az elso 4 eleg szokott lenni (+TLS), felteve persze hogy az MX, A, PTR es HELO-nev osszhangban vannak.
Nem elég. Olyan elmebeteg beállításokkal lehet találkozni, hogy a hajam leteszem.
Meg legalább két dologról beszélünk: 1) egyáltalán bemenjen a mail 2) minél kisebb spam score-t kapjon mire eljut a mailboxig.
hat en meg nem lattam spamszurot ami a tls/cipher dolgokat figyelembe vette volna.
egyaltalan ha a gmail nem jonne a piros lakatjaval akkor nem is kene smtp-hez tls...
"Meg legalább két dologról beszélünk: 1) egyáltalán bemenjen a mail". Simán szokás már TLSv1.2 és high cipher alatt eldobni a kapcsolatot. És akkor ez még nem is igazi spam szűrés.
Akkor mi lenne helyette?
Még 1 tétel:
- ha hírlevél, akkor unsubscribe link a mail body-ba, mert az okosabb szűrők felismerik a hírlevelet és csúnyán lepontozzák az unsubscribe lehetőség hiányát
és milyen jól is teszik. az másik kérdés, hogy az unsub link általában gyakorlatilag sub egy csomó további szemétre :)
Tapasztalatom szerint nem annyira. Volt mar, hogy - reszben - a feladatom volt unsub linkeket nyomkodni, es egyre kevesebb mail jott. Vannak idiotak, de szerencsere ok vannak kevesebben.
Blog | @hron84
via @snq-
http://flurdy.com/docs/postfix/
Ez egy folyamatosan frissített, jó és részletes howto.
Régen láttam ilyen szépen összeszedett doksit. Ráadásul ez az összeállítás, amit kb. mi is használunk. Annyi, hogy mivel frontend jó ha van a DB abuzgálásához, ISPConfig-ot rakunk és azt customizáljuk.
"Sose a gép a hülye."
Mi a retkemnek egy postfix abuzalasahoz egy komplett ISPConfig? A PostfixAdmin miert nem eleg jo?
A valaszokat "Szeretnek eljutni a Holdra, epitenek egy csillagrombolot" jeligere kerjuk a kiadoba.
Blog | @hron84
via @snq-
lehet, hogy "IT konzultans / tanacsado" ceg-nel dolgozik es szakmai artalom :).
Három csillagromboló és két halálcsillag nélkül nem lehet lejutni a bolygóra ezt lássa be..
tényleg nem rossz