Díky, tohle vypadá jako dobrý tip. Po cestě může být nějaký špatně implementovaný SMTP server a když se tečka trefí zrovna na to "správné" místo, problém je na světě. Pokusím se zjistit z hlaviček, přes které servery tyhle maily šly.
Honza > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Filip Jirsák > Sent: 19. listopadu 2007 16:44 > To: Java > Subject: Re: Zdvojeni tecek v emailech > > > Na problém v implementaci POP3 nebo IMAP v nějakém běžně > používaném klientovi bych tedy rozhodně nesázel. Spíš bych to > viděl na chybu na straně SMTP serveru, což ale asi taky > nebude žádný standardní server. Konkrétně asi špatně > implementuje toto (z RFC 2821 – SMTP): > > DATA <CRLF> > > If accepted, the SMTP server returns a 354 Intermediate reply and > considers all succeeding lines up to but not including the end of > mail data indicator to be the message text. When the end of text is > successfully received and stored the SMTP-receiver sends a 250 OK > reply. > > Since the mail data is sent on the transmission channel, the end of > mail data must be indicated so that the command and reply dialog can > be resumed. SMTP indicates the end of the mail data by sending a > line containing only a "." (period or full stop). A transparency > procedure is used to prevent this from interfering with the user's > text (see section 4.5.2). > > … a … > > 4.5.2 Transparency > > Without some provision for data transparency, the character sequence > "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. > In general, users are not aware of such "forbidden" sequences. To > allow all user composed text to be transmitted transparently, the > following procedures are used: > > - Before sending a line of mail text, the SMTP client checks the > first character of the line. If it is a period, one additional > period is inserted at the beginning of the line. > > - When a line of mail text is received by the SMTP server, it checks > the line. If the line is composed of a single period, it is > treated as the end of mail indicator. If the first character is a > period and there are other characters on the line, the first > character is deleted. > > > > > 19.11.07, Bares Jan <[EMAIL PROTECTED]>: > Díky za pomoc. Problém s největší pravděpodobností bude někde > na cestě ze serveru na klienta, nebo přímo na klientovi, ze > serveru to odchází v pořádku. Vím, že to s javou nesouvisí, > jen jsem se chtěl zeptat, zda někdo něco podobného neřešil. > Ono se to velmi špatně hledá, ideální by bylo odtrasovat > celou cestu emailu přes všechny mail servery a ještě si umět > vybrát právě ten email, u kterého to nastane, jak jsem psal, > stává se to jen někdy :-) > > Honza > > > Především je potřeba asi zjistit, kde je problém – tj podívat > > se na zdrojový kód odesílaného e-mailu a přijatého e-mailu. > > Pokud je chyba už v tom odeslaném, je to chyba buď > > odesílající aplikace nebo knihovny – pokud jsou v Javě, je na > > místě ptát se v této konferenci. Pokud je chyba někde jinde, > > můžete zjišťovat kde a pak poslat bugreport na příslušnou aplikaci. > > > > Obecně problém Javy to nebude určitě, takže minimálně bez > > jména použité knihovny pro sestavení e-mailu se neobejdeme. > > > > Filip Jirsák > > > > > > 19.11.07, Bares Jan <[EMAIL PROTECTED]>: > > S javou to souvisí asi tak, že v javě se píše hodně > > enterprise aplikací, které mohou rozesílat spoustu emailů > > (obě aplikace jsou Java EE). Proto předpokládám, že někdo z > > přítomných mohl narazit na podobný problém. Google jsem > > samozřejmě použil, ale na nic zajímavého jsem nenarazil. > > > > Honza > > > > > nezávislých projektech. Ze serveru jsou odesílány HTML maily > > > a některé z nich dorazí na klienty mírně modifikované. Občas > > > jsou některé tečky v HTML těle emailu zdvojené nebo i > > > > > > -- > > Filip Jirsák > > [EMAIL PROTECTED] > > > > > > > -- > Filip Jirsák > [EMAIL PROTECTED] >
