According to kensi, someone has apparently reconfigured mixmin to block
either posting in general, or posting by her specifically, and she's
been locked out for 24 hours now. She tried switching back to AIOE, only
to discover it's not been functioning for weeks (which is, quite frankly,
ridiculous and unconscionable when it wouldn't take half a week to stand
up a completely new NNTP server and point the domain name at that; the
time being wasted trying to fix the RAID problem instead of just starting
over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
EXPIRED BY NOW ANYWAY).

Anyway, kensi asked me to relay the following demand here in AFN:

----------
Either restore mixmin to normal immediately, or restore AIOE to normal
immediately. And stop monkeying with the free servers! Some people do not
have any alternatives, for any of a variety of reasons.
----------

That will be all for now.

Be it known, though, that any hacker exposed as the culprit behind this
latest problem will have me to answer to. Worse for them, at some point
they will likely have kensi to answer to, as well, and believe me when I
say that I've seen what happens to those kensi decides to utterly destroy,
and it is NOT pretty. You could fill a whole wing of Parkview Hospital
with them ...

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

Nadegda wrote:
>
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...

You tell them, Paul.
The bastards are all out to get you.

William Stickers <bill.stickers@innocent.com> wrote:

> Nadegda wrote:
> >
> > According to kensi, someone has apparently reconfigured mixmin to block
> > either posting in general, or posting by her specifically, and she's
> > been locked out for 24 hours now. She tried switching back to AIOE, only
> > to discover it's not been functioning for weeks (which is, quite frankly,
> > ridiculous and unconscionable when it wouldn't take half a week to stand
> > up a completely new NNTP server and point the domain name at that; the
> > time being wasted trying to fix the RAID problem instead of just starting
> > over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> > EXPIRED BY NOW ANYWAY).
> >
> > Anyway, kensi asked me to relay the following demand here in AFN:
> >
> > ----------
> > Either restore mixmin to normal immediately, or restore AIOE to normal
> > immediately. And stop monkeying with the free servers! Some people do not
> > have any alternatives, for any of a variety of reasons.
> > ----------
> >
> > That will be all for now.
> >
> > Be it known, though, that any hacker exposed as the culprit behind this
> > latest problem will have me to answer to. Worse for them, at some point
> > they will likely have kensi to answer to, as well, and believe me when I
> > say that I've seen what happens to those kensi decides to utterly destroy,
> > and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> > with them ...
> >

<https://www.dropbox.com/s/6zvnhu3amwqkped/abe0d25c5d9a8bf5a86587bb10180df3.jpg>

>
> You tell them, Paul.
> The bastards are all out to get you.
>

Shh! Don't clue him in, let it be a wonderful surprise when he
finds out for himself; then his <snicker> will be <snookered>.

--
^Ï^. – Sn!pe – My pet rock Gordon just is.

<https://youtu.be/_kqytf31a8E>

On Sun, 26 Mar 2023 07:41:40 -0000 (UTC), Nadegda <nad318b404@gmail.invalid> spurted out the following:
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...
>

That was me, I did it. I AM RESPONSIBLE. No, really, I am serious. It
was ME!!!

So fucking do something, bitch!

LOL

--
The Real Snoopy

On Sun, 26 Mar 2023 10:09:01 +0100, William Stickers <bill.stickers@innocent.com> spurted out the following:
> Nadegda wrote:
>>
>> According to kensi, someone has apparently reconfigured mixmin to block
>> either posting in general, or posting by her specifically, and she's
>> been locked out for 24 hours now. She tried switching back to AIOE, only
>> to discover it's not been functioning for weeks (which is, quite frankly,
>> ridiculous and unconscionable when it wouldn't take half a week to stand
>> up a completely new NNTP server and point the domain name at that; the
>> time being wasted trying to fix the RAID problem instead of just starting
>> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
>> EXPIRED BY NOW ANYWAY).
>>
>> Anyway, kensi asked me to relay the following demand here in AFN:
>>
>> ----------
>> Either restore mixmin to normal immediately, or restore AIOE to normal
>> immediately. And stop monkeying with the free servers! Some people do not
>> have any alternatives, for any of a variety of reasons.
>> ----------
>>
>> That will be all for now.
>>
>> Be it known, though, that any hacker exposed as the culprit behind this
>> latest problem will have me to answer to. Worse for them, at some point
>> they will likely have kensi to answer to, as well, and believe me when I
>> say that I've seen what happens to those kensi decides to utterly destroy,
>> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
>> with them ...
>
> You tell them, Paul.
> The bastards are all out to get you.

He can blame me for it.
--
The Real Snoopy

In article <tvosvk$2ddr3$2@dont-email.me>, nad318b404@gmail.invalid
says...
>
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.

You mean you can't afford a couple bucks a month?
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...

It was me. Bring it bitch.

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 07:41:40 +0000, Nadegda wrote:

> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically

I now have more information from kensi. It seems mixmin keeps fumbling
network connections, sometimes only a second or two after connecting:

----------
200 news.mixmin.net InterNetNews NNRP server INN 2.7.0 (20211218 prerelease) ready (posting ok)

Connection to host lost.
----------

Does anyone know what would cause this? Perhaps a certificate issue?
She seems to recall discussions here in the past regarding mixmin switching
from CACert to LetsEncrypt. Has that recently been done? What would likely
need to be done in the way of client-side reconfiguration afterward?

Though my own thinking is that she wouldn't even be able to see the server's
greeting message if TLS was failing to handshake ...

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

