You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Christian Schäfer <cg...@cgs.at> on 2002/07/29 17:44:51 UTC

Quick Review & SMTP AUTH

hi,

i am currently searching for a substitution for sendmail.cf, because ...

therefore i have done a quick review of james-2.0a3.
pop3 get was ok.
smtp put was not so good:

1. the smtp auth login/plain implementation seems to be a bit different between certain clients and servers.
i used akmail, mozilla, and outlook express.

2.) since my akmail did not work with auth login i´ve tried to go via telnet:


1027873583831 [INFO   ] (smtpserver): Connection from 127.0.0.1 (127.0.0.1)
1027873597551 [INFO   ] (smtpserver): Command received: EHLO cgshome
1027873602788 [INFO   ] (smtpserver): Command received: AUTH LOGIN
1027873606664 [DEBUG  ] (smtpserver): Exception opening socket: null
java.lang.NullPointerException
	at org.apache.james.util.Base64.decodeAsString(Base64.java:36)
	at org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:350)
	at org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:238)
	at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:163)
	at org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(Connection.java:167)
	at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:47)
	at org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:86)


null-pointer exception if username is not base64.
connection terminated.
.. well the connection should not terminate here i think ?

rfc2554:
         If the server cannot BASE64 decode the argument, it rejects the
         AUTH command with a 501 reply.  If the server rejects the
         authentication data, it SHOULD reject the AUTH command with a
         535 reply unless a more specific error code


.) same thing for plain:


1027876424636 [INFO   ] (smtpserver): Connection from 127.0.0.1 (127.0.0.1)
1027876453457 [INFO   ] (smtpserver): Command received: EHLO cgshome
1027876460437 [INFO   ] (smtpserver): Command received: AUTH PLAIN
1027876473476 [DEBUG  ] (smtpserver): Exception opening socket: null
java.util.NoSuchElementException
	at java.util.StringTokenizer.nextToken(Unknown Source)
	at org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:331)
	at org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:238)
	at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:163)
	at org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(Connection.java:167)
	at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:47)
	at org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:86)


auth plain with no base64 or invalid username.
connection terminated.

the plain login should use base64 ?



3.) auth plain

due to: /rfc2595.txt

   The mechanism consists of a single message from the client to the
   server.  The client sends the authorization identity (identity to
   login as), followed by a US-ASCII NUL character, followed by the
   authentication identity (identity whose password will be used),
   followed by a US-ASCII NUL character, followed by the clear-text
   password.  The client may leave the authorization identity empty to
   indicate that it is the same as the authentication identity.


[authorize-id] NUL authenticate-id NUL password

e.g.: <NUL>tim<NUL>tanstaaftanstaaf

This is not reflected in your implementation. smtphandler line 328 ..
well i may be wrong, cause i do not have time to go into the rfc in detail.


4.) rfc2554:

   (5) an optional parameter using the keyword "AUTH" is added to the
       MAIL FROM command, and extends the maximum line length of the
       MAIL FROM command by 500 characters.

this seems not to be used by any client.


5.) rfc2554:
   AUTH mechanism [initial-response]

the initial-response is not handled ?



lg chris.


















 - CGS ( Schaefer EDV )    --------------------------------
 NIC: CS1156-RIPE        INTERNIC : CS11402
 office@cgs.co.at          http://www.cgs.co.at
 Office:
 Maroltingergasse 47/1604, 1160 Wien,
 Tel.: 494 83 07
 tech: Zieglergasse 13-2-5, 1070 Wien.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Quick Review & SMTP AUTH

Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,

> > 2.) since my akmail did not work with auth login i´ve tried to go
via
> > telnet:
> >
> >
.
.
.
> > .. well the connection should not terminate here i think ?
> >
> > rfc2554:
> >          If the server cannot BASE64 decode the argument, it rejects
> the
> >          AUTH command with a 501 reply.  If the server rejects the
> >          authentication data, it SHOULD reject the AUTH command with
a
> >          535 reply unless a more specific error code
> >
> >
> > .) same thing for plain:
> 
> Agreed.  Filing a bug and will be addressing shortly.
> 

As of today, this issue has been resolved in the 2.1 code base.

--Peter



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Quick Review & SMTP AUTH

Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Christian,

> 1. the smtp auth login/plain implementation seems to be a bit
different
> between certain clients and servers.
> i used akmail, mozilla, and outlook express.

Certainly true.  See recent discussions on james-user and james-dev
about bug #6340
 
> 2.) since my akmail did not work with auth login i´ve tried to go via
> telnet:
> 
> 
> 1027873583831 [INFO   ] (smtpserver): Connection from 127.0.0.1
> (127.0.0.1)
> 1027873597551 [INFO   ] (smtpserver): Command received: EHLO cgshome
> 1027873602788 [INFO   ] (smtpserver): Command received: AUTH LOGIN
> 1027873606664 [DEBUG  ] (smtpserver): Exception opening socket: null
> java.lang.NullPointerException
> 	at org.apache.james.util.Base64.decodeAsString(Base64.java:36)
> 	at
> org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:350)
> 	at
>
org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:23
8)
> 	at
>
org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.jav
a:
> 163)
> 	at
>
org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(Con
ne
> ction.java:167)
> 	at
>
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Execu
ta
> bleRunnable.java:47)
> 	at
>
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.ja
va
> :86)
> 
> 
> null-pointer exception if username is not base64.
> connection terminated.
> .. well the connection should not terminate here i think ?
> 
> rfc2554:
>          If the server cannot BASE64 decode the argument, it rejects
the
>          AUTH command with a 501 reply.  If the server rejects the
>          authentication data, it SHOULD reject the AUTH command with a
>          535 reply unless a more specific error code
> 
> 
> .) same thing for plain:

Agreed.  Filing a bug and will be addressing shortly.

> 
> 1027876424636 [INFO   ] (smtpserver): Connection from 127.0.0.1
> (127.0.0.1)
> 1027876453457 [INFO   ] (smtpserver): Command received: EHLO cgshome
> 1027876460437 [INFO   ] (smtpserver): Command received: AUTH PLAIN
> 1027876473476 [DEBUG  ] (smtpserver): Exception opening socket: null
> java.util.NoSuchElementException
> 	at java.util.StringTokenizer.nextToken(Unknown Source)
> 	at
> org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:331)
> 	at
>
org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:23
8)
> 	at
>
org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.jav
a:
> 163)
> 	at
>
org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(Con
ne
> ction.java:167)
> 	at
>
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Execu
ta
> bleRunnable.java:47)
> 	at
>
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.ja
va
> :86)
> 
> 
> auth plain with no base64 or invalid username.
> connection terminated.
> 
> the plain login should use base64 ?
> 

I'm also addressing.  It's the same basic problem, different lines of
code.

 
> 
> 3.) auth plain
> 
> due to: /rfc2595.txt
> 
>    The mechanism consists of a single message from the client to the
>    server.  The client sends the authorization identity (identity to
>    login as), followed by a US-ASCII NUL character, followed by the
>    authentication identity (identity whose password will be used),
>    followed by a US-ASCII NUL character, followed by the clear-text
>    password.  The client may leave the authorization identity empty to
>    indicate that it is the same as the authentication identity.
> 
> 
> [authorize-id] NUL authenticate-id NUL password
> 
> e.g.: <NUL>tim<NUL>tanstaaftanstaaf
> 
> This is not reflected in your implementation. smtphandler line 328 ..
> well i may be wrong, cause i do not have time to go into the rfc in
> detail.

I don't believe that 2595 is the relevant RFC.  Note that the RFC you're
quoting is related to SASL implementations, not SMTP auth.  RFC 2554
specifically states that the response string should be base64 encoded,
so what we really want is AUTH<NUL>[base-64-encoded-block] where
[base-64-encoded-block] is a base 64 encoding of
[user-id]<NUL>[password].  This is exactly what the current code
supports.

 
> 
> 4.) rfc2554:
> 
>    (5) an optional parameter using the keyword "AUTH" is added to the
>        MAIL FROM command, and extends the maximum line length of the
>        MAIL FROM command by 500 characters.
> 
> this seems not to be used by any client.

All this says is that the line length is extended.

> 
> 5.) rfc2554:
>    AUTH mechanism [initial-response]
> 
> the initial-response is not handled ?

This is resolved.  See recent discussions regarding bug #6340
 
--Peter



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Quick Review & SMTP AUTH

Posted by David Rodal <ir...@bellatlantic.net>.
I had problems with mozilla working.
I applied the patch that Peter Goldstein gave in bug 6340

