Connecting with GroupWise-specific SASL provider with JavaMail IMAP

[David Sitsky]

Hi,

I need to develop some code which will connect to a GroupWise IMAP
server.  GroupWise has a special mode for "trusted applications", where
once you are authenticated, you can login as any user without entering
in a password.

This is used for developing virus-scanners and other software which
requires access to all the email in a GroupWise mail server.

I have developed a GroupWise-specific SASL provider and have integrated
it into JavaMail, by setting the appropriate properties in a JavaMail
session, and adding this provider to the security framework.

I can see it is getting called when I am trying to connect to the
GroupWise server.

The problem I am facing is as follows.  Here is an example IMAP
conversation with my GroupWise server:

S: * OK GroupWise IMAP4rev1 Server Ready
C: A010 AUTHENTICATE XGWTRUSTEDAPP
S: +
C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
                  4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
S: A010 OK XGWTRUSTEDAPP authentication successful

The client response data after XGWTRUSTEDAPP is the base64 encoding of
the special GroupWise "application ID + key".

What is currently causing a problem is the GroupWise IMAP server needs
the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
response.

Looking at the code in IMAPSaslAuthenticator.java, it rightly base64
encodes the response, but doesn't provide any way for me to insert the
"XGWTRUSTEDAPP " string before this base64 data.

Is there any way I can achieve this?  Is the GroupWise
challenge/response mechanism here not SASL compliant?  Is there a better
way for me to achieve this?

Thanks for any help or suggestions.

Cheers,
David



--
Cheers,
David

This message is intended only for the named recipient.  If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action  in reliance on the contents of this
information is strictly prohibited.

Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007

Phone: [phone]
Fax: [phone]

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

David Sitsky wrote:

> Hi,
>
> I need to develop some code which will connect to a GroupWise IMAP
> server.  GroupWise has a special mode for "trusted applications", where
> once you are authenticated, you can login as any user without entering
> in a password.
>
> This is used for developing virus-scanners and other software which
> requires access to all the email in a GroupWise mail server.
>
> I have developed a GroupWise-specific SASL provider and have integrated
> it into JavaMail, by setting the appropriate properties in a JavaMail
> session, and adding this provider to the security framework.
>
> I can see it is getting called when I am trying to connect to the
> GroupWise server.
>
> The problem I am facing is as follows.  Here is an example IMAP
> conversation with my GroupWise server:
>
> S: * OK GroupWise IMAP4rev1 Server Ready
> C: A010 AUTHENTICATE XGWTRUSTEDAPP
> S: +
> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>                  4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
> S: A010 OK XGWTRUSTEDAPP authentication successful
>
> The client response data after XGWTRUSTEDAPP is the base64 encoding of
> the special GroupWise "application ID + key".
>
> What is currently causing a problem is the GroupWise IMAP server needs
> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
> response.
>
> Looking at the code in IMAPSaslAuthenticator.java, it rightly base64
> encodes the response, but doesn't provide any way for me to insert the
> "XGWTRUSTEDAPP " string before this base64 data.
>
> Is there any way I can achieve this?  Is the GroupWise
> challenge/response mechanism here not SASL compliant?  Is there a better
> way for me to achieve this?

They're not following the IMAP AUTHENTICATE command spec, which says:

       The authentication protocol exchange consists of a series of
       server challenges and client responses that are specific to the
       authentication mechanism.  A server challenge consists of a
       command continuation request response with the "+" token followed
       by a BASE64 encoded string.  The client response consists of a
       single line consisting of a BASE64 encoded string.  ...

Given that you're authenticating with the XGWTRUSTEDAPP
mechanism, I don't see what the point is of including
XGWTRUSTEDAPP in the response.

Maybe you could report this as a protocol violation to Novell and
see if they're willing to fix it?

I also don't see an easy way to do this within the current
structure of JavaMail's SASL support.  If Novell won't fix this bug,
the best thing to do is probably to add yet another server-specific
hack to JavaMail to handle this case, something like this:

------- IMAPSaslAuthenticator.java -------
*** /tmp/sccs.xdaGCe    Thu Aug 31 10:21:07 2006
--- IMAPSaslAuthenticator.java  Thu Aug 31 10:20:48 2006
***************
*** 163,168 ****
--- 163,170 ----
         ByteArrayOutputStream bos = new ByteArrayOutputStream();
         byte[] CRLF = { (byte)'\r', (byte)'\n'};

