Posting Usenet News Messages

[Camelback Jones]

What part of "a line with a space in it is not a blank line" is so hard to
grasp?

Probably the same part of "it depends on context" that you don't grasp.

Besides, once I got it to work ( see below ) it appears that in fact it IS
a blank line (either that, or datasend() is smart enough or dumb enough to
strip the leading spaces before sending it...).

Sheesh!

Now a cursory search on Google turned up this page:

http://freebooks.by.ru/view/RedHatLinux6Unleashed/rhl6u320.htm

and this sample (which I take no credit/blame for):

LISTING 31.8 Posting an Article to Usenet

#!/usr/bin/perl
open (POST, "post.file");
@post = <POST>;
close POST;
use Net::NNTP;
$NNTPhost = 'news';
$nntp = Net::NNTP->new($NNTPhost)
or die "Cannot contact $NNTPhost: $!";
# $nntp->debug(1);
$nntp->post()
or die "Could not post article: $!";
$nntp->datasend("Newsgroups: news.announce\n");
$nntp->datasend("Subject: FAQ - Frequently Asked Questions\n");
$nntp->datasend("From: ADMIN <root\@rcbowen.com>\n");
$nntp->datasend("\n\n");
for (@post) {
$nntp->datasend($_);
} # End for
$nntp->quit;

*NOTE* the double new lines with no space between separating
the header and the body.

NOTED! But not necessary. I tried it with these two, then with one (as
well as with eight), and all worked. It just threw the excess lines into
the body.

The above is not production quality, IMHO, as it is not
scoped, does not use warnings nor strict,
nor is it error trapped properly.

Bt it should get the point across....

My reading of RFC 1036 seems to indicate that the required header lines for
date, message-id, and path are missing, so I'm a bit puzzled as to why it
works... but it does, and I don't really care about those one way or the
other, as long as the host adds them (which it apparently does).


Now, here's the part that's really bothering me: I dredged up an example

my @Message = ( "Newsgroups: alt.test\015\012",
"From: nospam\@some-domain.tld\015\012",
"Reply-To: trash\@some-domain.tld\015\012",
"Subject: Teste Net::NNTP\015\012",
"Organisation: Someone\015\012",
"Content-Type: text/plain; charset=ISO-8859-1\015\012",
"Content-Transfer-Encoding: 8bit\015\012",
"X-No-Archive: yes\015\012",
"\015\012", # Leerzeile zwischen Header und Body
"Erste Zeile\015\012",
"Zweite Zeile\015\012"
);
# Das Gefuckel mit \015\012 lässt sich meist in einem Rutsch erledigen
# @message = map { "$_" . "\015\012" } (0..$#message);
my $OK = $server->post(\@Message);

Which seems to be not drastically different from what I was trying to do...
and it DOESN'T WORK (even when I added multiple CR/LF's on the "blank"
line). It finally dawned on me that Net::NNTP has a debug() method, so I
turned it on, and it says, guess what...

441 - Article has no body, just headers.

Huh? The output from debug, right up to that point, looks absolutely the
same as the output from the datasend() example you found, as far as I can
see, and if we change these lines to datasend() calls, it seems to work
just fine.




Boy, I dunno... I'm going to do what I was planning to do but
using the straight datasend() calls, but I still want to know why the
post([@message]) form doesn't work...


And, you know what? All the blather about what constitutes a "blank" line
didn't have diddley-squat to do with it, because I tried every combination
of them I could think of, including the CR/LF that turned out to work...
The only reason I put spaces in was to see if it for some reason just HAD
to have at least one character on the line to declare it a "line" (hey, you
never know until you try... ).

and

either NNTP doesn't effing care about the space, or datasend() strips it,
because I changed

$nntp->datasend("\n\n");
to
$nntp->datasend(" \n");

just for the hell of it... and... IT... WORKS.

So there. ;p


Thanks for the example - I was so intent on finding out why post() wasn't
working that I blew off other datasend() examples several times, looking
for a workiong post() one.

So... we still don't know why post() doesn't work, but at least we have
code that DOES work!

Thanks again!

 

[Camelback Jones]

listen, you have an attitude problem.

Tad is trying to help you. he is
pointing
out that you should not have a space at that position, and you start
nitpicking
about it, without any knowledge, when Tad most definitively has.

Actually, as it turns out, Tad - whatever his knowledge may or may not be -
is wrong about that. Now that I finally have it working, it doesn't matter
whether there's a space there or not, which is exactly what I thought in
the first place.

the fact that his help was not enough for you to make your program work
is not good reason to slap him.

I'm not slapping him, or you, or anybody else. I'm stating what I believe
to be facts. I'm sorry if you don't like the way I state them, and I'm
sorry if you don't like the fact that I state my opinions freely.

we wait in anticipation

Your wait is ended: See my response with the word SOLVED appended to the
subject line.

You're welcome.

 

[Camelback Jones]

I read 1036 and 822. I've no doubt I missed plenty in those. If neither
of those is the relevant one, what is?

They'll do... 822 is obsoleted by 2822, but that doesn't matter for
these purposes.

I'm gruntled to know that. If you'll tell me where this is documented,
I'd love to read it and see what other nuggets are to be found. This
seems to be a difference from the general rule that LF's end a line and
CR's cause problems.

RFC822, section 3.2:

field = field-name ":" [ field-body ] CRLF

section 4.1:

message = fields *( CRLF *text )

As another general rule, Internet protocols (including
Usenet-over-Internet , use CRLF as the end-of-line sequence and
big-endian number representations.

So, how about it - do YOU have a working example of what I'm trying to
do? I could sure enough use the help, and telling me I don't know much
isn't telling me anything I don't already know.

No I don't, sorry. As someone else said, you perhaps need to put the
newlines on the end of you lines before passing them to post.

As I thought I'd said (several times, but maybe it only SEEMED that way
I tried that, too.

As it turns out, apparently the post() method just flat doesn't work, or
there's something mysterious about it...

Anyway, the datasend() method works, and as it turns out, either NNTP is
perfectly happy to consider " \015\013" as a "blank line" or datasend()
strips leading spaces, because it works just fine either way. See my
response with the word SOLVED appended to the subject line for details.

Thanks for the help!

 

[Joe Smith]

It's nothing to do with $!, rather to do with warn and die. If you put
"\n" on the end, it will suppress the line-number and file information,
which is usually essential to debugging any problem.

Line numbers and source-file info is very programmer-friendly.

For errors that are expected to occur (such as when a user
misspells the name of an input file or specifies an output
file that is write protected), it's better write a user-friendly
error message, and include the trailing "\n" to surpress
unneeded/confusing clutter.
-Joe

 

[Joe Smith]

Actually, as it turns out, Tad - whatever his knowledge may or may not be -
is wrong about that. Now that I finally have it working, it doesn't matter
whether there's a space there or not, which is exactly what I thought in
the first place.

While it may be true that is does not matter with the module you are
using, it does make a difference to the NNTP server. If you watch
the bytes leaving your socket, you'll see that the NNTP server
will _not_ accept "\n \n" for the mandatory blank line separating
the body from the headers.
-Joe