On 3/26/23 9:31 AM, Nadegda wrote:
> Does anyone know what would cause this? Perhaps a certificate issue?
> She seems to recall discussions here in the past regarding mixmin
> switching from CACert to LetsEncrypt. Has that recently been done? What
> would likely need to be done in the way of client-side reconfiguration
> afterward?

How a certificate is acquired is completely independent of the
certificate and what it does.

Just like how you power your computer is completely independent of what
you use your computer for.

Similarly, clients wouldn't need to change anything when servers change
how the server acquires it's certificate.

> Though my own thinking is that she wouldn't even be able to see the
> server's greeting message if TLS was failing to handshake ...

It depends what port is being used.

I can see a hypothetical scenario where someone is connecting to port
119 and /explicitly/ requesting encryption via the `STARTTLS` verb.
They could see the initial hello banner before the connection failed in
some way while trying to use encryption.

I can think of a few different things that might cause encryption
negotiation to fail. Internet connection problems related to MTU, old
root certificates on the client, changes in cipher suite configuration
on the server (possibly via system updates), etc.

A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when
trying to diagnose these types of connection issues.

--
Grant. . . .
unix || die

On 3/26/2023 12:01 PM, Grant Taylor wrote:
> On 3/26/23 9:31 AM, Nadegda wrote:
>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
>
> How a certificate is acquired is completely independent of the certificate and what it does.
>
> Just like how you power your computer is completely independent of what you use your computer for.
>
> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
>
>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
>
> It depends what port is being used.
>
> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
>
> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
>
> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
>

When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563

[RST,ACK] 144.76.182.167 ==> 192.168.0.2

so basically the server is telling everyone to "piss off".

No certificates are involved at that level :-/ It is not
an exchange of packets followed by a "kaboom". It's dead,
out of the gate.

The web server still works, so it is not a "general machine" problem
by the looks of it. Just related to a service that
"does not want to talk to anyone today".

Shades of the previous problem, or a new problem ?

It's perfectly normal for a server to issue a [RST], like
for a temporary resource shortage. But this is every packet
sent on that port number, is getting nacked. It is also possible
for DPI boxes, to shut off comms to a particular machine, using
[RST]. (The DPI box sends an [RST] in both directions.) So that
is a second failure mechanism (my old ISP had that
problem, a mis-programmed DPI box). If you were concerned about
which mechanism was at work, you could study the timestamps on
the responses.

But I'm pretty sure, based on statistics and occurrence frequency
of problems, this is a Mixmin-local problem.

Paul

On 3/26/23 11:12 AM, Paul wrote:
> When I use Wireshark here, I'm getting a steady stream of this from
> news.mixmin.net:563
>
> [RST,ACK] 144.76.182.167 ==> 192.168.0.2
>
> so basically the server is telling everyone to "piss off".

I suspect it's more "no service at this port" than it is "piss off".

Have you tried TCP port 119 w/ STARTTLS? I'm able to get connection and
what looks to be a valid TLS certificate that way.

% openssl s_client -connect news.mixmin.net:119 -starttls nntp 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
0 s:CN = news.mixmin.net
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
3 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFJTCCBA2gAwIBAgISBDpyiO1qxqG2ljev7V1z9PaiMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzAzMjExODUyMzRaFw0yMzA2MTkxODUyMzNaMBoxGDAWBgNVBAMT
D25ld3MubWl4bWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALrWi9I41vIbZTeElRdRbIPHG6dQnZRM0HmYEH7rTbxQOWKmTSR55Y2K0rsl3g8y
UK7TjNFsQ44br0ZyNEZi9jfvaCnqxRJLt2Gp4fK8mB/CoymgU4/Ou2UjZJ8YqAH8
aSJjVkcmo97AWRbYzTn40WQH19tyw4HPcRy0dGqlieAM55fcMbqc6e6eo5EK69N6
Qr7mfkZZxrBOuwUkp9bEiFHjYoFXZItX0SELpAPyq83uJgCyEW3pcPeEaXgrvOwh
MV416hKFdvreJnnAxwtgZeSgKwGEfPeu391BHqbsV5pp01seKhrIY0/lK60/g7H1
hfO9Vwyhj5BOUXpf8X976A8CAwEAAaOCAkswggJHMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNV
HQ4EFgQULsumFpNR/713W+y0LIlUpX6ywUkwHwYDVR0jBBgwFoAUFC6zF7dYVsuu
UAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8v
cjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9y
Zy8wGgYDVR0RBBMwEYIPbmV3cy5taXhtaW4ubmV0MEwGA1UdIARFMEMwCAYGZ4EM
AQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0
c2VuY3J5cHQub3JnMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcAtz77JN+cTbp1
8jnFulj0bF38Qs96nzXEnh0JgSXttJkAAAGHBbsEAwAABAMASDBGAiEAt/oToBl4
3qnZUmgma1dGxfe5FgwELiEegtxkClenfEkCIQD4oFmVfA7WxZ3MP3tBKePY4nbM
pTrCfinGXKMrRVDzfwB2AHoyjFTYty22IOo44FIe6YQWcDIThU070ivBOlejUutS
AAABhwW7BCQAAAQDAEcwRQIgNpBHCd8agfRSDMjSLWTEG8DENbVBtCU728GPxyjJ
VZcCIQCz8LnziFF05vof4uXay8/vj95ORQIcpoTK9LmazJlfnTANBgkqhkiG9w0B
AQsFAAOCAQEAsIs6Nn2u7iaObgrs6/gkozyvQtWDZ8GAeRGrXFJfPb49O1nP1Ytj
7UZdftCBrq3zJTwS4x6HzYHn5MQKq30V7RzdQWrg7+uWlYR96J8NlEqvH7+aeZqj
/baB4mXPOd0h3lF2Asmdef2ashZr2faMmhVhWY4p2teYINXP++eyjkmyKhZ1yL6W
qCXZbZi/8Sy6KctMAB1bhyxQbRyCIdroOa8DI46Kr3Q+tXbc2bTVW7MWeIz/XEfo
fFGWIUpQ47ubYwdp2GDkIrVi7sz2g3UxxIHDYaWyECPi3P4aRIkHp197qfjIR/VC
ay9FEG+vmCm6YuMwLaOtbRdRbzYHlsKNnQ==
-----END CERTIFICATE-----