+       // Hack for Novell GroupWise XGWTRUSTEDAPP authentication mechanism
+       boolean isXGWTRUSTEDAPP = sc.getMechanismName().equals("XGWTRUSTEDAPP");
         while (!done) { // loop till we are done
             try {
                 r = pr.readResponse();
***************
*** 188,193 ****
--- 190,197 ----
                             out.println("IMAP SASL DEBUG: response: " +
                                 ASCIIUtility.toString(ba, 0, ba.length) + " :");
                         ba = BASE64EncoderStream.encode(ba);
+                       if (isXGWTRUSTEDAPP)
+                           bos.write("XGWTRUSTEDAPP ".getBytes());
                         bos.write(ba);

                         bos.write(CRLF);        // CRLF termination


Any chance you're going to make your XGWTRUSTEDAPP SASL support available
to others?  If so, I'd be more willing to add the above to JavaMail.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[David Sitsky]

Bill Shannon wrote:
> David Sitsky wrote:
>> Hi,
>>
 >> [...]
 >>

>> The problem I am facing is as follows.  Here is an example IMAP
>> conversation with my GroupWise server:
>>
>> S: * OK GroupWise IMAP4rev1 Server Ready
>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>> S: +
>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>                  4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>
>> The client response data after XGWTRUSTEDAPP is the base64 encoding of
>> the special GroupWise "application ID + key".
>>
>> What is currently causing a problem is the GroupWise IMAP server needs
>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>> response.
>>

 >> [...]

>
> They're not following the IMAP AUTHENTICATE command spec, which says:
>
>       The authentication protocol exchange consists of a series of
>       server challenges and client responses that are specific to the
>       authentication mechanism.  A server challenge consists of a
>       command continuation request response with the "+" token followed
>       by a BASE64 encoded string.  The client response consists of a
>       single line consisting of a BASE64 encoded string.  ...
>
> Given that you're authenticating with the XGWTRUSTEDAPP
> mechanism, I don't see what the point is of including
> XGWTRUSTEDAPP in the response.
>
> Maybe you could report this as a protocol violation to Novell and
> see if they're willing to fix it?

I'll definitely send this report to Novell.  Thanks for the explanation.

> I also don't see an easy way to do this within the current
> structure of JavaMail's SASL support.  If Novell won't fix this bug,
> the best thing to do is probably to add yet another server-specific
> hack to JavaMail to handle this case, something like this:

Thanks for the advice... such a shame the "hack" is needed, thanks
Novell. :)

> Any chance you're going to make your XGWTRUSTEDAPP SASL support available
> to others?  If so, I'd be more willing to add the above to JavaMail.

Once the code is stable, and if I get approval from management, no
worries.  Its pretty simple code.

Thanks again for your prompt response.

--
Cheers,
David

This message is intended only for the named recipient.  If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action  in reliance on the contents of this
information is strictly prohibited.

Nuix Australia Pty Ltd
Suite 79
89 Jones St
Ultimo NSW 2007

Phone: [phone]
Fax: [phone]

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

just saw this, and I'm going to find exactly  the same scenario with
groupise in the following days, did anything got contrituted in the
end?

thanks
javier

On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:

> Bill Shannon wrote:
>>
>> David Sitsky wrote:
>>>
>>> Hi,
>>>
>>> [...]
>>>
>>>
>>> The problem I am facing is as follows.  Here is an example IMAP
>>> conversation with my GroupWise server:
>>>
>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>> S: +
>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>                 4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>
>>> The client response data after XGWTRUSTEDAPP is the base64 encoding of
>>> the special GroupWise "application ID + key".
>>>
>>> What is currently causing a problem is the GroupWise IMAP server needs
>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>> response.
>>>
>>> [...]
>>
>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>
>>      The authentication protocol exchange consists of a series of
>>      server challenges and client responses that are specific to the
>>      authentication mechanism.  A server challenge consists of a
>>      command continuation request response with the "+" token followed
>>      by a BASE64 encoded string.  The client response consists of a
>>      single line consisting of a BASE64 encoded string.  ...
>>
>> Given that you're authenticating with the XGWTRUSTEDAPP
>> mechanism, I don't see what the point is of including
>> XGWTRUSTEDAPP in the response.
>>
>> Maybe you could report this as a protocol violation to Novell and
>> see if they're willing to fix it?
>
> I'll definitely send this report to Novell.  Thanks for the explanation.
>
>> I also don't see an easy way to do this within the current
>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>> the best thing to do is probably to add yet another server-specific
>> hack to JavaMail to handle this case, something like this:
>
> Thanks for the advice... such a shame the "hack" is needed, thanks
> Novell. :)
>
>> Any chance you're going to make your XGWTRUSTEDAPP SASL support available
>> to others?  If so, I'd be more willing to add the above to JavaMail.
>
> Once the code is stable, and if I get approval from management, no
> worries.  Its pretty simple code.
>
> Thanks again for your prompt response.
>
> --
> Cheers,
> David
>
> This message is intended only for the named recipient.  If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action  in reliance on the contents of this
> information is strictly prohibited.
>
> Nuix Australia Pty Ltd
> Suite 79
> 89 Jones St
> Ultimo NSW 2007
>
> Phone: [phone]
> Fax: [phone]
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
> listserv@... and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

Yes, there's a hack in JavaMail 1.4.1 for this.  Let me know if it works
for you too.


jm wrote:

> just saw this, and I'm going to find exactly  the same scenario with
> groupise in the following days, did anything got contrituted in the
> end?
>
> thanks
> javier
>
> On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:
>> Bill Shannon wrote:
>>> David Sitsky wrote:
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>>
>>>> The problem I am facing is as follows.  Here is an example IMAP
>>>> conversation with my GroupWise server:
>>>>
>>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>>> S: +
>>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>>                 4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>>
>>>> The client response data after XGWTRUSTEDAPP is the base64 encoding of
>>>> the special GroupWise "application ID + key".
>>>>
>>>> What is currently causing a problem is the GroupWise IMAP server needs
>>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>>> response.
>>>>
>>>> [...]
>>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>>
>>>      The authentication protocol exchange consists of a series of
>>>      server challenges and client responses that are specific to the
>>>      authentication mechanism.  A server challenge consists of a
>>>      command continuation request response with the "+" token followed
>>>      by a BASE64 encoded string.  The client response consists of a
>>>      single line consisting of a BASE64 encoded string.  ...
>>>
>>> Given that you're authenticating with the XGWTRUSTEDAPP
>>> mechanism, I don't see what the point is of including
>>> XGWTRUSTEDAPP in the response.
>>>
>>> Maybe you could report this as a protocol violation to Novell and
>>> see if they're willing to fix it?
>> I'll definitely send this report to Novell.  Thanks for the explanation.
>>
>>> I also don't see an easy way to do this within the current
>>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>>> the best thing to do is probably to add yet another server-specific
>>> hack to JavaMail to handle this case, something like this:
>> Thanks for the advice... such a shame the "hack" is needed, thanks
>> Novell. :)
>>
>>> Any chance you're going to make your XGWTRUSTEDAPP SASL support available
>>> to others?  If so, I'd be more willing to add the above to JavaMail.
>> Once the code is stable, and if I get approval from management, no
>> worries.  Its pretty simple code.
>>
>> Thanks again for your prompt response.
>>
>> --
>> Cheers,
>> David
>>
>> This message is intended only for the named recipient.  If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action  in reliance on the contents of this
>> information is strictly prohibited.
>>
>> Nuix Australia Pty Ltd
>> Suite 79
>> 89 Jones St
>> Ultimo NSW 2007
>>
>> Phone: [phone]
>> Fax: [phone]
>>
>> ===========================================================================
>> To unsubscribe, send email to listserv@... and include in the body
>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
>> listserv@... and include in the body of the message "help".
>>
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
> listserv@... and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
SASL support ?? Or the support is just that small hack??