My mozilla AND my apple OS X mail program now perform smtp auth
with james without a problem.

I don't know if it's the same problem as yours but it sounds like it 
could
be.

David Rodal



On Monday, July 29, 2002, at 11:44 AM, Christian Schäfer wrote:

>
> hi,
>
> i am currently searching for a substitution for sendmail.cf, because ...
>
> therefore i have done a quick review of james-2.0a3.
> pop3 get was ok.
> smtp put was not so good:
>
> 1. the smtp auth login/plain implementation seems to be a bit different 
> between certain clients and servers.
> i used akmail, mozilla, and outlook express.
>
> 2.) since my akmail did not work with auth login i´ve tried to go via 
> telnet:
>
>
> 1027873583831 [INFO   ] (smtpserver): Connection from 127.0.0.1 
> (127.0.0.1)
> 1027873597551 [INFO   ] (smtpserver): Command received: EHLO cgshome
> 1027873602788 [INFO   ] (smtpserver): Command received: AUTH LOGIN
> 1027873606664 [DEBUG  ] (smtpserver): Exception opening socket: null
> java.lang.NullPointerException
> 	at org.apache.james.util.Base64.decodeAsString(Base64.java:36)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:350)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:238)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:
> 163)
> 	at 
> org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run
> (Connection.java:167)
> 	at 
> org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute
> (ExecutableRunnable.java:47)
> 	at 
> org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:
> 86)
>
>
> null-pointer exception if username is not base64.
> connection terminated.
> .. well the connection should not terminate here i think ?
>
> rfc2554:
>          If the server cannot BASE64 decode the argument, it rejects the
>          AUTH command with a 501 reply.  If the server rejects the
>          authentication data, it SHOULD reject the AUTH command with a
>          535 reply unless a more specific error code
>
>
> .) same thing for plain:
>
>
> 1027876424636 [INFO   ] (smtpserver): Connection from 127.0.0.1 
> (127.0.0.1)
> 1027876453457 [INFO   ] (smtpserver): Command received: EHLO cgshome
> 1027876460437 [INFO   ] (smtpserver): Command received: AUTH PLAIN
> 1027876473476 [DEBUG  ] (smtpserver): Exception opening socket: null
> java.util.NoSuchElementException
> 	at java.util.StringTokenizer.nextToken(Unknown Source)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.doAUTH(SMTPHandler.java:331)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.parseCommand(SMTPHandler.java:238)
> 	at 
> org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:
> 163)
> 	at 
> org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run
> (Connection.java:167)
> 	at 
> org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute
> (ExecutableRunnable.java:47)
> 	at 
> org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:
> 86)
>
>
> auth plain with no base64 or invalid username.
> connection terminated.
>
> the plain login should use base64 ?
>
>
>
> 3.) auth plain
>
> due to: /rfc2595.txt
>
>    The mechanism consists of a single message from the client to the
>    server.  The client sends the authorization identity (identity to
>    login as), followed by a US-ASCII NUL character, followed by the
>    authentication identity (identity whose password will be used),
>    followed by a US-ASCII NUL character, followed by the clear-text
>    password.  The client may leave the authorization identity empty to
>    indicate that it is the same as the authentication identity.
>
>
> [authorize-id] NUL authenticate-id NUL password
>
> e.g.: <NUL>tim<NUL>tanstaaftanstaaf
>
> This is not reflected in your implementation. smtphandler line 328 ..
> well i may be wrong, cause i do not have time to go into the rfc in 
> detail.
>
>
> 4.) rfc2554:
>
>    (5) an optional parameter using the keyword "AUTH" is added to the
>        MAIL FROM command, and extends the maximum line length of the
>        MAIL FROM command by 500 characters.
>
> this seems not to be used by any client.
>
>
> 5.) rfc2554:
>    AUTH mechanism [initial-response]
>
> the initial-response is not handled ?
>
>
>
> lg chris.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  - CGS ( Schaefer EDV )    --------------------------------
>  NIC: CS1156-RIPE        INTERNIC : CS11402
>  office@cgs.co.at          http://www.cgs.co.at
>  Office:
>  Maroltingergasse 47/1604, 1160 Wien,
>  Tel.: 494 83 07
>  tech: Zieglergasse 13-2-5, 1070 Wien.
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:james-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-user-
> help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>