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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
