[continued from previous message]

fellow elected officials. (They don't stay overnight, Schieve adds; she did
not intend to jeopardize any future electoral campaigns with drugs and
orgies.)

The issuance of an NFT is not, at this point, such a radical thing, even for
a government. Cities and states all over have sought at times to forge links
to the blockchain. In 2018, Cleveland declared itself Blockland, though the label seems to have waned. Wyoming has set itself up as the premier
regulatory haven for cryptocurrency, a label that other states, including Nevada, now seek to challenge. All it takes is a few interested
businesspeople and elected officials receptive to “new ideas,” especially those with a cypherpunk ring. That's not quite what's happening in Reno. For Schieve, the NFT was a gateway to something else.

An early sign emerged in January, when Mayor Francis Suarez of Miami, a
person on a recent tear of throwing out tech-friendly ideas and seeing what sticks, tweeted about turning his city into a “hub for crypto innovation” centered around Bitcoin. Schieve was unsatisfied. “When are you going to become a $LINK marine?” she teased in reply, cryptically to most
readers. She was referring to a blockchain platform called Chainlink,
perhaps best known for its cult following of “marines” who swarm toward any mention of the technology on social media. Their loyalty is expressed
through ranks earned by #HODLing (that is, holding) the platform's cryptocurrency, called Link. Apparently, the mayor of Reno was a member of
the battalion -- “link pilled,” in the community's parlance. “It was really
sweet,” Schieve says of the meme invasion her tweet inspired.

https://www.wired.com/story/mayor-reno-betting-blockchain/

------------------------------

From: Gabe Goldberg <gabe@gabegold.com>
Date: Fri, 4 Jun 2021 18:31:20 -0400
Subject: Oximeters used to be designed for equity. What happened?
(WiReD)

The pandemic drew attention to the racial bias built into pulse oxes. But calls to create a fairer device are missing one thing: It once existed.

https://www.wired.com/story/pulse-oximeters-equity/

------------------------------

Date: Sat, 5 Jun 2021 21:18:52 +0300
From: Hagai Bar-El <info@hbarel.com>
Subject: One blessing of the Cybersecurity Executive Order

On May 12th, the Biden administration issued an Executive Order <https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/>
that was written to improve the overall security posture of software
products that the government buys from the private sector. Recent events,
such as the SolarWinds hack <https://www.crn.com/the-solarwinds-hack>, contributed to the realization that such a move is necessary.

This Executive Order is a big deal. Of course, nothing will change
overnight, but given the size and complexity of the software industry, as
well as the overall culture behind software security (the culture of: “If
the customer doesn't see it — don't spend money on it”), an Executive Order can probably yield the closest thing to immediate improvement that we could reasonably wish for. The US Government is a very large customer, and all
major vendors will elect to comply with its requirements rather than cross
it all off their addressable markets.

A lot has been written on how important it is for the government to use its buying power (if not its regulatory power) to drive vendors into shipping
more secure products. Product security suffers from what could best be described as a /market failure/ condition, which would call for such
regulatory intervention.

To not overly repeat the mainstream media, I would like to focus on one
unique aspect of the current Executive Order, and on how it can ignite a new trend that will change product and network security for the better. I'll discuss true machine-readable security documentation.

The requirement for a Software Bill of Materials

The Executive Order requires that every software product is accompanied by a Software Bill of Materials (SBOM) which lists the third-party software
modules that it contains. This is essential for the customer to monitor its exposure to supply-chain vulnerabilities. Let's say that I ship software
/X/, and that my software happens to utilize a library from a third party,
say, the library /L/. I now need to worry not only about vulnerabilities
found in my software /X/, but also about vulnerabilities found in /L/. If I
am careless, I could keep maintaining my own software without incorporating patches that are made available for /L/ by its vendor. If I am negligent, I would even not bother to check if there are any newly discovered vulnerabilities that need to be patched in /L/. If I am yet more negligent,
I could even keep on using a stale end-of-life /L/ library that is no longer maintained at all. However careless or negligent I am, the price is always
to be paid eventually by my customer. The customer might not even /know/ how reliant his security posture is on /L/. For what he knows, he only bought
/X/. If that customer knew that its security posture relies on /L/ as well,
it could have put pressure on me to make sure I use a secure version of /L/
in my product, or not use it at all. The customer, in other words, could use its buying power to improve what it gets. This

