[twsocket] Bug in SmtpProt.pas
When using mail-client from ICS, and set the subject property with a string length very long, my exe crashes and goes down and I found the reason here: procedure TCustomSmtpClient.DataNext; var MsgLine : array [0..1023] of char; begin { If we have been disconnected, then do nothing. } { RequestDone event handler is called from socket SessionClose event. } if not FConnected then begin FWSocket.OnDataSent := nil; Exit; end; Inc(FItemCount); if FItemCount < FHdrLines.Count then begin { There are still header lines to send } -->StrPCopy(@MsgLine, FHdrLines.Strings[FItemCount]); <-- here There is no check for length of the line in FHdrLines before copying the line. If the line length is longer than 1024, the copying will fail and crash the exe. I'm not sure how to fix this the best way. The easiest I guess is to use StrPLCopy and ensure not copying more than we have room for. But is it nessecary to copy the content before putting in the send-buffer? Would it not be more effecient and easy to just put the underlying text in the stringlist from the right index directly in the send-buffer? In C++ I would do something like this: FWSocket->PutDataInSendBuffer(FHdrLines.Strings[FItemCount].c_str(), FHdrLines.Strings[FItemCount]..Length()); Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] bug in smtpprot.pas
Hi all, there is a bug in SmtpProt.pas (latest ics version just downloaded), function Rfc822DateTime, line 2892 and 2907, FormatDateTime function. Result := FormatDateTime('ddd, d mmm hh:mm:ss', t) + ' ' + TimeZoneBias The time separator : should be put between double quotes, like this: Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + ' ' + TimeZoneBias Otherwise the system default time separator would be used (in italian localization, default time separator is '.'). Regards -- Marcello Vezzelli Software Development Department E-Works s.r.l. tel. +39 059 2929081 fax +39 059 2925035 Direzionale 70 - Via Giardini 456/c 41100 Modena - Italy web: http://www.e-works.it meeting room: http://e-works.it/join/[EMAIL PROTECTED] -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: > When using mail-client from ICS, and set the subject property with a > string > length very long, my exe crashes and goes down and I found the reason > here: The SMTP protocol doesn't allow longer lines in any case, so your application could check for a correct length. Also it important to wrap lines that are longer than 74 cups. Means either a blank or tab in front of a continuation line. Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
> The SMTP protocol doesn't allow longer lines in any case, so > your application could check for a correct length. Also it > important to wrap lines that are longer than 74 cups. Means > either a blank or tab in front of a continuation line. I still think there should be check on linelength before copying, it's ok to not send all data if breaking rfc but not take down the whole application. Should also subject be split into continuation-lines if longer than 74 cups (cups=chars?)? Outlook does not seem to do this with the subject. If I understand this correct. If I have a subject of 2000 chars, I can send this if I insert crlf and tab at every 74 char and don't break any rfc? Anyway, TCustomSmtpClient.DataNext would fail even when using continuation lines every 74 char if the total length is longer than 1024. What do you think about this? Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: >>The SMTP protocol doesn't allow longer lines in any case, so >>your application could check for a correct length. Also it >>important to wrap lines that are longer than 74 cups. Means >>either a blank or tab in front of a continuation line. > > > I still think there should be check on linelength before copying, it's ok to > not send all data if breaking rfc but not take down the whole application. The application should do the check, that was Arlo's point. > Should also subject be split into continuation-lines if longer than 74 cups > (cups=chars?)? Outlook does not seem to do this with the subject. Outlook *does* indeed break long subject lines. Here's an example of a message I just sent using Outlook 2000: --- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: This is a very long subject line. This is a very long subject lin e. This is a very long subject line. This is a very long subject line. Th is is a very long subject line. This is a very long subject line. This is a very long subject line. This is a very lo Date: Tue, 25 Oct 2005 11:17:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" testing! dZ. --- > > If I understand this correct. If I have a subject of 2000 chars, I can send > this if I insert crlf and tab at every 74 char and don't break any rfc? Correct. > Anyway, TCustomSmtpClient.DataNext would fail even when using continuation > lines every 74 char if the total length is longer than 1024. Again, this is a limit imposed by the protocol itself, so the application should guard against it. That said, I agree that the component could avoid potential buffer overflows if it included the check, just as long as it does not impact performance and functionality adversely. dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
> Outlook *does* indeed break long subject lines. Here's an > example of a message I just sent using Outlook 2000: It does not when I test (Outlook 2003 SP1, but also with Norton Antivirus, dont know if this affects this). Other lines are split but not the subject. > > Anyway, TCustomSmtpClient.DataNext would fail even when using > > continuation lines every 74 char if the total length is > longer than 1024. > > Again, this is a limit imposed by the protocol itself, so the > application should guard against it. > > That said, I agree that the component could avoid potential > buffer overflows if it included the check, just as long as it > does not impact performance and functionality adversely. Anyway, the RFC 821 says that the maximum line length including is 1000 chars. If I use a subject that is longer, and break the line at 74 with and tab, the header-subject would be RFC-compliant, but the smtp-component would crash. Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
> Anyway, the RFC 821 says that the maximum line length > including is 1000 chars. If I use a subject that is > longer, and break the line at 74 with and tab, the > header-subject would be RFC-compliant, but the smtp-component > would crash. I guess I could use OnProcessHeader and split the lines into more lines if to long. But I think StrPCopy should be changed to StrPLCopy, I think this would not decrease performance, just stop the component from crashing if a line is to long. Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: >> Anyway, the RFC 821 says that the maximum line length >> including is 1000 chars. If I use a subject that is >> longer, and break the line at 74 with and tab, the >> header-subject would be RFC-compliant, but the smtp-component >> would crash. > > I guess I could use OnProcessHeader and split the lines into more lines if > to long. But I think StrPCopy should be changed to StrPLCopy, I think this > would not decrease performance, just stop the component from crashing if a > line is to long. Yes, it should be fixed, anyway it won't prevent the developer from checking for correct line length, so it is not so important. Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
On Oct 26, 2005, at 04:18, Bjørnar Nielsen wrote: >> Outlook *does* indeed break long subject lines. Here's an >> example of a message I just sent using Outlook 2000: > > It does not when I test (Outlook 2003 SP1, but also with Norton > Antivirus, > dont know if this affects this). Other lines are split but not the > subject. So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. dZ. -- God is real, except when declared as integer; and infinite when divided by zero. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
DZ-Jay wrote: > On Oct 26, 2005, at 04:18, Bjørnar Nielsen wrote: >>> Outlook *does* indeed break long subject lines. Here's an >>> example of a message I just sent using Outlook 2000: >> >> It does not when I test (Outlook 2003 SP1, but also with Norton >> Antivirus, >> dont know if this affects this). Other lines are split but not the >> subject. > > So the subject arrives as one continuous line of 1000+ characters? And > the SMPT server permits this? Strange. I'll take your word for it, as > I have no access to Outlook 2003 to test. Some mail servers reformat invalid headers and mime messages, with sometimes very strange results. Also some MTA's would drop the connection on receiving very long lines since they assume a buffer overrun attack. One note on OE 6, it truncates the subject line at 266 chars silently. Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
On Oct 26, 2005, at 06:06, Arno Garrels wrote: >> >> So the subject arrives as one continuous line of 1000+ characters? >> And >> the SMPT server permits this? Strange. I'll take your word for it, as >> I have no access to Outlook 2003 to test. > > Some mail servers reformat invalid headers and mime messages, with > sometimes very strange results. Also some MTA's would drop the > connection > on receiving very long lines since they assume a buffer overrun attack. That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. > One note on OE 6, it truncates the subject line at 266 chars silently. Outlook 2000 does the same thing, and it won't let you enter a subject line longer than 256 characters (but it split it with + after every 74 chars.) dZ. -- DZ-Jay [TeamICS] -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
> > That's what I was alluding at; I was assuming he meant that > the message would arrive intact with the entire subject line > without breaks or truncation. It does, but I can't write more than 256 chars in the subject-line. The subject is kept as a single line, no splits. The subject is sent this way and I receive it back from the mailserver the same way. Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: >> That's what I was alluding at; I was assuming he meant that >> the message would arrive intact with the entire subject line >> without breaks or truncation. > > It does, but I can't write more than 256 chars in the subject-line. The > subject is kept as a single line, no splits. The subject is sent this way > and I receive it back from the mailserver the same way. That's an old bug in OE, you should not copy M$ bugs but wrap the subject line. BTW: I think having ~1000 chars for the subject line is far enough, or do you know a client that would display such long subjects properly? Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
> That's an old bug in OE, you should not copy M$ bugs but wrap > the subject line. BTW: I think having ~1000 chars for the > subject line is far enough, or do you know a client that > would display such long subjects properly? I just testet Outlook, and it seems difficult to show the mail correct if the subject is very long and the lines are split. In my test it seems the best is to not to split the line and keep the subject not to long. Regards Bjørnar -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: > > >>That's an old bug in OE, you should not copy M$ bugs but wrap >>the subject line. BTW: I think having ~1000 chars for the >>subject line is far enough, or do you know a client that >>would display such long subjects properly? > > > I just testet Outlook, and it seems difficult to show the mail correct if > the subject is very long and the lines are split. In my test it seems the > best is to not to split the line and keep the subject not to long. As far as I know, it splits it for transport only, but concatenates all + delimited lines as one single header. dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in smtpprot.pas
Marcello Vezzelli wrote: > Hi all, > there is a bug in SmtpProt.pas (latest ics version just downloaded), > function Rfc822DateTime, line 2892 and 2907, FormatDateTime function. > > Result := FormatDateTime('ddd, d mmm hh:mm:ss', t) + > ' ' + TimeZoneBias > > The time separator : should be put between double quotes, like this: > > Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + > ' ' + TimeZoneBias > > Otherwise the system default time separator would be used (in italian > localization, default time separator is '.'). > > Regards I know this comes a little bit late, but... In the same function it is tested for English/US format by only comparing the first day (Sunday). Does anyone know if there is any other language where the Sunday is also abbreviated as "sun" but other days or months differ? if ShortDayNames[1] = MyShortDayNames[1] then Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + ' ' + TimeZoneBias Francois, why do you test at all and don't use TFormatSettings for all those functions? Is it performance? I don't know if the overloaded FormatDateTime function with TFormatStettings is slower. At least it makes the code much more readable and shorter (despite the definition of the TFormatSettings as a constant). Veit -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in smtpprot.pas
Hi A small typo in hh:mm:ss must be corrected to hh:nn:ss or hh":"nn":"ss MM is month and NN is minute Veit Zimmermann wrote: >Marcello Vezzelli wrote: > > >>Hi all, >>there is a bug in SmtpProt.pas (latest ics version just downloaded), >>function Rfc822DateTime, line 2892 and 2907, FormatDateTime function. >> >>Result := FormatDateTime('ddd, d mmm hh:mm:ss', t) + >> ' ' + TimeZoneBias >> >>The time separator : should be put between double quotes, like this: >> >>Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + >> ' ' + TimeZoneBias >> >>Otherwise the system default time separator would be used (in italian >>localization, default time separator is '.'). >> >>Regards >> >> > >I know this comes a little bit late, but... > >In the same function it is tested for English/US format by only >comparing the first day (Sunday). Does anyone know if there is >any other language where the Sunday is also abbreviated as "sun" >but other days or months differ? > > if ShortDayNames[1] = MyShortDayNames[1] then > Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + > ' ' + TimeZoneBias > >Francois, why do you test at all and don't use TFormatSettings >for all those functions? Is it performance? I don't know if the >overloaded FormatDateTime function with TFormatStettings is slower. >At least it makes the code much more readable and shorter (despite >the definition of the TFormatSettings as a constant). > > Veit > > -- Arnaldo Braun Consultoria em Informática mailto:[EMAIL PROTECTED] FLORIANOPOLIS - SC - BRASIL -- Esta mensagem foi verificada pelo sistema de antivírus e acredita-se estar livre de perigo. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in smtpprot.pas
Hi Arnaldo If you look at the source of FormatDateTime M is replaced by N if the preceding formatting character is H. I'm not quite sure if this works correctly, it won't hurt to change it to "nn" anyway. All: I checked FormatDateTime routines and they are all the same (regarding speed). So a call like Result := DateToStr (t, RFC822_FormatSettings) + ' ' + Time(t,RFC822_FormatSettings) + ' ' + TimeZoneBias with the following constant RFC822_FormatSettings : TFormatSettings = ( CurrencyFormat:3; NegCurrFormat: 8; ThousandSeparator: ','; DecimalSeparator: '.'; CurrencyDecimals: 2; DateSeparator: '.'; TimeSeparator: ':'; ListSeparator: ';'; CurrencyString:'€'; ShortDateFormat: 'dd.MM.'; LongDateFormat:'ddd, d mmm hh:nn:ss'; TimeAMString: ''; TimePMString: ''; ShortTimeFormat: 'hh:nn:ss'; LongTimeFormat:'hh:nn:ss'; ShortMonthNames: ('Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'); LongMonthNames:('January', 'February', 'March', 'April', 'May', 'June', 'July', 'Augut', 'September', 'October', 'November', 'December'); ShortDayNames: ('Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'); LongDayNames: ('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'); TwoDigitYearCenturyWindow: 0;); would be easier to read. Moreover according to Delphi Help it would be thread save in opposition to a call without a TFormatSettings parameter. Veit Arnaldo Braun wrote: > Hi > > A small typo in > > hh:mm:ss > > must be corrected to > > hh:nn:ss or hh":"nn":"ss > > MM is month and NN is minute > > > > > Veit Zimmermann wrote: > >> Marcello Vezzelli wrote: >> >> >>> Hi all, >>> there is a bug in SmtpProt.pas (latest ics version just downloaded), >>> function Rfc822DateTime, line 2892 and 2907, FormatDateTime function. >>> >>>Result := FormatDateTime('ddd, d mmm hh:mm:ss', t) + >>> ' ' + TimeZoneBias >>> >>> The time separator : should be put between double quotes, like this: >>> >>>Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + >>> ' ' + TimeZoneBias >>> >>> Otherwise the system default time separator would be used (in italian >>> localization, default time separator is '.'). >>> >>> Regards >>> >>> >> I know this comes a little bit late, but... >> >> In the same function it is tested for English/US format by only >> comparing the first day (Sunday). Does anyone know if there is >> any other language where the Sunday is also abbreviated as "sun" >> but other days or months differ? >> >> if ShortDayNames[1] = MyShortDayNames[1] then >> Result := FormatDateTime('ddd, d mmm hh":"mm":"ss', t) + >> ' ' + TimeZoneBias >> >> Francois, why do you test at all and don't use TFormatSettings >> for all those functions? Is it performance? I don't know if the >> overloaded FormatDateTime function with TFormatStettings is slower. >> At least it makes the code much more readable and shorter (despite >> the definition of the TFormatSettings as a constant). >> >> Veit >> >> > -- * * Dipl.-Ing. Veit Zimmermann [EMAIL PROTECTED] * * VECTRONIC Aerospace GmbH www.vectronic-aerospace.com * * Carl-Scheele-Str. 12 tel: +49 (0)30 6789 4990 * * D-12489 Berlin fax: +49 (0)30 6789 5230 * * Germany WGS84: 52°25.83'N 13°31.52'E * * -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be