|
Editorial 30(1): Maintaining our Internet-based publishing infrastructure
After Editorial 29(4): 'The last month' copy editing and formatting, a discussion of the editorial staff workload preceding the publication of a new issue of IIER, the topics for Editorial 30(1) should really mark a return to academic aspects of IIER's publishing. However, in the two months prior to IIER 30(1) publication, much time and effort had to be diverted into activities which can be described as "maintaining our Internet-based publishing infrastructure". The main components of IIER's "infrastructure" referred to here are the hosting of IIER's website, www.iier.org.au, and the provision of the email list, editor@iier.org.au. These are not academic aspects of IIER's publishing, but are absolutely essential infrastructure components.
Attempted to update iier-inf.html 14dec19. Although the directory listing under CuteFTP shows iier-inf.html has been updated and CuteFTP "View" shows correct version, the version seen via http://www.iier.org.au/iier-inf.html with Safari is the old version.As I usually do in these kinds of website hosting matters, I allowed Netregistry, IIER and WAIER's website provider, a few days to discover and fix without being "nagged" by customers. I thought it may be something to do with a Netregistry operation to "migrate" IIER and WAIER and other clients to a new cPanel host. However, Netregistry did not discover and fix, so early on Tuesday 17 December 2019 I submitted an online technical help query to Netregistry. My query generated an automated response from Netregistry, "#03710234: ftp upload to website but showing the old version of the website", which included the advice, "Our expected wait time is currently 24 hours." That seemed rather slow, so the next important entry in my file note was:
phone 1300 638 734, 17dec19, wait time about 70 mins, talk time about 20 mins, case number 03710234, Netregistry to ring back after migration team have investigated.The "talk time about 20 mins" was unproductive, the hapless person I encountered on 1300 638 734 had to give up and refer me to a more senior person. There was no "ring back", but next day, Wednesday 18 December, "The Netregistry Team" tried to explain what was going on, in an email which included this text (shown as a screen picture):
To enable this to be understood, I need to explain that for some years iier.org.au has run as a "subdomain" of waier.org.au, because that was an economical method (no extra cost other than domain name registration) to create www.iier.org.au. Thus suspension of waier.org.au caused suspension also of iier.org.au. Sometime soon after this brusque advice, the absolutely essential infrastructure matter really hit. After "emptying cache" in my Safari web reader, my attempts to view the websites waier.org.au and iier.org.au were given a blunt message on screen:
Account SuspendedYes, I freaked out (to international readers, I apologise for the resorting to idiomatic Australian English), this being my first encounter with such a message in over 20 years of communications with Internet service providers. So freaked out that I forgot to take a screen picture, but I did reply same day, to give the requested assurance about taking "immediate action", though not knowing what that action had to be. Then followed a long and frustrating wait until Tuesday 24 December 2019, when "Bernard" advised by email that "Your account has been un-suspended." My first login to the waier and iier sites to check out matters was on Wednesday 25 December, a rather inconvenient time. Apart from the brief technical details Bernard's email provided, it included this text, reproduced here because it contained advice that I acted upon:
This Account has been suspended.
Contact your hosting provider for more information.
We are happy to point you in the right direction, and give some basic advice. But there is a reasonable limit to support for hacked websites. That doesn't include us fixing the website for you, and while we do understand you are upset at being hacked, our responsibility is a secure hosting environment. The most important thing to take into account with hacking is prevention. You need to have the attitude of it's not a matter of 'if I get hacked', but rather 'when I get hacked'. Remember security almost always has a trade off for convenience. Yes it's inconvenient having to manage security for your website, but you always have to keep in mind, if your site is down for days because it's been exploited, how much more inconvenient would that be?The long delay I had encountered, and the remark about "the 5th site they've fixed today" made me wonder about the number of Netregistry clients also experiencing a "Website Hacked (Phishing)" problem. Was the IIER and WAIER experience unique or commonplace amongst Netregistry clients? So I acted immediately upon Netregistry's advice to "reach out and get help", by looking amongst Australian-based "website security companies". I can skip the details of this search (though very interesting insights were obtained), except to note that I very quickly reached conclusions on two key points. Firstly, as IIER's site has a full backup on my desktop iMac (and its external backup disk), IIER was well placed to consider the option of abandoning the Netregistry-hosted site and all of the 2698 IIER files it contained. This enabled (very fortunately) scope to migrate IIER's site to a new provider, without drawing upon the IIER files residing on the Netregistry-hosted site and possibly in need of "cleaning". Secondly, for various reasons pertaining to Netregistry's reputation amongst the 'commentariat' [1] on website hosting matters, that perhaps need not be explicitly elaborated here, it seemed prudent to migrate IIER to another provider, and also migrate IIER out of its connection to WAIER as a "sub-domain".If you've been hacked and you aren't a technical person. The best thing to do is reach out and get help. You may have to pay for that from website security companies, or any number of others doing the same work, but ultimately getting back online is going to be faster using guys who live and breathe this stuff. You may well be the 5th site they've fixed today.
On Friday 27 December 2019 our new provider, CircleBC (https://www.circlebc.com.au), commissioned a new iier.org.au site. Many thanks to David Debono at CircleBC who provided the new hosting account setup and very good "how to" advice. Over the weekend! That was phenomenal. Before the weekend 28-29 December concluded, I was able to complete my task list:
Here is another example of a "Bounce action notification" from the Mailman list server that distributes emails sent to editor@iier.org.au, made notable because Google, of all organisations, should be more acutely aware of the limitations of artificial intelligence programs that attempt to block "spam" or "junk email".
This message was created automatically by mail delivery software.These kinds of "Bounce action notifications" concerning @gmail.com addresses commenced on about 29 January 2020 (prior to that date, @gmail.com addresses were functioning without incident). The identity of the sending domain being blamed by Google Mail is not being stated in these bounce messages, but in this case and in my present mood I'll identify the sending domain as gmail.com, because the email was from a prospective author, address [xxx]@gmail.com. So, a "gotcha" moment (Google "What is gotcha?"), do we have an instance where gmail has labelled its own domain as having a "very low reputation"?A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:[gmail address for IIER associate editor Dr Christine Glass]
host gmail-smtp-in.l.google.com [2404:6800:4003:c02::1b]
SMTP error from remote mail server after end of data:
550-5.7.1 [2400:b800:3:1::222 19] Our system has detected that this message
550-5.7.1 is likely suspicious due to the very low reputation of the sending
550-5.7.1 domain. To best protect our users from spam, the message has been
550-5.7.1 blocked. Please visit
550 5.7.1 https://support.google.com/mail/answer/188131 for more information.
h16si2166979pfq.145 - gsmtp
Reporting-MTA: dns; se2.syd.hostingplatform.net.au
To be serious, at this stage I do not know whether the "very low reputation" domain is se2.syd.hostingplatform.net.au, which belongs to IIER's new provider of website hosting and email listserver, CircleBC (as described above), or whether iier.org.au is the "very low reputation" domain. So, time consuming further investigation is needed. Visiting https://support.google.com/mail/answer/188131 is not helpful, the "more information" given there is in a genre unique to IT persons, the "it is your fault, not ours" genre. That web page, and a large number of FAQ pages it links to give no information about why, when and how gmail imposed upon editor@iier.org.au its "system" for ascertaining "likely suspicious due to the very low reputation of the sending domain".
The "very low reputation" for gmail.com, as I see it, is a matter of concern for IIER (as well as Google), because @gmail.com is the most frequently occurring email domain used by our prospective authors. In our 2019 all submissions file, @gmail.com occurred 270 times, far larger than the next most frequent, @yahoo.com with 80 occurrences. Also, since about 29 January 2020 we have encountered repeated instances of IIER associate editors with gmail addresses having a "message has been blocked" applied to emails via editor@iier.org.au, from other IIER associate editors who use @bigpond.com addresses, including rjatkinson@bigpond.com. That is a serious impediment to associate editor teamwork.
How the heck does gmail identify an email as "likely suspicious due to the very low reputation of the sending domain"? Be explicit, what "sending domain" is gmail referring to? Do Google's gmail people really believe they can reliably identify "likely ... spam" by looking at the originating domain, or domains that relayed the email (such as iier.org.au)? Surely the question of what is spam and what is not can be assessed only by reading the body text of an email? To what extent are providers of email addresses, such as Google, resorting to such breaches of privacy?
So, very unfortunately, much time that should be devoted to advising authors, progressing IIER's review queues, and copy editing of accepted articles, has to be diverted to improving the reliability of editor@iier.org.au for associate editors and authors. Oh well, start using Google search to investigate Google's gmail. Start a tedious study of results from Google searches of the kind:
https://www.google.com.au/search?hl=en&as_q=Is+gmail.com+a+domain+having+a+very+low+reputation
One more example of time wasting due to "Bounce action notification" (and then I will end this line of grumpiness). Recently one of our IIER associate editors, Associate Professor Judy MacCallum, referred to me a message from the Mailman list server for editor@iier.org.au:
Your membership in the mailing list Editor has been disabled due toA surprise and time waster for Judy, who did not know that bounces were occurring. Hopefully, this particular kind of time wasting for all parties will be curtailed by some tweaking of Mailman's "bounce processing" settings. I increased the setting for "The maximum member bounce score before the member's subscription is disabled" from 5.0 to 10.0. I decreased the setting for "The number of days after which a member's bounce information is discarded, if no new bounces have been received in the interim" from 7 to 3.
excessive bounces The last bounce received from you was dated
29-Jan-2020. You will not get any more messages from this list until
you re-enable your membership. You will receive 3 more reminders like
this before your membership in the list is deleted.To re-enable your membership [several remedial actions outlined, each
involving a 40 character "confirm" string; not needed in this case
because I intervened with a list administrator action].