> Shades of the previous problem, or a new problem ?

Is there a problem?

> It's perfectly normal for a server to issue a [RST], like for a
> temporary resource shortage. But this is every packet sent on that
> port number, is getting nacked.

There are a number of things that could explain why /explicit/ TLS works
on port 119 via the `STARTTLS` verb and why /implicit/ TLS doesn't work
on port 563.

> It is also possible for DPI boxes, to shut off comms to a
> particular machine, using [RST]. (The DPI box sends an [RST] in both
> directions.)

Don't forget that the RST packets need to have source IP (and other
details) pretending to be the other system.

However I doubt that's the case. Especially with /explicit/ TLS working
when using the `STARTTLS` verb on TCP port 119.

> So that is a second failure mechanism (my old ISP had that problem,
> a mis-programmed DPI box). If you were concerned about which mechanism
> was at work, you could study the timestamps on the responses.

Hanlon's razor comes to mind.

> But I'm pretty sure, based on statistics and occurrence frequency of
> problems, this is a Mixmin-local problem.

It may be something as simple as the daemon that provides /implicit/ TLS
connectivity on TCP port 563 isn't running.

--
Grant. . . .
unix || die

In article <tvpogo$2og4s$1@dont-email.me>, nad318b404@gmail.invalid
says...
>
> Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
> On Sun, 26 Mar 2023 07:41:40 +0000, Nadegda wrote:
>
> > According to kensi, someone has apparently reconfigured mixmin to block
> > either posting in general, or posting by her specifically
>
> I now have more information from kensi. It seems mixmin keeps fumbling
> network connections, sometimes only a second or two after connecting:
>
> ----------
> 200 news.mixmin.net InterNetNews NNRP server INN 2.7.0 (20211218 prerelease) ready (posting ok)
>
>
> Connection to host lost.
> ----------
>
> Does anyone know what would cause this? Perhaps a certificate issue?
> She seems to recall discussions here in the past regarding mixmin switching
> from CACert to LetsEncrypt. Has that recently been done? What would likely
> need to be done in the way of client-side reconfiguration afterward?
>
> Though my own thinking is that she wouldn't even be able to see the server's
> greeting message if TLS was failing to handshake ...

Maybe mixmin is sick of your lies.

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 13:12:54 -0400, Paul wrote:

> On 3/26/2023 12:01 PM, Grant Taylor wrote:
>> On 3/26/23 9:31 AM, Nadegda wrote:
>>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
>>
>> How a certificate is acquired is completely independent of the certificate and what it does.
>>
>> Just like how you power your computer is completely independent of what you use your computer for.
>>
>> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
>>
>>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
>>
>> It depends what port is being used.
>>
>> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
>>
>> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
>>
>> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
>>
>
> When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563
>
> [RST,ACK] 144.76.182.167 ==> 192.168.0.2
>
> so basically the server is telling everyone to "piss off".
>
> No certificates are involved at that level :-/ It is not
> an exchange of packets followed by a "kaboom". It's dead,
> out of the gate.
>
> The web server still works, so it is not a "general machine" problem
> by the looks of it. Just related to a service that
> "does not want to talk to anyone today".
>
> Shades of the previous problem, or a new problem ?
>
> It's perfectly normal for a server to issue a [RST], like
> for a temporary resource shortage. But this is every packet
> sent on that port number, is getting nacked. It is also possible
> for DPI boxes, to shut off comms to a particular machine, using
> [RST]. (The DPI box sends an [RST] in both directions.) So that
> is a second failure mechanism (my old ISP had that
> problem, a mis-programmed DPI box). If you were concerned about
> which mechanism was at work, you could study the timestamps on
> the responses.
>
> But I'm pretty sure, based on statistics and occurrence frequency
> of problems, this is a Mixmin-local problem.
>
> Paul

That's bizarre, since kensi was able to get the server greeting
message.

As for DPI boxes, nobody should use them. They violate the end-to-end
principle. And the main uses I've heard of for them are all evil:
censorious regimes (think "China"); injecting ads and other unwanted
garbage for commercial gain (aka spamming); and malicious interference
with apps the superrich don't like people using (think Bittorrent). The
only legitimate use-case I can think of for them off-hand is antimalware,
and that use-case is defeated by the widespread use of TLS on both web and
email connections.

Basically, in the presence of pervasive end-to-end encryption the only
thing a DPI box can do that an ordinary perimeter firewall or local antivirus
can't is obstruct two third parties from talking to each other even if they
themselves both want to communicate (so, censorship) and compile a list of
who's talking to who (so, espionage).

Hence, evil.

And breaks the end-to-end principle and therefore breaks the internet.

Hence, stupid *and* evil.

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

On 3/26/23 11:44 AM, Nadegda wrote:
> As for DPI boxes, nobody should use them.

Deep Packet Inspection is a tool / technique. And like all tools /
techniques, it can be used for both good and / or bad.

