If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

newsgroup filters not working with Astraweb news server

RESOLVED INCOMPLETE

Status

MailNews Core
Networking: NNTP
RESOLVED INCOMPLETE
9 years ago
7 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 344778 [details]
annotated nntp log (level 5) for the test

SM trunk nightly Gecko/20081004 

Today is the last day on which ComCast users get usenet newsgroup service 
as a bundled part of their cable internet services.  Comcast's nntp service 
had been actually provided by giganews.  Knowing the troubles that Mozilla 
news filters had had with giganews servers, I decided to try a different 
server.  So, I switched to another usenet provider, Astraweb.  
See http://www.news.astraweb.com/

After setting up my new account and subscribing to the same newsgroups
as I had been using with giganews, I copied all my filters over, too.
I copied the .dat files over from the directory for the comcast/giganews
server to the directory for the astraweb server.  

Then I did a series of tests, reading newsgroups one at a time, first
on the comcast server, then on astraweb.  The filtering on the giganews
servers worked as it had before, well, but VERY slowly (~3 messages/sec).
On Astraweb, there was no evidence that any filtering was taking place
at all.  The astraweb filter log file remains empty.  

So, I repeated the test with nntp logging enabled.  The annotated log file
is attached.  It looks like the client sent the command 
XHDR path 16998-17006
to the server.  After that, there are a bunch of lines in the log that say
Next state: NNTP_XHDR_RESPONSE
but I see no actual data being returned by the server.  Do I need to turn 
the level of nntp logging up past 5 to get all the nntp data?  
("Turn it all the way up to 11" ? :)

Both servers use SSL, so a packet sniffer won't be helpful, I think.
In case you're wondering, yes, I verified with the UI that the news client
does see all the filters for the newsgroups and for the server itself 
on the new server that it saw on the old server.
(In reply to comment #0)
> So, I repeated the test with nntp logging enabled.  The annotated log file
> is attached.  It looks like the client sent the command 
> XHDR path 16998-17006
> to the server.  After that, there are a bunch of lines in the log that say
> Next state: NNTP_XHDR_RESPONSE
> but I see no actual data being returned by the server.  Do I need to turn 
> the level of nntp logging up past 5 to get all the nntp data?  
> ("Turn it all the way up to 11" ? :)

NNTP logging only logs the first line of responses.

> Both servers use SSL, so a packet sniffer won't be helpful, I think.

According to http://www.wireshark.org/about.html, Wireshark can look at the SSL packets.
(In reply to comment #2)

> NNTP logging only logs the first line of responses.

But I don't see ANY lines of XHDR response.  Do you?

> According to http://www.wireshark.org/about.html, Wireshark can look at 
> the SSL packets.

Oh, yes, I know.  I am mozilla's SSL developer after all.  It looks at 
them at a level that may be useful for debugging SSL issues, but we're
not having SSL issues here, and it doesn't decrypt the traffic.  
(It can't.  If it could, SSL would be useless.)
Version: 1.9.0 Branch → Trunk
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core
changing to UNCO rather than adding qawanted, since we don't understand yet what this is about
Status: NEW → UNCONFIRMED
Ever confirmed: false
Why not close it WONTFIX?  Be honest.
for starters, I'm not that devious and I don't have authority to WONTFIX :) If honesty means adding clarity ... I'm following my imperfect understanding of what is written in the comments and fthe definition of NEW/UNCO in https://bugzilla.mozilla.org/page.cgi?id=fields.html#status 

Why do you suggest WONTFIX?  If it's purely a server issue then it's INVALID.  Feel free to elaborate.
(In reply to comment #5)
> Why not close it WONTFIX?  Be honest.

Well, you haven't provided enough information, so that would make it an INCO resolution, not WONTFIX. I can't see it, but nor do I have the resources to test it.
According to comment #7, set closeme flag.
Whiteboard: closeme 2010-08-25
ATM there isn't enough information here (ref comment 7), so closing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme 2010-08-25
You need to log in before you can comment on or make changes to this bug.