Re: [qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
Hi Eric 'shubes', Thanks for the detailed explaination! It gives me more knowledge about the flow of messages in QT! The QT installation is from end 2009, with an update in 2010. I give the details this evening (Amsterdam time). shame mode on No updates sinds 2010 shame mode off I will dig into your recommendations this evening! Richard. Congrats on finding this out on your own, Richard. I'm afraid though, that this isn't a very good solution to the problem. What you've done is to make yourself available as an open relay to all of the IP addresses included in the 'part of ip of transmitter'. This is great for spammers, and bad for you. If a spammer in that address range were to exploit the relay, you would soon find your IP address blacklisted, preventing you to send emails to many destinations. This is not a pleasant situation for anyone to be in. While the likelihood of someone actually exploiting your host may be low, it's best to simply eliminate the possibility. As a result, I recommend undoing your change to the tcp.smtp file, followed by doing a # service qmail cdb to make the change effective. Now the question is, why/how did that cure your delivery problem? Adding the RELAYCLIENT variable does a few things, but not all that much. It causes simscan to bypass SpamAssassin scanning (clamav scanning is still done), and it allows the sender to send to absolutely any domain (the Relay part) as opposed to sending only to the domains which are local to your host (domains listed in your rcpthosts file). As you'll notice in the smtp log, the next thing that typically follows the chkuser sender message is the chkuser rcpt (recipient) message. So it's a good guess that something is amiss with the message recipient(s), which is consistent with what we've observed with RELAYCLIENT. It's unfortunate in this case that qmail or chkuser doesn't give us any kind of message as to what exactly the problem is. That's not acceptable in my mind, but we'll have to work around it in the meantime. Speaking of log messages, qmail/SPF used to reject incoming messages with no log message, but that's been subsequently fixed. I also don't know if RELAYCLIENT bypasses the SPF check or not. I suppose it's possible that this is the problem you're experiencing. You might try changing your /var/qmail/control/spfbehavior from 3 to 1, then restarting qmail, and see if perhaps that remedies your problem. How old is your qmail-toaster package? # rpm -qa | grep toaster | sort will show us what versions you're running. Also, # qtp-whatami would be helpful. Let us know if this remedies your problem or not. If it doesn't I would install spamdyke (definitely do this regardless), then use spamdyke's detailed logging facility to see exactly what's going on with this. That would be the easiest way to see exactly where the smtp session fails. -- -Eric 'shubes' On 07/30/2012 07:27 AM, Richard Vinke wrote: Self-study is good I added the next line to /etc/tcprules.d/tcp.smtp: 'part of ip of transmitter':allow,RELAYCLIENT=,more text (Here i added the relayclient). Now the mails of that domain is dripping in! On 07/30/2012 06:21 AM, Richard Vinke wrote: Hi all, I set up a qmail toaster several years ago, but only used it with an external smtp server (my provider). Several weeks ago, I had to use the Toaster also as smtp server, so people can send mail to me directly. I changes the MX records, opened port 25 and... voilà, it works! But one sender cannot deliver mail. With =/usr/sbin/qmlog smtp=, I see (real sender domain is replaced with 'domain') 07-27 15:21:24 CHKUSER accepted sender: from i...@domain.nl:: remote relay.domain.nl:unknown:195.78.85.133 rcpt : sender accepted 07-27 15:21:24 tcpserver: end 3644 status 0 But no mail is delivered. When I send a test mail to the same email address, it arrives OK. I think, it has something to do with the 'relay', but I am not sure. How can I solve this? Richard - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
Here is the more detailed info: [richard@server10 ~]$ rpm -qa | grep toaster | sort autorespond-toaster-2.0.4-1.3.6 clamav-toaster-0.95.2-1.3.30 control-panel-toaster-0.5-1.3.7 courier-authlib-toaster-0.59.2-1.3.10 courier-imap-toaster-4.1.2-1.3.10 daemontools-toaster-0.76-1.3.6 ezmlm-cgi-toaster-0.53.324-1.3.6 ezmlm-toaster-0.53.324-1.3.6 isoqlog-toaster-2.1-1.3.7 libdomainkeys-toaster-0.68-1.3.6 libsrs2-toaster-1.0.18-1.3.6 maildrop-toaster-2.0.3-1.3.8 maildrop-toaster-devel-2.0.3-1.3.8 qmailadmin-toaster-1.2.12-1.3.8 qmailmrtg-toaster-4.2-1.3.6 qmail-pop3d-toaster-1.03-1.3.19 qmail-toaster-1.03-1.3.19 qmailtoaster-plus-0.3.2-1.4.16 qmailtoaster-plus.repo-0.2-2 ripmime-toaster-1.4.0.6-1.3.6 simscan-toaster-1.4.0-1.3.8 spamassassin-toaster-3.2.5-1.3.17 squirrelmail-toaster-1.4.19-1.3.15 ucspi-tcp-toaster-0.88-1.3.9 vpopmail-toaster-5.4.17-1.3.7 vqadmin-toaster-2.3.4-1.3.6 And: [richard@server10 ~]$ /usr/sbin/qtp-whatami qtp-whatami v0.3.7 Tue Jul 31 17:05:03 CEST 2012 DISTRO=CentOS OSVER=5.6 QTARCH=i686 QTKERN=2.6.18-238.9.1.el5 BUILD_DIST=cnt50 BUILD_DIR=/usr/src/redhat This machine's OS is supported and has been tested I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Now, I wait for mail and watch with =/usr/sbin/qmlog -f smtp= Best wishes, Richard On 07/31/2012 09:46 AM, Richard Vinke wrote: Hi Eric 'shubes', Thanks for the detailed explaination! It gives me more knowledge about the flow of messages in QT! The QT installation is from end 2009, with an update in 2010. I give the details this evening (Amsterdam time). shame mode on No updates sinds 2010 shame mode off I will dig into your recommendations this evening! Richard. Congrats on finding this out on your own, Richard. I'm afraid though, that this isn't a very good solution to the problem. What you've done is to make yourself available as an open relay to all of the IP addresses included in the 'part of ip of transmitter'. This is great for spammers, and bad for you. If a spammer in that address range were to exploit the relay, you would soon find your IP address blacklisted, preventing you to send emails to many destinations. This is not a pleasant situation for anyone to be in. While the likelihood of someone actually exploiting your host may be low, it's best to simply eliminate the possibility. As a result, I recommend undoing your change to the tcp.smtp file, followed by doing a # service qmail cdb to make the change effective. Now the question is, why/how did that cure your delivery problem? Adding the RELAYCLIENT variable does a few things, but not all that much. It causes simscan to bypass SpamAssassin scanning (clamav scanning is still done), and it allows the sender to send to absolutely any domain (the Relay part) as opposed to sending only to the domains which are local to your host (domains listed in your rcpthosts file). As you'll notice in the smtp log, the next thing that typically follows the chkuser sender message is the chkuser rcpt (recipient) message. So it's a good guess that something is amiss with the message recipient(s), which is consistent with what we've observed with RELAYCLIENT. It's unfortunate in this case that qmail or chkuser doesn't give us any kind of message as to what exactly the problem is. That's not acceptable in my mind, but we'll have to work around it in the meantime. Speaking of log messages, qmail/SPF used to reject incoming messages with no log message, but that's been subsequently fixed. I also don't know if RELAYCLIENT bypasses the SPF check or not. I suppose it's possible that this is the problem you're experiencing. You might try changing your /var/qmail/control/spfbehavior from 3 to 1, then restarting qmail, and see if perhaps that remedies your problem. How old is your qmail-toaster package? # rpm -qa | grep toaster | sort will show us what versions you're running. Also, # qtp-whatami would be helpful. Let us know if this remedies your problem or not. If it doesn't I would install spamdyke (definitely do this regardless), then use spamdyke's detailed logging facility to see exactly what's going on with this. That would be the easiest way to see exactly where the smtp session fails. -- -Eric 'shubes' On 07/30/2012 07:27 AM, Richard Vinke wrote: Self-study is good I added the next line to /etc/tcprules.d/tcp.smtp: 'part of ip of transmitter':allow,RELAYCLIENT=,more text (Here i added the relayclient). Now the mails of that domain is dripping in! On 07/30/2012 06:21 AM, Richard Vinke wrote: Hi all, I set up a qmail toaster several years ago, but only used it with an external smtp server (my provider). Several weeks ago, I had to use the Toaster also as smtp server, so people can send mail to me directly. I changes the MX records, opened port 25 and...
Re: [qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
You can also try the cwatchall script in the qtp-menu for watching activity. It's rather nice. On 07/31/2012 08:15 AM, Richard Vinke wrote: Here is the more detailed info: [richard@server10 ~]$ rpm -qa | grep toaster | sort autorespond-toaster-2.0.4-1.3.6 clamav-toaster-0.95.2-1.3.30 control-panel-toaster-0.5-1.3.7 courier-authlib-toaster-0.59.2-1.3.10 courier-imap-toaster-4.1.2-1.3.10 daemontools-toaster-0.76-1.3.6 ezmlm-cgi-toaster-0.53.324-1.3.6 ezmlm-toaster-0.53.324-1.3.6 isoqlog-toaster-2.1-1.3.7 libdomainkeys-toaster-0.68-1.3.6 libsrs2-toaster-1.0.18-1.3.6 maildrop-toaster-2.0.3-1.3.8 maildrop-toaster-devel-2.0.3-1.3.8 qmailadmin-toaster-1.2.12-1.3.8 qmailmrtg-toaster-4.2-1.3.6 qmail-pop3d-toaster-1.03-1.3.19 qmail-toaster-1.03-1.3.19 qmailtoaster-plus-0.3.2-1.4.16 qmailtoaster-plus.repo-0.2-2 ripmime-toaster-1.4.0.6-1.3.6 simscan-toaster-1.4.0-1.3.8 spamassassin-toaster-3.2.5-1.3.17 squirrelmail-toaster-1.4.19-1.3.15 ucspi-tcp-toaster-0.88-1.3.9 vpopmail-toaster-5.4.17-1.3.7 vqadmin-toaster-2.3.4-1.3.6 And: [richard@server10 ~]$ /usr/sbin/qtp-whatami qtp-whatami v0.3.7 Tue Jul 31 17:05:03 CEST 2012 DISTRO=CentOS OSVER=5.6 QTARCH=i686 QTKERN=2.6.18-238.9.1.el5 BUILD_DIST=cnt50 BUILD_DIR=/usr/src/redhat This machine's OS is supported and has been tested I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Now, I wait for mail and watch with =/usr/sbin/qmlog -f smtp= Best wishes, Richard On 07/31/2012 09:46 AM, Richard Vinke wrote: Hi Eric 'shubes', Thanks for the detailed explaination! It gives me more knowledge about the flow of messages in QT! The QT installation is from end 2009, with an update in 2010. I give the details this evening (Amsterdam time). shame mode on No updates sinds 2010 shame mode off I will dig into your recommendations this evening! Richard. Congrats on finding this out on your own, Richard. I'm afraid though, that this isn't a very good solution to the problem. What you've done is to make yourself available as an open relay to all of the IP addresses included in the 'part of ip of transmitter'. This is great for spammers, and bad for you. If a spammer in that address range were to exploit the relay, you would soon find your IP address blacklisted, preventing you to send emails to many destinations. This is not a pleasant situation for anyone to be in. While the likelihood of someone actually exploiting your host may be low, it's best to simply eliminate the possibility. As a result, I recommend undoing your change to the tcp.smtp file, followed by doing a # service qmail cdb to make the change effective. Now the question is, why/how did that cure your delivery problem? Adding the RELAYCLIENT variable does a few things, but not all that much. It causes simscan to bypass SpamAssassin scanning (clamav scanning is still done), and it allows the sender to send to absolutely any domain (the Relay part) as opposed to sending only to the domains which are local to your host (domains listed in your rcpthosts file). As you'll notice in the smtp log, the next thing that typically follows the chkuser sender message is the chkuser rcpt (recipient) message. So it's a good guess that something is amiss with the message recipient(s), which is consistent with what we've observed with RELAYCLIENT. It's unfortunate in this case that qmail or chkuser doesn't give us any kind of message as to what exactly the problem is. That's not acceptable in my mind, but we'll have to work around it in the meantime. Speaking of log messages, qmail/SPF used to reject incoming messages with no log message, but that's been subsequently fixed. I also don't know if RELAYCLIENT bypasses the SPF check or not. I suppose it's possible that this is the problem you're experiencing. You might try changing your /var/qmail/control/spfbehavior from 3 to 1, then restarting qmail, and see if perhaps that remedies your problem. How old is your qmail-toaster package? # rpm -qa | grep toaster | sort will show us what versions you're running. Also, # qtp-whatami would be helpful. Let us know if this remedies your problem or not. If it doesn't I would install spamdyke (definitely do this regardless), then use spamdyke's detailed logging facility to see exactly what's going on with this. That would be the easiest way to see exactly where the smtp session fails. -- -Eric 'shubes'
[qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
On 07/31/2012 11:36 AM, Richard Vinke wrote: On 07/31/2012 05:15 PM, Richard Vinke wrote: I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Mail is dripping in! But, I changed it back, did the =qmailctl cdb= and =qmailctl restart=, and still the mail is dripping in ?? At least, my problem is solved. - The SPF problem is extremely intermittent, and difficult to reproduce. Many people run with SPF 3 and don't notice a problem. I suspect it *may* be related to a malformed SPF record (which is part of the sender domain's DNS) that triggers the problem with QMT's SPF implementation. That's just a guess though. BL is that the difference between SPF 1 and SPF 3 is negligible, especially with spamdyke implemented. FWIW, I'm hoping that one day spamdyke will implement SPF and DKIM checking, but don't look for that enhancement any time this year. Sam's presently pretty busy with other things. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
On 07/31/2012 09:22 PM, Eric Shubert wrote: On 07/31/2012 11:36 AM, Richard Vinke wrote: On 07/31/2012 05:15 PM, Richard Vinke wrote: I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Mail is dripping in! But, I changed it back, did the =qmailctl cdb= and =qmailctl restart=, and still the mail is dripping in ?? At least, my problem is solved. - The SPF problem is extremely intermittent, and difficult to reproduce. Many people run with SPF 3 and don't notice a problem. I suspect it *may* be related to a malformed SPF record (which is part of the sender domain's DNS) that triggers the problem with QMT's SPF implementation. That's just a guess though. BL is that the difference between SPF 1 and SPF 3 is negligible, especially with spamdyke implemented. FWIW, I'm hoping that one day spamdyke will implement SPF and DKIM checking, but don't look for that enhancement any time this year. Sam's presently pretty busy with other things. Hi Eric, If i read between the lines, i should set SPF on 1. To prevent any future problems. Is that correct? - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
On 07/31/2012 12:26 PM, Richard Vinke wrote: On 07/31/2012 09:22 PM, Eric Shubert wrote: On 07/31/2012 11:36 AM, Richard Vinke wrote: On 07/31/2012 05:15 PM, Richard Vinke wrote: I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Mail is dripping in! But, I changed it back, did the =qmailctl cdb= and =qmailctl restart=, and still the mail is dripping in ?? At least, my problem is solved. - The SPF problem is extremely intermittent, and difficult to reproduce. Many people run with SPF 3 and don't notice a problem. I suspect it *may* be related to a malformed SPF record (which is part of the sender domain's DNS) that triggers the problem with QMT's SPF implementation. That's just a guess though. BL is that the difference between SPF 1 and SPF 3 is negligible, especially with spamdyke implemented. FWIW, I'm hoping that one day spamdyke will implement SPF and DKIM checking, but don't look for that enhancement any time this year. Sam's presently pretty busy with other things. Hi Eric, If i read between the lines, i should set SPF on 1. To prevent any future problems. Is that correct? - That's the setting I use. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
On 07/31/2012 09:31 PM, Eric Shubert wrote: On 07/31/2012 12:26 PM, Richard Vinke wrote: On 07/31/2012 09:22 PM, Eric Shubert wrote: On 07/31/2012 11:36 AM, Richard Vinke wrote: On 07/31/2012 05:15 PM, Richard Vinke wrote: I changed: * removed the RELAYCLIENT and did =qmailctl cdb= * changed /var/qmail/control/spfbehavior from 3 to 1 and did =qmailctl restart= Mail is dripping in! But, I changed it back, did the =qmailctl cdb= and =qmailctl restart=, and still the mail is dripping in ?? At least, my problem is solved. - The SPF problem is extremely intermittent, and difficult to reproduce. Many people run with SPF 3 and don't notice a problem. I suspect it *may* be related to a malformed SPF record (which is part of the sender domain's DNS) that triggers the problem with QMT's SPF implementation. That's just a guess though. BL is that the difference between SPF 1 and SPF 3 is negligible, especially with spamdyke implemented. FWIW, I'm hoping that one day spamdyke will implement SPF and DKIM checking, but don't look for that enhancement any time this year. Sam's presently pretty busy with other things. Hi Eric, If i read between the lines, i should set SPF on 1. To prevent any future problems. Is that correct? - That's the setting I use. This night the mails 'suddenly' stops dripping in. (SPFbehavior still on 3). I read the topic http://wiki.qmailtoaster.com/index.php/Spfbehavior, and set the SPFbehavior to 1. Tonight, i will check the header info. - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: [SOLVED] CHKUSER accepted sender, but no mail received
Congrats on finding this out on your own, Richard. I'm afraid though, that this isn't a very good solution to the problem. What you've done is to make yourself available as an open relay to all of the IP addresses included in the 'part of ip of transmitter'. This is great for spammers, and bad for you. If a spammer in that address range were to exploit the relay, you would soon find your IP address blacklisted, preventing you to send emails to many destinations. This is not a pleasant situation for anyone to be in. While the likelihood of someone actually exploiting your host may be low, it's best to simply eliminate the possibility. As a result, I recommend undoing your change to the tcp.smtp file, followed by doing a # service qmail cdb to make the change effective. Now the question is, why/how did that cure your delivery problem? Adding the RELAYCLIENT variable does a few things, but not all that much. It causes simscan to bypass SpamAssassin scanning (clamav scanning is still done), and it allows the sender to send to absolutely any domain (the Relay part) as opposed to sending only to the domains which are local to your host (domains listed in your rcpthosts file). As you'll notice in the smtp log, the next thing that typically follows the chkuser sender message is the chkuser rcpt (recipient) message. So it's a good guess that something is amiss with the message recipient(s), which is consistent with what we've observed with RELAYCLIENT. It's unfortunate in this case that qmail or chkuser doesn't give us any kind of message as to what exactly the problem is. That's not acceptable in my mind, but we'll have to work around it in the meantime. Speaking of log messages, qmail/SPF used to reject incoming messages with no log message, but that's been subsequently fixed. I also don't know if RELAYCLIENT bypasses the SPF check or not. I suppose it's possible that this is the problem you're experiencing. You might try changing your /var/qmail/control/spfbehavior from 3 to 1, then restarting qmail, and see if perhaps that remedies your problem. How old is your qmail-toaster package? # rpm -qa | grep toaster | sort will show us what versions you're running. Also, # qtp-whatami would be helpful. Let us know if this remedies your problem or not. If it doesn't I would install spamdyke (definitely do this regardless), then use spamdyke's detailed logging facility to see exactly what's going on with this. That would be the easiest way to see exactly where the smtp session fails. -- -Eric 'shubes' On 07/30/2012 07:27 AM, Richard Vinke wrote: Self-study is good I added the next line to /etc/tcprules.d/tcp.smtp: 'part of ip of transmitter':allow,RELAYCLIENT=,more text (Here i added the relayclient). Now the mails of that domain is dripping in! On 07/30/2012 06:21 AM, Richard Vinke wrote: Hi all, I set up a qmail toaster several years ago, but only used it with an external smtp server (my provider). Several weeks ago, I had to use the Toaster also as smtp server, so people can send mail to me directly. I changes the MX records, opened port 25 and... voilà, it works! But one sender cannot deliver mail. With =/usr/sbin/qmlog smtp=, I see (real sender domain is replaced with 'domain') 07-27 15:21:24 CHKUSER accepted sender: from i...@domain.nl:: remote relay.domain.nl:unknown:195.78.85.133 rcpt : sender accepted 07-27 15:21:24 tcpserver: end 3644 status 0 But no mail is delivered. When I send a test mail to the same email address, it arrives OK. I think, it has something to do with the 'relay', but I am not sure. How can I solve this? Richard - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