thanks

On Mon, Dec 1, 2008 at 11:56 PM, Bill Shannon <bill.shannon@...> wrote:

> Yes, there's a hack in JavaMail 1.4.1 for this.  Let me know if it works
> for you too.
>
>
> jm wrote:
>>
>> just saw this, and I'm going to find exactly  the same scenario with
>> groupise in the following days, did anything got contrituted in the
>> end?
>>
>> thanks
>> javier
>>
>> On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:
>>>
>>> Bill Shannon wrote:
>>>>
>>>> David Sitsky wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>> The problem I am facing is as follows.  Here is an example IMAP
>>>>> conversation with my GroupWise server:
>>>>>
>>>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>>>> S: +
>>>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>>>                4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>>>
>>>>> The client response data after XGWTRUSTEDAPP is the base64 encoding of
>>>>> the special GroupWise "application ID + key".
>>>>>
>>>>> What is currently causing a problem is the GroupWise IMAP server needs
>>>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>>>> response.
>>>>>
>>>>> [...]
>>>>
>>>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>>>
>>>>     The authentication protocol exchange consists of a series of
>>>>     server challenges and client responses that are specific to the
>>>>     authentication mechanism.  A server challenge consists of a
>>>>     command continuation request response with the "+" token followed
>>>>     by a BASE64 encoded string.  The client response consists of a
>>>>     single line consisting of a BASE64 encoded string.  ...
>>>>
>>>> Given that you're authenticating with the XGWTRUSTEDAPP
>>>> mechanism, I don't see what the point is of including
>>>> XGWTRUSTEDAPP in the response.
>>>>
>>>> Maybe you could report this as a protocol violation to Novell and
>>>> see if they're willing to fix it?
>>>
>>> I'll definitely send this report to Novell.  Thanks for the explanation.
>>>
>>>> I also don't see an easy way to do this within the current
>>>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>>>> the best thing to do is probably to add yet another server-specific
>>>> hack to JavaMail to handle this case, something like this:
>>>
>>> Thanks for the advice... such a shame the "hack" is needed, thanks
>>> Novell. :)
>>>
>>>> Any chance you're going to make your XGWTRUSTEDAPP SASL support
>>>> available
>>>> to others?  If so, I'd be more willing to add the above to JavaMail.
>>>
>>> Once the code is stable, and if I get approval from management, no
>>> worries.  Its pretty simple code.
>>>
>>> Thanks again for your prompt response.
>>>
>>> --
>>> Cheers,
>>> David
>>>
>>> This message is intended only for the named recipient.  If you are
>>> not the intended recipient you are notified that disclosing, copying,
>>> distributing or taking any action  in reliance on the contents of this
>>> information is strictly prohibited.
>>>
>>> Nuix Australia Pty Ltd
>>> Suite 79
>>> 89 Jones St
>>> Ultimo NSW 2007
>>>
>>> Phone: [phone]
>>> Fax: [phone]
>>>
>>>
>>> ===========================================================================
>>> To unsubscribe, send email to listserv@... and include in the
>>> body
>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email
>>> to
>>> listserv@... and include in the body of the message "help".
>>>
>>
>>
>> ===========================================================================
>> To unsubscribe, send email to listserv@... and include in the
>> body
>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email
>> to
>> listserv@... and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
You'll still need the XGWTRUSTEDAPP SASL support.  Hopefully
David has made that available.


jm wrote:

> I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
> SASL support ?? Or the support is just that small hack??
>
> thanks
>
> On Mon, Dec 1, 2008 at 11:56 PM, Bill Shannon <bill.shannon@...> wrote:
>> Yes, there's a hack in JavaMail 1.4.1 for this.  Let me know if it works
>> for you too.
>>
>>
>> jm wrote:
>>> just saw this, and I'm going to find exactly  the same scenario with
>>> groupise in the following days, did anything got contrituted in the
>>> end?
>>>
>>> thanks
>>> javier
>>>
>>> On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:
>>>> Bill Shannon wrote:
>>>>> David Sitsky wrote:
>>>>>> Hi,
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>> The problem I am facing is as follows.  Here is an example IMAP
>>>>>> conversation with my GroupWise server:
>>>>>>
>>>>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>>>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>>>>> S: +
>>>>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>>>>                4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>>>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>>>>
>>>>>> The client response data after XGWTRUSTEDAPP is the base64 encoding of
>>>>>> the special GroupWise "application ID + key".
>>>>>>
>>>>>> What is currently causing a problem is the GroupWise IMAP server needs
>>>>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>>>>> response.
>>>>>>
>>>>>> [...]
>>>>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>>>>
>>>>>     The authentication protocol exchange consists of a series of
>>>>>     server challenges and client responses that are specific to the
>>>>>     authentication mechanism.  A server challenge consists of a
>>>>>     command continuation request response with the "+" token followed
>>>>>     by a BASE64 encoded string.  The client response consists of a
>>>>>     single line consisting of a BASE64 encoded string.  ...
>>>>>
>>>>> Given that you're authenticating with the XGWTRUSTEDAPP
>>>>> mechanism, I don't see what the point is of including
>>>>> XGWTRUSTEDAPP in the response.
>>>>>
>>>>> Maybe you could report this as a protocol violation to Novell and
>>>>> see if they're willing to fix it?
>>>> I'll definitely send this report to Novell.  Thanks for the explanation.
>>>>
>>>>> I also don't see an easy way to do this within the current
>>>>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>>>>> the best thing to do is probably to add yet another server-specific
>>>>> hack to JavaMail to handle this case, something like this:
>>>> Thanks for the advice... such a shame the "hack" is needed, thanks
>>>> Novell. :)
>>>>
>>>>> Any chance you're going to make your XGWTRUSTEDAPP SASL support
>>>>> available
>>>>> to others?  If so, I'd be more willing to add the above to JavaMail.
>>>> Once the code is stable, and if I get approval from management, no
>>>> worries.  Its pretty simple code.
>>>>
>>>> Thanks again for your prompt response.
>>>>
>>>> --
>>>> Cheers,
>>>> David
>>>>
>>>> This message is intended only for the named recipient.  If you are
>>>> not the intended recipient you are notified that disclosing, copying,
>>>> distributing or taking any action  in reliance on the contents of this
>>>> information is strictly prohibited.
>>>>
>>>> Nuix Australia Pty Ltd
>>>> Suite 79
>>>> 89 Jones St
>>>> Ultimo NSW 2007
>>>>
>>>> Phone: [phone]
>>>> Fax: [phone]
>>>>
>>>>
>>>> ===========================================================================
>>>> To unsubscribe, send email to listserv@... and include in the
>>>> body
>>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email
>>>> to
>>>> listserv@... and include in the body of the message "help".
>>>>
>>>
>>> ===========================================================================
>>> To unsubscribe, send email to listserv@... and include in the
>>> body
>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send email
>>> to
>>> listserv@... and include in the body of the message "help".
>>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

Hi,

I contaced David and unfortunately he was not allowed to donate the
code. So I am trying to build it myself. I have made some progress but
I have already a problem that must be overcome. I am working mostly by
trial and error so bear with me if I make big mistakes.

 I have built a provider GroupwiseSaslProvider (and associated factory
etc), that provides only:
                put("SaslClientFactory.XGWTRUSTEDAPP",
"com.etc.sasl.GwTrustedAppClientFactoryImpl");
and I have added to the security providers:
Security.insertProviderAt(new
com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);

The problem is, my javamail program picks PLAIN authentication before
XGWTRUSTEDAPP authentication. If before adding my provided, I remove
all other existing providers, then my provider kicks in, and the sasl
authentication works (I have to debug more but at least logs in ok
etc). But without the rest of the providers other parts of my code
break of course (https etc).

I am of course sure there must be some easy way to make my code use
XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
Can someone point me to it?

I might be able to provide my working implementation when it works to
you Bill if you can make so use of it, not sure about its overall
quality though.

regards,
javier


On Mon, Dec 15, 2008 at 6:26 PM, Bill Shannon <bill.shannon@...> wrote:

> Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
> You'll still need the XGWTRUSTEDAPP SASL support.  Hopefully
> David has made that available.
>
>
> jm wrote:
>>
>> I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
>> SASL support ?? Or the support is just that small hack??
>>
>> thanks
>>
>> On Mon, Dec 1, 2008 at 11:56 PM, Bill Shannon <bill.shannon@...>
>> wrote:
>>>
>>> Yes, there's a hack in JavaMail 1.4.1 for this.  Let me know if it works
>>> for you too.
>>>
>>>
>>> jm wrote:
>>>>
>>>> just saw this, and I'm going to find exactly  the same scenario with
>>>> groupise in the following days, did anything got contrituted in the
>>>> end?
>>>>
>>>> thanks
>>>> javier
>>>>
>>>> On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:
>>>>>
>>>>> Bill Shannon wrote:
>>>>>>
>>>>>> David Sitsky wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>> The problem I am facing is as follows.  Here is an example IMAP
>>>>>>> conversation with my GroupWise server:
>>>>>>>
>>>>>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>>>>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>>>>>> S: +
>>>>>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>>>>>               4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>>>>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>>>>>
>>>>>>> The client response data after XGWTRUSTEDAPP is the base64 encoding
>>>>>>> of
>>>>>>> the special GroupWise "application ID + key".
>>>>>>>
>>>>>>> What is currently causing a problem is the GroupWise IMAP server
>>>>>>> needs
>>>>>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>>>>>> response.
>>>>>>>
>>>>>>> [...]
>>>>>>
>>>>>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>>>>>
>>>>>>    The authentication protocol exchange consists of a series of
>>>>>>    server challenges and client responses that are specific to the
>>>>>>    authentication mechanism.  A server challenge consists of a
>>>>>>    command continuation request response with the "+" token followed
>>>>>>    by a BASE64 encoded string.  The client response consists of a
>>>>>>    single line consisting of a BASE64 encoded string.  ...
>>>>>>
>>>>>> Given that you're authenticating with the XGWTRUSTEDAPP
>>>>>> mechanism, I don't see what the point is of including
>>>>>> XGWTRUSTEDAPP in the response.
>>>>>>
>>>>>> Maybe you could report this as a protocol violation to Novell and
>>>>>> see if they're willing to fix it?
>>>>>
>>>>> I'll definitely send this report to Novell.  Thanks for the
>>>>> explanation.
>>>>>
>>>>>> I also don't see an easy way to do this within the current
>>>>>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>>>>>> the best thing to do is probably to add yet another server-specific
>>>>>> hack to JavaMail to handle this case, something like this:
>>>>>
>>>>> Thanks for the advice... such a shame the "hack" is needed, thanks
>>>>> Novell. :)
>>>>>
>>>>>> Any chance you're going to make your XGWTRUSTEDAPP SASL support
>>>>>> available
>>>>>> to others?  If so, I'd be more willing to add the above to JavaMail.
>>>>>
>>>>> Once the code is stable, and if I get approval from management, no
>>>>> worries.  Its pretty simple code.
>>>>>
>>>>> Thanks again for your prompt response.
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> This message is intended only for the named recipient.  If you are
>>>>> not the intended recipient you are notified that disclosing, copying,
>>>>> distributing or taking any action  in reliance on the contents of this
>>>>> information is strictly prohibited.
>>>>>
>>>>> Nuix Australia Pty Ltd
>>>>> Suite 79
>>>>> 89 Jones St
>>>>> Ultimo NSW 2007
>>>>>
>>>>> Phone: [phone]
>>>>> Fax: [phone]
>>>>>
>>>>>
>>>>>
>>>>> ===========================================================================
>>>>> To unsubscribe, send email to listserv@... and include in the
>>>>> body
>>>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send
>>>>> email
>>>>> to
>>>>> listserv@... and include in the body of the message "help".
>>>>>
>>>>
>>>>
>>>> ===========================================================================
>>>> To unsubscribe, send email to listserv@... and include in the
>>>> body
>>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send
>>>> email
>>>> to
>>>> listserv@... and include in the body of the message "help".
>>>
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