I have a firewall rule that looks for a specific string in queries to my
DNS servers. Said string is for a zone that I don't host and I don't
provide recursive services. It's a string that a bot uses for an
amplification attack.

I'm using -- what is arguably -- DPI to identify and block those DNS
queries from ever hitting my DNS server. -- The last time I looked I
had over a million requests for that query filtered.

> They violate the end-to-end principle.

No, Deep Packet Inspection does not violate the end-to-end principle.
Anybody can filter anything they want to anywhere on their network. How
they do it is up to them.

NAT violates the end-to-end principle in that there is no possible way
for each end to communicate directly without the assistance of something
else translating traffic.

> And the main uses I've heard of for them are all evil:

By your own words; "the main uses", implies that there are other uses.

As stated above, not all uses for DPI are evil.

> censorious regimes (think "China"); injecting ads and other
> unwanted garbage for commercial gain (aka spamming); and malicious
> interference with apps the superrich don't like people using (think
> Bittorrent).

Altering the stream without terminating it is considerably more than
/just/ DPI. It's also more evil than /just/ DPI.

> The only legitimate use-case I can think of for them off-hand is
> antimalware,

So you agree that there are acceptable uses for DPI.

> and that use-case is defeated by the widespread use of TLS on both
> web and email connections.

I'm trying to decide if TLS monkey-in-the-middle counts as DPI or not.
I think it's more active proxying than it is DPI.

I also think that DPI conceptually could happen even with TLS if the DPI
system has access to the keys and no PFS / ephemeral keys are used.
E.g. a company puts the web server's TLS keys on a DPI box so that they
can inspect traffic at the edge for compliance reasons.

> Basically, in the presence of pervasive end-to-end encryption the
> only thing a DPI box can do that an ordinary perimeter firewall or
> local antivirus can't is obstruct two third parties from talking
> to each other even if they themselves both want to communicate (so,
> censorship) and compile a list of who's talking to who (so, espionage).

A perimeter firewall / router can easily obstruct two parties from
talking to each other. You don't need DPI for that.

A perimeter firewall / router can easily compile a list of who's
talking. NetFlow and the likes are specifically meant for things like
this. You don't need DPI for that either.

> Hence, evil.

DPI is a tool. A tool by itself is not inherently evil.

How the tool is most commonly used may be evil.

> And breaks the end-to-end principle and therefore breaks the internet.

DPI doesn't break the end-to-end principle.

> Hence, stupid *and* evil.

Nope.

--
Grant. . . .
unix || die

In article <tvq09p$2og4s$2@dont-email.me>, nad318b404@gmail.invalid
says...
>
> Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
> On Sun, 26 Mar 2023 13:12:54 -0400, Paul wrote:
>
> > On 3/26/2023 12:01 PM, Grant Taylor wrote:
> >> On 3/26/23 9:31 AM, Nadegda wrote:
> >>> Does anyone know what would cause this? Perhaps a certificate issue? She seems to recall discussions here in the past regarding mixmin switching from CACert to LetsEncrypt. Has that recently been done? What would likely need to be done in the way of client-side reconfiguration afterward?
> >>
> >> How a certificate is acquired is completely independent of the certificate and what it does.
> >>
> >> Just like how you power your computer is completely independent of what you use your computer for.
> >>
> >> Similarly, clients wouldn't need to change anything when servers change how the server acquires it's certificate.
> >>
> >>> Though my own thinking is that she wouldn't even be able to see the server's greeting message if TLS was failing to handshake ...
> >>
> >> It depends what port is being used.
> >>
> >> I can see a hypothetical scenario where someone is connecting to port 119 and /explicitly/ requesting encryption via the `STARTTLS` verb. They could see the initial hello banner before the connection failed in some way while trying to use encryption.
> >>
> >> I can think of a few different things that might cause encryption negotiation to fail.  Internet connection problems related to MTU, old root certificates on the client, changes in cipher suite configuration on the server (possibly via system updates), etc.
> >>
> >> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend when trying to diagnose these types of connection issues.
> >>
> >
> > When I use Wireshark here, I'm getting a steady stream of this from news.mixmin.net:563
> >
> > [RST,ACK] 144.76.182.167 ==> 192.168.0.2
> >
> > so basically the server is telling everyone to "piss off".
> >
> > No certificates are involved at that level :-/ It is not
> > an exchange of packets followed by a "kaboom". It's dead,
> > out of the gate.
> >
> > The web server still works, so it is not a "general machine" problem
> > by the looks of it. Just related to a service that
> > "does not want to talk to anyone today".
> >
> > Shades of the previous problem, or a new problem ?
> >
> > It's perfectly normal for a server to issue a [RST], like
> > for a temporary resource shortage. But this is every packet
> > sent on that port number, is getting nacked. It is also possible
> > for DPI boxes, to shut off comms to a particular machine, using
> > [RST]. (The DPI box sends an [RST] in both directions.) So that
> > is a second failure mechanism (my old ISP had that
> > problem, a mis-programmed DPI box). If you were concerned about
> > which mechanism was at work, you could study the timestamps on
> > the responses.
> >
> > But I'm pretty sure, based on statistics and occurrence frequency
> > of problems, this is a Mixmin-local problem.
> >
> > Paul
>
> That's bizarre, since kensi was able to get the server greeting
> message.
>
> As for DPI boxes, nobody should use them. They violate the end-to-end
> principle. And the main uses I've heard of for them are all evil:
> censorious regimes (think "China"); injecting ads and other unwanted
> garbage for commercial gain (aka spamming); and malicious interference
> with apps the superrich don't like people using (think Bittorrent). The
> only legitimate use-case I can think of for them off-hand is antimalware,
> and that use-case is defeated by the widespread use of TLS on both web and
> email connections.
>
> Basically, in the presence of pervasive end-to-end encryption the only
> thing a DPI box can do that an ordinary perimeter firewall or local antivirus
> can't is obstruct two third parties from talking to each other even if they
> themselves both want to communicate (so, censorship) and compile a list of
> who's talking to who (so, espionage).
>
> Hence, evil.
>
> And breaks the end-to-end principle and therefore breaks the internet.
>
> Hence, stupid *and* evil.

