""Bürkle wrote:
i posted a lot, but i think i missed that one:
when the authentification failed, i always get the following
error in the
mail.log:
Nov 6 17:37:09 tank courieresmtpd: started,ip=[::ffff:192.168.0.1]
Nov 6 17:37:09 tank courieresmtpd:
error,relay=::ffff:192.168.0.1,from=<SENDER>,to=<RECEIP>: 450 Service
temporarily unavailable.
This looks like wrong [servername|database|username|password]
or mysql
server not running. Are you sure that during MYSQL_SELECT_CLAUSE test
you are using the right mysql connection parameters?
Rodrigo, here's my file again:
----------------------
##VERSION: $Id: authmysqlrc,v 1.14 2003/05/09 18:15:15 mrsam Exp $
MYSQL_SERVER 127.0.0.1
MYSQL_USERNAME courier
MYSQL_PASSWORD *******
MYSQL_PORT 3306
MYSQL_OPT 0
MYSQL_DATABASE mailuser
MYSQL_USER_TABLE user
MYSQL_CLEAR_PWFIELD passwd
MYSQL_UID_FIELD uid
MYSQL_GID_FIELD gid
MYSQL_LOGIN_FIELD id
MYSQL_HOME_FIELD home
MYSQL_QUOTA_FIELD concat(quota_size * 1024, "S")
# MYSQL_SELECT_CLAUSE SELECT concat(id,
"@mydomain.com"),"",passwd,uid,gid,home,"",concat(quota_size * 1024, "S"),""
FROM user WHERE id = "$(local_part)"
----------------------
About the connection:
With the commented MYSQL_SELECT_CLAUSE it works perfect, but when its
uncommented its not working at all (just a connect to the mysql, but no
query). So both time it should use the same connection, because i just
change the single line, or?
About the error "450 Service temporarily unavailable":
I tested and found, that when i, for example, change the tablename to a
non-existing one, i get the same error. -> So i think its the standard
message for those kind of "get-nothing-back-from-database" errors ;-)
I believe that you reached the
something_silly_done_during_these_long_tests_is_blocking_final
_success
stage.
*Grin*, would be nice if it would be so.
I can't believe that this could be so complicated.
At the moment i'm sniffing the mysql-port via tcpdump and ethereal. This
shows me, that everthing works equal (the Connect, the Init DB) until it
comes to select clause. The next packet in the working constellation has the
SELECT-data. The same packet in the non-working constellation has no data.
So for me, it looks like that it is no database or connection problem, what
do you think?
MANY MANY greets
Roman Bürkle
3 messages in net.sourceforge.lists.courier-usersAW: AW: [courier-users] authmysqlrc +...