situation is what the SBOM provision comes to solve. It forces me to
disclose to my customers those additional dependencies that I subject them
to, so they can exert their market power towards improving the quality of
what they get.

The bigger picture: security documentation

The SBOM is a great idea, and its benefit is yet wider. Security
documentation is in poor shape today. Security is not very well covered in product documentation. Technical specifications, like the RFCs published by
the Internet Engineering Task Force (IETF), have sections titled *Security Considerations* in them; product documentation usually doesn't. Even answers
to basic questions such as: “What are the exposure risks to the data processed by the product?” or “What could I do as a customer to minimize the
attack surface of the product I'm using?” are seldom answered directly. If the customer is lucky, then there are tips scattered around the manuals,
help pages, and readme files. If the customer is less lucky, as customers usually turn out to be in such cases, he will need to deduce this from other pieces of product information.

Any security-specific documentation that products will now have to be
shipped with is an immense improvement, and will hopefully serve as a
precedent for more. One day, hopefully, customers will require a clear
manifest of the product's attack surface: an enumeration of all interfaces
and how those are protected. Cynicism aside, I am confident that once
vendors actually produce such documents for their customers, they may become aware of some vulnerabilities of their products of which they were not aware before, and fix them on time.

Once we generate more security documents for products, the next step would
be making those security documents truly machine-readable.

True machine-readable security documents

The Executive Order requires the SBOM document to be included with the
product, without prescribing the precise format this document should take,
but noting that it shall be ‘machine-readable'. Every vendor can use
whatever format it desires, and ‘machine-readable' is a definition that is wide enough to cover any document which is not a handwritten napkin (until
it gets scanned). Nevertheless, we are likely to witness accelerated
document evolution. Thousands of vendors will have to start producing those documents very shortly. It will take very few years, rather than decades,
for the industry to converge onto a few stable forms (most likely the forms that will be used by the major consultancies and certification bodies, and
in light of further instructions from the government). The standardization
fora will soon enough take on the challenge of defining a standard schema, augmenting some work that has already been done.

When this happens, we will all be one large step into the future of true machine-readable security documentation. By ‘/true/ machine-readable' I
refer to documents that machines can actually learn from, not just parse.

Once the SBOM document uses a true machine-readable format, it will be processed by risk management software packages. Such packages will take this input, along with assessment and prioritization from tools like /Kenna/ or /VulnDB/, to draw a more accurate risk posture for the organization, based
on the newly learned dependencies. Introducing automation into the process
will also force the vendors into keeping those SBOM documents accurate and updated.

The prevalence of security documents that are truly machine-readable is a
big deal. We are not just talking about a security document that is read by
a management app instead of by a person; we are talking about a step in the direction of reducing one of the biggest headaches of security monitoring configuration: discovery.

A headache called discovery

The year is 1997, and I get to help improve the security of a large organization. One big challenge at the time was the connection of desktops using modems that were left in answer mode when unattended. I came prepared with instructions and scripts for securing those modems. Soon enough I
learned that there was no place in the organization where all those modems
were even registered. The one-month “secure the modems” project started with
3.5 weeks of running war-dialers — bots that dial all extensions to create the list of active modems, with just one short week left for actually
securing them. Today we barely use modems, but corporate networks grow
faster than anyone can keep record, and the trend (at least in tech
companies) is to not restrict adoption of new technologies by people, unless necessary. Be it software packages, web services, connected devices or
modems, discovery is always a challenge, and the place where many balls get dropped.

*Much of the unaddressed attack surface in large systems is caused not by vulnerabilities of which you are unaware, but rather by functionality of
which you are unaware.* (No point Googling it; I made it up.)

Having mechanisms in place that enforce rigorous record-keeping of systems
and their dependencies might not count as the latest core security tech, but can certainly prevent many security incidents.

Beyond SBOM