You cry about free stuff. Typical woke broke liberal.

In article <tvq13a$pij$1@tncsrv09.home.tnetconsulting.net>,
gtaylor@tnetconsulting.net says...
>
> On 3/26/23 11:44 AM, Nadegda wrote:
> > As for DPI boxes, nobody should use them.
>
> Deep Packet Inspection is a tool / technique. And like all tools /
> techniques, it can be used for both good and / or bad.
>
> I have a firewall rule that looks for a specific string in queries to my
> DNS servers. Said string is for a zone that I don't host and I don't
> provide recursive services. It's a string that a bot uses for an
> amplification attack.
>
> I'm using -- what is arguably -- DPI to identify and block those DNS
> queries from ever hitting my DNS server. -- The last time I looked I
> had over a million requests for that query filtered.
>
> > They violate the end-to-end principle.
>
> No, Deep Packet Inspection does not violate the end-to-end principle.
> Anybody can filter anything they want to anywhere on their network. How
> they do it is up to them.
>
> NAT violates the end-to-end principle in that there is no possible way
> for each end to communicate directly without the assistance of something
> else translating traffic.
>
> > And the main uses I've heard of for them are all evil:
>
> By your own words; "the main uses", implies that there are other uses.
>
> As stated above, not all uses for DPI are evil.
>
> > censorious regimes (think "China"); injecting ads and other
> > unwanted garbage for commercial gain (aka spamming); and malicious
> > interference with apps the superrich don't like people using (think
> > Bittorrent).
>
> Altering the stream without terminating it is considerably more than
> /just/ DPI. It's also more evil than /just/ DPI.
>
> > The only legitimate use-case I can think of for them off-hand is
> > antimalware,
>
> So you agree that there are acceptable uses for DPI.
>
> > and that use-case is defeated by the widespread use of TLS on both
> > web and email connections.
>
> I'm trying to decide if TLS monkey-in-the-middle counts as DPI or not.
> I think it's more active proxying than it is DPI.
>
> I also think that DPI conceptually could happen even with TLS if the DPI
> system has access to the keys and no PFS / ephemeral keys are used.
> E.g. a company puts the web server's TLS keys on a DPI box so that they
> can inspect traffic at the edge for compliance reasons.
>
> > Basically, in the presence of pervasive end-to-end encryption the
> > only thing a DPI box can do that an ordinary perimeter firewall or
> > local antivirus can't is obstruct two third parties from talking
> > to each other even if they themselves both want to communicate (so,
> > censorship) and compile a list of who's talking to who (so, espionage).
>
> A perimeter firewall / router can easily obstruct two parties from
> talking to each other. You don't need DPI for that.
>
> A perimeter firewall / router can easily compile a list of who's
> talking. NetFlow and the likes are specifically meant for things like
> this. You don't need DPI for that either.
>
> > Hence, evil.
>
> DPI is a tool. A tool by itself is not inherently evil.
>
> How the tool is most commonly used may be evil.
>
> > And breaks the end-to-end principle and therefore breaks the internet.
>
> DPI doesn't break the end-to-end principle.
>
> > Hence, stupid *and* evil.
>
> Nope.

Nads is a liberal crybaby.

On 3/26/23 12:03 PM, Skeeter wrote:
> Nads is a liberal crybaby.

That may, or may not, be the case.

I don't particularly care.

If someone wants to have a polite and civil discussion about a topic
that I'm interested in, then I'll do so. At least until I get tired of
the discussion.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/26/23 12:03 PM, Skeeter wrote:

>>Nads is a liberal crybaby.

>That may, or may not, be the case.

>I don't particularly care.

>If someone wants to have a polite and civil discussion about a topic
>that I'm interested in, then I'll do so. At least until I get tired of
>the discussion.

Isn't it less difficult to see that the other person has a point if the
other person doesn't repeatedly change socks to fake the existence of a
disinterested third party supporting his position?

"Nadegda" isn't pretending to be human except in Paul's own mind. (Paul
has a mind? Yes yes, I know. Post proof, ko0ky.)

There are still enough people on Usenet to speak to who don't morph
continuously.

I'm suggesting a fairly low bar here.

In article <tvq563$40n$1@tncsrv09.home.tnetconsulting.net>,
gtaylor@tnetconsulting.net says...
>
> On 3/26/23 12:03 PM, Skeeter wrote:
> > Nads is a liberal crybaby.
>
> That may, or may not, be the case.
>
> I don't particularly care.
>
> If someone wants to have a polite and civil discussion about a topic
> that I'm interested in, then I'll do so. At least until I get tired of
> the discussion.

Then Kensi/Nads won't work for you.

On 26 Mar 2023, Nadegda <nad318b404@gmail.invalid> posted some
news:tvq09p$2og4s$2@dont-email.me:

