ez egy kiegészítés, vagyis nem bírálja felül az előtte lévő RFC-ket.
Ja, valoban furcsa pl. ez a mondat: "It consolidates, updates and clarifies, but does not add new or change existing functionality of the following". Kerdes az, hogy a 2 ujabb RFC 5. pontban szereplo leirasa funkcionalitast modosit (vagy ujat hoz be), avagy inkabb pontosit?
Az általad említett végső pont pedig az, hogy egy SMTP kliensnek egyébként nincs hatályos joga
FYI: smtp kliens az, aki egy smtp szerver szolgaltatasait veszi igenybe, tehat akar egy masik smtp szerver is lehet, mint pl. jelen esetben. Aztan kivancsi vagyok, hogy ha egy tavoli gep megszolit a 25-os porton, akkor megis mi alapjan mondod meg, hogy o kozvetlen levelkezbesitessel probalkozik ...
Pont az ilyen szarul beállított levelezőszerverek és domainek miatt van annyi spam, amennyi.
Az valoban igaz, hogy a rosszul beallitott dolgok miatt tobb a spam, de nezzuk meg, hogy ez a citromailes benazas vajon tenyleg csokkenti-e? Ha lattal mar spoof-olt levelet, aminek valodi, pl. @gmail-es, @freemail-es, stb. envelope-pal kuldte el a levelet, akkor te is belathatod, hogy ez az MX rekordhoz valo irracionalis ragaszkodas semennyivel nem csokkenti a spamek szamat, hiszen pl. a @gmail.com-nak van MX-e, vagy a spoof-olt domainnek szinten van MX rekordja (meg az enyemnek is). Fals pozitiv hibat viszont okoz. Ha nalad ez a 'komolyan veves', akkor reszvetem...
Szoval az allaspontom tovabbra is az, hogy nem RFC kompatibilis arra rafogni egy level elutasitasat, hogy a felado domainnevnek nincs MX rekordja, ha van A. Arrol nem is beszelve, hogy a citromail kifogasa sem RFC-sertesrol szol (mert nem is szolhat arrol), hanem valami homalyos antispam torekvesrol, ami inkabb ugyetlen, mintsem hatekony...