Once we get into the habit of deploying systems that come with written manifests of their capabilities, there is no reason to stop at the SBOM.
Some people suggest an intuitive extension into what they call a *Bill of Behaviors*, and one can easily think of other security-related properties
that vendors could report about their systems. So much heuristics are used
by security monitoring tools just because there is no clear statement of
what an expected behavior of a system is. Using such heuristics not only implies missing alerts, but it also costs us in reduced
sensitivity. Heuristics-based security monitors are configured for reduced sensitivity to overcome false-alerts; false-alerts that could easily kill
any deployment of a security monitoring tool. Anyone deploying security monitoring tools will tell you that the Achilles heel of those tools is not
in the quality of their monitoring technology, but in the complexity of the configuration management that is required to deploy them effectively. By targeting this complexity, we strengthen the weakest link.

Once true machine-readable security docs appear, and some standard for them emerges, security monitoring systems will happily start reading them. We
will enjoy less heuristics involved in assessing what packages an installed piece of software /may/ contain within it, or what network traffic is /reasonable/ to see. Finally, once the overall security posture of a system
is more deterministic and less reliant on heuristics, there will be an incentive for vendors to exceed the requirements of Executive Orders, and provide more such machine-readable manifests. This will assure them that
their systems are not generating false alarms by security monitoring tools.

What about IoT?

So far, we've discussed typical corporate IT networks. Once the trend of machine-readable security documentation gains traction, it may also be
adopted into IoT, where its value will be yet magnified.

In the IoT space, heuristics are more prevalent. It's a relatively new
domain where standards are fewer and fragmentation rules. There are good companies out there that built complete business models around trying to identify what's running on an IoT network; even just recognizing what types
of devices are involved. Security-wise, the IoT space today is where the IT space was two decades ago, with frequent use of weak authentication, use of
old software stacks, and over-reliance on obscurity.

Clarity is a good friend of Security, and IoT networks could use much of it.

Summary: the role of the government

The space of IT security, for both corporate networks, home networks and
IoT, leaves much to wish for. The market is motivated by functional
features, with security taking the back seat. This is the case, to a large extent, because security is evident neither in its existence nor in its absence; a situation that is likely to prevail.

Moreover, product security suffers from significant information
asymmetry. The vendor knows much more about the security of its product than the customer (even if such knowledge means knowing that he doesn't really
know, as is the case with many vendors). This asymmetry implies that
customers cannot properly factor security into their buying decisions, diminishing the ability of the market to fuel improvements, as it does in
other areas.

Such conditions, like the related public safety conditions, call for
government intervention. In some cases this happens through regulation
(e.g., with car seat belts). In softer cases, where life and death do not
seem to be directly at stake, the government can still catalyze improvement
by using its buying power. In our case, the primary interest of the
government might be to protect itself, rather than the public, but the
outcome is the same. (It is reasonable to expect that some of the benefit of that buying power, which the taxpayer enables, benefits back the taxpayer,
so all is well.)

Forcing software products to come with a *Bill of Materials* is just part of the benefit of the Executive Order, but I argue that even this addition
alone, once imposed on many large vendors, can ignite a multi-phase process
of improvement:

1. starting with one mandatory machine-readable SBOM document that has
to be kept up to date,
2. leading to machine-generated machine-readable documents, which are
easier for the vendor to produce and refresh,
3. to standards-based true machine-readable documents that can be used
by security gear, both for SBOM and for other areas where positive
attestation by the vendor can help reduce the use of heuristics in
security monitoring,
4. to an overall higher security posture by improving the accuracy and
benefit of security monitoring and enforcement tools; accuracy that
will also favor vendors.

We do not need an Executive Order for this, but we do need an Executive
Order to build the critical mass of demand for machine-readable security documentation that will ignite this entire process.

Whatever the overall aspiration of the government is — I believe that it
will get more than it bargained for.

/This essay has also been published at: https://www.hbarel.com/

------------------------------

Date: May 29, 2021 14:31:25 JST
From: Dewayne Hendricks <dewayne@warpspeed.com>
Subject: CDC loosened mask guidance to encourage vaccination --
it failed spectacularly (Beth Mole, Ars Technica)

FDA approval and paid time off would make people more likely to get a shot, poll finds.
By Beth Mole
May 28 2021 <https://arstechnica.com/science/2021/05/cdc-loosened-mask-guidance-to-encourage-vaccination-it-failed-spectacularly/>

The Centers for Disease Control and Prevention stunned health officials and experts on May 13 with the abrupt announcement that people fully vaccinated against COVID-19 could forgo masking in most settings -- indoor, outdoor, uncrowded, and crowded alike. The guidance was a stark reversal from the
health agency's previous stance, issued just two weeks earlier, that still recommended vaccinated people wear masks among crowds and in many indoor, uncrowded settings.

