Email küldés programozói szemmel

Gyakran belefutok abba a problémába, hogy hogyan lenne jó kezelni az automatikus emailokat. Lásd regisztráció, jelszó visszaállítas.

Lássuk a szereplőket:

  • Programozó: Bizonyos események bekövetkeztekor küldenem kell értesítéseket.
  • Designer, marketing, stb. :  Megálmodják az email kinézetét és tartalmát.
  • Frontendes: (opcionális) Lekódolja az email kinézetét pixelpontosan. Ő kihagyható mert igazából a Designer/Marketinges össze tudja kattingatni WP/Elementor /Divi megoldásokhoz hasonló szerkesztőben. Imadnák az ilyent, hiszen fejléc és lábléc komponensként beilleszthető lenne . 

Ti találkoztatok ezzel a probléma a körrel? Hogy van nálatok megoldva? 

Pár megoldást már megvizsgáltam:

Email szolgáltató (Sparkpost és hasonlók) tudnak templatet, de komponens alapú nem igazán van.

Self-host részén pl a listmonk szimpatikus projekt. Van transaction(sima email küldő) api, de talán jövőben lesz komolyabb szerkesztő benne.

Ismerősőm magának kódolta le, de nyilván egy kész megoldás mindig jobb. 

Az hogy a kódban van a templateket, elég körülményes. Egy idő után rengeteg időt elvesz az hogy ezeket a templateket gyakran át kell írni. Nem mindig könnyű előcsalni a a küldöző leveleket sem. Mondjuk ez a programozó bénasága. Azt is mondjuk, hogy valamikor másnak a kódján kell dolgozni. 😀 

( zeller | 2025. 05. 31., szo – 13:37 )

Programozói szemmel nem ez a küldés, hanem az, hogy hova (cím, port), milyen módon kell kapcsolódni, milyen authentikáció, starttls, stb. van, a MTA milyen mértékben követeli meg a szabványos működést, illetve hogy az MTA válaszait hogyan, milyen módon naplózza(!) a küldő alkalmazás, mikor tekintse sikeresnek/átmenetileg vagy végleg sikertelennek a levél feladását, és ezeket hogyan, miként kezelje. 
Az, hogy a "DATA" után mit tol át az alkalmazás az MTA-nak, mint a levél törzse, az programozói szempontból sokadrangú, mondhatni irreleváns kérdés. Szerintem... 
Azon pörögjön a marketing meg az összes hasonló társulat... (Ja, és mivel a levél megjelenítése a kliensre van bízva, a "pixel pontosan" faßßág 100%-ban kihagyható a dologból. Minél egyszerűbb a template, amibe csak be kell sed-del rakni a dolgokat :-) annál jobb...

A küldés alapszintű megoldása a hibás küldés esetén, queueba helyezésén keresztül, a visszapattanó levelek kezeléséig már rég meg van oldva, méghozzá olyan megoldásokkal amit nagyon sokan Implementáltek már. szóval meghízhatóan működik. Ilyen alap dolgokkal nem kell foglalkozzak. Architekturális kérdések vannak. Template csak adig érdkel amíg nem ki nem sikerül szolgálnom az igényeket. Igény az hogy backendesnek a válláról levegyük az emeail templatezést.

>  Ilyen alap dolgokkal nem kell foglalkozzak

Óriási tévedés. Mert amikor nem megy a küldés, akkor jól jönne, hogy érted, mit csinál a szoftver a háttérben. Meg se tudom számolni, hány "nem küldi ki a levelet a alkalmazás" című ticketnél jött volna jól a kérdezőnek, ha utána megy, hogy hogyan is működik elvi síkon a levélküldés. Frameworköt használni fun, de ettől még tessen csak foglalkozni az alapokkal. Van olyan framework pl ami nem tud STARTTLS authentikációt, csak TLS-t. Ha ez élesítés közben derül ki, az szopó.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Frameworköt használni fun, de ettől még tessen csak foglalkozni az alapokkal.

Attól mentsen meg a Jóisten, hogy a fejlesztők a levelezés alapjaival foglalkozzanak.

Ha el akarod kerülni a szopást, akkor a fejlesztőknek ennyit kell tudniuk az emailezésről:

DATA=$(cat << EOM
{"personalizations":[{"to":[{"email":"hrgy@hup.hu","name":"Hrgy User"}],
"subject":"Hello"}],
"content": [{"type": "text/plain", "value": "IDE KELL ÍRNI AZ EMAILT"}]
)

curl --request POST \
--url https://api.sendgrid.com/vagy/valami/másik/service/akár/házon/belül/nem/muszáj/cloud \
--header 'Authorization: Bearer IDE KELL ÍRNI AZ API KEY-T' \
--data $DATA

Ezzel nem értek egyet. Igenis tudja meg a fejlesztő, mekkora plusz feladatok vannak még. A fejlesztés részeként kezelni kell a subscribe/unsubscribe eventeket, a soft/hard bounce kezelését, visszacsatolás kell a backend irányba, stb.  Adott esetben a levelet a küldesi folyamat teljes logolasa mellett tárolni is kell.

Error: nmcli terminated by signal Félbeszakítás (2)

Itt nem érzem az ellentmondás, pont a felsoroltak miatt tűnik rossz ötletnek annyival letudni az emailezést, hogy itt van egy SMTP szerver, lövöldözz vele a vakvilágba. Az eredeti állítások olyasmik voltak, hogy a programozónak csak azt kell tudnia, hogy SSL van-e, meg hogy milyen porton kell csatlakozni, aztán jól lesz az úgy.

A levelkuldo szolgaltatast is fejlesztok keszitettek, de persze ertem a dolgot. :)