> Time to trigger the right-wing snowflakes again. Melt, snowflakes,
> melt! On Sun, 26 Mar 2023 13:12:54 -0400, Paul wrote:
>
>> On 3/26/2023 12:01 PM, Grant Taylor wrote:
>>> On 3/26/23 9:31 AM, Nadegda wrote:
>>>> Does anyone know what would cause this? Perhaps a certificate
>>>> issue? She seems to recall discussions here in the past regarding
>>>> mixmin switching from CACert to LetsEncrypt. Has that recently been
>>>> done? What would likely need to be done in the way of client-side
>>>> reconfiguration afterward?
>>>
>>> How a certificate is acquired is completely independent of the
>>> certificate and what it does.
>>>
>>> Just like how you power your computer is completely independent of
>>> what you use your computer for.
>>>
>>> Similarly, clients wouldn't need to change anything when servers
>>> change how the server acquires it's certificate.
>>>
>>>> Though my own thinking is that she wouldn't even be able to see the
>>>> server's greeting message if TLS was failing to handshake ...
>>>
>>> It depends what port is being used.
>>>
>>> I can see a hypothetical scenario where someone is connecting to
>>> port 119 and /explicitly/ requesting encryption via the `STARTTLS`
>>> verb. They could see the initial hello banner before the connection
>>> failed in some way while trying to use encryption.
>>>
>>> I can think of a few different things that might cause encryption
>>> negotiation to fail.  Internet connection problems related to MTU,
>>> old root certificates on the client, changes in cipher suite
>>> configuration on the server (possibly via system updates), etc.
>>>
>>> A network sniffer; e.g. tcpdump, tshark, Wireshark, is your friend
>>> when trying to diagnose these types of connection issues.
>>>
>>
>> When I use Wireshark here, I'm getting a steady stream of this from
>> news.mixmin.net:563
>>
>> [RST,ACK] 144.76.182.167 ==> 192.168.0.2
>>
>> so basically the server is telling everyone to "piss off".
>>
>> No certificates are involved at that level :-/ It is not
>> an exchange of packets followed by a "kaboom". It's dead,
>> out of the gate.
>>
>> The web server still works, so it is not a "general machine" problem
>> by the looks of it. Just related to a service that
>> "does not want to talk to anyone today".
>>
>> Shades of the previous problem, or a new problem ?
>>
>> It's perfectly normal for a server to issue a [RST], like
>> for a temporary resource shortage. But this is every packet
>> sent on that port number, is getting nacked. It is also possible
>> for DPI boxes, to shut off comms to a particular machine, using
>> [RST]. (The DPI box sends an [RST] in both directions.) So that
>> is a second failure mechanism (my old ISP had that
>> problem, a mis-programmed DPI box). If you were concerned about
>> which mechanism was at work, you could study the timestamps on
>> the responses.
>>
>> But I'm pretty sure, based on statistics and occurrence frequency
>> of problems, this is a Mixmin-local problem.
>>
>> Paul
>
> That's bizarre, since kensi was able to get the server greeting
> message.
>
> As for DPI boxes, nobody should use them. They violate the end-to-end
> principle. And the main uses I've heard of for them are all evil:
> censorious regimes (think "China"); injecting ads and other unwanted
> garbage for commercial gain (aka spamming); and malicious interference
> with apps the superrich don't like people using (think Bittorrent).
> The only legitimate use-case I can think of for them off-hand is
> antimalware, and that use-case is defeated by the widespread use of
> TLS on both web and email connections.
>
> Basically, in the presence of pervasive end-to-end encryption the only
> thing a DPI box can do that an ordinary perimeter firewall or local
> antivirus can't is obstruct two third parties from talking to each
> other even if they themselves both want to communicate (so,
> censorship) and compile a list of who's talking to who (so,
> espionage).
>
> Hence, evil.
>
> And breaks the end-to-end principle and therefore breaks the internet.
>
> Hence, stupid *and* evil.

Maybe the server process just didn't want to take anymore of "kensi's"
shit.

Warning! Always wear ANSI approved safety goggles when reading posts by
Checkmate.

On Sun, 26 Mar 2023 07:41:40 -0000 (UTC), Nadegda had the audacity to say
the following:

>
> According to kensi, someone has apparently reconfigured mixmin to block
> either posting in general, or posting by her specifically, and she's
> been locked out for 24 hours now. She tried switching back to AIOE, only
> to discover it's not been functioning for weeks (which is, quite frankly,
> ridiculous and unconscionable when it wouldn't take half a week to stand
> up a completely new NNTP server and point the domain name at that; the
> time being wasted trying to fix the RAID problem instead of just starting
> over from scratch isn't worth a bunch of old articles THAT WOULD HAVE ALL
> EXPIRED BY NOW ANYWAY).
>
> Anyway, kensi asked me to relay the following demand here in AFN:
>
> ----------
> Either restore mixmin to normal immediately, or restore AIOE to normal
> immediately. And stop monkeying with the free servers! Some people do not
> have any alternatives, for any of a variety of reasons.
> ----------
>
> That will be all for now.
>
> Be it known, though, that any hacker exposed as the culprit behind this
> latest problem will have me to answer to. Worse for them, at some point
> they will likely have kensi to answer to, as well, and believe me when I
> say that I've seen what happens to those kensi decides to utterly destroy,
> and it is NOT pretty. You could fill a whole wing of Parkview Hospital
> with them ...

That's some Funny Frothy Foam, Sybian* Cowgirl. Are you implying that your
alleged college Sock Professor Kensi can't even afford to pay for an NNTP
server? Maybe "she" should have majored in something important like gender
queer inequity caused by global warming by white cisgendered males, instead
of stupid shit like Astrophysics.

*For those who don't know... Nads' favorite toy:

https://youtu.be/_zOkhh5mXes

--
Checkmate ®
Copyright © 2023
all rights reserved

"its usually the lesser intelligent person , that comments
on the more intelligent person's , lack of intelligents
and we all think what we do has major significants"

-David Keeting, in perhaps the most ironic statement
ever made on Usenet.

https://youtu.be/wT-8Dm1VThc

https://youtu.be/NxSj2T2vx7M

Footloose! https://youtu.be/mXfVaXjBFK4

Kensi, "doing a little victory dance"
https://youtu.be/obInNk448nI
***************************************************
"I am the author of nearly as much kook butthurt as
kensi." -Nadegda
Message-ID: <pbg8ne$p9k$21@dont-email.me>
***************************************************

AUK Hammer of Thor award, Feb. 2012 (Pre-Burnore)
Destroyer of the AUK Ko0k Awards (Post-Burnore)
Co-winner Pierre Salinger Hook, Line & Sinker
award May 2001, (Brethern of Beelzebub troll)
Pierre Salinger Hook, Line & Sinker award, Feb 2012

Author, Humorist, Cynic
Philosopher, Humanitarian
Poet, Elektrishun to the Stars
Usenet Shot-Caller

In loving memory of The Battle Kitten
May 2010-February 12, 2017

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 11:57:44 -0600, Grant Taylor wrote:

> On 3/26/23 11:44 AM, Nadegda wrote:
>> As for DPI boxes, nobody should use them.
....
>> Basically, in the presence of pervasive end-to-end encryption the
>> only thing a DPI box can do that an ordinary perimeter firewall or
>> local antivirus can't is obstruct two third parties from talking
>> to each other even if they themselves both want to communicate (so,
>> censorship) and compile a list of who's talking to who (so, espionage).
>
> A perimeter firewall / router can easily obstruct two parties from
> talking to each other. You don't need DPI for that.
>
> A perimeter firewall / router can easily compile a list of who's
> talking. NetFlow and the likes are specifically meant for things like
> this. You don't need DPI for that either.

But those are typically owned by one of the endpoints, not a middleman
such as an ISP. OK, one of the endpoints (or both) could be a typical
corporate entity with an internally very authoritarian structure, but
that's a whole separate political can of worms.

I'm fine with doing whatever I want to on my own perimeter to keep out
malicious traffic and suchlike. I'm not fine with, say, my ISP doing so,
even with the best of intentions. If a tool I'm using is generating a
false positive that's then getting in my way, I can create an exception
or temporarily deactivate it or similarly. If a tool my ISP is using is
doing likewise, I'm stuffed. (What, call their support? You *must* be
joking. They'll just connect me to someone who knows less about what's
happening under the hood than *I* do. After putting me on hold for three
hours first.)

>> And breaks the end-to-end principle and therefore breaks the internet.
>
> DPI doesn't break the end-to-end principle.

Sure it does, since it makes whatever link it's attached to no longer just
a dumb pipe.

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

Time to trigger the right-wing snowflakes again. Melt, snowflakes, melt!
On Sun, 26 Mar 2023 20:00:14 +0000, Adam H. Kerman wrote:

> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>On 3/26/23 12:03 PM, Skeeter wrote:
>
>>>Nads is a liberal crybaby.
>
>>That may, or may not, be the case.
>
>>I don't particularly care.
>
>>If someone wants to have a polite and civil discussion about a topic
>>that I'm interested in, then I'll do so. At least until I get tired of
>>the discussion.
>
> Isn't it less difficult to see that the other person has a point if the
> other person doesn't repeatedly change socks to fake the existence of a
> disinterested third party supporting his position?
>
> "Nadegda" isn't pretending to be human except in Paul's own mind. (Paul
> has a mind? Yes yes, I know. Post proof, ko0ky.)
>
> There are still enough people on Usenet to speak to who don't morph
> continuously.
>
> I'm suggesting a fairly low bar here.

Hey, fuckhead. Yeah, you, fuckhead. I've been posting using this same nym
and email continually since 2012 or so -- so, more than a full decade.
That's about as non-morphy as one can get.

You can Google it if you don't believe me.

--
FNVWe Nadegda

"By all means, compare these shitheads to Nazis. Again and again. I'm with
you." -- Mike Godwin, Aug 13, 2017, 8:03 PM
Checkmate admits that, for all intents and purposes, he carries a teddy
bear in public: <d6cnes.ket.17.19@news.alt.net>

On 3/27/23 9:37 AM, Nadegda wrote:
> But those are typically owned by one of the endpoints, not a middleman
> such as an ISP. OK, one of the endpoints (or both) could be a typical
> corporate entity with an internally very authoritarian structure,
> but that's a whole separate political can of worms.

I have a friend that works for an international tier 1 backbone carrier
and they use NetFlow to monitor the routers in their network. They have
MANY tier 2 and tier 3 customers who's traffic is sampled as it passes
through the tier 1's global network.

The sampling they do is not interested in any specific flow and only
concerns itself with aggregate so that the tier 1 can grow their network
as necessary before things get congested.

The point being that /anyone/ in the path can instrument and / or filter.

> I'm fine with doing whatever I want to on my own perimeter to keep
> out malicious traffic and suchlike. I'm not fine with, say, my ISP
> doing so, even with the best of intentions. If a tool I'm using is
> generating a false positive that's then getting in my way, I can
> create an exception or temporarily deactivate it or similarly. If a
> tool my ISP is using is doing likewise, I'm stuffed. (What, call their
> support? You *must* be joking. They'll just connect me to someone who
> knows less about what's happening under the hood than *I* do. After
> putting me on hold for three hours first.)

