| VZ | Čárka ve jménu odesílatele |
| Z internetu dorazí nějaký e-mail, který má odesílatele ve formátu RFC-822, ale jméno před adresou obsahuje čárku, např. "Jan Novák, správce IT <novak@nekde.xx>". Uživatel dá Reply... a při psaní odpovědi vidí pouze jednu adresu a neuvědomí si, že čárka v LN je oddělovač jednotlivých adresátů. Nicméně při odeslání se vyhledá jméno "Jan Novák" v některé z adresních knih a pokud ho tam najde, tak se odpověď pošle jednak na nalezenou adresu (např. novak@firma.cz) a také na zbytek původní adresy "správce IT <novak@nekde.xx>". Takže odpověď dostane i úplně cizí člověk, který se tak může dostat k důvěrným informacím určeným pouze původnímu odesílateli. Odpovídající uživatel přitom nic netuší a i když si později odeslanou zprávu otevře, tak záměnu části adresy snadno přehlédne - jedná se o shodná jména. Nechtěné přidání adresy se projeví i po zmáčknutí F9, ale na to si uživatel před odesláním odpovědi nevzpomene.
Zatím to řeším agentem, který po doručení zprávy zkontroluje, zda pole From nebo Principal obsahuje čárky a pokud ano, tak obsah těchto polí zkopíruje do nových polí jako zálohu a nahradí čárky dolním apostrofem.
Otázky:
1. dá se to řešit na úrovni LN/Domino jiným způsobem?
2. může taková záměna čárky za apostrof nějak ovlivnit doručování zpráv? | | cifra | Spatne | 15.09.2008
18:07:44
ID: 2746.1
 
| Obavam se, ze to je spatna implementace RFC na strane uzivatele. Adresa nesmi obsahovat carku a pokud ji obsahuje, tak ma byt v uvozovkach, ale ne cela. Tzn., ze maji uvozovky koncit pred spicatou zavorkou. Pak je vse v poradku... | | VZ | To je jasne ... | 15.09.2008
21:33:54
ID: 2746.2
| ... chyba je jednoznačně u odesílatele. Ale vysvětlujte to někomu z nejvyššího vedení, pokud vinou tohoto problému odeslal důležitý dokument na nechtěnou adresu mimo firmu - někomu, kdo to určitě neměl vidět. Víckrát se to prostě nesmí opakovat.
Ideální by bylo, kdyby na tu chybu s čárkou dokázal upozornit odesílatele i příjemce už SMTP router, např. přes anti-relay pravidla při příjmu. Jenže tam musí být přesná adresa konkrétního odesílatele nebo aspoň doména. A přes pravidla na routeru či ve schránce to také nejde - nedá se tam zadat podmínka, kdy adresa odesílatele obsahuje čárku.
Kromě toho by asi nebylo vhodné odmítat e-maily jen proto, že má odesílatel nesprávný formát adresy. Co kdyby to byla třeba žádost o nabídku - obchodníci by asi nejásali, kdyby přišli o možnost získat zakázku protože router odmítl přijmout e-mail jen kvůli nepřesnému formátu v adrese odesílatele. Ale také by asi nechtěli odeslat kvůli stejné chybě kopii nabídky nějakému jmenovci žadatele, který by pracoval třeba u konkurence.
Taky by to šlo ošetřit až v při vytváření odpovědi nebo forwardování, ale to by bylo náročnější na modifikaci šablony a testování v různých prostředích - LN, web-mail, pop3/imap klienti. Modifikace odesílatele je asi nejjednodušší a měla by fungovat bez ohledu na prostředí.
Na druhou stranu se mi nelíbí nutnost modifikovat v tomto případě adresu odesílatele, když se nedá dobře odhadnout, jaké to bude mít dopady. Nicméně modifikace adresy odesílatele pomocí uvozovek bude asi korektnější než záměna čárky za apostrof. Díky za radu. | | VZ | Tak apostrof asi problémy nedělá | 16.09.2008
09:37:50
ID: 2746.3
| Adresa po záměně čárky za apostrof bez problémů projde přes @ValidateInternetAddress([Address822]; ...).
Je to jednodušší než hledat, kde asi tak přidat uvozovku a jestli někde nějakou případně ubrat. Eventuálně by šlo ustřihnout část fráze dle RFC822 a nechat adresu původního odesílatele pouze ve formátu RFC821, tedy novak@nekde.xx | | cifra | Varianta b)... | 18.09.2008
16:50:35
ID: 2746.4
| by byla asi nejlepsi a nejjednodussi.. |
|
