snews (secure news) doesn't work through a proxy (e.g. Squid). Change that. The patches for mozilla/netwerk/protocol/http attched to bug 31174 might help during development.

If you are behind a proxy, have setting correct (SSL works), create a secure news server account and try to get newsgroups for it, you get "Failed to connect to bla.example.com".

does news through a proxy work? I've never tried.

You mean normal news? Through which type of proxy? A port forwarder? SOCKS? I once tried a port forwarder with 4.x, but it didn't work right away, and I quickly gave up. I don't have a working SOCKS installed, I think. Or snews? snews through Squid as SSL proxy works fine in 4.x.

It was a poorly documented fact, but there was no proxy support for news (non-SSL) in client. HTTP specifies proxy behaviors in the protocol, my implicit understanding is that there is no such behavior for news. SNEWS was "proxiable" because it piggybacked the "SSL Tunnel" feature of the "Security" field (which was designed mainly for tunneling of HTTPS requests. snews would be a separate behavior, and now that someone mentioned it, I have never seen it work on any NS6 builds up to RTM either. I've tried to document some of the details of how clients and Proxies work together, and I'll update w/ a link when I'm done. Also, if this is going to be given a high fix priority, I can put some time to analyzing how the connection looks on the wire, which might help w/ fixing this problem.

I need to learn more about proxies and news (and snews) over proxies, so any info would be appreciated. > snews would be a separate behavior, and now that someone mentioned it, I have > never seen it work on any NS6 builds up to RTM either. snews works NS6. I just tried it. accepting bug.

What benc said: I am not aware of a news proxy in the sense that the cleint can specify an arbitary server on the net to contact. There *is* Newscache, which acts like a transparent proxy, but can fetch only from predefined (by the admin) servers. Also, I always have problems to get it to work. snews should probably work similar to https proxies like in bug 31174. BTW: Since I didn't get newscache to work, snews is the only way for me to use news in Mozilla.

s/snews is/snews over squid proxy would/

I think we need to test and support snews via "SSL Proxy" and "SOCKS". After thinking about it further, I am becoming un-convinced of the need to offer an application level proxy setting for services that have a one-one client-server relationship. A "news" proxy (rather than a SOCKS setup that allows news connections) is not a good idea to me. I'm going to read some more RFC's, hopefully nobody ever proposed this in writing.

Mass moving all NEWS bugs from esther to myself.

Let's focus this bug on snews via "SSL Proxy" (ala squid, i.e. SSL starts at the client) and possibly "SOCKS". benc, can you file a new bug (and cc me) about the "normal" news proxying, to which you object? We could later mark it WONTFIX, but I'd like to see this evaluated - I didn't think thought it, but it doesn't seem like a bad idea to me. (I don't like connection-, but application-oriented proxies.)

clarified summary: There is a SOCKS checking for all mailnews in bug 44995. If that checking fails to implement news or SNEWS for SOCKS, we should break out bugs from that point.

ben, you got your new bug in 60744 ...

I know a little about Squid. It knows nothing about SSL. All it knows is that it should just pass data back and forth for a CONNECT method. The default configuration allows the CONNECT method only for ports 443 and 563. Changing this is possible but might be construed as a security hole. There seems to be no way for an average user to know what will or will not work other than to try it. Since Squid doesn't know SSL, the first part of the transaction has to be in cleartext. Only after the connection is established can SSL commence. Attached are some test results. I relaxed my Squid's CONNECT restrictions so I can use any port. My Squid is listening on port 3128. You can see that you have to do a pseudo-HTTP transaction and wait for the HTTP 200 response. Once you do, you're in business. If an error occurs, you have to be prepared to deal with an HTTP error code and an HTML error document. Is this what you really want?

ten, SNEWS worked before with CONNECT commands (SSL Tunnel). I don't know what it it supposed to look like in squid logs, but the behavior is the same as w/ using CONNECT for HTTPS. I'll probably write some more documents explaining how that works, and I'll add relevant links here if it helps.

*** Bug 87876 has been marked as a duplicate of this bug. ***

according to bbaetz, this is a feature request. marking as such.

It's a bug. In Advanced prefs, I set the proxy for "SSL", not just "HTTPS". Nevertheless, it's not used for news over SSL. I.e. it doesn't work as reasonably expected.

*** Bug 129056 has been marked as a duplicate of this bug. ***

I agree. snews (or any XXX-over-SSL protocol) ought to be able to work through any proxy that understands the CONNECT protocol (and doesn't restrict it to port 443).

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

I think this functionality is not just about NNTP. Our capmus admins, damn 'em, provide awful email server, I prefer to use paid service. Some email service provider are aware of damned admins and provide 443 port for email. So, in fact I can use email via 443 port and NNTPS via 563. Most of the Instant Messengers had already reflected the fact that user is likely to have an evil admin. It's time for Thunderbird to reflect this fact either. I use connect-tunnel currently. It is inconvenient: 1. Every service accesible via 443/563 port is likely to be SSL. Thunderbird checks for SSL validity every time it connects to the server. Thunderbird thinks that server is named "rsdn.localhost". And SSL certificate is issued to "snews.rsdn.ru". Thunderbird yells about DNS name mismatch every time! 2. Thunderbird ties login/password pairs to server DNS names, not to accounts. If you use "localhost" for every NNTP account with just different port numbers, Thunderbird is unable to store login/pass for every account. If you log into RSDN, TB tries USENET login/pass. It fails. I enter my RSDN credential. Next time I try to log into my USENET server, TB tries USENET credentials. Of course, it fails. TB is unable to distinguish accounts this way. So I have to enhance "hosts" with usenet.localhost, gmane.localhost, rsdn.localhost, each pointing to 127.0.0.1 with connect-tunnel instances running on different ports. All the users in our and other networks have potential ability to repeat this tweakkit, but this is techy.

(In reply to comment #22) > I think this functionality is not just about NNTP. I would agree that it is my opinion that proxies with SSL in TB are borked, but I haven't tested. Punting to Core: Mailnews: Networking in the hope that someone with more experience will see this. CC'ing people with a bit more clue than I (hopefully) on the issues.

Joshua, I'm happy to help you by answering any questions you might have. Implementing this feature ought to be pretty simple. It could be implemented as a layer in the protocol stack on the socket, below the SSL layer, or it could be implemented in each protocol (e.g. nntp, SMTP, etc.) which might seem simpler in the short term but requires that every such protocol be modified. Conceptually, it's this simple: If the protocol is configured to use SSL (e.g. as in SMTP-over-SSL) and is also configured to use a proxy, then you connect to the proxy (instead of the intended destination server) and then perform the trivial CONNECT protocol (one request and one response) after which you carry on just as if you had connected directly to the intended server directly. The "hard" part (if there is one) is probably in providing meaningful error messages to the user in the event that the CONNECT protocol fails.

IMAP does this, if I understand correctly, in nsImapProtocol::SetupWithUrl: rv = socketService->CreateTransport(&connectionType, connectionType != nsnull, *socketHost, socketPort, proxyInfo, getter_AddRefs(m_transport));

Joshua: I appreciate your concerns, but you should understand that this is a feature that is implemented (or is broken) on a per-protocol basis. You can't have a general bug like this unless it is a tracking bug. You should re-focus this bug back to the area that fails, and file a new bug for each network protocol that fails. (Although I did the proxy testing for Netscape, I was focused on the browser protocols. Only recently have I begun to look at the mailnews networking features. So I wish I could give you a list, but I'm working on checking each feature, one at a time.)

(In reply to benc from comment #26) > Joshua: I appreciate your concerns, but you should understand that this is a > feature that is implemented (or is broken) on a per-protocol basis. > > You can't have a general bug like this unless it is a tracking bug. You > should re-focus this bug back to the area that fails, and file a new bug for > each network protocol that fails. The code for handling protocol proxies is identical for NNTP, POP, and SMTP. The rules for CONNECT proxies are likely to be handled only generically for that subset anyways.