Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6478 > unrolled thread

JavaMail bug?

Back to article view | Back to comp.lang.java.programmer

Contents

  JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-23 20:32 +0000
    Re: JavaMail bug? Knute Johnson <september@knutejohnson.com> - 2011-07-23 20:54 -0700
      Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-24 09:50 +0000
        Re: JavaMail bug? Knute Johnson <september@knutejohnson.com> - 2011-07-24 09:27 -0700
          Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-25 19:36 +0000
            Re: JavaMail bug? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2011-07-25 23:00 -0700
              Re: JavaMail bug? Steve Sobol <sjsobol@JustThe.net> - 2011-07-25 23:18 -0700
                Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-26 17:49 +0000
              Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-26 17:42 +0000
    Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-07-25 15:40 +0100
      Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-25 19:54 +0000
        Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-25 20:11 +0000
          Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-29 21:32 +0000
            Re: JavaMail bug? Knute Johnson <september@knutejohnson.com> - 2011-07-29 16:26 -0700
            Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-01 13:20 +0100
              Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-01 21:49 +0000
                Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-02 16:34 +0100
                  Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-02 20:01 +0000
                    Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-03 09:27 +0100
                      Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-08 22:50 +0000
                        Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-09 13:31 +0100
                          Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-09 22:47 +0000
                            Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-10 09:34 +0100
                              Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-10 19:37 +0000
                    Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-03 09:38 +0100
                      Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-16 21:06 +0000
                        Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-17 10:29 +0100
                          Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-17 19:54 +0000
                            Re: JavaMail bug? Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-08-18 09:34 +0100
                              Re: JavaMail bug? Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-18 19:50 +0000
            Re: JavaMail bug? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-01 12:54 +0000

Page 2 of 2 — ← Prev page 1 [2]

#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

[toc] | [prev] | [next] | [standalone]

#6931

On Tue, 09 Aug 2011 13:31:49 +0100, Nigel Wade wrote:

> 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.
>
Its unlikely that anything like that would happen. This is my house 
server that I'm describing. The config is whatever I set it to and nobody 
else is ever likely to touch it.

> Imagine your firewall goes
> down, the mail server stops working
>
Indeed. If the firewall breaks, nothing will work until it gets replaced.

> I see the documentation showing use of Transport.sendMessage() (an
> abstract instance method) following a Session.getTransport().
>
Sure, but they are all static apart from sendMessage, which is abstract.
 
> I don't see use of Transport.send().
>
True enough.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#6961

On 09/08/11 23:47, Martin Gregorie wrote:
> On Tue, 09 Aug 2011 13:31:49 +0100, Nigel Wade wrote:
>

>> I see the documentation showing use of Transport.sendMessage() (an
>> abstract instance method) following a Session.getTransport().
>>
> Sure, but they are all static apart from sendMessage, which is abstract.

It's sendMessage() which they use in the example, not any of the static 
methods - that's the important fact. sendMessage() must be implemented 
by whatever class creates the Transport which is returned by 
Session.getTransport(), it could not instantiate a Transport unless it 
had implemented the abstract methods.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#6988

On Wed, 10 Aug 2011 09:34:40 +0100, Nigel Wade wrote:

> It's sendMessage() which they use in the example, not any of the static
> methods - that's the important fact. sendMessage() must be implemented
> by whatever class creates the Transport which is returned by
> Session.getTransport(), it could not instantiate a Transport unless it
> had implemented the abstract methods.
>
Thanks for the reminder. I was knackered last night due to having flown a 
4 1/4 hour soaring flight yesterday PM and that didn't register.
 
I still think we're dealing with an ugly bit of design, though: IMO there 
too many ways of specifying the MTA host and login parameters and, worse, 
the design decision to use static methods has prevented these from being 
orthogonal to the methods that send messages.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#6772