The CDC said at the time that it was merely following the science for
masking. The agency and its director, Rochelle Walensky, highlighted fresh, real-world studies demonstrating COVID-19 vaccines' high efficacy and
ability to lower transmission risks. But the update was also part of an
overt effort to encourage vaccination among the vaccine hesitant by
emphasizing the perks of being vaccinated -- like not needing to wear masks anymore and reclaiming other bits of normal life.

That messaging shift came as states across the country started to see their pace of vaccination slow despite a glut of vaccine doses. Numerous polls
have indicated that most of the people eager to get vaccinated already
have. Now, with just 62 percent of the US adult population vaccinated, much
of the remaining unvaccinated portion is either hesitant or resistant to
being vaccinated. It's that group of people the CDC was trying to reach with the new mask guidance.

``The science is also very clear about unvaccinated people,'' Walensky said during the May 13 press briefing, in which she announced the mask guidance update. ``[Unvaccinated people] remain at risk of mild or severe illness, of death, or spreading the disease to others. You should still mask, and you should get vaccinated right away. Your health and how soon you return to normal life before the pandemic are in your very capable hands.''

Mask blunder

The mask update immediately generated confusion and controversy given the reversal and its abruptness. And according to fresh polling data, the
guidance failed spectacularly at convincing unvaccinated people to get vaccinated.

In new results from the Kaiser Family Foundation's ongoing COVID-19 vaccine monitoring poll, 85 percent of unvaccinated people said the CDC's loosened
mask guidance for fully vaccinated people made *no difference* to their vaccination plans. Only 10 percent said the change made them *more likely*
to get vaccinated and a final 4 percent or so said the change made them
*less likely* to get a shot. It gets worse. The poll broke unvaccinated
people into three groups: people who said they would &*definitely not* get vaccinated, people who would get vaccinated *only if required*, or people
who would *wait and see*. Those most resistant to getting vaccinated were
the least likely to be swayed by the CDC's latest guidance. Among the *definitely not* group, 98 percent said the change made no difference to
them and the remaining 2 percent said they were less likely to get vaccinated -- zero percent said they were more likely to get a vaccine. For the *only
if required* group, 89 percent said the CDC change made no difference.

Overall in the poll -- which collects data on a nationally representative sampling of adults -- 62 percent said they had already gotten their vaccine (which tracks with CDC vaccination data), 12 percent said they would wait
and see about vaccination, 7 percent said they would only get vaccinated if they were required, and 13 percent said they would *definitely not* get vaccinated. That *definitely not* portion has largely remained the same throughout the polling, which stretches back to December.

While the CDC's loosened masking guidance was clearly not persuasive to the unvaccinated, the poll explored other tactics that could boost
vaccination. The two ideas that seemed to have the most sway were: 1) if the Food and Drug Administration grants a vaccine full approval, rather than the current Emergency Use Authorizations (EUA); and 2) if employers provided
paid time off to get vaccinated and recover from any side effects, like
feeling under the weather the day after a dose.

FDA approval and PTO

A total of 32 percent of unvaccinated people said a full FDA approval (a Biologics License Application [BLA] approval) would make them more likely to get a COVID-19 vaccine. Currently, all three vaccines available in the US
have been granted an EUA. The FDA grants EUAs only during public health emergencies, like the COVID-19 pandemic, through a process that is
fast-tracked compared with a full BLA approval.

Importantly, both tracks require efficacy and safety data from massive Phase III clinical trials. The main difference between an EUA and full approval is the amount of time that people in the clinical trials are followed after
full vaccination. Typically, the FDA likes to have at least six months of follow-up data from a vaccine trail. This allows the trial runners and the
FDA to look at how well vaccine protection holds up over that time and if
any rare side effects crop up. For an EUA, the follow-up period may only be around two months.

However, the difference is largely moot at this point. With nearly 167
million people in the US alone already given at least one shot, regulators
have a wealth of post-market safety data. Also, Pfizer and BioNTech
announced in April that they had six-months of trial follow-up data that confirmed the vaccine's high efficacy and found no safety concerns. Earlier this month, Pfizer and BioNTech, as well as Moderna, announced that they havestarted a rolling data-submission process for a BLA. [...]

