function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

E-Mail - to Case - Exchange 2007 Issue?

I have configured e-mail to case to the best of my knowledge...
I'm getting the following error....



No login methods supported!;

  nested exception is:

        com.sun.mail.iap.ProtocolException: No login methods supported!



SFDC Url: 


SFDC Login Refresh: 30

SFDC Timeout:       600


Registered Services:



Any Ideas?

Try setting the <protocol> in the email2case.txt file to IMAPS instead of just IMAP.  IMAPS is secure IMAP, Exchange 2007 seems to play nicer with it.
NcartwrightNcartwright PKIX path building failed: unable to find valid certification path to requested target;

  nested exception is: PKIX path building failed: unable to find valid certification path to requested target



SFDC Url: 


SFDC Login Refresh: 30

SFDC Timeout:       600


Registered Services:



New error :o|

Well, I've got bad news and good news and bad news.

The bad news is that this is a Java issue with SSL keys.

The good news is that there is a way to fix it.

The bad news is that it's a bit involved.  You have to import the SSL key into Java so Java knows and trusts that key.

This page describes the process pretty well, albeit for JIRA, not Email To Case, but the process is the same because it's all Java:

Basically you need to follow the first 3 steps in the above doc:
  1. Get the certificate of your Exchange server and store it to a file.
  2. Use keytool to import the public key into Java.
  3. Modify email2case.bat to include the param for your new keystore, so it should now look like:
echo Email To Case Agent v1.06
java -jar -Xmx256M Email2Case.jar sfdcConfig.txt\mydir\truststore

Where that truststore dir is the directory in which Java put the imported key file.

Then restart Email2Case and it should work.

Sorry, I know this is a PITA -- you can blame Sun for making it difficult with Java.

I'm a bit confused. Keystore command we have a path - what is suppose to go in that path?
Here is the error i'm getting now:
Message: PKIX path building faile unable to find va
certification path to requested target;
  nested exception is:
eption: PKIX path building failed:
lderException: unable to find valid certification path to requested target
Thanks for your help!!
Right, the certification path error is the error I was addressing with my prior post.  This error is noting the fact that Java doesn't know about your Exchange server's SSL certificate.  Have a look at that JIRA link I posted (, they're showing the exact same error.
For the keystore path I think you can use any path, just make sure you reference that path when you change the batch file.

I was getting the same error message that started this thread. I changed to IMAPS and incorporated the keystore changes and now I get this in the log:

Message: PKIX path building failed: s unable to find valid
certification path to requested target;
  nested exception is:
eption: PKIX path building failed:
lderException: unable to find valid certification path to requested target
2008-04-30 10:26:31,856 [Timer-0] INFO  Generating SMTP Authentication Request

Is the path refering to verifying the CA, or it it the path to my keystore as I entered it in the batch file?

I tried the following additions to the batch file:\EmailAgent\keystore\EmailAgent\EmailAgent\keystore

(I tried the last based on searching other resources for using SSL in java)

This is actually the full line that is in my batch file:
java -jar -Xmx256M Email2Case.jar sfdcConfig.txt\EmailAgent\keystore mailserver-fep

The crazy thing is, this all worked on my desktop, but now that I am trying to run it on a server, it's kicking out this message. Could it be because Outlook is not installed on the server?

Oh, and I also put SalesForce's certificate in my keystore, just in case. Didn't help
I have found a lot of other applications generating that error, and the common thread seems to be self-certified servers. The one I'm working with is also self-certified. Now I just can't figure out why this works on my own machine, but not on the server. I inherited this machine from the previous administrator. I wonder if he installed some patch/hack to get Java to stop validating certificates.

We have a wild card cert that i'm attempting to use from net sol.

Any issues with wild card cert?

I don't know about the wild card cert.

Per Zach's question, you can disable cert checking in Java code at least:

I'm not sure if there's some command line setting you can make that would accomplish the same though.
You don't need to do anything with certificates unless you are using a self-signed certificate.  You can check for self-signed for IMAPS by:

$openssl s_client -showcerts -connect


depth=0 /

verify error:num=18:self signed certificate

Then you will need to download and import the certificate into your keystore:

keytool -importcert -keystore /usr/java/jdk1.6.0_05-64/jre/lib/security/cacerts -storepass changeit -alias -file

Of course, this creates a nice time bomb because the certificate eventually expires.  Then you have to generate a new certificate and install it on both the server and your keystore.

1. Don't use imaps, but use non-secure imap (port 143)
2. Use a self-signed cert and update both client and server when it expires.
3. Use a commercial certificate and then only have to update the server when it expires.  (It is signed by a certificate authority in your keystore.)
4. Ignore host verification completely, assuming you're not worried about a man-in-the-middle attack.

Disable SSL host verification with the following code.  (It always returns true.)

     * Disable the verification of the server hostname.
     * For debugging, use
     * For HTTPS, verify name in certificate matches hostname in URL.
     * If set, JSSE calls HostnameVerifier if its matching fails.
    public static void disableHostVerify()
    { HostnameVerifier()
            public boolean verify(String hostname, SSLSession session)
                logger.log(Level.INFO, "Verifying host: " + hostname + " and peer host: "
                    + session.getPeerHost());
                return true;

We are getting:

Message: AUTHENTICATE failed.

...with Exchange 2007 (IMAP enabled and everything...)

Did you try using imaps as your protocol instead of imap?
IMAPS definitely does not work.  We're using IMAP.  email admin got the error to change to "No login methods supported" now.

We will now try a previous post:

"To those of you seeking help to the "No login methods supported" error when trying to connect with IMAP on Exchange 2007, I can recommend checking your IMAP4 settings in the Client Access part of your exchange server. The authentication is normally set to TLS (secure), but if it has to run with IMAP (not secure), it has to be set to basic authentication (NO-TLS).
"NO-TLS" didn't work.  This is getting critical. E-mail customer support is down without this piece of junk.
Have you filed a case with support?  Ultimately it's really just a Javamail issue, not Email To Case per se, but there probably is a very simple explanation.

Incidentally in the Spring '09 release in a few weeks there will be On Demand Email To Case.  In On Demand Email To Case you'll be able to just forward your emails to a box and will process it just as it does with Email To Case today -- no more Email To Case Java client needed.
Also: why do you say that imaps definitely will not work?
Yes, a case has been opened.  IMAPS definitely did not work. IMAPS with port AUTHENTICATION failed.  IMAP with port 143 gives us "no login methods supported!".

It does seem to be a java issue, in which case, the piece-o-junk email2case needs to be updated.
My point is actually that there's nothing that needs to be changed about Email To Case or Javamail -- just that all apps that use Javamail will behave in this way when IMAP has a certain configuration.  For example:

Note that at the bottom of the first article the author says:

I got it working.

In Zimbra I needed to specify that I could use plaintext passwords for the imap protocol.

He's using Zimbra as his mail server, not Exchange, but the concept may be the same.  I am unfortunately not familiar enough with Exchange to know how to do this in Exchange.
I assume that's what the "NO-TLS" thing is about, correct? If so, we tried that too.

We still have an unanswered case open with Salesforce...we should hear from them in the next week or so while our customer support email is still not functional.  Fun fun fun!  Along with the global failure a few days ago, this has been a wild ride.

It's been a long time, but I finally got this working. Since I started, we ended up getting a real certificate, but I found other problems we had that might help people who are trying to go the self-cert route.


#1 - the keytool.exe tips were not helping me. I believe I was running the right commands to get my cert put into the Java settings as a Root CA, and I got messages that said it worked, but I don't think it did. The third-party cert we purchased was not trusted by Java by default. I used KeyTool UI to get their cert in there as a root, and I imagine you might be able to put your self-signed one in the same way.


I went to import/Keystore's entry/Trusted Certificate/Root CA Certificate and used that screen to import what I got from the CA's web page.


#2 - And I don't know how I tripped over this. After you go through all the effort of getting your cert trusted by Java, make sure that's the cert Exchange is using for IMAPS. In my case, it was set to use an old expired self-cert. Open the Exchange Management Console, go to "Microsoft Exchange/Server Configuration/Client Access" in the left pane. click the POP3 and IMAP tab in the right pane, and double-click IMAP4 in the list of protocols. Click the Authentication tab. Make sure the X.509 certificate name field matches the cert that shows up when you use webmail.


I hope this all makes sense. I'm not a Java developer or an Exchange administrator.


By the way, I got the Email Agent to run as a service. Let me know if I should post instructions, or if everybody already knows how to do this.

Not sure if you noticed, but Spring '09 gets rid of the Email2Case java crapplication, altogether.  Praise Zeus!
Oh, and I imagine if you went to the Exchange screen I mentioned in point #2 above and chose "Plain Text Logon" then you would get rid of the "No login methods supported" error when you try to use IMAP instead of IMAPS.