Jake Vickers wrote:
Mike Canty wrote:Eric, Sorry, but what you have suggested, is not working for me.I have altered the tcp.smtp file with your suggestion. I have included a line exactly like the 127. Line but changed the IP address to be 192.168.xxx. (obviously the xxx is a number).I was having messages on the sending server, but I have corrected these. Aline from the maillog on the sending server reads as below (the actual server that is sending the message is shown here as "r...@server.domainname.com.au", the recipient is"u...@anotherdomainname.com.au" and the relay is the recipient mail serverAug 19 14:13:25 server sendmail[2101]: n7J4hPKb002101: from=root, size=357,class=0, nrcpts=1, msgid=<200908190443.n7j4hpkb002...@server.domainname.com.au>, relay=r...@localhost Aug 19 14:13:26 server sendmail[2102]: n7J4hPPH002102: from=<r...@server.domainname.com.au>, size=697, class=0, nrcpts=1,msgid=<200908190443.n7J4hPKb002101@ server.domainname.com.au>, proto=ESMTP,daemon=MTA, relay=localhost.localdomain [127.0.0.1] Aug 19 14:13:26 server sendmail[2101]: n7J4hPKb002101: to=u...@anotherdomain.com.au, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30357, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (n7J4hPPH002102 Message accepted for delivery) Aug 19 14:13:26 server sendmail[2104]: STARTTLS=client, relay=mailserver.anotherdomain.com.au., version=TLSv1/SSLv3, verify=FAIL, cipher=AES256-SHA, bits=256/256 From what I can gather here the message was sent OK from the originating server. However, the message is still showing as below. -------------------------------- The original message was received at Wed, 19 Aug 2009 14:13:25 +0930 from localhost.localdomain [127.0.0.1] ----- The following addresses had permanent fatal errors ----- <u...@anohterdomain.com.au> (reason: 511 sorry, can't find a valid MX for sender domain (#5.1.1 - chkuser))The settings for chkuser to verify a valid MX record for the sending domain (TTBOMK) cannot be changed with a switch. It can only be changed by editing the source code and recompiling. You will need to have that sender get a valid MX record created or create your own DNS entry to allow it through.
See http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html I believe you can add a variable definition to your line in tcp.smtp that tells chkuser not to check this. Since CHKUSER_SENDER_MX is already set at compile time, I don't know how you'd unset it using an environment variable. Looks like you can turn off chkuser entirely though. See CHKUSER_STARTING_VARIABLE. If I'm reading that right, if you add "CHKUSER_STARTING_VARIABLE=CU_START_VAR,CU_START_VAR=none" would turn off chkuser entirely for that connection.
On a side note, could CHKUSER_ALLOW_SENDER_CHAR_3="/" be used for blackberries, without having to rebuild qmail-toaster? If so, I think this adds fodder to redoing the stock toaster chkuser defaults. I'm thinking that if options cannot be turned off dynamically (CHKUSER_SENDER_MX for example), then they should be left off at compile time and activated in the tcp.smtp file, so that they can be dynamically disabled if desired. It could very well be that we can simply use the stock chkuser defaults as they are, and use definitions in tcp.smtp for toaster variants.
Or perhaps I'm just not awake yet (still dreaming).
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
