Még mindig nem érted.
Tegyük fel én üzemeltetem a hosztabc.hu oldalt, ami legyen egy jól konfigurált, biztonságos tárhely szolgáltató.
Így természetesen SPF rekordot és authentikált email küldést alkalmaz minden domainre.
Te veszekedni kezdesz az ügyintézővel, hogy miért kérik hogy a hrgy84@tedomained.hu email címről küldj egy megrendelést az info@hosztabc.hu címre, hogy de hát te küldeni tudsz akárki nevében levelet.
De nincsen igazad. Megpróbálsz tegyük fel küldeni egy levelet info@hosztabc.hu feladóval nekünk. Mivel authentikált a küldés, én azonnal eldobom az üzenetet. Tegyük fel ezt más levelező szerverről próbálod meg (akár sajátról), akkor is eldobom, mert nincs az IP címed a megengedett tartományban, ami az SPF rekordban szerepel.
Ha ugyanígy megpróbálod ezt egy Gmail, Yahoo, Hotmail.. címre küldeni, ott vagy azonnal eldobódik vagy megjelenik egy figyelmeztetés (Gmail-ban például felül sárga sáv), hogy a figyelem a feladó valószínűleg hamis.
És ma már nagyon sok email szerver figyelembe veszi ezt. Most nem "Kispista és társa Bt" 16 éves rendszergarázdájának a torrentezett Windows email szerverére gondolok, hanem nagy cégekre.
Ja és az a legjobb az egészben, hogy aki ebbe beszáll az védett lesz innentől. Tehát nem úgy van, hogy ha csak mindenki alkalmazza, akkor ér valamit. Ha te alkalmazod, onnantól neked nem kell attól tartanod, hogy saját hamisított címről neked tudnak küldeni levelet. Ha pedig valaki más (nem a te adminisztrációs tartományodban lévő) kap a te címedről hamis levelet, akkor az csakis az ő, illetve szolgáltatójának a hibája. A szolgáltatóé, mert nem vette figyelembe az SPF rekordot és az övé mert egy megbízhatatlan szolgáltatót választott.
Szerk:
Persze amit az SMTP-ről írsz az jó, csak már régen nem erről szól a dolog. Én írtam SMTP és POP3 szervert is, ismerem a protokollokat, de most nem ezekről az RFC-kről van szó, hanem kiegészítő technikákról, amelyek az ezredforduló után jelentek meg. Az SPF pedig csak egy a sok közül..
Kb olyan ez mintha azt mondaná valaki, hogy a SIP nem NAT-oltható. Eredetileg valóban voltak problémák, de azóta olyan technikák jöttek be (például STUN), amelyekkel simán üzemeltethető NAT mögött is kliens. Vagy például aktív FTP. Felelőtlenül azt állíthatná egy szakember, aki sok-sok éve tanulta a protokollt, hogy tűzfal mögött úgysem megy. Csakhogy ma már a legtöbb otthoni filléres routernek is van olyan helper funkciója, ami megnyitja az adott adat portot.