And just to get the whole information at the same time, I have a
second problem. When I log by hand on a telnet, I do the follwoing:

* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT XGWEXTENSIONS]
 Server Ready
A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
A0 OK XGWTRUSTEDAPP authentication successful
. LOGIN USER22
. OK LOGIN completed
. LIST "" "%"
* LIST (\Unmarked) "/" "INBOX"
* LIST (\Noinferiors \Unmarked) "/" "Sent Items"
* LIST (\Unmarked) "/" "Calendar"
* LIST (\Noinferiors \Unmarked) "/" "Tasklist"
* LIST (\Unmarked) "/" "Cabinet"
* LIST (\Noinferiors \Unmarked) "/" "Trash"
. OK LIST completed

When I do it why my java code, all goes as planned, but after getting
A0 OK XGWTRUSTEDAPP authentication successful
my java code does not issue a LOGIN USER22 to go into that user
mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
So the  next command, the LIST fails. Any idea on how I am doing
wrong??

many thanks
javier


A0 AUTHENTICATE XGWTRUSTEDAPP
+
XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2MjBGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=


On Mon, Dec 22, 2008 at 11:38 AM, jm <jmuguruza@...> wrote:

> Hi,
>
> I contaced David and unfortunately he was not allowed to donate the
> code. So I am trying to build it myself. I have made some progress but
> I have already a problem that must be overcome. I am working mostly by
> trial and error so bear with me if I make big mistakes.
>
>  I have built a provider GroupwiseSaslProvider (and associated factory
> etc), that provides only:
>                put("SaslClientFactory.XGWTRUSTEDAPP",
> "com.etc.sasl.GwTrustedAppClientFactoryImpl");
> and I have added to the security providers:
> Security.insertProviderAt(new
> com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
>
> The problem is, my javamail program picks PLAIN authentication before
> XGWTRUSTEDAPP authentication. If before adding my provided, I remove
> all other existing providers, then my provider kicks in, and the sasl
> authentication works (I have to debug more but at least logs in ok
> etc). But without the rest of the providers other parts of my code
> break of course (https etc).
>
> I am of course sure there must be some easy way to make my code use
> XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
> Can someone point me to it?
>
> I might be able to provide my working implementation when it works to
> you Bill if you can make so use of it, not sure about its overall
> quality though.
>
> regards,
> javier
>
>
> On Mon, Dec 15, 2008 at 6:26 PM, Bill Shannon <bill.shannon@...> wrote:
>> Just the hack to allow the XGWTRUSTEDAPP SASL support to work.
>> You'll still need the XGWTRUSTEDAPP SASL support.  Hopefully
>> David has made that available.
>>
>>
>> jm wrote:
>>>
>>> I understand the 'hack' got into javamail, but not the XGWTRUSTEDAPP
>>> SASL support ?? Or the support is just that small hack??
>>>
>>> thanks
>>>
>>> On Mon, Dec 1, 2008 at 11:56 PM, Bill Shannon <bill.shannon@...>
>>> wrote:
>>>>
>>>> Yes, there's a hack in JavaMail 1.4.1 for this.  Let me know if it works
>>>> for you too.
>>>>
>>>>
>>>> jm wrote:
>>>>>
>>>>> just saw this, and I'm going to find exactly  the same scenario with
>>>>> groupise in the following days, did anything got contrituted in the
>>>>> end?
>>>>>
>>>>> thanks
>>>>> javier
>>>>>
>>>>> On Fri, Sep 1, 2006 at 12:00 AM, David Sitsky <sits@...> wrote:
>>>>>>
>>>>>> Bill Shannon wrote:
>>>>>>>
>>>>>>> David Sitsky wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>
>>>>>>>> The problem I am facing is as follows.  Here is an example IMAP
>>>>>>>> conversation with my GroupWise server:
>>>>>>>>
>>>>>>>> S: * OK GroupWise IMAP4rev1 Server Ready
>>>>>>>> C: A010 AUTHENTICATE XGWTRUSTEDAPP
>>>>>>>> S: +
>>>>>>>> C: XGWTRUSTEDAPP ZmJpADQ5NjRBNjAxMTgxNjAwMDBCNjAwRDIwMDdDMDA
>>>>>>>>               4NTAwNDk2NEE2MDIxODE2MDAwMEI2MDBEMjAwN0MwMDg1MDAA
>>>>>>>> S: A010 OK XGWTRUSTEDAPP authentication successful
>>>>>>>>
>>>>>>>> The client response data after XGWTRUSTEDAPP is the base64 encoding
>>>>>>>> of
>>>>>>>> the special GroupWise "application ID + key".
>>>>>>>>
>>>>>>>> What is currently causing a problem is the GroupWise IMAP server
>>>>>>>> needs
>>>>>>>> the "XGWTRUSTEDAPP " string before this base 64 data in the challenge
>>>>>>>> response.
>>>>>>>>
>>>>>>>> [...]
>>>>>>>
>>>>>>> They're not following the IMAP AUTHENTICATE command spec, which says:
>>>>>>>
>>>>>>>    The authentication protocol exchange consists of a series of
>>>>>>>    server challenges and client responses that are specific to the
>>>>>>>    authentication mechanism.  A server challenge consists of a
>>>>>>>    command continuation request response with the "+" token followed
>>>>>>>    by a BASE64 encoded string.  The client response consists of a
>>>>>>>    single line consisting of a BASE64 encoded string.  ...
>>>>>>>
>>>>>>> Given that you're authenticating with the XGWTRUSTEDAPP
>>>>>>> mechanism, I don't see what the point is of including
>>>>>>> XGWTRUSTEDAPP in the response.
>>>>>>>
>>>>>>> Maybe you could report this as a protocol violation to Novell and
>>>>>>> see if they're willing to fix it?
>>>>>>
>>>>>> I'll definitely send this report to Novell.  Thanks for the
>>>>>> explanation.
>>>>>>
>>>>>>> I also don't see an easy way to do this within the current
>>>>>>> structure of JavaMail's SASL support.  If Novell won't fix this bug,
>>>>>>> the best thing to do is probably to add yet another server-specific
>>>>>>> hack to JavaMail to handle this case, something like this:
>>>>>>
>>>>>> Thanks for the advice... such a shame the "hack" is needed, thanks
>>>>>> Novell. :)
>>>>>>
>>>>>>> Any chance you're going to make your XGWTRUSTEDAPP SASL support
>>>>>>> available
>>>>>>> to others?  If so, I'd be more willing to add the above to JavaMail.
>>>>>>
>>>>>> Once the code is stable, and if I get approval from management, no
>>>>>> worries.  Its pretty simple code.
>>>>>>
>>>>>> Thanks again for your prompt response.
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> This message is intended only for the named recipient.  If you are
>>>>>> not the intended recipient you are notified that disclosing, copying,
>>>>>> distributing or taking any action  in reliance on the contents of this
>>>>>> information is strictly prohibited.
>>>>>>
>>>>>> Nuix Australia Pty Ltd
>>>>>> Suite 79
>>>>>> 89 Jones St
>>>>>> Ultimo NSW 2007
>>>>>>
>>>>>> Phone: [phone]
>>>>>> Fax: [phone]
>>>>>>
>>>>>>
>>>>>>
>>>>>> ===========================================================================
>>>>>> To unsubscribe, send email to listserv@... and include in the
>>>>>> body
>>>>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send
>>>>>> email
>>>>>> to
>>>>>> listserv@... and include in the body of the message "help".
>>>>>>
>>>>>
>>>>>
>>>>> ===========================================================================
>>>>> To unsubscribe, send email to listserv@... and include in the
>>>>> body
>>>>> of the message "signoff JAVAMAIL-INTEREST".  For general help, send
>>>>> email
>>>>> to
>>>>> listserv@... and include in the body of the message "help".
>>>>
>>
>>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