Szerintem elsosorban uzleti szempont, hogy mi a jobb: szolgaltatasert fizetni, vagy hazon belul (esetleg kulsosokkel) lefejlesztetni. Utobbi esetben lehet szolgaltataskent is arulni. De ez ugyanugy igaz arra is, hogy erdemes-e szolgaltataskent irodahazat berelni portassal-takaritokkal, vagy venni, es uzemeltetni. Esetleg nyomtatokat veszel, es gondoskodsz a papirrol meg a tonerekrol, vagy megrendeled valakitol, aki csereli a patront, ha kifogy. Cegmerettol is fugg, meg hogy milyen teruleten mozognak: egy softwarefejleszto ceg elobb fogja megirni maganak, mint egy marketinges.

A strange game. The only winning move is not to play. How about a nice game of chess?

( Carter | 2025. 05. 31., szo – 13:49 )

Ez a pixelpontosan érdekes. Bő évtizede nincs már ilyen elvárás. Az új elvárás: jelenjen meg a modern telefonkijelzőkön olvashatóan. Következménye: régebbi (5 éves) telefonokon az összes rosszul jelenik meg :)

( wladek1 | 2025. 05. 31., szo – 14:50 )

Szerkesztve: 2025. 05. 31., szo – 14:53

0) lépés: minden frontend/backend tema lenyegtelen annak fenyeben, hogy plaintext -ben is be kell adagolnod az email-be ugyanazt. (zeller kollega problemaja is eltunik ezzel, tovabba szvsz gusztustalan is ennek a kihagyasa, illetve pl a KLMS konkretan delay -t ad a nem megfeleloen osszetakolt levelekre.)
1) Használj valami vízüveg-szerkesztőt, a header/footer adott (a képeket emellett beágyazzuk az e-mailbe, nem külső forrásból rángatjuk be) A valid HTML hasznalata kritikus pont, minden a levelben direkt megjelenitett dolog (stylesheet, img, stb a levelben szerepeljen - pl a css a html -be agyazva)
2) ...szhatod, ha a nem tartod be az itt foglaltakat, a tartalom is kulon fontos. Mar a nem konzekvens domainmegjelenites a linkekben is minusz pontokat jelent pl az SA -nak.

Error: nmcli terminated by signal Félbeszakítás (2)

A mutt-ot meg a mailx-et csak poénnak szántam :-) de igen, ha csak html van a  levélben, az nagyon nem jó - sok esetben azt is lefelé pontozzák az ilyen alapon működő szűrők.
Ha van "Must have" kifelé mutató linkek a levélben, azok ne egyszer használatos, ne url-rövidítős dolgok legyenek, és akkor is működjenek, ha egy 3rd party content proxy-n keresztül látogatja meg a címzett (mert például a t..dm..o átírja a levélben a linket úgy, hogy "magára irányítja", és az eredeti link csak paraméterként kerül az így összeállt URL-be)
 

( realkry | 2025. 06. 01., v – 07:05 )

Az egyetlen üdvözítő megoldás a külső, erre szakosodott eszközt használni:

- az eszközben a dizájner, marketinges, oldal tulajdonsa kitalálja a szövegezést, kinézetet és ezt megvalósítja. Ebben nekik az eszközt készítő nyújt támogatást.

- a programozó a megfelelő esemény bekövetkeztekor meghívja az eszköz megfelelő végpontját és átadja az eseményre jellemző változó paramétereket, a választ logolja.

Minden a levéllel kapcsolatos nyűg, kinézet, blacklist, új szövegezés, stb az eszközt biztosító feladata.

win-win

Aztán meg jön az, hogy a delivery rate 99,7 % alá kerül ami miatt a szolgáltató lerug, és mindenki néz, mint hal a szatyorban, mert szerinte az elég, hogy ratestalsz -szerinted- mindent a szolgáltatóra, de nem kezeled le az emailekkel kapcsolatos notifikációkat. Lásd fentebb.

Error: nmcli terminated by signal Félbeszakítás (2)

( YleGreg | 2025. 06. 06., p – 16:40 )

Pár éve csináltam egy ilyet. Akkor abba futottam bele, hogy teszteléskor kiderült, a szolgáltatónál volt egy limit a levélküldésre, így amikor a 300 körüli tesztelő (önkéntesek, ez egy e-sport verseny honlapja volt) kvázi egyszerre nyomott a regisztrációra, a levelek nagy része SMTP hibával tért vissza.

Átírtam, hogy a levelek egy queue -ba menjenek, ami a rate limit betartásával ürült csak. Az éles induláskor több ezer regiszrációt kellett kiszolgálni nagyon rövid idő alatt, engem nagyon meglepett, hogy ekkora nyüzsi van ebben a scénában. Na, ha valaki frameworkkel rakja össze a levél küldést, akkor sok sikert az efféle problémák megoldásához. Ha tudja a framework, akkor jó, de nem tudja, akkor csúnya bazmegolás lesz az első perf teszt után, mert ez csak akkor jön ki.

Nekem az volt a mázlim, hogy jó programozó vagyok, viszont rossz szoftverfejlesztő, mert a feladathoz nem a legújabb, legjobban hypeolt keretrendszerrel álltam neki, hogy időt spóroljak. Hanem a jó öreg php+html+js kombóval dolgoztam, így a levél küldés minden bitje a kezemben volt, vagyis nem kellett koncepciót váltani, csak be kellett rakni egy aszinkron réteget a levél állomány elkészítése és a kiküldése közé. Néha jó az öreg a háznál. :-)

Mármint itt a framework alatt szerintem leginkább szolgáltatást ért az ember, olyankor nem a te szolgáltató által mezei userekre hangolt smtp szerver van, azt az egészet ők üzemeltetik, nyilván úgy, hogy bulk küldésre vannak berendezkedve, ehhez a részéhez neked nincs közöd.