Kauza html emaily (diskuse)

[#Tom]

Já bych HTML maily zrušil, kdo to smetí má furt mazat?

[stativ]

Já ne, dobře se tak odhalují spamy…

[R]

Co by sa dalo cakat od firmy, ktora pouziva najnovsi Exchange? Usmevne to posobi hlavne v spojeni s faktom, ze najnovsi Outlook ma podporu HTML uplne rozdrbanu.

[Luk]

Co na to říct? Tohle. Postmasterovská adresa dnes nefunguje leckomu, včetně velkých firem působících v oblasti internetových služeb. To by ještě nebylo nejhorší - mnohem horší je, že jejich odesílátka mnohdy neskutečným způsobem prasí zprávy, které pak Spamassassin zcela logicky ocení nějakým bodovým přídělem, protože spammeři si s dodržováním pravidel ve většině případů vůbec nelámou hlavu.

[Kvakor]

On je totiz casto postmaster u mailu, co poskytuji webhostingy, nastaveny jako administracni ucet pro e-mailove ucty, takze i kdyz existuje a neni zablokovany, vetsinou se nevybira.

[Luk]

To je samozřejmě chyba, zprávy z účtů tohoto typu by se rozhodně měly buď vybírat přímo nebo přesměrovávat někam, kde to někdo čte. Řeč je ale hlavně o firmách, jako je Seznam - tam se rozhodně nejedná o tuto situaci.

[sssssssss]

 Nemam s tim problem a nechapu proc nekdo jo.

[Filip Jirsák]

Bohuzial, Vami odoslane emaily nesplnaju nalezitosti, ktore musia splnat, aby boli prijate nasim mailserverom bez problemov.

Jen tak dál. Čím víc správců si stanový nějaká interní (a nejlépe tajná) pravidla pro příjem e-mailů, tím dříve se stane e-mail pro takovýto druh komunikace nepoužitelný. Třeba pak všichni tihle odesílatelé a příjemci, kteří si stanovují vlastní pravidla, přestanou e-mail používat, a ti ostatní ho zase budou moci používat jako e-mail, se všemi pravidly dle RFC.

[msk]

Jedna sa o defaultne nastavenie spamassasin v debian lenny. Tu je score:

2.9 BAD_ENC_HEADER         Message has bad MIME encoding in the header
0.0 HTML_MESSAGE           BODY: HTML included in message
1.7 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
0.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headers

Ja za to, ze je niekto prasa, nemozem. Co sa tyka RFC, tak pokial sa bavime o 821, to pojednava len o transportnej vrstve. Takze kludne tade mozem poslat domace porno encodovane do base64 telnetom a pokial dodrzim tych par pravidiel, tak to v pohode odoslem. A to, ze to prijemca neprecita, je smtp uplne fuk.

[pasmen]

Jedná se o RFC 2822, řekl bych.

[Filip Jirsák]

RFC 821 je už poněkud zastaralé, už pár let je nahrazeno RFC 2821. A pak také existuje RFC 2822 a RFC 2045 – 2049.

Já jsem ale měl na mysli především váš údiv „já jsem si tu stanovil pravidla a oni si je nezjistí a klidně je ignorují“.

[kavol]

ale "on" si ta pravidla nestanovil, ta pravidla jsou v RFCčkách, na která odkazuješ, to že je "on" nezná není až tak podstatné

[Filip Jirsák]

V kterém RFC je, že e-mail musí obsahovat i část Mime-Typem text/plain? Navíc autor píše pouze o nějakých pravidlech, která si sám stanovil – jak můžete vědět, že mezi těmi pravidly není třeba že odesílatel musí po celou dobu odesílání e-mailu poskakovat po jedné noze a bít se v prsa?

[Luk]

Co sa tyka RFC, tak pokial sa bavime o 821, to pojednava len o transportnej vrstve.

Ale máme také například RFC 2822, kde jsou pravidla pro vlastní zprávy (ať už se přenášejí pomocí SMTP nebo jinak). Tam je kupříkladu napsáno:

A date-time specification MUST be semantically valid. That is, the day-of-the-week (if included) MUST be the day implied by the date, the numeric day-of-month MUST be between 1 and the number of days allowed for the specified month (in the specified year), the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of seconds allowing for a leap second; see [STD12]), and the zone MUST be within the range -9959 through +9959.

Toto jsou zrovna pravidla, která bývají často porušována. Jinak se dá říct, že když se bavíme o zprávách a jejich vyhodnocování ve Spamassassinu, jde v první řadě o RFC 2822 (formát zpráv) a až následně o RFC 2821 (SMTP).

[CET]

Che, to by me fakt zajimalo, jakou prasarnu do toho MIME a Content-type cpe:)

[Nicky726]

A co takhle být rád, že mi nemůžou obchody cpát reklamu horem, dolem i mailem?

[Mmurphy]

Teď tedy úplně přesně nevím na co si autor článku stěžujě. Koukal jsem teď na zdroj jednoho informačního emailu právě z Alza a všechno je podle RFC v pořádku. V hlavičce je správně "MIME-Version: 1.0" a jsou tu dokonce i dvě části, jedna s "Content-Type: text/plain;" a druhá s "Content-Type: text/html;".

To by si taky třeba mohl začít stěžovat, že jsem tenhle komentář nenapsal v ASCII.

To že si někdo stanoví svá pravidla pro SPAM ještě neznamená, že zpráva je špatně.

[Luk]

To že si někdo stanoví svá pravidla pro SPAM ještě neznamená, že zpráva je špatně.

Jenže ony mnohdy ty zprávy špatně jsou. Například když mi chodily od Seznamu zprávy, na něž Amavis reagoval takto:

X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char F8 hex): Subject:
	Zat\370\355zen\355 z\341pisu v ...

a Spamassassin takto:

X-Spam-Status: Yes, score=5.11 tagged_above=2 required=5
	tests=[DNS_FROM_RFC_ABUSE=0.374, MSGID_FROM_MTA_ID=1.704,
	NO_REAL_NAME=0.178, SUBJ_ILLEGAL_CHARS=2.854]

Prostě naprasili osmibitové znaky do předmětu a více se tím netrápili. Ony byly navíc osmibitové znaky i v těle zprávy, aniž by tam byla hlavička Content-Transfer-Encoding: 8bit. To je další prasárna a současně porušení RFC 2822 ("If the body contains data in any bit-width other than 7-bit, the appropriate bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" for unencoded 8 bit wide data).").

[Karel]

+1

[Filip Jirsák]

Škoda, že něco takového nenapsal autor původního příspěvku. Ten psal pouze o tom, že e-maily nesplňují nějaká jeho pravidla, přičemž jediné, o kterém jsme se dozvěděli, bylo to, že e-mail musí mít i text/plain část.

[msk]

Ja som na zaciatku diskusie pastol body z assasinu, kde to je presne vidiet. Pravdu mate v tom, ze nebyt tych 2.9 bodov za encoding, tak by to SA neoznacil ako spam. Co ale nic nemeni na veci, ze by som ten mail napriek tomu nebol schopny precitat.