jm wrote:

> Hi,
>
> I contaced David and unfortunately he was not allowed to donate the
> code. So I am trying to build it myself. I have made some progress but
> I have already a problem that must be overcome. I am working mostly by
> trial and error so bear with me if I make big mistakes.
>
>  I have built a provider GroupwiseSaslProvider (and associated factory
> etc), that provides only:
>                 put("SaslClientFactory.XGWTRUSTEDAPP",
> "com.etc.sasl.GwTrustedAppClientFactoryImpl");
> and I have added to the security providers:
> Security.insertProviderAt(new
> com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
>
> The problem is, my javamail program picks PLAIN authentication before
> XGWTRUSTEDAPP authentication. If before adding my provided, I remove
> all other existing providers, then my provider kicks in, and the sasl
> authentication works (I have to debug more but at least logs in ok
> etc). But without the rest of the providers other parts of my code
> break of course (https etc).
>
> I am of course sure there must be some easy way to make my code use
> XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
> Can someone point me to it?

There's a property you can set to disable use of PLAIN authentication.
See the javadocs for the com.sun.mail.imap package.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

jm wrote:

> And just to get the whole information at the same time, I have a
> second problem. When I log by hand on a telnet, I do the follwoing:
>
> * OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT XGWEXTENSIONS]
>  Server Ready
> A0 AUTHENTICATE XGWTRUSTEDAPP
> +
> XGWTRUSTEDAPP R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
> BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
> A0 OK XGWTRUSTEDAPP authentication successful
> . LOGIN USER22
> . OK LOGIN completed
> . LIST "" "%"
> * LIST (\Unmarked) "/" "INBOX"
> * LIST (\Noinferiors \Unmarked) "/" "Sent Items"
> * LIST (\Unmarked) "/" "Calendar"
> * LIST (\Noinferiors \Unmarked) "/" "Tasklist"
> * LIST (\Unmarked) "/" "Cabinet"
> * LIST (\Noinferiors \Unmarked) "/" "Trash"
> . OK LIST completed
>
> When I do it why my java code, all goes as planned, but after getting
> A0 OK XGWTRUSTEDAPP authentication successful
> my java code does not issue a LOGIN USER22 to go into that user
> mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
> So the  next command, the LIST fails. Any idea on how I am doing
> wrong??

