Does JavaMail "connect" require a password?

[Mickey Segal]

According to
http://java.sun.com/products/javamail/javadocs/com/sun/mail/smtp/package-summary.html, a
method used for JavaMail requires a password:

tr.connect(smtphost, username, password);

I had dutifully included the appropriate password, but today found that my
hosting company had changed the password with no prior notice. While
testing to see what functionality of the domain they had blithely disabled,
I was surprised to find that JavaMail still worked, even with the defunct
password.

Are there conditions under which the JavaMail ignores the password in the
connect method, or is there something strange going on here?

A few weeks ago I changed the first parameter of the connect method to
"localhost" as a workaround for a glitch in which the server suddenly
started delaying regular email for hours and intermittently not sending
JavaMail at all. The hosting company suggested using "localhost" as the
first parameter in the connect method as a workaround for the unexplained
flakiness of their servers. I don't know if this removes the need for a
password.

 

[none]

According to
http://java.sun.com/products/javamail/javadocs/com/sun/mail/smtp/package-summary.html, a
method used for JavaMail requires a password:

tr.connect(smtphost, username, password);

I had dutifully included the appropriate password, but today found that my
hosting company had changed the password with no prior notice. While
testing to see what functionality of the domain they had blithely disabled,
I was surprised to find that JavaMail still worked, even with the defunct
password.

Are there conditions under which the JavaMail ignores the password in the
connect method, or is there something strange going on here?

A few weeks ago I changed the first parameter of the connect method to
"localhost" as a workaround for a glitch in which the server suddenly
started delaying regular email for hours and intermittently not sending
JavaMail at all. The hosting company suggested using "localhost" as the
first parameter in the connect method as a workaround for the unexplained
flakiness of their servers. I don't know if this removes the need for a
password.

does your host use stmp auth? or is authentication just required for
pop/imap access?
Could this be that your host's smtp server is badly configured to allow
non authenticated users to send email?

Without checking smtp, i guess javamail won't send the password if the
provider is not challenged.

Tim

 

[Mickey Segal]

does your host use stmp auth? or is authentication just required for
pop/imap access?
Could this be that your host's smtp server is badly configured to allow
non authenticated users to send email?

Without checking smtp, i guess javamail won't send the password if the
provider is not challenged.

It now looks like the answer is that the password changes are not
propagating through the server. Logging in to the cPanel interface requires
the new password, but the password change does not seem to have propagated
to other parts of the server, and the password required by FrontPage
extensions and JavaMail is still the old password.

So it does look like the server is badly configured, but the issue is not
unauthenticated access but instead there is a broken process of password
propagation.

Does anyone have any recommendations of hosting companies run by people who
know what they are doing? This situation is a problem waiting to occur,
since once the new password gets set globally all our JavaMail-dependent
servlets will fail until we change the password used for invoking JavaMail.