* 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). #+BEGIN_QUOTE 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. #+END_QUOTE So every host will append their hostname to the path line. Real example: #+BEGIN_SRC 281 Authentication accepted. ihave <asdhs47ewue@t32qtsdruhjdr> 335 Send article to be transferred. Path: cbosgd!mhuxj!mhuxt!eagle!jerry From: Test@test.com 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: Test@test.com Newsgroups: alt.binaries.test Message-Id: <sdhs47ewue@t32qtsdruhjdr> Subject: This is my test . #+END_SRC So now let's see what's the difference to a POST: #+BEGIN_SRC post 340 Start posting. From: Test@test.com 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: Test@test.com Newsgroups: alt.binaries.test Message-Id: <124eqtqfs@adfsdhd3> . #+END_SRC 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 "$@" ```