After doing the AUTNETHICATE, JavaMail thinks you're already logged in,
so there's no need to issue a login command.  Does the XGWTRUSTEDAPP
mechanism give you a way to specify both an authentication ID and an
authorization ID?

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

Hi Bill,

yes, I saw the property, but setting it to true does not work it for
me (either as string or boolean), see output:
DEBUG: getProvider() returning
javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc]
DEBUG: mail.imap.fetchsize: 16384
DEBUG: mail.imap.statuscachetimeout: 1000
DEBUG: mail.imap.appendbuffersize: -1
DEBUG: mail.imap.minidletime: 10
DEBUG: disable AUTH=PLAIN
DEBUG: enable SASL
DEBUG: mail.imap.sasl.authorizationid: user2
* OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT
XGWEXTENSIONS] Server Ready
IMAP DEBUG: AUTH: PLAIN
IMAP DEBUG: AUTH: XGWTRUSTEDAPP
DEBUG: protocolConnect login, host=groupwisehost, user=user2,
password=<non-null>
IMAP SASL DEBUG: Mechanisms: PLAIN XGWTRUSTEDAPP
IMAP SASL DEBUG: callback length: 2
IMAP SASL DEBUG: callback 0: javax.security.auth.callback.NameCallback@5a5140
IMAP SASL DEBUG: callback 1:
javax.security.auth.callback.PasswordCallback@18c4b30
IMAP SASL DEBUG: SASL client PLAIN
A0 AUTHENTICATE PLAIN
+
IMAP SASL DEBUG: challenge:  :
IMAP SASL DEBUG: response: user2

this is using latest beta of javamail1.4.2 you posted some weeks ago
javier

On Mon, Dec 22, 2008 at 5:18 PM, Bill Shannon <bill.shannon@...> wrote:

> jm wrote:
>>
>> Hi,
>>
>> I contaced David and unfortunately he was not allowed to donate the
>> code. So I am trying to build it myself. I have made some progress but
>> I have already a problem that must be overcome. I am working mostly by
>> trial and error so bear with me if I make big mistakes.
>>
>>  I have built a provider GroupwiseSaslProvider (and associated factory
>> etc), that provides only:
>>                put("SaslClientFactory.XGWTRUSTEDAPP",
>> "com.etc.sasl.GwTrustedAppClientFactoryImpl");
>> and I have added to the security providers:
>> Security.insertProviderAt(new
>> com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
>>
>> The problem is, my javamail program picks PLAIN authentication before
>> XGWTRUSTEDAPP authentication. If before adding my provided, I remove
>> all other existing providers, then my provider kicks in, and the sasl
>> authentication works (I have to debug more but at least logs in ok
>> etc). But without the rest of the providers other parts of my code
>> break of course (https etc).
>>
>> I am of course sure there must be some easy way to make my code use
>> XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
>> Can someone point me to it?
>
> There's a property you can set to disable use of PLAIN authentication.
> See the javadocs for the com.sun.mail.imap package.
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

I would not know what to reply here...if it helps, when I set a
breakpoint in IMAPStore, at line 534:

        if (enableSASL)
            p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
authzid has user22 (the one whose mailbox I  want to access)
and u has user2 (user given in the session) .


I have make it all work with a dirty hack in IMAPStore,  like this:

        if (enableSASL)
            p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
        if ("true".equals(System.getProperty("javamail.groupwisesasl"))) {
            p.login(authzid, pw);
        } else {
            if (p.isAuthenticated())
                ; // SASL login succeeded, go to bottom
            else if (p.hasCapability("AUTH=PLAIN") && !disableAuthPlain)
                p.authplain(authzid, u, pw);
            else if ((p.hasCapability("AUTH-LOGIN") ||
p.hasCapability("AUTH=LOGIN")) && !disableAuthLogin)
                p.authlogin(u, pw);
            else if (!p.hasCapability("LOGINDISABLED"))
                p.login(u, pw);
            else
                throw new ProtocolException("No login methods supported!");
        }

javier

On Mon, Dec 22, 2008 at 5:20 PM, Bill Shannon <bill.shannon@...> wrote:

> jm wrote:
>>
>> And just to get the whole information at the same time, I have a
>> second problem. When I log by hand on a telnet, I do the follwoing:
>>
>> * OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT
>> XGWEXTENSIONS]
>>  Server Ready
>> A0 AUTHENTICATE XGWTRUSTEDAPP
>> +
>> XGWTRUSTEDAPP
>> R1dBVEVNUE8AQjVENzIxNjEwRjgyMDAwMDg0QkJFMDAwNzMwMDk3MDBCNUQ3MjE2Mj
>> BGODIwMDAwODRCQkUwMDA3MzAwOTcwMAA=
>> A0 OK XGWTRUSTEDAPP authentication successful
>> . LOGIN USER22
>> . OK LOGIN completed
>> . LIST "" "%"
>> * LIST (\Unmarked) "/" "INBOX"
>> * LIST (\Noinferiors \Unmarked) "/" "Sent Items"
>> * LIST (\Unmarked) "/" "Calendar"
>> * LIST (\Noinferiors \Unmarked) "/" "Tasklist"
>> * LIST (\Unmarked) "/" "Cabinet"
>> * LIST (\Noinferiors \Unmarked) "/" "Trash"
>> . OK LIST completed
>>
>> When I do it why my java code, all goes as planned, but after getting
>> A0 OK XGWTRUSTEDAPP authentication successful
>> my java code does not issue a LOGIN USER22 to go into that user
>> mailbox (that user is the one set in "mail.imap.sasl.authorizationid".
>> So the  next command, the LIST fails. Any idea on how I am doing
>> wrong??
>
> After doing the AUTNETHICATE, JavaMail thinks you're already logged in,
> so there's no need to issue a login command.  Does the XGWTRUSTEDAPP
> mechanism give you a way to specify both an authentication ID and an
> authorization ID?
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

some advance...I resolved that issue by setting
                    props.put("mail.imap.sasl.mechanisms", "XGWTRUSTEDAPP");
this way that mechanism is always used instead of PLAIN

On Mon, Dec 22, 2008 at 5:59 PM, jm <jmuguruza@...> wrote:

> Hi Bill,
>
> yes, I saw the property, but setting it to true does not work it for
> me (either as string or boolean), see output:
> DEBUG: getProvider() returning
> javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
> Microsystems, Inc]
> DEBUG: mail.imap.fetchsize: 16384
> DEBUG: mail.imap.statuscachetimeout: 1000
> DEBUG: mail.imap.appendbuffersize: -1
> DEBUG: mail.imap.minidletime: 10
> DEBUG: disable AUTH=PLAIN
> DEBUG: enable SASL
> DEBUG: mail.imap.sasl.authorizationid: user2
> * OK [CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=XGWTRUSTEDAPP UNSELECT
> XGWEXTENSIONS] Server Ready
> IMAP DEBUG: AUTH: PLAIN
> IMAP DEBUG: AUTH: XGWTRUSTEDAPP
> DEBUG: protocolConnect login, host=groupwisehost, user=user2,
> password=<non-null>
> IMAP SASL DEBUG: Mechanisms: PLAIN XGWTRUSTEDAPP
> IMAP SASL DEBUG: callback length: 2
> IMAP SASL DEBUG: callback 0: javax.security.auth.callback.NameCallback@5a5140
> IMAP SASL DEBUG: callback 1:
> javax.security.auth.callback.PasswordCallback@18c4b30
> IMAP SASL DEBUG: SASL client PLAIN
> A0 AUTHENTICATE PLAIN
> +
> IMAP SASL DEBUG: challenge:  :
> IMAP SASL DEBUG: response: user2
>
> this is using latest beta of javamail1.4.2 you posted some weeks ago
> javier
>
> On Mon, Dec 22, 2008 at 5:18 PM, Bill Shannon <bill.shannon@...> wrote:
>> jm wrote:
>>>
>>> Hi,
>>>
>>> I contaced David and unfortunately he was not allowed to donate the
>>> code. So I am trying to build it myself. I have made some progress but
>>> I have already a problem that must be overcome. I am working mostly by
>>> trial and error so bear with me if I make big mistakes.
>>>
>>>  I have built a provider GroupwiseSaslProvider (and associated factory
>>> etc), that provides only:
>>>                put("SaslClientFactory.XGWTRUSTEDAPP",
>>> "com.etc.sasl.GwTrustedAppClientFactoryImpl");
>>> and I have added to the security providers:
>>> Security.insertProviderAt(new
>>> com.etc.sasl.GroupwiseSaslProvider(imapMta.getTrustedAppKey()), 1);
>>>
>>> The problem is, my javamail program picks PLAIN authentication before
>>> XGWTRUSTEDAPP authentication. If before adding my provided, I remove
>>> all other existing providers, then my provider kicks in, and the sasl
>>> authentication works (I have to debug more but at least logs in ok
>>> etc). But without the rest of the providers other parts of my code
>>> break of course (https etc).
>>>
>>> I am of course sure there must be some easy way to make my code use
>>> XGWTRUSTEDAPP instead of PLAIN without removing all other providers.
>>> Can someone point me to it?
>>
>> There's a property you can set to disable use of PLAIN authentication.
>> See the javadocs for the com.sun.mail.imap package.
>>
>>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

jm wrote:
> some advance...I resolved that issue by setting
>                     props.put("mail.imap.sasl.mechanisms", "XGWTRUSTEDAPP");
> this way that mechanism is always used instead of PLAIN

Right.  The other property controls the built-in PLAIN support in
JavaMail, but if you enable SASL it also has PLAIN support that is
controlled by the property above.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

jm wrote:
> I would not know what to reply here...if it helps, when I set a
> breakpoint in IMAPStore, at line 534:
>
>         if (enableSASL)
>             p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
> authzid has user22 (the one whose mailbox I  want to access)
> and u has user2 (user given in the session) .

That's a question for someone who understands the XGWTRUSTEDAPP authentication
mechanism.  Did you ask David if he handled this case in his implementation?
Is there public documentation for the XGWTRUSTEDAPP mechanism?

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[jmwap]

No I didn't ask David any more details, I think he moved on to other stuff.

I found this link where it seems they talk about the LOGIN after authentication:
http://developer.novell.com/documentation/gwimap/index.html?page=/documentation/gwimap/gwimpenu/data/al4pzys.html


On Mon, Dec 22, 2008 at 11:25 PM, Bill Shannon <bill.shannon@...> wrote:

> jm wrote:
>>
>> I would not know what to reply here...if it helps, when I set a
>> breakpoint in IMAPStore, at line 534:
>>
>>        if (enableSASL)
>>            p.sasllogin(saslMechanisms, saslRealm, authzid, u, pw);
>> authzid has user22 (the one whose mailbox I  want to access)
>> and u has user2 (user given in the session) .
>
> That's a question for someone who understands the XGWTRUSTEDAPP
> authentication
> mechanism.  Did you ask David if he handled this case in his implementation?
> Is there public documentation for the XGWTRUSTEDAPP mechanism?
>
>

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".