Re: Wizfile problem

"John C." <[email protected]> wrote:

> Just tried the links again and they worked. 

I noticed their web site became responsive several hours after my prior
post on how slow it was to load their web doc.  The CDN from where they
get all their scripts to define their dynamic web page finally started
delivering the scripts.  Without scripts their web doc is undefined (you
get a bouncing ball placeholder page).  I don't trust sites that deliver
NOTHING when Javascript is disabled.  Why hide static content behind
scripts?  Why are the scripts not at their own domain?

> However, an email I sent them bounced. It said:

"It said" is what you wrote to them, not the NDR (Non-Delivery Report)
that would've been sent back as status.  What did the NDR say?  No such
e-mail address, inbox full, server busy, or what?

At their web site, contact options are a web form, or an e-mail address
of [email protected].  Is that the e-mail address to which
you sent your report?

When I use online tools to verify the e-mail address (typically they
start an SMTP session, but abort before the DATA command, so they don't
send an e-mail, just attempt to establish a mail session to the
specified mailbox), the result is the mail server timed out on verifying
the mailbox (status = MailboxValidationTimeout).  Another verifier
reporter said NoMxServersFound which means their nameserver does not
have MX records specifying what are the legit mail servers at the domain
to receive e-mails.  While the mailbox verify can fail simply because
many servers refuse to reply OK when specifying the mailbox, and won't
send back status until after accepting a message (to avoid spammers from
harvesting valid e-mail addresses), the lack of MX records is a
nameserver (DNS) error.  Many sending mail servers will refuse to
connect to a receiving mail server unless the receiving mail server has
been identified as legit at the domain.

https://en.wikipedia.org/wiki/MX_record

Looks like they need more work to get their web site and servers
working.  They're still borked.  You might have to use their web form to
contact them *if* that is working.

> I was, however, eventually easily able to prevent the program from
> starting with Windows. I found the setting by using Emisoft Hijackfree.
> 
> https://www.majorgeeks.com/files/details/emsisoft_hijackfree.html

I suspect it was a startup program that was getting loaded.  While your
tool includes an auto-run checklist, I use SysInternals' AutoRuns.

At the MajorGeeks site, the link to the author's home site (EMSI) points
to http://www.hijackfree.com/en/.  Yet visiting there redirects to to a
click redirection tracking site.  That was after a couple attempts to
connect.  Before that I got redirected to some site that wanted me to
install a Firefox add-on.  Looks like the hijack site has been hijacked.
I cannot find a separate hijackfree product at emsisoft.com.  Looks like
hihackfree is a component in their Emergency Kit; see:

https://www.emsisoft.com/en/blog/1498/emsisoft-emergency-kit-4-0-released/

They give no information about hijackfree, so I cannot compare it
against SysInternals' Autoruns which is inclusive of everywhere programs
can be started on Windows startup, on Windows account login, in Task
Scheduler, and on various Windows events.  Their screenshots are
worthless for seeing the depth of scan on auto-run programs.