[antispam-f] Re: SecureSockets

  • From: Harriet Bazley <lists@xxxxxxxxxxxxxxxxxx>
  • To: antispam@xxxxxxxxxxxxx
  • Date: Wed, 13 Feb 2019 00:08:34 GMT

On 8 Feb 2019 as I do recall,
          Frank de Bruijn  wrote:

In article <38200f8357.harriet@xxxxxxxxxxxxxxxx>,
   Harriet Bazley <lists@xxxxxxxxxxxxxxxxxx> wrote:
On 8 Feb 2019 as I do recall,
          Frank de Bruijn  wrote:
Let's go back a bit. You wrote earlier that version 1.67 was OK until
you rebooted. So what happens when you load the module manually by
double clicking the file and then run AntiSpam?

No difference.   It doesn't work until I 'load' the module from within
AntiSpam by clicking on the 'Module' button.   Whereupon...
  Module is: SecureSockets   1.04 (26 Nov 2005)
Yep, still same version in memory, apparently.

This doesn't make any sense. There is only one function which handles
checking/loading this module. It is called in the procedure that loads
the settings if there is a Security setting 1 or 2, or when the Module
button is clicked.

However, if I then do a 'Quit and restart' from AntiSpam's menu, it
registers the presence of the module correctly when it reloads.   And I
don't see how it can be preserving the contents of its own memory
(unless maybe it is?  Maybe it's the old bugbear of fragments of data
persisting in uninitialised Wimpslot space when a program is quit and
then rerun?)


I'm still trying to work out what bizarre combination of circumstances
is actually going on here to break a previously-working setup, although
the obvious fix is to copy the module inside AntiSpam itself (the answer
to the question as to how SecureSockets is getting loaded at all is that
Hermes is being run to send mail after the end of the fetch).

As a result of trying to insert debugging commands in the source file
I've inadvertently discovered that AntiSpam does *not* complain about
the module's being missing if the !RunImage is run directly (and does
not throw up any further errors after such a run, even if you
subsequently quit the app and run it 'normally').   On the other hand,
when it's run via the !Run file it seems to give repeated errors every
time it attempts to fetch from that mailbox, up to and until you
double-click on the !RunImage manually.

At least I now have a shorter-but-not-compressed version of the source
!RunImage that I can insert debugging info into.    ;-)

I thought it might be an issue with the BASIC compression, but I get the
same results after substituting my 'shorter' file for the main
!RunImage, and whether it is located inside or outside the app
directory.   The next test is to see what happens if I run it with the
command-line switches present (and with a limited Wimpslot);
unfortunately once the problem is 'fixed' it doesn't show up again until
after a complete reboot, so I tend to put off further tests until the
next day's e-mail session, which makes investigation rather slow....

but I can't see in that case how SecureSockets 1.05 is nonetheless
getting loaded and yet not being recognised as present when AntiSpam
checks for it.

I tried creating a standalone version of FNmodule, and that worked
precisely as expected (i.e. registered the presence of the module).
It's in the specific context of checking from within the app that it's
failing, for some totally unknown reason.

I need to do some poking around with Reporter to see which values are
different when the file is run by the two different means.

If that module is in memory when AntiSpam is started, it should be
accepted. Unless it does not have the correct values at the help string
offset in the module header. Does it present itself as SecureSockets
1.05 or something else (*help secure. should tell you)?

*help secure.
==> Help on keyword SecureSockets
Module is: SecureSockets   1.04 (26 Nov 2005)

Harriet Bazley                     ==  Loyaulte me lie ==

A statement of fact cannot be insolent

Other related posts: