Tor forcing servers to fall off the top of the world?
Citizen.Kaine
Newsgroups:
alt.flame,alt.2600,alt.wired,alt.cyberpunk,alt.usenet.kooks,alt.hackers.malicious
Subject: Re: Fat Matter Blows a Tire - (mad high ports open on Linux
bAwwx)
Date: Sun, 28 Jun 2009 02:03:35 -0400
Message-ID: <h2715l$bsr$1...@news.albasani.net>
References:
<d407c87a-e483-4510...@c36g2000yqn.googlegroups.com>
<Xns9C379D33FD...@194.177.98.144>
<115d45di4qah7dqaa...@4ax.com>
How To Stay On Usenet Forever
(Even If You're A Total Net.Asswipe And Get TOSsed Every 2 Hours)
Tor up, get a Motzarella account, you're back as soon as they let you
connect through the exit nodes. Takes a day at the most.
Make two accounts. That way if one gets closed you can use the other
while you make a new one.
The Motzarella dumbasses won't know it's all you if you always use Tor
for everything (including e-mail comms with them). Run your e-mails
through Babelfish twice (your native language --> some other language
--> back to your native language again) and it sounds even more like a
different person because the translations will fuck up everything you
write but in a way that is still understandable.
HTH
______________________________________________________
Is there a line to be drawn?
Rosebud
VanguardLH
won't post to binary groups, and the original post and mine do not
contain binaries, anyway.
Citizen.Kaine wrote:
> From: The Monitor <the.newsgr...@googlemail.com>
> Newsgroups: alt.flame,alt.2600,alt.wired,alt.cyberpunk,alt.usenet.kooks,alt.hackers.malicious
> Subject: Re: Fat Matter Blows a Tire - (mad high ports open on Linux bAwwx)
> Date: Sun, 28 Jun 2009 02:03:35 -0400
> Message-ID: <h2715l$bsr$1...@news.albasani.net>
>
> How To Stay On Usenet Forever
> (Even If You're A Total Net.Asswipe And Get TOSsed Every 2 Hours)
>
> Tor up, get a Motzarella account, you're back as soon as they let you
> connect through the exit nodes. Takes a day at the most.
>
> Make two accounts. That way if one gets closed you can use the other
> while you make a new one.
>
> The Motzarella dumbasses won't know it's all you if you always use Tor
> for everything (including e-mail comms with them). Run your e-mails
> through Babelfish twice (your native language --> some other language
> --> back to your native language again) and it sounds even more like a
> different person because the translations will fuck up everything you
> write but in a way that is still understandable.
> ______________________________________________________
>
> Is there a line to be drawn?
And why I've asked Ray if he could have the username portion (before teh
@domain) of the Message-ID header modified to include an obfuscated copy
of the poster's IP address. A obfuscated portion of the username field
would remain fixed based on the poster's IP address. They get a Net
identity based on their IP address but only the NNTP server knows what
is the actual IP address. AIOE does this which makes it possible to
continue killfiling an unwanted poster despite their nymshifting. He
claims that he wants to remain RFC compliant (whereas AIOE's MID header
currently is not) but that doesn't explain why he cannot remain
compliant and still obfuscate the IP address in a portion of the
username field. Yes, there are ways to get around IP identification but
if the poster is nuisanced enough then perhaps they'll surrender. Even
if not nuisanced enough to surrender, what they don't realize is that
they have been punished by having to go through all their machinations.
Citizen.Kaine
>NOTE: alt.binaries.news-server-comparison was removed from my reply. I
> won't post to binary groups, and the original post and mine do not
> contain binaries, anyway.
>
alt.binaries.news-server-comparison is a discussion group.
Binary posts are not permitted to alt.binaries.news-server-comparison.
You are basing your suggestion on cable connected users.
Rosebud
Ray Banana
> And why I've asked Ray if he could have the username portion (before teh
> @domain) of the Message-ID header modified to include an obfuscated copy
> of the poster's IP address. A obfuscated portion of the username field
> would remain fixed based on the poster's IP address. They get a Net
> identity based on their IP address but only the NNTP server knows what
> is the actual IP address. AIOE does this which makes it possible to
> continue killfiling an unwanted poster despite their nymshifting.
You are confusing NNTP-Posting-Host and Message-ID headers (again).
The local part of a Message-ID is different for every single posting and
hence not suitable for filtering. The NNTP-Posting-Host header is
defined in RFC 2980 and its content should be the result of a reverse
DNS lookup of the IP address and not some munged representation of an IP
address + the DNS name of the news server. As this header is defined as
optional, I prefer to omit it rather than publish some misleading
information.
> Yes, there are ways to get around IP identification but
> if the poster is nuisanced enough then perhaps they'll surrender. Even
> if not nuisanced enough to surrender, what they don't realize is that
> they have been punished by having to go through all their machinations.
The assumption that an IP address (munged or not) establishes some sort
of "net identity" of the person who posted a particular article is
basically wrong. Many ISPs assign different IP addresses for each new
connection from the same customer, others even force a change of the IP
address several times a day, in some environments several users share
the IP address of a gateway or proxy server and so on. IP addresses are
meaningless and useless as a means to identify a particular person over an
extended period of time (> 1 day).
For users connecting via Tor the IP address is utterly useless as a
distinctive feature, as only the IP address of the exit node is visible
to the server they connect to.
--
Time flies like an arrow, fruit flies like a Banana.
http://www.eternal-september.org
VanguardLH
> On 5780 September 1993, V...@nguard.LH wrote:
>
>> And why I've asked Ray if he could have the username portion (before teh
>> @domain) of the Message-ID header modified to include an obfuscated copy
>> of the poster's IP address. A obfuscated portion of the username field
>> would remain fixed based on the poster's IP address. They get a Net
>> identity based on their IP address but only the NNTP server knows what
>> is the actual IP address. AIOE does this which makes it possible to
>> continue killfiling an unwanted poster despite their nymshifting.
>
> You are confusing NNTP-Posting-Host and Message-ID headers (again).
Yikes, yep, you're right.
> The local part of a Message-ID is different for every single posting and
> hence not suitable for filtering.
I thought the requirement is that the MID be unique. So why can't a
portion before the @ be fixed to represent the obfuscated IP address and
the rest be dynamically generated so the entire string (fixed+variable)
is still unique?
The problem is that NNTP servers do not overwrite the MID header if one
is already included. If the user's client adds a MID header, that's the
one that gets used, right? Would there be a problem if the NNTP server
*did* overwrite the MID header with one that it generates?
> The assumption that an IP address (munged or not) establishes some sort
> of "net identity" of the person who posted a particular article is
> basically wrong.
Yet for many unwanted posters, it can be seen that their IP addresses
don't change for many months. Well, what else do we *users* have in
trying to identify certain posters to filter? We have what we get and
often what we get is too minimal to define a reasonable filter that
targets well just the one unwanted poster. That the filter may only
survive a month or two is still good enough to get rid some of the noise
today. Despite the lack of support from the NNTP servers to give us
reasonable information on which to filter, we are still going to filter.
Aioe
> AIOE does this which makes it possible to
> continue killfiling an unwanted poster despite their nymshifting. He
> claims that he wants to remain RFC compliant (whereas AIOE's MID header
> currently is not)
only two things: aioe.org message-ids *are* RFC complaints. With tor ip
addresses are useless (and for this TOR is forbidden here)
Whiskers
> Ray Banana wrote:
>> On 5780 September 1993, V...@nguard.LH wrote:
[...]
> Would there be a problem if the NNTP server
> *did* overwrite the MID header with one that it generates?
[...]
Yes.
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
VanguardLH
> VanguardLH wrote:
>>
>> Would there be a problem if the NNTP server *did* overwrite the MID
>> header with one that it generates?
>
> Yes.
And why?
How is uniqueness guaranteed by multiple clients who are generating
their own MIDs and who use the same FQDN but are submitting their posts
to different NNTP servers? For users of the same NNTP client software
that can generate its own MIDs, all those users are posting with the
same FQDN. These clients are not in a mesh network amongst themselves
or sharing a database where they check that the MID they generate has
not been used by another client using the same FQDN. Those clients
can't determine their generated MIDs are globally unique. Seems like
MID collisions are inevitable, so who handles them?
Since peering is not instantaneous across all peered NNTP servers, and
because clients could generate the same MID but post to different NNTP
servers, how is the collision handled when an NNTP server does get
around to peering with the other NNTP servers?
RFC 3977:
If the server does not have any way to determine a message-id from the
article itself, it MUST synthesize one.
Sure seems like the NNTP server is allowed to generate its own MID even
if one was included by the client (but which the NNTP server couldn't
determine what it was). So why can't the NNTP server be made blind to
client-generated MIDs so they generate their own? It wouldn't be blind
to the NNTP servers to which it peers but it seems it could be blind to
MIDs in messages from clients (which would include users running their
own leeching servers, like Hamster). It seems obvious that an NNTP
server would know with who it peers versus clients submitting posts to
it (which would include users running their own servers).
Do collisions always result in a rejection of the message? If so, which
message gets rejected: the one on the NNTP server which is peering
elsewhere or the article from other NNTP server to which it is peering?
I saw mention that mail2news gateway might have to invent a new MID when
they detect a collision. That isn't something an NNTP server (as a
non-peered client) can do, too?
How does a server get notified there is a collision? Is that when it
attempts to post to another server? Is it just a rejection error or is
a specific error returned to notify the sending server that their
article has been rejected due to a MID collision? In either case, why
can't the sender generate a new MID to workaround the rejection? A
server might but I can see clients (like Forte Agent) might not be able
to do this (but then the cure for those clients would be to NOT generate
their own MIDs).
NNTP servers can always place restrictions or requirements on clients,
like using SSL to connect, which port to use, max connects per day
(Motzy allows 1200), max posts per day (AIOE allows 25), or other setup.
So why can't an NNTP server stipulate that it will ignore MIDs generated
by its clients and use its own?
Whiskers
>> VanguardLH wrote:
>>>
>>> Would there be a problem if the NNTP server *did* overwrite the MID
>>> header with one that it generates?
>>
>> Yes.
>
> And why?
Because it would interfere with those of us who generate personal MIDs to
facilitate scoring-up of responses to our own posts (or to allow others to
plonk us easily <grin>).
> How is uniqueness guaranteed by multiple clients who are generating
> their own MIDs and who use the same FQDN but are submitting their posts
> to different NNTP servers? For users of the same NNTP client software
> that can generate its own MIDs, all those users are posting with the
> same FQDN.
You don't look at headers much, do you! There is one usenet client
that defaults to 'the same FQDN' for all users - Forte 'Agent' (and 'Free
Agent' of course). Web-site posting services (eg Google Groups) usually
give their users all the same FQDN, too. But as far as I know all other
usenet clients default to the 'name' of the machine they are running on,
or to the domain name of the upstream news-server - and most also allow
the user to assign their own FQDN of course, which is the ideal
arrangement. (I dimly remember reading somewhere that 'Agent' can be made
to use a personal FQDN too, although few users seem to do so).
> These clients are not in a mesh network amongst themselves
> or sharing a database where they check that the MID they generate has
> not been used by another client using the same FQDN. Those clients
> can't determine their generated MIDs are globally unique. Seems like
> MID collisions are inevitable, so who handles them?
It doesn't seem to be a problem in practice. Each program used for
generating MIDs has its own algorithm, often taking into account both the
date and time of posting and a random element - as well as an optional
personal element, to the left of the @ sign, in some cases, and perhaps
something to identify the software generating the MID. (Note that I don't
assume the 'newsreader' program itself generates the MID; most can and do,
but other arrangements are possible).
All that, plus the fact that (apart from archives, which should have their
own index system anyway) articles are purged from the servers after 'a
little while' (hours to years), seems to mean that MID duplication is not
worth worrying about.
[...]
> NNTP servers can always place restrictions or requirements on clients,
> like using SSL to connect, which port to use, max connects per day
> (Motzy allows 1200), max posts per day (AIOE allows 25), or other setup.
> So why can't an NNTP server stipulate that it will ignore MIDs generated
> by its clients and use its own?
A news admin could indeed impose his own MIDs on all articles injected by
his users. I've even heard that at least one does just that. But that
really helps no-one, and I would not want to use a server that did that
sort of thing. It makes articles *less* traceable to the poster, not more
so.
VanguardLH
> VanguardLH wrote:
>>
>> Whiskers wrote:
>>>
>>> VanguardLH wrote:
>>>>
>>>> Would there be a problem if the NNTP server *did* overwrite the
>>>> MID header with one that it generates?
>>>
>>> Yes.
>>
>> And why?
>
> Because it would interfere with those of us who generate personal
> MIDs to facilitate scoring-up of responses to our own posts (or to
> allow others to plonk us easily <grin>).
I guess my preference is towards a community feature rather than worry
about individual features. Since MID collisions are possible, it seems
the NNTP server needs to handle them. However, it is unlikely that
client programs would recover and invent a new MID when a collision was
detected.
>> How is uniqueness guaranteed by multiple clients who are generating
>> their own MIDs and who use the same FQDN but are submitting their
>> posts to different NNTP servers? For users of the same NNTP client
>> software that can generate its own MIDs, all those users are posting
>> with the same FQDN.
>
> You don't look at headers much, do you! There is one usenet client
> that defaults to 'the same FQDN' for all users - Forte 'Agent' (and
> 'Free Agent' of course).
So, as I asked, how do those independent clients using the same FQDN
ensure that they are generating a globally unique MID? They can't.
> Web-site posting services (eg Google Groups) usually give their users
> all the same FQDN, too.
With all posters going through there getting the same FQDN and with the
MID generated by the server, not by the web browser using user.
> But as far as I know all other usenet clients default to the 'name' of
> the machine they are running on, or to the domain name of the
> upstream news-server - and most also allow the user to assign their
> own FQDN of course, which is the ideal arrangement.
And there is some organization to ensure these users that are selecting
their own FQDNs are using unique ones? Didn't think so.
>> These clients are not in a mesh network amongst themselves or sharing
>> a database where they check that the MID they generate has not been
>> used by another client using the same FQDN. Those clients can't
>> determine their generated MIDs are globally unique. Seems like MID
>> collisions are inevitable, so who handles them?
>
> It doesn't seem to be a problem in practice.
Do you operate a peered NNTP server to understand how collisions are
handled? I don't and why I asked.
> Each program used for generating MIDs has its own algorithm, often
> taking into account both the date and time of posting and a random
> element - as well as an optional personal element, to the left of the
> @ sign, in some cases, and perhaps something to identify the software
> generating the MID. (Note that I don't assume the 'newsreader'
> program itself generates the MID; most can and do, but other
> arrangements are possible).
Trying to make something unique doesn't it will be.
>> NNTP servers can always place restrictions or requirements on
>> clients, like using SSL to connect, which port to use, max connects
>> per day (Motzy allows 1200), max posts per day (AIOE allows 25), or
>> other setup. So why can't an NNTP server stipulate that it will
>> ignore MIDs generated by its clients and use its own?
>
> A news admin could indeed impose his own MIDs on all articles
> injected by his users. I've even heard that at least one does just
> that. But that really helps no-one, and I would not want to use a
> server that did that sort of thing. It makes articles *less*
> traceable to the poster, not more so.
Since the user can alter what MID is generated by their client, how are
they more traceable? For users that are sharing the *same* FQDN, as is
the case for Forte Agent users, just how are they more traceable than
if the MID were unique through the NNTP server that they used?
I was actually hoping Ray might come back since he does run an NNTP
service and might be familiar with what happens with MID collisions and
if there really was a problem with NNTP servers using their own MIDs
instead of electing to use the one the client generated. He might be a
little too busy right now after the file system problem with his
servers from yesterday.
Curt Welch
> Whiskers wrote:
>
> > VanguardLH wrote:
> >>
> >> Would there be a problem if the NNTP server *did* overwrite the MID
> >> header with one that it generates?
> >
> > Yes.
I think some servers have done that in the past even if it is a problem.
It only creates minor problems if you do it.
> And why?
Because it's been a standard in NNTP to allow clients to generate there own
Message-IDs for a very long time and as result, some clients take advantage
of that fact in different ways. You would break any client which did so.
Such as checking to see if the message shows up on the server by trying to
fetch it with the Message-ID the client put on the Article. Some people
put unique personal markers in the message-ids which makes it easier to
find followups to their articles. Some binary posting systems put id
information in the message id. Some ideas have been proposed to put binary
file hash values in the message-ids.
> How is uniqueness guaranteed by multiple clients who are generating
> their own MIDs and who use the same FQDN but are submitting their posts
> to different NNTP servers? For users of the same NNTP client software
> that can generate its own MIDs, all those users are posting with the
> same FQDN. These clients are not in a mesh network amongst themselves
> or sharing a database where they check that the MID they generate has
> not been used by another client using the same FQDN. Those clients
> can't determine their generated MIDs are globally unique. Seems like
> MID collisions are inevitable, so who handles them?
Uniqueness can never be guaranteed. That's just a fact of distributed
systems. If two people posted with the same ID nothing really bad happens.
It just means that no server will get both messages. Every server has
one, or the other, but not both. Whichever they receive first, is the one
they get a copy of. So it just means the articles fail to correctly
propagate to all servers, and if anyone started to reference the article by
Message-ID they might not get the article they thought they were getting.
This is Usenet. There is no expectation of perfect propagation of all
articles. Articles get dropped, or rejected, all the time. 1000's of
articles get rejected and dropped on a typical server every day. But they
are dropped because they are invalid or odd in some way, so the "good
stuff" never gets dropped.
The trick is not to assume we MUST create uniqueness in Message-IDs because
we can't. The truth is that the real goal is to reduce the probability of
a duplicate to such a small number, that it no longer becomes significant.
That is, we have so few collisions, that no one even notices when they do
happen.
That as it turns out, is very easy to do, and that's exactly what the
clients that share the same FQDN do.
You make that work by first adding bits to the message-id to indicate the
current time (as best you know it), then you simply add random bits. The
more random bits you add, the more you reduce the expected time between
collisions. It's easy to reduce the expected time between collisions to
over 100 years at which point the error rate is no longer significant
because other forms of erros that prevent proper propagation become larger
(like hardware failures).
> Since peering is not instantaneous across all peered NNTP servers, and
> because clients could generate the same MID but post to different NNTP
> servers, how is the collision handled when an NNTP server does get
> around to peering with the other NNTP servers?
It's not handled. It doesn't need to be handled.
> RFC 3977:
> If the server does not have any way to determine a message-id from the
> article itself, it MUST synthesize one.
>
> Sure seems like the NNTP server is allowed to generate its own MID even
> if one was included by the client (but which the NNTP server couldn't
> determine what it was).
That's a silly argument. :)
The headers are exactly defined. Either the article is valid, and it
includes a message-id, it valid, but doesn't include a message-id, or it's
invalid. There is no way possible for it to be valid and "the server not
know if the message-id is there". That's just silly.
> So why can't the NNTP server be made blind to
> client-generated MIDs so they generate their own?
As I said, some have in the past. It's just not the standard however. It
works without causing major issues, but some features of some clients that
worked on other servers, would not work on a server which replaced the
Message-Id with it's own.
> It wouldn't be blind
> to the NNTP servers to which it peers but it seems it could be blind to
> MIDs in messages from clients (which would include users running their
> own leeching servers, like Hamster). It seems obvious that an NNTP
> server would know with who it peers versus clients submitting posts to
> it (which would include users running their own servers).
People have, in the past, made the error of trying to feed articles to a
peer using the POST command. That's wrong on many levels for many reasons
(mostly subtle - but all very important). It happens when someone tries to
use a user account to act like a peer where they fetch articles from one
place (like an email list) and inject them into Usenet with a Post
command). These techniques are dangerous and have caused nasty problems
multiple times on Usenet in the past when they end up creating loops. If
one person feeds from an email list to Usenet, and some other idiot then
tries to feed from Usenet, back to the email list, and they assume
duplication will be prevented by Message-ID, then the minute some system in
the path decided to change the message-id (as you are suggesting) it
creates a loop which causes the same article to keep getting reposted to
Usenet over and over and over - each time getting a new Message-Id.
Not overriding the Message-ID supplied helps reduce that nasty problem (but
the people setting up the cross feeds should be shot first).
> Do collisions always result in a rejection of the message? If so, which
> message gets rejected: the one on the NNTP server which is peering
> elsewhere or the article from other NNTP server to which it is peering?
> I saw mention that mail2news gateway might have to invent a new MID when
> they detect a collision. That isn't something an NNTP server (as a
> non-peered client) can do, too?
Peering is fairly simple in theory (though the implementation actually gets
very tricky). The sending side offers the article by sending the
message-id. The receiving side then checks to see if it already has that
message-id. If it does, it sends back a response saying it doesn't what
the article. If it doesn't, then it sends back a response saying it does
want the article, and then the sending side sends it.
If two articles were posted with the same Message-Id, it would simply be a
race to see which article gets to which servers first. Whichever article
gets there first, is the one that server gets a copy of. So we would just
end up with a situation that ever server has one aritlce or the other, but
none have both.
> How does a server get notified there is a collision?
The servers never notice there was a collision. Nobody gets notified there
is a collision. For the most part, no one would notice it happened. To
notice it, you would have to check every article on one server, against
every article on another, to see if you had two with the same Message-Id.
Nobody normally does anything like that because for the most part, it's a
total waste of time.
Only if someone had access to many servers, and took the time to carefully
compare articles, would they notice it.
> Is that when it
> attempts to post to another server?
We don't call it "post" when we are feeding articles to a peer. We call it
feeding an article. It's done the NNTP command IHAVE or with CHECK and
TAKETHIS. Those commands are configured to only work on a server which is
talking to a peer. They don't work for normal end user connections.
New articles get added to Usenet by end users with the POST command.
If a user provides a message-id, it is checked to see if the message-id
already exists on the server. If it does, the post is rejected and the
user that sees an error message. Servers only keep track of the
message-ids they have seen recently (what's in their spools and sometimes
for a bit longer). How long that is depends on teh server. It might be
only hours, or might be a year.
Small articles like text articles move though the major server very
quickly, (bounces around the world a few times in less than a second).
Large binary posts move much slower. None the less, most servers get
copies very quickly. This means that if you try to create a dup by posting
to two servers with the same Message-Id, you have to do it within a second
or two most the time or else the slower message gets rejected before it's
even posted to the first server.
It's hard to even intentionally create a dup that way.
However, it's easy to find a message-id from a very old article, and then
post a new message with the same message-id as the old one. That in
general works just fine, but now we don't have historical uniqueness which
creates issues for archives. It's just not nice. :)
> Is it just a rejection error or is
> a specific error returned to notify the sending server that their
> article has been rejected due to a MID collision?
MID collision is the norm. It's not an error. You expect to be offered
messages you already have copy of from another peer.
The return status is just "I already have it, you don't need to send it to
me."
The server has no clue (and no way of knowing) that the article being
offered is actually a different article with the same message-id.
> In either case, why
> can't the sender generate a new MID to workaround the rejection? A
> server might but I can see clients (like Forte Agent) might not be able
> to do this (but then the cure for those clients would be to NOT generate
> their own MIDs).
The server must never generate a new MID on a reject. That would cause the
same article to be duplicated over and over and over.
See how that works? Server A gets the article from a POST command and
offeres it to peers B and C, who both take a copy of it. Peer B offers it
to C who says "I alrady have the MID". Peer C offers it to B who also says
"I already have it". Now peer B assigns a new MID and sends it to C. C
takes it. But now it's got two copies of the same article, with different
message ids. So now the article shows up twice in the newsgroup it was
posted to.
Peer C also assigns a new Message-ID to it, and sends it to B. Now B has
two copies of.
B and C send their new copies to A. A takes it because it's never seen
those MIDs. Now A has three copies of the article with 3 different MIDs.
A offers those to B and C. They reject them because they already have
them. A makes up new MIDS and sends to the B and C, ...
Within seconds, the servers are flooded with 1000s of copies of the same
article all with different message-ids. And it's just getting worse and
worse as each server keeps making more and more copies of the articles as
their peers reject them based on the old MID.
Servers should never change the MID of an article or else all chose breaks
out. And that's part of why they also shouldn't do it for what should be
new articles given with a POST command.
> NNTP servers can always place restrictions or requirements on clients,
> like using SSL to connect, which port to use, max connects per day
> (Motzy allows 1200), max posts per day (AIOE allows 25), or other setup.
> So why can't an NNTP server stipulate that it will ignore MIDs generated
> by its clients and use its own?
NNTP serves can do anything the guy who owns the server want's it to do. I
can make my server spot all of your articles, and add a line to the bottom
that says "I just wanted to add this line here to show I could do it". But
if my server causes problems on Usenet for other admins, and for users,
then great pressure will be placed on my by the community to fix it.
If you want to run a server and have it add it's own message-ids you can do
that. But expect that some users won't want to use your server because of
the fact you do that. And you run the risk of some user trying to do a
feed from some other place to Usenet though your server, and if you change
MIDs it might cause a flood problem. But as long as you are quick to spot
such a problem and put an end it, you can do it.
But it's not the standard, and it's not the standard for fairly reasonable
reasons.
--
Curt Welch http://CurtWelch.Com/
cu...@kcwc.com http://NewsReader.Com/
David W. Hodgins
> So, as I asked, how do those independent clients using the same FQDN
> ensure that they are generating a globally unique MID? They can't.
It's up to the user and the software they use, to ensure a globally
unique message id is generated.
In the case of forte agent, where most of it's users are using 4ax.com
as the domain name, see
http://groups.google.ca/group/alt.usenet.offline-reader.forte-agent/msg/fc61ddfd1330ce8f?
for an explanation (by the author) of how it generates unique ids.
If two articles are posted to the same server, with the same message id,
the second will get rejected. What happens when it's rejected depends
is up to the software doing the posting. It can either generate a new
message id, and try again, or it can notify the user, and let them
figure out what to do. This will also happen if the first article has
already propagated to a second server, and an attempt to post an article
with the same messageid is made.
If the two articles are posted to different servers, and then a peering
attempt trys to propagate them, both servers will reject the other
servers article, and will each keep the version they originally
received. Again, while this could happen in theory, I'm not aware of
any cases where it has, without the user forcing it to happen.
The uniqueness of messageid generation by current newsreaders, and
the speed of propagation between most servers makes the a problem not
worth worrying about.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
VanguardLH
I was thinking the servers that found they had a common MID and rejected
each other's articles could invent a new MID and then resubmit the
articles. However, I suppose some clients might have already downloaded
the accepted article and have that MID so if their server changed it (to
peer it elsewhere) that the client would then get an error saying no
such article existed (because it wouldn't under the old MID that got
changed).
So it seems the only way an NNTP server could include the obfuscated IP
address of the poster would be if it also ignored the MIDs from its
clients and always used its own MIDs. But, according to others, the
server overwriting the MID (or ignoring and using its own MID) causes
problems with how others expect MIDs to work.
Well, looks like the idea of obfuscating the poster's IP address into
the MID got shot down and is laying in embers. I wish I could remember
back but it seems that I did once use an NNTP server that always
generated its own MIDs.
VanguardLH
So it looks like the server overwriting the MID can cause too many
problems. Well, perhaps the server could insert its own header to track
the identity of its clients (without providing any personal info). I've
seen the X-Trace header used but that only gives info back to the server
admin. That header doesn't seem to have a fixed section within it where
a substring would contain the poster's identity (either as their account
ID with that NSP or with their obfuscated IP address).
Curt Welch
> David W. Hodgins wrote:
>
> > On Mon, 29 Jun 2009 15:32:35 -0400, VanguardLH <V...@nguard.lh> wrote:
> >
> >> So, as I asked, how do those independent clients using the same FQDN
> >> ensure that they are generating a globally unique MID? They can't.
> >
> > It's up to the user and the software they use, to ensure a globally
> > unique message id is generated.
> >
> > In the case of forte agent, where most of it's users are using 4ax.com
> > as the domain name, see
> > http://groups.google.ca/group/alt.usenet.offline-reader.forte-agent/msg
For some reason, I'm thinking it was altopia that used to do it.
Curt Welch
What problem are you trying to solve exactly? I didn't see the beginning
of this thread.
X-Trace on Diablo servers includes the time, the host name of the server it
was posted from, the process number of the process that did the post, the
user's id, and their IP address, and the port number for the server side of
the connection (I think) - all encrypted so only the admin (hopefully) can
decode it. You can put anything you want into an X-Trace header or you can
add any other header you feel like to put the data in.
murphy
Easy enough to catch up on:
MiD:<h27shk$303$1...@news.eternal-september.org>
VLH is seeking a solution to uniqueness for his(?) scoring
as a function generated by the server.
>X-Trace on Diablo servers includes the time, the host name of the server it
>was posted from, the process number of the process that did the post, the
>user's id, and their IP address, and the port number for the server side of
>the connection (I think) - all encrypted so only the admin (hopefully) can
>decode it. You can put anything you want into an X-Trace header or you can
>add any other header you feel like to put the data in.
>
The discussion is focused on text posts yet it is more likely to have
collisions with the masses of binary articles distributed, surely?
I do recall quantities of missing parts to binary articles being
reported from time to time with ISP hosted spools, and assumed
this was just a reflection of retention and article count failures.
Maybe the actual case was rejection of a series of same string MiD?
Agent has long been configurable to use POST in supplying
a "homemade" MiD string devoid of 4ax.com.
VLH appears to desire all servers to generate something
which effectively is the users responsibility to invoke.
The risk of passing an identifier, not of the posters choosing,
to a reader is maybe a huge factor for some in choosing a
server to post from. That's "post anything", not just some
lame flame.
X-Trace works for the purpose of server administration,
and legislation in some lands, why not just leave it at that.
murphy
--
"dog, eye that goose!"
Wal
http://www.oneil.com.au/footrot/
TMM
> Tor up
[...]
> [...] won't know it's all you if you always use Tor [...]
Adding RBL-checks into "everything you use", easily gets rid of such
problems.