------------------------------

Date: Fri, 4 Jun 2021 14:59:53 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: Deter prying eyes by locking your own letters (Atlas Obscura)

A how-to for those who want to use folds, tucks, slits, and more to turn letters into little works of art.

https://www.atlasobscura.com/articles/letterlocking-how-to

DIY encryption.

------------------------------

Date: Mon, 31 May 2021 10:55:10 +0200
From: Marco <listaddr@gmail.com>
Subject: Facebook systematically censoring "vaccine concerns",
regardless of truthfulness (Project Veritas)

This is not "fighting fake news", this is pure censorship.

https://www.projectveritas.com/news/breaking-facebook-whistleblowers-expose-leaked-internal-docs-detailing-new/

------------------------------

Date: Fri, 4 Jun 2021 15:06:50 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: Facebook suspends Trump for 2 years in response to Oversight Board
ruling (WashPost)

The change is part of a series of responses to the Facebook Oversight
Board's ruling on former President Trump. https://www.washingtonpost.com/technology/2021/06/03/trump-facebook-oversight-board/

Risks? Facebook, Trump...

------------------------------

Date: Mon, 31 May 2021 14:38:38 +0200
From: Marco <listaddr@gmail.com>
Subject: Google made it nearly impossible for users to keep their
location private (Business Insider)

Google continued collecting location data even when users turned off various location-sharing settings, made popular privacy settings harder to find, and even pressured LG and other phone makers into hiding settings precisely
because users liked them, according to the documents.

https://www.businessinsider.com/unredacted-google-lawsuit-docs-detail-efforts-to-collect-user-location-2021-5

------------------------------

Date: Fri, 4 Jun 2021 13:28:53 -0600
From: "Cipher Editor" <cipher-editor@ieee-security.org>
Subject: Security Engineering: A Guide to Building Dependable Distributed
Systems (Ross Anderson)

[*Cipher* is at http://www.ieee-security.org/cipher.html
It is published 6 times per year]

Security Engineering: A Guide to Building
Dependable Distributed Systems by Ross Anderson
Book Review By Sven Dietrich
5/31/21

Wiley Publishing 2020, ISBN ISBN-13: ISBN: 978-1-119-64278-7 (Hardcover)
1232 pages, Third Edition

We live amid constant reminders in real life about what could have been done better from a computer security perspective. When something goes wrong, we find it is a protocol that is exhibiting an exploitable vulnerability, or a software repository that has been infiltrated with code containing a vulnerability, or a critical infrastructure system held for ransom. One
wonders what design principles the system authors and builders had
considered to mitigate any compromises or to allow them to continue to
function in the presence of those compromises. How can we engineer those solutions, how can we build better systems: more secure, more dependable?
One book attempts to provide this background.

At over 1200 pages, Ross Anderson's third edition of 'Security Engineering:
A Guide to Building Dependable Distributed Systems' is a large update after
the first edition in 2001 and the second edition in 2008. This is a comprehensive book on security engineering, providing anywhere from an introduction to the various subfields of computer and network security to considerations necessary to building secure and resilient real-world
systems, and all the way to identifying research problems that remain to be addressed for the topics in each chapter.

The book is divided into three parts, with a total of 29 chapters, and
contains an extensive bibliography. The first part covers the basics, the second part looks at applications of secure systems, and the third part
broadly discusses politics, management, and assurance. Each chapter covers several themed subsections, followed by a chapter summary, a set of research problems, and further reading. The chapters read well and flow easily within themselves as well as from one chapter to the next. While it is a a
descriptive treatise, not a rigorous mathematical treatment of the various subjects, nonetheless occasional mathematical formulas or charts will pop up inline to illustrate the broad concepts brought forth and to whet the
reader's appetite to seek out the original research paper or other
references cited.

The first part spans 8 chapters that quickly set the stage for Ross
Anderson's approach to the subject matter: 'What is Security Engineering?', 'Who is the Opponent?', 'Psychology and Usability', 'Protocols', 'Cryptography', 'Access Control', 'Distributed Systems', and last but not
least 'Economics'. The reader learns about what it means to deal with
adversity in the 2020s, identifying the threat models, the pitfalls, and the consequences of not getting security right. The big impact here is from the author's contribution to the security field, the systems view, the
psychology and usability aspects, as well as the economics aspects, topics
for which the author has organized (or otherwise contributed to) workshops
and conferences.

