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 c
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, For
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 ti
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 doub
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
> 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 co
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
>
> 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 sen
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 an
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
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 a
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 On
> 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
> 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, TCustomSmtpClien
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 sh
> 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 b
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.
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.
18 matches
Mail list logo
