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
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
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 CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF 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 CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF 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 CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF 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 CRLF+TAB 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 CRLF+TAB 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
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