The second part discusses real-world applications of secure systems,
covering many decades of security work, from the early days of 'Multilevel Security' and 'Nuclear Command and Control', to 'Advanced Cryptographic Engineering', 'Biometrics' and 'Tamper Resistance' as well as Digital Rights Management in 'Copyright and DRM', to 'Network Attack and Defence',
'Phones', 'Locks and Alarms', just to mention some of the 16 chapters in
here. This part is wrapped up with thoughts on 'New Directions' in the
field, talking among others about the combination of Machine Learning, Artificial Intelligence and Security and what it means for both attacker and defender sides.

The third part covers politics, management, and assurance in four
chapters. Here the reader learns about 'Surveillance or Privacy', 'Secure Systems Development', 'Assurance and Sustainability'. Controversial topics
of surveillance versus privacy are brought up in the context of political
and technological settings that have affected Internet users for many years, including wiretapping and censorship. Risk quantification and DevSecOps are brought into the picture here as well. This part wraps up with 'Beyond "Computer Says No"', reminding us what Ross Anderson has told us all along
in these chapters: think about the big picture, and how does it fit in?

This is a fantastic book for organizing one's thinking about security engineering and design. The reader how all the facets fit together in the
real world through both scientific references and anecdotes from the last
few decades. The depth is provided, should the reader care to delve deeper, through an absolutely impressive bibliography of close to 2100 entries. The narrative is easy to follow throughout the book, whether the reader is
learning about DDoS attacks (always close to my heart), espionage (Snowden's surveillance revelations, for example), security protocol failures,
financial transaction protocols, mobile phone security, electronic voting security (very relevant in the last few years), security printing, covert channels, DNS security, deception, or ransomware, among others.

The breadth of the topics covered provides a good perspective for
appreciating the impact that good (secure?) design can have on real-world systems that surround us. That is even more so relevant now that the
Internet has invaded, uh, permeated our homes with Internet-of-Things
devices that make our lives more Internet-centric with all the advantages
and risks that come with it.

The accessible style of this book and, most importantly, the relevant
context of the discussed secure systems, make for one pleasurable
reading. While it could be considered a very comprehensive introduction to
the idea of security engineering, there are enough timely and
thought-provoking musings to keep more advanced readers interested in
seeking out the scientific articles providing the adequate depth, hindsight, and foresight. This book is a must-have if security engineering is your intended field or connected to your field.

Ross Anderson did a great job of producing the third edition of 'Security Engineering: A Guide to Building Dependable Distributed Systems' in 2020, a book intended to last for many years. He is a well-known expert in the
security field and this overarching treatise makes for one impressive (and heavy!) book. The book is a welcome addition to my bookshelf, to be used as
a reference or even textbook in the years to come.

Sven Dietrich reviews technology and security books for IEEE Cipher. He
welcomes your thoughts at spock at ieee dot org.]

------------------------------

Date: Tue, 1 Jun 2021 22:31:13 +0100
From: John Bechtel <john@bechtel.me.uk>
Subject: Re: Risks: Colonial Pipeline accused of negligence in proposed
class action (Bloomberg Law, RISKS-32.69)

The idea that Colonial would shut the pipeline down if it can't
measure who is getting what product (as I understand the story) sounds very much like the apocryphal story about telephone exchanges (Central Offices or Switches to some) back in the day: What is the purpose of a telephone
exchange? ``Why, to make telephone calls, of course!''
But that is not the answer. The true answer is: to generate billing records.
If the hard disk to which billing records are written is full, should the exchange place calls?

------------------------------

Date: Thu, 03 Jun 2021 14:27:41 -0400
From: Sam Steingold <sds@gnu.org>
Subject: Re: Florida governor signs law to block *deplatforming* of
Florida politicians (The Verge, RISKS-32.69)

I think [they] have reinvented Shadow banning. https://en.wikipedia.org/wiki/Shadow_banning

I find it disappointing that such a terrifying risk to free discourse is
being advocated here.

------------------------------

Date: Mon, 31 May 2021 09:43:09 +0100
From: "Patrick O'Beirne" <pob@sysmod.com>

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)