I've just been reviewing the JavaMail API as it's a while since I used 
it. You need to be aware that Transport.send() is a /static/ method. I 
presume this means it takes no note of any connection established by an 
object of class Transport, since the class method has no knowledge of 
any contents of any Transport object. That probably explains why it uses 
the values in the Session, not those established by the Transport object 
you've created.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#7143

On Wed, 03 Aug 2011 09:38:41 +0100, Nigel Wade wrote:

> I've just been reviewing the JavaMail API as it's a while since I used
> it. You need to be aware that Transport.send() is a /static/ method. I
> presume this means it takes no note of any connection established by an
> object of class Transport, since the class method has no knowledge of
> any contents of any Transport object. That probably explains why it uses
> the values in the Session, not those established by the Transport object
> you've created.
>
Final comment:

On Sunday this whole mess niggled me again, so I ripped out the property 
setting the default MTAname and replaced the call of tr.send(msg) with 
tr.sendMessage(msg, recipients) so the Transport acquired from the 
Session is used. This all works as expected: there's only the one EHLO 
conversation and the recipient is validated (which I don't remember 
seeing earlier).   


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#7155

On 16/08/11 22:06, Martin Gregorie wrote:
> On Wed, 03 Aug 2011 09:38:41 +0100, Nigel Wade wrote:
>
>> I've just been reviewing the JavaMail API as it's a while since I used
>> it. You need to be aware that Transport.send() is a /static/ method. I
>> presume this means it takes no note of any connection established by an
>> object of class Transport, since the class method has no knowledge of
>> any contents of any Transport object. That probably explains why it uses
>> the values in the Session, not those established by the Transport object
>> you've created.
>>
> Final comment:
>
> On Sunday this whole mess niggled me again, so I ripped out the property
> setting the default MTAname and replaced the call of tr.send(msg) with
> tr.sendMessage(msg, recipients) so the Transport acquired from the
> Session is used. This all works as expected: there's only the one EHLO
> conversation and the recipient is validated (which I don't remember
> seeing earlier).
>
>

Yes, I think that's the best way to do authentication. If you look at 
the top of the Javadocs for com.sun.mail.smtp (the protocol which is 
actually used behind the scenes, it's not exactly obvious because the 
design hides this from you) it states:

To use SMTP authentication you'll need to set the mail.smtp.auth 
property (see below) or provide the SMTP Transport with a username and 
password when connecting to the SMTP server. You can do this using one 
of the following approaches:

     * Provide an Authenticator object when creating your mail Session 
and provide the username and password information during the 
Authenticator callback.

       Note that the mail.smtp.user property can be set to provide a 
default username for the callback, but the password will still need to 
be supplied explicitly.

       This approach allows you to use the static Transport send method 
to send messages.

     * Call the Transport connect method explicitly with username and 
password arguments.

       This approach requires you to explicitly manage a Transport 
object and use the Transport sendMessage method to send the message. The 
transport.java demo program demonstrates how to manage a Transport 
object. The following is roughly equivalent to the static Transport send 
method, but supplies the needed username and password:

           Transport tr = session.getTransport("smtp");
           tr.connect(smtphost, username, password);
           msg.saveChanges();      // don't forget this
           tr.sendMessage(msg, msg.getAllRecipients());
           tr.close();



-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#7166

On Wed, 17 Aug 2011 10:29:24 +0100, Nigel Wade wrote:

