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]
