From Georgi: We may want to restrict the ports that IRC can use, since it might be possible to use a link like <a href="irc://localhost:25">IRC TO localhost:smtp</a> to send mail in another user's name, similar to a problem we once had with Gopher.
I don't see how it would be possible to send anything that looks like SMTP over irc:, but I could be wrong. http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/chatzilla-service.js#171 It looks to me that chatzilla shouldn't allow connections over questionable ports, but I've never actually seen this function get called. Mitch, what's the deal with nsIProtocolHandler.allowPort? Is it only supposed to be called for questionable ports, or all ports? Any idea why it isn't being called for me?
rob: you need to call nsIIOService::allowPort from your implementation of newChannel if you want to use the standard port blocking mechanism. nsIOService::AllowPort will invoke your nsIProtocolHandler::allowPort to give you the opportunity to override a port that the io service would otherwise block. see nsIIOService.idl and nsIProtocolHandler.idl for more details. this stuff is sort of documented there.
btw: this issue is not just with SMTP... we generally block other ports as well. the list is in nsIOService.cpp.
Comment on attachment 113511 [details] [diff] [review] patch r/sr=darin (looks good!) i really wish we had chosen different names for nsIIOService::allowPort and nsIProtocolHandler::allowPort, since the sense of the return value is inconsistent :-( the protocol handler one should have been called something like "overridePortBan" or something more to the point.
Bugs published on the Known-vulnerabilities page long ago, removing confidential flag.