[antispam-f] Re: missing headers
- From: Frank de Bruijn <antispam@xxxxxxxxxx>
- To: antispam@xxxxxxxxxxxxx
- Date: Wed, 12 Sep 2007 20:51:22 +0200
In article <gemini.jo96pq001ohus00z4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Jeremy Nicoll - freelists <jn.flists.73@xxxxxxxxxxxxxxxxxxxx> wrote:
> Richard Porter <ricp@xxxxxxxxxxxxxxxx> wrote:
[snip]
> Remember the log shows data interpreted by AS while it is testing a
> mail, before deciding to delete or download a mail. Data downloaded
> isn't logged (well, it was in one of my versions, byte by byte, when I
> was looking for problems in download logic, but I dunno if Frank's
> code has that option.
There is a debug setting which does something like that (or did I remove
that again? I'll need to check the code...), but you don't really want
to use that, because...
> And even if it does such logging generated so much output that unless
> you have a repeatable problem one tends to leave the option off.)
[snip]
> > It is of course entirely possible that the server returned the
> > complete headers plus ten body lines the first time and then only
> > sent a few lines of text when it was asked to return the whole
> > message.
> I think that's pretty unlikely.
I don't.
> It's more likely that some aspect of very long lines plus, perhaps, a
> badly constructed email, got mishandled.
I don't think so. Very long lines shouldn't cause any problems at all
during downloading, because that part of the program doesn't use BASIC
variables for storing the incoming data.
[snip]
> Seeing as the lines just above are clearly split mid-word, this looks
> like logging has suffered from the long-lines problem.
No real problem. AntiSpam is coded to handle that (check PROCincoming).
> But download of a file shouldn't have the problem because AS should
> be taking incoming data byte by byte and transferring it to the
> download file.
Indeed it does. I.e. it reads bytes from the buffer, does some EOL/EOT
checking, and writes to file using OS_BPut. That bit is coded in
assembler.
> > Would AntiSpam report an error if it was told that 5685 octets
> > followed and only 530 were returned?
> Early versions wouldn't have. I doubt newer ones do. Here the
> number of octets I actually receive are greater than the number
> reported by the ISP's mail server because (using VRPC) Windows's AV
> software gets into the midst of all this and the message that comes in
> from the ISP gets stuff added to it by the AV software before AS sees
> it.
Hmmmm... That makes an option to check this less useful for people using
VRPC.
Regards,
Frank
Other related posts:
