FAQ

Frequently Asked Questions:

Q: Why don’t you implement the “ihave” command?

A: Because it’s not worth it. I won’t make you (more) anonymous. It won’t allow you to override the Path value, so it doesn’t bring anything different to the upload hence not worth it to implement. From RFC 1036 (the bold is mine).

2.1.6. Path

This line shows the path the message took to reach the current system. When a system forwards the message, it should add its own name to the list of systems in the “Path” line. The names may be separated by any punctuation character or characters (except “.” which is considered part of the hostname). Thus, the following are valid entries:

cbosgd!mhuxj!mhuxt cbosgd, mhuxj, mhuxt @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM teklabs, zehntel, sri-unix@cca!decvax

(The latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) Additional names should be added from the left. For example, the most recently added name in the fourth example was teklabs. Letters, digits, periods and hyphens are considered part of host names; other punctuation, including blanks, are considered separators.

Normally, the rightmost name will be the name of the originating system. However, it is also permissible to include an extra entry on the right, which is the name of the sender. This is for upward compatibility with older systems.

The “Path” line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message traveled to reach the local host. There are several uses for this information. One is to monitor USENET routing for performance reasons. Another is to establish a path to reach new hosts. Perhaps the most important use is to cut down on redundant USENET traffic by failing to forward a message to a host that is known to have already received it. In particular, when host A sends a message to host B, the “Path” line includes A, so that host B will not immediately send the message back to host A. The name each host uses to identify itself should be the same as the name by which its neighbors know it, in order to make this optimization possible.

A host adds its own name to the front of a path when it receives a message from another host. Thus, if a message with path “A!X!Y!Z” is passed from host A to host B, B will add its own name to the path when it receives the message from A, e.g., “B!A!X!Y!Z”. If B then passes the message on to C, the message sent to C will contain the path “B!A!X!Y!Z”, and when C receives it, C will change it to “C!B!A!X!Y!Z”.

Special upward compatibility note: Since the “From”, “Sender”, and “Reply-To” lines are in Internet format, and since many USENET hosts do not yet have mailers capable of understanding Internet format, it would break the reply capability to completely sever the connection between the “Path” header and the reply function. It is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. However, the existing convention of placing the host name and an “!” at the front of the path, and of starting the path with the host name, an “!”, and the user name, should be maintained when possible.

So every host will append their hostname to the path line. Real example:

281 Authentication accepted.
ihave <asdhs47ewue@t32qtsdruhjdr>
335 Send article to be transferred.
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: [email protected]
Newsgroups: alt.binaries.test
Message-ID: <sdhs47ewue@t32qtsdruhjdr>
Subject: This is my test

this is my test
.
235 Transferred <sdhs47ewue@t32qtsdruhjdr>
head <sdhs47ewue@t32qtsdruhjdr>
221 0 <sdhs47ewue@t32qtsdruhjdr>
Date: Sun, 11 Mar 18 22:18:08 CET
Organization: XXX.XXX
Path: storage.XXX.XXX
From: [email protected]
Newsgroups: alt.binaries.test
Message-Id: <sdhs47ewue@t32qtsdruhjdr>
Subject: This is my test
.

So now let’s see what’s the difference to a POST:

post
340 Start posting.
From: [email protected]
Newsgroups: alt.binaries.test
Message-ID: <124eqtqfs@adfsdhd3>
Subject: This is my test

this is a test
.
240 Posted <124eqtqfs@adfsdhd3>
head <124eqtqfs@adfsdhd3>
221 0 <124eqtqfs@adfsdhd3>
Subject: This is my test
Date: Sun, 11 Mar 18 22:19:07 CET
Path: storage.XXX.XXX
Organization: XXX.XXX
From: [email protected]
Newsgroups: alt.binaries.test
Message-Id: <124eqtqfs@adfsdhd3>
.

Organization is there. Path is there (whatever you put it there doesn’t matter, even not-for-mail was replaced by storage.XXX.XXX)

Q: Why don’t you implement a random password feature?

A: To support a random password feature, newsup would need to support the command line syntax of those programs that do the split of the files (at least rar and 7zip), making them as dependencies (imagine that they change the command line syntax - improbable, but that is not the point - then making, the certain versions of those programs, a dependency of newsup). Such functionality is also easily achieved with a bash script:

Example:

#!/bin/bash

RANDOM_PASSWORD=`tr -cd '[:alnum:]' < /dev/urandom | fold -w12 | head -n1`
echo "Ranomd password: ${RANDOM_PASSWORD}"
ZIP_CMD="split_cmd = 7z a -mx0 -v50m -t7z -p${RANDOM_PASSWORD} -- "
sed -i "s/^split_cmd.*/${ZIP_CMD}/" ~/.config/newsup.conf
newsup --metadata password=${RANDOM_PASSWORD} -f "$@"