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
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
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
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,
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
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
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
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
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
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
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.
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
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
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.
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
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
16 matches
Mail list logo