> On 16/08/11 22:06, Martin Gregorie wrote:
>> On Wed, 03 Aug 2011 09:38:41 +0100, Nigel Wade wrote:
>>
>>> I've just been reviewing the JavaMail API as it's a while since I used
>>> it. You need to be aware that Transport.send() is a /static/ method. I
>>> presume this means it takes no note of any connection established by
>>> an object of class Transport, since the class method has no knowledge
>>> of any contents of any Transport object. That probably explains why it
>>> uses the values in the Session, not those established by the Transport
>>> object you've created.
>>>
>> Final comment:
>>
>> On Sunday this whole mess niggled me again, so I ripped out the
>> property setting the default MTAname and replaced the call of
>> tr.send(msg) with tr.sendMessage(msg, recipients) so the Transport
>> acquired from the Session is used. This all works as expected: there's
>> only the one EHLO conversation and the recipient is validated (which I
>> don't remember seeing earlier).
>>
>>
>>
> Yes, I think that's the best way to do authentication. If you look at
> the top of the Javadocs for com.sun.mail.smtp (the protocol which is
> actually used behind the scenes, it's not exactly obvious because the
> design hides this from you) it states:
> 
> To use SMTP authentication you'll need to set the mail.smtp.auth
> property (see below) or provide the SMTP Transport with a username and
> password when connecting to the SMTP server. You can do this using one
> of the following approaches:
>
Yes, I found that too.
 
>            Transport tr = session.getTransport("smtp");
>            tr.connect(smtphost, username, password); msg.saveChanges(); 
>                // don't forget this tr.sendMessage(msg,
>            msg.getAllRecipients());
>            tr.close();
>
I'm not calling Message.saveChanges(), but as something wrapped your text 
up in a bit of a ball I'm not sure that your 'don't forget'  refers to.
Instead I hung onto the recipient array and just passed it into 
Transport.sendMessage(). It also works correctly.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#7209

On 17/08/11 20:54, Martin Gregorie wrote:

>>
> I'm not calling Message.saveChanges(), but as something wrapped your text
> up in a bit of a ball I'm not sure that your 'don't forget'  refers to.
> Instead I hung onto the recipient array and just passed it into
> Transport.sendMessage(). It also works correctly.
>

It isn't "mine". It's a quote from the Javadocs. It refers to the 
saveMessage(), which I've never used. I presume that's in case you want 
to save the changes to the messages into some message store (Drafts?). 
The entire package is rather convoluted for simple message 
generation/submission.

I don't know why you don't see the text correctly. The post appears ok 
viewed in my newsreader (Thunderbird). It's flowed text, maybe your 
newsreader doesn't like that.  But, as far as I can tell, the code part 
is correctly line-wrapped anyway, rather than flowed.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#7226

On Thu, 18 Aug 2011 09:34:21 +0100, Nigel Wade wrote:

> It isn't "mine". It's a quote from the Javadocs. It refers to the
> saveMessage(), which I've never used.
>
Thanks for the clarification.

> I presume that's in case you want
> to save the changes to the messages into some message store (Drafts?).
>
Thats what the method description says its for. 

> The entire package is rather convoluted for simple message
> generation/submission.
>
It certainly gives me the impression of having been written before it was 
designed or documented and that it wasn't fully understood by the  
documentation's author.
 
> I don't know why you don't see the text correctly. The post appears ok
> viewed in my newsreader (Thunderbird).
>
OK. I thought that finding "msg.saveMessage();" had been wrapped onto the
end of the preceding line since the rest of the snippet is one statement 
per line. I've noticed that some constructions - particularly 'bulleted 
points', i.e. lines each starting with '- ' tend to get wrapped by 
something in USENET and thought this was another case of it.
   

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#6713

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> The 'gotcha' turned out to be my omission to set the 'mail.smtp.host' 
> property. I didn't do that because the connect() documentation says that 
> it overrides the default host. This turns out to be incorrect: the MTA 
> host named in connect() appears in all the debugging and is used by the 
> getURL method, *but* the hostname supplied in the 'mail.smtp.host' 
> property is what defines the MTA that is actually used. If the property 
> is omitted the MTA host name defaults to localhost.

Fwiw: I recently saw this kind of behaviour on Oracle on a Solaris host:
Some mailhost is configured for "smtp_out_server", which is supposed to
be used for utl_mail (pl/sql), but is also used for utl_smtp (ignoring
the hostname passed to utl_smtp.Open_Connection(...).)

I haven't used JavaMail myself, so can't say much about that.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web