Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nigel Wade Newsgroups: comp.lang.java.programmer Subject: Re: JavaMail bug? Date: Tue, 09 Aug 2011 13:31:49 +0100 Lines: 51 Message-ID: <9acnlmF447U1@mid.individual.net> References: <995djcFq0nU1@mid.individual.net> <99njvpFv11U1@mid.individual.net> <99qjntFk6uU1@mid.individual.net> <99sf3vFncoU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: individual.net U15sm6iquP1M/3LRKY2D2QfNIVLl6f3RQv3xEGw5XGpArGTY7H Cancel-Lock: sha1:yXIjPwppgKxc2SA4zCrq+bQvcBc= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6912 On 08/08/11 23:50, Martin Gregorie wrote: > On Wed, 03 Aug 2011 09:27:43 +0100, Nigel Wade wrote: > >> Note that it does not include AUTH, so no authentication will be allowed >> and the client should not attempt it. >> > Fair point. > >> This isn't a good idea. It's an open invitation to spammers to verify >> the existence of every recipient in your domain. >> > Except that this server really is private: my firewall blocks all inbound > connection requests and so its only contact with the outside world are > its outbound SMTP connections to my ISP's mail server when it needs to > send mail. Incoming mail is fetched by getmail and passed to the MTA via > the Postfix.sendmail utility. Ok. Fairy snuff. Personally I'd still get rid of it unless you are actively using it. It's somewhat in the realm of "security by obscurity". There's a potential for the vulnerability to be exposed, or for the configuration to migrate somewhere where it is exposed. Imagine your firewall goes down, the mail server stops working and users are clamouring for their email (it's like a drug here, users will get along without any other system, but not the mail server). Panic, Panic. Bypass the broken firewall to get the mail server back online - and now you're exposed. > >> I presume that this is due to the fact that the connect() above failed. >> You have specified authentication by using a user/password, but the >> connection does not allow authentication. When you subsequently use >> tr.send() there is no open session so a default session is created which >> appears to be to localhost. >> > OK, that makes sense. > > Your point about Transport.send() being static would seem to explain the > behaviour I'm seeing, but there's still a heap of anomalies, mainly in > the documentation: > > - Transport.send() says that its not a good idea to inherit the > connection from a Session and doesn't provide a suitable way of setting > the hostname (at least its docs don't mention one or mention the use of > properties, though obviously they are used by it. > > - now go and look at SMTPTransport. Its documentation includes > example code doing as we did, and getting the connection from Session. > I see the documentation showing use of Transport.sendMessage() (an abstract instance method) following a Session.getTransport(). I don't see use of Transport.send(). -- Nigel Wade