It's highly dependent.

I'm /okay/ with ISPs having a /default/ filtering policy as long as it's
documented and there are options to change the default.

I was just skimming the Broadband Internet Technical Advisory Group's
Port Blocking recommendation a couple of days ago.

Read - BITAG - Port Blocking (PDF)
- https://www.bitag.org/documents/Port-Blocking.pdf

Here's some germane copy (from pages ii and iii):

- ISPs should avoid port blocking unless they have no reasonable
alternatives available for preventing unwanted traffic and protecting users.

- ISPs that can reasonably provide to their users opt-­out provisions
or exceptions to their port blocking policies should do so.

- ISPs should publicly disclose their port blocking policies.

- ISPs should make communications channels available for feedback
about port blocking policies.

- ISPs should revisit their port blocking policies on a regular basis
and reassess whether the threats that required the port blocking rules
continue to be relevant.

- Port blocking (or firewall) rules of consumers’ devices should be
user-­configurable.

I used to do business, many years ago before moving, with an ISP that
had what they called a "Good 'Net Neighbor" configuration that they
/defaulted/ to and requested clients use if they could. From memory,
GNN consisted of the following:

- Block TCP & UDP ports 135, 137, 138, 139, and 445.

> Sure it does, since it makes whatever link it's attached to no longer
> just a dumb pipe.

Nothing guarantees that any given endpoints will be able to communicate.
There are a lot of things that can break that. DPI doesn't
substantively change that in any way. It's just another tool in the
tool box to do what is already being done.

--
Grant. . . .
unix || die

Warning! Always wear ANSI approved safety goggles when reading posts by
Checkmate.

On Mon, 27 Mar 2023 15:37:07 -0000 (UTC), Nadegda had the audacity to say
the following:

> But those are typically owned by one of the endpoints, not a middleman
> such as an ISP. OK, one of the endpoints (or both) could be a typical
> corporate entity with an internally very authoritarian structure, but
> that's a whole separate political can of worms.
>
> I'm fine with doing whatever I want to on my own perimeter to keep out
> malicious traffic and suchlike. I'm not fine with, say, my ISP doing so,
> even with the best of intentions. If a tool I'm using is generating a
> false positive that's then getting in my way, I can create an exception
> or temporarily deactivate it or similarly. If a tool my ISP is using is
> doing likewise, I'm stuffed. (What, call their support? You *must* be
> joking. They'll just connect me to someone who knows less about what's
> happening under the hood than *I* do. After putting me on hold for three
> hours first.)
>

It's like this, NaddlebeRRy: Those who choose to use free servers have no
say in how the operator chooses to run the server. If you don't like it,
kick rocks.

--
Checkmate ®
Copyright © 2023
all rights reserved

"its usually the lesser intelligent person , that comments
on the more intelligent person's , lack of intelligents
and we all think what we do has major significants"

-David Keeting, in perhaps the most ironic statement
ever made on Usenet.

https://youtu.be/wT-8Dm1VThc

https://youtu.be/NxSj2T2vx7M

Footloose! https://youtu.be/mXfVaXjBFK4

Kensi, "doing a little victory dance"
https://youtu.be/obInNk448nI
***************************************************
"I am the author of nearly as much kook butthurt as
kensi." -Nadegda
Message-ID: <pbg8ne$p9k$21@dont-email.me>
***************************************************

AUK Hammer of Thor award, Feb. 2012 (Pre-Burnore)
Destroyer of the AUK Ko0k Awards (Post-Burnore)
Co-winner Pierre Salinger Hook, Line & Sinker
award May 2001, (Brethern of Beelzebub troll)
Pierre Salinger Hook, Line & Sinker award, Feb 2012

Author, Humorist, Cynic
Philosopher, Humanitarian
Poet, Elektrishun to the Stars
Usenet Shot-Caller

In loving memory of The Battle Kitten
May 2010-February 12, 2017

Warning! Always wear ANSI approved safety goggles when reading posts by
Checkmate.

On Mon, 27 Mar 2023 15:41:10 -0000 (UTC), Nadegda had the audacity to say
the following:

> Hey, fuckhead. Yeah, you, fuckhead. I've been posting using this same nym
> and email continually since 2012 or so -- so, more than a full decade.
> That's about as non-morphy as one can get.
>

n00b!

--
Checkmate ®
Copyright © 2023
all rights reserved

"its usually the lesser intelligent person , that comments
on the more intelligent person's , lack of intelligents
and we all think what we do has major significants"

-David Keeting, in perhaps the most ironic statement
ever made on Usenet.

https://youtu.be/wT-8Dm1VThc

https://youtu.be/NxSj2T2vx7M

Footloose! https://youtu.be/mXfVaXjBFK4

Kensi, "doing a little victory dance"
https://youtu.be/obInNk448nI
***************************************************
"I am the author of nearly as much kook butthurt as
kensi." -Nadegda
Message-ID: <pbg8ne$p9k$21@dont-email.me>
***************************************************

AUK Hammer of Thor award, Feb. 2012 (Pre-Burnore)
Destroyer of the AUK Ko0k Awards (Post-Burnore)
Co-winner Pierre Salinger Hook, Line & Sinker
award May 2001, (Brethern of Beelzebub troll)
Pierre Salinger Hook, Line & Sinker award, Feb 2012

Author, Humorist, Cynic
Philosopher, Humanitarian
Poet, Elektrishun to the Stars
Usenet Shot-Caller

In loving memory of The Battle Kitten
May 2010-February 12, 2017